あるフィンテックのお客様の 500,000 QPS OpenResty ゲートウェイで周期的に発生していたレイテンシースパイクを調査した結果、3 つの根本原因にたどり着きました。特定の入力でバックトラックに陥り 1 回の実行に最大 244.64 ms を要していた文字列処理関数、リクエストごとに再コンパイルされる正規表現により CPU 時間の 26.5% を消費していた log フェーズ、そしてビルドパラメータ --with-pcre-jit の欠落により無効のままだった PCRE JIT です。3 つすべてを修正した結果、300 ms のスパイクは解消され、クラスターの CPU 使用率は約 30% 低下しました。

このゲートウェイは中核となるクロスボーダー決済清算システムの入り口であり、毎日数百億件のリクエストを処理しています。お客様の監視ダッシュボード上ではすべてが健全に見え、P50 レイテンシーは 10 ms 以内で安定していました。しかしスパイクは主要なトランザクションパスの厳格な SLA を超過しており、ゲートウェイでのトランザクションタイムアウトにつながりかねないリスクを抱えていました。本記事では、OpenResty XRay がコードに一切手を加えることなく、各根本原因を特定していった過程を紹介します。

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

良好な平均値の裏に潜むレイテンシースパイクと CPU の浪費

お客様への定期的なパフォーマンスヘルスチェックにおいて、OpenResty XRay を利用し、その本番環境で非侵入型の詳細スキャンを実施しました。お客様の既存の監視ダッシュボードではシステム全体が安定稼働していると表示されていたにもかかわらず、OpenResty XRay の分析は、見かけ上の良好な平均値の裏に潜む 2 つの深刻な性能リスクをすぐに明らかにしました。

  • 原因不明のレイテンシースパイク： 大半のリクエストが正常に処理されている中でも、ごく一部のリクエスト（最も遅い 1%）において、短時間ながらも 300 ms 以上の深刻なレイテンシーが依然として発生していました。これらの信号は、お客様の既存の大量の監視データの中では統計ノイズとして見過ごされがちですが、OpenResty XRay はその最長の所要時間を正確に捉え分析し、高リスクイベントとして特定することができます。（同じ症状がまったく異なる根本原因に起因する場合もあります。D 言語サービスの P99 レイテンシーの原因が保守的 GC にあったことを特定した事例もご覧ください。）
  • 慢性的な CPU ボトルネック： 監視データは、ゲートウェイクラスターの CPU 利用率、特に log フェーズにおいて、高止まりしていることを示していました。ピーク時の安定性を確保するため、お客様のチームはオーバープロビジョニングを採用せざるを得ず、これが高額なインフラコストに直結していました。

これは、誰もが一度は直面する典型的な課題です。問題がおおよそどこにあるのか、おそらく Lua コード層にあるだろうと推測はできるものの、具体的にどの行、どの関数、そしてどのような条件下でトリガーされるのかは不明でした。

コード変更・再起動なしで行う OpenResty レイテンシーのトラブルシューティング

明らかに、課題はもはや単に多くの監視データを収集することではなく、大量のデータから実行可能な洞察をいかに得るかです。「観察-推測-検証」という非効率なサイクルから脱却するためには、本番環境で安全に深層調査を行えるツールが不可欠です。これこそが OpenResty XRay の核心的価値が発揮される点であり、その非侵入型の動的トレーシングが鍵となります。コード変更もサービス再起動も不要である点は、金融コアシステムにおいて譲れない要件です。

お客様の高負荷な本番 Pod 上で OpenResty XRay の自動分析を開始しました。数分後、最初の詳細分析レポートが生成され、謎が解き明かされ始めました。

根本原因 1：1 回の実行に 244 ms を要したパターンマッチングのバックトラック

お客様の高性能ゲートウェイクラスターの綿密な分析において、まず解決に着手したのは、深刻なレイテンシースパイクの問題でした。

  • データ分析の結果： 本番環境におけるリアルタイムサンプリング分析を通じて、高レイテンシー現象が特定の文字列処理関数に起因することを突き止めました。データによると、特定のパターン入力の処理において、その関数の 1 回の実行に最大で 244.64 ms の時間がかかっており、これは観測されたレイテンシースパイクの原因を十分に説明するものでした。
  • 原因究明： さらなる分析により、その関数が依存する基盤エンジンは、JIT（Just-in-Time コンパイル）による最適化が設計段階で考慮されていなかったことが判明しました。特定の境界条件の入力が与えられると、そのパターンマッチングアルゴリズムは非効率的なバックトラックモードに陥り、実行時間の指数関数的な増加を引き起こしていました。

この発見に基づき、ホットパス内の当該関数を、フレームワーク内でより現代的で、同時接続数の多いシナリオ向けに設計された JIT フレンドリーな代替実装に置き換えることを提案しました。実施後、システムのレイテンシースパイクは効果的に解消され、サービス可用性指標は安定を取り戻しました。

根本原因 2：リクエストごとに再コンパイルされる正規表現が招いた log フェーズの CPU 高騰

レイテンシー問題の解決後も、システムの全体的な CPU 使用率が想定されるベースラインを上回っていることが判明し、さらなる最適化の余地があることが示唆されました。

  • XRay 分析結果： On-CPU フレームグラフによる分析から明確な方向性が見えました。通常は低オーバーヘッドと見なされるログ記録（log）フェーズが、予期せず CPU 時間の 26.5% を占め、過度な CPU リソース消費の原因となっていることが判明しました。
  • 詳細分析： この関数スタックに対するドリルダウン分析により、問題の核心が明らかになりました。ログ処理ロジックにおいて、フォーマットおよびマスキングのための正規表現が、リクエスト処理のたびに再コンパイルされていたのです。ループ内で繰り返される高コストなコンパイル処理が、過剰な CPU オーバーヘッドの直接的な原因となっていました。

関連する正規表現の呼び出しにおいて、「コンパイルキャッシュ」オプションを有効にし、一度コンパイルした正規表現を複数回利用するよう推奨しました。この調整により、お客様のログモジュールの CPU 使用率が大幅に削減され、解放された計算リソースによって、サーバーがコアビジネスロジックを処理する能力が向上しました。

根本原因 3：ビルドパラメータの欠落により無効のままだった PCRE JIT

これまでの 2 つの最適化はアプリケーションレベルの具体的な問題を解決しましたが、OpenResty XRay の「Lua-Land」レポートは、より深く、より体系的な問題が潜んでいることを明らかにしました。

  • システム全体にわたる発見： 分析レポートにより、キャッシュ最適化を適用した後でも、システムの中核を成す PCRE（Perl Compatible Regular Expressions）エンジンの JIT 加速機能が、本番環境全体で有効化されていなかったことが判明しました。
  • 根本原因の特定： この問題はコードロジックに起因するものではなく、より上流のビルド段階に原因がありました。お客様がデプロイに用いるベースコンテナイメージにおいて、コアアプリケーションゲートウェイのコンパイル時に、PCRE JIT サポートを有効にするための重要なコンパイルパラメータ（--with-pcre-jit）が見落とされていたことを確認しました。
  • 戦略的改善策： これは、クラスター全体でこの重要なパフォーマンス強化機能が全く活用できていなかったことを意味します。お客様のチームに対し、CI/CD プロセスを修正し、ベースイメージを再構築する提案を行いました。この措置により、コアとなる性能機能が根本から有効化され、OpenResty の潜在能力を最大限に引き出すことができました。すべての関連サービスのパフォーマンスベースラインが体系的に向上し、アプリケーションコード、ランタイム環境からインフラストラクチャ構築に至るまで、全レイヤーにわたる OpenResty XRay の分析能力が実証されました。

最適化の結果：レイテンシースパイクの解消と CPU 使用率 30% 削減

OpenResty XRay から得られた洞察に基づき、お客様のチームは一連の最適化を実施しました。その効果はすぐに現れ、数値として明確に確認できました。

  1. レイテンシースパイクが完全に解消： 最適化後、レイテンシー曲線は非常に滑らかになり、300 ms を超えていたものが安定したレベルにまで低下しました。
  2. CPU コストを 30% 削減： 正規表現キャッシュの問題を修正し、JIT をグローバルに有効にした結果、ゲートウェイクラスター全体の CPU 使用率が約 30% 低下し、大幅なクラウドインフラコストの削減につながりました。
  3. MTTR（平均解決時間）の大幅短縮： パフォーマンス問題の診断に要する時間は、従来の「数週間にわたる推測と会議」から「数分での正確な特定」へと大幅に短縮されました。

CI/CD でパフォーマンスリグレッションを事前に検出

これら 2 つのパフォーマンスボトルネックを解消することの直接的な価値は明らかです。しかし、より深い洞察として、高負荷・低レイテンシーの OpenResty 環境において、パフォーマンス問題がしばしばビルドシステム、ランタイム設定、そして基盤インフラの細部に潜んでいるというエンジニアリング上の原則が改めて裏付けられました。

問題の根源がアプリケーションコードのロジックだけでは捉えきれない場合、従来の観測手法は効率面で限界を迎えます。非侵入型の動的トレーシングがなければ、最も経験豊富なエンジニアでさえ、これらの潜在的なパフォーマンスリグレッションに直面した際の特定コストが著しく増加します。

この経験に基づき、お客様のエンジニアリングチームは、次の段階のエンジニアリングプロセス最適化を慎重に計画しています。同チームは OpenResty XRay による継続的なパフォーマンス分析をシフトレフト（開発ライフサイクルの早い段階へ前倒し）し、CI/CD プロセスのベンチマークテスト工程に統合する予定です。これにより、パフォーマンスリグレッションにつながりかねないコードや設定がメインブランチにマージされる前に、自動化されたベンチマークテストレポートを通じて、環境、設定、またはコンパイルに起因するパフォーマンス異常を確実に捕捉できるようになります。この取り組みは、「受動的な対応」から「能動的な防御」への思考転換を象徴しています。

今回の OpenResty 環境における 2 つの典型的なパフォーマンスの盲点に関する詳細な分析が、同様に最前線でシステムの安定性と効率向上に尽力されている皆様に、参考となる視点や示唆を提供できることを願っています。

よくある質問

平均レイテンシーが正常でも OpenResty でレイテンシースパイクが発生するのはなぜですか？

平均値がテール（最も遅い一部のリクエスト）を覆い隠すためです。このゲートウェイでは P50 レイテンシーが 10 ms 以内に収まる一方、ごく一部のリクエストで 300 ms を超えるスパイクが発生していました。特定のパターンの入力で文字列処理関数が非効率なバックトラックモードに陥り、1 回の実行に最大 244.64 ms を要していたのです。こうした稀なイベントは従来のダッシュボードでは統計ノイズとして見過ごされますが、OpenResty XRay は最長の所要時間を捉え、高リスクとして特定します。なお、本件の根本原因はいずれも on-CPU の計算処理でした——CPU は無駄な処理で忙しかったのです。症状がその逆——レイテンシーは高いのに CPU 使用率が低い——という場合、時間は計算ではなく待機に費やされています。off-CPU 分析ガイドをご覧ください。

OpenResty の log フェーズが CPU を大量に消費するのはなぜですか？

log フェーズは通常オーバーヘッドが小さいはずですが、このゲートウェイでは CPU 時間の 26.5% を消費していました。On-CPU フレームグラフにより、ログのフォーマットとマスキングに使われる正規表現がリクエストごとに再コンパイルされていたことが判明しました。該当する正規表現呼び出しでコンパイルキャッシュを有効にし、「一度コンパイルして何度も実行する」形にしたことで、ログモジュールの CPU 使用量は大幅に減少しました。

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 Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

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