View a markdown version of this page

ステージ 2: 設計と実装 - AWS 規範ガイダンス

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

ステージ 2: 設計と実装

このセクションでは、レジリエンス目標の実現について説明します。ビジネスにとって最も重要なものをマッピングし、構築する時が来ました。イノベーションを遅らせずにレジリエンスを高めるにはどうすればよいですか?

AWS マネージドサービスをレジリエンスショートカットと考える。インフラストラクチャを維持する貴重なエンジニアリング時間を消費するのではなく、冗長性を処理するサービスを使用してください。例えば、Amazon Simple Storage Service (Amazon S3) を考えてみましょう。耐久性 AWS リージョン のために、データの複数のコピーを に自動的に保存します。追加のコードや深夜のページャーの義務は必要ありません。

コアアプリケーションコンポーネントについてはどうですか? 賢明な選択は、チームの影響を倍増させる可能性があります。サービスのバックボーンであるデータベースを考えてみましょう。独自のレプリケーションシステムを構築する代わりに、フェイルオーバーを自動的に処理する Amazon Aurora の使用を検討してください。これらの機能にはコストがかかる場合がありますが、チームの焦点はインフラストラクチャの維持からビジネス上の問題の解決にシフトします。このコストは、機能配信を高速化し、停止中の収益損失を回避することで相殺できます。

スタートアップはカスタムソリューションを構築する必要がある場合があります。これが革新的なスタートアップの本質です。これを行うときは、シンプルでありながらスマートに保ちます。Elastic Load Balancing グループと Amazon EC2 Auto Scaling グループを使用して、アプリケーションを複数のアベイラビリティーゾーンに分散します。1 つのアベイラビリティーゾーンに障害が発生した場合でも、ベースライントラフィックを処理するように Auto Scaling グループの最小容量を設定します。これにより、複雑なアーキテクチャパターンなしで、ローカライズされた障害に対する回復力が得られます。スタートアップが成長し、顧客がより高いレジリエンスを要求するにつれて、より高度なアプローチに進化できます。

本番稼働環境と開発環境は別々の にしておくことをお勧めします AWS アカウント。動きが速いときはそれらを混在させようとしていますが、この境界はセーフティネットです。これにより、優れた意味を持つ実験が本番稼働用サービスを停止するのを防ぐことができます。これを「高速で物事を壊す」開発文化の保険と考える - 開発中の物事を壊し、生産を安定させる。

アプリケーションがサードパーティーのサービスに依存している場合は、障害に備えてください。支払いプロセッサに問題がある場合、システムは問題を適切に処理できますか? シンプルなサーキットブレーカーとフォールバックオプションを構築します。エラーメッセージを表示する代わりに、これらのトランザクションをキューに入れることができます。顧客は、完全にはなくても、物事を機能させ続けたことに感謝します。

構築時に文書化しますが、実用性を維持します。重要な決定の背後にある理由の記録に集中し、簡単な復旧プレイブックを作成します。インシデントが発生した場合は、これらを準備することが重要です。

完全なレジリエンスのために構築しているわけではなく、適切なレジリエンスのために構築しているわけです。オーバーエンジニアリングレジリエンスに費やされる 1 時間ごとに、顧客が求める機能に費やされない 1 時間です。 AWS マネージドサービスを基盤として使用し、最も重要な場所にターゲットを絞ったレジリエンスを追加し、ビジネスの成長に合わせてレジリエンスをスケールアップするための明確なパスを作成します。

次の章では、エンジニアリングリソースを消費せずにこれらの設計選択肢を検証する方法について説明します。スタートアップ企業にとって、テストは合理的な向上であり、アプリケーションの耐障害性に対する賢明な投資でなければなりません。