ワークロードの回復力のテスト

失敗のシナリオ

テストを実施するには、テスト対象のさまざまな障害シナリオを定義し、文書化する必要がある。 アプリケーション設計の一部として障害シナリオを検討することは、良い習慣であり、初日からアプリケーションアーキテクチャに弾力性を組み込むことができる。 最初に失敗シナリオを定義するときは、範囲を広くとるようにする。 技術チームメンバーとエンドユーザーの両方と一緒に、ビジネス・ワークショップでリストを作成することが役立ちます。

広い範囲から始めるのは良いが、シナリオが実現する可能性も考慮すること。 例えば、ワークショップの参加者は、エイリアンの宇宙船がレーザーボルトでデータセンターを破壊することを問題視するかもしれない。 大きな損害や停電を引き起こす可能性はあるが、実際に発生する可能性は非常に低い。 だから、まだ偏向シールドを作る必要はあまりないと、グループを説得できるはずだ！ 軽薄な例ではあるが、これにはもう一つポイントがある。偏向シールドも、設計、開発、テストに多額の費用がかかるかもしれない。 障害シナリオを設計する際に問うべき重要な質問のひとつは、 ワークロードをオフラインから守るために費やす金額は現実的か、ということだ。 保護にかかるコストとワークロード障害にかかるコストとの間で、御社のビジネスにとって適切なバランスを取ることが重要です。 潜在的な災害の発生から起こりうるリスクを計量することは、ここで役立つ。

テスト環境

失敗シナリオを文書化したら、次のステップはテストだ。 IBM Cloud、常に別のテストアカウント、別のテスト環境を作成することがベストプラクティスです。 別のアカウントテストを実施することで、すべてのテストが確実に行われ、誤って本番環境に影響を与えることがなく、他の環境を混乱から守ることができます。 また、テストに関連するコストを分離することで、ビジネスにおける請求書作成時に費目を分けることができます。

手始めに、テストが必要な環境の数と種類の計画を立て、戦略を文書化する。 コストや計画されているテストの数や種類によって、適切な環境にはいくつかの形態がある。 スケールの一端では、恒久的なミラー生産が可能だ。 もう一方では、主要なコンポーネントだけを含むようにスケーリングされたデプロイ・オンデマンド環境を使用することもできる。 あるいは、その中間かもしれない。 どのテスト環境を使用するにしても、実施するテストの種類と、それが影響する可能性のあるワークロードの部分を考慮し、有意義な結果が得られることを確認してください。 そして、定期的にテストのアーキテクチャと戦略を見直し、本番環境からコンフィギュレーションが逸脱しないようにすること。 理想的には、CI/CDパイプラインを使ってこれを自動化できる。

テスト方法

回復力をどのようにテストするかを決定することは、パズルの最も難しい部分のひとつである。 フォールト・インジェクション」とも呼ばれるように、各テストシナリオには、どのように障害を導入し、必要に応じてどのように修正するかを詳述した手順を文書化する必要がある。

環境にフォールトを注入する方法の1つは、コンフィギュレーションの変更である。 たとえば、アクセス・コントロール・リストやセキュリティ・グループ構成の変更により、仮想プライベート・クラウドの接続性の問題がシミュレートされる可能性があります。 また、IAMを通じてコンポーネントへのアクセスを変更することで、停電をシミュレートすることもできる。 もちろん、 IBM Cloud、コード内で変更を自動化するために使用できるAPIがあり、環境内で故意に障害を引き起こすために使用することもできる。 アンチパターンであることは間違いないが、APIの意図する動作を理解すれば、適切に環境を設定するだけでなく、環境を「壊す」ためにAPIを使うことも可能だ。 APIを使用している場合、スクリプトを作成し、パイプラインの一部として自動または手動で実行することができる。 断続的な故障は、継続的な破損と修理によってシミュレートすることができる。 スクリプトはソース管理された環境に置いてください。

テスト、特にカオス工学に関する詳しい情報は、 カオステストと ゾーン障害カオス実験の実行を 参照。