COLUMN
構築済みのインフラにすぐにデプロイできるAWS App Runnerを使っていますか?
こんにちは、使ったことが無いサービスをざっくりやってみてお伝えするシリーズの第三回目になります。過去の記事もよかったら見てください。 |
関連コラム
今回はApp Runnerになります。業務ではTerraformの資産があるために今まで1回も使ったことがありません。今回もざっくり利用して行きたいと思います。
1. AWS AppRunnerとは?
AWS App Runner はフルマネージド型のコンテナアプリケーションサービスであり、インフラストラクチャやコンテナの経験がなくても、ウェブアプリケーションや API サービスを構築、デプロイ、実行できます。
引用: AWS App Runner
このようなサービスのようです。
似ているサービスでAWS Fargateがありますが、違いはなんでしょうか。
2023年10月時点の情報になります。
特徴 / サービス | AWS AppRunner | AWS Fargate |
---|---|---|
主な用途 | 簡単な設定での迅速なデプロイメント | 複雑なコンテナオーケストレーションに対応 |
インフラ管理 | 完全マネージド、手間なし | 詳細設定可能だがサーバー管理不要 |
デプロイ方法 | ソースコードまたはコンテナイメージ | コンテナイメージのみ |
オーケストレーション | 自動、ユーザー操作不要 | ECSやEKSによる詳細設定 |
CI/CD統合 | 直接統合可能 | CI/CDツール統合が必要 |
スケーリング | 自動的にスケールアップ・ダウン | ユーザー設定に基づいてスケールアップ・ダウン |
ネットワーク設定 | 基本設定のみ | 高度な設定可能 |
適用シナリオ | シンプルなアプリケーション | 複雑なアプリケーションや特定要件 |
カスタマイズ性 | 限定的 | 高度にカスタマイズ可能 |
コスト | 低コストで始めやすい | 詳細な設定によりコスト増 |
プロトコルサポート | 主にHTTP/HTTPS | HTTP/HTTPSに加え、より多様なプロトコルサポート |
このように細かいことをやろうとするとFargateを選択する必要がありそうです。
また、プロトコルもHTTP/HTTPSなのでUDPで何かしたい要件がある場合注意が必要です。料金面に関しても、AppRunnerは0.064 USD/vCPUでFargateは0.05056USD/vCPUになります。FargateはSavings Planも適用できる場合がありますので料金に関しては慎重な検討が求められます。
料金はリージョンで異なりますので、詳細は各種AWSのページをご覧ください
2. 実際に構築してみた
では早速触って行きたいと思います。
AWSにしては珍しく、ダッシュボード画面に料金が表示されています。
デプロイ1回につき$1で構築は分単位で課金されるみたいです。ビルドが長くなる、ファイルの配置に時間がかかるとコストが増していくようです。
「App Runner サービスを作成」を押下したらこの画面になりました。
リポジトリタイプは2種類あり、コンテナレジストリとソースコードリポジトリから選択できるようです。コンテナレジストリECRのみ。Docker Hubは選択できません。
ソースコードはBitbucketとGitHubのみです。CodeCommitは対応してないのですね。
ECRからイメージを作成するのは、想像がつくのですがソースコードレポジトリの場合はどうなるのでしょうか。Dockerfileを読み取って一式ビルドしてくれるのでしょうか。ソースコードリポジトリの方が興味深いので今回はこちらを試してみたいと思います。
上記の設定をします。GitHubのリポジトリ指定が必要です。
このように設定しました。上記リポジトリはまだ何も入っていません。
一旦手動で設定します。
「次へ」ボタン押下で上記の画面になりました。
設定ファイルを使用できるのですが、CircleCI等のサービスに似ていますね。
ランタイムが選択できるのですが、Lambdaみたいに出力さえ設定すれば勝手にHTTPにしてくれるのでしょうか。
ランタイムを選択したら上記画面になりました。
なるほど、流石にそうですよね。
上記のように設定しました。
「次へ」ボタンを押下したところ、設定値がいくつか出てきました。今回は動作確認なので最小構成で進めたいと思います。
デフォルト設定を下記のようにしました。
全て1です。
ヘルスチェックも出来るだけ大きくしました。
WAFが設定できるのは素晴らしいですね。今回は設定しませんが、WAFが設定できるとIP制限やメンテナンス画面が出力できるようになりますので、助かります。
ネットワーク設定で、AWS内での閉域が設定できます。業務アプリにも展開出来るのは素晴らしいと思います。ガバナンスで制限されている組織にも嬉しい機能です。カスタムVPCはRDSとの接続に使用します。
上記の設定はデフォルトのまま進めます。
「次へ」ボタンを押下したところ、確認画面と作成とデプロイになったのですが、リポジトリに何も入ってないのでリポジトリの中身を作成したいと思います。ちなみにこの画面から移動してしまうと、それまでの設定は無かったことになります。先にリポジトリを作るのをお勧めします。
ヘルスチェックに無茶苦茶な値を入れたところエラーになりました。20以下で設定しなおしました。
デプロイを開始したところ上記画面になりました。
アプリケーションログも参照できました。私の設定が間違っており0.0.0.0で起動したいので修正したいのですが、
グレーアウトされたままになっており、まだ編集できないようです。
この間も
となっており、課金時間として計上されているのでしょうか。
非常に不安です。
一時停止もグレーアウトしており、停止する手段がありません。
適当に設定したヘルスチェックのせいで、19秒でタイムアウトをするのを20秒の間隔で20回失敗しないと操作出来ないのかもしれません。
ダメ元でCLIを試します。
CLIの表示としてはCREATE_FAILEDになっていました。
削除コマンドを受け付けたようです。
Web側では上記のようになりました。CLIが効いてよかったです。ちょっと冷や汗をかきました。
再度サービスを作り直していきます。
ヘルスチェックは上記のようにすぐに失敗を検知できるようにしました。
4分程度でデプロイが完了しました。
が、URLにアクセスしてもアクセス出来ません。
思い当たる節はポートです。80に変更して実行してみます。
ログに表示してくれるのは非常に有難いです。
Hello worldが表示されました!これは便利ですね。
そして、一番試したかった機能、自動デプロイです。こちらを試したいと思います。
を
にしました。
を
に変更し、pushしました。
ログの更新ボタンを何度か押していたら検知しました。
しばらく待ったところ表示されました。
11:16:53にpull
11:19:36にヘルスチェックがOKになりルーティングが開始された模様です。
3. まとめ
App Runnerを実際に使用してみて、期待を大きく超える素晴らしいサービスであると感じました。今回はカスタムVPCを使用せず、RDSとの直接連携は行いませんでしたが、RDSとの連携が可能であることは、一般的なMVCフレームワークを選択する際に大きな利点となります。また、GUIに依存せずに設定値をYAMLファイルに保存できることも大きなメリットだと思います。ポート指定が少し親切じゃない点やヘルスチェックの設定によってはデプロイが続き、課金が発生する可能性がある点は懸念材料ですが、CLIを使えばこれらは解決できます。特に、コミットで自動的にパイプラインが構築される機能は、使用しない手はないと思います。特定ブランチにコミットしてテストを実行し、正常であればリリースブランチへの投入という使い方も可能です。非常に夢の広がるサービスだと感じますので、ぜひ皆さんも利用してみてください。
関連コラム
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。