1. はじめに
Nuxt.jsを容易にデプロイしてインフラ運用の負荷を削減したいので、AWS Amplifyを導入することが決まりました。
Amplifyは、GitHubと連携でき、pushするたびに自動でデプロイしてくれるため、非常に便利です。
ただ、インフラ運用の負荷がないとはいっても、どのような仕組みなのかを理解する必要があるため、調査しました。
2. Amplify 日本ユーザーグループ / 導入事例
Amplifyに関するサイトがまとまってるため、とても参考になります。
導入事例も参考になるかもしれないです。
3. GitHub / CI/CD
GitHubのリポジトリとAmplifyを紐づけるだけで、あとはよしなにCI/CDを実行してくれます。
添付画像の通り、GitHub以外のサービスも可能です。
4. AutoScaling(オートスケーリング)
AutoScalingは自動で行われるため、開発者側で設定する必要はありません。
ALBなどのロードバランサーの構築も不要です。
下記「AWS Amplify のよくある質問」の記事より、
内部的にCloudFrontを利用しているとのことです。
AWS Amplify は、Amazon CloudFront のグローバルエッジネットワークを活用して、ウェブアプリをグローバルに配信します。
Amplifyはフルマネージド型のため、AutoScalingは自動的に行われるという仕組みとなります。
AWS Amplify では、フルマネージド型のウェブアプリケーションと静的ウェブホスティングサービスも利用可能です。
5. どれくらいの規模まで利用が可能か
フルマネージド型のため、どれくらいのアクセスまで対応しているかは負荷テストを行い、開発者側で対応できるかどうかを判断する必要があります。
スペックで注意すべき点は、リクエストトークンというものになります。
もしこちらに抵触した場合には上限緩和の申請を行えます。
アプリの 1 秒あたりのリクエストトークンの最大数。Amplify Hostingは、消費するリソースの量(処理時間とデータ転送)に基づいてトークンをリクエストに割り当てます。
このトークン残量の状況については、CloudWatchで監視ができないため、クライアント(Webブラウザ)に対して、HTTPステータスコード:429がレスポンスされる状況により判断することができます。
Amplify は、受信リクエストが消費する処理時間とデータ転送に基づいて、ウェブサイトへの 1 秒あたりのリクエスト数 (RPS) を制御します。アプリケーションが 429 HTTP ステータスコードを返した場合、受信リクエストはアプリケーションに割り当てられた処理時間とデータ転送の時間を超えています。このアプリケーションの制限は、Amplify のサービスREQUEST_TOKENS_PER_SECONDクォータによって管理されます。クォータの詳細については、「Amplify ホスティングService Quotas」を参照してください。
もしかすると、Amplifyのアクセスログなどで確認ができるかもしれません。
(実際に429のログが出力されるかの確認までは、こちらで行えませんでした)
6. 冗長化 / 可用性
AWS側でAZやリージョン単位で障害が発生した場合、他のリージョンにて利用することが考えられます。
ただ、Amplifyを利用する上では、AWS側の復旧を待つというのがいいかなと個人的に思いました。
7. https接続(SSL証明書) / サブドメイン
Route53のホストゾーンを構築しておくことで、Amplifyから簡単に設定することが可能です。
SSL証明書の設定などは不要で、Amplify側でよしなにやってくれます。
8. AWS WAFとの連携(DDoSやSQLインジェクションなど)
Amplifyの前段に、CloudFrontを配置することで、AWS WAFを使って、実装することが可能です。
Amplifyの内部的にCloudFrontは存在してはいますが、別途用意が必要ということになります。
9. SSR
10. Basic認証
アクセスコントールからBasic認証の設定ができます。
フロント側での実装が不要であり、dev/stg環境へ簡単に設定できるため便利な機能です。
11. さいごに
AWS Amplifyは、一度構築してしまえば、GitHubへpushするたびに自動デプロイされ、かつインフラ管理は、ほぼほぼ不要です。
ストレステストは、必ず実施してください。
どれくらいの規模まで利用できるかがわからないのが欠点ですが、トークンを増やせば結構な大規模の案件でも利用できるのではないかと考えてます。
是非とも使ってみてください。