JJUG CCC 2019 Spring 参加メモ

5/18(土)に開催されたJJUG CCC 2019 Springに参加してきました。
その時のメモを復習がてらまとめてます。

資料まとめサイト

有志の方がセッション資料をまとめてくださっています。
https://sun0range.com/event-report/jjug-ccc-2019-spring-time-table

10:00~ 初めてのgRPC

  • 資料：https://speakerdeck.com/line_developers/starting-grpc

    • 発表資料にサンプルコードがちょこちょこ書いてたので資料の充実さがすごい

  • Swaggerからソースを自動生成できるけどなんだかんだ手を入れる必要がある

    • 仕様に変更会った時再生成したらまた編集しないとでしんどい。。。
  • protoファイルは基本的にいじらないから楽？
  • messageとかserviceとかprotoファイルの定義が必要だけど書き方がJavaのクラスとかIFっぽい
  • gradleでプラグイン入れれば使える
    • オプションで細かいこと設定できるけど割と読み解くのが大変だったらしい
  • Stubは3種類あるけど全部使おうとすると大変だから基本はBrockingStubを使えばいける
  • 引数、戻り値にstreamをつけることで複数のデータ送受信ができる！
    • streamつけるとちょっとコードがめんどくさくなるらしい。。
  • 1:1、1:複数までは割と実装しやすいけど、クライアントから複数渡す形式は実装がややこしい
    • そもそもクライアントから複数通信ってあんまり使わない。。。
  • stream処理を書くための拡張みたいのは色々でてる
  • ブラウザからはREST、内部だけgRPCで通信が良さげ？
  • Spring bootとgRPCを合わせて使うライブラリが2つほどあり、実際に使うならその辺を使うのが現実的っぽい
  • リバプロ型、クライアントサイド型とかもあるけど、サービスメッシュ型が最近は流行りっぽい
  • 割といろんな仕組み使わないといけないから、マイクロサービスとの相性はよさげではあるけど、実装時点ではJava Servletレベルのエコシステムしかないから結構しんどいかも。。

感想

マイクロサービスを実際に作ってRESTで苦労した経験がそもそもないのでありがたみについてはあまりイメージできなかったです……
ただ、マイクロサービスの内部もRESTでカッチリやろうとすると消耗するみたいな話はよく聞くので、手段の1つとしては覚えておきたいところ。

11:00~ 大企業運営の法人向けサービスにおけるOpenJDK移行事例

  • 資料：https://slides.com/hiroyuki_onaka/jjug-ccc-2019-spring/#/

  • SIerの立場での発表！

  • 単純な話JAVA_HOMEとかをきりかえる”だけ”
  • RHEL系の話
  • Apache FelixがOpenJDK11.0.1⇨11.0.2でバグ
    • リリースノートが提供されるようになったのは11.0.3からなので見れない。。。
    • コミットログとかを追った
      • 今後はトラブルが発生した時にOSS的に問題を切り分けてく必要がある！
        • Issueとかコミットログとか
  • 芋づる式に地獄のバージョンアップ
    • OpenJDK以降の時にDBバージョンアップする必要が出てくる。。。
    • Tomcatのserver.xmlとかも。。。
  • OS側がJDKを動かすための依存がOracleJDKとOpenJDKだと違う(OpenJDKのが多い)
  • 通信相手のTLSアルゴリズムが古すぎると使えなくなる。。。
  • インフラ周りを放置しすぎてると地獄
    • JDK6&Struts&古いWebLogicとかはやばかったらしい
    • 継続的にインフラをメンテできてればまだ対応しやすい
      • SIerにとって継続的にインフラをアプデできる体制に移行できるのはここが最後ですよ！！

感想

芋づる式のアップデートとか、まったく他人事じゃないよなぁって話でした……
実際今私がいる案件もまだ話は出てないものの、Tomcatバージョンが古かったりStrutsを使っていたり、継続的なメンテができているとはお世辞にも言えない状態なので地獄を見そうですね。

11:25~ 開発リーダー1年目。メンバーのスキルアップのためにやっていること。

  • 資料：https://docs.google.com/presentation/d/1Xx5UPJkmy2dgzRloe8zaGGpEPWk1rhLiAMypK4TKRz8/edit

  • 正社員2名でパートナー4人でうちでもありそうな構成

  • 結局正社員だろうがパートナーだろうがキャリアとか環境に合ってないと思われるとみんなやめてく
  • 輪読会、ランチ、夕会や雑談
  • 輪読会を実際どのようにやってるか資料に乗ってる
    • うちでも割と有効そう
    • こういう本読んどいて〜とかは結局みんな読まない、とか読んでも内容はイマイチ。。みたいなパターンが多い
    • リーダブルコードとかを使うことで良いコードを意識するメンバーが増えた
  • ランチを断る人もいるけど、断れる環境っていいよね
  • マネージャとしてのキャリアってエンジニアとしてのキャリア+α
  • 自分がやったほうが早いって考えはやめとけ
    • メンバがつまづくとこを直してくだけで1人がやるより断然速度は早くなる

感想

これまた全く他人事じゃない話。
私自身、入社してしばらくは本も全く読まなかったし、先輩からこれ読んだ方がいいよ！と言われても結局読まないことが多かったのでこの輪読会って方法は割と良さそうだと思いました。
雑談は本当大事！雑談がしやすい環境の案件、雑談がしづらい環境の案件のどちらも環境も経験しましたが、
雑談しやすい環境のが圧倒的に仕事のコミュニケーションも取りやすかったです。
現在の案件でもメンバーとして意識してることの1つですね～。

13:30~ 先行開発！Javaでクリーンアーキテクチャ – ゼロから始める新規開発

  • 資料：https://nrslib.com/clean-architecture-with-java/

    • 記事としてもまとめてくださってる！

  • クリーンアーキテクチャのよくある図の前にヘキサゴナルアーキテクチャ（ポートアンドアダプター）

    • ゲーム機本体とディスプレイなどの周辺機器の関係みたいな
    • アプリケーションだと入出力デバイスもデータストアのことも知らない
  • クリーンアーキテクチャはヘキサゴナルアーキテクチャの実装方法を説明するアイデア
  • ドメインとしてのエンティティとデータモデルは違うし画面出力用のviewmodelも違う

感想

以前自分で調べた際にあまりイメージできなかったクリーンアーキテクチャが、なんとなくイメージできるまでになったわかりやすい発表でした。
資料だけでもわかりやすい上、復習用に記事までまとめてくださっているため興味がある方はぜひ資料URLに飛んで見てみてください。
アーキテクチャそのものは非常に有用なものだと感じましたが、インターフェースをがっつり切る分実装のコストは大きそうで、「本当に必要か？」はよく考える必要があるように感じました。

14:30~ テストエンジニアが教える JUnitを書き始める前に考えるべきテスト

  • 資料：https://speakerdeck.com/nihonbuson/jjug-ccc-2019-spring

  • テストは品質レベルが”十分”であることしか示せない(※完璧じゃない)

  • 実装の作り込みの防止もテストの大切な目的
  • テストの内容についても議論しましょう！
    • ペアワークを実際にやったけど、テストの仕様を他の人と話すと、自分が気づいてないテストがでてきた
  • プログラム書く前から”何をテストする？？”を話すだけでも効果がある
  • テストケースを考える時は理由を必ず考える！
    • 選択肢5つのうち2つをテストします⇨どうして？⇨境界値
    • 理由がそのまま具体的なテストケース名になる
  • 開発者がやるのはchecking、QAがやるのはTesting
  • 自動テストでできるのはcheckingだけ
  • 発表資料内にテストに関するおすすめ書籍あり
  • JaSSTってイベントはおすすめとのこと

感想

思っていたより基本的な内容のお話でした。
ただ、わかってはいるけどやれてないって案件は実際多そうにも感じてます。
実装前に”何をテストする？”をしっかり考える部分については、工数に関係なく取り組める話だと思うので日々実践していきたいですね。

15:45~ 1400万ユーザーのWebサービスを15年運用して考える、Javaである理由

感想

いくつか理由は上げていらっしゃったものの、社内のナレッジ蓄積と人の集めやすさが結局大きい印象を受けました。
ここしばらくJavaScriptを触ってて型の厳しさに対するありがみは感じるようになりましたが、それもTypeScriptを使えばほぼ解決するんですよね……
言語的な部分で言うならJavaを使う理由ってそこまでないのかなぁと感じました。

16:45~ ストラングラーパターンによるマイクロサービスマイグレーションの勘所

  • 資料：https://speakerdeck.com/kawakamitor/jjug-ccc-2019-spring

  • Oracleがやっぱりボトルネック

  • k8sのスタンダードな構成
    • それぞれはSpring Bootで実装
  • Strangler Pattern
  • Azureのサービスを一旦経由させて従来のDB⇨サービスからAzure上のDBを見るように
    • joinjoin&joinが厄介
    • 効果の高いところから始め、場合によっては大胆に移行するしかない
  • SwaggerでSpringのControllerを自動生成
    • クライアントも自動生成できるからうまく使えばSwaggerは便利！
  • k8sを使った開発ではこれまで以上にログ収集が必須
    • Papertrailを使用しているらしい
  • spring-cloud-starter-sleuthはSpringBootならとりあえず入れとけ！
    • サービスをまたいだリクエストのログを識別できるようになる
  • k8s周りは非互換なバージョンアップがあるので注意！
    • 基本的には新クラスタ立てて並行稼働しつつ切り替えていこう

感想

今いる案件でマイクロサービスをやるならまさにこのパターンになるんだろうなぁって感じのセッションでした。
joinしまくってる箇所の分割、移行は本当にネックですね……

17:45~ マイクロサービス：４つの分割アプローチの比較

  • 資料：https://www.slideshare.net/masuda220/ss-146325870

  • クラウド、コンテナは必要なものだけど、結局重要なのは設計スキル

  • 前提として、発表者の人は（プロダクトには）枯れた技術しか使いたくない
  • まずはモノリスで作ってからマイクロサービスへの検討
    • 多分うちもこんな流れになるよね
  • そもそも関心の分離とか疎結合とかはマイクロサービスうんぬん関係なく必要な内容
  • 実際問題マイクロサービスでどこまで小さくできるかはスキル次第
    • 最初はある程度まで分散して、経験、実績が出れば次の段階でさらに細かく分けるという方法
  • マイクロサービス化した時にモノリスではありえなかった問題が出てくる
    • 経験をつめば問題なくなってくるが、ここを考えておかないと辛い目にあうだけ。。。
  • マイクロサービス間の通信8つの勘違いと真実
    • ぶっささる人多い気がするので要チェック！

  • 設計時点での論理的な分割はとにかく積極的に！

    • 設計がよくなればなるほどマイクロサービス化のハードルも下がる

  • ビジネスロジックでの分割の説明中Twitterでコンウェイの法則？が話題に上がってた

  • ユースケース単位での分割

    • ユースケースで分割した裏で、ロジックを領域ごとに整理して管理することで、重複やデータ不整合を防ぐ

  • ドメイン駆動的な分割

    • そもそもエヴァンス流とバーノン流で違うっぽい？
    • わからん！とのこと

  • ドメイン駆動設計の「モデル」はビジネスルール

  • 時間の都合上トランザクションについては資料を参照してね

感想

マイクロサービス化を行うときに頭に入れておかねば……！みたいな内容がつまりにつまった濃いセッションでした。
個人的に以下2点は忘れないようにしたいと感じました。

  • 論理的な分割は積極的に、物理的な分割は慎重に
    • 論理的な分割のノリで物理的な分割をやってしまい、システムが複雑になって地獄を見る……というのは実際にハマりそうなパターンだったので
  • マイクロサービス間の通信8つの勘違いと真実
    • この勘違いをして地獄を見る想像が一瞬でできたので……

セッションは聞いてないけどtwitterタグ監視で見つけた話題

  • Javaアプデについて
    • 今後JavaはLTSだけを追おうとすると変更多くてキツいのでちゃんと半年ごとのアプデチェックしましょう
  • 教育系
    • Javaの従来型の新人研修は現場と乖離がある
    • 検収時点からLint入れて綺麗なコードを意識させる