こんにちは。AIサービス開発部の上原と申します。
2020年度に株式会社OPTiMへ新卒入社後、業務では主にバックエンドシステムの設計・実装やAmazon EKSを利用したサービス運用を担当しており、特に最近はKubernetesと格闘する日々を送っております。
さて、皆さんは2021年5月にローンチされたAWSの新サービス「AWS App Runner」をご存知でしょうか？
AWS App Runnerは手元にあるソースコードやコンテナを渡すだけでアプリケーションをフルマネージドで運用してくれるPaaS (Platform as a Service) 型のサービスで、HerokuやCloud Foundryといったサービスと位置付けが近いものとなっています。
今回はAWS App Runnerについて、その特徴、アプリケーション実行までのフロー、さらにはCloudWatchでのメトリクス・ログ監視までを試した話をしていきます。特にAWS App Runnerを利用して小規模サービスを手っ取り早く運用レベルまで持っていきたい方にとって参考になる内容かと思います。
AWS App Runnerとは
"AWS App Runner は、コンテナ化されたウェブアプリケーションや API を開発者が簡単かつ迅速にデプロイできるフルマネージド型サービスです。"
AWS App Runner – Fully managed container application service - Amazon Web Services
出来る事
AWS App Runnerでは簡単なステップで以下機能が利用できます。
- 自動デプロイ
- Amazon ECRおよびGItHubリポジトリとの連携によりイメージプッシュもしくはコミットをトリガーとした自動デプロイが可能
- ロードバランシング
- 自動でロードバランシング機構を構築しアプリケーションに高い信頼性と可用性を提供
- 自動スケーリング
- リクエスト数に応じた自動水平スケーリングが有効
- ログおよびメトリクス
- Amazon CloudWatchにより実行アプリケーションのログおよびメトリクス監視が可能
- 証明書管理
- フルマネージドTLSの適用および証明書の自動更新が有効
- コスト管理
- サービス実行の分だけ料金を請求
出来ない事
抽象度の高いサービスなので全体的に細かいカスタマイズは出来ない傾向にあります。特に気になった未対応の機能（2021/06/01時点）をピックアップしました。
- アプリケーションのBlue/Greenデプロイ
- 自動スケール基準となるメトリクスのカスタム（リクエスト数を基準とした自動スケールのみ対応）
- コンテナのサイドカー構成
- 実行サービスからのAWSプライベートサブネットへのアクセス
- AWS CodeCommit連携
AWS App RunnerはGitHubでロードマップが公開されておりますので、今後の機能追加など覗いてみると面白いです。
特徴
他社Paas型サービスと比べ他AWSサービスとの連携が容易な点が特徴で、
- Amazon ECR連携
- Amazon ECR (コンテナイメージレジストリ) へのイメージプッシュをトリガーとするCDパイプライン構築
- Amazon CloudWatch連携
- Amazon CloudWatchからのメトリクス・ログ監視
- Amazon Route53連携
- Amazon Route53を利用したカスタムドメイン設定
といった他AWSサービスとの素早い連携はもちろんのこと、さらに、AWS App Runnerのパートナーとなっている Datadog, MongoDB, HashiCorp, Pulumi, Logz.io, Trek10, Sysdig といった企業のサービスと容易に統合可能とのことです。
使い方
それでは実際にAWS App RunnerへのデプロイとCloudWatchを用いたログ・メトリクス監視までを試してみます。
デプロイまでの流れ
1. ソースおよびデプロイの設定
プロバイダは Amazon ECR か GitHub から選択可能のようです。今回の例ではAmazon ECRにて公開されているチュートリアル用のコンテナを設定します。URI: public.ecr.aws/aws-containers/hello-app-runner:latest
デプロイ設定は 手動 か 自動 から選択でき、後者を選択するとプロバイダのAmazon ECRリポジトリへのプッシュをトリガーとするCDが構築できます。今回は 手動 を選択しました。
2. サービスを設定
今回は基本デフォルト設定のままで任意のサービス名を入力しポートは 8000 とします。インスタンススペックや環境変数、起動コマンド、オートスケーリング基準なども設定可能のようです。
3. 確認および作成
最後に 作成とデプロイ を押下すると、必要なAWSリソースがバックグラウンドで準備され、数秒程度でデプロイされたアプリケーションのダッシュボードが表示されます。
ステータスが Operation in progress から Running になればデプロイ成功です。
4. アプリケーションへアクセス
ダッシュボードの デフォルトドメイン へアクセスし、無事にページが表示されることを確認しましょう。
ここまでインフラのことを意識せずにコンテナ化されたWebページのデプロイまで出来ました、簡単ですね！（ページもかわいい...！）
CloudWatchによるメトリクス・ログ監視
デプロイが完了するとCloudWatchからメトリクスおよびログを確認出来るようになります。
アプリケーションログ確認
CloudWatchダッシュボード > インサイト > ロググループ: /aws/apprunner/{設定したアプリケーション名}/xxxxxxxxxxxxx/application > クエリの実行
システムメトリクス確認
標準でCloudWatchから監視可能なメトリクスは以下の通りです。
インスタンスレベル
CloudWatchダッシュボード > メトリクス > 全てのメトリクス > AppRunner > Instance metrics
| メトリクス | メトリクス名 | 説明 |
|---|---|---|
| CPU使用率 | CPUUtilization |
1分毎の平均CPU使用率 (%) |
| メモリ使用率 | MemoryUtilization |
1分毎の平均メモリ使用率 (%) |
サービスレベル
CloudWatchダッシュボード > メトリクス > 全てのメトリクス > AppRunner > Service metrics
| メトリクス | メトリクス名 | 説明 |
|---|---|---|
| HTTPリクエスト数 | Requests |
サービスが受信したHTTPリクエスト数 |
| HTTPステータス数 | 2xxStatusResponses4xxStatusResponses5xxStatusResponses |
2xx, 4xx, 5xxごとに分類された応答ステータス数 |
| HTTPリクエストレイテンシー | RequestLatency |
サービスがHTTPリクエストの処理に掛かった時間 |
| インスタンス数 | ActiveInstances |
HTTPリクエストを処理可能なインスタンスの数 |
上記でサービス運用に最低限必要なメトリクスは網羅できていそうな感触です。重要なメトリクスに関しては別途CloudWatchアラームを設定しても良いでしょう。
まとめ
最後までお読みいただきありがとうございました。
AWS App Runnerを利用するとAmazon EKS, Amazon ECS, AWS FargateといったAWSの既存アプリケーション実行環境で発生しがちな構築コストを大幅に削減でき、かつCloudWatchやDatadogとの連携で素早く監視構成を構築出来るのは魅力的だと思いました。
今後、個人開発やPoCといった小規模サービス運用では比較的構築コストが掛からないAWS App Runnerを重宝する場面も多くなるのではないでしょうか。
関連リンク
- 公式ドキュメント - App Runner Developer Guide
- 公式ブログ - AWS App Runnerのご紹介
- 公式概要 - App Runner
- 公式ロードマップ - apprunner-roadmap
さいごに
株式会社OPTiMで一緒に働けるエンジニアを募集しています！年齢や経歴などお互いの属性を尊重しあい気持ちよく働ける職場です！
