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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. レイテンシのスパイクが完全に解消： 最適化後、レイテンシ曲線は非常に滑らかになり、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 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

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