Zenn
🚀

AWS App Runner採用の決め手 〜インフラ構成の最適化〜

2024/12/24に公開

はじめに

こんにちは!株式会社ブロードエッジ・ウェアリンク CTOの高丸です。
今回は、Qiita Advent Calendar 2024の7日目の記事です。

5日目の記事でFastAPIを使った新バックエンドAPIを構築した話を書きましたが、
今回は、それをAWSで運用する上で、App Runnerを選択したことに関して書いていきます。

https://aws.amazon.com/jp/apprunner/

AWS App Runnerを選定したきっかけ

我々のインフラ環境はAWSなのですが、既存のカルテシステムの環境に、ECS(Fargate)を利用していました。

技術的には問題なく動作していたものの、CDを組んでいなかったため、属人的なデプロイ方法になっていたことがまず問題として挙げられます。

また、現場のメンバーのスキルや、とりくんでいたリプレイスプロジェクトがコーディングに集中しなければいけないことを考えると、デプロイ方法は単純で、インフラ管理コストがほぼ掛からない方法が必要でした。

当初はFargateの継続利用も検討しました。
ある程度のアプリケーションの規模で、サーバーレス環境となると、AWSではFargateがコンテナのカスタマイズ性も高く、技術選定としては良いと考えていました。
しかし、個人的にはGoogle CloudのCloud Runが好きで、あの開発感覚が欲しかったので、Fargateは少し面倒に感じてしまっていました。

また選定の大きなきっかけとしては、「App Runnerが便利」という記事を見かけることが、ここ数年で多くなってきたのも事実です。

以下の記事は大変参考になりました。

https://pages.awscloud.com/rs/112-TZM-766/images/BOS22_AWS-Builders-Online-Series_2022-Q3_Presentation-Deck.pdf
https://speakerdeck.com/track3jyo/app-runner-the-appeal-and-evolution-over-3-years-since-launch
https://speakerdeck.com/n1215/aws-app-runnergasorosoroben-fan-huan-jing-demoshi-iwu-ninarisou

App Runnerに対し、2022年前半までは「本番利用までには至らない」という意見が多かったですが、2023年以降はポジティブな印象が多く、「こういう環境を待っていた」というのも多かったです。
(もちろん、まだ改善の余地もあります)

AWSでサーバーレス環境を選ぶなら

サーバーレス環境の選択で私が最も重視しているのは、アプリケーションの複雑度です。
AWSの主要なサーバーレスサービスは、それぞれ以下のような位置づけで使い分けるのが良いと考えています:

  • Lambda:個別の細かい処理を繋ぐのに最適
  • App Runner:まとまったAPI群の実行環境として理想的
  • Fargate:より複雑なインフラ構成が必要な場合の選択肢

特にAPI群をすべてLambdaで実装しようとすると、個々の関数の管理や関数間の連携が必要になり、かえって複雑になってしまうことがあります。(Step Functionsの活用なども要検討)

その点、App Runnerは、まとまったAPI群としてはちょうどよい環境です。

App Runnerの最大の魅力は、デプロイメントの簡潔さにあります。
Dockerコンテナをビルドして、ECRにプッシュするだけでデプロイが完了します。

特に初期段階では、我々のアプリケーション自体はそれほど複雑ではありませんでしたが、高頻度のデプロイを実現したいという目的がありました。App Runnerは、まさにこのニーズにぴったりとマッチしました。

もちろん、アプリケーションの成長に伴って要件も変化していきます。例えば、サイドカーコンテナが必要になったような場合は、その時点でFargateへの移行を検討する、という判断基準を私の中では設けています。

App Runnerで気をつけなければいけないところ

一般ユーザーがアクセスできるようにパブリックエンドポイントでの使用の場合、App Runner環境は独立した環境となり、VPC内部と連携が必要な場合は、VPCコネクタが必要というところで、そこにハマりました。

VPC内部に入ったあとは、VPCの通信経路に従うので、例えばS3にアクセスする場合にはVPCエンドポイントが必要だったり、接続される側はVPCコネクタに付与したSGからの許可をする必要があったりと設定に手間取ることがありました。(弊社のSTG環境と本番環境の差異で苦労した部分もあります)
このあたりから、Terraformによる管理も追加していった感じになります。

あとは、弊社環境に特殊なNACLがあり、それが原因でApp RunnerからShopifyに通信が出来ない事象が発生したのを、VPC Flowlogsを使って調査したこともありました。

苦労したのは、弊社のもともとのネットワーク環境の設定ミスによるもので、App Runnerに依存するものは少なかったと思います。

コストに関しても、稼働していない場合はメモリのみの課金(プロビジョニングされたコンテナインスタンスの料金に該当)のため、妥当なコストに抑えられていると思います。
(Fargateは設定したCPU・メモリで一定の料金が発生し、LBも別で設置する必要があります)
https://aws.amazon.com/jp/apprunner/pricing/

技術選定としてアリだったか

やはり一番の効果はデプロイ回数が増やせたことだと思います。CDの整備含め、誰でも簡単にデプロイ・ロールバックできることが大事だと思います。

しばらくは、これ以上複雑なインフラにならない限り、Webアプリケーションのインスタンスで困ることはないかなと思います。(別途アプリケーションの問題でDBのコネクション数が異常な数値になる現象があったのは後日の記事で紹介します)

これからもAWSでのモダンなアーキテクチャの1つとしてのApp Runnerに期待しています!

Discussion

ログインするとコメントできます