コンポーネントの障害に耐えられるようにワークロードを設計する - 信頼性の柱

コンポーネントの障害に耐えられるようにワークロードを設計する

高い可用性と低い平均復旧時間 (MTTR) の要件を持つワークロードは、回復力を考慮した設計をする必要があります。

ワークロードのすべてのコンポーネントをモニタリングしてエラーを検知する: ワークロードの状態を継続的にモニタリングすることで、お客様と自動化システムがパフォーマンスの低下または完全な障害の発生を速やかに把握できるようにします。ビジネス価値に基づいて重要業績評価指標 (KPI) をモニタリングします。

復旧および修復メカニズムはすべて、問題を迅速に検出する機能から開始する必要があります。技術的な障害を最初に検出して、解決できるようにするのです。ただし、可用性はワークロードがビジネス価値を提供する能力に基づいているため、その能力が検出および修正戦略の主要な指標である必要があります。

正常なリソースにフェイルオーバーする: リソース障害の発生時に、正常なリソースが引き続きリクエストに対応できるようにします。ロケーション障害 (アベイラビリティーゾーンや AWS リージョンなどにおける障害) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。

これは、個別のリソースの障害 (EC2 インスタンスなど) や、マルチ AZ ワークロードの 1 つのアベイラビリティーゾーンの障害の場合はより簡単です。Elastic Load Balancing と AWS Auto Scaling などの AWS のサービスは、リソースとアベイラビリティーゾーンにまたがってロードを分散するようサポートするからです。マルチリージョンのワークロードの場合、状況はさらに複雑です。例えば、クロスリージョンリードレプリカを使用すると、データを複数の AWS リージョンにデプロイできますが、プライマリロケーションに障害が発生した場合は、リードレプリカをマスターに昇格させ、そこへトラフィックを向ける必要があります。Amazon Route 53 と AWS Global Accelerator も AWS リージョンにわたりトラフィックをルーティングするのに役立ちます。

ワークロードが Amazon S3 や Amazon DynamoDB などの AWS のサービスを使用している場合、自動的に複数のアベイラビリティーゾーンにデプロイされます。障害が発生した場合、AWS コントロールプレーンはトラフィックを正常な場所に自動的にルーティングします。Amazon RDS の場合、設定オプションとしてマルチ AZ を選択する必要があります。そして障害が発生すると、AWS はトラフィックを正常なインスタンスに自動的にルーティングします。Amazon EC2 インスタンスまたは Amazon ECS タスクの場合、デプロイ先のアベイラビリティーゾーンを選択します。Elastic Load Balancing は、異常なゾーンのインスタンスを検出 し、正常なゾーンにトラフィックをルーティングするソリューションを提供します。Elastic Load Balancing は、オンプレミスのデータセンターのコンポーネントにトラフィックをルーティングすることもできます。

マルチリージョンのアプローチ (オンプレミスのデータセンターも含まれる場合があります) の場合、Amazon Route 53 はインターネットドメインを定義し、ヘルスチェックを含むルーティングポリシーを割り当てて、トラフィックが正常なリージョンにルーティングされるようにします。または、AWS Global Accelerator は、アプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供します。そして、インターネットの代わりに AWS グローバルネットワークを使用して、選択した AWS リージョンのエンドポイントにルーティングして、パフォーマンスと信頼性を向上させます。

AWS は障害からの復旧を念頭に置いたサービスの設計に取り組んでいます。私たちは、障害からの復旧時間とデータへの影響を最小限に抑えるサービスを設計しています。当社のサービスは主にデータストアを使用しており、リクエストが認識されるのは複数のレプリカにわたりデータが永続的に保存された後です。これらのサービスとリソースには Amazon Aurora、Amazon Relational Database Service (Amazon RDS) マルチ AZ DB インスタンス、Amazon S3、Amazon DynamoDB、Amazon Simple Queue Service、Amazon SQS、および Amazon Elastic File System (Amazon EFS) が含まれます。これらのサービスは、セル単位の分離とアベイラビリティーゾーンにより提供される障害切り分けを活用するように構成されています。当社は、運用上の手順の多くで自動化を幅広く使用しています。また、中断から迅速に復旧するために、置換と再起動の機能を最適化しています。

すべてのレイヤーの修復を自動化する: 障害を検出したら、自動化機能を使用して修復するアクションを実行します。

再起動する機能 は、障害を修復するための重要なツールです。分散システムについて前述したように、ベストプラクティスは、可能な場合はサービスをステートレスにすることです。これにより、再起動時のデータまたは可用性が失われるのを防ぎます。クラウドでは、再起動の一環として、リソース全体 (EC2 インスタンス、Lambda 関数など) を置き換えることができます (通常はそうする必要があります)。再起動自体は、障害から復旧するための簡単で信頼できる方法です。ワークロードでは、さまざまなタイプの障害が発生します。障害は、ハードウェア、ソフトウェア、通信、オペレーションなどさまざまな部分で発生する可能性があります。さまざまなタイプの障害をそれぞれ捕捉、特定、修正するための新しいメカニズムを構築するのではなく、さまざまなカテゴリの障害を同じ復旧戦略にマッピングします。ハードウェアの障害、オペレーティングシステムのバグ、メモリリーク、その他の原因で、インスタンスが機能しなくなることがあります。状況ごとにカスタム修復を構築するのではなく、そのいずれかをインスタンスの障害として扱います。インスタンスを終了し、AWS Auto Scaling がそのインスタンスを置き換えることを許可します。その後、障害が発生したリソースの分析を帯域外で実行します。

もう 1 つの例は、ネットワークリクエストを再起動する機能です。依存関係にあるシステムからエラーが返された場合、ネットワークのタイムアウトの場合と依存関係にあるシステムの障害の両方に同じ復旧アプローチを適用します。どちらのイベントもシステムに類似の影響を与えるため、どちらかのイベントを「特例」とするのではなく、エクスポネンシャルバックオフとジッターで限定的に再試行するという類似の戦略を適用します。

再起動する機能 は、復旧指向コンピューティング (ROC) および高可用性クラスターアーキテクチャを特徴付ける復旧メカニズムです。

Amazon EventBridge を使用して、CloudWatch アラームなどのイベントや他の AWS のサービスの状態の変化をモニタリングおよびフィルタリングできます。イベント情報に基づいて、AWS Lambda (または他のターゲット) をトリガーして、ワークロードでカスタム修正ロジックを実行できます。

Amazon EC2 Auto Scaling は、EC2 インスタンスの状態をチェックするように設定できます。インスタンスが実行中以外の状態にある場合、またはシステムステータスが損なわれている場合、Amazon EC2 Auto Scaling はインスタンスが異常であると見なし、代替インスタンスを起動します。AWS OpsWorks を使用している場合は、レイヤーレベルで EC2 インスタンスの自動ヒーリングを設定できます。

大規模な置き換え (アベイラビリティーゾーン全体の喪失など) の場合、複数の新しいリソースを一度に取得するのではなく、静的安定性が高可用性のために優先されます。

静的安定性を使用してバイモーダル動作を防止する: バイモーダル動作とは、たとえばアベイラビリティーゾーンに障害が発生した場合に新しいインスタンスの起動に依存するなど、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。バイモーダル動作を防止するために、静的に安定し、1 つのモードでのみ動作するシステムを構築する必要があります。この場合、1 つのゾーンが削除された場合にワークロードの負荷を処理するのに十分な数のインスタンスを各ゾーンにプロビジョニングしてから、Elastic Load Balancing または Amazon Route 53 ヘルスチェックを使用して、障害のあるインスタンスから負荷を分散します。

EC2 インスタンスやコンテナなどのコンピューティングデプロイの静的安定性があると、信頼性が最も高くなります。これは、コストがかかる懸念と比較検討する必要があります。プロビジョニングするコンピューティングキャパシティーを減らし、障害が発生した場合は新しいインスタンスを起動する方が、コストは低くなります。ただし、大規模な障害 (アベイラビリティーゾーンの障害など) が発生した場合には、効果が低くなります。このアプローチは障害が発生する前に準備するのではなく、障害が発生したときに事後的に対処することになるためです。ソリューションを考える際は、信頼性とワークロードのコストのニーズを比較検討する必要があります。より多くのアベイラビリティーゾーンを使用することで、静的安定性に必要なコンピューティングキャパシティーが減少します。

図 13:トラフィックがシフトした後、AWS Auto Scaling を使用して、障害が発生したゾーンのインスタンスを非同期で置き換え、正常なゾーンで起動します。

バイモーダル動作のもう 1 つの例に、ネットワークのタイムアウトにより、システム全体の設定状態の再読み込みが始まることがあります。これにより想定外の負荷が別のコンポーネントに加わり、そのコンポーネントで障害が発生し、想定外の結果につながる可能性があります。この負のフィードバックループは、ワークロードの可用性に影響を与えます。そこで、静的に安定し、1 つのモードでのみ動作するシステムを構築する必要があります。静的に安定した設計は、 動作を継続的に行い設定状態を常に一定の頻度で更新します。呼び出しに失敗すると、ワークロードは以前にキャッシュされた値を使用し、アラームをトリガーします。

バイモーダル動作のもう 1 つの例は、障害発生時にクライアントがワークロードキャッシュをバイパスできるようにすることです。これは、クライアントのニーズに対応するソリューションのように思われるかもしれませんが、ワークロードのリクエストを大幅に変更し、障害が発生する可能性が高いため、許可すべきではありません。

イベントが可用性に影響する場合に通知を送信する: 重大なイベントが検出されると、イベントによって引き起こされた問題が自動的に解決された場合でも、通知が送信されます。

自動ヒーリング機能により、ワークロードの信頼性を高めることができます。ただし、対処する必要のある根本的な問題もあいまいになる可能性があります。根本原因の問題を解決できるように、自動ヒーリングによって対処されたものを含む問題のパターンを検出できるように、適切なモニタリングとイベントを実装します。Amazon CloudWatch アラームは、発生した障害に基づいてトリガーできます。また、実行された自動ヒーリングアクションに基づいてトリガーすることもできます。CloudWatch アラームは、Amazon SNS 統合を使用して、E メールを送信するか、サードパーティのインシデント追跡システムにインシデントを記録するように設定できます。