コンテナデプロイの簡素化 - AWS App Runner で実現するゼロ設定デプロイ
AWS App Runner を使ったコンテナ Web アプリケーションのデプロイ方法を解説。ECS/Fargate との使い分け、自動スケーリング、VPC 統合、CI/CD パイプラインとの連携まで実践的に紹介します。
App Runner の位置づけとコンテナデプロイの課題
コンテナ化された Web アプリケーションを AWS にデプロイする場合、従来は ECS (Elastic Container Service) や EKS (Elastic Kubernetes Service) を使用するのが一般的でした。しかし、これらのサービスはクラスター管理、タスク定義、サービス定義、ロードバランサー、ターゲットグループ、セキュリティグループなど多数のリソースを設定する必要があり、インフラの知識が求められます。AWS App Runner は 2021 年にリリースされたフルマネージドのコンテナアプリケーションサービスで、これらの複雑さを完全に抽象化します。ソースコードリポジトリ (GitHub) またはコンテナイメージ (ECR) を指定するだけで、ビルド・デプロイ・スケーリング・ロードバランシング・ TLS 終端のすべてを App Runner が自動的に処理します。開発者はアプリケーションコードに集中でき、Dockerfile さえあればインフラの知識なしに本番環境へデプロイできます。
デプロイ方法とソース設定
App Runner は 2 つのソースタイプをサポートします。1 つ目はコンテナイメージソースで、ECR (パブリックまたはプライベート) のイメージを指定します。ECR へのイメージプッシュを検知して自動デプロイする設定も可能です。2 つ目はソースコードリポジトリで、GitHub リポジトリを接続し、App Runner がビルドからデプロイまでを一貫して実行します。Python と Node.js のマネージドランタイムが提供されており、buildspec.yml 不要でビルドコマンドと起動コマンドを指定するだけで動作します。 ```yaml # CloudFormation での App Runner サービス定義 Resources: AppRunnerService: Type: AWS::AppRunner::Service Properties: ServiceName: my-web-app SourceConfiguration: AuthenticationConfiguration: AccessRoleArn: !GetAtt AppRunnerAccessRole.Arn AutoDeploymentsEnabled: true ImageRepository: ImageIdentifier: !Sub '${AWS::AccountId}.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest' ImageRepositoryType: ECR ImageConfiguration: Port: '8080' RuntimeEnvironmentVariables: - Name: NODE_ENV Value: production InstanceConfiguration: Cpu: '1024' Memory: '2048' ``` インスタンス設定では vCPU (0.25 / 0.5 / 1 / 2 / 4) とメモリ (0.5 〜 12 GB) を組み合わせて選択します。ECS Fargate のようにタスク定義・サービス定義・ ALB ・リスナー・ターゲットグループを個別に設定する必要がなく、1 つのリソース定義でデプロイが完結します。
GitHub 連携とソースコードデプロイの実践
ソースベースデプロイでは GitHub リポジトリを接続し、App Runner がコードから自動的にコンテナイメージをビルドしてデプロイします。対応するマネージドランタイムは Python、Node.js、Java、Go、.NET で、これらを選択すると Dockerfile を書かずにデプロイが完了します。リポジトリのルートに apprunner.yaml を配置することで、ビルドコマンド、起動コマンド、ランタイムバージョン、環境変数を宣言的に定義でき、インフラ設定をコードと一緒にバージョン管理できます。GitHub 連携では自動デプロイと手動デプロイを選択できます。自動デプロイを有効にすると、指定ブランチへの push を検知してビルドとデプロイが自動実行され、CI/CD パイプラインを別途構築する必要がありません。手動デプロイを選択した場合はコンソールまたは API から明示的にデプロイをトリガーします。自動ビルドの料金は 1 分あたり約 0.005 ドルで、頻繁な push を行うリポジトリではビルド料金が蓄積する点に注意が必要です。
カスタムドメインとオブザーバビリティ
カスタムドメインの設定はコンソールからドメイン名を入力し、DNS プロバイダー (Route 53 または外部 DNS) に CNAME レコードを追加するだけで完了します。ACM (AWS Certificate Manager) 証明書が自動的に発行・更新され、設定した独自ドメインで HTTPS アクセスが可能になります。VPC コネクタ利用時は ENI (Elastic Network Interface) が作成されるため、指定するサブネットに十分な IP アドレス空間を確保する必要があります。オブザーバビリティ面では、X-Ray トレーシングを有効にすることでリクエストのレイテンシとエラーの分散トレースを可視化できます。CloudWatch にはアクセスログとアプリケーションログが自動送信され、メトリクスとして HTTP 2xx/4xx/5xx カウントやレスポンスタイムが記録されます。ヘルスチェックは HTTP パスまたは TCP で設定でき、異常インスタンスの自動置換が行われます。
自動スケーリングとコスト構造
App Runner はリクエスト数に基づく自動スケーリングを標準で提供します。Auto Scaling Configuration で同時リクエスト数の閾値 (デフォルト 100)、最小インスタンス数 (1 〜 25)、最大インスタンス数 (最大 25) を設定できます。トラフィックが減少するとインスタンスを自動的に削減し、最小インスタンス数まで縮退します。一時停止 (Pause) 機能を使えばインスタンスをゼロにでき、メモリ料金のみの課金となります。料金体系は vCPU あたり 0.064 USD/時、メモリ GB あたり 0.007 USD/時です。アクティブなインスタンスには vCPU + メモリの両方が課金され、プロビジョニング済み (待機中) のインスタンスにはメモリ料金のみが課金されます。たとえば 1 vCPU / 2 GB メモリの構成で月 730 時間稼働した場合、約 56.9 USD/月です。ECS Fargate の同等構成 (1 vCPU / 2 GB) は約 44.3 USD/月ですが、App Runner は ALB (約 22.3 USD/月〜) が不要なため、小規模なサービスでは App Runner の方がトータルコストで有利になるケースがあります。
VPC 統合とセキュリティ
App Runner はデフォルトでパブリックなエンドポイントを提供しますが、 VPC コネクタを使用することでプライベートサブネット内のリソース (RDS 、 ElastiCache 、 DynamoDB VPC エンドポイントなど) にアクセスできます。 VPC コネクタはサブネットとセキュリティグループを指定して作成し、 App Runner サービスに関連付けます。アウトバウンド通信のみが VPC を経由し、インバウンドは引き続き App Runner のマネージドエンドポイントで受け付けます。 WAF (Web Application Firewall) との統合により、 App Runner のエンドポイントに WAF WebACL を関連付けて、 IP 制限やレートリミットなどのセキュリティルールを適用できます。 Secrets Manager や Systems Manager Parameter Store との統合により、データベースの認証情報や API キーを安全に管理し、環境変数として注入できます。 IAM によるアクセス制御、 CloudWatch によるメトリクス監視 (リクエスト数、レイテンシ、 HTTP ステータスコード)、 CloudWatch Logs へのアプリケーションログ出力も標準で提供されます。 コンテナ技術の知見を広げたい場合はAmazon の専門書も活用できます。
ECS/Fargate との使い分け
App Runner と ECS/Fargate はどちらもコンテナワークロードを実行しますが、対象ユースケースが異なります。App Runner は HTTP/HTTPS ベースの Web アプリケーションや API に特化しており、リクエスト駆動のスケーリングが標準です。一方、ECS/Fargate はバッチ処理、ワーカープロセス、gRPC、WebSocket、サイドカーパターンなど幅広いワークロードに対応します。 選択の判断基準は以下のとおりです。App Runner を選ぶべきケースは、HTTP/HTTPS の Web アプリや API を素早くデプロイしたい場合、インフラ管理を最小限にしたい場合、チームにコンテナオーケストレーションの専門知識が少ない場合です。ECS/Fargate を選ぶべきケースは、サイドカーコンテナやサービスメッシュが必要な場合、TCP/UDP プロトコルを使用する場合、タスク配置戦略やキャパシティプロバイダーの細かな制御が必要な場合、バッチ処理やキューワーカーなど非 HTTP ワークロードの場合です。EKS は Kubernetes エコシステムとの互換性が必要な場合や、マルチクラウド戦略でワークロードのポータビリティを重視する場合に選択します。App Runner は ECS/Fargate の上に構築されたより高い抽象化レイヤーであり、制御の柔軟性とシンプルさのトレードオフです。Elastic Beanstalk も簡易デプロイを提供しますが、裏側で EC2 や ALB のリソースが可視化されて管理でき、カスタマイズ幅が広い反面、管理対象リソースが増えます。Dockerfile 不要で CI/CD も不要、VPC や ALB の設定を省きたい場合は App Runner が最適です。
まとめ - App Runner の活用指針
AWS App Runner は、コンテナ化された Web アプリケーションを最小限の設定でデプロイ・運用するためのサービスです。ソースコードまたはコンテナイメージを指定するだけで、ビルド・デプロイ・ TLS ・ロードバランシング・ Auto Scaling が自動的に構成されます。VPC コネクタによるプライベートリソースへのアクセス、WAF 統合によるセキュリティ強化、Secrets Manager との連携による認証情報管理など、本番運用に必要な機能も備えています。ECS/Fargate と比較して制御の柔軟性は劣りますが、ALB やターゲットグループの設定が不要なため、小〜中規模の Web アプリケーションではトータルコストと運用負荷の両面で有利です。コンテナデプロイの第一歩として、あるいはプロトタイプの迅速な公開手段として、App Runner は有力な選択肢です。