Amazon Web Services ブログ

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 に入ります。リクエストルーターに転送され、さらに Primary ENI を通じて特定の Fargate タスクにリクエストをルーティングします (図 1の太いオレンジ色の矢印)。レスポンスは同じ経路をたどって戻っていきます。
  • アプリケーションのアウトバウンドトラフィック: アプリケーションを起点とするすべてのアウトバウンドトラフィックは、Fargate タスクの Primary ENI から App Runner VPC に用意された NAT ゲートウェイとインターネットゲートウェイを介してインターネットにルーティングされます (図 1 の緑の太字の矢印)。パブリックネットワーキングモードでは、アプリケーションからのアウトバウンドトラフィックはお客様の VPC のプライベートエンドポイントに到達できません。アプリケーションからお客様 VPC にアクセスするためにはパブリックエンドポイントが必要です。
  • コンテナイメージの pull: サービスの作成、更新、デプロイ、スケールアップの際に新しい Fargate タスクが起動されます。Fargate タスクのブートストラップ中、アプリケーションのコンテナイメージは Primary ENI を介して Amazon ECR から pull されます (図 1 の細い緑の矢印)。
  • ログのプッシュ: アプリケーションログも Primary ENI 経由で Amazon CloudWatch にプッシュされます (図 1 の細い緑色の矢印)。

ご覧のとおり、パブリックネットワーキングモードでは、すべてのトラフィックフローが 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"
  ]
}
EOF

aws apprunner create-vpc-connector \
--cli-input-json file:///vpc-connector.json

cat > service.json <<EOF
{
    "ServiceName": "my-vpc-connected-service",
    "SourceConfiguration": {
        "ImageRepository": {
            "ImageIdentifier": "<ecr-image-identifier>",
            "ImageConfiguration": {
                "Port": "8000"
            },
            "ImageRepositoryType": "ECR"
        }
    },
    "NetworkConfiguration": {
        "EgressConfiguration": {
            "EgressType": "VPC",
            "VpcConnectorArn": "arn:aws:apprunner:..../my-vpc-connector"
        }
    }
}
EOF

aws apprunner create-service \
--cli-input-json file:///service.js

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 ネットワーキングモードでのトラフィックフローについても確認してみましょう。

  • リクエスト/レスポンスのトラフィック: Fargate タスクは、パブリックネットワーキングモードと同様に App Runner VPC 内の Primary ENI で構成されます。サービス URL に送信されたリクエストは、パブリックネットワーキングモードと同じルートで App Runner VPC 内にある NLB、リクエストルーター、Primary ENI を経由して Fargate タスクまで送られます (図 3 のオレンジ色の太い矢印)。これは、インバウンドトラフィックが VPC を通過しないため、VPC Connector セキュリティグループのインバウンドルールが関係ないことを意味します。
  • アプリケーションのアウトバウンドトラフィック: アウトバウンドトラフィックのために、Fargate タスクは Primary ENI に加えて Secondary のネットワークインターフェイスを設定します。アプリケーションコンテナを起点とするすべてのネットワークトラフィックは、この Secondary インターフェースにルーティングされ、そこから Fargate 側の Hyperplane ENI に転送され、Hyperplane のデータプレーンを経て、お客様 VPC の Hyperplane ENI に転送されます。お客様 VPC に入ると、トラフィックは お客様 VPC のルーティングテーブルに従って宛先のエンドポイントに転送されます (図 3 の緑の太字の矢印)。インターネット向けのトラフィックがある場合、VPC の NAT ゲートウェイとインターネットゲートウェイを経由して適切なパスを有効にする必要があることに注意してください。
  • コンテナイメージの pull: ECR からのコンテナイメージの pull はパブリックネットワーキングモードと同様に、App Runner VPC 内の Faragate タスクの Primary ENI を経由します (図 3 の細い緑色の矢印)。コンテナイメージを pull するために VPC で特別なパスを有効にする必要はありません。
  • ログのプッシュ: パブリックネットワーキングモード同様に、CloudWatch Logs へのログのプッシュも App Runner VPC 内の Fargate タスクの Primary ENI を経由します。VPC 内で特別なパスを有効化する必要ありません (図 3 の細い緑色の矢印)。

図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 ネットワーキングモードでのサービスのスケール

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

  • お客様 VPC での IP アドレス消費量の削減: Hyperplane ENI は共有されるため、リクエストの負荷を処理するために必要な Fargate タスクの数を増やしても、通常、サービスごとに必要になる ENI はごくわずかです。複数の App Runner サービスで同じ VPC Connector を参照する場合、基盤となる Hyperplane ENI はこれらのサービス間で共有され、VPC の IP スペースを効率的に使用できるようになります。
  • Fargate タスクのブートストラップ時間の短縮: Hyperplane ENI はサービスが VPC Connector に関連付けられたときに一度だけ作成されます。スケールアップやデプロイのために起動する後続の Fargate タスクは、事前に作成された ENI へのトンネルを確立するだけです。Fargate タスクのブートストラップ中に発生する Secondary ENI のプロビジョニング時間を短縮することができます。

まとめ

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

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

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