AWS Amplify ConsoleでSSRアプリの複数環境(Multi Environment)を作ってみよう - 前編

はじめまして、古田です。アプリ中心にシステムアーキテクト的なお仕事をしています。

先日、Amplify ConsoleのSSR(Server Side Rendering)アプリ対応が社内で話題になっていました。そこで今回は、Amplifyって何?という方にも解るようにAWS Amplifyの概要の説明と、実際のアプリ環境を例にAmplify Consoleという機能にスポットを当ててご紹介したいと思います。
(そしてさらに、新機能を用いてSSRアプリの構築を試していくのですが、長くなってしまったのでそちらは後編で続けたいと思います。)

AWS Amplify について

Amplifyはモバイル・ウェブアプリ向けの開発ツール群です。簡単に言うと、私のようなインフラに疎いエンジニアが、超高速でAWS上にアプリを構築できてしまうサービスです。mBaaSに分類され、Google CloudにおけるFirebaseと同じ方向性のサービスと言えます。

Amplifyには性質の異なる多くのツールが含まれるため、それぞれがどのような役割を持っているのかをしっかり理解する必要があります。公式の説明に沿って、以下の様に体系的に覚えるのが良いでしょう。

開発

認証・ストレージ・データストア等のバックエンド構築と、それらをフロントエンドから操作するためのライブラリです。バックエンドの実態はそれぞれCognito・S3・DynamoDB等お馴染みのAWSサービスですが、そのサービスの設定項目やAPIに熟知せずとも構築・操作ができるという思想になっています。

配信

Gitリポジトリと連携したCI/CD機能や、マネージドなホスティング環境が用意されます。ブランチごとフロント・バックエンド環境を複数用意するといったことが可能です。

管理

バックエンドのAWSリソースを管理するための、専用の管理画面と管理者ユーザが提供されます。例えばAmplifyで構築したバックエンド・データストア(DynamoDBテーブル)の中身を、AWS CLIやマネジメントコンソールを経由せず、専用のイケてるUIから参照・更新することができます。

  • Amplify Admin UIと言い、昨年後半にリリースされた比較的新しい機能です。

Amplify Console でできること

さて、本題のAmplify Consoleです。ここは言葉より目で見た方が早いと思うので、実際に構築したアプリ環境の全体図をご紹介します(※これはSPAです)。

f:id:t2-furuta:20210528085214p:plain
Amplifyを利用した複数環境とGitフローの全体図
前提

  • 外部リポジトリはBitbucketを利用
  • master、developが保護ブランチで、feature/xxxがトピックブランチ
  • featureで開発したらプルリクレビューしてdevelopへ反映
  • スプリントレビュー終わったらmasterへ反映し本番公開

Amplify Consoleを使うことで、このようなGitフローに対応した環境を比較的簡単に作ることができるんです。具体的に見ていきましょう。

フロントエンドの自動ホスティング

外部のGitリポジトリ(GitHub/Bitbucket/CodeCommit等)と接続し、ブランチと連動してフロントエンドアプリケーションのビルド~ホスティングをすることができます。
今回の例ではdevelop・masterはもちろん、featureブランチも増える度に専用のフロントエンドURLが作成されます。プルリクレビューの際、レビュアーはそのサイトで動作を確認することができます。*1

バックエンドの自動構築

バックエンドを複数構築し*2、それぞれをブランチと紐づけて定義することができます。リモートブランチへPushすると、そのブランチに対応する環境のバックエンドが構築されるので、バックエンドのCI/CDもできてしまうという訳です。
このアプリでは、本番サイトのPROD環境、チームでレビューしたり偉い人にデモをするSTG環境、じゃんじゃん開発をするDEV環境があり、それぞれmaster・develop・featureブランチに対応させています。もうちょっと言うと、DEV環境のバックエンドはAmplify CLIで直接更新し、STG環境とPROD環境はAmplify Consoleで更新する形にしています。

ポイント
  1. 単純な複数環境だけでなくフロントエンド・バックエンド多対1という構成もOK。
  2. GitリポジトリをAmplify Consoleと紐づけるだけでCI/CDが(ほぼ)片付くので、別のAWSアカウント上にも簡単に環境構築が可能。

Firebaseも1プロジェクト内で複数サイトをホスティングすることは可能ですが、それだと図のDEV環境の範囲にしかなりません。Firebaseで複数環境するのであれば基本的には複数プロジェクトを用意するのですが、このような構成となるとGitHub Actionsをそれなりに手間かけて組み立てる必要がでてきます。

そもそもAWS・GCPは大きく思想が異なるサービスなので、単純に比較することはできませんが、個人的にはこのAmplify ConsoleがAmplifyのミソとなるツールかなと思っています。

まとめ

バックエンドのAWSサービスを知ってるとぶっちゃけこれAmplifyで構築しなくてもいいんじゃね?とか邪な考えが頭をよぎる時があるかもしれません。そんな時は、それらのリソース全部のCloudFormationテンプレートを自分で書いて、CodePipeline・CodeDeployを組んで複数環境へのCI/CDする手間を想像してください。多分、思いとどまれるんじゃないでしょうか。みなさん、Amplify、特にAmplify Consoleに感謝しましょう。

Amplifyが対応する以前から、FirebaseではCloud Functionsを使ってSSRアプリのホスティングができました。その辺のホスティングサービス*3とも比較しつつ、後編では実際にSSRアプリで同様の環境を作ってみたいと思います。

f:id:t2-furuta:20210528013221j:plain

執筆者古田拓也

たぶんシステムアーキテクト。
C#とXAMLが好きで、JavaScriptが苦手です。

Twitter

*1:Amplify Consoleにはプルリクエストごとに環境を作ってくれるPreview機能があります。この事例を構築した当時はGitHubしかPreview機能に対応していなかったのですが、この記事を書きながら触っていたら、現時点はBitbucketも使えるようになっていました。このフローは変えてもいいかも。

*2:厳密にはバックエンドを複数作ること自体はAmplify Consoleでなくamplif envの機能で、Amplify CLIでも作れます。

*3:世の中にはNetlifyやVercelとかあると思うのですが、品質を大切にするEnterpriseyな世界では、SOCやISOなんたら対応といったセキュリティ的・リーガル的な厳しい社内ガイドラインを突破できるクラウドサービスは少ない。