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

エッジの耐障害性

信頼性の柱には、ワークロードが意図した機能を正しく一貫して実行する能力が含まれます。これには、ライフサイクルを通じてワークロードを運用およびテストする機能が含まれます。この点で、エッジで回復力のあるアーキテクチャを設計するときは、まずそのアーキテクチャのデプロイに使用するインフラストラクチャを考慮する必要があります。次の図に示すように、 AWS Local Zones と を使用して実装できる組み合わせは、Outpost AWS Outpostsから Outpost、Outpost から Local Zone、Local Zone から Local Zone の 3 つです。 AWS エッジサービスと従来のオンプレミスインフラストラクチャや を組み合わせるなど、回復力のあるアーキテクチャには他にも可能性がありますが AWS リージョン、このガイドではハイブリッドクラウドサービスの設計に適用されるこれら 3 つの組み合わせに焦点を当てています。

インフラストラクチャの考慮事項

サービス設計の中核となる原則の 1 つは AWS、基盤となる物理インフラストラクチャの単一障害点を回避することです。この原則により、 AWS ソフトウェアとシステムは複数のアベイラビリティーゾーンを使用し、1 つのゾーンの障害に対して回復力があります。エッジで、 は Local Zones と Outposts に基づくインフラストラクチャ AWS を提供します。したがって、インフラストラクチャ設計のレジリエンスを確保する上で重要な要素は、アプリケーションのリソースがデプロイされる場所を定義することです。

ローカルゾーン

ローカルゾーンは、サブネットや EC2 インスタンスなどのゾーン AWS リソースの配置場所として選択できるため AWS リージョン、 内のアベイラビリティーゾーンと同様に動作します。ただし、現在 AWS リージョン 存在しない ではなく AWS リージョン、大規模な人口、産業、IT センターの近くにあります。これにもかかわらず、ローカルゾーンのローカルワークロードと で実行されているワークロード間の高帯域幅の安全な接続は維持されます AWS リージョン。したがって、低レイテンシーの要件では、Local Zones を使用してワークロードをユーザーの近くにデプロイする必要があります。

Outposts

AWS Outposts は、 AWS インフラストラクチャ、 AWS のサービス、APIs、ツールをデータセンターに拡張するフルマネージドサービスです。で使用されているのと同じハードウェアインフラストラクチャ AWS クラウド がデータセンターにインストールされます。その後、Outposts は最も近い に接続されます AWS リージョン。Outposts を使用して、低レイテンシーまたはローカルデータ処理要件を持つワークロードをサポートできます。

親アベイラビリティーゾーン

各ローカルゾーンまたは Outpost には、親リージョン (ホームリージョンとも呼ばれます) があります。親リージョンは、 AWS エッジインフラストラクチャ (Outpost または Local Zone) のコントロールプレーンがアンカーされている場所です。Local Zones の場合、親リージョンは Local Zone の基本的なアーキテクチャコンポーネントであり、お客様が変更することはできません。 は AWS クラウド をオンプレミス環境に AWS Outposts 拡張するため、注文プロセス中に特定のリージョンとアベイラビリティーゾーンを選択する必要があります。この選択は、Outposts デプロイのコントロールプレーンを選択した AWS インフラストラクチャに固定します。

エッジで高可用性アーキテクチャを開発する場合、VPC をそれらの間で拡張できるように、Outposts や Local Zones などのこれらのインフラストラクチャの親リージョンが同じである必要があります。この拡張 VPC は、これらの高可用性アーキテクチャを作成するための基盤です。回復力の高いアーキテクチャを定義する場合は、サービスがアンカーされる (またはアンカーされる) リージョンの親リージョンとアベイラビリティーゾーンを検証する必要があります。次の図に示すように、2 つの Outposts 間に高可用性ソリューションをデプロイする場合は、2 つの異なるアベイラビリティーゾーンを選択して Outposts を固定する必要があります。これにより、コントロールプレーンの観点からマルチ AZ アーキテクチャが可能になります。1 つ以上のローカルゾーンを含む高可用性ソリューションをデプロイする場合は、まずインフラストラクチャがアンカーされている親アベイラビリティーゾーンを検証する必要があります。そのためには、次の AWS CLI コマンドを使用します。

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

前のコマンドの出力：

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

この例では、Miami Local Zone (us-east-1d-mia-1a1) はus-east-1d-az2 アベイラビリティーゾーンに固定されています。したがって、エッジで回復力のあるアーキテクチャを作成する必要がある場合は、セカンダリインフラストラクチャ (Outposts またはローカルゾーン) が 以外のアベイラビリティーゾーンに固定されていることを確認する必要がありますus-east-1d-az2。たとえば、 us-east-1d-az1は有効です。

次の図は、可用性の高いエッジインフラストラクチャの例を示しています。

ネットワークに関する考慮事項

このセクションでは、エッジでのネットワーキング、主にエッジインフラストラクチャにアクセスするための接続に関する最初の考慮事項について説明します。サービスリンクの回復力のあるネットワークを提供する有効なアーキテクチャを確認します。

ローカルゾーンの耐障害性ネットワーク

ローカルゾーンは、Amazon S3 や Amazon RDS などの任意のリージョンサービスをシームレスに使用できるようにする、複数の冗長で安全な高速リンクを使用して親リージョンに接続されます。お客様は、オンプレミス環境またはユーザーからローカルゾーンへの接続を提供する責任があります。選択した接続アーキテクチャ (VPN や など AWS Direct Connect) に関係なく、メインリンクで障害が発生した場合にアプリケーションのパフォーマンスに影響を与えないように、ネットワークリンクを介して達成する必要があるレイテンシーは同等である必要があります。を使用している場合 AWS Direct Connect、該当する耐障害性アーキテクチャは AWS リージョン、AWS Direct Connect 耐障害性に関する推奨事項に記載されている へのアクセスアーキテクチャと同じです。ただし、主に国際ローカルゾーンに適用されるシナリオがあります。Local Zone が有効になっている国では、 AWS Direct Connect PoP が 1 つしかないため、 AWS Direct Connect レジリエンスに推奨されるアーキテクチャを作成することはできません。単一の AWS Direct Connect 場所にのみアクセスできる場合、または単一の接続を超える回復力が必要な場合は、 AWS ブログ記事「オンプレミスから への高可用性接続の有効化 AWS Local Zones」で説明されているように AWS Direct Connect、Amazon EC2 で VPN アプライアンスを作成できます。

Outposts の耐障害性ネットワーク

ローカルゾーンとは対照的に、Outposts には、ローカルネットワークから Outposts にデプロイされたワークロードにアクセスするための冗長接続があります。この冗長性は、2 つの Outposts ネットワークデバイス (ONDs。各 OND には、ローカルネットワークへの 1 Gbps、10 Gbps、40 Gbps、または 100 Gbps で少なくとも 2 つのファイバー接続が必要です。これらの接続は、スケーラブルなリンクの追加を可能にするために、リンク集約グループ (LAG) として設定する必要があります。

この接続の詳細については、 AWS Outposts ドキュメントの「Outposts ラックのローカルネットワーク接続」を参照してください。

最適なエクスペリエンスと回復性を実現するために、 へのサービスリンク接続には、少なくとも 500 Mbps (1 Gbps が適しています) の冗長接続を使用する AWSことをお勧めします AWS リージョン。サービスリンクには、 AWS Direct Connect または インターネット接続を使用できます。この最小値により、EC2 インスタンスの起動、EBS ボリュームのアタッチ、Amazon EKS AWS のサービス、Amazon EMR、CloudWatch メトリクスなどのアクセスが可能になります。

次の図は、高可用性プライベート接続のこのアーキテクチャを示しています。

次の図は、高可用性パブリック接続のこのアーキテクチャを示しています。

ACE ラックを使用した Outposts ラックデプロイのスケーリング

集約、コア、エッジ (ACE) ラックは、 AWS Outposts マルチラックデプロイの重要な集約ポイントとして機能し、主に 3 ラックを超えるインストールや将来の拡張を計画する場合に推奨されます。各 ACE ラックには、10 Gbps、40 Gbps、および 100 Gbps 接続をサポートする 4 つのルーターがあります (100 Gbps が最適です）。各ラックは、冗長性を最大化するために最大 4 つのアップストリームカスタマーデバイスに接続できます。ACE ラックは最大 10 kVA の電力を消費し、重さは最大 705 ポンドです。主な利点には、物理ネットワーク要件の軽減、ファイバーケーブルアップリンクの軽減、VLAN 仮想インターフェイスの削減などがあります。 は、VPN トンネルを介してテレメトリデータを通じてこれらのラック AWS を監視し、インストール中にお客様と密接に連携して、適切な電源の可用性、ネットワーク設定、最適な配置を確保します。ACE ラックアーキテクチャは、デプロイのスケールに応じて価値を高め、大規模なインストールにおける複雑さと物理ポート要件を軽減しながら、接続を効果的に簡素化します。 詳細については、 AWS ブログ記事「Scaling AWS Outposts rack deployments with ACE Rack」を参照してください。

Outposts とローカルゾーン間でインスタンスを分散する

Outposts と Local Zones には、有限数のコンピューティングサーバーがあります。アプリケーションが複数の関連インスタンスをデプロイする場合、これらのインスタンスは、異なる設定がない限り、同じサーバーまたは同じラック内のサーバーにデプロイされる可能性があります。デフォルトのオプションに加えて、サーバー間でインスタンスを分散して、同じインフラストラクチャで関連するインスタンスを実行するリスクを軽減できます。パーティションプレイスメントグループを使用して、複数のラックにインスタンスを分散することもできます。これはスプレッドラック分散モデルと呼ばれます。自動ディストリビューションを使用して、グループ内のパーティション間でインスタンスを分散するか、選択したターゲットパーティションにインスタンスをデプロイします。インスタンスをターゲットパーティションにデプロイすることで、ラック間で他のリソースを分散しながら、選択したリソースを同じラックにデプロイできます。Outposts には、ホストレベルでワークロードを分散できるスプレッドホストと呼ばれる別のオプションもあります。次の図は、スプレッドラックとスプレッドホストの分散オプションを示しています。

の Amazon RDS マルチ AZ AWS Outposts

Outposts でマルチ AZ インスタンスデプロイを使用すると、Amazon RDS は 2 つの Outposts に 2 つのデータベースインスタンスを作成します。各 Outpost は独自の物理インフラストラクチャ上で動作し、高可用性のためにリージョン内の異なるアベイラビリティーゾーンに接続します。2 つの Outposts がカスタマー管理のローカル接続を介して接続されている場合、Amazon RDS はプライマリデータベースインスタンスとスタンバイデータベースインスタンス間の同期レプリケーションを管理します。ソフトウェアまたはインフラストラクチャに障害が発生した場合、Amazon RDS はスタンバイインスタンスをプライマリロールに自動的に昇格させ、新しいプライマリインスタンスを指すように DNS レコードを更新します。マルチ AZ 配置の場合、Amazon RDS はプライマリ DB インスタンスを 1 つの Outpost に作成し、別の Outpost 上にあるスタンバイ DB インスタンスにデータを同期的にレプリケートします。Outposts でのマルチ AZ 配置は、 でのマルチ AZ 配置のように動作しますが AWS リージョン、以下の違いがあります。

マルチ AZ 配置は、Amazon RDS on Outposts でサポートされているすべてのバージョンの MySQL および PostgreSQL で使用できます。ローカルバックアップは、マルチ AZ 配置ではサポートされていません。

次の図は、Amazon RDS on Outposts マルチ AZ 設定のアーキテクチャを示しています。

フェイルオーバーメカニズム

ロードバランシングと自動スケーリング

Elastic Load Balancing (ELB) は、実行中のすべての EC2 インスタンスに受信アプリケーショントラフィックを自動的に分散します。ELB は、1 つのインスタンスが過負荷にならないようにトラフィックを最適にルーティングすることで、受信リクエストを管理するのに役立ちます。Amazon EC2 Auto Scaling グループで ELB を使用するには、ロードバランサーを Auto Scaling グループにアタッチします。これにより、グループがロードバランサーに登録されます。ロードバランサーは、グループへのすべての受信ウェブトラフィックの単一の連絡先として機能します。Auto Scaling グループで ELB を使用する場合、個々の EC2 インスタンスをロードバランサーに登録する必要はありません。Auto Scaling グループによって起動されたインスタンスは、自動的にロードバランサーのメンバーとなります。同様に、Auto Scaling グループによって終了したインスタンスは、ロードバランサーから自動的に登録解除されます。Auto Scaling グループにロードバランサーをアタッチした後、ELB メトリクス (ターゲットあたりの Application Load Balancer リクエスト数など) を使用して、需要の変動に応じてグループ内のインスタンス数をスケールするようにグループを設定できます。必要に応じて、Auto Scaling グループに ELB ヘルスチェックを追加して、Amazon EC2 Auto Scaling がこれらのヘルスチェックに基づいて異常なインスタンスを識別して置き換えることができます。ターゲットグループの正常なホスト数が許容数を下回った場合に通知する Amazon CloudWatch アラームを作成することもできます。

次の図は、Application Load Balancer が の Amazon EC2 でワークロードを管理する方法を示しています AWS Outposts。

次の図は、ローカルゾーンでの Amazon EC2 の同様のアーキテクチャを示しています。

Amazon Route 53 for DNS フェイルオーバー

複数の HTTP サーバーやメールサーバーなど、同じ機能を実行する複数のリソースがある場合、Amazon Route 53 を設定してリソースの正常性をチェックし、正常なリソースのみを使用して DNS クエリに応答できます。たとえば、ウェブサイト example.comが 2 つのサーバーでホストされていると仮定します。1 つのサーバーはローカルゾーンにあり、もう 1 つのサーバーは Outpost にあります。これらのサーバーの状態をチェックし、現在正常なサーバーのみexample.comを使用して の DNS クエリに応答するように Route 53 を設定できます。エイリアスレコードを使用して ELB ロードバランサーなどの選択した AWS リソースにトラフィックをルーティングする場合は、リソースの正常性を評価し、正常なリソースにのみトラフィックをルーティングするように Route 53 を設定できます。リソースのヘルスを評価するようにエイリアスレコードを設定する場合、そのリソースのヘルスチェックを作成する必要はありません。

次の図は、Route 53 フェイルオーバーメカニズムを示しています。

Amazon Route 53 Resolver の AWS Outposts

Amazon Route 53 Resolver は Outposts ラックで使用できます。オンプレミスのサービスとアプリケーションに、Outposts から直接ローカル DNS 解決を提供します。ローカル Route 53 Resolver エンドポイントは、Outposts とオンプレミス DNS サーバー間の DNS 解決も有効にします。Route 53 Resolver on Outposts は、オンプレミスアプリケーションの可用性とパフォーマンスの向上に役立ちます。

Outposts の一般的なユースケースの 1 つは、工場設備、高頻度取引アプリケーション、医療診断システムなど、オンプレミスシステムへの低レイテンシーアクセスを必要とするアプリケーションをデプロイすることです。

Outposts でローカル Route 53 Resolver を使用するようにオプトインすると、親への接続が失われた場合でも、アプリケーションとサービスは引き続きローカル DNS 解決の恩恵を受け、他のサービスを検出 AWS リージョン できます。ローカルリゾルバーは、クエリ結果が Outposts からローカルにキャッシュおよび提供されるため、DNS 解決のレイテンシーを減らすのにも役立ちます。これにより、親への不要なラウンドトリップがなくなります AWS リージョン。プライベート DNS を使用する Outposts VPCs 内のアプリケーションのすべての DNS 解決はローカルで提供されます。 https://docs.aws.amazon.com/managedservices/latest/userguide/set-dns.html

ローカルリゾルバーを有効にするだけでなく、この起動によりローカルリゾルバーエンドポイントも有効になります。Route 53 Resolver アウトバウンドエンドポイントを使用すると、Route 53 Resolver は DNS クエリを管理対象の DNS リゾルバーに転送できます。例えば、オンプレミスネットワーク上などです。対照的に、Route 53 Resolver インバウンドエンドポイントは、VPC の外部から受信した DNS クエリを、Outposts で実行されているリゾルバーに転送します。これにより、プライベート Outposts VPC にデプロイされたサービスの DNS クエリを、その VPC の外部から送信できます。インバウンドエンドポイントとアウトバウンドエンドポイントの詳細については、Route 53 ドキュメントの「VPC とネットワーク間の VPCs」を参照してください。