彗星の如く登場したAWS App Runnerの特徴をまとめてみました
はじめに
ご無沙汰しています。 最近ブログ更新をサボっていたのですが、本日（2021-05-19 JST）、AWSの新サービスであるApp Runnerが彗星の如くリリースされました。コンテナ技術のアップデートを追う身としてとても気になったので、早速サービスの特徴をまとめてみました。 そのサマリ内容をブログを通して皆さまにお伝えできればと思います。
App Runnerが気になる方や利用判断のお手伝いにつながれば幸いです。
注意事項
本ブログは2021-05-19時点の情報になります。 今後、サービスのアップデート次第で内容が変わる可能性がある点だけご留意いただければと思います。
Overview
AWS App Runnerとは、プロダクションレベルでスケール可能なWebアプリケーションを素早く展開するためのマネージドサービスです。 GitHubと連携してアプリケーションソースコードをApp Runner上でビルド＆デプロイできるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできます。
App Runnerはアプリケーション開発者がより簡単でWebアプリをデプロイできる点に主眼を置いています。 ECS/Fargateでアプリケーションを構築しようとすると、ネットワークやロードバランシング、CI/CD設定などインフラレイヤの足回りを整える必要がありますよね。 つまりインフラスキルがある程度必要になってくるのですが、App Runnerはこれらインフラ周辺の構築を全て引っくるめて（ブラックボックス化して）マネージドにしているのが特徴です。
※LambdaはイベントドリブンなサービスとしてAPI Gatewayと連携してWebアプリを提供できますが、App Runnerはソースコード単体でWebアプリとして機能するものを、ソースコードベースもしくはコンテナイメージベースからAWS上にサクッと展開できるイメージです。
@toriclsさんも言っていますが、非常に抽象度の高いサービスです。
App Runner は Web アプリや API サーバの実行に必要なネットワークやロードバランサなどをフルマネージドに提供します！
— Tori Hara 🚀 (@toricls) 2021年5月18日
パイプラインやオーケストレータについても一切考えずにお手元のコードを AWS 上で実行できて最高です✨✨
/ "Introducing AWS App Runner ..." https://t.co/o7Vke20gFm 2/n
利用可能なリージョン
現時点では、以下のリージョンで利用可能です。Asia Pacific (Tokyo)も対応している点が嬉しいですね。
- US East (N. Virginia): us-east-1
- US East (Ohio): us-east-2
- US West (Oregon): us-west-2
- Europe (Ireland): eu-west-1
- Asia Pacific (Tokyo): ap-northeast-1
App Runnerの構成について
App Runnerは大きく３つの要素から構成されています。
- Service
- GitHub Connection
- AutoScaling Configuration
ServiceはApp Runnerのコアな要素です。 アプリケーションのソースやデプロイ方法、ビルド設定、オートスケールやヘルスチェック設定などを含んでいます。
GitHub Connectionはその名の通り、アプリケーションをApp Runner上で稼働させる際にGitHubからソースコードを取得する場合に定義として利用します。
AutoScaling Configurationはその名の通り、アプリケーションのオートスケール設定です。後ほど説明します。
ざっと絵にしてみると、以下のような感じでしょうか。
App Runnerを利用する際の流れ
図でも表現しましたが、App Runnerは以下のような流れで設定します。
- ソース選択
- デプロイ設定
- ビルド設定
- サービス設定
具体的にどのような設定が必要なのか、何ができて何ができないのかブレイクダウンしていきましょう。
Step.1 ソース設定
稼働させるアプリケーションのソース場所を指定します。 現時点ではGitHubによるソースコードECRのコンテナイメージが指定できます。
GitHubと接続する場合は、先程の通りGitHub Connectionにて接続対象を設定します。 パブリック及びプライベートリポジトリどちらでも可能ですが、いずれもGitHub側でAWS側から参照できるようにパーミッション設定を行っておく必要があります。
余談ですが、CodePipelineを利用している場合、ソースステージとしてGitHub接続を行う場合にCodeStar ConnectionでGitHubの接続設定を行います。一方、AppRunnerの設定とは別ものであり、新規に定義する必要があります。
一方、ECRからコンテナイメージを取得する場合は、イメージURIを指定します。 ECRもパブリック及びプライベートの両方が利用可能ですが、プライベートを指定する場合、IAMロールが必要になる点に注意してください。
Step. 2 デプロイ設定
アプリケーションデプロイを自動 or 手動どちらで行うかを選択します。 自動を選択した場合、ブランチプッシュやイメージプッシュをトリガにデプロイが走ります。 一方、手動の場合はコンソールやCLIから明示的な操作が必要になります。 アプリの特性によって使い分けるのが良いでしょう。
Step.3 ビルド設定
Step.1 ソースの設定にてGitHub連携を選択した場合のみ、アプリケーションを稼働させるランタイムやビルドコマンド、起動コマンドなどをこのStepで指定します。 ここで注意すべきなのが、現在はPython3.XかNodejs 12.xのランタイムにしか対応していない点です。
Golang等のアプリケーションはまだ未対応のようです。 ただし、ソース設定としてECRを選択した場合、その他言語のアプリケーションで稼働させることは可能です。
※筆者がGolangで試したところ、問題なくデプロイ＆リクエスト受付がなされました。 現時点でPythonやNodejs以外でApp Runnerを利用したい場合、ECRによるコンテナイメージが必要な点を押さえておけばよさそうですね。
Step.4 サービス設定
最後にサービス設定を行います。主に以下のような項目です。
- CPUとメモリの指定
- 環境変数の指定
- オートスケール設定
- ヘルスチェック設定
- セキュリティ設定
- タグ設定
なお、CPUとメモリは現状以下の組み合わせからのみ設定できるようです。
- 1vCPU / 2GB
- 1vCPU / 3GB
- 1vCPU / 4GB
- 2vCPU / 4GB
リソースを大量消費するようなアプリケーションは現時点では対応できません。一方、Webアプリケーションをユースケースとしているので、この程度のリソースで十分なのかなとも推察しています。
また、オートスケール設定は同時実行数、インスタンスの最小・最大数を指定できますが、自分達でカスタム定義を作成して使い回せるようにもなっています。これがApp Runnerの構成で説明したAutoScaling Configurationに該当します。
ヘルスチェックに関しては、以下項目が指定できます。
- Timeout: ヘルスチェックのタイマ(秒)
- Interval: ヘルスチェック間隔(秒)
- Unhealthy threshold: ヘルスチェック失敗と判断されるまでのリクエスト数
- Health threshold: ヘルスチェック成功と判断されるまでのリクエスト数
セキュリティ設定はインスタンス（デプロイしたアプリケーション）に付与するIAMロールとアプリ内データを暗号化するためのKMSを指定可能です。 KMSはAWS管理キーを指定することもできますし、CMKも選択できます。 ただし、一度KMSを設定した後、App Runnerサービスとしては変更できない点は注意したほうが良さげです（まあ、App Runner自体が非常にシンプルなので、すぐ作り直せる範疇かと思います）。
App Runnerのその他特徴
エンドポイント
- App RunnerはWebアプリケーションをユースケースとしており、自動でHTTPSでエンドポイントが払い出されます。このエンドポイントに対して、Route53のパブリックHosted Zoneと連携することで、カスタムドメインも簡単に設定可能です。 コンソール上からドメイン指定するだけで設定できるので、非常に楽な印象です。
証明書の更新
払い出されたエンドポイントのSSL/TLS証明書はAWS側で内部的に自動で更新されます。 ACMが提供するAmazonが発行したSSL/TLS証明書と同じように、利用者側での証明書更新を気にしなくてよくなるのは非常に良い点ですね。
ログ・メトリクス連携
App Runnerは何もせずともCloudWatchアラーム＆CloudWatchログと連携されています。 メトリクスに関しては以下が取得できます。
CloudWatchアラームと組み合わせることで、5xxエラー増大やレイテンシ増大などをモニタリングできます。
また、アプリケーションログについてもデフォルトでCloudWatch Logsに出力されています。 メトリクスフィルター＆CloudWatchアラームと連携することで、ログ監視も設定できそうですね。
AWS Copilotとの連携
コンテナのデプロイを容易にするツールとしてAWS Copilotがあります。 CopilotはAmazon ECSでのコンテナ実行を簡単に扱えるようにしたCLIツールです。
このCopilotですが、すでにApp Runnerと連携可能になっています。 そのため、Copilotと同じ開発者体験を維持しつつ、App Runnerの抽象性を享受できるわけですね！
ただし、Copilotでは裏でCloudFormationが動いており、VPCなどのリソースが作成されてしまいます。 一方、マネジメントコンソールからApp Runnerのサービスを作成すると、利用者側からCloudFormationスタックは見えず、VPCなども作成されません。 ここらへんの内容はクラスメソッドさんがすでに試されているようなので、興味のある方は見てみると良いと思います。
現状では対応していないこと
僕がざっと検証してみて、現状対応していなさそうな点は以下でした。
- カナリアリリースやBlue/Greenデプロイ
- WAFとの連携
- Secrets ManagerやSystems Managerパラメータストア等によるApp Runnerからの環境変数追加
- コンテナのサイドカー構成
上記はあくまで一部です。ただ、機能追加がたくさん行われてしまうと、結局開発者が気にしなければならないポイントも増えていくので、要件が膨らんでくるとECS/Fargateの利用に倒れるのかな、と考察しています。
AppRunnerではロードマップが公開されており、Issueとして機能リクエストできます。 ご覧になった皆さんの中で、アプリ開発上のリクエストがあれば、どんどんIssueを挙げていきましょう！
最後に
最後までお読みいただきありがとうございました。 App Runnerの概要をざっとご紹介してみましたが、いかがでしたでしょうか。 アプリケーション開発者としてペインポイントになりがちだった箇所が全て取り除かれた、素晴らしいサービスかなと思います。 ある程度セキュリティやインフラ設定箇所をAWSによせつつ、アプリケーション開発に集中できるので、簡単なAPIエンドポイントなどを用意する場合などに重宝しそうです。
本稿の内容に誤り等があれば、遠慮なくご指摘ください。 では！
おまけ
先日、AWSより以下発表がありました。
嬉しくも、僕自身も以下に認定いただきました。感謝！
これからも変わらずに、ブログやコミュニティの場を通して、様々なエンジニアの方々と技術や知見をシェアしつ、クラウドが持つ素晴らしさで世の中のアップデートに貢献できたらいいな、と思ってます。
参考資料
AWS App Runner – Fully managed container application service - Amazon Web Services
