翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステージ 2: 設計と実装

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

AWS Well-Architected フレームワーク

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

以下は、 AWS Well-Architected フレームワークが耐障害性の目的を達成するアプリケーションを設計および実装するのに役立つ方法の例です。

依存関係について

システムの依存関係を理解することは、レジリエンスにとって重要です。依存関係には、アプリケーション内のコンポーネント間の接続、およびサードパーティー 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 とは、ツールだけでなく文化に関するものです。自動化、テスト、障害からの学習を重視する文化を構築することは、適切なツールやプロセスを実装するのと同じくらい重要です。ロールバックは、影響を最小限に抑えて非常に迅速に行われる場合、失敗ではなく学習経験と考えるべきです。

ORRs の実行

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

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

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

レスポンスの選択

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

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

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

耐障害性モデリング

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

安全に失敗する

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