アイリッジ開発者ブログ

アイリッジに所属するエンジニアが技術情報を発信していきます。

App RunnerはECS for Fargateを置き換える存在になるか

こんにちは!開発部でインフラエンジニアを担当している斎藤です。

今回、AWS App Runnerに少し触れてみたので、その所感をまとめたいと思います。App Runnerの登場は 2021年5月19日でして、サービスとしては1周年が経過した状態になっています。そろそろ真面目に検証してもいい時期かな? と感じまして、ECS for Fargateとどう違うのか、どう使い分けるのかを考えていきたいと思います。

目次

App Runnerってどんなサービス?

App Runnerは、コンテナを実行できるサービスの一つです。EC2やECS、Lambdaと同じコンピューティングサービスに分類されるサービスですね。AWSにはコンテナを実行できるサービスとしてECS、EKSがすでに存在しています。App RunnerはECSやEKSの仲間として新たに加わったサービスとなります。

App RunnerがECSやEKSと違うのは特に以下の点です。

ソースコードのみからでもコンテナを展開できる

App Runnerでは、コンテナイメージからコンテナを展開するだけではなく、GitHub上にあるソースコードから自動的にソースコード実行に必要なコンテナをビルドして、展開することも可能です。これにより、利用者はDockerコンテナのメンテナンス作業から解放されます。

コンテナ実行インフラは完全に隠蔽されている

ECSやEKSでは、コンテナの実行・アクセスに必要な以下のインフラを明示的に作成する必要があります。

  • VPC、サブネット、インターネットゲートウェイ
  • ECS、EKSクラスタ
  • コンテナを実行するEC2インスタンス (EC2タイプを選択する場合)
  • ALBなどのロードバランサ

App RunnerですとこれらのリソースはAWSでの管理となり、ユーザはこれらのリソースを作成、管理する必要はありません。

これは実行インフラやその管理を意識しなくていいというメリットがある反面、細かい融通を利かせることができないというデメリットもはらんでいます。

App RunnerとECS for Fargateとの比較

さて、AWSに極力コンテナ実行基盤の管理を任せる方法ですと、従来ではECS for Fargateという選択肢が有力だったのですが、これとApp Runnerとの違いはどうなっているでしょうか。違いをまとめた表は以下の通りです。

要件 App Runner ECS for Fargate
パスベースルーティング可能か ×
タスクの概念があるか ×
Private ECRレポジトリからのプルが可能か
VPC内リソースとの通信が可能か
オートスケールが可能か △(スケール用のメトリクスはAWS任せ)
VPC・ECSクラスタの準備が不要か ×
ジョブスケジューリング可能か ×
NATゲートウェイによる固定IP設定が可能か
カスタムドメインが利用可能か △(デフォルトで自動化はサポートされない)
X-Rayとの連携が可能か
セキュリティグループによるアクセスコントロールが可能か △(outboundのみ可能)
  • パスベースルーティングが可能か

    ECSではALBがユーザ管理対象になっているため、当然パスベースルーティング設定可能ですが、App Runnerではロードバランサをユーザが操作することができないため、不可能になっています。

  • タスクの概念があるか

    複数のコンテナを一つの空間にまとめて起動できる概念である、ECSのタスクですが、App Runnerにはこの概念はなく、スタンドアローンでコンテナを1種類実行するのみになっています。

  • Private ECRリポジトリからのプルが可能か

    こちらはECS、App Runnerともに可能です。ただし、App RunnerはECRに存在するコンテナイメージの起動しかサポートしていない点に注意です。

  • VPC内リソースとの通信が可能か

    ECSはVPC内で実行されるため当然可能ですが、App RunnerはAWSの管理ネットワーク内で起動されるため、そのままではVPC内リソースと通信できません。App RunnerではVPC Connectorという機能を使って、VPCにApp Runnerサービスを接続することにより、VPC内リソースとの通信をサポートします。

  • オートスケールが可能か

    ECSもApp Runnerもオートスケールが可能です。ただし、ECSではオートスケールに利用するメトリクスを自身で選択できるのに対し、App Runnerでは同時リクエストベースのオートスケールしかできないため、事前に要件を満たすか確認する必要があります。

  • VPC・ECSクラスタの準備が必要か

    前節でも述べた通り、App Runnerでは実行インフラの構築・運用管理はAWS任せになるため、不要になります。

  • ジョブスケジューリング可能か

    ECSではcronによるジョブスケジューリングをサポートしていますが、App Runnerにはこの機能はありません。

  • NATゲートウェイによる固定IP設定可能か

    App RunnerでNATゲートウェイをサポートするには、VPC Connectorを用いてNATゲートウェイへのデフォルトルートが存在するプライベートサブネットにApp Runnerサービスを接続する必要があります。

  • カスタムドメインが利用可能か

    ECSではALBがRoute 53との連携によりカスタムドメインをサポートしますが、App Runnerでも同様にカスタムドメインがサポートされています。ただし、手動でHTTPS通信するときの証明書に対するDNS検証のために、手動でTXTレコードをホストゾーンに追加する必要があり、デフォルトではCloudFormationやCDKを使った自動化がサポートされていません。やるとすると自前でカスタムリソースを定義することになるかと思います。

  • X-Rayとの連携が可能か

    これはECS、App Runnerともにサポートしています。

  • セキュリティグループによるアクセスコントロールが可能か

    App Runnerはアクセスエンドポイントが必ずインターネットにさらされることと、ロードバランサのセキュリティグループがAWS管理になるため、inboundのアクセスコントロールをすることができません。一方でoutboundに対しては、VPC Connectorを用い、その際にVPC Connectorに接続するセキュリティグループを指定することにより、アクセスコントロールを行うことが可能になります。

現時点での所感

今回App Runnerを調査して、現時点で本番投入は、きめ細やかな制御が可能なECS for Fargateになってしまうのかなと思いました。特にパスベースルーティングが不可能なことや、管理画面用にinboud IPを絞りたいというときにセキュリティグループを設定することができないことが致命的です。

一方で簡易的なWebサービスをさっと上げるためには、App Runnerはうってつけのサービスといえます。リッチなCaaS(Container as a Service)やPaaSに近い感じですね。

プロジェクトで利用するツールなどをApp Runnerを使ってさっと上げる、とにかく公開してフィードバックを得る、なんて使い方には積極的に利用できるサービスなんじゃないでしょうか。