翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ステージ 2: 設計と実装
前のステージでは、耐障害性目標を設定しました。この「設計と実装」ステージでは、前のステージで設定した目標に従って障害モードを予測し、設計における選択肢を特定します。また、変更管理の戦略を定義し、ソフトウェアコードの作成とインフラストラクチャ設定を行います。以下のセクションでは、コスト、複雑さ、運用オーバーヘッドなどのトレードオフを考慮する際に検討する必要のある AWS のベストプラクティスについて説明します。
AWS Well-Architected フレームワーク
望ましい耐障害性目標に基づいてアプリケーションを設計する場合は、複数の要因を評価し、最適なアーキテクチャでトレードオフする必要があります。耐障害性に優れたアプリケーションを構築するには、設計、構築とデプロイ、セキュリティ、運用の各側面を考慮する必要があります。AWS Well-Architected フレームワーク
AWS Well-Architected フレームワークが耐障害性目標を達成するアプリケーションを設計および実装するのに役立つ方法の例を次に示します。
-
信頼性の柱: 信頼性の柱は、障害や中断が発生した場合でも、正しく一貫して動作できるアプリケーションを構築することの重要性を強調しています。例えば、AWS Well-Architected フレームワークでは、マイクロサービスアーキテクチャを使用してアプリケーションを小さくシンプルにすることをお勧めしています。これにより、アプリケーション内のさまざまなコンポーネントの可用性に対するニーズを区別できます。また、スロットリング、エクスポネンシャルバックオフによる再試行、フェイルファスト (負荷分散)、べき等性、定常作業、サーキットブレーカー、静的安定性を使用して、アプリケーションを構築するためのベストプラクティスに関する詳細な説明を検索することもできます。
-
包括的なレビュー: AWS Well-Architected フレームワークでは、ベストプラクティスと設計原則に照らしてアーキテクチャの包括的なレビューを行うことが推奨されています。このフレームワークでは、アーキテクチャを一貫して測定し、改善すべき分野を特定する方法を提供します。
-
リスク管理: AWS Well-Architected フレームワークは、アプリケーションの信頼性に影響を与える可能性のあるリスクの特定と管理に役立ちます。潜在的な障害シナリオに積極的に対処することで、障害の発生可能性や結果として生じる障害を減らすことができます。
-
継続的な改善: 耐障害性は継続的なプロセスであり、AWS Well-Architected フレームワークは継続的な改善を強調しています。AWS Well-Architected フレームワークのガイダンスに基づいてアーキテクチャとプロセスを定期的に見直し、改良することで、進化する課題や要件に直面してもシステムの耐障害性を維持できます。
依存関係について
システムの依存関係を理解することは、耐障害性にとって重要です。依存関係には、アプリケーション内のコンポーネント間の接続、およびサードパーティー API やビジネス所有の共有サービスなど、アプリケーション外のコンポーネントへの接続が含まれます。1 つのコンポーネントの障害が他のコンポーネントに影響を与える可能性があるため、これらの接続を理解すると、中断を分離して管理できるようになります。この知識は、エンジニアが障害の影響を評価し、それに応じて計画を立て、リソースを効果的に使用するのに役立ちます。依存関係を理解することで、代替戦略を作成し、復旧プロセスを調整できるようになります。また、ハード依存関係をソフト依存関係に置き換えることができるケースも特定できるため、依存関係に障害が発生した場合でもアプリケーションでビジネス機能の提供を継続することができます。依存関係は、負荷分散とアプリケーションのスケールの決定にも影響します。アプリケーションに変更を加えるときは、潜在的なリスクと影響を判断するのに役立つ依存関係について理解することが不可欠です。この知識は、安定した回復力のあるアプリケーションを作成し、障害管理、影響評価、障害復旧、負荷分散、スケール、変更管理を支援します。依存関係を手動で追跡することも、AWS X-Ray
ディザスタリカバリ戦略
ディザスタリカバリ (DR) 戦略は、主にビジネス継続性を確保することで、回復力のあるアプリケーションの構築と運用に重要な役割を果たします。これにより、壊滅的な事態の渦中であっても、重要な事業運営が最小限の障害で維持され、ダウンタイムと潜在的な収益損失を最小限に抑えることができます。DR 戦略はデータ保護に不可欠です。この戦略には複数の場所に及ぶ定期的なデータバックアップやデータレプリケーションが組み込まれていることが多いため、貴重なビジネス情報を保護し、災害発生時の全損状態を回避できます。さらに、多くの業界が、企業に機密データを保護し、災害発生時もサービスを確実に利用できるような DR 戦略を策定するよう求めるポリシーによって規制されています。サービスの障害を最小限に抑えることで、DR 戦略による顧客の信頼と満足度も向上します。適切に実装され、頻繁に実践される DR 戦略により、災害後の復旧時間を短縮し、アプリケーションを迅速にオンラインに戻すことができます。さらに、災害時は、ダウンタイムによる収益の損失だけでなく、アプリケーションとデータの復元に要する費用により、相当額のコストが発生する可能性があります。適切に設計された DR 戦略であれば、こうした財務上の損失から保護することができます。
選択する戦略は、アプリケーションの特定のニーズ、RTO と RPO、予算によって異なります。AWS Elastic Disaster Recovery
詳細については、AWS ウェブサイトの「Disaster Recovery of Workloads on AWS」および「AWS マルチリージョンの基礎」を参照してください。
CI/CD 戦略の定義
アプリケーション障害の一般的な原因の 1 つは、以前の既知の動作状態からアプリケーションを変更するコードやその他の変更です。変更管理に慎重に対処しないと、頻繁に障害が発生する可能性があります。変更の頻度が増えるにつれ、影響を及ぼす可能性も高くなります。ただし、変更の頻度を抑えると変更設定が多くなり、より複雑になることで障害が発生する可能性がはるかに高くなります。継続的インテグレーションと継続的デリバリー (CI/CD) のプラクティスは、変更を小規模かつ頻繁に保ち (生産性の向上につながります)、各変更を自動化することで高レベルの検査を受けるように設計されています。基本的な戦略には、次のようなものがあります。
-
フルオートメーション: CI/CD の基本的な概念は、できるだけ多くのビルドおよびデプロイプロセスを自動化することです。これには、構築、テスト、デプロイ、さらにはモニタリングが含まれます。自動パイプラインは、人為的ミスの可能性を減らし、一貫性を確保し、プロセスの信頼性と効率を高めるのに役立ちます。
-
テスト駆動型開発 (TDD): アプリケーションコードを記述する前にテストを記述します。この手法により、すべてのコードにテストが確実に関連付けられ、コードの信頼性と自動検査の品質が向上します。これらのテストは CI パイプラインで実行され、変更が検証されます。
-
頻繁なコミットと統合: 開発者がコードを頻繁にコミットし、頻繁に統合を実行することを推奨します。小規模で頻繁な変更はテストやデバッグが容易であり、重大な問題のリスクが軽減されます。自動化により各コミットやデプロイでのコストが削減され、頻繁な統合が可能になります。
-
イミュータブルインフラストラクチャ: サーバーやその他のインフラストラクチャコンポーネントを静的でイミュータブルなエンティティのように扱います。できるだけ多く変更するのではなく、インフラストラクチャを置き換え、パイプラインを通じてテストされデプロイされたコードを使用して新しいインフラストラクチャを構築します。
-
ロールバックメカニズム: 何か問題が発生した場合に変更をロールバックするには、常に簡単で信頼性が高く、頻繁にテストされた方法を使用します。以前の既知の正常な状態にすばやく戻ることは、デプロイの安全性にとって不可欠です。これは、前の状態に戻すシンプルなボタンでも、アラームによって完全に自動化および開始することもできます。
-
バージョン管理: すべてのアプリケーションコード、設定、インフラストラクチャをバージョン管理リポジトリのコードとして維持します。この方法により、変更を簡単に追跡し、必要に応じて元に戻すことができます。
-
Canary デプロイとブルー/グリーンデプロイ: アプリケーションの新しいバージョンを最初にインフラストラクチャのサブセットにデプロイするか、2 つの環境 (ブルー/グリーン) を維持することで、本番環境での変更の動作を検証し、必要に応じてすばやくロールバックできます。
CI/CD とは、ツールだけでなく文化にも関連します。自動化、テスト、障害からの学習を重視する文化を構築することは、適切なツールやプロセスを実装するのと同じくらい重要です。ロールバックが影響を最小限に抑えながら非常に迅速に行われた場合、失敗ではなく学習経験と考えるべきです。
ORR の実施
運用準備状況レビュー (ORR) は、運用と手続きのギャップを特定するのに役立ちます。Amazon では、何十年にもわたる大規模なサービスを運用してきた教訓を、ベストプラクティスガイダンスによる厳選された質問に抽出するための ORR を作成しました。ORR では、以前に学んだ教訓を取り込み、新しいチームがアプリケーションでこれらの教訓を考慮できるようにします。ORR では、以下の耐障害性モデリングセクションで説明されている耐障害性モデリングアクティビティで実行できる障害モードまたは障害の原因のリストを提供することができます。詳細については、AWS Well-Architected フレームワークウェブサイトの「Operational Readiness Reviews (ORR)」を参照してください。
AWS 障害分離境界について
AWS では、耐障害性目標の達成に役立つ複数の障害分離境界を提供しています。これらの境界を使用して、指定された影響抑制の予測可能な範囲を活用できます。アプリケーションに選択した依存関係について意図的に選択できるように、これらの境界を使用して AWS サービスがどのように設計されるかを理解しておく必要があります。アプリケーションで境界を使用する方法については、AWS ウェブサイトの「AWS 障害分離境界」を参照してください。
応答方法の選択
システムは、アラームにさまざまな方法で応答できます。アラームの中には、運用チームからの応答を必要とするものもあれば、アプリケーション内で自己修復メカニズムをトリガーするものもあります。自動化のコストを制御したり、エンジニアリングの制約を管理したりするために、自動化できる応答を手動操作として維持する場合があります。アラームに対する応答のタイプは、応答の実装コスト、アラームの予想される頻度、アラームの精度、およびアラームにまったく応答しないことによる潜在的なビジネス損失の 1 つの機能として選択される可能性があります。
例えば、サーバープロセスがクラッシュすると、プロセスはオペレーティングシステムによって再起動されるか、新しいサーバーがプロビジョニングされて古いサーバーが終了するか、オペレーターがサーバーにリモート接続して再起動するよう指示される場合があります。これらの応答は同じ結果 (アプリケーションサーバープロセスを再開する) になりますが、実装コストとメンテナンスコストのレベルは異なります。
注記
複数の応答を選択して、詳細な耐障害性アプローチを取ることができます。例えば、前のシナリオでは、アプリケーションチームが 3 つの応答すべてを実装し、それぞれの間に時間遅延を設けることを選択できます。失敗したサーバープロセスインジケータが 30 秒後もアラーム状態のままである場合、チームはオペレーティングシステムがアプリケーションサーバーの再起動に失敗したと見なすことができます。したがって、Auto Scaling グループを作成して新しい仮想サーバーを作成し、アプリケーションサーバープロセスを復元できます。インジケータが 300 秒経過してもアラーム状態のままである場合、元のサーバーに接続してプロセスの復元を試みるために、アラートが運用スタッフに送信されることがあります。
アプリケーションチームとビジネスが選択する応答には、運用上のオーバーヘッドをエンジニアリング時間への先行投資で相殺するというビジネスの需要を反映する必要があります。応答 (静的安定性などのアーキテクチャパターン、サーキットブレーカーなどのソフトウェアパターン、または運用手順) を選択する際は、各応答オプションの制約と予想されるメンテナンスを慎重に検討する必要があります。アプリケーションチームをガイドするための標準的な応答がいくつか存在する場合があるため、一元化されたアーキテクチャ機能によって管理されるライブラリとパターンを、この考慮事項への入力として使用できます。
耐障害性モデリング
耐障害性モデリングでは、アプリケーションが予想されるさまざまな中断に対応する方法を文書化します。 中断を予測することで、チームはオブザーバビリティ、自動コントロール、復旧プロセスを実装し、中断しても障害を軽減または防止できます。AWS では、耐障害性分析フレームワークを使用して耐障害性モデルを開発するためのガイダンスを作成しました。 このフレームワークは、中断とそれによるアプリケーションへの影響を予測するのに役立ちます。 中断を予測することで、回復力のある信頼性の高いアプリケーションを構築するために必要な軽減策を特定できます。耐障害性分析フレームワークを使用して、アプリケーションのライフサイクルを反復するたびに耐障害性モデルを更新することをお勧めします。 このフレームワークを反復する度に使用すると、設計フェーズ中に中断を予測し、本番環境のデプロイ前後にアプリケーションをテストしてインシデントを減らすことができます。このフレームワークを使用して耐障害性モデルを開発することで、耐障害性目標を達成できます。
安全に失敗する
中断を回避できない場合は、安全に失敗しましょう。重大なビジネス損失が発生しない、デフォルトのフェイルセーフなオペレーションモードでアプリケーションを作成することを検討してください。データベースのフェイルセーフ状態の例としては、デフォルトで読み取り専用操作があり、ユーザーはデータを作成または変更できません。データの機密性によっては、アプリケーションをデフォルトでシャットダウン状態にし、読み取り専用クエリを実行しないようにすることもできます。アプリケーションに必要なフェイルセーフ状態を考慮してください。極端な条件下では、デフォルトでこのオペレーションモードになります。
