信頼性をテストする - 信頼性の柱

信頼性をテストする

本番環境のストレスに耐えられるようにワークロードを設計した後、ワークロードが意図したとおりに動作し、期待する弾力性を実現することを確認する唯一の方法が、テストを行うことです。

バグまたはパフォーマンスのボトルネックがワークロードの信頼性に影響を与える可能性があるため、ワークロードが機能の要件と機能以外の要件を満たしていることを検証するためにテストします。ワークロードの弾⼒性をテストして、本番環境でしか表面化しない潜在的なバグを見つけられるようにします。このようなテストを定期的に行います。

プレイブックを使用して失敗を調査する: 調査プロセスをプレイブックに文書化することで、よく理解されていない障害シナリオに対する一貫性のある迅速な対応が可能になります。プレイブックは、障害シナリオの原因となる要因を特定するために実行される事前定義されたステップです。プロセスステップの結果は、問題が特定されるか、エスカレーションされるまで、次のステップを決定するために使用されます。

このプレイブックは、事後的な行動を効果的に実行できるようにするために立てる必要がある予防的な計画です。本番環境でプレイブックに含まれていない障害シナリオが発生した場合は、まず問題に対処します (火を消します)。その後、振り返って問題に対処するために実行した手順を見て、これらの手順を用いてプレイブックに新しいエントリを追加します。

プレイブックは特定のインシデントに対応するために用いられる一方、ランブックは特定の結果を達成するために使用されます。多くの場合、ランブックは日常的なアクティビティに用いられる一方、プレイブックは非日常的なイベントに応えるために使用します。

インシデント後の分析を実行する: 顧客に影響を与えるイベントを確認し、寄与する要因と予防措置を特定します。この情報を使用して、再発を制限または回避するための緩和策を開発します。迅速で効果的な対応のための手順を開発します。対象者に合わせて調整された、寄与因子と是正措置を必要に応じて伝えます。

既存のテストで問題が見つからなかった理由を評価します。テストがまだ存在しない場合は、このケースのテストを追加します。

機能要件をテストする: これには、必要な機能を検証する単体テストと統合テストが含まれます。

これらのテストがビルドおよびデプロイアクションの一部として自動的に実行されると、最良の結果が得られます。例えば、デベロッパーは AWS CodePipeline を使用して、CodePipeline が変更を自動的に検出するソースリポジトリに変更をコミットします。このような変更が構築されたら、テストが実行されます。テストが完了すると、ビルドされたコードがテストのためステージングサーバーにデプロイされます。CodePipeline はステージングサーバーから統合テストや負荷テストなど、より多くのテストを実行します。これらのテストが正常に完了すると、CodePipeline はテストおよび承認されたコードを本番稼働インスタンスにデプロイします。

さらに、顧客の行動を実行およびシミュレートできる合成トランザクションテスト (「Canary テスト」とも呼ばれますが、Canary デプロイと混同しないでください) は、最も重要なテストプロセスの 1 つであることが経験からわかっています。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。Amazon CloudWatch Synthetics を使用すると、 Canary を作成して エンドポイントと API をモニタリングできます。

スケーリングおよびパフォーマンス要件をテストする: これには、ワークロードがスケーリングとパフォーマンスの要件を満たしていることを検証するための負荷テストが含まれます。

クラウドでは、ワークロードに合わせて、本番稼働働規模のテスト環境を作成できます。スケールダウンしたインフラストラクチャでこれらのテストを実行する場合、観測された結果を、本番環境で予想される事態にスケーリングする必要があります。実際のユーザーに影響を与えないように注意する場合は、本番環境でも負荷テストとパフォーマンステストを行います。その際、実際のユーザーデータと混合したり、使用統計や本番レポートを破損しないないようにテストデータにタグを付けます。

テストでは、ベースリソース、スケーリング設定、サービスクォータ、および弾力性設計が負荷がかかる時に想定どおりに動作することを確認します。

カオスエンジニアリングを使用して回復力をテストする: 本番稼働前および本番稼働環境に定期的に障害を挿入してテストを実行します。ワークロードが障害にどのように反応するかの仮説を立て、その仮説をテスト結果と比較して、一致しない場合はプロセスを繰り返します。本番稼働テストがユーザーに影響を与えないようにします。

クラウドでは、どのようにシステム障害が発生するかをテストでき、復旧の手順も検証できます。オートメーションにより、さまざまな障害のシミュレーションや過去の障害シナリオの再現を行うことができます。これにより、実際の障害シナリオが発生する前にテストおよび修正できる障害経路が明らかになるため、リスクが軽減されます。

カオスエンジニアリングは、本番での乱れ条件に耐えるシステムの能力の信頼性を確立するためにシステム上で実験を行う場合の規律です。– カオスエンジニアリングの原則

本番稼働前の環境とテスト環境では、カオスエンジニアリングを定期的に実行し、CI/CD サイクルの一部にする必要があります。本番環境では、チームは可用性を中断しないように注意する必要があり、 ゲームデーを 本番環境におけるカオスエンジニアリングのリスクを制御する方法として使用します。

テストの取り組みは可用性の目標に見合ったものにする必要があります。可用性の目標を達成するためにテストを実施することこそが、目標達成の信頼性を高める唯一の方法です。

ワークロードが障害に対する弾力性を持てるように設計したコンポーネントの障害をテストします。これには、EC2 インスタンスの損失、プライマリ Amazon RDS データベースインスタンスの障害、アベイラビリティーゾーンの停止などがあります。

外部依存関係が利用できないかテストします。依存関係にあるシステムの一時的な障害に対するワークロードの弾力性を、1 秒未満から数時間までの継続時間でテストする必要があります。

その他のサービス品質劣化のパターンでは、機能が低下して応答が遅くなり、サービスが停止することがよくあります。このパフォーマンス低下の一般的な原因は、主要サービスのレイテンシー増加と、信頼性の低いネットワーク通信 (パケットのドロップ) です。ネットワークへの影響 (遅延やメッセージのドロップなど)、DNS 障害 (名前を解決できない、依存サービスへの接続を確立できないなど) などの障害をシステムに挿入する機能を活用することも可能です。

障害を挿入するためのサードパーティオプションがいくつかあります。これには、次のようなオープンソースオプションが含まれます。 Netflix Chaos MonkeyChaos ToolKit、および Shopify Toxiproxyまたは、次のような商用オプションがあります。 Gremlin。カオスエンジニアリングの実装方法の初期調査では、自己作成のスクリプトを使用することをお勧めします。これにより、エンジニアリングチームはワークロードにどのようにしてカオスが導入されるかを理解できます。これらの例については次を参照してください。 EC2 RDS および S3 の弾力性のテストに Bash、Python、Java、PowerShell などの複数の言語を使用します。また、実装する際に AWS Systems Manager を使用して Amazon EC2 にカオスを挿入します。これにより、AWS Systems Manager ドキュメントを使用してブラウズアウトと高 CPU 状態をシミュレートできます。

定期的にゲームデーを実施する: ゲームデーを使用して、実際の障害シナリオに関わる人々と、可能な限り本番環境に近い環境 (本番環境を含む) で障害対処手順を実行します。ゲームデーでは、本番環境のテストがユーザーに影響を与えないようにするための対策を講じます。

ゲームデーを定期的にスケジュールして、本稼働環境のイベントをシミュレートすることで、アーキテクチャとプロセスのパフォーマンスをテストします。これは、改善可能な箇所を把握したり、イベントに対応する体験を組織的に醸成するのに役立ちます。

弾力性を考慮した設計が整い、本番環境以外の環境でテストした後、本番環境ですべてが計画どおりに機能することを確認するのがゲームデーです。ゲームデー、特に初日は、「全員が総力を挙げた」取り組みです。いつ起こるか、そして何が起こるかについてエンジニアと運用担当者に通知します。プレイブックを用意します。次に、障害が所定の方法で本番システムに注入され、影響を評価します。すべてのシステムが設計どおりに動作すると、検出と自己修復が行われ、影響はほとんどありません。ただし、負の影響が観察された場合、テストはロールバックされ、ワークロードの問題は必要に応じて (プレイブックを参照して) 手動で修正します。ゲームデーは本番環境で行われるため、顧客の可用性に影響を与えないように期すために、あらゆる予防策を講じる必要があります。