ステージ 3: 評価とテスト

回復力のある基盤を構築しましたが、実際にはどのような仕組みになっているでしょうか。レジリエンステストは、製品市場に適合していることを証明するためにレースをしているときに、高級品のように聞こえる場合があります。ただし、この機能の開発を妨げずにこれを行うには、賢明な方法があります。この章では、スタートアップのペースに合ったリーンで実用的なテストについて説明します。

から始めてAWS Resilience Hub、それを初期アーキテクチャ評価ツールと見なします。アーキテクチャのレジリエンス基盤の有益なベースラインレビューを提供します。一般的な設定パターンと潜在的な単一障害点を確認することで、基本的なインフラストラクチャのセットアップが復旧目標と一致しているかどうかを評価するのに役立ちます。複数のアベイラビリティーゾーン設定の欠落やバックアップポリシーの不完全など、明らかなギャップにフラグを付けることができます。Resilience Hub は、慎重なアーキテクチャレビューと重要なパスのターゲットを絞ったテストを補完しますが、置き換えるものではありません。

文書化された復旧目標を検証するには、開発環境で AWS Backupで毎月の復元テストをスケジュールします。エンジニアリング時間が必要ですが、実際のインシデント中にバックアップが機能しないことを検出するよりも安い場合があります。ユニットテストの実行やコードレビューなど、通常の開発サイクルの一部にします。目標は完「完」ではなく、必要なときに回復できることを確信することです。

スタートアップが成長し、顧客が依存し始めるにつれて、テストゲームを段階的にレベルアップします。新機能をデプロイする場合は、パイプラインに基本的なレジリエンスチェックを含めます。を使用して簡単なカオス実験を試してくださいAWS Fault Injection Service。本番稼働前の環境で開始し、小規模で開始します。本番環境の実験を検討する前に、開発中の遅延した API レスポンスをアプリケーションがどのように処理するかをテストします。信頼度が高まったら、これらのテストを徐々に拡張しますが、常に本番稼働前に最初に検証してください。スタートアップにとって、本番環境でモノを壊すことは、意図的に壊すことなく十分にリスクがあります。

キーはバランスです。テストに費やされる 1 時間は、新機能の構築に費やされない 1 時間です。ただし、いくつかの戦略的テストにより、顧客の信頼を失うような停止を防ぐことができます。が提供する自動ツールを使用して、手間のかかる AWS 作業を行い、お客様にとって最も重要なテストに集中します。これにより、イノベーションを遅らせることなく、アプリケーションの耐障害性を信頼できます。

次の章では、スタートアップのスケールに応じてこの基盤を進化させる方法について説明します。