複雑な本番環境において Java メモリ問題を特定することは、隠れたメモリリークであれ、高頻度なオブジェクト生成による GC 負荷であれ、常にパフォーマンス エンジニアリングにおける大きな課題です。従来のヒープダンプ (Heap Dump) 分析方法は、“Stop-the-World” (STW) を引き起こしサービスを長時間停止させてしまう可能性があるだけでなく、その"オフライン事後分析"の形式も分析プロセスを極めて時間のかかるものにし、かつ瞬間的な問題を捉えることが困難です。

本記事では、非侵入型の「オンライン分析」実践をご紹介します。ある注文システムの事例を通じて、OpenResty XRay を利用し、サービスを停止することなく、セーフポイントに依存せずに、実行中の JVM のメモリ問題を体系的に診断する方法をご紹介します。以下に、3 つのステップで段階的に問題をピンポイントで特定する方法をご覧いただけます：

• リークの特定：GC オブジェクト参照分析を使用し、予期せぬメモリ常駐の根本原因を迅速に特定します。
• GC 負荷の変動調査：GC オブジェクト割り当て回数分析を通じて、高頻度でオブジェクトを生成するコードパスを発見します。
• メモリ使用量の最適化：GC オブジェクト割り当てサイズ分析を利用し、「大オブジェクト」の生成元を特定します。

1. 背景と課題

あるお客様の注文システムにおける性能リグレッションテスト中に、当社のエンジニアチームは典型的なメモリ異常現象を確認しました。具体的には、アプリケーションのヒープメモリ使用量が継続的に上昇し、複数回の Full GC 後もヒープ領域の占有率が顕著に低下しないという状況です。

これまでの経験から、この現象は通常、以下の 2 つの潜在的な問題を示唆しています。

1. メモリリーク (Memory Leak) の発生。これは、一部のオブジェクトが参照を失った後も本来回収されるべきであるにもかかわらず、予期せぬ GC ルートからの参照パスが存在するため、メモリ上に常駐し続けてしまう状態を指します。
2. 特定の業務処理パスにおける高頻度なオブジェクト生成「チャーン」 (Memory Churn) の発生。これは、大量の一時的なオブジェクトが頻繁に生成・破棄されることで Young GC への負荷が過度に増大し、結果としてFull GCが頻繁にトリガーされる状況を指します。

従来のヒープダンプ (Heap Dump) 分析手法、例えば jmap を用いて HPROF ファイルをエクスポートし、MAT などのツールでオフライン分析を行う方法は、強力な機能を持つ一方で、本番環境では課題に直面します。数 GB にも及ぶヒープスナップショットのエクスポート自体が、長時間の STW (Stop-the-World) を引き起こし、稼働中のサービスにとっては許容できない影響を与えます。

サービスを中断せず、かつ顕著な性能オーバーヘッドを発生させないという前提で「オンライン」診断を実施するため、エンジニアチームは実行中の JVM を分析する目的で OpenResty XRay を起動しました。

2. 体系的な診断アプローチ：メモリリークからパフォーマンスの不安定性まで

「全体像から詳細へ」という診断戦略を採用し、まずメモリリークの有無を確認し、次にアロケーションの頻度とサイズに関する問題を調査しました。

2.1 メモリリークの診断：GC Root の特定

最初の重要なタスクは、メモリリークが存在するかどうかを確認し、その発生源を特定することです。OpenResty XRay の GC オブジェクト参照関係アナライザーを使用しました。

分析を実行すると、フレームグラフレポートはメモリ内のオブジェクトを以下の 2 つのカテゴリに明確に分類しました。

• Dead GC objects ： 不要となり、ガベージコレクションによる回収を待っているオブジェクト（調査対象外）。
• GC root によって 参照されているオブジェクト：生存しており、重点的に調査すべきオブジェクト。

エンジニアチームは後者のオブジェクトに焦点を当てて調査を進めました。GC root 参照チェーンを階層的に辿っていくと、分析ツールはメモリ使用量が集中している箇所として、OrderProcessingService$OrderService インスタンスを明確に指し示しました。

さらに深く掘り下げた結果、メモリが主にこのインスタンスの 2 つのフィールドによって保持されていることが判明しました。

• notificationQueue (並行キュー)
• paymentRecords (支払い記録配列)

参照パスの分析を通じて、これらのコレクション内のオブジェクトはビジネスプロセス終了後に削除されるべきでしたが、ロジックの欠陥により、想定よりも長く存続してしまっていることが確認され、メモリリークの発生箇所が特定されました。

2.2 割り当て頻度の分析：メモリ「スラッシング」の検出

メモリリーク箇所を特定した後、次に問題となるのは、不必要なメモリの頻繁な確保・解放（メモリ「スラッシング」）が発生していないかという点です。高頻度なメモリ割り当ては GC （ガベージコレクション）負荷を増大させ、メモリ リークがない場合でもシステムの スループットを低下させる原因となります。

OpenResty XRay の GC オブジェクト割り当て回数アナライザー を使用することで、コード パス別に分類されたオブジェクト作成頻度フレーム グラフを取得しました。

レポートによると、createOrder メソッド (@OrderProcessingService.java:118) におけるオブジェクト作成回数（フレーム グラフの幅）が、他のビジネス パスと比較して著しく高いことが示されています。

高頻度なオブジェクト作成、特に Old 世代への昇格は、Young GC の頻繁な発生を招き、Old 世代のメモリ領域の枯渇を加速させる可能性があります。これは STW （Stop-The-World）時間の増加を引き起こし、結果として P99 応答遅延の悪化につながります。

2.3 アロケーションサイズ分析：「大オブジェクト」の特定

最後に、「大オブジェクト」の問題、つまり一部の処理パスでサイズの大きなオブジェクトが頻繁に生成されていないかを確認しました。

そこで、GC オブジェクトアロケーションサイズアナライザー に切り替えました。GC オブジェクトアロケーションフレームグラフ は、サンプリング期間中に生成された GC オブジェクトの総サイズに基づいて統計を表示します。生成されたオブジェクトの総サイズが大きいほど、グラフ上での割合が高くなります。

分析レポートによると、generateOrderId メソッド (@OrderProcessingService.java:155) およびその呼び出しチェーンは、実行回数は多くないものの、メモリ使用量の面で非常に目立っていました。主な原因は、サイズの大きな文字列オブジェクトが頻繁に生成されていたためです。

評価の結果、この ID 生成ロジック は重複するケースが多く、キャッシュの導入が適切であると判断しました。文字列生成ロジックにキャッシュ 機構を導入する改修を行うことで、このパスにおけるヒープ使用量のピークを大幅に削減することができました。

3. 診断効率とシステム改善

OpenResty XRay の 3 つのアナライザーを活用することで、当社の技術チームは短時間で現象から根本原因までの特定を完遂しました。

• 診断効率の向上：従来、ヒープダンプツールに頼っていたため、繰り返し比較したり、参照チェーンを手動で追跡したりする必要がありました。しかし、XRay のフレームグラフ（Flame Graph）を使用することで、わずか数分で問題が集中している領域を直感的に把握できるようになり、トラブルシューティング のプロセスを大幅に短縮できました。
• システム性能の改善：問題を修正した結果、GC 時間の占有率が明らかに低下し、アプリケーションは同じ負荷下でより安定した応答を示すようになりました。これにより、全体の遅延曲線も安定傾向にあります。

さらに重要な点として、今回の実践は方法論に変化をもたらしました。OpenResty XRay の可視化分析により、チームメンバーはメモリ内のオブジェクトのライフサイクルと参照関係を直接理解できるようになりました。チューニングに関する議論は「経験による推測」から「証拠に基づく意思決定」へと転換し、性能最適化の確実性を高めています。

4. Java アプリケーションのメモリ分析に OpenResty XRay を選ぶ理由

従来の Java メモリ分析は、ヒープダンプに大きく依存しています。この「オフラインでの事後分析」型のアプローチには、固有の限界があります。

OpenResty XRay は、異なるアプローチを提供します。それは**非侵入型の「オンライン分析」**です。OpenResty XRay は、その設計により従来のツールの課題を回避しています。

1. 本番環境での安全性 OpenResty XRay は、Java プロセスの再起動、コードの変更、または JDK の置換を必要としません。安全なアタッチメカニズムにより、実行中の JVM に直接接続し、業務に透過的に機能します。

2. 極めて低いオーバーヘッドと非侵襲性 これは OpenResty XRay の中核となる技術的優位性です。JVM のセーフポイント (Safepoint) メカニズムに依存しないサンプリング方式を採用しているため、STW (Stop-the-World) を一切発生させることなく、JVM のメモリ、CPU、I/O などを分析できます。これにより、リアルタイムの本番トラフィック下で詳細な診断を実行できる、数少ないツールの一つとなっています。

3. 直感的な可視化分析 提供される GC オブジェクト参照フレームグラフやメモリ参照パスグラフは、「誰が誰を参照しているか」「メモリがどこで使われているか」を直感的に可視化し、メモリ問題の分析ハードルを大幅に低減します。

4. 多角的なパフォーマンスプロファイル

OpenResty XRay の機能はメモリ分析に限定されません。今回のケースでは GC に焦点を当てましたが、必要に応じて CPU フレームグラフや I/O 分析などに切り替えることで、システム全体のパフォーマンスプロファイルを多角的に構築できます。

この設計により、OpenResty XRay は本番環境で Java メモリ問題をリアルタイムに分析できる、真に数少ないツールの一つです。上記の注文システム事例では、チームが「リアルタイム診断 + 迅速な検証」というクローズドループを実現し、システム停止を伴う分析のリスクを回避するのに貢献しました。

5. まとめと考察

今回の注文システムにおけるメモリ問題の調査では、OpenResty XRay が体系的な診断プロセスを構築する上で大いに役立ちました。具体的には、「メモリリークの有無」から「発生頻度」、そして「オブジェクトサイズ」へ。さらに、「参照関係」から「割り当て回数」、そして「割り当てサイズ」へと段階的に掘り下げることで、調査範囲を効率的に絞り込むことができました。

このリアルタイムサンプリングと可視化に基づく分析アプローチは、従来のヒープダンプとオフライン分析による手法を効果的に代替します。これにより診断効率が向上するだけでなく、さらに重要な点として、高並行かつ高可用なJavaサービスの本番環境におけるパフォーマンスチューニングに対し、より安全で効率的な問題解決のアプローチを提供します。

OpenResty XRay について

OpenResty XRay は動的トレーシング製品であり、実行中のアプリケーションを自動的に分析して、パフォーマンスの問題、動作の問題、セキュリティの脆弱性を解決し、実行可能な提案を提供いたします。基盤となる実装において、OpenResty XRay は弊社の Y 言語によって駆動され、Stap+、eBPF+、GDB、ODB など、様々な環境下で複数の異なるランタイムをサポートしております。

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty^® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty^® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty XRay（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

英語版の原文と日本語訳版（本文）をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます！