構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

JJUG CCC 2023 Fall（11/11）前編

イベント・勉強会

春に続き、1 人で参加しました。

jjug.doorkeeper.jp

当初は懇親会まで参加…の予定でしたが、結果的に途中離脱しました（それについては後編の最後で）。

本編（午前）

Virtual Threads! Checkpoint Restore! Java の進化に対応する Spring Framework 6.1 / Spring Boot 3.2 の注目機能紹介（Maki さん）

docs.google.com

今回は会社へのフィードバックも意識しつつの参加だったので、

  • A-1 の 10:00 〜（Java 8 → 21 の実例の話）
  • A-2 の 10:25 〜（Jakarta EE 11 の話）

と迷いましたが、こちらを選択。

（ありがたや）

話の内容は、

  • Virtual Threads サポート
  • CRaC サポート

の 2 点に絞られていました（前者が中心）。

  • Spring ではパラメータ 1 つ（spring.threads.virtual.enabled=true）で Virtual Threads を有効にできること
    • コードをチマチマ書き換えないでも良いのは楽チン！
  • VIrtual Thread では R2DBC を使わなくても JDBC でasync/await的な処理に対応できること
  • 現状ではまだ（非 Spring でいうところの）CompletableFutureでallOf()などの後join()するような処理は Virtual Thread 対応では書けないのと流量制御はできないこと
    • 依然として Reactive API は必要
    • ただし前者については Structured Concurrency がプレビュー中
  • CRaC 対応ではセキュリティに配慮したチェックポイント（スナップショット）作成を検討中

というのがわかっただけでも収穫がありました。

Java（JVM 言語）で MySQL に接続しようとするとこういう問題があるんですよ…。

Java の AoT コンパイルは現状では非常に遅いので、CRaC が本当に実用的に使えるようになると良いですね。

レガシーなWebサービスから世界標準への挑戦（Hashimoto さん）

自社の状況に被る部分（レガシー）と今後の参考になりそうな点（OpenAPI Specification の利用）があったので選択。

  • 長く続いている（生きのこっている）プロダクトには色々な歴史的経緯があること
  • OpenAPI でリソースベース（RESTful）ではなく手続きベースの API も定義できる（しても良い）こと
    • 言われてみればそういう仕様だった
  • スキーマから自動生成したコードをどこまで利用するかについては、やはり判断が難しそうなこと

を理解（？）しました。

ここ数年 Java のコードをまともに書いてないんですよね（TypeScript >> Python > Go > Dart（Flutter） >>> Java みたいなイメージです）。

ノーコメント。

GMO ペイメントゲートウェイ社では「バリデーションは従来から独自に実装を実装を用意しているので自動生成しているものは使っていない」とのこと。

うーん（OIDC に準拠するより「OAuth 2.0 + 何か（ID 的な）」を選んじゃうんだろうな…）。

スポンサーブースでの LT

スペースの都合上「大人数」とはいきませんでしたが、そこそこの人数が昼食に直行せずに残って盛り上がっていました。

かっぽじって聞くとしたらどっちの耳だろう（そういう話じゃない）。

幅広い世代に浸透してますね（そういうわたしは「お試し」程度でやめちゃったんですけど）。

😺ﾆｬｰ

EPP（Java 8 で 17 相当のパフォーマンス出すやつ）が使える話、覚えてる人少なかったみたいでした。

ごめんなさい、わたしも知らなかったです。

本編（午後）

コンテナ環境でのJavaトラブルシューティング技法（数村さん）

speakerdeck.com

ミーティングルームの話も聞きたかったのですが体は 1 つなのでこちらを選択。

  • コンテナイメージを小さくすればするほどコンテナ単体でのトラブルシューティングは難しくなる
    • 言われてみればそのとおり
      • 当然だけど忘れがち
  • コンテナのトラブルシューティング手法はいくつかあるが、それぞれ良い点悪い点があるし環境による制約もある
    • 今回は Kubernetes が前提
      • ECS on Fargate など、別の環境についても調べてみると良さそう

なことがわかりました。

文脈から判断すると JVM の JIT に起因する部分はここでいうところの「起動時間」の外？

同意。

（そのままの勢いで、技術書典で本を購入しました）

サイドカーからメインのコンテナを突っつく話。Kubernetes の Pod じゃなくて ECS のタスクで同じようなことをするには…の呟きでした。

（貴族っぽい人たちは出てきません。まあ「エフェメラル」なので出てきてもすぐ消えていなくなりそうですが）

持続可能なデータアーキテクチャを実現したリアーキテクティング（Urano さん）

AWS とか DynamoDB とかデータ移行の話が出てくるようだったので選択。

ゆったりとしたペースで話していただけたので、話の流れがよくわかりました。

  • AWS では SA さんにちゃんと相談してアーキテクチャを設計すると良い感じなものに仕上がる

というのをあらためて認識しました。

「データ量多くなって」の話、DynamoDB ではスキャンではなくクエリで処理している、とのこと。

確かにパーティションキーで絞り込む分走査対象のレコードが減りますが、インデックスを作っていないとパーティション内での走査は減らないような…？

ただ、作り込みすぎると色々なものが密結合になって変更しづらくなるんですよね。

慌ててると忘れがちなやつ。

移行時と移行後でワークロード変わりますからね。

話を聞きながら、終始これが頭に頭に浮かんでいました。

後編はこちら↓

hmatsu47.hatenablog.com