REL11-BP03 すべてのレイヤーの修復を自動化する - 信頼性の柱
実装のガイダンス リソース

REL11-BP03 すべてのレイヤーの修復を自動化する

障害を検出したら、自動化機能を使用して修復するアクションを実行します。パフォーマンスの低下は、内部のサービスメカニズムによって自動的に修復される場合もあれば、修復アクションによってリソースを再起動または削除する必要がある場合もあります。

セルフマネージドアプリケーションやクロスリージョン修復では、復旧設計と自動修復プロセスを既存のベストプラクティスから引き出すことができます。

リソースを再起動または削除する機能は、障害を修復するための重要なツールです。ベストプラクティスは、可能な限りサービスをステートレスにすることです。これにより、リソースの再起動時のデータまたは可用性が失われるのを防ぎます。クラウドでは、再起動の一環として、リソース全体 (コンピューティングインスタンス、サーバーレス関数など) を置き換えることができます (通常はそうする必要があります)。再起動自体は、障害から復旧するための簡単で信頼できる方法です。ワークロードでは、さまざまなタイプの障害が発生します。障害は、ハードウェア、ソフトウェア、通信、オペレーションなどさまざまな部分で発生する可能性があります。

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

期待される成果: 障害の検出を修正するために、自動アクションが実行されます。

一般的なアンチパターン:

  • 自動スケーリングなしでリソースをプロビジョニングする。

  • インスタンスまたはコンテナにアプリケーションを個別にデプロイする。

  • 自動復旧を使用せずに、複数のロケーションにデプロイできないアプリケーションをデプロイします。

  • 自動スケーリングと自動復旧が修復に失敗するアプリケーションを手動で修復する。

  • フェイルオーバーデータベースの自動化はない。

  • トラフィックを新しいエンドポイントに再ルーティングする自動化された方法が足りない。

  • ストレージのレプリケーションはない。

このベストプラクティスを活用するメリット: 自動修復により、平均回復時間を短縮し、可用性を向上させることができます。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

Amazon EKS やその他の Kubernetes サービスの設計には、レプリカセットまたはステートフルセットの最小値と最大値の両方、およびクラスターとノードグループの最小サイズが含まれている必要があります。これらのメカニズムは、Kubernetes コントロールプレーンを使用して障害を自動的に修正しながら、継続的に利用可能な処理リソースを最小限に抑えます。

コンピューティングクラスターを使用してロードバランサーを介してアクセスされる設計パターンでは、Auto Scaling グループを活用する必要があります。Elastic Load Balancing (ELB) は、受信アプリケーショントラフィックを 1 つ以上のアベイラビリティーゾーン (AZ) にある複数のターゲットと仮想アプライアンスに自動的に分散します。

ロードバランシングを使用しないクラスター化されたコンピューティングベースの設計では、少なくとも 1 台のノードが失われることを想定したサイズにする必要があります。これにより、新しいノードを復旧している間も、サービスが容量が減少する可能性がある状態で稼働し続けることができます。サービスの例としては、Mongo、DynamoDB Accelerator、Amazon Redshift、Amazon EMR、Cassandra、Kafka、MSK-EC2、Couchbase、ELK、Amazon OpenSearch Service などがあります。これらのサービスの多くは、追加の自動修復機能を使用して設計できます。一部のクラスターテクノロジーでは、ノードが失われたときにアラートを生成し、新しいノードを再作成するための自動または手動のワークフローをトリガーする必要があります。このワークフローは、AWS Systems Manager を使用して自動化でき、問題を迅速に修正できます。

Amazon EventBridge を使用すれば、CloudWatch アラームなどのイベントや、その他の AWS サービスの状態の変化などを、モニタリングおよびフィルタリングすることができます。イベント情報に基づいて、AWS Lambda、Systems Manager Automation、または他のターゲットを呼び出して、ワークロードに対してカスタム修正ロジックを実行できます。Amazon EC2 Auto Scaling は、EC2 インスタンスの状態をチェックするように設定できます。インスタンスが実行中以外の状態にある場合、またはシステムステータスが損なわれている場合、Amazon EC2 Auto Scaling はインスタンスが異常であるとみなして代替インスタンスを起動します。大規模な置き換え (アベイラビリティーゾーン全体の喪失など) の場合、静的安定性が高可用性のために優先されます。

実装手順

  • Auto Scaling グループを使用して、ワークロードに階層をデプロイします。Auto Scaling は、ステートレスなアプリケーションで自己修復を実行し、キャパシティを追加および削除できます。

  • 前述のコンピューティングインスタンスの場合は、ロードバランシングを使用して適切なロードバランサーのタイプを選択します。

  • Amazon RDS の修復を検討します。スタンバイインスタンスでは、スタンバイインスタンスへの自動フェイルオーバーを設定します。Amazon RDS リードレプリカの場合、リードレプリカをプライマリにするには自動化されたワークフローが必要です。

  • 複数のロケーションにデプロイできないアプリケーションがデプロイされている EC2 インスタンスに自動復旧を実装し、障害時の再起動を許容できます。自動復旧は、アプリケーションが複数のロケーションにデプロイできない場合に、障害が発生したハードウェアを交換してインスタンスを再起動するために使用できます。インスタンスメタデータおよび関連する IP アドレスは保持されます。また、EBS ボリュームと Amazon Elastic File System または File Systems for Lustre および Windows へのマウントポイントも保持されます。AWS OpsWorks を使用することで、レイヤーレベルで EC2 インスタンスの自動修復を設定できます。

  • 自動スケーリングまたは自動復旧を使用できない場合、または自動復旧が失敗した場合は、AWS Step Functions と AWS Lambda を使用して自動復旧を実装します。自動スケーリングを使用できず、さらに、自動復旧が使用できないか、自動復旧が失敗した場合は、AWS Step Functions と AWS Lambda を使用して修復を自動化できます。

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

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例:

関連ツール: