概要
- ソースコードまたはコンテナイメージから AWS クラウド内に簡単にデプロイしてWebアプリケーションを運用することができるAWSサービス
- ソースコードまたはコンテナイメージを指定するだけで、自動的にビルド・デプロイ・スケーリングを行い、アプリケーションをインターネット上に公開できる
特徴
- コンテナイメージを指定するだけで自動デプロイとスケーリングを行うことができる
- HTTPS でアクセスできるエンドポイントを自動作成できる
- ビルドパイプラインを AppRunner が管理 (ソースコードリポジトリを直接連携できる)
- トラフィックに応じた自動スケーリング
- 比較的シンプルな構成(モノリス)で動かせる Web アプリケーションに適している
ユースケース
App Runner が適しているケース
-
インフラ管理を最小限に抑えたい Web アプリ
- コンテナで動作するアプリケーションを、コードかイメージの指定だけでサクッと公開したい場合
-
スモールスタートでシンプルな構成を求める場合
- リソース (CPU, メモリ) がそこまで多く必要ない、小規模〜中規模の Web サービス
-
チーム内でのプロトタイプや PoC
- 本格的なマイクロサービス化をする前に、短期間で動作確認したいとき
-
ユーザ管理や認証を含む内部向け Webアプリ
- チームや社内だけで使用し、認証機能を持つ Web アプリケーションを簡易的にデプロイ
App Runner が適していないケース
- 複雑なネットワーキング設定が必要な場合
- AppRunner は内部的な VPC 接続などもサポートしているが、EKS/ECS + Fargate の方が柔軟性が高い
- 短期実行のジョブ系ワークロード
- サーバーレスアーキテクチャ (AWS Lambda + EventBridge など) の方が適している
- GPU・大容量メモリなど特殊なリソースを要する負荷の高いワークロード
- 対応リソースに限りがあるため、ECS/EKS などより柔軟なサービスが好ましい
プラクティス
-
消えては困るデータはDBやオブジェクトストレージなどの外部ストレージで管理する
- コンテナインスタンス終了後にApp Runnerのストレージにアクセスできないため、ステートレスな構造にする(データ永続化は外部で行う)
-
VPC外のリソース(S3やDynamoDBなど)へのアクセス制御はインスタンスロールで制限する
-
VPC内のリソース（RDSなど）へのアクセスは”VPCコネクター”を設定して接続する
-
SIGTERM(終了要求)をハンドリング(終了処理)する処理を加える
-
App Runner内部的にコンテナ内のアプリケーションに対してSIGTERMを送信する(オートスケーリングのスケールイン時など)
-
その後タイムアウトの後にSIGKILL(強制終了)が送信される
- SIGTERMで処理できないアプリは強制終了され、処理中データがロストする懸念がある
-
-
秘密情報の受け渡しはSSM パラメータストアやSecrets Managerを使用する
-
ログはファイルではなく、標準出力(STDOUT)や標準エラー出力(STDERR)へ出力する
- ファイルに出力した情報を確実に取り出すことが難しいため
-
X-Rayを使用し分散トレーシングを行う
- ログとメトリクスだけでは、分散されたシステムやリソース間の問題個所の特定が難しいため
-
ヘルスチェックエンドポイントの設計(アプリケーション内部のヘルスチェック)
- App Runner はデフォルトでアプリの起動可否を監視しスケールイン/スケールアウトを行うが、アプリケーションによっては、より詳細な状態(依存DB への接続可否など)をチェックするために ヘルスチェック エンドポイントを実装しておくと、トラブルシュートが容易になる
-
コンテナイメージ最適化と脆弱性スキャン
-
イメージサイズの最適化
- デプロイ時にイメージを取得するため、不要なパッケージを含めない最小限のベースイメージを利用すると、ビルドやデプロイの高速化やセキュリティ強化につながる
-
脆弱性スキャン
- AWS ECR のスキャン機能や、他のイメージスキャンツールを使って脆弱性を検知し、定期的なアップデートを行うとセキュリティリスクを軽減できる
-
-
適切なスケーリングパラメータの調整(同時接続数やリクエスト遅延を考慮した設定)
- App Runner はリクエスト数に応じてスケールする、どの程度余裕をもってスケールさせるかなどの設定を見直すことが必要。最小インスタンス数 (Minimum concurrency) をどんな値にするかなど、サービスの SLA へどこまで影響を与えるかも考慮して設定する
おおまかな利用の流れ
AWS App Runner を用いたアプリケーションデプロイの大まかな流れは次の通り
-
コンテナイメージの用意 (またはソースコードの準備)
- GitHubなどのリポジトリにソースを配置するか、AWS ECR などにイメージをプッシュする
-
App Runner サービスの作成
- デプロイソース (ソースコード or コンテナイメージ) を指定
- ビルド設定・ランタイム設定の指定
- ソースコードの場合はビルドコマンドやランタイム環境を指定
- コンテナイメージの場合は、Dockerfile などのビルド手順は不要
- サービス設定 (CPU・メモリなど)
- アプリケーションに必要なリソース量や環境変数設定などを実施
-
デプロイ
- 設定内容を確認してデプロイを実行
- 数分でデプロイが完了すると、App Runner が提供するエンドポイントでサービスが利用可能
-
運用・監視
- App Runner コンソールやCloudWatch ログやメトリクスを確認
- 必要に応じてコンテナイメージの更新やソースコードの更新を行い、自動ビルド＆デプロイを繰り返す