2024/06/16に開催された JJUG CCC Spring 2024 に参加してきました。 JJUG CCCはもちろん、オフラインの勉強会に参加するのは本当に久しぶりのことです。コロナ禍以来、こういうのとはすっかり遠ざかっていました (あと一時期Javaから離れていたこともありましたが) 。懐かしい方々とも久しぶりに顔を合わせて話をすることができて良かったです。
ということで参加したセッションについて軽く感想でも。
参加したセッション
- 次世代RDB劔"Tsurugi"にアクセスするJavaライブラリー・ツール
- JJUGキーノート: Java First. Java Always.
- Adopting ZGC in HBase for LINE Messaging
- Spring Boot vs MicroProfile - クラウドネイティブにおけるフレームワークの比較と選択
- 新卒エンジニアが 0から Non-Blocking な gRPCサーバーを作った話
- バッチを作らなきゃとなったときに考えること
次世代RDB劔"Tsurugi"にアクセスするJavaライブラリー・ツール
https://www.nautilus-technologies.com/JJUG20240616-tsurugi.pptx
- ひしだま 氏によるTsurugiの紹介とTsurugiに使われているJava製ライブラリについて紹介するセッションでした
- スポンサーセッションということで会社の人として発表してましたが、まあ皆さん誰か分かってましたよね🙂
- Tsurugiはトランザクションの扱いが他のRDBMSと異なる (トランザクション分離レベルがSerializableのみである) ので、まずそこからの解説と、提供しているJava APIやJava製ツールの紹介でした
身内の応援的な感じで参加してましたが、内容をかなり詰め込んだのでちょっと急ぎ気味になったものの、聴衆の食い付きは良かったかなとの印象を持ちました。 このセッションを聞いて関心を持たれた方は是非 GitHubのtsurugidbプロジェクト をチェックしてみてください。
JJUGキーノート: Java First. Java Always.
- OracleのGeorges Saabさんによるキーノートセッション
- Java Platform GroupのSenior Vice President
- 本当に初期の時代からJavaに関わっていらっしゃった方による、OpenJDK時代になってからのJavaの変化について語る内容でした
- 開発者は新機能をどんどん実装することを望むが、エンタープライズ系の現場では安定を望まれるというJavaが抱えるジレンマと向き合った結果、今の定期リリース＋LTSの開発スタイルになっていったこと、それによって様々ないい影響が起きたことについて述べていました
非常に印象的だったのがOpenJDKチームは今のソフトウェア開発のトレンドをとても意識しており、最近のJavaはAIが注目され、Pythonが人気になっているという趨勢を踏まえた変化を目指しているという点でした (Panamaでより用意にネイティブAPIへアクセスできるようになる、Pythonのように気軽に書けるように public static void main を省略できるようにする、VS Codeプラグインの提供など) 。
Adopting ZGC in HBase for LINE Messaging
- LINE の吉田さん (shinyafox さん) による、ZGCの解説及びLINEで利用しているHBaseサーバーへのZGC適用事例の紹介でした
- 前半ではこれまでJavaに採用されてきたGCアルゴリズムの紹介と、TBクラスのヒープすら扱うようになってきた時代に合わせて登場したZGCについての解説でした
- LINEではHadoopをベースとしたNoSQLデータベースであるHBaseを使っていますが、後半ではこのHBaseにZGCを適用した際に遭遇した様々な事象とその対応について解説するという非常に参考になる内容でした
- HBaseはベースとしているHDFSの性質上非常に巨大なヒープサイズで運用するため、STW時間への対応が重要 (STWが長すぎてサーバーが固まっていると誤検知される「ジュリエット問題」として有名) になってきます
個人的に驚いたのがLINEではJava17やJava21でHBaseを動かしているという点で (Hadoopは公式ではJava11までしか対応していないとうたっている) 、後でTwitterでやり取りしたところ、独自に頑張って動かしているとのことでした。
Spring Boot vs MicroProfile - クラウドネイティブにおけるフレームワークの比較と選択
- 豆蔵の荻原 利雄さんによる、MicroProfile (以下MP) についてSpring Bootと比較しながら紹介するセッションでした
- MPとSpringでCRUDアプリケーションを作り、それぞれのコードを比較しての解説を行っていました
- ちなみにQuarkusと言えばネイティブコンパイルが有名ですが、これはまだまだ実用レベルには達していないとのことでした
MPは存在は知っていたものの、なかなか自分で触る機会がなかったので、このように実際に使ってシステムを作った人の体験に基づく話を聞くことができて良かったです。
新卒エンジニアが 0から Non-Blocking な gRPCサーバーを作った話
- 出前館のKoki SatoさんによるJavaでgRPCサーバーを構築する際に使った技術について紹介するセッションでした
- 出前館ではシステムのマイクロサービス化を進めて一度パブリッククラウド上に構築した後に、さらに今度はプライベートクラウド上にリプレースする作業を進めており、その際にREST APIによる通信からgRPCに変更することにしたとのことです
- まずはgRPCそのものの解説で、Protol Buffersをベースにした通信であること、IDLを用いてスキーマを共有し、ノンブロッキングな通信であるなどの特徴を紹介していました
- 続いて、JavaでgRPCアプリを構築するために選定した技術の話となりました
- LINEは Armeria というNettyベースのフレームワークを開発しており、こちらを使って構築、以降はこのフレームワークの解説となりました
個人的に最近はNIOを使って低レイヤの通信を扱うサーバーを作ったりしていたので、ノンブロッキングのキーワードにつられて入りました。 ArmeriaはgRPCに限らずマイクロサービスを構築する上で必要となる様々な機能を提供した大きなフレームワークで、すごいのを作ったなあと驚きました。
バッチを作らなきゃとなったときに考えること
- irof さんによる、特に日本におけるシステム開発にはどうしてもつきまとうバッチ処理についてゆるゆると語るセッションでした
- 辞書を引くとリアルタイム処理の対義語として一括処理と説明される、バッチ処理とはそもそも何者なのか？から始まりました
- 自分の方で補足すると、辞書に載っているこの説明は昔のコンピューターの利用形態から来ているものですね
- 昔はコンピューターを利用するためには事前にスケジュールを予約し、実行してもらいたいプログラムのパンチカードなどをオペレーターに渡して一括処理してもらうことが一般的で、これをバッチ処理と呼んでいました
- 一括処理であるのは間違いない、スケジューリングはよく出てくるけど必須ではない、人の入力が必要がだったらバッチではないけど逆は違うかな、などバッチに対する捉え方は結構人それぞれでは、と
- 自分の方で補足すると、辞書に載っているこの説明は昔のコンピューターの利用形態から来ているものですね
- バッチが好まれる背景としては専用の実行環境が用意されることや、そして即時処理が難しいものが押し込まれがち、というのは結構耳の痛い話でした😅
- バッチを最小限にするにはどうするか？という話になり、処理内容を解体して一括処理が必要なところとそうでないところを整理することが重要であることを強調してました
- バッチの範囲を最小限にする必要がある理由としては次の点を挙げていました
- データ量は増大する一方
- 実行する機会が少ないので (中には年次バッチとか四半期バッチとかもある) 知見が貯まりにくい
- クライドネイティブと相性が悪い
日本は締め処理などの習慣もあって、どうしてもバッチ処理と付き合うことが多くなります。 上にも書いたように割と結論を明確に述べるのではなく、みんなで色々考えてみようよというスタンスのゆるゆるとした語りのセッションで、余り意識することなく付き合っているバッチ処理に対して一歩立ち止まって見直してみるきっかけとなるいい (そして楽しい) 内容だったと思いました。
