AWS App Runner 概要 メモ


## 概要

* ソースコードまたはコンテナイメージから AWS クラウド内に簡単にデプロイしてWebアプリケーションを運用することができるAWSサービス
  * ソースコードまたはコンテナイメージを指定するだけで、自動的にビルド・デプロイ・スケーリングを行い、アプリケーションをインターネット上に公開できる

![apprunner.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/586535/c5aa0637-16ba-3554-7d99-35a1a6d3ac49.png)




## 特徴

- コンテナイメージを指定するだけで自動デプロイとスケーリングを行うことができる
- HTTPS でアクセスできるエンドポイントを自動作成できる
- ビルドパイプラインを AppRunner が管理 (ソースコードリポジトリを直接連携できる)
- トラフィックに応じた自動スケーリング 
- 比較的シンプルな構成(モノリス)で動かせる Web アプリケーションに適している



## ユースケース

### App Runner が適しているケース

1. インフラ管理を最小限に抑えたい Web アプリ
   - コンテナで動作するアプリケーションを、コードかイメージの指定だけでサクッと公開したい場合
   
2. スモールスタートでシンプルな構成を求める場合
   - リソース (CPU, メモリ) がそこまで多く必要ない、小規模〜中規模の Web サービス
   
3. チーム内でのプロトタイプや PoC
   - 本格的なマイクロサービス化をする前に、短期間で動作確認したいとき
4. ユーザ管理や認証を含む内部向け Webアプリ
   - チームや社内だけで使用し、認証機能を持つ Web アプリケーションを簡易的にデプロイ



### App Runner が適していないケース

1. 複雑なネットワーキング設定が必要な場合
   - AppRunner は内部的な VPC 接続などもサポートしているが、EKS/ECS + Fargate の方が柔軟性が高い
2. 短期実行のジョブ系ワークロード
   - サーバーレスアーキテクチャ (AWS Lambda + EventBridge など) の方が適している
3. GPU・大容量メモリなど特殊なリソースを要する負荷の高いワークロード
   - 対応リソースに限りがあるため、ECS/EKS などより柔軟なサービスが好ましい



## プラクティス

1. **消えては困るデータはDBやオブジェクトストレージなどの外部ストレージで管理する**

   * コンテナインスタンス終了後にApp Runnerのストレージにアクセスできないため、ステートレスな構造にする(データ永続化は外部で行う)

     

2. **VPC外のリソース(S3やDynamoDBなど)へのアクセス制御はインスタンスロールで制限する**

   

3. **VPC内のリソース（RDSなど）へのアクセスは”VPCコネクター”を設定して接続する**

   

4. **SIGTERM(終了要求)をハンドリング(終了処理)する処理を加える**

   1. App Runner内部的にコンテナ内のアプリケーションに対してSIGTERMを送信する(オートスケーリングのスケールイン時など)

   2. その後タイムアウトの後にSIGKILL(強制終了)が送信される
       - SIGTERMで処理できないアプリは強制終了され、処理中データがロストする懸念がある

      
5. **秘密情報の受け渡しはSSM パラメータストアやSecrets Managerを使用する**

   

6. **ログはファイルではなく、標準出力(STDOUT)や標準エラー出力(STDERR)へ出力する**

   * ファイルに出力した情報を確実に取り出すことが難しいため

     

7. **X-Rayを使用し分散トレーシングを行う**

   * ログとメトリクスだけでは、分散されたシステムやリソース間の問題個所の特定が難しいため

     

8. **ヘルスチェックエンドポイントの設計(アプリケーション内部のヘルスチェック)**

   - App Runner はデフォルトでアプリの起動可否を監視しスケールイン/スケールアウトを行うが、アプリケーションによっては、より詳細な状態(依存DB への接続可否など)をチェックするために ヘルスチェック エンドポイントを実装しておくと、トラブルシュートが容易になる

     

9. **コンテナイメージ最適化と脆弱性スキャン**

   - イメージサイズの最適化
     - デプロイ時にイメージを取得するため、不要なパッケージを含めない最小限のベースイメージを利用すると、ビルドやデプロイの高速化やセキュリティ強化につながる

   - 脆弱性スキャン

     - AWS ECR のスキャン機能や、他のイメージスキャンツールを使って脆弱性を検知し、定期的なアップデートを行うとセキュリティリスクを軽減できる

       

10. **適切なスケーリングパラメータの調整(同時接続数やリクエスト遅延を考慮した設定)**

    - App Runner はリクエスト数に応じてスケールする、どの程度余裕をもってスケールさせるかなどの設定を見直すことが必要。最小インスタンス数 (Minimum concurrency) をどんな値にするかなど、サービスの SLA へどこまで影響を与えるかも考慮して設定する

      
## おおまかな利用の流れ

AWS App Runner を用いたアプリケーションデプロイの大まかな流れは次の通り

1. **コンテナイメージの用意 (またはソースコードの準備)**

   - GitHubなどのリポジトリにソースを配置するか、AWS ECR などにイメージをプッシュする

     

2. **App Runner サービスの作成**

   1. デプロイソース (ソースコード or コンテナイメージ) を指定
   2. ビルド設定・ランタイム設定の指定
      * ソースコードの場合はビルドコマンドやランタイム環境を指定
   3. コンテナイメージの場合は、Dockerfile などのビルド手順は不要
   4. サービス設定 (CPU・メモリなど)
      * アプリケーションに必要なリソース量や環境変数設定などを実施

3. **デプロイ**

   - 設定内容を確認してデプロイを実行
   - 数分でデプロイが完了すると、App Runner が提供するエンドポイントでサービスが利用可能

4. **運用・監視**

   - App Runner コンソールやCloudWatch ログやメトリクスを確認
   - 必要に応じてコンテナイメージの更新やソースコードの更新を行い、自動ビルド＆デプロイを繰り返す



## 参考文献

- [AWS 公式ドキュメント: App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/what-is-apprunner.html)
- [AWS Black Belt Online Seminar](https://pages.awscloud.com/rs/112-TZM-766/images/202112_AWS_Black_Belt_AWS_CON243_App_Runner_Introduction.pdf)
- [AWS App Runner を使う時に押さえておきたい勘所 〜 Web アプリをコンテナに最適化する 〜](https://speakerdeck.com/track3jyo/key-points-of-using-apprunner?slide=54)