【AWS re:Invent 2024】Scaling on AWS for the first 10 million users

初めに

日々成長していくビジネスと共にシステムも成長していかなければなりません

本セッションでは成長に対処していくための方法を、User数に応じて学ぶセッションとなります

全60枚以上のスライドでボリュームがあるため、一部を抜粋して記載させていただきますのでご了承ください。

アプリケーションの定義

このセッションで説明されるアプリについて定義されました

以下をアプリとして定義していきます

• ユーザーインターフェース層
• ビジネスロジック層
• データストレージ

Day1

ユーザーが1人以上

ユーザーが少ない立ち上げ初期のケースです

従来のシステム

JavaScriptを使用したシンプルなスタック

• ウェブサーバーアプリのホスティング層（例：nginx、Apacheなど）
• オプションの共有ストレージ層
• ロードバランサー
• CDN（コンテンツ配信ネットワーク）

新入社員トレーニングで作ってみようの教材になりそうです。

モダンなシステム

構成図を見ての通りスッキリしました

開発者はデプロイに集中できて、運用者が保守する必要も最小限です

• 運用の負担を大幅に削減
• スケールやパフォーマンスが組み込み
• モダンなフロントエンドフレームワークとの統合
• 開発者体験（DX）に適合した機能

重要なのはモダンな構成はフロント、バックエンドが別のコンポーネントになっていること

Amplify Hostingにより継続的なデプロイとアプリを簡単にデプロイ・管理・スケールできます

詳細はこちら

Amplify Hosting の未来

何枚もスライドで説明されていたのでAmplify Hosting を推していることが伝わってきます笑

モダンフレームワークのサポート

静的サイトジェネレーター（SSG）

サーバーサイドレンダリング（SSR）

クライアントサイドレンダリング（CSR：シングルページアプリケーション）

上記3つがあります

特にSSRはページロードの短縮によるSEOの改善につながるかと思います

知名度の少ない立ち上げ初期のシステムでは重要なことですね。

バックエンド

フロントエンドの次はバックエンドです

ここは悩ましいところですね、、

EC2をバックエンドにする場合

この環境はまず本番環境ではないですね

EC2が完全に単一障害点となっています

最後に面白い表現が「全ての卵を1つのバスケットに入れる？」

バスケットを落としたら終了です。分散させましょう。

ではどうすればいいか？

1つの答えはありません。ケース・バイ・ケースとなります。

EC2を使用すべきケースも当然あります

サービスを理解して適切な判断ができるようにしたいですね

ECS

とはいえやはりECSを推していそうです

説明を見る限りFagateが前提に見えます

保守に関してはFagateの場合かなり楽になります。パッチ適用の苦しみからも開放されます。

トラフィックに応じて自動スケールするので怯えることもありません。

EC2とECSは悩みますが、個人的にはこれからビジネス、システムが急成長していくのであればECSを選択します。

保守が全く無いわけではないですが、EC2と比べるとかなりの負荷が減ります。

運用者が個別でいないフェーズであればなおさらです。

まとめ

一部の内容だけでしたが、いかがでしたでしょうか。

Breakout sessionなのでこの後動画配信されるかもしれません。

これから成長していくシステムを開発、保守している方にはぜひすべての内容を見ていただきたいです。