re:Invent 2024: AWSのルーティング深掘り - VPCからCloud WANまで
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Dive into the depths of routing on AWS (NET318)
この動画では、AWSのRoutingについて、基本的な構成要素から実践的なシナリオまでを体系的に解説しています。単一のVPCにおけるRouting Information BaseとForwarding Information Baseの違いから始まり、Transit Gateway、AWS Cloud WANなどを活用した複数リージョンでのルーティング設定、さらにはDirect Connectを使用したハイブリッド接続の実装方法まで、段階的に説明が進められます。特に、Network Functions GroupやFirewallの導入、AS path prependingやLocal preferenceを使用したトラフィックエンジニアリングなど、実務で直面する具体的な課題に対する解決策が22個のPro Tipとともに提示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのRoutingに関するセッションの概要
皆さん、ようこそ。今日はAWSのRoutingについて深く掘り下げていきたいと思います。スキューバギアは持ってきましたか？私はTomです。こちらがAnkitです。私たち二人ともネットワーキングを専門とするPrincipal Solutions Architectsです。お客様とアーキテクチャやデザインについて話し合う機会が多く、今日はその経験を皆様と共有させていただきます。
アジェンダですが、まず基礎から始めて、Routingの基本的な構成要素について説明し、その後、単一のVPCから、複数のリージョンや複数のVPCにまたがるシナリオまで、さまざまなRouting設定の例を見ていきます。1時間のセッションですので、最も有用だと思われるシナリオを厳選させていただきました。 レベルとしては、300レベル、つまり上級者向けとなっています。ただし、この数字は平均的なものですので、基礎的なトピックから始めて、徐々に深い内容に進んでいきます。最後には、コードサンプルやエキスパートレベルの概要もお見せできるかもしれません。
その他のネットワーキング構成要素について知りたい方は、基礎編のNET202、そしてグローバルコネクティビティの詳細についてはNET311とNET301があります。NET301は1時間後にVenetianで開催される予定です。
Routingの基本概念とAWSのネットワーキングコンポーネント
では、基本的な構成要素から始めましょう。まず最初に、Routeとは何かについて説明します。これはRoutingに関するセッションですので、基本をしっかり押さえておきましょう。 Routeとは、目的地（どこに行きたいか）とそこにどうやって到達するかという情報です。ネットワークの観点から言えば、到達したいネットワークと、そこへ至るパス（Next Hop）があるということです。 例えば、IPv4のRouteがあり、Next HopがInterfaceである場合や、IPv6のRouteがあり、Next Hopが何らかのv6 IPアドレスである場合などです。
AWSに限らず、どのRoutingソリューションを見ても、通常2つのRoutingデータベースがあります：Routing Information BaseとForwarding Information Baseです。 例えば、RouterにInterfaceのAとBがあり、それぞれNetwork 10と10に接続されているとします。これらはRouting Information Baseに格納されます。 さらに、InterfaceのC、おそらくNetwork 10と20があり、これもRouting Information Baseに格納されます。その後、RouterはRouting Information Base内のすべてのRouteを確認し、特定の宛先への最適なRouteを選択します。この例では、何らかの理由でInterface Aが最適なパスとして選択されたことがわかります。
結局のところ、Routing Information Base（RIB）はルーティングコンポーネントが認識しているすべてのルートであり、Forwarding Information Base（FIB）はルーターが選択した特定の宛先への最適なパスということになります。 AWSのネットワーキングコンポーネントを見る際、私たちが目にしているのはFIBです。そのため、同じ宛先への複数のパスが存在する可能性がありますが、ソリューション上のRoute Tableを確認すると、FIBと最適なルートのみが表示されることになります。
本日お話しするコンポーネントについて、まずはVirtual Data Center、つまりVPCとその中のRoute Tableについて見ていきます。グローバルな接続性については、AWS Transit Gatewayについて説明します。これは論理的なリージョナルルーターで、分散システムであり、単一障害点のない、リージョン内で数千のVPCを接続できるシステムです。次にAWS Cloud WANですが、これは単一のポリシーで管理でき、リージョン間の動的ルーティングを可能にする、グローバルに展開された管理型Transit Gatewayの集合体と考えることができます。ハイブリッド接続の観点からは、AWSへのファイバー接続であるAWS Direct Connectと、AWSが管理する従来型のIPsec VPNトンネルであるSite-to-Site VPNについて見ていきます。また、Software-Defined Wide Area Network（SD-WAN）についても触れます。AWSにはネイティブなソリューションはありませんが、サードパーティのソリューションをAWSに統合する方法をご紹介します。
AWSのルーティングコンポーネントには、一般的に3種類のルートタイプがあります。まず、Static Routeです。これは管理者が特定の宛先を指定して手動で設定するルートです。 次にPropagated Routeがあります。これは他の場所にルートが存在することに基づいて、Route Tableに自動的に表示されるルートです。 そして最後にDynamic Routeです。AWSでDynamic Routeと言えば、通常はインターネット上でルーティング情報を交換する標準プロトコルであるBorder Gateway Protocol（BGP）を指します。
2つのピアがTCP経由で接続すると、ルーティングデータベースを交換します。 Static Route、Propagated Route、Dynamic Routeなど、複数のソースから同じルートを受信した場合、特定の優先順位があります。 ネットワーキングコンポーネントが認識するルートの中では、常にStatic Routeが他のルートよりも優先され、次にPropagated Route、最後にDynamic Routeという順序になります。
ただし、この規則には重要な例外があります。設定したStatic RouteよりもDynamic Routeの方がより具体的である場合など、より具体的なルートの場合は、Dynamic RouteがStatic Routeよりも優先されます。また、Propagated Routeの中でも、同じルートを複数の異なるソースから受信することがあります。Propagated Routeにはタイブレーカーがあり、これはルートがVPCから来ているか（これが最も優先される）、Direct Connectから来ているか（これが次に優先される）、VPN経由で来ているか（これが最も優先度が低い）などの要因に基づいています。この優先順位は、使用しているネットワークソリューションによって異なります。
単一VPCにおけるRoutingの設定と最適化
BGPを使用した動的ルーティングでは、 BGPを通じて同じルートが入ってきた場合、Local PreferenceやAS Pathなどの標準的な属性を使用してそれらのルートを制御することができます。後半でAnkitが具体例を示しながら、その使用方法について説明します。それでは、単一のVPCと単一のリージョンから始めて、いくつかの例を見ていきましょう。ただし、単一のVPCの詳細に入る前に、オンプレミス環境とAWSクラウドネットワーキングを比較してみましょう。
オンプレミスのルーターを考えると、異なるサブネットに接続する複数のインターフェースがあり、そのサブネットの先にホストが存在します。Subnet A、B、C、そしてDがある場合、これをAWSのVPCに置き換えると、それらのホストの代わりにEC2インスタンス、仮想マシン、コンテナ環境、さらにはLambda関数などが配置されることになります。また、AWSにもサブネットという概念があり、通常はVPCという構成の中に含まれています。VPCには、内部のすべてのサブネットを包含するCIDRレンジが設定されます。ここではIPv4の例を示していますが、VPCはIPv6もサポートしており、デュアルスタックリソースやIPv6専用リソースも利用可能です。
VPCの中央には暗黙的なルーターが存在することにお気づきでしょう。このルーターには、デフォルトで全員が使用するメインルートテーブルがあります。このルートテーブルには、VPC CIDRレンジに一致する2つのエントリがあり、ネクストホップがlocalと表示されます。このメインまたはデフォルトのルートテーブルにより、デフォルトで誰もが互いに通信できます。VPC内で全員が互いに通信できるのであれば、そもそもなぜサブネットが必要なのかと疑問に思うかもしれません。大きなサブネットを1つ作り、Security Groupでトラフィックを制御すれば十分ではないかと。
サブネットが必要な理由はいくつかあります。まず、サブネットはAvailability Zone単位の構成要素であり、一方でVPCは複数のAvailability Zoneにまたがる地域的な存在です。異なるAvailability Zoneにリソースをデプロイしたい場合は、各Availability Zone用に個別のサブネットを使用する必要があります。サブネットのもう1つの利点は、個々のサブネットの周りに効果的にNetwork Access Control List（NACL）を作成し、サブネットの出入りトラフィックを制御できることです。さらに、追加のRoute Tableを作成して、サブネットごとにルーティングを制御することもできます。
この仕組みがどのように機能するか、例を見てみましょう。このシナリオでは、Subnet BとDは完全にプライベートで、インターネットからアクセスできないようにすべきリソースが含まれています。ただし、一方通行のドアのように、インターネットへの接続性は提供したいと考えています。つまり、インターネット上のリソースと通信してアップデートをダウンロードすることはできますが、外部からアクセスすることはできません。VPCからトラフィックを流すためにはInternet Gatewayが必要です。IPv6の場合、シンプルな解決策があります：Egress Only Internet Gatewayを設定することで、IPv6アドレスを持つリソースが外向きの通信のみを行え、インバウンドでは何も到達できないようにすることができます。
IPv4では、Subnet単位でRoutingを設定することで目的を達成できます。Subnet AとCにNAT Gatewayを配置します。これらのNAT Gatewayはインターネットとの直接的な接続性を持ち、トラフィックの送信を可能にします。ただし、外部からNAT Gatewayへの接続を試みても、そのトラフィックは破棄されてしまいます。
各Subnetに対して個別のRoute Tableを作成し、それをSubnetに関連付けることで、Subnet単位でRoutingを設定します。Subnet BではIPv4のデフォルトルートがNAT Gateway oneを経由するように設定され、Subnet DではNAT Gateway twoを指すように設定された別のRoute Tableがトラフィックを制御します。このセッションを通して重要なのは、トラフィックをZone内に閉じ込めることです。Availability Zone間でトラフィックをやり取りすると、コストが発生し、レイテンシーも増加するため、避けたいところです。異なるRoute Tableを使用し、同じ宛先ネットワークとデフォルトルートを持ちながら、次のホップを変える（NAT Gateway oneかNAT Gateway two）ことで、トラフィックをZone内に閉じ込めることができます。NAT Gateway用のSubnetについては、インターネットへのルートを持つ同じRoute Tableを共有できます。
VPC内のより高度なRouting設定：Ingress RoutingとMore Specific Routing
VPC内のRoutingに関連するより高度な構成として、Ingress RoutingとMore Specific Routingがあります。Ingress Routingは、Internet GatewayやVirtual Private Gatewayからのトラフィックをネットワーク機能にリダイレクトする方法です。ここでいうネットワーク機能とは、通常はFirewallを指しますが、他のものである可能性もあります - 典型的にはFirewall、次世代のFirewallアプライアンス、またはAWS管理のFirewallです。More Specific Routingでは、同様のリダイレクトが可能ですが、今度はGatewayからの入力トラフィックではなく、VPC内の2つの異なるSubnet間のトラフィックを対象とし、ローカルルートの動作を上書きします。
元のシナリオに変更を加えて説明すると、下部の2つのインスタンスにはパブリックIPアドレスが割り当てられるため、Internet Gatewayを介してインターネットから直接アクセス可能になります。しかし、このトラフィックを直接これらのインスタンスに到達させるのではなく、何らかのネットワーク機能を経由させたいと考えています。この例では、AWS Network Firewallを使用しています。これは、AWSに導入可能なお好みのサードパーティベンダーのソリューションに置き換えることもできます。
そして、Route Tableを作成し、それをInternet Gatewayに関連付けます。このRoute Table内には、常に存在するローカルルートが表示されます。さらに、Subnet BまたはSubnet Dへ向かうトラフィックは、まずセキュリティアプライアンスを経由するように指定する2つの追加ルートを設定します。これにより、Internet Gatewayを通過して通常であればSubnet BとDに直接送信されるトラフィックを、Firewallにリダイレクトします。検査が完了した後にのみ、Firewallレイヤーから2つのインスタンスへのローカルRoutingを使用できます。
送信トラフィックに関して、異なるサブネットには異なるRoute Tableを使用する必要があります。Subnet Bでは、戻りトラフィックがFirewall 1を経由するようにし、Subnet Dでは戻りトラフィックがFirewall 2を経由するように設定して、トラフィックをゾーン内に保ちます。より詳細なルーティングについては、Gatewayは必要ありません。詳細なルーティングはVPC内のトラフィックに影響を与えます。ここでは、Subnet AからSubnet Cへのトラフィックが、Subnet B内のFirewallを経由するようにします。通常、より詳細なルーティングがなければ、ローカルルートが優先され、2つのインスタンスが直接通信できてしまいます。
必要な作業は、VPCのレンジよりも具体的なルートを追加することです。Subnet Cへのトラフィックは、Network Firewallを経由する必要があります。Network Firewallのサブネットに入ると、そのRoute Tableは関係なくなり、ローカルルートだけになります。クリーンなトラフィックを受け取り、検査後にSubnet Cに到達します。戻りトラフィックも同じ経路を通るように、正しく設定する必要があります。
このセッションを通して、設計を検討する際に役立つヒントやコツをPro Tipsとしてご紹介します。この例では、より具体的なルートは、SubnetのCIDRレンジまたはVPCのCIDRレンジと一致する必要があります。静的ルーティングには、まだお話ししていない問題が1つあります。AWSでは、静的ルートを設定する際、ネクストホップの健全性を認識することができません。つまり、Network Interfaceに静的ルートを設定しても、そのNetwork Interfaceの背後にあるものが停止した場合に検知できません。オンプレミスでは、VRRPやHSRPなどの仮想IPアドレスでこの問題を解決しますが、AWSではそれができません。
AWSに存在しないこの問題を解決するには、主に2つの選択肢があります。1つ目は、NAT Gateway、Network Firewall、Transit Gatewayなど、AWS内ですでに高可用性が確保されているリソースをターゲットにする方法です。これらはVPC内では単一のNetwork Interfaceとして表示されますが、その背後には複数のコンポーネントが存在します。もう1つの選択肢は、自己ホスト型ソリューションとして、AWS Gateway Load Balancerを使用するか、Elastic Network Interfaceの再接続を実装する方法です。
ENIの再接続から見ていきましょう。このシナリオでは、左側にソースインスタンスがあり、インターネット上に宛先があります。Instance AはFirewallで、Elastic Network Interface Xを持っており、インターネットへ行くトラフィックはXを経由するように静的ルートを設定します。そして、インスタンスから検査後のトラフィックが宛先に向かいます。もしそのインスタンスが故障した場合、障害を検知し、2番目のインスタンスをプロビジョニングし、Elastic Network Interfaceをアクティブなインスタンスに移行するためのAPI呼び出しを行う必要があります。その間、トラフィックはブラックホール化され、このフローに対して実質的な停止が発生します。
このプロトタイプでは、Elastic Network Interfaceの切り離しと再接続を行っていますが、これは非同期APIコールを通じたコントロールプレーンの操作です。一般的に、障害発生時にはデータプレーンのフェイルオーバーが最適なアプローチであるため、このようなAPIコールの使用はお勧めしません。 レジリエンスに対処するより良い方法は、Gateway Load Balancerを使用することです。Gateway Load Balancerは、VPC内にGateway Load Balancer Endpointとして表示され、実質的にGateway Load Balancer自体にマッピングされるネットワークインターフェースとして機能します。 Gateway Load Balancerは、プロキシである通常のロードバランサーとは異なり、ロードバランシングルーターとして考えてください。接続を終端するのではなく、トラフィックをルーティングし、通常はFirewallなどの異なるネットワーク機能に分散させることができます。
この構成では、ソースからGateway Load Balancer Endpointをデスティネーションとするデフォルトルートを設定します。 Gateway Load Balancerは、フローをハッシュ化してトラフィックを分散し、送信方向と戻り方向の両方で適切なFirewallが選択されるようにすることで、対称的なトラフィックフローに関する懸念を解消します。 インスタンスAに障害が発生した場合、Gateway Load Balancerはヘルスチェックを実行して自動的に障害を検知し、既存および新規のフローをインスタンスBに移動し始めます。 インスタンスAの既存のフローをインスタンスBやCに移動する必要がある場合は、ロードバランサーの設定オプションでそれを有効にすることができます。
複数リージョンにまたがるRoutingの実装とAWS Cloud WANの活用
2つのアプローチを比較すると、Gateway Load Balancerが明らかにAWS上でネットワーク機能を管理するための優れた方法であることがわかります。障害を自動的に検知し、トラフィックを次のアプライアンスに移動させ、コントロールプレーンの変更を必要とせずにすべての操作をデータプレーン上で実行します。 では次に、外部リソースへの接続について説明しましょう。まずはデータセンターへの接続から始めます。これには、IPv4とIPv6の両方をサポートするルーターとネットワークを備えたオンプレミス環境が含まれます。ここでは、VPCを単一のサブネットに簡略化しています。
AWS Direct Connect（バックボーンへの専用ファイバー接続を提供）を介してオンプレミスに接続するには、Virtual Private Gateway（VGW）をプロビジョニングする必要があります。VGWにはBGPに関連するAutonomous System Number（ASN）が割り当てられ、これはすべてのネットワークコンポーネントの一意の識別子として機能します。 次に、Direct Connect Gatewayをプロビジョニングします。これは、複数のAWSリージョンと異なるDirect Connect locationをグローバルに接続できる論理的なVRFまたはネットワーク機能と考えることができます。 Direct Connectから、Private Virtual Interfaceを使用してオンプレミスへの論理的なインターフェースを作成します。これは基本的に、BGPを実行するVLANです。Direct Connect Gatewayとオンプレミスのルーター間でeBGPセッションが確立され、ルーティング情報が交換されます。なお、物理ケーブルやロケーションへの接続を含む物理的な接続については、Ankitがパート2で説明する予定なので、ここでは示していません。
現在は論理的な側面に焦点を当てていますが、サブネットAのルートテーブルを見てみましょう。Virtual Private Gateway（VGW）が動的に学習したルートをサブネットのルートテーブルに伝播させるオプションがあることがわかります。これにより、それらのルートを静的に設定する必要がなく、自動的にVPCルートテーブルに伝播させることができ、VPCがオンプレミスネットワークへの到達方法を把握できるようになります。
デバイス側では、Route Tableにネットワークの宛先とそれに到達するための次のホップが表示され、パスには確認されているAutonomous System番号が表示されます。オンプレミス環境への戻りパスやVPCへの到達経路では、IPv6とIPv4の両方のネットワークが確認できます。次のホップはDirect Connectインターフェースですが、Direct Connect GatewayのASNを確認することができます。このシナリオでは、Direct Connect GatewayがVGWのASNを隠蔽しており、パス内でVGWのASNを確認することはできません。
デフォルトでは、VPCをVGWを介してDirect Connect Gatewayに接続すると、すべてのVPC CIDRがオンプレミス環境にアドバタイズされます。これらはDirect Connect Gatewayレベルでフィルタリングすることが可能です。これは高可用性を備えたデプロイメントではありませんが、論理的な接続の一例として紹介しています。Direct Connect側での高可用性の実現については、Ankitが詳しく説明する予定です。
VPCを接続するもう一つの選択肢として、AWS Site-to-Site VPNがあります。このマネージドVPNサービスは、1つのVPN接続に対して2つのトンネルを提供し、VGWでは各トンネルが約1.2Gbpsの帯域幅を実現できます。実際には1つのトンネルしか使用しませんが、ルーティング情報の交換にBGPを設定することも可能です。VPCの観点からは、大きな変更はありません。依然としてVGWがSubnetにルートを注入しているため、Subnet側からはそれらのルートの出所を知ることはできません。
インフラストラクチャを高可用性にするために、VPNには動的ルーティングを使用することをお勧めします。VGWに2つの接続 - VPNトンネルとDirect Connect接続 - がある場合、トラフィックが通るパスをルーターから制御することができます。Direct Connectを優先したい場合は、その設定が可能です。VPCの観点からは、優先順位についてドキュメントを確認する必要があります。静的ルートと最長プレフィックスマッチの後、AWSはVPN BGPルートよりもBGP Direct Connectルートを優先するため、トラフィックはDirect Connect Gatewayのパスを通ることになります。
Direct Connectのバックアップとしてのみ、VPNを使用することを検討するかもしれませんが、本番環境のデプロイメントでは、VPN接続ではなく、別のDirect Connectをバックアップとして使用することをお勧めします。動的ルーティングによるフェイルオーバーについて、BGPには30秒ごとにKeep-aliveメッセージを送信する仕組みが組み込まれています。3回のKeep-aliveメッセージが失敗すると接続がダウンしたとみなされますが、この障害検出には90秒かかります。
障害検知を改善するために、300ミリ秒ごとにBFDパケットを送信するBidirectional Forwarding Detection（BFD）を有効にすることができます。 これにより、1秒以内にリンク障害を検知することが可能になります。ただし、BFDはDirect Connect上でのみ機能し、 別のDirect Connect接続へのフェイルオーバー時にのみ有効であることに注意が必要です。BFDを使用する場合は、Direct Connect上で実装し、フェイルオーバー用の別のDirect Connect接続を用意する必要があります。
次に、単一リージョン内の複数のVPCを含むルーティングシナリオについて見ていきましょう。この接続には、AWS Transit Gatewayを使用します。これは論理的なリージョナルルーターとして機能し、1つまたは複数のルートテーブルを持つことができます。 VPCに接続する際は、ルーターインターフェースとして機能するアタッチメントを作成します。これらのアタッチメントは、特定のルートテーブルに関連付けられ、その関連付けによってVPCからのトラフィックの扱い方が決定されます。
AWS Cloud WANを用いたグローバルネットワーキングとFirewall導入
アタッチメントを作成すると、Transit Gatewayのルートテーブルに登録されます。また、VPCルートをルートテーブルに自動的に伝播するオプションもあります。ルートテーブルの観点からは、VPC側のすべてのIPv4およびIPv6レンジへの到達方法を把握できます。すべてのトラフィックをTransit Gatewayに送信するデフォルトルートを設定したり、10/8などのアグリゲートを作成してすべてのトラフィックをTransit Gatewayに送信したりすることができます。
ここでのポイントは、VPC内のルーティングをシンプルに保ち、複雑さはTransit GatewayやCloud WAN（これについてはAnkitが後ほど説明します）に任せることです。VPC内のルーティングはできるだけシンプルにすべきで、複雑にしすぎないようにしましょう。Transit Gatewayは、オンプレミスへのハイブリッド接続も集約することができます。ただし、Transit Gatewayを経由するトラフィックには追加の処理料金がかかるので、料金ページを確認しておくことをお勧めします。
Transit Gatewayからオンプレミスへの接続にはSite-to-Site VPNを使用できます。Virtual Private Gatewayに接続する場合と比べての利点は、複数のIPsecトンネルを作成してトラフィックを分散できることです。1つのトンネルで1.2ギガビット/秒を処理できることを覚えておられると思いますが、今では10本のトンネルを追加して、VPN経由で10ギガビット以上を実現できます。BGPセッションは引き続き存在し、このBGPセッションを使用してTransit Gatewayルートテーブルにルートを追加し、オンプレミスへの経路を把握します。
反対方向では、最初にお見せしたVPCおよび他のすべてのVPCへのルートが表示され、これらは Transit Gatewayの自律システム番号から来ています。ここで重要なヒントですが、IPv6とIPv4の両方の範囲に接続する必要がある場合は、複数のVPNトンネルを作成する必要があります - IPv4とIPv6用に別々のトンネルが必要です。もう1つのオプションとして、オンプレミス環境への接続にSD-WANを使用することもできます。
SD-WANの場合、お好みのサードパーティベンダーを選択し、AWS内のVPCに2台のアプライアンスとしてヘッドエンドをデプロイし、そのVPCをTransit Gatewayに接続して、Connectアタッチメントを作成する必要があります。これらのConnectアタッチメントは、基本的にGREトンネルです。GREトンネルは別のトンネリングプロトコルで、最大5ギガビット/秒までの速度を実現できるため、IPsecよりも少し高速ですが、暗号化は提供されません。
これらのトンネル上では、Transit GatewayとSD-WANヘッドエンド間でeBGPを使用してルーティング情報を交換しています。そこから、SD-WANヘッドエンドは残りのSD-WANネットワークに接続し、データセンターや必要な支社にも接続します。ルートテーブルでは、オンプレミスへのルートのネクストホップがConnectアタッチメントであることが確認できます。オンプレミス側では、VPCへのルートがSD-WANを経由し、最終的にTransit Gatewayを通ることが分かります。
SD-WANはIBGPとeBGPの両方をサポートしています。シンプルさと一貫性を保つため、eBGPの使用をお勧めします。最後に、Transit GatewayをDirect Connect経由で接続することもできます。Direct Connect gatewayを使用し、今回はTransit virtual interfaceを作成します。これもBGPを実行します。VPCにすべてのルーティング情報が動的に伝播されるのと同じように、オンプレミスのルーターでは、Transit Gatewayが発信するルートが表示されます。
これらのルートは動的にアドバタイズされるのではなく、Transit Gatewayに発信させたいルートを手動で設定する必要があり、そのルート数の制限は200です。つまり、300のVPCがある場合、それらのVPCを最大200のルートに集約できる必要があります。では、ここで複数のパスがある場合はどうなるでしょうか？どのパスが優先され、オンプレミスからはどのパスを優先するのでしょうか？
最後のケースは簡単に解決できます。これもルーターの話で、ロジックはあなたがコントロールできるので、トラフィックの流れ方を決めることができます。Transit Gatewayについては、ドキュメントにルート評価の順序が記載されています。 より具体的なルートがあれば、そちらが優先されます。この場合、同じルートがありますが、Direct Connect gatewayから伝播されたルートが他のものより優先されます。そのため、トラフィックはDirect Connectを使用することになります。
ここでのプロティップは、反対方向についてです - トラフィックを対称的に保つようにロジックを合わせることが重要です。 Direct Connectが優先される場合は、反対方向でもDirect Connectを優先するようにしましょう。もし何らかの理由でDirect Connectが失敗した場合、次に利用可能な接続オプションはTransit Gateway Connect attachmentsです。これらはルーティングテーブルには表示されませんが、引き継ぎを行います。
これは単なるForwarding Information Baseなので、そこに存在し、プライマリルートが消失した場合に引き継ぎます。そして最後に、もしSD-WANに問題が発生した場合、トラフィックはIP VPNの使用に切り替わります。
ここで、インスペクションを追加してさらに複雑にしてみましょう。このシナリオでは、VPCとオンプレミスネットワーク間にインスペクションを追加したいと思います。これを実現するために、複数のルートテーブルを作成します - VPC用のルートテーブルとハイブリッド接続用のルートテーブルで、それぞれの接続からのトラフィックの扱いを制御します。その後、インスペクションVPCを作成し、Transit Gatewayに接続して、独自のルートテーブルに配置します。
Direct Connectを活用したハイブリッドマルチリージョンネットワークの構築
この接続にはAppliance modeが有効になっていることに注目してください。これにより、Transit Gatewayを通過して接続に向かうトラフィックが同じAvailability Zone内に留まることが保証されます。 VPCルートテーブルのルーティングの観点からは、通常オンプレミス向けとなるすべてのトラフィックを静的ルートを使用してインスペクションVPCに送信します。 インスペクション後、トラフィックはすべてのルートが伝播されているインスペクションルートテーブルを使用します。これはクリーンなトラフィックなので、すべてのルートをそこに含めることができます。反対方向では、ハイブリッドルートテーブルに静的ルートがあり、トラフィックをインスペクションVPCに戻します。個々のVPCに対して静的ルートを設定するか、集約ルートを作成することができます。作成したルートはオンプレミスに広告されます。トラフィックは戻ってきて、インスペクションVPCに到達し、インスペクション後にVPCに到達します。
複数のリージョンの追加に移りましょう - 単一のリージョンがどのように見えるかは既に理解しています。2番目のリージョンを追加するのは比較的簡単です。同じTransit Gatewayと複数のVPCを別のリージョンにデプロイし、そのリージョン内のVPC間でトラフィックをルーティングできます。リージョン間でトラフィックを通信する必要がある場合は、リージョンの任意の組み合わせ間でTransit Gatewayのペアリングを作成する必要があります。これらのTransit Gatewayペアリングは現在スタティックルーティングのみをサポートしているため、ペアリングの向こう側にある経路を定義するためのスタティックルートを作成する必要があります。スタティックルーティングとはいえ、ここでのヒントは、Transit Gatewayを作成する際に一意のASNを割り当てることです。将来的にダイナミックルーティングが利用可能になった時点で、これが役立つからです。
リージョン1とリージョン2間のインスペクションの仕組みを見てみましょう。IPsecで行ったのと同じパターンに従うことができます。個々のルートテーブルの詳細には触れません - 概要だけお話しします。トラフィックは両方のリージョンでインスペクションされる必要があります。理論的には1つのリージョンだけを使用するように設定することも可能ですが、それは非常に複雑で、リージョンを追加すればするほど、この作業は不可能に近くなっていきます。
これらは、リージョン間のインスペクションを実現するために必要なすべてのルートの設定です。これは単一リージョン内での異なるタイプやファミリーのVPC間のインスペクションさえカバーしていません。2つのリージョンだけでもここまで多くの設定が必要です - シンプルに保っても6つの異なるスタティックルートを設定する必要があります。そして複数のルートテーブルを作成する必要があります。
ここで、AWS Cloud WANを使用してこのグローバルデプロイメントとインスペクションを実現する方法をAnkitにバトンタッチします。AWS Cloud WANは、数分でマルチリージョンAWSネットワークを作成できるサービスです。まず、Cloud WANの構成要素について説明しましょう。1つ目はCNE（Core Network Edge）です。これはリージョナルな構成要素で、完全にAWSによって管理されています。これは実際にパケットの出入りを制御するエンティティで、内部的にはTransit Gatewayによく似た仕組みと動作をしています。Transit Gatewayに比べての大きな利点は、完全なメッシュeBGPペアリングが、これもまたAWSによって完全に提供・管理されることです。
2つ目の構成要素はセグメントです - セグメントはグローバルなルーティングドメイン、グローバルVRF、またはグローバルルーティングテーブルと考えてください。これらはデフォルトでグローバルです。この例では、Development、Test、Productionという3つのセグメントを示しており、各セグメントは3つの異なるリージョンにまたがっています。セグメントは本質的にグローバルですが、
各セグメントには地域ごとのルーティングビューがあり、それぞれが地域のルーティングテーブルを持っています。 これは、パケットフローの詳細を見ていく際に興味深いポイントとなります。 あらゆるアタッチメントはセグメントに関連付けられます。このダイアグラムを展開してVPCを追加していくと、各VPCにはセグメントの1つに関連付けられたアタッチメントが存在することになります。
最後のCloud WANの構成要素として、ポリシーについて説明します。これはJSONドキュメントで、グローバルネットワーキングポリシー全体を管理します。これにより、デプロイメントを何リージョンに展開するか、アタッチメントポリシーはどうあるべきか、そしてどのアタッチメントをどのセグメントに配置するかといった意図を表現できます。また、トラフィックや個々のルーティングフローにも影響を与えることができ、これについてはパケットフローのセクションで詳しく説明します。
最初のユースケースとして、VPC間のリージョンをまたぐ同一セグメントルーティングについて見ていきましょう。この場合、異なるリージョンに2つのVPCがあり、両方ともDEVセグメントに関連付けられています。先ほど説明したように、セグメントには地域ごとのルーティングビューがあるため、このDEVセグメントはリージョン1にルーティングテーブルを持ちます。リージョン1のVPC CIDRが表示されるのは予想通りですが、さらにリージョン2のVPC CIDRも表示されます。これがリージョン1からリージョン2へトラフィックを送信できるようにする伝播ルートです。同様に、リージョン2のDEVセグメントのルーティングテーブルにも対応するルートが存在します。これらの2つのハイライトされたルートにより、静的ルートを設定することなく双方向の通信が可能になります。
AWS Cloud WANとDirect Connectを組み合わせたグローバルネットワーキング
このシナリオを拡張して、異なるセグメント間のVPCについて説明すると、図は次のようになります：左側にDEV VPC、右側に異なるリージョンのTest VPCがあります。上部にはDEVセグメントのルーティングテーブルがあり、予想通りDev VPCのCIDRのみが表示されます。下部にはTestセグメントのルーティングテーブルがあり、Test VPCのCIDRのみが表示されます。
これら2つのセグメント間、またはこれらのセグメントに接続されているVPC間の接続性を提供するために、Cloud WANポリシーを使用します。セグメントアクションを定義し、DEVセグメントとTestセグメント間ですべてのアタッチメントルートを共有したい旨を指定します。このポリシーを実行すると、ルーティングテーブルに新しいルートが表示され始めます。これらが新しいルートです。DEVセグメントのルーティングテーブルを確認すると、Test VPCのCIDRが表示されるようになります。下部では、TestセグメントのルーティングテーブルにDEV VPCのCIDRが表示されるようになります。これがAWS Cloud WANを使用して、異なるセグメント間でマルチリージョンの動的な接続性を実現するメカニズムです。
いくつか重要なポイントがありますので、ご留意ください。まず、ルートの共有は双方向に機能します。つまり、2つのSegmentがルートを共有する場合、それぞれのSegmentが互いのすべてのルートを参照できます。 次に、ルートの共有は推移的ではありません。つまり、3つ目のSegmentを作成してTestのSegmentと共有した場合、その3つ目のSegmentはTestのSegmentのルートのみを参照できます。
これをさらに発展させて、Firewallとインラインのトラフィックアプライアンスを導入してみましょう。このユースケースでは、左側にDEV VPC、右側にTest VPC、そしてリージョナルなFirewallスタックが必要です。これらのFirewallスタックは、Network Functions Group（NFG）と呼ばれる新しいタイプのSegmentに関連付けられます。このNFGはAWSによって管理されるSegmentで、このSegment内のルーティングは完全にAWSによって制御・管理されます。ただし、既存のルートを確認したい場合のために、ルートの可視性は維持されています。
Inspection VPCはNFGに関連付けられます。ルーティングテーブルを見てみましょう。上部にDEV Segmentのルーティングテーブルがあり、下部には Test Segmentのルーティングテーブルがあります。要件は、これらのSegment間の直接接続からFirewallを介した接続へと進化しました。これは前のユースケースとは異なるアプローチなので、ルート共有を無効にしています。このFirewallを導入するために必要なポリシーアクションを見てみましょう。 DEV Segmentから発信されTestのSegmentに向かうすべてのトラフィックを、
NFGと呼ばれるNetwork Functions Groupを経由して送信するように指定します。 ここでの重要なポイントは、静的ルートが一切不要だということです。先ほどTomが、マルチリージョンの接続にTransit Gatewayを使用する場合のInspectionについて触れましたが、Transit Gatewayでは各リージョンでFirewall Inspectionを実行することがベストプラクティスとされています。
AWS Cloud WANでは、Modeと呼ばれる設定を使用することで、シングルFirewallとダブルFirewallのどちらのInspectionを実行するか選択できます。Single hopモードは、1つのリージョンでのみFirewall Inspectionを実行したい場合に使用します。Firewall Inspectionを実行したいリージョンを指定することもできますし、指定しない場合はAWSが決定論的に1つのリージョンを選択します。パケットの流れを詳しく見てみましょう。Single hopを使用しているため、 Firewallスタックの1つを削除することができ、これによってコスト削減の可能性があります。
ポリシーを実行すると、新しいルートが表示されます。DEVセグメントのルートを見てみると、テストVPCのCIDRが表示され、ネクストホップは検査用VPCのものとなっています。これがDEV VPCからトラフィックをファイアウォールVPCに送信するルートです。ファイアウォールが検査を実行しますが、重要なのは、トラフィックの対称性を保つために、検査用VPCに向かうVPCアタッチメントでアプライアンスモードを有効にする必要があることです。ファイアウォールからの戻りトラフィックは、AWSが管理するNetwork Functions Groupsのルーティングテーブルで検索されます。
ルートは、トラフィックを第2のリージョンに配信する必要があることを認識しているため、トラフィックは第2のリージョンのCNEに向かいます。これはNFGのルーティングテーブルで検索され、トラフィックはテストVPCに配信される必要があることがわかります。戻りトラフィックについては、テストセグメントのルーティングテーブルで検索が行われます。下部にはDEV VPCのCIDRに対するルートが表示され、ここでもネクストホップは検査用VPCとなっています。このルートによって、トラフィックは同じファイアウォールVPCに戻されます。アプライアンスモードが有効になっているため、トラフィックは同じファイアウォールアプライアンスに対称的に配信され、ファイアウォールはフローの両側を確認することができます。
ファイアウォールが検査を実行し、トラフィックをNFGに送り返します。NFGはトラフィックをDEV VPCに送信する必要があることを理解します。これで、今年初めにリリースされた新しいサービス挿入機能を使用したCloud WANによるトラフィック検査のパケットウォークが完了します。完全を期すために、もう1つのルートが追加されていますが、このトラフィックフローではこのルートは考慮していません。
プロのためのヒントをご紹介します：まず、ルートの共有とsend viaアクションは相互に排他的です。直接接続が必要な場合はルートを共有し、インラインアプライアンスを挿入したい場合はsend viaを使用します。次に、シングルホップを使用する場合は、どのリージョンのファイアウォールを使用するかを必ず定義してください。指定しない場合、AWSは決定論的に1つのリージョンを選択しますが、そのリージョンのファイアウォールに負荷が集中するリスクがあります。この設定全体を、静的ルートを一切使用せずに複数のリージョンにデプロイできることを覚えておいてください。
Direct Connectのレジリエンシーとパブリックリソースへのアクセス
過去15-20分間で、同じユースケースを実現するためのTransit GatewayとCloud WANの使用方法について説明してきました。こちらが比較スライドです。詳細には触れませんが、写真を撮りたい方のために5秒間停止します。ここで話題を変えて、Direct Connect経由のハイブリッドマルチリージョンネットワークシナリオについて説明していきます。先ほど述べたように、これらはお客様との対話に基づいて厳選したシナリオです。
Direct Connectのレジリエンシーについて説明しましょう。先ほど見ていただいた図では、左側にAWSのデプロイメント、中央にDirect Connect、右側にデータセンターが配置されていました。まず、Direct Connect gatewayを複数のTransit Gatewayに関連付けることで、複数のリージョンに拡張し、各Transit Gatewayの背後には、それに接続されたVPCがあります。レジリエンシーを考える上で重要なのは、その点線の下で何が起きているのかを理解することです。
その仕組みを紐解いていきましょう。Direct Connectを調達すると、Direct Connectロケーション内のAWSルーターとカスタマールーター間に物理的な光ファイバー接続が提供されます。これが整うと、VIFとBGPペアリングの組み合わせである Transit Virtual Interfaceの作成を開始できます。
BGPが確立すると、ルートの交換を開始できます。ラストマイル接続については、ダークファイバーを持ち込むか、パートナーと協力してDirect Connectロケーションへの接続を提供することができます。このセットアップは機能しますが、AWSルーターとカスタマールーター間のリンクという単一障害点の影響を受けやすい状態です。私たちは事前に通知してAWSルーターの定期的なメンテナンスを実施していますので、このようなデプロイメントでは、いずれかの時点でダウンタイムが発生することは避けられません。
これを防ぐために、同じDirect Connectロケーション内で構成を複製し、別の回線を調達してTransit VIFを作成し、ベストプラクティスとしてラストマイル接続を別のカスタマールーターで終端することができます。ただし、この場合でも、可能性は低いものの、Direct Connectロケーション自体が障害を起こすというコーナーケースのリスクは残ります。これに対処するために、別のDirect Connectロケーションにこのデプロイメントを複製し、2つのリンクを取得して2つのVIFを作成し、ラストマイル接続を異なるカスタマールーターで終端することができます。この構成により、リンク障害、ルーター障害、Direct Connectロケーション障害から保護されます。
ハードウェアとDirect Connect接続に多大な投資をした後、設定面でのレジリエンシーに関する重要なヒントがあります。それは、複数のVIFで同じプレフィックスをアドバタイズすることで、論理的な冗長性も確保するというものです。2つのロケーションにまたがる4つのDirect Connect接続を持つこのシナリオが、これから説明するルーティングシナリオのベースラインとなります。各Direct Connectロケーションには関連するAWSリージョンがあり、ロードバランシングの説明に入る際にその情報について詳しく見ていきます。
最初のユースケースである、オンプレミスからS3へのアクセスについてお話ししましょう。デプロイメントの観点から見ると、これは2つのロケーション間の接続の基本形であり、オレンジの線はPublic VIF （パブリック仮想インターフェース）を表しています。これもBGPペアリングの一種です。このユースケースでは、オンプレミスから複数のリージョンにホストされているS3バケットへの双方向接続を提供します。Public VIFもBGPの上で動作するため、どのようなルート交換が行われるのか見ていきましょう。
BGPセッションが確立すると、Bring Your Own IPアドレスを含む、すべてのAWSパブリックプレフィックスが見えるようになります。オンプレミスのルーターのルーティングテーブルを確認すると、すべてのパブリックプレフィックスが表示されます。ネクストホップはDirect Connectに面したインターフェースとなり、パスにはAmazonのパブリックASNである7224が含まれることになります。その後、AWSからの戻りの通信のために、自身のパブリックプレフィックスのアドバタイズを開始できます。
ここでのプロティップは、Public VIFをその他のインターネット向け接続と同様に扱うということです。パブリック接続に対して特定のセキュリティ対策を実施している場合は、Public VIFに対しても同様の対策を適用することをお勧めします。BGPが確立すると、AWSのパブリックプレフィックスが見え、自身のパブリックプレフィックスを私たちにアドバタイズし始めます。もう一つのプロティップは、Public VIFでのロードバランシングは、同じ関連付けられたリージョン内でのみ許可されるということです。つまり、2つのロケーションが同じAWSリージョンに関連付けられている場合にのみ、それらの間でロードバランシングを行うことができます。Direct ConnectロケーションがどのAWSリージョンに関連付けられているかを理解するには、ドキュメントを参照してください。
プライベート接続とトラフィックエンジニアリングの基礎
次に、プライベート接続について詳しく見ていきましょう。先ほど、S3バケットなどのパブリックリソースへの接続方法について説明しました。今度は、オンプレミスデータセンターからVPCへの接続を拡張します。基本的なシナリオに戻ると、3つのリージョンがあり、各リージョンにはRegional Transit Gatewayがあり、2つのロケーションにまたがるDirect Connect接続用のDirect Connect Gatewayに関連付けられており、そしてデータセンターがあります。先ほどTransit GatewayとDirect Connect Gatewayの関連付けについて説明したように、Allowed Prefixesを設定する必要があります。ここでの制限は、関連付けごとに200プレフィックスです。
ここでのプロティップは、Allowed Prefixesの設定では重複が許可されないということです。画面に表示されているように3つの異なるTransit Gatewayがある場合、各関連付けから発信されるプレフィックスは一意である必要があります。オンプレミスのルーターを確認すると、Transit Gateway発信のルートが表示されます。ネクストホップはDirect Connect向けのインターフェースとなり、パスにはDirect Connect Gatewayの ASNのみが含まれることになります。
対照的に、AWS Cloud WANを使用した場合の実装方法を見てみましょう。基本的な構成は同じですが、リージョナルなTransit Gatewayの代わりに、グローバルなAWS Cloud WANのデプロイメントを使用し、各Core Network Edge（CNE）がDirect Connect gatewayへの関連付けを持つという点が異なります。
この場合、Transit Gatewayベースのデプロイメントと比較して2つの重要なメリットがあります。1つ目のメリットは、すべての関連付けに対して許可されたプレフィックスを設定する代わりに、最大5000ルートまで双方向の動的ルーティングが自動的に得られることです。つまり、より高い制限で動的ルーティングが実現できます。2つ目のメリットは、AWS Cloud WANでは、Direct Connect gatewayがCNEのASNを隠蔽しないことです。オンプレミスのルーターを確認すると、AS pathにCNEのASNとDirect Connect gatewayのASNの両方が表示されます。これにより、デバッグ時やルートの発信元を特定する際に、より詳細な可視性が得られます。
AWS Cloud WAN、Direct Connect gateway、Direct Connectを使用したこのグローバルデプロイメントを基盤として、トラフィックにどのように影響を与えることができるか見ていきましょう。例えば、AWSからオンプレミスへトラフィックを送信する際に、常に上部のリンクを優先したい場合を考えてみます。最も簡単なアプローチは、より具体的なルーティングを使用することです。上部のリンクから/24を、他のリンクから/16をアドバタイズします。前のセクションで説明したように、より具体的なルーティングが常に優先されます。これにより上部のリンクが常に優先されますが、各接続からより具体的なルートを送信できない場合も多くあります。
各リンクからサマリーのみをアドバタイズできるお客様も多くいらっしゃいます。そのような場合、AWSからオンプレミスへのトラフィックに影響を与えるために、AS path prependingやLocal preferenceなどのBGP属性を使用できます。これは特に重要です。なぜなら、逆方向（オンプレミスからAWSへ）については、常に自身のルーター上でBGP属性を使用してトラフィックに影響を与えることができるからです。まずAS path prependingについて見ていきましょう。上部にNetwork Aがあり、下部にAWSのルーターがあるシナリオを考えてみます。このネットワークに到達するための2つの経路があり、BGP属性を使用して一方の経路を他方より優先させたい場合です。
AS path prependingでは、Router 1はAS pathの長さが1でプレフィックスをアドバタイズし、Router 2では同じプレフィックスをパス長2でアドバタイズできます。このルーターのルーティングテーブルを確認すると、Router 1を経由するルートの方がホップ数が少ないと認識し、常にそのパスを優先します。ルートを優先順位付けしたり、トラフィックの経路に影響を与えたりするための2つ目のメカニズムは、Local preferenceの使用です。Direct Connectの世界では、Local preferenceに変換されるBGP Communitiesがあります。
シナリオは同じで、Network Aと2つのパスを持つAWS Routerが下部にあります。Router 1からの左側のパスでは、コミュニティ値7100（Local Preferenceの値が低いことを意味する）を付与してプレフィックスをアドバタイズします。一方、右側では同じプレフィックスをBGP Communityタグ7300（Local Preferenceの値が高いことを意味する）で広告します。BGPテーブルを確認すると、このAWS Routerは常により高いLocal Preferenceを持つ右側のルートを優先します。BGP Communityの正確な文字列についてはAWSのドキュメントで確認できます。
これでAWSからオンプレミスへのパスに影響を与える2つのメカニズムができました。では、どのような場合にどちらを使うべきでしょうか？様々な組み合わせが可能ですが、シンプルな判断基準をご紹介します：AS Path Prependingは同じDirect Connect locationでパスに影響を与えたい場合に使用し、Local Preferenceは複数のDirect Connect location間でパスに影響を与えたい場合に使用します。プロのヒントとして：両方のメカニズムを設定した場合、Local PreferenceはAS Path Prependingよりも常に優先されます。
高度なトラフィックエンジニアリングとセッションのまとめ
トラフィックエンジニアリングの演習のため、シナリオに戻りましょう。まず、4つのDirect Connect接続にナンバリングを行い、Direct Connect Location 1をDirect Connect Location 2よりも常に優先するという大まかな要件があります。Locationをまたぐトラフィックエンジニアリングなので、Local Preferenceを使用できます。
これを実装するために、上部2つの接続から同じサマリールートをコミュニティ値7300（高いLocal Preference）で広告できます。下部では同じプレフィックスを低いLocal Preference、つまりコミュニティ値7100で広告します。これによりDirect Connect Location 1が常に優先されることが保証されますが、さらに具体的に、Link 1とLink 2の間ではLink 1を常に優先したいとします。
ここで同じLocation内でのトラフィックエンジニアリングについて話します。これこそAS Path Prependingを使用するべき場面です。上部のLink 1からはAS PATHの長さを1で広告し、2番目のリンクではAS Path Prependingを使用します。この設定により、Link 1とLink 2の間では常にLink 1が使用され、Link 1がダウンした場合にLink 2が使用されます。
まとめを見てみましょう。最初にAWSが提供するルーティングの基本要素について説明しました。その後、ルーティングのシナリオを見ていきました。まず単一のVPCから始めて、Tomが、VPCのSubnetルーティングテーブルの仕組みや、Static Route、Propagated Route、Dynamic Routeの作成方法について説明しました。その後、範囲を広げて、同一リージョン内の複数のVPCを接続しました。インラインのFirewallを導入し、さらに複数のリージョンにまたがる複数のVPCへと拡張しました。最後に、高度なハイブリッド接続について説明し、マルチリージョンやマルチDirect Connectに関連するシナリオについて説明しました。そして、22個のPro Tipをご紹介しました。
以上で、Tomとわたしからのプレゼンテーションを終わらせていただきます。本日は最後までご視聴いただき、ありがとうございました。今回は特にPro Tipという新しい試みを取り入れてみました。もしよろしければ、アプリを使って感想をお聞かせください。改善のためのフィードバックもお待ちしております。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion