高並列処理のビジネスシナリオでは、システムパフォーマンスがユーザー体験とビジネス成果に直接影響します。応答の遅延は、ミリ秒レベルであっても、ユーザーの定着率やビジネス指標に悪影響を及ぼす可能性があります。しかし、本番環境におけるパフォーマンスの問題、特に断続的なボトルネックは、その複雑さと再現の難しさから、特定と解決に課題が伴うことがよくあります。

本稿では、実際のケースを通じて、典型的な本番環境のパフォーマンス問題をどのように調査するかをご紹介します。あるお客様のオンラインシステムでは、ビジネスのピーク時に平均応答時間が倍増し、CPU 使用率が継続的に高い状態が発生していました。技術チームは、ログ分析、一般的なパフォーマンスプロファイリングツールの使用、テスト環境での再現など、従来の方法を採用しましたが、問題の根本原因を正確に特定することができませんでした。

この問題を解決するため、チームは深層観測プラットフォームである OpenResty XRay を採用しました。OpenResty XRay は複雑な本番環境におけるパフォーマンス問題の診断のために設計されており、動的トレース技術（eBPF+ や Stap+ など）に基づいて、コードの変更やサービスの再起動なしにオンラインサービスを深く分析することができ、システムパフォーマンスへの影響も最小限に抑えられます。

本稿では、OpenResty XRay を使用してこのパフォーマンス問題を診断する全過程を詳細に説明します。多次元のフレームグラフ分析を通じて、コードの奥深くに隠れたパフォーマンスのボトルネックを特定する方法を段階的に紹介します。

OpenResty XRay の試用をすぐに申請する

全体的 CPU 使用分析

OpenResty XRay は以下の C-land CPU フレームグラフを自動生成しました：

Screenshot

このフレームグラフを分析することにより、チームは迅速に問題の核心を発見しました：ModSecurity モジュールが絶対的な第一のパフォーマンスボトルネックとなっています。

  1. ModSecurity モジュールの CPU 使用率：57.9%
  2. 全体の CPU ボトルネック比率：約 60%

モジュール内部の詳細分析

OpenResty XRay の細粒度トラッキング機能をさらに活用することで、チームは主に 2 つの CPU 消費源を特定しました：

1. PCRE DFA 正規表現マッチングのボトルネック

以下の C-land CPU フレームグラフは、PCRE の DFA マッチング関数が CPU リソース消費において顕著な位置を占めていることを示しています。pcre_dfa_exec 関数はアプリケーション全体の CPU 時間の 24.4% を占めています。

Screenshot

この発見により、nginx 版 ModSecurity モジュールの呼び出しがこの高消費の主な原因であることが明確に示されました。注目すべき点として、PCRE ライブラリの DFA エンジンは JIT コンパイル付きのバックトラッキングエンジンと比較して性能が明らかに劣っており、これが最適化の方向性と機会を提供しています。

2. HTTP レスポンスボディの Gzip 圧縮ボトルネック

OpenResty XRay の多次元分析機能により、システムパフォーマンスの 2 番目の大きなボトルネックをさらに詳しく調査することができました。複数の C レベル CPU フレームグラフサンプルを収集することで、チームは HTTP レスポンスボディの圧縮がシステムパフォーマンスに与える影響を体系的に分析しました：

  • サンプル 1 の分析：初期サンプリングでは、zlib ライブラリの deflate 関数がアプリケーション全体の CPU 時間配分の 13.1% を占めていることが示されました。このデータは、Gzip 圧縮が無視できないパフォーマンス消費点であることを明確に示しています。

Screenshot

  • サンプル 2 による検証：発見の正確性を確保するため、2 回目のサンプリングを実施しました。結果はさらに顕著で、このサンプルでは deflate 関数の CPU 使用率が 34.7% に上昇し、圧縮操作がシステムパフォーマンスに大きな影響を与えていることがさらに確認されました。

Screenshot

圧縮戦略の詳細分析

Gzip 圧縮がシステムパフォーマンスの2番目のボトルネックであることを確認した後、OpenResty XRay の専門的な分析能力が十分に発揮され、圧縮戦略のさまざまな側面を深く探究するのに役立ちました：

圧縮レベルの分析

まず、OpenResty XRay の専用アナライザーを通じて圧縮レベルの包括的な検査を行いました。その結果は考えさせられるものでした：

found 561 response chunks not gzip'd
gzip levels: count=2000, min=1, avg=1, max=1
value |-------------------------------------------------- count
    0 |                                                      0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2000
    2 |                                                      0
    4 |                                                      0

このデータは二つの重要な事実を明らかにしています：

  1. システム内には 2000 の圧縮されたレスポンスチャンクがあり、すべてレベル 1（最低圧縮レベル）を採用しています
  2. 同時に 561 の非圧縮レスポンスチャンクが存在しています

これは、圧縮レベルの観点から見ると、システム構成はすでに合理的であることを示しています—レベル1は最高の実行効率を提供しています。しかし、圧縮操作は依然として多くの CPU リソースを消費しており、これによって私たちはさらに探究することになりました：どのタイプのコンテンツがこれらのリソースを消費しているのでしょうか？

MIME タイプ分布分析

上記の質問に回答するため、再度 XRay 分析機能を起動し、Gzip 圧縮に関わる MIME タイプについて精密な統計を取りました：

found 557 response chunks not gzip'd
* gzip application/javascript: count=606
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@     606
    2 |                                                     0
    4 |                                                     0
* gzip text/html: count=212
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@         212
    2 |                                                     0
    4 |                                                     0
* gzip text/css: count=182
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@      182
    2 |                                                     0
    4 |                                                     0

このデータセットからより詳細な状況が明らかになりました：

  1. JavaScript ファイル（606 インスタンス）が最も主要な圧縮対象となっています
  2. HTML ファイル（212 インスタンス）と CSS ファイル（182 インスタンス）がそれに続いています
  3. これら三種類のタイプがほぼすべての圧縮操作を占めています
  4. 同様に 557 個の応答チャンクが圧縮されていません

分析結論

この一連の段階的な分析を通じて、いくつかの重要な結論が導き出されました：

  1. システムは最も効率的な圧縮レベルである「レベル 1」を既に採用しています
  2. 圧縮操作は主に静的リソース（JS、CSS）と動的コンテンツ（HTML）に集中しています
  3. 圧縮レベルが最適化されているにもかかわらず、圧縮操作はシステムパフォーマンスの重要なボトルネックとなっています

これらの発見は最適化の方向性を示しています：単に圧縮レベルを調整するのではなく、全体的な圧縮戦略を再考する必要があります。特に、異なるタイプのリソースに対して差別化された処理方法を採用することが重要です。

最適化ソリューション

本ケースで発見された 2 つの主要なパフォーマンスボトルネックに対して、以下の最適化ソリューションをご提案いたします：

1. 圧縮パフォーマンスの最適化：zstd プライベートモジュール

Gzip 圧縮のボトルネックに対応するため、高性能な代替ソリューションとして zstd プライベートモジュールをご提供いたします。このモジュールは Facebook がオープンソースとして公開している Zstandard 圧縮アルゴリズムに基づいており、パフォーマンスは zlib の最大 5倍に達し、本ケースで発見された 34.7% の CPU 圧縮オーバーヘッドを大幅に削減することが可能です。当社のプライベートライブラリサービスとして、zstd モジュールは特に高並列処理シナリオ向けに最適化されており、お客様により効率的な圧縮ソリューションを提供いたします。

2. WAF パフォーマンスの最適化：OpenResty Edge

ModSecurity モジュールのパフォーマンスボトルネックに対して、当社の OpenResty Edge はより高性能な WAF ソリューションを提供いたします。

多くのシナリオにおいて、OpenResty Edge の WAF パフォーマンスは ModSecurity と比較して一桁上のパフォーマンスを発揮し、本ケースにおける ModSecurity が CPU の 60% を占めるという問題を効果的に解決します。これにより、お客様はシステムセキュリティを確保しながら、より優れたパフォーマンスを実現することが可能です。

これらの 2 つのソリューションは、お客様の実際のビジネスニーズに応じて参考・選択いただけるものであり、システムのセキュリティを確保しながら、より優れたパフォーマンス体験を得るお手伝いをいたします。

「消火」から「防火」へ：OpenResty XRay の核心的価値

本事例は現代的なパフォーマンス最適化の縮図です。問題の根源は単純なコードのバグではなく、システム内部の設定、ライブラリ関数、処理戦略間の複雑な相互作用に潜んでいました。従来のツールでは「煙」しか見えませんが、OpenResty XRay はその深い洞察力により「火元」を直接特定することができます。

この実例を通じて、OpenResty XRay の核心的価値が明確に示されています：

  • 精密な洞察、推測の排除：XRay は曖昧な「CPU 使用率の高さ」という問題を、明確で実行可能な最適化目標へと変換します。フレームグラフはシステムが遅くなっただけでなく、ModSecurity モジュールと pcre_dfa_exec 関数を直接特定し、パフォーマンス最適化を「推測」から的を絞った「実行」へと変えます。

  • データ駆動型の意思決定支援：Gzip のボトルネックに直面した際、最初の反応は通常「ダウングレード」です。しかし XRay は圧縮レベルと MIME タイプの詳細な分析により、現在の設定が既に「最適解」であることをデータで証明し、無駄な調整を避け、最適化の方向性を「動的・静的リソースの分離処理」というより高次元の戦略へと導きました。これこそが一般的なチューニングとアーキテクチャ最適化の分岐点です。

  • 非侵襲的で本番環境対応：すべての詳細分析は本番環境でリアルタイムに完了し、コード修正や再起動は不要です。これはあらゆる企業レベルのアプリケーションにとって、ビジネス継続性を保証する生命線であり、真の「無感知」診断を実現しています。

これらの能力の背後にあるのが、OpenResty XRay の基盤です。その中核は、eBPF+ や Stap+ といった当社が独自に改良した動的トレース技術に基づいています。これらの先進技術により、XRay はシステムオーバーヘッドを極めて低く保ちながら、従来のツールをはるかに超える深さと精度を提供できます。特筆すべきは、OpenResty XRay が RHEL/CentOS 7 の 3.10 旧カーネルと 6.x 新カーネルの両方をサポートしており、ユーザーの様々なシステム環境に幅広い互換性と保証を提供していることです。

今日のビジネス競争において、パフォーマンスは単なる技術指標ではなく、核心的なビジネス資産です。OpenResty XRay が技術チームに提供するのは、受動的な「消火」から能動的な「防火」への自信であり、システムの長期的な安定性を保証し、究極のユーザー体験を創造する強力なツールなのです。

OpenResty XRay の試用をすぐに申請する

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 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

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