2023年5月26日
カオスエンジニアリング
Harness Chaos Engineeringによる継続的レジリエンスの実現
継続的レジリエンスアプローチをご紹介します。自動化されたカオスエクスペリメントを通じて、レジリエンスを構築する取り組 みがソフトウェア開発ライフサイクルの全ての段階に組み込まれるカオスエンジニアリングを実践するための最新のアプローチです。Harness Chaos Engineering（Harness CE）には、DevOpsでContinuous Resilienceを実現するために必要な全ての構成要素が付属しています。
カオスエンジニアリングは、障害を注入し、システムの定常状態を検証する科学的手法です。ここではカオスエンジニアリングの概念については詳しく説明しませんが、継続的レジリエンスと呼ばれる、より現代的な実装アプローチについて見てみましょう。カオスエンジニアリングの基本を理解するには、こちらの記事を参照してください。従来、カオスエンジニアリングは本番環境における重要なシステムやサービスのレジリエンスを検証するものとして知られてきました。最近では、カオスエンジニアリングはSDLC全体のレジリエンスを確保するために使用されています。SDLCの全ての段階でレ ジリエンスを確保することは、ビジネスクリティカルなサービスの可用性を最大限にエンドユーザーに提供する最も効率的な方法です。
カオスエンジニアリングの概念は、皆さんよくご存知でしょう。カオスエンジニアリング分野における現在の課題のいくつかは、組織全体での実践の実装と拡張、そのようなカオスエクスペリメントの取り組みの成功の測定、スケジュールと取り組みの観点からレジリエンスの最終マイルストーンに到達するために何が必要かを知ることに関連しています。これらの課題の理由は、伝統的にカオスエンジニアリングがGameDayアプローチを使用して本番環境で一連のエクスペリメントを慎重に計画し、実行する演習として教えられてきたためです。GameDayの成功は、時々実行の設計と調整を担当する少数の個人の手にかかっており、他の通常の品質テストやパフォーマンステストのように自動化されてはいません。
継続的レジリエンスアプローチ
現代のカオスエンジニアリングの実践では、開発者とQAチームがカオスエクスペリメントの開発を共有します。テストは全ての環境で自動化されており、開発者、QAチーム、SREなどの全ての担当者によって実行されます。レジリエンスの重視はSDLCの全てのゲートに組み込まれており、これがContinuous Resilienceという用語につながります。継続的レジリエンスアプローチでは、ほとんどのカオスエクスペリメントの実行がパイプラインで発生すると予想されます。ただし、継続的レジリエンスとは、パイプライン内で混乱を引き起こすだけではありません。それは、開発、QA、プリプロダクション、本番の全ての環境で実行されるカオスエクスペリメントを自動化を意味しますが、厳密さの程度はさまざまです。
GameDaysは、特に必要に応じてレジリエンスをテストする必要がある重要なシステムにおいて、自動化されたカオスエンジニアリングエクスペリメントと併用できます。GameDaysは、ドキュメンテーション、リカバリー手順を検証し、インシデント対応のベストプラクティスについてエンジニアをトレーニングする手段も提供します。
Continuous Resilienceの基本理念
カオスエンジニアリングのGameDayアプローチと比較すると、継続的レジリエンスアプローチは次の原則に基づいて構築されています。
- ChaosHubを使用したカオスエクスペリメント開発
- 新しいレジリエンスメトリクスの採用
- SDLCまたはパイプラインへの統合
- カオスエクスペリメントのためのセキュリティーガバナンス
1. ChaosHubを使用したカオスエクスペリメント開発
よく書かれたカオスエクスペリメントは、カオスエンジニアリング実践を成功させるための構成要素です。これらのエクスペリメントは、ソフトウェアまたはインフラストラクチャー構成の変更に対応するために、継続的にアップグレードまたは変更する必要があります。これが、カオスエクスペリメントがカオス「エンジニアリング」と呼ばれる理由です。ベストプラクティスは、カオスコードのライフサイクルを通常のソフトウェアコードと同様に管理することです。これは、カオスエクスペリメントコードがソースコードリポジトリーで開発および維持され、偽陽性と偽陰性がテストされ、開発環境でテストされ、大規模環境での使用にプロモートされることを意味します。
カオスエクスペリメントは、チームの複数のメンバーまたは組織の複数のチームによって簡単に調整、インポート、エクスポート、および共有できなければなりません。上記の機能を備えたChaosHubまたはカオスエクスペリメントの集中リポジトリーが、カオスエクスペリメントの開発とメンテナンスに使用される必要があります。
この方法で、従来のGameDayアプローチのようにSREのみに限定するのではなく、QAチームのメンバーと開発者を積極的に関与させてカオスエクスペリメントの開発を記述します。
2. レジリエンスメトリクスの採用
カオスプラクティスのロールアウトは、通常「本番インシデントの減少率」や「復旧時間の短縮率」などのビジネス目標と関連付けられます。これらのメトリクスは多かれ少なかれ本番システムに関連付けられており、OpsチームまたはSREによって処理されます。例えば、QAテストベッドやパイプラインでは稼働時間や復旧時間は測定できません。全てのペルソナがカオスエクスペリメントに関与する継続的レジリエンスアプローチでは、測定するメトリクスは開発者／QAチーム／QAパイプラインとプリプロダクション／本番／SREの両方に関連する必要があります。このニーズに対して、2つの新しいメトリクスが提案されています。
・レジリエンススコア
・レジリエンスカバレッジ
レジリエンススコア：エクスペリメントには、1つ以上のサービスに対する1つ以上の障害が含まれる可能性があります。レジリエンススコアは、カオスエクスペリメントまたはサービスに関連付けることができます。
レジリエンススコアは、全てのペルソナがパイプライン、QAシステム、本番環境で使用できます。
カオスエンジニアリングのレジリエンススコア
レジリエンスカバレッジ：レジリエンススコアはサービスまたはエクスペリメントの実際のレジリエンスをカバーしますが、レジリエンスカバレッジは、システム全体のレジリエンスがチェックされたと宣言するためにさらに何回カオスエクスペリメントが必要かを示します。これは、ソフトウェアテストにおけるコードカバレッジに似ています。レジリエンススコアと合わせて、レジリエンスカバレッジによりレジリエンス測定を完全に制御できます。レジリエンスカバレッジはサービスまたはシステムに適用 されます。
カオスエンジニアリングにおけるレジリエンスカバレッジ
サービスに対して作成できるカオスエクスペリメントの数は膨大になる可能性があるため、レジリエンスカバレッジメトリクスは実際的な数のカオスエクスペリメントを作成するために使用する必要があります。
3. SDLCまたはパイプラインへの統合
カオスエクスペリメントの自動化は、継続的レジリエンスを達成するために重要です。レジリエンスカバレッジは常に低い数値（通常は5％未満）から始まり、エクスペリメントを非常に安全に実行し、重要なサービスに対して実行できます。どちらの場合も、新しいコードがパイプライン経由で導入される場合、レジリエンスの保証が不可欠です。従って、これらのエクスペリメントはロールアウトプロセスの健全性または品質を検証する通常のパイプラインに挿入する必 要があります。カオスエクスペリメントは開発サイクルごとに自動化されるため、開発／QAチームが費やした開発時間に応じて、レジリエンスカバレッジは段階的に増加し、最終的には数力月または数四半期で50％以上に達します。
パイプラインが80％を超えるレジリエンススコアで80％のレジリエンスカバレッジに達するとします。その場合、既知のソースから本番環境でレジリエンスの問題や停止が発生するリスクが大幅に軽減され、MTTF（平均故障時間）などの信頼性メトリクスの向上につながります。
パイプラインポリシーを設定して、パイプラインへのカオスエクスペリメントの挿入を義務付けることができます。
パイプラインを自動化し、ポリシーを通じてカバレッジを測定するには、製品を最もよく知っているチームメンバー、つまり開発者とQAチームメンバーによるカオスエクスペリメントの開発が義務付けられます。SREはこれらのエクスペリメントを使用して、運用グレードの環境を強化できます。これは、組織のカオスエンジニアリングの実践がレベル1からレベル4まで成熟する有機的なプロセスです。
カオスのパイプラインへの統合は、さまざまな方法で行うことができます。以下にいくつかのオプションを示します。
- システムのテストベッドまたはプリプロダクションにデプロイするデプロイメントパイプラインを選択し、変更のデプロイ後にカオスエクスペリメントスイートを実行。結果として得られるレジリエンススコアまたはレジリエンスカバレッジが満足のいくものでない場合は、パイプラインの手動検査と承認、または変更の自動ロールバックなどの適切なアクションを実行する。
- 新しい機能がプリプロダクションまたは本番環境にデプロイされるときに機能フラグをデプロイする機能フラグパイプラインを選択し、フラグが有効になっている環境でカオスエクスペリメントスイートを実行。結果として得られたレジリエンススコアまたはレジリエンスカバレッジが満足のいくものでない場合は、パイプラインの手動検査と承認、またはフラグの自動ロールバックなどの適切なアクションを実行する。
- コードを開発テスト環境にデプロイする開発パイプラインなど、最も低い環境に基本的なレジリエンステストを挿入するのが一般的。ただし、開発環境は最小限のサービス構成で維持されるため、レジリエンスカバレッジは低いことが予想される。
4. セキュアなカオスエクスペリメントオーケストレーション
カオスエクスペリメントは、サービスが予期せず停止した場合に望ましくない遅延を引き起こす可能性があるため、一般的に破壊的であると認識されています。例えば、誰かがカオスエクスペリメントを通じてQA環境内のKubernetesクラスターの全てのノードをダウンさせても弱点の発見には役立ちませんが、QAプロセスとそのタイムラインに多大な中断を引き起こす可能性があります。同様に、カオスエクスペリメントプロセスは必要なガードレールまたはセキュリティーガバナンスポリシーと関連付ける必要があります。
カオスエクスペリメントに関するセキュリティーガバナンスの例
・本番インフラストラクチャー1でのみノード障害を許可する
・午前9時から午後9時までの間、prod-2でネットワーク損失障害を許可しない
・管理者グループのみにノードの再起動の挿入を許可する
・ユーザーグループがqa-2インフラストラクチャーネットワーク障害を挿入することを許可しない
上記のようなセキュリティーガバナンスポリシーを使用すると、大規模なカオスエクスペリメントがより現実的になり、自動化によりレジリエンスカバレッジを拡大できます。
Harness Chaos Engineeringを始めましょう
Harness Chaos Engineeringは、カオスエンジニアリングのContinuous Resilienceアプローチをデプロイするために必要な上記の構成要素で構築されています。これには、すぐに使える多くの障害、セキュリティーガバナンス、ChaosHub、CDパイプラインや機能フラグと統合する機能などが付属しています。
Harness Chaos Engineeringのお問い合わせ
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。