翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# カオスエンジニアリングの開始方法
実験を行う前に、カオスエンジニアリングのプラクティスを最大限に活用するために、いくつかの重要なものを用意することをお勧めします。これらの必須事項には以下が含まれます。
+ オブザーバビリティ (メトリクス、ログ記録、リクエストトレース)
+ 探索する実際のイベントまたは障害のリスト
+ リーダーシップの賛同による組織のレジリエンススポンサーシップ
+ カオス実験の実行時に発見された新機能よりも、潜在的なビジネスへの影響に基づく重要な検出結果の優先順位付け
## カオス実験のオブザーバビリティ
メトリクス、ログ記録、リクエストトレースで構成されるオブザーバビリティは、カオスエンジニアリングで重要な役割を果たします。実験を実行するときは、ビジネスメトリクス、サーバー側のメトリクス、クライアントエクスペリエンスメトリクス、およびオペレーションメトリクスを理解する必要があります。オブザーバビリティがないと、定常状態の動作を定義したり、意味のある実験を作成して、アプリケーションに関する仮説が満たされているかどうかを確認することはできません。
### メトリクス
次の図は、さまざまなタイプのアプリケーションのカオス実験で追跡できるメトリクスのタイプを示しています。
+ **ビジネスメトリクス** – *定常状態*はシステムの通常のオペレーションを示し、ビジネスメトリクスによって定義されます。1 秒あたりのトランザクション (TPS)、1 秒あたりのクリックストリーム、1 秒あたりの注文、または同様の測定値で表すことができます。アプリケーションが想定どおりに動作している場合、アプリケーションは定常状態を示します。したがって、実験を実行する前に、アプリケーションが正常であることを確認します。障害の割合が許容範囲内にある可能性があるため、定常状態は必ずしも障害発生時にアプリケーションに影響を与えないことを意味するわけではありません。定常状態はベースラインです。例えば、支払いシステムの定常状態は、成功率が 99%、往復時間が 500 ミリ秒の 300 TPS の処理として定義できます。視覚的に見ると、定常状態を絵文字 (EKG) と考えることができます。システムの定常状態が突然変動する場合は、サービスに問題があることがわかります。
+ **サーバー側のメトリクス** – 実験中のリソースのパフォーマンスを理解するには、実験前、実験中、実験後のリソースのパフォーマンスに関するインサイトが必要です。リソースが に与える影響を測定するには AWS、[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) を使用できます。CloudWatch は、アプリケーションをモニタリングし、パフォーマンスの変化に対応し、リソースの使用を最適化し、運用状態に関するインサイトを提供するサービスです。実験中に、飽和、リクエストボリューム、エラー率、レイテンシーなどのサーバー側のメトリクスをキャプチャします。
+ **カスタマーエクスペリエンスメトリクス** – では AWS、[CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) を使用して、Locust、Grafana k6、Selenium、Puppeteer などのツールを使用してユーザーリクエストをシミュレートすることで、実際のユーザーメトリクスをキャプチャできます。実際のユーザーメトリクスは、カオスエンジニアリング実験を行う組織にとって不可欠です。実験中に実際のユーザーがどのように影響を受けるかをモニタリングすることで、チームは障害や中断が本番環境の顧客にどのように影響するかを正確に把握できます。主なクライアントエクスペリエンスメトリクスは、最初のバイトまでの時間 (TTFB)、最大コンテンツフルペイント (LCP)、次のペイントへのインタラクション (INP)、合計ブロック時間 (TBT) です。
+ **オペレーションメトリクス** – 介入は、レプリケーションコントローラーや自動スケーリングなどのメカニズムを使用して、ポッド、タスク、EC2 インスタンスの再起動中のクライアントリクエストのレイテンシーの成功など、障害を自動で軽減する方法を測定します。障害発生時に自動的に介入できることは、良好なユーザーエクスペリエンスと直接相関します。これらの緩和メカニズムに時間の経過に伴うドリフトがあるかどうかを理解することは重要です。成功した自動緩和策と失敗した自動緩和策の両方のメトリクスを定義することで、システム全体で潜在的なリグレッションを特定するのに役立つガイドポストを作成します。
### ログ記録
集中ログ記録は、カオス実験の前、最中、および後にアプリケーションコンポーネントの状態を理解する上で重要です。すべてのアプリケーションコンポーネントからログを収集して、実験が挿入された時点で各コンポーネントが何をしていたかの統合ビューを構築することをお勧めします。これにより、end-to-endの実験フローを明確に把握できます。
### リクエストのトレース
リクエストトレースを使用すると、アプリケーション内のコンポーネント全体で 1 つのリクエストのフローを監視して、挿入された障害がシステムとその依存関係に与える影響を包括的に把握できます。リクエストを追跡することで、障害がさまざまなサービスやコンポーネントにどのように伝播されるかを把握できるため、中断の範囲をより適切に評価できます。リクエストを追跡するには AWS、 を使用できます[AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)。
## カオス実験に注入する失敗シナリオ
アプリケーションに一般的な障害を挿入する目標は、アプリケーションがこれらの予期しないイベントにどのように反応するかを理解することです。これにより、緩和メカニズムを作成し、このような障害に対するシステムの耐障害性を高めることができます。さらに、カオスエンジニアリングを使用して過去の障害シナリオを再生し、緩和メカニズムが期待どおりに機能し、時間の経過とともにドリフトしていないことを確認する必要があります。
カオスエンジニアリング実験を計画するときは、次のイベントを考慮してください。
| 失敗モード | 説明 |
| --- | --- |
| サーバーの障害 | EC2 インスタンスを再起動し、Kubernetes ポッドまたは Amazon Elastic Container Service (Amazon ECS) タスクを削除して、アプリケーションがこのようなクラッシュにどのように反応するかを理解します。 |
| API エラー | AWS および独自のサービス APIsして、アプリケーションの動作を理解します。 |
| ネットワークの問題 | レイテンシーや輻輳を導入するか、接続をブロックして実際のネットワーク問題を模倣します。 |
| AWS アベイラビリティーゾーンの障害 | アベイラビリティーゾーン全体の障害を再生して、ゾーン間の復旧を確認します。 |
| AWS リージョン 接続障害 | 全体でネットワーク障害を再生 AWS リージョン して、セカンダリリージョンのリソースがそのようなイベントにどのように反応するかを検証します。 |
| データベース障害 | データベースレプリカをフェイルオーバーしたり、データが破損したり、データベースインスタンスにアクセスできなくなったりして、アプリケーションと復旧戦略への影響を理解します。 |
| データベースと Amazon S3 レプリケーションの一時停止 | アベイラビリティーゾーン間でデータベースまたは Amazon Simple Storage Service (Amazon S3) レプリケーション AWS リージョン を一時停止するか、ダウンストリームアプリケーションの影響を理解します。 |
| ストレージの劣化 | I/O を一時停止するか、Amazon Elastic Block Store (Amazon EBS) ボリュームを削除するか、ファイルを削除してデータの耐久性と復旧を確認します。 |
| 依存関係の障害 | サードパーティーのサービスなど、依存するダウンストリームまたはアップストリームサービスのパフォーマンスを低下または低下させ、end-to-endのフローと顧客への影響を理解します。 |
| トラフィックの急増 | ユーザートラフィックの急増を生成して自動スケーリング機能をテストし、コールドブート時間がアプリケーション全体の状態にどのように影響するかを確認します。 |
| リソースの枯渇 | CPU、メモリ、ディスク容量を最大にして、アプリケーションの正常な劣化を確認します。 |
| カスケード失敗 | ダウンストリームアプリケーションとコンポーネントにカスケードするプライマリ障害を開始します。 |
| 不正なデプロイ | ロールバックメカニズムを検証するために、問題のある変更または設定をロールアウトします。 |
## 組織のレジリエンススポンサーシップ
カオスエンジニアリングは、組織全体に適用されると最大の価値を提供します。組織全体のレジリエンス目標の設定を支援し、ドメインに対する懸念、不確実性、疑念を排除し、変革プロセスを開始して、全員の責任のレジリエンスを実現できるエグゼクティブスポンサーと協力することをお勧めします。
カオスエンジニアリングプラクティスを構築するビジネスケースをサポートするには、カオスエンジニアリングの取り組みを重要なビジネスプロジェクトにアタッチします。レジリエンスをアセットにし、アクセラレーションを促進することで、時間の経過とともに成功を追跡するのに役立ちます。まず、1 か月または 1 四半期あたりの重大なインシデントの数、平均復旧時間、およびこれらのインシデントが顧客や組織に与えた影響から始めます。カオスエンジニアリング実験に応じてアプリケーションスタック全体で改善が行われるため、6 か月から 12 か月の期間にわたってインシデントの数を減らすことをチームで目標を設定します。
インシデントの反復性が高いかどうかを測定します。たとえば、期限切れの TLS 証明書があると、クライアントは信頼できる接続を確立できないため、ダウンタイムが発生するとします。複数の TLS 証明書の有効期限切れが原因で 1 年間に複数のインシデントが発生した場合は、TLS 証明書の有効期限の実験を実行し、チームがアラートを受け取るか、そのような問題を自動的に軽減できることを確認できます。これにより、このような障害に対する耐障害性を確保できます。
カオスエンジニアリングの進行状況を経時的に追跡するには、次のメトリクスをキャプチャして、アプリケーションのライフサイクル全体でカオスエンジニアリングの価値を強調します。
+ **インシデント率の低下** – 本番環境のインシデントの数を経時的に追跡し、この数をカオスエンジニアリングの導入と関連付けます。重大なインシデントの発生率が低下することが予想されます。
+ **平均解決時間 (MTTR) の改善** – インシデントの解決にかかる平均時間を計算し、このデータを追跡して、時間の経過とともにカオスエンジニアリングが改善されるかどうかを確認します。
+ **アプリケーションの可用性の向上** – カオス実験によるアプリケーションの耐障害性の向上に応じて、サービスレベルのメトリクスを使用して可用性の向上を示します。
+ **市場投入までの時間の短縮** – カオスエンジニアリングは、アプリケーションの耐障害性がわかっているため、革新的な製品をより迅速に起動できるという自信を与えることができます。製品のリリース速度の増加を追跡します。
+ **運用コストの削減** – カオスプラクティスの導入により、アラートノイズ、運用負荷、アプリケーションを管理するための手動作業などの指標が減少するかどうかを定量化します。
+ **信頼を高める** – 開発者、サイト信頼性エンジニア (SREs)、その他の技術スタッフにアンケートを行い、カオスエンジニアリングがアプリケーションの耐障害性に対する信頼を高めたかどうかを判断します。認識は重要です。
+ **カスタマーエクスペリエンスの向上** ‒ カオスエンジニアリングを、サービスの中断、ロールバック、停止の軽減など、お客様の良い成果につなげます。
## 修復の優先順位付け
カオス実験を実行すると、アプリケーションが意図したとおりに動作しない改善が必要な領域を特定する可能性が高くなります。このような項目の修復はバックログで機能するため、機能開発などの他の作業とともに優先順位を付ける必要があります。将来の障害を避けるため、これらの機能強化に時間をかけることをお勧めします。これらの学習と修復タスクは、それらが引き起こす可能性のある影響のレベルに基づいて優先順位を付けることを検討してください。アプリケーションのレジリエンスやセキュリティに直接影響する検出結果は、顧客への影響を避けるために、新機能よりも優先される必要があります。チームが機能開発よりも修復作業の優先順位付けに苦労する場合は、エグゼクティブスポンサーに連絡して、ビジネス上のリスク許容度に基づいて優先順位が設定されていることを確認することを検討してください。