アノテーション テクニカルサポートの川崎です。
本記事は AWS re:Invent 2022 のセッションレポートとなります。
概要
ネットワークは、アプリケーションが中断のないエクスペリエンスをユーザーに提供する上で主導的な役割を果たします。 このセッションでは、アプリケーションの可用性を最高レベルに維持するためにネットワークを設計する方法を学びます。 このセッションでは、単一リージョンとマルチリージョンの両方のネットワーク アーキテクチャと、可用性を強化し、適切な管理と回復を支援するサービスについて説明します。
セッション動画
セッション資料
セッション情報
イントロダクション
このセッションでは、レジリエントなネットワーク、回復力のあるネットワークを構築する方法についてお伝えします。 私は Kyle Tedeschi (カイル・テデスキ) と言います。 AWSを導入する前は、ネットワークエンジニアとして活動していましたが、 AWSに移行してからは物理ネットワークを扱わなくなりました。 このセッションの目標は、AWS上でレジリエントなネットワークを構築できるように支援することです。 私のパートナーを紹介します。
私は Scott Morrison (スコット・モリソン) と言います。 AWSのネットワーキング・スペシャリスト・ソリューションアーキテクトです。 AWS ネットワーキングのすべてをカバーしています。 顧客との会話で、最も一般的なトピックは、ネットワークのレジリエンスについてです。
AWSのネットワークは非常に大規模であり、多くのサービスや機能があります。 1時間のセッションでは、すべてをカバーすることはできません。 このセッションでは、ネットワークをレジリエンスを持って構築するために最も重要なトピックを取り上げます。
まず、AWS のレジリエンスについて抽象的なレベルからどのように考えるかという、 レジリエンスの理論から始めます。 単一リージョンのレジリエンスとマルチリージョンのレジリエンスについて詳しく説明します。 最後に、ハイブリッドネットワークのレジリエンスについて説明し、 AWS を超えて広がるネットワークの管理について話します。
レジリエンスのための責任共有モデル
AWS を使用したことがある人なら、この責任共有モデルの図を見たことがあるでしょう。 この図は、セキュリティや持続可能性を説明するために使われますが、 レジリエンスにも責任共有モデルが当てはまります。
責任共有モデルは、AWSがインフラストラクチャのレジリエンスに責任を持ち、 顧客がアプリケーションのレジリエンスの設計と構築を担当するという考え方です。
AWS は基盤となるインフラストラクチャのレジリエンスに責任があります。 AWS は、ネットワークの可用性が高く、サービスの可用性が高く、リージョンの可用性が高いことを確認します。 そして、AWS上の様々な障害分離ゾーンについて説明します。 障害分離ゾーンは、顧客である、あなた方が扱う領域です。 これらの障害分離ゾーンを活用できるように設計し、障害に耐えられるようにし、 アプリケーションにレジリエンスを構築できるようにするのは、ユーザーの責任です。
これが責任共有モデルの考え方です。
レジリエンスのトレードオフ
AWSのレジリエンスについて考える際、トレードオフが存在することが分かります。 CAP定理により、一貫性、可用性、分断耐性の3つの特性のうち2つしか持てないとされています。 アプリケーションとネットワーク設計をAWSで行う際に、このCAP定理を考慮し、どれが最も重要で、次に重要、そして最も重要でないかを判断して設計が必要です。 また、レジリエンスにはコストと複雑さが伴うため、レジリエンスのレベルに応じて開発環境、非本番環境、本番環境の非クリティカル、ミッションクリティカルと分類して対応が求められます。 開発環境では冗長性が低くても、顧客への影響はないため問題ないことが多いです。 本番環境では、より多くのレジリエンスが必要で、エンドユーザーがプラットフォームを確実に利用できるようにする必要がありますが、ミッションクリティカルではありません。 トレードオフとして、多少の費用と複雑さは許容し、適度な可用性を得ることができます。 ミッションクリティカルなワークロードでは、最大限のレジリエンスが必要です。 これらのシステムには、例えば911システムや遠隔医療システムなどが含まれます。 これらの場合、費用がかかっても、複雑になっても投資する価値があります。 しかし、開発ワークロードに対して同じレベルの対応を行うと、無駄な投資になってしまうこともあります。 結果として、レジリエンスの高さによって環境を階層化し、過剰な対応を避けつつ、ミッションクリティカルな環境では適切なレジリエンスを実現することが重要です。
障害ドメインの定義
障害ドメインについて説明します。 AWS内には、異なるタイプの障害ドメインが存在します。 AWS自体は障害ドメインではありません。 その理由は、AWSがリージョンを互いに完全に独立して運用しているためです。
グローバルサービスは少数です。 それらのサービスは非常に高い可用性で動作します。 Route 53 を見ると、Route 53 では非常に高い可用性 SLA が示されています。 これは、Route 53 がグローバルサービスであるためです。 複数のリージョンでデータプレーンを使用して、DNS クエリに常に応答できるようにしています。
ほとんどのサービスはリージョン内に存在し、そこに最初の障害ドメインがあります。 現在、リージョン障害が起きることは、非常にまれですが、 リージョンは障害ドメインです。
マルチリージョンへの移行は、非常にコストがかかり複雑です。 したがって、本当にマルチリージョンが必要なのか、 それとも問題が発生した場合に備えて別のリージョンに再デプロイできるようにするだけでよいのか、よく考慮してください。
現実的に、障害分離ゾーンの検討を開始する必要があるのは、アベイラビリティゾーンです。 すべてのリージョンには、通常3つ以上のアベイラビリティゾーンがあり、互いに独立して動作します。
NAT ゲートウェイに注目すると、NAT ゲートウェイは独立したアベイラビリティゾーンで動作します。 アベイラビリティゾーンごとに 1つをデプロイすると、コントロールプレーンもデータプレーンも分離され、 そのアベイラビリティゾーンに対して完全に分離されます。
一方、Network Load Balancer は、リージョンとアベイラビリティゾーンの両方にデプロイします。 コントロールプレーンの観点から見ると、Network Load Balancerを展開すると、 複数のアベイラビリティゾーンにまたがるリージョン オブジェクトが得られます。
各アベイラビリティゾーンには個別のノードがあり、これらのノードは互いに独立しています。 これらはゾーンごとに分離されて動作します。
したがって、Network Load Balancerでは、パケットを処理するデータプレーンはアベイラビリティゾーンの障害ドメインですが、 コントロールプレーンはリージョナルです。 したがって、複数のゾーンに同時に影響を与える可能性があるため、Network Load Balancer に変更を加える方法には少し注意する必要があります。 アプリケーションとネットワークをよく考えて、それらを障害ドメインに配置することをお勧めします。
これらの個々のコンポーネントのどこに障害ドメインがあるか、理解しているでしょうか。 それはリージョンか、ゾーンか、セルのようなゾーンの下にあるものか。 それについて考えてみてください。
多くの人が考慮していないもう 1 つの障害ドメインの 1 つはフローです。 AWS ネットワーキングでは、フローはTCP と UDP の 5 つのタプルです。 つまり、送信元と宛先のポート、送信元と宛先の IP アドレス、および IANA プロトコル番号です。 TCP と UDP 以外のプロトコルの場合、これは、送信元 IP と宛先 IP、および IANA プロトコル番号の 3 つのタプルです。 それがフローを定義します。
TCP を考えると、TCPセッションはフローです。 物理ネットワークを見ると、複数のルーターがありますが、それでもオンプレミスと同様の物理ネットワークです。
そして、3 つのフローを取る場合、それらは 3 つのパスを通過する可能性があります。 3つのフローすべてが異なる道を進むという保証はありませんが、分散する可能性は高くなります。 したがって、フローが増えれば増えるほど、物理ネットワーク上での分散が広がります。 これは、これら 3 つの流れに乗って異なる道を歩む場合、それらは同じ運命を共有しないことを意味します。 したがって、輻輳やリンク障害などは、3 つのフローすべてに影響を与えることはありません。 それらは一部のみに影響を与える可能性があります。
これを行うには、スケーラブルで信頼性の高いデータグラムである SRD を使用できます。 これは AWS が開発したプロトコルであり、今週、SRD 上で実行される ENA Express をリリースしました。 これらの流れを単一の流れに分離すると、それらは運命を共有することになります。 そのリンクが切れると、これら 3 つのフローがすべてなくなることになります。
このことが重要なのは、カプセル化とオーバーレイです。 カプセル化するときは、これら 3 つのフローをすべて取り出して1 つのフローに凝縮しますが、これは非常に危険です。 すべてが同じ物理パスを使用するようになるため、カプセル化プロトコルを実行する場合は注意してください。
フェイルオーバーにデータプレーンを使用する
データプレーンはサービスの主要な機能で、パケットやリクエストの処理を行います。 一方、コントロールプレーンはサービスの管理や構成の方法を決めます。 フェイルオーバーを実現する際は、データプレーンを利用することが重要です。 なぜなら、データプレーンは冗長性を実現し、コントロールプレーンは一貫性を高めるために実装されているからです。 CAP定理に基づくと、コントロールプレーンは一貫性があり、データプレーンは可用性です。 これを念頭に置き、単一リージョンでレジリエントなネットワークを構築する際には、 NAT ゲートウェイや Transit Gateway、ロードバランシングなどのサービスを活用しながらデータプレーンを使用することが望ましいです。
AWS Hyperplane
AWS Hyperplane は、内部サービスであり、多くのAWSサービスを支える重要な役割を果たしています。 ネットワークの水平方向にスケーラブルな状態管理で、テラバイト規模のマルチテナントのキャパシティを提供し、 NAT ゲートウェイや PrivateLink、Network Load Balancerなどのサービスをサポートしています。 Hyperplane には、各 AZ 内に高可用性とフォールトトレラントを持つ複数のノードが存在します。 アタッチメントが作成されると、それは AZ 内の Hyperplane ノードのセットに適用されます。 Hyperplane ノードの1つが異常になると、トラフィックの一部に影響しますが、 異常な Hyperplane ノードから正常な Hyperplane ノードへとトラフィックが移行されます。 別の VPC で別のアタッチメントを作成すると、異なる Hyperplane ノードのセットが使用されます。 この技術はシャッフルシャーディングと呼ばれています。 Hyperplane はマルチテナントサービスであり、一部の重複が発生する可能性があります。 例えば、VPC AとVPC Bのアタッチメントは、一部の重複する Hyperplane ノードでアクティブになります。 リージョン全体のサービスを構築する際に、アタッチメントを複数のAZに配置することが、高いレジリエンスを得るために強く推奨されています。 Hyperplane は、完全なフォールトトレラント性を持ち、AZ 内で高い可用性が確保されています。
NAT ゲートウェイ
NAT ゲートウェイについて、AWSの責任と顧客の責任を見ていきます。 NAT ゲートウェイはAWSが管理し、インフラストラクチャ層やオペレーティングシステム、プラットフォームを運用しています。 顧客はトラフィックを送信するだけです。 NAT ゲートウェイはアベイラビリティゾーン内で冗長性を備えて実装されています。
顧客の責任はどこにあるのでしょうか。 例えば、3つのアベイラビリティゾーンがあり、EC2 インスタンスがオートスケーリンググループ内にあり、 プライベートサブネットでインターネットアクセスが必要とされる場合、NAT ゲートウェイをデプロイします。 AZ に1つだけ NAT ゲートウェイを配置すると、何か異常が発生して影響を受けると、すべての EC2 インスタンスがインターネットにアクセスできなくなります。
推奨される方法は、アクティブなアベイラビリティゾーン毎に NAT ゲートウェイを展開することです。 アクティブなアベイラビリティゾーンとは、リソースが展開されている場所です。 リージョンには4つの AZ があるかもしれませんが、3つしか使っていない場合があります。 その場合、使用している3つの AZ に NAT ゲートウェイを配置してください。
また、ローカル NAT ゲートウェイを使用するよう、サブネットのルートテーブルを更新してください。 これにより、例えば AZ A で異常イベントが発生しても、 他の AZ 内のインスタンスは影響を受けずにローカル NAT ゲートウェイを使い続けることができます。 NAT ゲートウェイはアベイラビリティゾーン内で高い可用性が保たれ、各 AZ 間で完全に独立しています。
AWS Transit Gateway
まず、Transit Gateway は AWS が管理しているため、 顧客はオペレーティングシステム、インフラストラクチャ、プラットフォームを心配すること無く、 エンドポイントにトラフィックを送信する構成のみに集中できます。 また、Transit Gateway はリージョン内で冗長性があります。
顧客の責任について説明するために、サンプルシナリオを考えてみます。 3つの AZ を持つ VPC があり、別の VPC にあるアプリケーションにアクセスする必要がある EC2 インスタンスがいくつかある場合、 VPC 間のルーティングを実行したいとします。 そこで、Transit Gateway をデプロイし、それをサブネットにアタッチします。 また、アクティブな各 AZ にアタッチすることで、 異常なイベントが発生しても他の AZ のリソースは問題なく Transit Gateway にアクセスできます。
よくある質問として、「レジリエンスを高めるために複数の Transit Gateway を導入する必要がありますか？」というものがありますが、答えはノーです。 なぜなら、Transit Gateway は Hyperplane 上に構築されており、AZ 内での可用性が高く、リージョン内でのフォールトトレラントと信頼性が高まるからです。 つまり、データプレーンのレジリエンスを高めるために複数の Transit Gateway をデプロイする必要はなく、単一のTransit Gatewayで対応できます。
Application Load Balancer
Application Load Balancer（ALB）は、AWSが管理し、リージョン内で冗長性を持たせることができます。 ALB を作成すると、AWS は DNS 名を作成し、管理します。 これは、ALB ノードの正常性を保証するためです。
顧客側では、2つのアベイラビリティーゾーン（AZ）とターゲットを持つ VPC が必要です。 HTTP や HTTPS のトラフィックを負荷分散するために、ALB をデプロイします。 また、指定したサブネットに ALB ノードをデプロイします。
クライアントがアプリケーションにアクセスしようとすると、DNS クエリが実行され、Route 53 は ALB ノードの IP リストで応答します。 クライアントは、その中の1つを選択して ALB にパケットを送信し、ノードがターゲットに転送されます。
レジリエンスは、Route 53 が ALB ノードのヘルスチェックを実行し、異常なノードを検出した場合に、DNS クエリへの応答を停止することで機能します。 その後、ALB サービスは異常なノードを停止し、新しい正常なノードを起動します。 新しいノードがオンラインになると、DNS で利用できるようになります。
Network Load Balancer
Network Load Balancer（NLB）は、AWSが管理するレジリエンスの共有責任モデルの一部です。 NLB は、アベイラビリティーゾーン（AZ）内で冗長性を持たせて実装されており、Route 53 の DNS レコードを使ってリージョン内で冗長性が提供されます。
例として、2つの AZ を持つ VPC で、非 HTTP トラフィックのターゲットをいくつか用意しました。 NLB はレイヤー4のロードバランサーなので、ALB のような HTTP トラフィックである必要はありません。 そこで、負荷分散のために NLB をデプロイします。
NLB を構成する際に、「NLB をどこに配置しますか？」「サブネットは何ですか？」と尋ねられます。 指定したサブネットにいくつかの ENI がドロップされ、それが NLB 用になります。 NLB は Hyperplane を使用しており、指定したサブネット内に単一の IP アドレスを持つ単一の ENI が存在します。 それはトラフィックを処理する複数のノードを持つ Hyperplane によってサポートされています。 これにより、AZ の NLB で静的 IP アドレスを使用できます。
異常な NLB ノードがある場合、それは本質的に異常な Hyperplane ノードであり、トラフィックが別のノードに透過的に移動されます。 これにより、単一の IP アドレスが複数の Hyperplane ノードによって提供されるため、IP アドレスは変更されません。
クライアントが NLB に接続したい場合、Route 53 でクエリを実行します。 そして、Route 53 は指定したサブネット内の ENI を表すいくつかの IP アドレスで応答します。 その後、クライアントはこれらの ENI に接続し、トラフィックが転送されます。
Route 53 はヘルスチェックを行い、NLB の ENI が稼働しているかどうかを確認します。 もし、ある AZ（例えばAZ A）で問題を引き起こすイベントが発生した場合、Route 53 はヘルスチェックでそれを検出し、 影響を受けた AZ に対してその IP アドレスを提供しなくなります。 その結果、健全な AZ がすべてのトラフィックを受け取ることになります。 これが、NLB を使ったリージョン内の AZ 間での冗長性についての説明です。
Network Firewall と Gateway Load Balancer
まず、Gateway Load Balancer は、サードパーティのアプライアンスを使ったトラフィックの検査に利用されるものであり、 AWS Network Firewallもこれを使用しています。 AWS がインフラストラクチャを管理するため、冗長性がアベイラビリティゾーンに持たれています。
シナリオでは、2つの AZ を持つ VPC が用意され、サードパーティのファイアウォールがデプロイされています。 この構成でトラフィックの獲得と検査がどのように行われるかについて触れています。 方法としては、まず Gateway Load Balancer を作成し、ENI をどこに配置するか決める必要があります。 ENI は基本的に Hyperplane によってサポートされており、Gateway Load Balancer に単一障害点がなくなるようになっています。
Gateway Load Balancer と NLB の主な違いは、トラフィックがアプライアンスに到達する方法にあります。 トラフィックは GENEVE トンネル内でカプセル化され、インライン検査が行われます。
クロスゾーン負荷分散を有効にする必要がありますか?
クロスゾーン負荷分散を有効にするべきかという質問に答えるために、シナリオを見てみます。 2つのアベイラビリティゾーン (AZ) とそれぞれのターゲットグループが含まれた VPC があり、 Elastic Load Balancer (NLB または ALB) によってサポートされています。 クロスゾーン負荷分散が無効の場合、1つの AZ が異常になると、Route 53 がその AZ の IP アドレスを使用しなくなり、 残りの正常な AZ にクライアントがアクセスできるようになります。
クロスゾーン負荷分散を有効にすると、ELB がヘルスチェックを行い、迅速なフェイルオーバーが可能になります。 ですが、クロスゾーン負荷分散を有効にするべきかは状況次第です。 ALB と NLB の場合、各 AZ を独立した障害ドメインとして扱うことが推奨されているため、クロスゾーン負荷分散はデフォルトで無効になっています。 デフォルトの設定を変更することで、障害ドメインの一部となる ELB が別の AZ にトラフィックを切り替えることが可能になります。
Gateway Load Balancer では、クロスゾーン負荷分散を有効にすることが推奨され、デフォルトでは有効になっています。 その理由は、潜在的にその方がコストが安くなる可能性があるからです。 コストが低い理由は、このサードパーティのネットワーク検査アプライアンスのライセンス料を支払っている場合、 クロスゾーン負荷分散を有効にしていると、各 AZにアプライアンスを 1つずつ配置して実行することを考えてみてください。 つまり、2ノードのライセンスを支払うことになります。
一方、クロスゾーン負荷分散を無効にした場合、その方法で復元力の高いアーキテクチャを構築するには、 トラフィックを滞留させないようにするために、各 AZ に2つのアプライアンスが必要になります。 したがって、この場合、2つのアプライアンスと 4つのアプライアンスの間でコストが計算される可能性があります。 したがって、実際には、ライセンスの内容に従って判断する必要があります。
ELB のベストプラクティスとして、DNS を尊重し、静的 IP アドレスに依存しないことが推奨されています。 また、再接続時にエクスポネンシャルバックオフとジッターを使用することも推奨されます。 これによりアプリケーションへの過剰な負荷を避けることができます。
推奨アーキテクチャ
推奨されるアーキテクチャは、3つの AZ を持つ単一リージョンです。 AZ Aには複数のサービスがありますが、それらは現時点で1つの AZ でのみアクティブです。 ベストプラクティスとして、アクティブな各 AZ に NAT ゲートウェイと PrivateLink をデプロイすることが推奨されています。 可用性が高く、フォールトトレラントな PrivateLink も AWS でサポートされています。 また、Transit Gateway アタッチメントや、AWS Network Firewall エンドポイント、 Gateway Load Balancer エンドポイントも同様に各アクティブな AZ にデプロイする必要があります。 また、クロスゾーン負荷分散を有効にするか無効にするか、および DNS のいくつかのベストプラクティスについて、 負荷分散に関するいくつかのベストプラクティスについても説明しました。
さて、マルチリージョンのレジリエンスに移ります。 多くのアプリケーションでは、単一リージョン内の複数のアベイラビリティゾーンにデプロイし、AWS Well Architected フレームワークと連携することで、可用性、シンプルさ、コストの適切なバランスが得られます。 ただし、規制またはその他の理由により、マルチリージョン・アーキテクチャが必要なお客様もいます。
このセクションでは、リージョン間のルーティングについて説明します。 レジリエンスの高い方法でリージョン間の VPC にアクセスするにはどうすればよいでしょうか? また、マルチリージョン・アーキテクチャにトラフィックを取得する方法について、 3つのオプションについても検討します。 実行したいアプリケーション・スタックが複数のリージョンにあるシナリオ向けの、 トラフィック・ルーティング・オプションをいくつか見ていきます。
リージョン間の接続
リージョン間の接続には、VPC ピアリングや Transit Gateway などの方法があります。 VPC ピアリングは２つの VPC 間でネットワーク接続を確立し、レジリエンスが組み込まれています。 冗長性を作る必要はなく、AWS がすべての処理をしてくれます。 また、Transit Gateway では、マルチリージョンの場合もピアリング接続を構成するだけで済みます。 これも冗長性の作成は不要で、高可用性は AWS によって管理されています。
さらに、クラウド WAN というサービスがあり、これを用いて VPC やオンプレミスネットワークを相互に接続することでグローバルネットワークを作成できます。 クラウド WAN にもレジリエンスが組み込まれており、バックアップとして Transit Gateway を導入する必要はありません。 クラウド WAN を使用する際に追加の冗長性を行う必要もありません。
Route 53
ルーティングオプションの1つ目は、Route 53 です。 Route 53 について、複数のリージョン内でトラフィックを取得する方法を説明します。 AWS クラウド上に2つのリージョンがあり、それぞれにアプリケーションスタックと Elastic Load Balancer が配置されている場合、 Route 53 を使用してトラフィックルーティングを行うことができます。 クライアントがドメイン名 example.com に対して DNS クエリを実行すると、 Route 53 はリージョンAまたはリージョンBのロードバランサー IP を返すように設定されます。
Route 53では、重み付け、ラウンドロビン、レイテンシーベース、地理位置情報ベースなどのトラフィックルーティングオプションがサポートされており、 それらを使ってトラフィックをリージョンに振り分けることができます。 また、レジリエントなコントロールプレーンとデータプレーンが用意されており、データプレーンはグローバルに分散されていて、 コントロールプレーンは us-east-1 に配置されています。
リージョン間でトラフィックの切り替えやリージョン内のアプリケーションスタックをオフラインにする際には、一般的にデータプレーンを使用することが推奨されます。 データプレーンを使用することで、Route 53 ヘルスチェックや Application Recovery Controller (ARC) を利用できます。 これにより、分散されたネットワークを活用して、フェイルオーバーとトラフィックルーティングが行えます。
この方法のおすすめは、アクティブ/アクティブアーキテクチャの Route 53 ヘルスチェックで、 より詳細な制御が必要な場合やフェイルオーバー前に追加のチェックが望ましい場合には、ARC を利用することです。 Route 53 のヘルスチェックや ARC の使い方に関して、詳細な情報が載っているブログ投稿もありますので、是非参考にしてください。
Amazon CloudFront
ルーティングオプションの2番目、CloudFront です。 CloudFront は、400以上のエッジロケーションが世界中に展開されている、Web トラフィック向けのコンテンツ配信ネットワークです。
シナリオとして、リージョンAとリージョンBにコンテンツのオリジンがあると仮定しましょう。 CloudFront はエッジロケーションとリージョンエッジキャッシュを持っています。 クライアントは DNS クエリを実行し、CloudFront のエッジロケーションに接続します。 そして、エッジロケーションはクライアントに対してコンテンツを配信するか、リージョンエッジキャッシュにリクエストを転送します。 リージョンエッジキャッシュも同様にローカルでコンテンツをキャッシュして提供するか、オリジンと接続します。
マルチリージョン展開では、Route 53 を利用してオリジン接続を行います。 例えば、DNS 名が origin.example.com の場合、オリジンを region-a.example.com と region-b.example.com でサポートします。 Route 53 は、CloudFront にトラフィックを転送するノードを決定します。
例えば、リージョンエッジキャッシュノードがリージョンAにあるオリジンの情報を Route 53 から受け取った場合、トラフィックはリージョンAに転送されます。 リージョン内のアプリケーションスタックが異常になった場合、Route 53 はそのリージョンの情報を DNS クエリに含めなくなり、 CloudFront は正常なリージョンの IP アドレスを取得します。 これにより、健全なオリジンに接続することが可能になります。
AWS Global Accelerator
3番目のオプションは、AWS Global Accelerator を使用することです。 まず、AWS Global Accelerator は TCP および UDP トラフィックをサポートし、非 HTTP ワークロードも扱えます。 90以上のエッジロケーションがあります。
サンプルシナリオでは、2つのリージョンを利用してアプリケーションスタックが構築されており、Global Accelerator がデプロイされます。 グローバルエニーキャスト IP アドレスが割り当てられ、2つの IP アドレスが別のネットワークゾーンに配置されます。 これにより冗長性が確保され、レジリエンスが実現されます。
クライアントは example.com に接続し、Route 53 はネットワークゾーンの高可用性を実現します。 ネットワークゾーンが異常になった場合、Route 53 は正常なネットワークゾーンにトラフィックを提供します。 Global Accelerator がトラフィックをオリジンに転送し、ルーティングポリシーに従って処理されます。
Global Accelerator はオリジンに対してヘルスチェックを行い、通常30秒でフェイルオーバーが実現できます。 ウェブサイトの高可用性のために Global Accelerator、エニーキャスト IP アドレス、 ネットワークゾーンには、Route 53 によるヘルスチェックが行われます。
Direct Connect での最高レジリエンス
ハイブリッドネットワークにおいて、Direct Connect は一般的な接続方法です。 専用ファイバーを使って AWS に直接接続し、AWS リージョンとプライベート VPC への最短パスを得られます。 Direct Connect では、2つのレジリエントなモデルがあります。 高レジリエンスモデルと最高レジリエンスモデルです。
高レジリエンスモデルは、2つの異なる場所に1つの接続があるため、レジリエンスが高いですが、ミッションクリティカルなワークロードには向いていません。 一方、最高レジリエンスモデルは、2つの Direct Connect ロケーションが必要で、 それらのロケーションの異なる論理デバイス上に2つの接続を持ち、ワークロードが実行されているリージョンにも接続します。 これにより、最高のレジリエンスを実現できます。
「バックアップ」Direct Connect ゲートウェイを追加する必要がありますか?
ただし、このアーキテクチャには1つの Direct Connect ゲートウェイがあり、一部の人々はこれを単一障害点と指摘するかもしれません。 「バックアップ」や Direct Connect ゲートウェイを追加する必要があるかという質問に対する答えは「いいえ」です。 Direct Connect ゲートウェイは単一障害点ではなく、ルーティングプレーンの一部でもありません。 そのため、パケットは通過しません。 これは、AWS バックボーン上でデータを最短パスでリージョンに転送できるようにする大きな種類の論理ルートリフレクターです。
実際には、世界中のさまざまな場所に接続を追加することで、拡張性とレジリエンスが高まります。 さらに、複数の場所・複数のリージョンのアーキテクチャを簡素化し、よりレジリエンスのある状態に到達するのに役立ちます。 従って、必要なのは1つだけで、それを保つことが大切です。 2つを追加すると値が無効になり、物事がより複雑になるだけです。
Direct Connect が仮想インターフェイス (VIF) 上のリンク障害を検出するまでにどれくらい時間がかかりますか?
今回の話題は、仮想インターフェイス間のフェイルオーバーにかかる時間についてです。 複数の Direct Connect ゲートウェイを使っている場合、フェイルオーバーにかなりの時間がかかることがありますが、 単一の Direct Connect ゲートウェイであれば、BGP コンバージェンスによりフェイルオーバーが行われます。
オンプレミスと Direct Connect ゲートウェイ間にはリンクが確立されており、eBGP セッションが続いていて、eBGP タイマーは最短で90秒に設定可能です。 しかし、90秒は重要なワークロードにとっては長い時間です。
そこで、双方向転送検出（BFD）が役立ちます。 多くの顧客が BFD を使用していないことがわかりますが、BFD を使うことで Hello パケットが継続的に送受信され、最大300ミリ秒の変動がサポートされます。 つまり、300ミリ秒ごとにパケットを送信し、3回連続でパケットを失敗しない限り送信が行われます。 これにより、リンク障害を1秒未満（900ミリ秒以内）で検出し、フェイルオーバーが迅速に行われます。
AWS Site-to-Site VPN によるレジリエンス
Site-to-Site VPN に関して、接続ごとに2つのトンネルが提供されますが、2番目のトンネルを使うことで追加料金がかかるわけではありません。 この2つ目のトンネルを活用して、トンネル間でフェイルオーバーを実現できます。 静的ルーティングではなく、BGP を利用することが推奨されており、これによりトンネル間のトラフィックの移行を容易に行えます。 メンテナンス時には、MED (Multi Exit Discriminator) を使って、トラフィックへの影響をコントロールできます。
ただし、Site-to-Site VPN では双方向転送検出はサポートされておらず、Direct Connect でしかサポートされていません。 また、複数のリージョンに接続する際は、リージョンへの直接接続が推奨されています。 これによりリージョン間の影響を防ぐことができます。 例えば、us-east-1 リージョンで問題が発生した場合、それが us-west-2 リージョンにも影響を与えるケースを避けることができます。
このように、Site-to-Site VPN では、複数のトンネルと BGP を用いてフェイルオーバーや複数のリージョンへの接続対策が推奨されています。 これにより、1つのリージョンや顧客ルーターに障害が発生しても、他のリージョンやルーターに影響が及ばないような安定した接続環境を構築できます。
モニタリング、ベースライン、可視性
ハイブリッドワークロードにおいて、ネットワークのベースラインとモニタリングは重要です。 フローログをオンにし、トップトーカーとなる通信を確認することが必要です。 常にオンにする必要はありませんが、少なくとも1週間はオンにしておき、トラフィック量や行き先を把握することが推奨されます。 コンプライアンス上必要でなければ、通常はオンにし続ける必要はありません。 また、Amazon VPC デバッグツールを使って、レイテンシーやパケットロス等のデータを CloudWatch メトリクスに記録しましょう。
帯域幅や平均レイテンシーについてもベースラインを設定することが望ましいです。 これは、アプリケーションのパフォーマンスが遅く感じた際に、問題がネットワークにあるかどうか判断する指標になります。
エンドツーエンドのテストを実行することで、デバッグツールが活躍します。 トラフィックがどのようなものであるかや、ユーザーエクスペリエンスがどのようなものかを理解することができます。 こうした情報は、トラブルシューティングを行う際に非常に有用となります。
ネットワークのベースラインとモニタリングを行い、適切なツールを使ってデータを収集・分析し、トラブルシューティング時に活用しましょう。
ハイブリッドネットワークのレジリエンス
このセッションでは、ハイブリッドネットワークのレジリエンスについて説明します。 Direct Connect では2か所に拠点を持ち、ワークロードが存在するリージョンに関連付けられることが望ましいです。 レジリエンスを向上させるために、それぞれの場所に2つの接続があることと、異なる論理デバイス ID があることを確認してください。 BFD の有効化と複数の Direct Connect ゲートウェイを避けることも大切です。
Site-to-Site VPNでは、両方のトンネルを活用し、動的ルーティングを使用してください。 ECMP を使って帯域幅を集約し、アクティブ/アクティブな環境を作り出すことができます。 ただし、非対称ルーティングになる可能性があるため、お客様の構内機器が対応しているか確認してください。 また、高速化された Site-to-Site VPN を有効にし、Global Accelerator を利用することで、より速いバックボーンアクセスが可能となり、インターネットの悪影響を避けることができます。
本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。
2
