AWS App Runner の VPC ネットワーキングに Dive Deep する

この記事は Deep Dive on AWS App Runner VPC Networking を翻訳したものです。

2021 年に発表された AWS App Runner は、Web アプリケーションや API サーバーを稼働させるためのフルマネージドサービスです。App Runner はお客様の AWS アカウントのインフラストラクチャをほとんど(またはまったく)使用せずに、安全な Web サーバーアプリケーションを構築および実行するための手順を大幅に簡素化します。お客様のソースコードやコンテナイメージを使用して、AWS クラウド上でアプリケーションコンテナをビルド・デプロイし、バックグラウンドで自動的にコンテナ間のリクエストをスケーリング、ロードバランスしてくれます。お客様が意識するのは、HTTPS リクエストを受けるサービスの URL だけです。

先日、AWS は App Runner サービスの VPC サポートを発表しました。これまで App Runner でホストされているアプリケーションは、インターネット上のパブリックエンドポイントにのみ接続することが可能でした。この新しい機能により、アプリケーションは Amazon RDS データベース、Amazon ElastiCache クラスター、または VPC でホストされている他のプライベートサービスなど、VPC 内のプライベートリソースに接続できるようになりました。この記事では、App Runner のバックグラウンドを紹介し、App Runner でホストされているアプリケーションと VPC 間のネットワーク接続、特に VPC で作成されたネットワークインターフェースとその上を流れることが予想されるトラフィックフローの詳細について説明します。

VPC アクセスの詳細に入る前にまず、この新しい機能が開始される前から存在しているデフォルトのパブリックネットワークモードでの App Runner の内部動作を確認しましょう。

パブリックネットワーキングモード

App Runner でサービスを作成すると、バックグラウンドでは次のようなことが行われます。アプリケーションコンテナを Amazon Elastic Container Service によってオーケストレーションされた AWS Fargate タスクとして、App Runner が所有する VPC にデプロイします。App Runner が所有する VPC 内には、リクエストを受けるインターネット向けの Network Load Balancer (NLB) と、リクエストを適切な Fargate タスクに転送するレイヤー 7 のリクエストルーターがあります。Fargate タスク自体は Fargate が所有する VPC で動作する Firecracker microVMs でホストされます。Fargate タスクは awsvpc ネットワークモードで起動され、App Runner VPC と相互接続されます。つまり各 Fargate タスクには、App Runner VPC の Elastic Network Interface (ENI) がアタッチされます。これを Fargate タスクの Primary ENI と呼びます。リクエストルーターは、その Primary ENI のプライベート IP アドレスを介して、各 Fargate タスクにプライベートアクセスします。実際、ENI は双方向であるため、Fargate タスクとのすべてのネットワークトラフィックは Primary ENI を通過します。このトラフィックの流れは 4 つに分類されます。

ご覧のとおり、パブリックネットワーキングモードでは、すべてのトラフィックフローが App Runner VPC を介して完全にバックグラウンドでサポートされます。お客様は、VPC アクセスを必要としない、アウトバウンドのインターネットアクセスのみを必要とするアプリケーションをデプロイするために、お客様の AWS アカウント内に VPC やネットワーキングリソースをプロビジョニングする必要はありません。

図1: パブリックネットワーキングモードのアーキテクチャ

しかし、多くのアプリケーションはプライベートリソースのエコシステムで運用されており、お客様の VPC へのアクセスが必要です。以下のセクションでは、既存のアーキテクチャでこの機能を実現する方法について説明します。

VPC ネットワーキングモードの紹介

VPC へのアウトバウンドアクセスを持つアプリケーションを App Runner 上にデプロイするには、まず、アプリケーションと関連付ける 1 つ以上のサブネットとセキュリティグループを指定して、VPC Connector を作成する必要があります。次のように CLI を使用して Create/UpdateService で VPC Connector を参照できます。

cat > vpc-connector.json << EOF{"VpcConnectorName": "my-vpc-connector","Subnets": [ "subnet-a", "subnet-b", "subnet-c"],"SecurityGroups": [ "sg-1", "sg-2"]}EOFaws apprunner create-vpc-connector \--cli-input-json file:///vpc-connector.jsoncat > service.json

VPC Connector のサブネットにマッピングされたアベイラビリティゾーンには、バックグラウンドで起動した Fargate タスクが均等に分散されています。高可用性を担保するために、少なくとも 3 つのアベイラビリティゾーン (リージョンで提供されるアベイラビリティゾーンが 3 つ以下の場合はサポートされるすべてのアベイラビリティゾーン) にまたがるサブネットを選択することをお勧めします。

セキュリティグループに関しては、VPC Connector はアプリケーションからのアウトバウンド通信にのみ使用されることに注意することが重要です (この理由については後ほど詳しく説明します)。従って、セキュリティグループのインバウンドルールは使用されず、事実上無視されます。重要なのはアウトバウンドルールであり、宛先のエンドポイントへの通信を許可する必要があります。また、図 2 に示すように、宛先リソースに関連するセキュリティグループには、VPC Connector のセキュリティグループからのトラフィックを許可する適切なインバウンドルールがあることを確認する必要があります。

図2: VPC Connector の設定

VPC ネットワーキングモード詳解

ここで、お客様の VPC と、Fargate 所有の VPC 内で動作するアプリケーションコンテナとの接続がどのように確立されるのか Dive Deep していきましょう。VPC ネットワーキングモードで使用している技術は AWS Hyperplane です。AWS Hyperplane は、AWS が提供する多くのネットワークサービスを支えてきた内部サービスです。特に、AWS Private Link や AWS Lambda VPC networking の VPC 間接続をサポートしており、アプリケーションタスクをホストする VPC と Fargate VPC の間の接続を確立するというユースケースに完全に適合しています。Hyperplane を選択した理由については次のセクションで詳しく説明しますが、まずは VPC ネットワーキングモードのアーキテクチャを理解していきましょう。

VPC Connector を作成し、それをサービスに関連付けると、Hyperplane ENI と呼ばれる特殊なタイプの ENI がお客様のサブネットに作成されます。同様に、Fargate タスクの microVM をホストする Fargate のサブネットにも Hyperplane ENI が存在します。Fargate タスクが起動すると、2 つの Hyperplane ENI 間でトンネルが確立され、VPC 間の接続が作成されます。

VPC 内に作成された Hyperplane ENI は、サブネットの CIDR レンジからプライベート IP アドレスが割り当てられるという点で通常の ENI と非常によく似ています。しかし、注意すべきいくつかの重要な違いがあります。Hyperplane ENI は、App Runner によってそのライフサイクルが制御されるマネージドなネットワークリソースです。ENI を表示し、そのフローログにアクセスすることはできますが、ENI をデタッチしたり、削除することはできません。Hyperplane ENI のもう 1 つの特徴は、通信が単一方向であるという点があります。アプリケーションを起点とするアウトバウンドトラフィックのみをサポートします。そのため、Hyperplane ENI の IP アドレスにインバウンドリクエストを送信することはできません。アプリケーションへの受信リクエストは、パブリックネットワーキングモードと同様にサービスの URL を経由して送られてきます。VPC ネットワーキングモードでのトラフィックフローについても確認してみましょう。

図3: VPC ネットワーキングモードのアーキテクチャ

AWS Hyperplane for VPC ネットワーキングモードのメリット

ここまで Hyperplane ENI について説明してきましたが、なぜ通常の ENI ではなく Hyperplane を使って VPC への接続を確立することにしたのでしょうか？Hyperplane は、高スループットと低レイテンシーのネットワーク仮想化機能を提供します。Hyperplane ENI では、Fargate タスクごとに 1 つ作成される通常の ENI と比較して、より高度な共有を実現します。Hyperplane ENI は、サブネットと 1 つまたは複数のセキュリティグループの組み合わせに関連付けられます。同じ組み合わせを共有する Fargate タスクは、同じ Hyperplane ENI を介してトラフィックを送信できます。この例では、VPC Connector で指定したセキュリティグループは、App Runner サービスに属するすべての Fargate タスクに同じものが適用されます。VPC Connector には複数のサブネットが存在する可能性があるため、サブネットごとに Hyperplane ENI が作成されます。Fargate タスクはこれらのサブネットに均等に分散され、所定のサブネット内のすべての Fargate タスクは、共有の Hyperplane ENI を介してトラフィックを送信することができます。

前の図 (図 3 ) は、サブネットあたり 1 つの Fargate タスクと Hyperplane ENIのみを簡略化して示したものです。しかし、Hyperplane の利点は図 4 に示すように、サービスがスケールしたときに最もよくわかります。App Runner VPC では Fargate タスクとその Primary ENI (これは Hyperplane ENI ではなく通常の ENI) の間に 1 対 1 の関係がありますが、お客様 VPC ではサブネットごとに 1 つの Hyperplane ENI のみ存在します。そのアベイラビリティゾーン内のすべての Fargate タスクは、お客様 VPC 内の同じ共有の ENI を通じてトラフィックを送信します。

図4: VPC ネットワーキングモードでのサービスのスケール

このアーキテクチャは、お客様にとっていくつかの利点があります。

まとめ

AWS Hyperplane のパワーとスケーラビリティを利用して、App Runner アプリケーションがお客様 VPC 内のプライベートリソースに接続できるこの機能をお届けできることを嬉しく思っています。この機能は App Runner に多く寄せられたご要望の 1 つです。私達はお客様からのフィードバックをお待ちしています。GitHub の App Runner ロードマップにコメントください。この機能を使用してプライベート RDS データベースに接続する Web アプリケーションのセットアップについて説明したブログもぜひご覧ください。

この記事の著者、Archana Srikanta はサーバーレス/コンテナのプリンシパルエンジニアで、AWS Fargate と App Runner のプライマリアーキテクトです。ぜひ彼女の Twitter をフォローしてください。@ArchanaSrikanta

翻訳はソリューションアーキテクト加治が担当しました。原文はこちらです。