JJUG CCC 2019 Spring に行ってきた #jjug_ccc

Java メモ

JJUG CCC 2019 Spring に行ってきました。簡単に所感をまとめます。

jjug.doorkeeper.jp

セッション資料は以下で公開されると思います。

GitHub - jjug-ccc/slides-articles-2019Spring: JJUG CCC 2019 Spring 登壇資料まとめ

所感

今回、会場に WiFi が設置されてました。快適。

Java そのものやフレームワークの話ではなく、事例や設計手法の話が以前より増えた気がする。CfPでそういうのを選んでるんだろうか。あと、アンカファレンスがおもしろそうだった。次回はそっちを聴いてみよう。

以下、メモから抜粋。

初めてのgRPC

寝坊して朝イチのこれが聴けなかった。あとで資料を読む。

What's new in Jakarta EE and Eclipse GlassFish (May 2019)

www.slideshare.net

  • Java は Oracle の商標
  • javax.* の copyright は Oracle
    • javax.* ⇒ jakarta.* に変わる予定？
  • Jakarta EE 8
    • Java EE 8 とほとんど変わらない
  • Jakarta EE 9
    • APIのテコ入れ
    • JSFメジャーバージョンアップ
    • CDIとの結び付きが強くなる？
    • APIに手が入るところはパッケージが変わるはず
    • javax パッケージは互換性のために残る
  • Java EE に比べて開発スピードはかなり早くなるはず
  • Java EE 8 に対応したベンダーは Jakarta EE にも追従するはず
  • https://jakartablogs.ee/

ちょうどGWあたりにパッケージの話が流れてきた気がする。誰がわるいということではないし、開発スピードが上がるので Jakarta EE はまだまだこれからとのこと。

ArchUnit で Java / Kotlin アプリケーションのアーキテクチャを CI する

確かにアーキテクチャは暗黙知になりがちで時間がたつにつれてブレる気がする。今回、初めて ArchUnit を知ったけどなかなかよさそう。ちょっと調べてみよう。

Catch up Java 12 and Java 13

www.slideshare.net

  • Java 12 の変更点はそれほど多くない
  • APIの削除はなかった
  • Javaが持っているGCは全部で7個に
  • 新しくGCは入ったがツールはこれから対応される見込み
  • OSから借りたメモリは基本的にはOSに返さない
    • Java 12 で未使用のメモリを返すように
  • Switch が文から式に (プレビュー)
    • break ⇒ break-with？
  • JMHはマイクロベンチマークの選択肢として便利

個人的には Switch 式と String#transform が気になる。要復習。

Java クライアント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

CData JJUG 2019 Spring 参考資料 · GitHub

  • APIをもっと楽に使えるように
  • API開発でなぜ苦労するのか
  • RESTはソフトウェアアーキテクチャのスタイル (原則であって規約ではない)
    • ドキュメントを読み解かないとわからない
  • OData
  • GraphQL
    • ネストした情報を一発で取得できる
    • RESTではそれぞれ取得するか、専用のエンドポイントを用意するか
    • Javaで使うのはまだつらい...？
  • CData JDBC Driver
    • Web API を SQL で実行できる

以前、GraphQL を少し試してみたけど、確かに Java ではまだまだ使いやすいとは言えない感じだったかな。今後に期待ですが。OData はあまり聞いたことがなかったけど、エンタープライズ向けには割と使いやすいみたいなので、ちょっと押さえておこうかな。どうでもいいけど、タイトルがずっと "クライント" になってるのが気になった。

LINEのBOT Platformの裏側の話

  • LINEではJava利用が圧倒的に多い
  • Kotlinも増えてきている
  • Streaming API
    • リアルタイム性が重要
    • Server-Sent Event by Spring WebFlux
    • 双方向通信の必要はなかったので WebSocket は採用しなかった
  • Redis の Pub/Sub と Kafka の組み合わせ
  • SSE は長時間イベントを送らないと接続が切れる
    • ping 送信用の Flux を merge (10秒間隔で ping 送信)
  • SSE の再接続
    • Last Event ID
  • Data Hub として Kafka を使っている
    • Consumer Group で複数サービスに配信？
  • logback + MDC
    • ThreadLocal ベースで実装されている機能
    • ログに reqeust 情報を追加する
    • WebFlux で使う場合はひと工夫が必要？
  • モニタリング

もしかしたら普通なのかもしれないけど、LINE では Kafka をいろいろ活用されてるんですね。そこらへんのノウハウがいっぱいありそう。

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

ストラングラーパターン。モノリスなアプリケーションを段階に置き換えるという話。機能やアーキテクチャより、ログ管理やインフラ周りの運用がキモに思えた。

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

www.slideshare.net

  • マイクロサービスを実現する技術においてコンテナの存在は大きい
  • 4つの動機のうち今日のメインは機能分散
  • 最初にモノリスで作って、抜き出せる機能/移行を検討する
  • モノリスで有効な設計はマイクロサービスでも同様のはず☆
  • クラウドによって非同期はやりやすくなった/当たり前になってきた
  • 論理的なモジュール分割は積極的に大胆に
  • 物理的な配置と運用単位は慎重に
  • マイクロサービスではモノリスにはない考慮ポイントが多い
    • ノウハウがあればいいが最初のうちは慎重にやる
  • マイクロサービス間の通信の勘違いと真実☆
    • ネットワーク全体は等質ではない
  • 4つのアプローチ☆
    • 実際には択一ではなく組み合わせ
  • 部門の構造とシステム構造が一致させるのがよいとは限らない？
  • ユースケースで分割するとトランザクション単位のマイクロサービスになる
    • ユースケースサービスを薄くして、後ろに各サービスを置く リソースで分割
    • リソースをまたがった参照が複雑になりがち
      • 外部キー制約が使えない、JOINが使えない
    • モノリスでは識別単位の情報にいろいろ持たせ過ぎていた？
    • リソース管理単位を分割する
  • ビジネスルールの分割パターン
    • 入出力はシンプルになる
  • トランザクション分解パターン☆
  • モノリスのトランザクションはマイクロサービスでは適用できないかも

要復習。モノリスで有効な設計スキルはマイクロサービスでは同じとのこと。ただ、マイクロサービスに分割する際にはマイクロサービス特有の考慮ポイントがあることに注意する必要がありそう。