動作確認
ALB のヘルスチェックの確認
EC2 コンソール からロードバランサーを開いて、ターゲットグループ を確認します。
動作確認
メモ帳などにコピーしてある、ALB の DNS にブラウザからアクセスしてみます。
(httpsではなく、 http でアクセスします。)
DNS は ロードバランサーを開いて、自身の ALB にチェックボックスを入れることで再確認ができます。
Fargate によるコンテナのスケーラビリティを確認
早速 Fargate を使ってコンテナをスケールさせていきましょう。
EC2 ではタスクを 2 つまで増やしましたが、今回は 4 つに挑戦してみます。
Fargate は時間単位の従量課金とはいえ、課金 にはくれぐれもご注意下さい！
このコンテナWebアプリを果たして何処までスケールさせることができるのか、気になる方がいらっしゃるかもしれません。
AWS では各サービスごとの制限を設けており、この範囲内でリソースをスケールさせることが可能です。
この制限はユースケースによっては上限を緩和できる場合もあります。詳しくはドキュメントをご参考下さい。
サーバーレスのメリット
ハンズオンの手順や最終的なアプリ画面だけを見ると、EC2 も Fargate も違いはないように見えます。
しかし、アプリケーションはデプロイして終わりではなく、その後の 運用 が必ず手順として生じてきます。
こちらが EC2 と Fargate の運用コストの差を図にしたものになります。Fargate と違って、EC2 は VM の運用をする必要があります。
セキュリティの確保のために OS のパッチをあてる作業や、インスタンスのメトリクスを監視し、スケールに対応する手間を考えなくて済み、アプリケーションの開発といった 価値ある作業に集中 できることがサーバーレスのメリットとなります。
目に見えるコスト（AWS利用料）はFargateのほうが高いですが、EC2で運用した場合種々の運用に関わる人的コストが目に見えないコストとしてかかるため、TCOを意識してそれぞれの起動タイプ比較する必要があります。
時間の余った方は、次の課題に挑戦してみましょう。
- サービスに Auto Scaling を設定して Cloud9 内の Apache Bench から負荷をかけてみる
- 新しいコンテナイメージ (PHP+NGINXなど) を作成し、Fargate でデプロイしてみる
- コンテナ用の CICD パイプラインを作成してみる
以上でハンズオンは終了となります。お疲れさまでした！