😇

App Runnerの登場とAmplify ConsoleのSSR対応でVPCレスなAWSアーキテクチャを夢見た話

2021/05/19に公開

AWS

Amplify

App Runner

tech

はじめに

新サービスの AWS App Runner が発表されました、そして AWS Amplify Console が Next.js(バージョン 9 の機能をサポート)を使っての Server Side Rendering と Static Site Generate に対応しました。

この 2 つのサービスを使うことでフロントエンドもバックエンドも VPC レスでスケーラビリティのある AWS アーキテクチャが実現可能になりました。もちろん、リリースされたばかりでこのアーキテクチャに載せることができるソフトウェアは限られたものです。しかし、将来の VPC レスアーキテクチャを夢見ることができたので、個人的な思想を元に現状でどこまでできるのかや VPC レスで何がうれしいかなどを雑多に語っていきます。

2 つのサービスの概要

共通

PaaS 的なサービスでデフォルトでメトリクスやログを記録する仕組みを持っており、最低限の定義でソフトウェアをデプロイができるサービスです。

AWS App Runner

App Runner は Docker コンテナイメージまたはソースコード(Python、Node.js)から AWS にウェブアプリケーションをデプロイするためのサービスです。非常に強力に抽象化されており、開発者はインフラストラクチャーのことをほぼ意識せず Auto Scaling 可能なアーキテクチャをデプロイする事ができます。Cloud Run、Google App Engine、Heroku あたりと競合しそうなサービスです。

AWS Amplify Console

Amplify Console はフロントエンドに特化した静的な Web ホスティングをホスティングするためのサービスです。Basic 認証やリダイレクト設定、高度な Git リポジトリとの連携も可能です。Netlify、GitHub Pages、Firebase Hosting あたりと競合しそうなサービスです。機能追加で Next.js v9 の SSR および SSG に対応し API 機能によってウェブ API も合わせてデプロイが可能になりました。

詳細は下記のブログを参照してください。

https://dev.classmethod.jp/articles/aws-amplify-console-guide-lines-for-frontend-engineer/

なぜ VPC レスなアーキテクチャがうれしいのか

VPC は仮想サーバーなどのリソース同士をプライベートなネットワークで接続可能にさせてくれる非常に素晴らしいサービスです。私が AWS 経験の無いインフラエンジニアに最初に学ぶ AWS サービスを進めるなら VPC か Amazon EC2 のどちらかになるぐらい重要かつ基本的なサービスです。

しかし、VPC の中でウェブアプリケーションをスケーラブルに動かそうとすると Elastic Load Balancing、Amazon ECS、Nat Gatewaty や他にはスケーリングの為に AWS Auto Scaling など多くの AWS サービスについての学習が必要になります。VPC はとても便利なサービスですが使わなくて済めば管理する情報、リソースが減りアーキテクチャは保守しやすくなります。

また、現代では Amazon S3、Amazon DynamoDB、MongoDB Atlas のような HTTPS で非プライベートネットワークからリクエストを受け付ける事が可能なリソースが当たり前になっておりプライベートネットワークは必須ではなくなりつつあります。

なので VPC レスでアーキテクチャを実現できることは、とてもうれしいです。

サーバーレスアーキテクチャと比べてどうなのか

今回紹介している VPC レスなアーキテクチャはサーバーレスアーキテクチャに内包されるアーキテクチャです。比較するようなものではなく、サーバーレスアーキテクチャをプロセスモデル(Lambda のようなスレッドモデルではない)で VPC を使わないことが可能になったと捉えています。

今まではサーバーレスアーキテクチャを実現したい時は、プロセスモデルが必要なら Fargate を使う = VPC を使うことが必須でした。(厳密には Amazon Lightsail が Docker コンテナに対応していたので、今回の App Runner が初めてではありませんが、あちらが Public ECR にしか対応していないことやサービスの立ち位置的にまた目的が違うと思います。)今後は App Runner を使うことでプロセスはモデルのサーバーレスアーキテクチャを AWS で実現可能になりました。

フロントエンドも App Runner で動かすべきか？

App Runner は Node.js、Docker コンテナに対応しているのでフロントエンドも App Runner で動かす事ができます。抜粋ですがメリット・デメリットを整理してみます。

Amplify Console で動かすメリット

スケーリングの設定が不要である(内部で S3、Lambda@Edge を使用する為)
自動 Git ブランチの検出と連携
プルリクエストに対してプレビュー環境の自動生成

Amplify Console で動かすデメリット

Next.js の v9 しか対応していない(Nuxt.js や Next.js v10 に対応できない)
CloudFront や Lambda@Edge がマネジメントコンソールから見えてしまう
Lambda@Edge の制約を受ける(https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-requirements-limits.html)

現状だと Next.js の v9 しか動かせないのが特に厳しいと感じるデメリットです。(生成されるリソース的に Serverless Framework の Next.js Plugin を流用している？)AWS によるアップデートで v10 に対応したとして Next.js がアップデートするたびに遅れが発生してしまいます。

なので、例えば B2C の本番利用には厳しいかなと感じており、今後のアップデートに期待しています。現時点ではフロントエンドも App Runner にデプロイするのが安定択でしょう。

App Runner の Aurora や ElastiCache などの VPC 内リソースとの連携について

App Runner は隠蔽された VPC 内で動作していますが(https://docs.aws.amazon.com/apprunner/latest/dg/security-data-protection-internetwork.html)、隠蔽されているので Aurora や ElastiCache を同一の VPC 内に作ることは出来ないし VPC ピアリングして接続することもできません。

ロードマップに既に App Runner から VPC 内リソースにアクセスを可能にする Issue(https://github.com/aws/apprunner-roadmap/issues/1)が作成されていますが、これの実現方法がとても気になっています。というのも単に別途 VPC を作成しその中に Aurora を作成して App Runner 側から特殊な VPC ピアリングを張るみたいな形になってしまうと結局 VPC が必要になってしまいます。もしこれが実装されるなら AWS がどのように実装するかとても楽しみに思っています。

まとめ

Amplify Console の SSR 機能はまだ使えるケースが限定的なので今後に期待
App Runner は既に完成度が高い、フロントエンドにもバックエンドにも使える
App Runner が Aurora や ElastiCache と繋ぐ場合でも VPC レスで出来たらうれしい