OpenResty XRay がどのようにしてアプリケーションの問題特定と効率化を支援するかをご覧ください。

詳細はこちら LIVE DEMO

すべてのエンジニアが恐れる悪夢——本番サーバーが一斉に CPU 使用率 100% に達し、リクエストをまったく処理できなくなる。再起動しても改善しない。ロールバックしても改善しない。システムは稼働しているにもかかわらず、完全に麻痺した状態に陥る。

これが、2021 年 7 月に Bilibili のエンジニアリングチームが直面した事態です。Bilibili——アジア最大級の動画共有プラットフォームのひとつであり、数億人のユーザーにサービスを提供——は、オープンソースの OpenResty フレームワーク上に内部ゲートウェイシステムを構築していました。障害発生時、本番稼働中のすべてのサーバーにおける OpenResty のプロセスが同時に同じ状態に陥りました——CPU 使用率 100%、リクエスト処理ゼロ。

社内リソースをすべて使い果たした後、Bilibili のチームは OpenResty Inc.（以下、弊社）にサポートを要請しました。

その後の診断にかかった時間はわずか数秒でした。そして、判明した根本原因は、経験豊富なエンジニアでさえ思わず立ち止まるようなものでした——数値型の重み（weight）が期待される箇所に、文字列型のゼロ値（"0"）が渡されたことで、システム全体にわたる無限再帰が引き起こされていたのです。

本記事では、OpenResty XRay ——非侵襲型の動的トレーシングツール——が、Bilibili の本番プロセスに対してコードを一行も変更することなく、また何も注入することなく、どのようにして正確な根本原因を特定したかを解説します。

OpenResty XRay を使用してソフトウェアの問題を迅速に可視化し解決する

Bilibili：数億のストリームを支えるプラットフォーム

Bilibili は上海を拠点とする動画共有プラットフォームであり、アジアで最も人気の高いストリーミングサービスのひとつです。中国におけるアニメストリーミングの主要プラットフォームとして設立された後、現在では自国市場において YouTube に匹敵する規模と文化的影響力を持つ、幅広いコンテンツプラットフォームへと発展しています。

Bilibili は OpenResty XRay の商用顧客です。同社のエンジニアリングチームは、オープンソースの OpenResty 開発フレームワーク上にプラットフォームの内部ゲートウェイシステムを構築していました。この選択が、今回の障害の診断方法に直接関係することになります。

再起動が効かないとき：障害の経緯

2021 年 7 月 13 日、Bilibili の本番環境は、標準的なインシデント対応手順書では想定されていない状態に陥りました。

本番稼働中のすべてのサーバーにおける OpenResty プロセスが、同時に CPU 使用率 100% に達し、その状態が継続しました。リクエストはまったく処理されていませんでした。システムは従来の意味でクラッシュしていたわけではなく、フル稼働しながら有用な処理を何ひとつ行っていない状態でした。

CPU All 100%

エンジニアリングチームはサーバーの再起動や直近の変更のロールバックといった標準的な対応を実施しましたが、いずれも効果がありませんでした。すべてのサーバーが同じ状態に戻ってしまいました。社内リソースを使い果たし、障害が本番環境で継続する中、Bilibili のチームは OpenResty Inc. にサポートを要請しました。

その後 Bilibili が公開した障害報告記事——2021.07.13 障害の経緯——は大きな反響を呼び、障害の診断・解決に関する技術的な詳細について多くの質問が寄せられました。本記事はそれらの質問に直接回答するとともに、関連ツールをより広い技術者コミュニティに紹介することを目的としています。

コードに一切触れずに根本原因を特定する

Bilibili のチームは OpenResty Inc. に対し、障害が発生している本番環境へのアクセスを提供しました。その後の対応は、OpenResty XRay のコア機能を端的に示すものとなりました——稼働中のシステムに一切の変更を加えることなく、コードレベルの深い診断を実現するという機能です。

コード変更なし。インストルメンテーション（計装）なし。Bilibili のプロセスへの注入なし。特別なコンパイルオプションやプラグインも不要。

ステップ 1：C レベル CPU フレームグラフ

OpenResty XRay の自動サンプリングによる C レベル CPU フレームグラフを使用し、OpenResty チームは Bilibili の OpenResty Nginx プロセスが CPU 時間のほぼすべてを Lua コードの実行に費やしていることを迅速に特定しました。

C-Land CPU Flame Graph for Bilibili

プライバシーおよびデータセキュリティ上の理由から、このグラフには OpenResty のオープンソースソフトウェアに由来する関数フレームのみが表示されており、Bilibili の Lua コードおよび関連情報は含まれていません。

ステップ 2：Lua レベル CPU フレームグラフ

次に、OpenResty XRay の自動サンプリングによる Lua レベル CPU フレームグラフを使用し、CPU 時間のほぼすべてが単一の Lua コードパスに集中しており、そのコードパスが無限ループで実行されていることを確認しました。OpenResty XRay の Lua CPU フレームグラフは、個々の Lua ソースコード行の粒度で動作します。

Lua-Land CPU Flame Graph for Bilibili

こちらも同様に、顧客に関連しないオープンソースコードの関数フレームのみが表示されています。

Bilibili の元の障害報告記事で参照されている Lua フレームグラフは、OpenResty XRay を使用して、Bilibili の本番サーバー上の問題のある OpenResty サービスプロセスをサンプリングすることで取得されたものです。

OpenResty XRay が両フレームグラフを生成するのに要した時間はわずか数秒でした。これらのグラフは根本原因を含む正確なコードパスを示しており、トラブルシューティングのプロセス全体を通じて、システムプロセスやアプリケーションへのコード変更や注入は一切必要ありませんでした。

根本原因：型の不一致ひとつで、システム全体が停止

Lua フレームグラフが問題の箇所を特定しました。

ビジネスロジックの設定メタデータに、サーバーの重み（weight）として文字列型のゼロ値（"0"）が挿入されていました。OpenResty の lua-resty-balancer ライブラリの Lua API は、数値型の重み値を期待していました。この型の不一致が無限再帰を引き起こし、すべての本番サーバーで同時に無限ループとして顕在化しました。

これは、ログ解析や従来の APM ツールではほぼ発見不可能な種類の根本原因です——エラーはスローされず、クラッシュも発生せず、表面的なメトリクスではシステムが正常に稼働しているように見えました。ただひとつの例外を除いて——有用な処理を何も行っていなかったという点を除いて。

障害後の対応

解決策は 3 つのレベルにわたる変更を伴いました。

Bilibili における対応： エンジニアリングチームは、ビジネスロジックコードにおいて、上流サーバーの重み値として文字列型の値が設定データに書き込まれないよう保護する仕組みを実装しました。

OpenResty XRay における対応： 最新バージョンでは、Lua コールスタックのすべてのローカル変数（local variable）の値を出力する新機能が導入されました。この種の障害に対して、この機能により、今回のケースで必要だった追加の推論ステップを経ることなく、より迅速かつ直接的に根本原因を特定できるようになります。

オープンソースライブラリにおける対応： OpenResty Inc. は、オープンソースの lua-resty-balancer ライブラリに対して、このクラスの API 誤用に対する明示的な入力検証（バリデーション）を追加しました。誤ったデータ型の重み値は、今後常に数値型に変換されるようになり、ライブラリレベルでこの障害モードを防止します。

OpenResty XRay の仕組み：非侵襲型のコードレベル診断

OpenResty XRay は、強化された独自の動的トレーシング技術を活用した、非侵襲型のトラブルシューティング・分析ソフトウェアです。

OpenResty XRay を使用することで、企業は OpenResty、Nginx、LuaJIT、PHP、Python、Perl、Go、PostgreSQL、Redis など、オープンソースのプログラミング言語およびランタイムで構築されたソフトウェアに対して、詳細な分析とモニタリングを自動的に実施できます。Java や Ruby を含む追加の技術スタックへのサポートも積極的に拡充中です。

OpenResty XRay のコードレベルのトラブルシューティングに必要なもの：

  • ユーザーのアプリケーションへの変更ゼロ
  • 特別なプラグイン、モジュール、コンパイルオプション不要
  • カスタマープロセスへのコード注入なし

また、既存の未変更の Docker コンテナや Kubernetes（K8s）コンテナに対して、コンテナ内部に変更を加えることなく解析し、その内部で稼働するアプリケーションを精密に分析することも可能です。

OpenResty XRay を使用することで、CPU スパイクやメモリリークから異常なリクエストレイテンシや高ディスク I/O に至るまで、パフォーマンス、機能、セキュリティに関する問題を迅速かつ正確に特定・診断し、あらゆる環境におけるシステムの安定性を確保できます。

Bilibili に加え、OpenResty XRay は Zoom、Microsoft、Qunar.com をはじめとする多くの企業のパフォーマンス最適化および本番環境における問題の特定を支援してきた実績があります。

OpenResty Console Screenshot

OpenResty XRay で問題を迅速に可視化・解決する

おわりに

本障害は完全に解決されました。プロセス全体を通じて、弊社チームおよび製品をご信頼いただいた Bilibili に深く感謝申し上げます。

本記事は、OpenResty XRay をより広い技術者コミュニティに紹介するシリーズの一部です。エンジニアリングイノベーションを主軸に活動してきた企業として、弊社は現在、ツールが実際の本番環境においてどのように機能するかを積極的にドキュメント化する取り組みを進めています——より多くのエンジニアリングチームがその恩恵を受けられるよう。

OpenResty XRay の詳細についてご興味をお持ちの方、または弊社のドメインエキスパートによる無料コンサルティングレポートをご希望の方は、OpenResty XRay 製品ページをご覧の上、製品トライアルをお申し込みください。

動的トレーシング技術および弊社がその上に構築したクローズドソースの拡張機能にご関心のある方は、こちらをご参照ください：Ylang: eBPF、Stap+、GDB およびその他のためのユニバーサル言語。

OpenResty XRay について

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

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

著者について

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

翻訳

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