開発ブログ

株式会社Nextatのスタッフがお送りする技術コラムメインのブログ。

電話でのお問合わせ 075-744-6842 ([月]-[金] 10:00〜17:00)

  1. top >
  2. 開発ブログ >
  3. AWS >
  4. AWS App Runnerがそろそろ本番環境でも使い物になりそう

AWS App Runnerがそろそろ本番環境でも使い物になりそう

こんにちは、ナカエです。

某所のLTでApp Runnerの紹介をしてきたのでブログ記事でも紹介します。

AWS App Runner概要

app_runner_icon.png

AWS App Runner は2021年5月にリリースされた、コンテナ化されたウェブアプリケーションのフルマネージドサービスです。GitHubのリポジトリからのソースコードベースのデプロイとECRからのコンテナベースのデプロイに対応しています。

バックエンドはECSでも利用可能なFargate(Firecracker VM)となっています。

app_runner_arch.png

参考: https://dev.classmethod.jp/articles/report-con406-reinvent2022/

ECSとの違い

ECS/Fargateと比較すると、AWS App Runnerのほうがユーザー側が責任を追う範囲がより小さくなります。AWSにお任せして楽ができるトレードオフとしてECSより自由度は低いサービスと言えます。

デプロイパイプラインを自前で用意する必要がないのが1つ目の大きな違いです。ロードバランサーも組込みなのでALBなどを別途使う必要もありません。

オートスケールの設定項目も最小/最大インスタンス数、1コンテナあたりの同時リクエスト数の3項目となっており、ECSと比べると利用できるメトリクスが少ないものの設定は非常に楽です。

その他設定項目もECSと比べると細やかさはなく、また機能の少ない部分もありますが、その反面、利用を開始するためのハードルはかなり低いと言えます。

  • 1つのサービスに対し複数のコンテナを組み合わせられない
  • ECSタスクに相当するジョブの機能はない
  • Arm(Graviton)、Windowsコンテナ未対応
  • etc.

2022年の注目アップデート

まだ比較的若いサービスであるApp Runnerですが、2022年には多くのアップデートがあり、プロダクション環境でも安心して利用できる状態となったと言えると思います。
 

2022/02/08 カスタマーVPCへの接続が可能に

https://docs.aws.amazon.com/apprunner/latest/relnotes/release-2022-02-08-vpc.html

VPCコネクタに対応し、DynamoDBなどグローバルなリソースだけでなく、RDSなどVPC内のリソースが使えるようになりました。

app_runner_arch_2.png
 

2022/10/28 マネージドランタイムの言語対応追加

https://aws.amazon.com/jp/about-aws/whats-new/2022/10/aws-app-runner-support-php-go-dot-net-ruby-managed-runtimes/

GitHubからの自動デプロイで利用されるマネージドランタイムの言語対応が追加されました。以前はJavaとNode.jsのみでしたが、現在はPHP、Go、.NET、Rubyも利用可能となりました。

2022/10/31 プライベートアクセスが可能に

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/aws-app-runner-supports-privately-accessible-services-amazon-vpc/

App Runnerへのアクセスはインターネット経由の公開アクセスに限定されていましたが、プライベートサービスを選択するとVPC内からのアクセスに限定できるようになりました。

より厳密にはVPCエンドポイント経由でのアクセスとなります。

これによりVPC内からアクセスするマイクロサービスをApp Runnerで作成することも可能になったのに加え、CloudFront + WAFを前段に置く構成の場合でも、迂回路がなくなったのが嬉しいポイントです。

Before

app_runner_public_access.png
 

After

app_runner_private_access.png

料金について

CPUとメモリに対しそれぞれ起動時間への従量課金となっていますが、リクエストのないアイドル状態ではメモリに応じた料金しかかからないのが一つの特徴です。

個人的にはApp Runnerの料金はECSと比較して高いかなと感じていたのですが、軽く試算してみると稼働時間やリクエスト数の少ないシステムではECS/Fargateより安く上がることもありそうでした。

試算

WAFを組み込んだプライベートのほぼ最小構成

  • CloudFront + WAF + VPCエンドポイント(2AZ) + App Runner
    • vCPU 1、メモリ2GB
    • ずっと待機状態とすると5500円/月ほど(リクエスト時間に応じて料金増)
  • CloudFront + WAF + ALB + ECS/Fargate
    • vCPU0.5、メモリ1GB
    • 6,500円/月ほど
 

※ DBは未考慮、デプロイ・ビルドの料金は別

プライベート構成とするとApp RunnerをVPCに接続するためのENIの料金が少し高い(AZを1つにするともう少し下がる)のですが、ECSではALBが必要なことを考慮するとトントンくらいでしょうか。

業務であればECS/Fargateの対立候補として十分選択肢になりうるが、趣味で使うには少し高いのでパブリックな構成でなんとかならないか考えたいというのが個人的な感想です。


改善されてほしい点

このように機能面は本番利用で通用するようになってきていますが、物足りない点はまだまだあります。

App Runnerユーザーが期待している改善点は、App RunnerのRoadmapのリポジトリにも起票されています。

ゼロスケール

GCPのCloud RunやLambdaのように、待機しているコンテナインスタンスの数をゼロにすることで、リクエストがない時間の料金もゼロに近づくと嬉しいですね。ただしApp Runnerは裏がENI経由でのFargateへの接続となっているので、完全なるコールドスタートに対応するのはECS/Fargate同様にかなり厳しいのではと推測しています。

issue: https://github.com/aws/apprunner-roadmap/issues/9

Secrets Managerからの環境変数の読込

秘匿情報をコンテナ外から読み込むソースとしてSecrets Managerに対応するとよりセキュアな運用が可能です。RoadmapではComing soonとあるので早いうちに入りそうです。

issue: https://github.com/aws/apprunner-roadmap/issues/6

最低スペック変更

現在vCPU 1 + メモリ2GBが最低スペックなので、もう少し低スペックで安いコンテナインスタンスに対応されるとより需要が広がりそうです。

issue: https://github.com/aws/apprunner-roadmap/issues/25

Arm対応

ECS/FargateのようにArmに対応すると、コストダウンも期待できます。

issue: https://github.com/aws/apprunner-roadmap/issues/98

サイドカー対応

主たるコンテナを変更せずに横断的な機能(ログ転送など)を横付けするサイドカーコンテナへの対応があると便利です。ただ、あまり複雑にすると手軽さが失われてしまうので対応の可能性は低そうではあります。

issue: https://github.com/aws/apprunner-roadmap/issues/71

PHPのマネージドランタイムでビルトインウェブサーバーをデフォルトにするのを今すぐにやめてください

前の記事 でも指摘していましたが、PHPのビルトインウェブサーバーは公開ネットワーク上で使うことを想定していないので、これはすぐにやめていただきたいです。

issue: https://github.com/aws/apprunner-roadmap/issues/157

まとめ

  • 2022年の各種アップデートでAWS App Runnerは進化を遂げた
    • VPCコネクタによりRDSなどVPC内リソースへの接続に対応した
    • プライベートエンドポイントによりWAFでの完全防御やマイクロサービスに対応した
    • マネージドランタイムがGoやPHPなどにも対応した
  • ECS/Fargateの代替として十分アリ
    • ただしAWS縛りがなければ Fly.io、Render、RailwayのようなPaaSかGCPのCloud Runのほうがまだ良さそう

スケーリングや料金面はまだまだAWS Lambdaが強いですが、エンドポイントの多いHTTP APIをなんでもかんでも全部Lambdaにするのは個人的には完全なるアンチパターンだと思っているので、コンテナ系のサービスには頑張ってほしいところです。

TOPに戻る