Session title

遅い場所から、遅い理由へ：JFR、OpenTelemetry、eBPFでたどるJVM障害の真相

Description

ログ、メトリクス、分散トレースを導入しているのに、性能問題の根本原因までたどり着けない。そんな経験はないでしょうか。

分散トレースによって、どのリクエストが遅く、どのサービスで遅延が発生したかは把握できます。しかし分かるのは主に「何が」「どこで」起きたかまでです。GC、メモリアロケーション、ロック競合といったJVM内部の問題なのか、それともTCP再送、CPUスケジューリング、ディスクI/OなどOSレベルの問題なのかという「なぜ」までは見えません。

本セッションでは、性能障害の調査を以下の3層で進める実践的なアプローチを紹介します。

1. OpenTelemetryで問題のリクエストとSpanを特定する
2. JDK Flight Recorder (JFR) でCPU、アロケーション、GC、ロック競合を分析する
3. eBPFでネットワーク、スケジューラー、ディスクI/OなどJVM外部の挙動を確認する

また、OpenTelemetry Profilingの将来像だけでなく、JFRのセーフポイントバイアス、トレースとプロファイルの相関方法、eBPFの権限やコンテナ環境での制約など、実運用で考慮すべき限界についても解説します。

対象は、Java/JVMアプリケーションの開発・運用に携わるバックエンドエンジニア、SRE、プラットフォームエンジニア、パフォーマンスエンジニアです。特に、ログ・メトリクス・トレースを活用していても原因特定に苦労している方を想定しています。Javaや分散トレースの基礎知識を前提としますが、JFRやeBPFの経験は必要ありません。

本セッションでは、JFRによる観測、RecordingStream API、OpenTelemetryとの関連付け、eBPFを活用した調査手法を扱います。一方で、APM製品比較、eBPFプログラムの実装、JVMチューニングの網羅的解説、可視化基盤構築、ヒープダンプ解析の詳細は扱いません。

セッション終了後には、「トレースだけでは分からない性能問題をどう切り分けるか」「JFRとeBPFをどのような順序で活用するか」「OpenTelemetry Profilingを現時点でどこまで実運用に取り入れるべきか」を判断できるようになることを目指します。

Additional information

Javaアプリケーションの本番障害という共通課題に対し、JVM内部からOSカーネルまでを横断する実践的な調査手法を提示することを目的としています。トレースで「遅い場所」を特定できても、GC、アロケーション、ロック競合、CPUスケジューリング、TCP再送、ディスクI/Oのどれが原因かは分かりません。本セッションではJFR、OpenTelemetry、eBPFを個別に紹介するのではなく、「OpenTelemetryで対象リクエストを絞り、JFRでJVM内部を調べ、eBPFでOS側を確認する」という再利用可能な調査フローとして、ライブデモを交えて解説します。特定の商用APM製品に依存しないため、幅広いJava開発・運用環境へ応用できると考えます。

これまで継続して検証してきたJava、OpenTelemetry、Native Image、CRaC、性能分析の知見を基に、成功例だけでなく、JFRの観測上の偏り、eBPFの権限、コンテナ環境、発展途上のProfiling仕様などの制約も扱います。聴衆は、次の本番障害で調査をどこから始め、どの時点でJFRからeBPFへ進むべきかを判断できる、ベンダーニュートラルな方法論を持ち帰っていただけると確信しています。

Agenda（45分、変更の可能性あり）

1. トレースに残された「なぜ」の空白（4分）
   ログ、メトリクス、分散トレースで分かることと、分からないことを整理
2. JFRによるJVM内部の観測（8分）
   CPU、アロケーション、GC、ロック競合の分析と、RecordingStreamによるリアルタイム取得を紹介
3. OpenTelemetry Profilingの現在地（5分）
   第4のシグナルとしての位置付け、Spanとの相関、仕様の成熟度と現時点の制約を解説
4. JFRとトレースの相関分析（6分）
   遅延したSpanと同時間帯のJFRイベントを結び付け、JVM内部の原因を絞り込む方法を提示
5. eBPFでJVMの外側を調査（6分）
   TCP再送、Off-CPU時間、CPUスケジューリング、ディスクI/Oを確認する判断基準を説明
6. 3層を横断するライブデモ（10分）
   OpenTelemetryでリクエストを特定し、JFRでJVM内部を調査した後、eBPFでOS側へ掘り下げ
7. Native Image・CRaCの注意点と導入判断（4分）
   各環境における制約と、本番導入できる要素、検証から始める要素を整理
8. まとめ（2分）
   「OpenTelemetry → JFR → eBPF」の調査フローと、次の障害対応で使える判断基準を再確認

Session title

JDKは準備できた。あなたのアプリは？ ─ PQC移行の現実

Description

量子コンピュータは、もはや遠い未来の話ではありません。現在広く利用されているRSAやECCは、将来的に量子計算によって安全性が損なわれる可能性があり、Post-Quantum Cryptography（PQC）への移行は避けられない課題となっています。しかし、多くの開発者にとって「何から始めればよいのか」「既存システムへどう適用すべきか」はまだ明確ではありません。

本セッションでは、PQCの基礎を短く整理した上で、実際の移行プロジェクトで得られた知見をもとに、既存アプリケーションをPQCへ移行する際の実践的な考え方と進め方を解説します。

具体的には、暗号アルゴリズムの置き換えだけでは解決できない互換性や性能への影響、TLSや証明書基盤との関係、ハイブリッド方式の活用、ライブラリ選定など、現実の移行で直面する課題とその対処方法を取り上げます。また、新規システム開発において将来のPQC対応を見据えた設計上のポイントについても紹介します。

対象は、Javaアプリケーションの設計・開発・運用に携わるソフトウェアエンジニア、アーキテクト、SRE、セキュリティ担当者です。暗号技術の専門知識は前提としませんが、TLSや公開鍵暗号の基本的な理解があるとより理解しやすくなります。

本セッションでは、PQCの基礎、移行時の課題、実プロジェクトで得られたベストプラクティス、既存システムと新規開発それぞれの対応方針を扱います。一方で、量子アルゴリズムの数学的詳細や暗号理論の証明、特定製品の比較評価、PQCアルゴリズムの実装方法そのものについては扱いません。

セッション終了後には、「なぜ今から準備が必要なのか」を説明できるだけでなく、自身のシステムにおけるPQC影響範囲を整理し、移行時の主要なリスクや落とし穴を理解した上で、現実的な移行ロードマップを描けるようになることを目指します。

Additional information

このセッションを提案する理由は、PQCを暗号理論やTLSの新機能ではなく、Javaアプリケーション全体に関わる移行課題として扱うためです。Java 24はML-KEMとML-DSAを標準APIで提供しますが、プリミティブが利用可能になっただけでは移行は完了しません。暗号化データ、JWTやJARなどの署名、証明書・PKI、KeyStore・HSM・KMS、外部連携プロトコルも、それぞれ異なる標準、互換性、鍵ライフサイクルを持つため、Java全体を一括で「対応済み」と判断すべきではない点を理解してもらい、今後の移行における基礎情報として利用してもらいたいと考えています。

登壇者は、JavaにおけるPQCの利用方法に加え、暗号資産の棚卸、互換性検証、実行時証跡、段階的展開を継続して検証しています。参加者は、

①自分のコードと構成からRSA、ECC、署名、鍵管理の利用箇所を洗い出す
②各箇所を機密性と真正性のリスクで分類する
③Java標準APIで対応できる範囲と周辺製品への依存を区別する
④最初の検証対象と成功条件、ロールバック条件を決める
⑤既存・新規システムの移行バックログを作る

という一連の手順を持ち帰ることができます。

Agenda (45分、変更の可能性あり）

• 量子脅威とJavaへの影響（5分）
  • 機密性と真正性のリスク、早期準備が必要な理由
• JavaのPQC対応とコード例（8分）
  • ML-KEM、ML-DSA、JCA APIでできること・できないこと
• 暗号資産を見つける（7分）
  • コード、依存関係、設定、実行環境を横断した棚卸し
• Javaアプリの5つの移行領域（12分）
  • TLS、JWT・CMS・JAR署名と暗号化データ、PKI、鍵管理、B2B連携
• 移行時の落とし穴と検証（7分）
  • 性能、データ形式、鍵・署名サイズ、相互運用性、フォールバック
• 段階的ロードマップ（4分）
  • 優先順位、ハイブリッド方式、Crypto-Agility、ロールバック
• まとめ（2分）