ステージ 2: 設計と実装

前のステージでは、回復力目標を設定します。設計と実装の段階では、前のステージで設定した目標に従って、障害モードを予測し、設計上の選択肢を特定しようとします。また、変更管理の戦略を定義し、ソフトウェアコードとインフラストラクチャ設定を開発します。以下のセクションでは、コスト、複雑さ、運用上のオーバーヘッドなどのトレードオフを考慮する際に考慮すべき AWS ベストプラクティスについて説明します。

AWS Well-Architected フレームワーク

希望するレジリエンス目標に基づいてアプリケーションを設計するときは、複数の要因を評価し、最適なアーキテクチャでトレードオフを行う必要があります。回復力の高いアプリケーションを構築するには、設計、構築とデプロイ、セキュリティ、運用の側面を考慮する必要があります。AWS Well-Architected フレームワークは、 で回復力のあるアプリケーションを設計するのに役立つ一連のベストプラクティス、設計原則、アーキテクチャパターンを提供します AWS。 AWS Well-Architected フレームワークの 6 つの柱は、回復力、安全性、効率、費用対効果、持続可能なシステムを設計および運用するためのベストプラクティスを提供します。このフレームワークは、ベストプラクティスに照らしてアーキテクチャを一貫して測定し、改善すべき分野を特定する方法を提供します。

AWS Well-Architected フレームワークがレジリエンス目標を達成するアプリケーションの設計と実装にどのように役立つかの例を次に示します。

• 信頼性の柱: 信頼性の柱は、障害や中断が発生した場合でも、正しく一貫して動作できるアプリケーションを構築することの重要性を強調しています。例えば、 AWS Well-Architected Framework では、マイクロサービスアーキテクチャを使用してアプリケーションを小さくてシンプルにすることをお勧めします。これにより、アプリケーション内のさまざまなコンポーネントの可用性のニーズを区別できます。また、スロットリング、エクスポネンシャルバックオフによる再試行、フェイルファスト (負荷分散）、冪等性、定常作業、サーキットブレーカー、静的安定性を使用してアプリケーションを構築するためのベストプラクティスの詳細な説明も参照できます。

• 包括的なレビュー: AWS Well-Architected フレームワークは、ベストプラクティスと設計原則に照らしてアーキテクチャの包括的なレビューを推奨します。アーキテクチャを一貫して測定し、改善すべき分野を特定する方法を提供します。

• リスク管理: AWS Well-Architected フレームワークは、アプリケーションの信頼性に影響を与える可能性のあるリスクの特定と管理に役立ちます。潜在的な障害シナリオに事前に対処することで、障害の可能性やその結果生じる障害を減らすことができます。

• 継続的改善: レジリエンスは継続的なプロセスであり、 AWS Well-Architected Framework は継続的改善を強調しています。 AWS Well-Architected Framework のガイダンスに基づいてアーキテクチャとプロセスを定期的に見直して改善することで、変化する課題や要件に直面してもシステムの耐障害性を維持できます。

依存関係について

システムの依存関係を理解することは、回復力の鍵です。依存関係には、アプリケーション内のコンポーネント間の接続、およびサードパーティー APIs やビジネス所有の共有サービスなど、アプリケーション外のコンポーネントへの接続が含まれます。これらの接続を理解すると、1 つのコンポーネントの障害が他のコンポーネントに影響を与える可能性があるため、中断を分離して管理できます。この知識は、エンジニアが障害の影響を評価し、それに応じて計画を立て、リソースを効果的に使用するのに役立ちます。依存関係を理解することは、代替戦略を作成し、復旧プロセスを調整するのに役立ちます。また、ハード依存関係をソフト依存関係に置き換えることができるケースを特定するのにも役立ちます。これにより、依存関係に障害が発生した場合でもアプリケーションは引き続きビジネス機能を提供できます。依存関係は、負荷分散とアプリケーションのスケーリングに関する決定にも影響します。アプリケーションに変更を加えるときは、潜在的なリスクと影響を判断するのに役立つため、依存関係を理解することが不可欠です。この知識は、障害管理、影響評価、障害対策、負荷分散、スケーリング、変更管理を支援し、安定した回復力のあるアプリケーションを作成するのに役立ちます。依存関係を手動で追跡することも、 などのツールやサービスを使用して分散アプリケーションの依存関係AWS X-Rayを把握することもできます。

ディザスタリカバリ戦略

ディザスタリカバリ (DR) 戦略は、主にビジネス継続性を確保することで、回復力のあるアプリケーションの構築と運用に重要な役割を果たします。これにより、致命的なイベント中であっても、重要な事業運営が可能な限り最小限の障害で存続できることが保証され、ダウンタイムと収益の損失を最小限に抑えることができます。DR 戦略はデータ保護に不可欠です。多くの場合、複数の場所にまたがる定期的なデータバックアップとデータレプリケーションが組み込まれているため、貴重なビジネス情報を保護し、災害発生時の完全な損失を防ぐのに役立ちます。さらに、多くの業界は、企業が機密データを保護し、災害発生時にサービスを確実に利用できるように DR 戦略を立てることを要求するポリシーによって規制されています。DR 戦略は、最小限のサービス障害を保証することで、顧客の信頼と満足度も強化します。適切に実装され、頻繁に実施されている DR 戦略により、ディザスタ後の復旧時間が短縮され、アプリケーションが迅速にオンラインに戻されます。さらに、災害は、ダウンタイムによる収益の損失だけでなく、アプリケーションとデータの復元のコストからも、かなりのコストが発生する可能性があります。適切に設計された DR 戦略は、これらの財務上の損失を防ぐのに役立ちます。

選択する戦略は、アプリケーションの特定のニーズ、RTO と RPO、予算によって異なります。 AWS Elastic Disaster Recoveryは、オンプレミスとクラウドベースのアプリケーションの両方に DR 戦略を実装するために使用できる専用のレジリエンスサービスです。

詳細については、 AWS ウェブサイトの「 でのワークロードのディザスタリカバリ AWS」およびAWS 「マルチリージョンの基礎」を参照してください。

CI/CD 戦略の定義

アプリケーションの障害の一般的な原因の 1 つは、アプリケーションが以前既知の動作状態から変化するコードやその他の変更です。変更管理に慎重に対処しないと、頻繁に障害が発生する可能性があります。変更の頻度は、影響の可能性を高めます。ただし、変更の頻度が低いほど変更セットが大きくなり、複雑さが高いために障害が発生する可能性がはるかに高くなります。継続的インテグレーションと継続的デリバリー (CI/CD) のプラクティスは、変更を小規模かつ頻繁に保ち (生産性の向上につながります）、各変更を自動化することで高レベルの検査を受けるように設計されています。基本的な戦略には、次のようなものがあります。

• 完全自動化: CI/CD の基本的な概念は、ビルドとデプロイプロセスを可能な限り自動化することです。これには、構築、テスト、デプロイ、さらにはモニタリングが含まれます。自動パイプラインは、人為的ミスの可能性を減らし、一貫性を確保し、プロセスの信頼性と効率を高めるのに役立ちます。

• テスト駆動型開発 (TDD): アプリケーションコードを記述する前にテストを記述します。この手法により、すべてのコードに関連するテストが行われるため、コードの信頼性と自動検査の品質が向上します。これらのテストは CI パイプラインで実行され、変更を検証します。

• 頻繁なコミットと統合: デベロッパーにコードを頻繁にコミットし、頻繁に統合を実行するよう促します。小規模で頻繁な変更では、テストとデバッグが容易になり、重大な問題のリスクが軽減されます。自動化により、各コミットとデプロイのコストを削減できるため、頻繁な統合が可能になります。

• イミュータブルインフラストラクチャ: サーバーやその他のインフラストラクチャコンポーネントを静的でイミュータブルなエンティティのように扱います。インフラストラクチャをできるだけ変更するのではなく置き換え、テストされ、パイプラインを通じてデプロイされるコードを使用して新しいインフラストラクチャを構築します。

• ロールバックメカニズム : 何か問題が発生した場合に変更をロールバックするには、常に簡単で信頼性が高く、頻繁にテストされた方法があります。デプロイの安全性を保つには、以前の既知の正常な状態にすばやく戻ることが重要です。これは、前の状態に戻すシンプルなボタンでも、アラームによって完全に自動化および開始することもできます。

• バージョン管理： すべてのアプリケーションコード、設定、インフラストラクチャをバージョン管理されたリポジトリ内のコードとして維持します。この方法により、変更を簡単に追跡し、必要に応じて元に戻すことができます。

• Canary デプロイとブルー/グリーンデプロイ: アプリケーションの新しいバージョンをインフラストラクチャのサブセットに最初にデプロイするか、2 つの環境 (ブルー/グリーン) を維持すると、本番環境での変更の動作を検証し、必要に応じて迅速にロールバックできます。

CI/CD は、ツールだけでなく、文化に関するものです。自動化、テスト、障害からの学習を重視する文化の構築は、適切なツールやプロセスを実装するのと同じくらい重要です。ロールバックは、影響を最小限に抑えて非常に迅速に行われる場合、失敗ではなく、学習エクスペリエンスと見なす必要があります。

ORRs の実行

運用準備状況レビュー (ORR) は、運用と手順のギャップを特定するのに役立ちます。Amazon では、何十年もの大規模なサービスを運用してきたことから学んだことを、ベストプラクティスガイダンスによる厳選された質問に絞り込むための ORRs を作成しました。ORR は、以前に学習した教訓をキャプチャし、新しいチームがこれらの教訓をアプリケーションで考慮していることを確認する必要があります。ORRsは、以下の耐障害性モデリングセクションで説明されている耐障害性モデリングアクティビティに実行できる障害モードまたは障害の原因のリストを提供することができます。詳細については、 AWS Well-Architected Framework ウェブサイトの「Operational Readiness Reviews (ORRs )」を参照してください。

AWS 障害分離の境界について

AWS は、耐障害性目標を達成するために複数の障害分離境界を提供します。これらの境界を使用して、それらが提供する影響抑制の予測可能な範囲を活用できます。アプリケーションに選択した依存関係を意図的に選択できるように、これらの境界を使用して AWS サービスがどのように設計されるかを理解しておく必要があります。アプリケーションで境界を使用する方法については、 ウェブサイトのAWS 「障害分離境界 」を参照してください。 AWS

レスポンスの選択

システムは、アラームにさまざまな方法で応答できます。アラームによっては、運用チームからの応答が必要な場合がありますが、アプリケーション内で自己修復メカニズムをトリガーするアラームもあります。自動化のコストを制御したり、エンジニアリングの制約を管理したりするために、手動操作として自動化できるレスポンスを保持しておくこともできます。アラームに対する応答のタイプは、応答を実装するコスト、アラームの予想される頻度、アラームの精度、およびアラームにまったく応答しない潜在的なビジネス損失の関数として選択される可能性があります。

例えば、サーバープロセスがクラッシュすると、オペレーティングシステムによってプロセスが再起動されたり、新しいサーバーがプロビジョニングされて古いサーバーが終了したり、オペレーターにサーバーにリモート接続して再起動するように指示されたりすることがあります。これらのレスポンスは、アプリケーションサーバープロセスを再開するのと同じ結果になりますが、実装コストとメンテナンスコストのレベルは異なります。

注記

詳細なレジリエンスアプローチを取るために、複数のレスポンスを選択できます。例えば、前のシナリオでは、アプリケーションチームは 3 つのレスポンスすべてを実装し、それぞれに時間遅延を持たせることを選択できます。失敗サーバープロセスインジケータが 30 秒後にアラーム状態のままである場合、チームはオペレーティングシステムがアプリケーションサーバーの再起動に失敗したと想定できます。したがって、新しい仮想サーバーを作成し、アプリケーションサーバープロセスを復元する Auto Scaling グループを作成する場合があります。インジケータが 300 秒経過してもアラーム状態のままである場合、元のサーバーに接続してプロセスを復元しようとするアラートが運用スタッフに送信されることがあります。

アプリケーションチームとビジネスが選択する対応には、運用上のオーバーヘッドとエンジニアリング時間への先行投資を相殺するというビジネスの需要を反映する必要があります。各応答オプションの制約と予想されるメンテナンスを慎重に検討して、応答、静的安定性などのアーキテクチャパターン、サーキットブレーカーなどのソフトウェアパターン、または運用手順を選択する必要があります。アプリケーションチームを導き出すための標準的なレスポンスがいくつか存在する場合があるため、一元化されたアーキテクチャ機能によって管理されるライブラリとパターンをこの考慮事項への入力として使用できます。

耐障害性モデリング

耐障害性モデリングは、アプリケーションが予想されるさまざまな中断にどのように対応するかを文書化します。  中断を予測することで、チームはオブザーバビリティ、自動コントロール、復旧プロセスを実装して、中断しても障害を軽減または防止できます。 AWS は、レジリエンス分析フレームワーク を使用してレジリエンスモデルを開発するためのガイダンスを作成しました。  このフレームワークは、中断とそのアプリケーションへの影響を予測するのに役立ちます。  中断を予測することで、回復力のある信頼性の高いアプリケーションを構築するために必要な緩和策を特定できます。アプリケーションのライフサイクルを繰り返すたびに回復力モデルを更新するために、回復力分析フレームワークを使用することをお勧めします。  このフレームワークを反復するたびに使用すると、設計段階で中断を予測し、本番デプロイの前後にアプリケーションをテストすることで、インシデントを減らすことができます。このフレームワークを使用して回復性モデルを開発することで、回復力の目標を達成できます。

安全に失敗する

中断を回避できない場合は、安全に失敗してください。ビジネスに大きな損失が発生しないデフォルトのフェイルセーフなオペレーションモードでアプリケーションを作成することを検討してください。データベースのフェイルセーフ状態の例としては、デフォルトで読み取り専用オペレーションがあり、ユーザーはデータを作成または変更できません。データの機密性によっては、アプリケーションをデフォルトでシャットダウン状態にし、読み取り専用クエリを実行しないようにすることもできます。アプリケーションのフェイルセーフ状態を検討し、極端な条件下ではデフォルトでこのオペレーションモードに設定します。