最近、ある大手フィンテック顧客と協力し、その中核となるクロスボーダー決済清算システムの定期的な性能評価を実施しました。このシステムは、OpenResty を基盤として構築された高性能 API ゲートウェイをエントリポイントとし、毎日数百億回の呼び出しを処理し、ピーク QPS は 50万 を超えます。フィンテック分野において、システムの安定性と低遅延はビジネスの生命線です。顧客は主要なトランザクションパスの SLO ( Service Level Objective ) に対して、非常に厳しい要件を設けています。当初の評価では、システムは非常に安定して稼働しているように見えました。P50 遅延は 10 ms 以内に安定し、主要な各指標は健全な状態を示していました。

平均遅延指標は良好でしたが、P99 遅延カーブを詳細に分析すると、見過ごせない安定性のリスクが潜んでいることを発見しました。周期的に発生するスパイクにより、遅延が 300 ms レベルまで上昇し、これは主要なトランザクションパスに対する厳格な SLA 閾値を超過していました。OpenResty を基幹ゲートウェイとするシステムにとって、これは性能劣化の兆候であるばかりでなく、潜在的なトランザクションタイムアウトのリスクにもつながります。

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

「地震計」が震源を特定できない時

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

  • 説明不能な P99 遅延： P99 遅延曲線上に、短時間ながら 300 ms を超えるスパイクが存在することを発見しました。これらの信号は、お客様の既存の大量の監視データの中では統計ノイズとして見過ごされがちですが、OpenResty XRay はその最長応答時間を正確に捉え分析し、高リスク イベントとして特定することができます。
  • 継続的に高止まりする CPU リソースの無駄な消費（CPU ブラックホール）： 監視データは、ゲートウェイ クラスターの CPU 利用率、特に log フェーズにおいて、常に高止まりしていることを示していました。ピーク時の安定性を確保するため、お客様チームは過剰な構成を採用せざるを得ず、これが高額なインフラコストに直結していました。

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

経験主義から動的観測への価値転換

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

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

パフォーマンスホットスポットの特定と解決

P99 レイテンシー急増の謎がまず解明されました。

  • 証拠： OpenResty XRay の「Regex Expressions」レポートは、string.gmatch 関数呼び出し（パターンは"([^%.]+)"）が、サンプリング期間中に「単一実行における最長処理時間」として驚異的な 244.64 ms を記録したことを明確に示しています。
  • 根本原因分析： これが P99 レイテンシー急増の直接的な原因でした。分析の結果、顧客チームのエンジニアが Lua 内蔵の string.gmatch を慣習的に使用していたことが判明しました。その技術的な背景として、この関数が依存する LPeg エンジンが JIT (Just-In-Time Compilation) をサポートしていない点が挙げられます。特定の境界条件や悪意のある入力に直面すると、その正規表現エンジンは致命的なパフォーマンスのバックトラックを引き起こし、実行時間が急激に上昇します。
  • 解決策の提案： 直ちに顧客に対し、パフォーマンスボトルネックとなっているコード内の string.gmatch をすべて ngx.gmatch に置き換えることを提案しました。ngx.gmatch は OpenResty が徹底的に最適化した PCRE ライブラリに基づいており、パフォーマンスがより安定しているだけでなく、JIT コンパイルもサポートしています。

詳細なオーバーヘッド分析

遅延問題の解決後、次に CPU 使用率に着目しました。

  • XRay 証拠： On-CPU フレームグラフは最も直感的な手がかりを示しており、ngx_http_log_request 関数が CPU 時間の実に 26.5% もの時間を占有していました。本来軽量であるべき log フェーズが、CPU リソースを大量に消費する主要因となっていたのです。
  • 根本原因分析： フレームグラフのスタックをドリルダウンし、ngx_http_lua_ffi_compile_regex への大量の呼び出しが行われていることを発見しました。これは、log フェーズでログの非識別化とフォーマットに使用される Lua コードが、すべてのリクエストに対して同じ正規表現を繰り返しコンパイルしていることを意味します。これは典型的でありながら、見過ごされがちなパフォーマンスの罠です。
  • 解決策の提案： 根本原因は、ngx.re.match 呼び出し時に 'o' (compile-once) オプションが不足していたことでした。すべてのホットパス（特に log フェーズ）における ngx.re.* 呼び出しに 'o' オプションを追加し、正規表現が「一度コンパイルすれば、何度でも再利用できる」ことを保証することを提案します。

見落とされていた PCRE JIT スイッチ

これまでの 2 つの発見はすでに大きな価値をもたらしましたが、OpenResty XRay の「Lua-Land」レポートは、より根深く、システム全体に関わる問題を浮き彫りにしました。

  • 発見： レポートによると、お客様システム内の すべて の ngx.re.* 呼び出しにおいて、JIT コンパイルオプションが無効になっていました。これは、修正対象としていた呼び出しについても同様でした。
  • 根本原因分析： 調査の結果、多くのチームが陥りがちなミスが判明しました。お客様がゲートウェイ構築に用いたベース Docker イメージの OpenResty コンパイル時に、重要なコンパイルパラメータである --with-pcre-jit の追加が漏れていたのです。
  • 解決策の提案： このことは、クラスター全体が PCRE JIT がもたらす絶大なパフォーマンス上のメリットを一度も享受できていなかったことを意味します。直ちにお客様チームに対し、ベースイメージの再コンパイルと、すべての ngx.re.* 呼び出しにおける 'j' (JIT) オプションの一括有効化を提案し、OpenResty の真のポテンシャルを最大限に引き出すことを促しました。

定量的なエンジニアリング効率とリソース最適化指標

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

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

継続的なパフォーマンス観測能力の構築

これら 2 つのパフォーマンスボトルネックを解消することの直接的な価値は明らかです。しかし、より深い洞察として、高並行・低遅延の OpenResty 環境において、パフォーマンス問題がしばしば構築システム、実行時設定、そして低レイヤーの細部に潜む魔物の中に隠されているという工学哲学が改めて裏付けられました。

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

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

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

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

翻訳

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