How to perform chaos engineering on the cloud?

01 カオスエンジニアリングの手法

従来のシステム運用保守の方式では、通常、システムのバックボーンプロセスとビジネスプロセスのみに注目し、バイパスシステムや基盤アーキテクチャを見過ごしがちです。システムアラームが発生した際、注意を払っていなかった部分が原因である可能性が高く、運用保守担当者が適切に対応できないことがあります。大規模障害が発生した場合、複数のビジネスドメインの担当者を連携させて対処する必要がありますが、各担当者は異なるビジネス領域の出身で、責任範囲や専門性も異なるため、効率的に連携して障害に対処できません。

ビジネスシステムのガバナンスおよび運用保守レベルは、ビジネスシステムのレベルに応じて 4 つの段階に分類できます。

① 業務システム：ビジネス開発者が最も得意とする、または最も関与するシステム。開発コードなどが該当します。

② 関連ビジネス：同じ会社や部門で開発された 2 者間の依存関係を指します。

③ ミドルウェアおよび基盤コンポーネント：一般的な開発者はこのレイヤーを気にしなくなります。

④ インフラストラクチャ層：運用保守担当者が熟知しており、開発者はこのレイヤーの運用保守にほとんど関与しません。

各技術層は異なる問題に直面します。

● 業務システムで最も一般的な問題は、コードバグ、トラフィックのバースト、およびリリース時の中間状態の問題です。

● 関連ビジネス層が直面する問題は、問題が発生した際にビジネスがどのように動作するかです。たとえば、関連ビジネスが停止した場合、関連ビジネスの依存関係エラーや RT の急増が発生する可能性があります。関連ビジネスにコードバグがある場合は、論理エラーとなります。

● ミドルウェアおよび基盤コンポーネントで発生する問題は、主にミドルウェアの機能停止、スロークエリ、ApsaraDB RDS の障害、またはメッセージ遅延です。

● 物理インフラ層で発生する問題のほとんどは、システムダウンタイムまたはネットワークの問題で、ネットワーク輻輳、ネットワークパケット損失、レイテンシの増加、さらにはデータセンター全体の機能停止が含まれます。

上記の異なる技術層で発生する未知の問題を解決するため、カオスエンジニアリングを導入し、4 つの観点から検証します。

① 容量：システム容量を明確にすることで、システムがどのくらいのユーザー数や呼び出しに耐えられるかを把握できます。

② システム複雑性：システムが長期化するにつれ、潜在的な問題がますます増えます。ビジネスと技術の更新および反復により、技術的負債も増え、リンクが長期化し、トラブルシューティング手法も不足します。

③ 可用性：世界に 100% 利用可能なシステムは存在せず、あらゆるシステムが障害を起こす可能性があります。可用性とは、システムに問題が発生した際にどうなるかということです。

④ 人、プロセス、および連携効率：システム障害対応において最も不安定な要素です。

カオスエンジニアリングのすべての訓練シナリオは障害に由来します。障害をまとめた後、まずテスト環境でウォーターテストを実施して検証します。その後、成熟したケースを本番環境での訓練に移行できます。訓練完了後、振り返りを実施し、システムで解決すべき問題をまとめます。これがカオスエンジニアリングの究極の目標、つまり訓練から最適化可能な箇所を抽出し、最適化することです。最後に、すべての安定したケースを集約し、カオスエンジニアリング自動化のケースセットにまとめます。このセットは本番システムを安定して実行し、本番システムのパフォーマンスと複雑性のリグレッションを実施し、一部の変更がシステムの安定性や可用性に影響を与えないようにします。

カオスエンジニアリングの実践は 4 つの典型的なステップに分類されます。

ステップ 1：システムの定常状態を定義し、測定する。システムがどのような条件下でどのようなリクエストに対応できるか、または安定して稼働している際のパフォーマンスを明確にする必要があります。たとえば、システムが 1000 QPS で安定したサービスを提供できる場合などです。

ステップ 2：仮説を立てる。システムの定常状態において、システムの安定性に影響を与える可能性のある変数を見つけます。たとえば、キャッシュが正常に機能しなくなった場合でも、システムが 1000 QPS でサービスを提供できるかどうかなどです。

ステップ 3：仮説を実世界で発生しうるイベントに落とし込む。たとえば、キャッシュが正常に機能しなくなった場合、実際に発生しうるイベントとして、キャッシュサーバーのネットワーク停止やキャッシュシステムの強制排除などが考えられます。

ステップ 4：仮説を立証または反証する。たとえば、キャッシュが正常に機能しなくなった後にシステムが不安定になった場合、最大 QPS が 1000 に達するかどうかを確認します。システム QPS が依然として 1000 に達する場合は、少なくともこのモデルケースにおいてシステム安定性が合格となります。QPS が 1000 に達しない場合、たとえば QPS 200 でシステムが不安定になる場合は、システムのボトルネックを特定して対処できます。

カオスエンジニアリングの実践には 5 つの原則があります。

① 定常状態の動作に関する仮説を構築する：カオスエンジニアリングは、不安定なイベントが発生した際にシステムが正常に機能するかどうかを検証することに焦点を当てるべきであり、システムがどのように機能するかを検証しようとするものではありません。

② 実世界のイベントを多様化する：まず、発生し得ないイベントは気にせず、実際に発生しうるイベントで実験する必要があります。次に、問題が発生する可能性のあるシステム内の箇所をできるだけ多くリストアップし、発生確率が高いもの、または過去に発生したイベントを優先します。

③ 本番環境で実験を実行する：エラスティックコンピューティングの初期段階では、システム安定性が低く、可観測性も不十分で、オンラインで障害を注入した際の影響範囲を十分に監視できないため、本番環境での実験は不可能でした。たとえば、コードは隔離されているがデータは隔離されていない環境でテストする場合、システムの真のボトルネックを検出することは全くできません。オンライン環境とのわずかな違いでも最終結果の精度に影響を与えるからです。そのため、本番環境で実験を実施し、問題発生時のシステムのパフォーマンスを最大限に引き出すことを推奨します。

④ 自動実験を継続的に実行する：パフォーマンスをリグレッションの一部として組み込み、機能リグレッションだけでなく、自動パフォーマンスリグレッションも実施します。

⑤ 影響範囲を最小化する：十分な可観測性がある状態で、訓練がシステムに与える可能性のある影響を制御します。訓練の目的はシステムの弱点を検証することであり、システムを完全に破棄することではありません。そのため、訓練の範囲を制御し、影響を最小化し、オンラインユーザーへの過度の影響を避ける必要があります。

02 エラスティックコンピューティングにおけるカオスエンジニアリング実践

負荷テスト中に、各ユーザーの各 API に呼び出し QPS 上限、つまりフロー制御を設定します。負荷テストシナリオにおけるすべてのユーザーの重ね合わせは比較的安定していますが、依然として不安定な箇所が存在します。まず、ユーザーに対するフロー制御は存在するものの、その検証は行われていません。ユーザーがしきい値内で呼び出しを行うことで、機能の完了を保証し、システムに過度な負荷をかけないようにしています。次に、単一インターフェイスまたはアプリケーション全体の総容量が不明です。単一ユーザーの呼び出しではシステム安定性を保証できます。

異なるユーザーの呼び出しピークが単一呼び出し元から重ね合わされることで、システムバックエンドの負荷が高くなりすぎ、ピーク時にシステムに問題が発生します。

上記のプロセスは 4 つのステップにまとめられます。

ステップ 1：比較的安定したシステムを構築する。

ステップ 2：問題を埋め込む — システム容量が不明な状態にする。

ステップ 3：ユーザーが実環境で発生しうる問題をトリガーする。つまり、同じプラットフォーム上で異なるユーザーが突然呼び出しを行う。

ステップ 4：結論として、システムが負荷に耐えられず、最終的に障害が発生する。

上記のプロセスで解決すべき 4 つの問題があります。システム容量の不明による重大な結果、ピークフロー時のシステムパフォーマンスの不明、ピークフローの原因の不明、およびシステムクラッシュ後の対応プロセスの不明です。システムの安定性を探索するため、未知を既知に変える必要があり、そのため負荷測定を導入します。主に 3 つのステップに分けられます。

ステップ 1：ベースライン。システムのボトルネックと負荷テストの停止条件を定義します。

ステップ 2：実際の負荷テスト。負荷テストは一般的に API をエントリーポイントとして実施します。外部 API、内部 API のいずれも対象となります。負荷テストの方法は 3 つあります。

● シンプルなブルートフォース負荷テスト：非常にシンプルな API を対象とします。単一の API 呼び出しでシステムに負荷をかけ、インターフェイスを並行呼び出しして負荷テストを実施します。

● ロジックフロー型の負荷テスト：呼び出し前にリソースを準備する必要があり、インターフェイスを単独で呼び出すことはできません。コンテキストセマンティクスを持つインターフェイスとも呼ばれ、ステートフルなインターフェイスです。インターフェイスを編成し、インスタンスの作成やクエリを実施し、各インスタンスに対してシリアルフローを編成し、シリアルフローに対して並列負荷テストを実施し、最終的にロジックフロー型の負荷テストケースを形成します。

● オンライン再生負荷テスト：より複雑なケースや内部呼び出しのケースに使用します。

ステップ 3：自動負荷テスト。安定したケースとシステムに害のないケースを自動ケースセットに統一し、ベースラインに基づいて自動アラームを設定します。自動負荷テストのリグレッションで、インターフェイスが事前に予測されたベースラインを満たしていないことが判明した場合、自動アラームが発生し、システムパフォーマンスのリグレッションを実現し、最終的に前述の 4 つの問題を解決します。

● システム容量の不明による重大な結果に対して、システム容量ベースラインを設定し、システムの限界まで負荷をかけることでシステム容量を確定します。

● フローピークの原因の不明に対して、ピーク値の仮定、マルチユーザーシミュレーション、およびフロー制御の解放によりテストを実施します。実際の生産環境では、システム容量を定義した後、ユーザーフロー制御の計算を通じて不明なピーク元の問題を解決し、フロー制御のしきい値を合理的な範囲に設定できます。

● ピークトラフィック時のシステムパフォーマンスの不明に対して、システムのボトルネックが検出された際に、システムボトルネック時のパフォーマンスを特定できます。

● システムクラッシュ後の対応プロセスの不明に対して、負荷テストを通じて抜き打ち訓練を実施し、ビジネス担当者が高トラフィックシナリオに迅速かつ安定して対応できるかを確認し、障害発生時の発見・特定・復旧の時間を短縮します。

障害訓練と可観測性は切り離せません。可観測性の構築が比較的完了している場合、オンラインシステムに障害訓練を注入し、システムの影響範囲を制御できます。

可観測性は 4 つのレイヤーに分類されます。

● ビジネスレイヤー：結果モック、JVM OOM、ビジネスロジック例外、およびアプリケーション内の CPU 全振りを含みます。

● 依存ビジネスレイヤー：依存ビジネス専用のビジネスインターフェイス監視があり、自身と内部依存関係に対して SLA 契約の一部を定めています。

● ミドルウェアおよび基盤ソフトウェアレイヤー：ミドルウェアビジネスの監視があり、キャッシュヒット率、スロークエリ監視、ネットワークステータス監視などがあります。

● サーバーレイヤー：ビジネス検出およびネットワークステータス監視があります。

異なるレイヤーに対して異なる障害訓練があります。たとえば、ビジネスレベルのモックでは、すべてのビジネスドメインの担当者に周知し、ビジネスレベルで監視し、VM 内部に注意を払う必要があります。依存サービスに対しては、RT の上昇、結果のモック、または結果のエラー報告に注目します。ミドルウェアおよび基盤ソフトウェアレイヤーは、キャッシュの遅延、機能停止、MySQL の遅延、接続不能などの問題に直面する可能性があります。インフラストラクチャプロバイダーとして、エラスティックコンピューティングはサーバーレイヤーにより注目しています。エラスティックコンピューティングが各リージョンでオンラインになる際、制御システムは複数のゾーン、ダウンタイム、および訓練を経て、制御システムの可用性を検証する必要があります。そのため、サーバーレイヤーは訓練において豊富な経験を持っています。

障害訓練のステップは以下の通りです。

ステップ 1：障害訓練のコンセプトは、システムの不安定さを意図的に高め、不安定なイベントをできるだけ増やすことであり、開発者の日常的なコンセプトと相反します。そのため、まず全員に障害訓練を受け入れてもらう必要があります。専門的な訓練チームが固定の訓練スケジュールと明確な訓練編成を策定し、すべてのビジネスが参加します。

ステップ 2：日常的な訓練組織。日常的な訓練組織におけるイベントの選択原則は、頻度の高い問題を優先し、リスクを低いものから高いものへと段階的に進めることです。次に、まず低リスク環境でテストし、隔離環境での影響を確認し、低リスク環境で破壊的な実験や大規模障害シミュレーションを実施します。たとえば、影響が完全に制御不能な障害は低リスク環境で実施する必要があります。比較的安定したケースや影響を特定できるケースのみが本番環境での訓練を実施できます。本番環境で訓練を実施する際は、発見・特定・復旧のプロセスに従う必要があります。

ステップ 3：抜き打ち訓練。抜き打ち訓練にはレッドブルー演習とワンクリック訓練が含まれます。レッドブルー演習は比較的保守的で、訓練チームから訓練ケースに精通した担当者を選び、レッド軍として障害訓練に参加させ、随時システムに問題を注入します。その他のすべてのビジネス担当者はブルー軍として、問題の発見・特定・復旧時間の検証を担当します。ワンクリック訓練はより積極的な方法で、通常、ビジネスリーダーが直接障害を注入し、すべてのビジネス担当者の障害対応プロセスを訓練します。高度に成熟したシステムのみがワンクリック訓練の目標を達成できます。

ステップ 4：まとめと改善。まとめと改善は、カオスエンジニアリングにおける障害訓練と負荷テストの究極の目標です。障害訓練と負荷テストを通じてシステムの限界を確定します。これには、システムウォーターレベルの限界、運用保守対応の限界、問題発見の限界、およびシステム復旧の限界が含まれ、システムパフォーマンスと問題対応プロセスを明確にします。利用不可なノードとパフォーマンスボトルネックを記録し、最終的に利用不可なノードを改善目標項目として抽出します。システム安定性の改善に責任を持ちます。

大規模分散システムとして、エラスティックコンピューティングシステムのカオスエンジニアリングとシンプルなカオスエンジニアリングの違いは何でしょうか。

① 複数セットの環境デプロイメント。エラスティックコンピューティングは 20 セットの高可用性デプロイメントと複数セットの環境計画を持つため、自動追跡システムによりケースカバレッジとリージョンカバレッジを自動化することを期待しています。

② 凝集と結合のノードが多い。計画すべき依存関係が多く、連携すべきビジネス当事者も多い。解決策は、より多くのビジネスドメインを連携させ、優先度に応じて実施する訓練を編成することです。

③ 大量のリアルタイム呼び出し。訓練中、非常に大規模なフローシステムに対応する必要があり、フローを短時間で停止することはできません。そのため、訓練中にシステムの一部が不安定になると、オンラインで非常に重大な障害として増幅されます。グレーリリース訓練、SLA、およびサーキットブレーカーデグレードを通じて問題を回避できます。

④ インターフェイスの機能が多い。自動訓練によるケースカバレッジの達成を期待し、ケースの自動リグレッションにより毎日自動的にオンラインシステムに回帰し、システムパフォーマンスの変化を追跡します。

03 システム評価とカオスエンジニアリングツール

カオスエンジニアリングシステムの成熟度は、縦軸で 5 つのレベルに分類できます。

レベル 1：主にスタートアップ期のシステムで、単一環境および単一リージョンにデプロイされており、開発テスト環境でのみ訓練を実施できます。

レベル 2：初期段階のマルチ AZ デプロイを備え、やや複雑な障害を注入できます。

レベル 3：本番環境およびグレーリリース環境で訓練を実施できます。

レベル 4：比較的成熟したシステムで、本番環境で実験を実行でき、比較的成熟した障害注入や関連ビジネスの障害注入を実施できます。

レベル 5：さまざまな環境でシステム障害とデータプレーン障害を注入でき、目標システムでもあります。

クラウドは多くのサポートツールを提供しています。

負荷テストの面では、シナリオを設定し、負荷テストの進行を制御し、全国にデプロイされた限定ノードを通じてユーザーリクエストをシミュレートできる性能テスト PTS ツールがあり、ユーザーの動作に近いテストが可能です。負荷測定中、クラウド監視 ARMS および PTS 監視を通じて可観測性の作業を完了でき、同時にシステム負荷を観察できます。

障害注入プラットフォーム Application High Availability Service (AHAS) は、アプリケーション層、基盤層、物理マシン層を含むさまざまなレベルで問題を注入できます。

負荷テストと訓練があれば、防御も必要です。負荷測定の主なツールには PTS、Jmeter などがあります。負荷テストの防御ツールには Sentinel や AHAS などの内部および外部ツールがあります。システムに問題が発生した際、Hystrix や AHAS を通じてシステムをデグレードできます。訓練ツールには AHAS、ChaosBlade、ChaosMonkey などがあります。訓練シナリオでは、AHAS を通じて障害シナリオをサーキットブレーカーできます。さらに、クラウド上では ARMS、クラウド監視などの可観測性コンポーネントも提供されています。クラウド内外の両方で Prometheus を可観測性に活用できます。