翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# エッジの耐障害性
信頼性の柱には、ワークロードが意図した機能を正しく一貫して実行する能力が含まれます。これには、ライフサイクルを通じてワークロードを運用およびテストする機能が含まれます。この点で、エッジで回復力のあるアーキテクチャを設計するときは、まずそのアーキテクチャのデプロイに使用するインフラストラクチャを考慮する必要があります。次の図に示すように、 AWS Local Zones と を使用して実装できる組み合わせは 3 つあります AWS Outposts。*Outpost から Outpost*、*Outpost から Local Zone*、*Local Zone から Local Zone* です。 AWS エッジサービスと従来のオンプレミスインフラストラクチャや を組み合わせるなど、回復力のあるアーキテクチャには他にも可能性がありますが AWS リージョン、このガイドではハイブリッドクラウドサービスの設計に適用されるこれら 3 つの組み合わせに焦点を当てています。
![\[Local Zones と Outposts を使用してエッジに回復性を実装します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/resiliency-at-edge-options.png)
## インフラストラクチャの考慮事項
サービス設計の中核となる原則の 1 つは AWS、基盤となる物理インフラストラクチャの単一障害点を回避することです。この原則により、 AWS ソフトウェアとシステムは複数のアベイラビリティーゾーンを使用し、1 つのゾーンの障害に対する回復力があります。エッジでは、 は Local Zones と Outposts に基づくインフラストラクチャ AWS を提供します。したがって、インフラストラクチャ設計のレジリエンスを確保する上で重要な要素は、アプリケーションのリソースがデプロイされる場所を定義することです。
### ローカルゾーン
ローカルゾーンは、サブネットや EC2 インスタンスなどのゾーン AWS リソースの配置場所として選択できるため AWS リージョン、 内のアベイラビリティーゾーンと同様に動作します。ただし、現在 AWS リージョン 存在しない ではなく AWS リージョン、大規模な人口、産業、IT センターの近くにあります。それにもかかわらず、ローカルゾーンのローカルワークロードと で実行されているワークロード間の高帯域幅の安全な接続は維持されます AWS リージョン。したがって、低レイテンシーの要件では、ローカルゾーンを使用してワークロードをユーザーの近くにデプロイする必要があります。
### 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`は有効です。
次の図は、可用性の高いエッジインフラストラクチャの例を示しています。
![\[可用性の高いエッジアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-edge-architectures.png)
## ネットワークに関する考慮事項
このセクションでは、エッジでのネットワーキング、主にエッジインフラストラクチャにアクセスするための接続に関する最初の考慮事項について説明します。サービスリンクの回復力のあるネットワークを提供する有効なアーキテクチャを確認します。
### ローカルゾーンの耐障害性ネットワーク
ローカルゾーンは、Amazon S3 や Amazon RDS などの任意のリージョンサービスをシームレスに使用できるようにする複数の冗長で安全な高速リンクを使用して親リージョンに接続されます。お客様は、オンプレミス環境またはユーザーからローカルゾーンへの接続を提供する責任があります。選択した接続アーキテクチャ (VPN や など Direct Connect) に関係なく、メインリンクで障害が発生した場合にアプリケーションのパフォーマンスに影響を与えないように、ネットワークリンクを介して達成する必要があるレイテンシーは同等である必要があります。を使用している場合 Direct Connect、該当する耐障害性アーキテクチャは AWS リージョン、[Direct Connect 耐障害性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/)に記載されている へのアクセスアーキテクチャと同じです。ただし、主に国際ローカルゾーンに適用されるシナリオがあります。Local Zone が有効になっている国では、 Direct Connect PoP が 1 つしかないため、 Direct Connect レジリエンスに推奨されるアーキテクチャを作成することはできません。単一の Direct Connect 場所にのみアクセスできる場合、または単一の接続を超える回復力が必要な場合は、 AWS ブログ記事[「オンプレミスから への高可用性接続の有効化 AWS Local Zones](https://aws.amazon.com/blogs/compute/enabling-highly-available-connectivity-from-on-premises-to-aws-local-zones/)」で説明されているように Direct Connect、Amazon EC2 で VPN アプライアンスを作成できます。
### Outposts の耐障害性ネットワーク
ローカルゾーンとは対照的に、Outposts には、ローカルネットワークから Outposts にデプロイされたワークロードにアクセスするための冗長接続があります。この冗長性は、2 つの Outposts ネットワークデバイス (ONDs。各 OND には、ローカルネットワークへの 1 Gbps、10 Gbps、40 Gbps、または 100 Gbps で少なくとも 2 つのファイバー接続が必要です。これらの接続は、スケーラブルなリンクの追加を可能にするために、リンク集約グループ (LAG) として設定する必要があります。
| アップリンク速度 | アップリンク数 |
| --- | --- |
| 1 Gbps | 1、2、4、6 または 8 |
| 10 Gbps | 1、2、4、8、12 または 16 |
| 40 または 100 Gbps | 1、2 または 4 |
![\[Outposts の耐障害性ネットワーク\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/outpost-resiliency-networking.png)
この接続の詳細については、 AWS Outposts ドキュメントの[「Outposts ラックのローカルネットワーク接続](https://docs.aws.amazon.com/outposts/latest/userguide/local-rack.html)」を参照してください。
最適なエクスペリエンスと回復性を実現するために、 へのサービスリンク接続には、少なくとも 500 Mbps (1 Gbps が適しています) の冗長接続を使用する AWSことをお勧めします AWS リージョン。サービスリンクには、 Direct Connect または インターネット接続を使用できます。この最小値により、EC2 インスタンスの起動、EBS ボリュームのアタッチ、Amazon EKS AWS のサービス、Amazon EMR、CloudWatch メトリクスなどのアクセスが可能になります。
次の図は、高可用性プライベート接続のこのアーキテクチャを示しています。
![\[高可用性プライベート接続の耐障害性アーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-private-connection.png)
次の図は、高可用性パブリック接続のこのアーキテクチャを示しています。
![\[高可用性パブリック接続の耐障害性アーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-public-connection.png)
### 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](https://aws.amazon.com/blogs/compute/scaling-aws-outposts-rack-deployments-with-ace-racks/)」を参照してください。
## Outposts とローカルゾーン間でインスタンスを分散する
Outposts と Local Zones には、有限数のコンピューティングサーバーがあります。アプリケーションが複数の関連インスタンスをデプロイする場合、これらのインスタンスは、異なる設定がない限り、同じサーバーまたは同じラック内のサーバーにデプロイされる可能性があります。デフォルトのオプションに加えて、サーバー間でインスタンスを分散 して、同じインフラストラクチャで関連するインスタンスを実行するリスクを軽減できます。パーティションプレイスメントグループを使用して、複数のラックにインスタンスを分散することもできます。これは*スプレッドラック*分散モデルと呼ばれます。自動ディストリビューションを使用して、グループ内のパーティション間でインスタンスを分散するか、選択したターゲットパーティションにインスタンスをデプロイします。インスタンスをターゲットパーティションにデプロイすることで、ラック間で他のリソースを分散しながら、選択したリソースを同じラックにデプロイできます。Outposts には、ホストレベルでワークロードを分散できる*スプレッド*ホストと呼ばれる別のオプションもあります。次の図は、スプレッドラックとスプレッドホストの分散オプションを示しています。
![\[Outposts と Local Zones のスプレッドラックとスプレッドホスト分散オプション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/spread-rack-host-distribution.png)
## の 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 リージョン、以下の違いがあります。
+ 2 つ以上の Outposts 間のローカル接続が必要です。
+ 顧客所有の IP (CoIP) アドレスプールが必要です。詳細については、[Amazon RDS ドキュメントの「Amazon RDS のカスタマー所有 IP アドレス AWS Outposts](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.coip.html)」を参照してください。
+ レプリケーションは、ローカルネットワークで実行されます。
マルチ AZ 配置は、Amazon RDS on Outposts でサポートされているすべてのバージョンの MySQL および PostgreSQL で使用できます。ローカルバックアップは、マルチ AZ 配置ではサポートされていません。
次の図は、Amazon RDS on Outposts マルチ AZ 設定のアーキテクチャを示しています。
![\[Amazon RDS on Outposts のマルチ AZ 設定。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/rds-outposts-multi-az.png)
## フェイルオーバーメカニズム
### ロードバランシングと自動スケーリング
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。
![\[Outposts での Amazon EC2 ワークロードのロードバランシング。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/alb-in-outposts.png)
次の図は、Local Zones での Amazon EC2 の同様のアーキテクチャを示しています。
![\[Local Zones の Amazon EC2 ワークロードのロードバランシング。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/alb-in-local-zones.png)
**注記**
Application Load Balancer は、 AWS Outposts と Local Zones の両方で使用できます。ただし、 で Application Load Balancer を使用するには AWS Outposts、ロードバランサーに必要なスケーラビリティを提供するために Amazon EC2 容量のサイズを設定する必要があります。でのロードバランサーのサイズ設定の詳細については AWS Outposts、 AWS ブログ記事[「Configuring an Application Load Balancer on AWS Outposts](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-an-application-load-balancer-on-aws-outposts/)」を参照してください。
### Amazon Route 53 for DNS フェイルオーバー
複数の HTTP サーバーやメールサーバーなど、同じ機能を実行する複数のリソースがある場合、[Amazon Route 53](https://aws.amazon.com/route53/) を設定して、リソースの正常性をチェックし、正常なリソースのみを使用して DNS クエリに応答できます。たとえば、ウェブサイト `example.com`が 2 つのサーバーでホストされていると仮定します。一方のサーバーはローカルゾーンにあり、もう一方のサーバーは Outpost にあります。これらのサーバーの状態をチェックし、現在正常なサーバーのみ`example.com`を使用して の DNS クエリに応答するように Route 53 を設定できます。エイリアスレコードを使用して ELB ロードバランサーなどの選択した AWS リソースにトラフィックをルーティングする場合は、リソースの正常性を評価し、正常なリソースにのみトラフィックをルーティングするように Route 53 を設定できます。リソースのヘルスを評価するようにエイリアスレコードを設定する場合、そのリソースのヘルスチェックを作成する必要はありません。
次の図は、Route 53 フェイルオーバーメカニズムを示しています。
![\[Outposts とローカルゾーンの Route 53 フェイルオーバーメカニズム。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/route-53-failover.png)
**注意事項**
プライベートホストゾーンでフェイルオーバーレコードを作成する場合は、CloudWatch メトリクスを作成し、アラームを メトリクスに関連付けてから、アラームのデータストリームに基づくヘルスチェックを作成できます。
Application Load Balancer AWS Outposts を使用して でアプリケーションをパブリックにアクセスできるようにするには、パブリック IPs からロードバランサーの完全修飾ドメイン名 (FQDN) への宛先ネットワークアドレス変換 (DNAT) を有効にするネットワーク設定をセットアップし、公開されたパブリック IP を指すヘルスチェックを使用して Route 53 フェイルオーバールールを作成します。この組み合わせにより、Outposts がホストするアプリケーションへの信頼性の高いパブリックアクセスが保証されます。
### Amazon Route 53 Resolver 上の AWS Outposts
[Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) は 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](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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)」を参照してください。