[STP211-R] Scaling on AWS for your first 10 million users（アーキテクチャ）

投稿日: 2022/12/09

ビジネス初期 AWS インフラストラクチャにおいて、急速な成長に対応する能力を構築するための成功したパターンとテクニックについて説明するセッションです。スケーラブルなAWSサービスの実装から実績のあるパターン設計まで、一般的なインフラストラクチャの課題を克服できるアーキテクチャの例を紹介しました。

ユーザーが少ない基本的な構造から、10万、100万ユーザーを対応するレベル、さらにその先のマスサービスまで、どのように拡張し構成していくかを紹介したいと思います

「app」の定義をシステムの観点から単純化すると、frontend + backend + data storage に分類できます。

ユーザーが少数の最小サービスアーキテクチャは、以下のようにpresentation、business、dataとして古典的に使用してきました。

しかし、最近では、フロントエンドフレームワークの流行に応じて、ホストベースのような典型的な構成は好まれていない。

modern frontend 開発方式を使用する理由は以下の通りです。

1) 運用コストオーバーヘッド減少
2) scale/性能が優秀
3) modern frontend 技術に適用可能

Amplify Hosting では、リポジトリからコードを管理し、ビルドし、デプロイまでパイプラインとして処理します。

Amplify Hostingの利点と特性は、下の図に示されています。

コンピューティングリソースで、古典的なホストではなく、EC2、ECS/EKS、AWS Lambdaなど多様な選択が可能になりました。

古典的なインスタンスベースのバックエンド構成は、まだ有用な方法、または下の図のようなdisadvantageを持っています。

上記の課題を克服するために、AWSの管理対象サービスを使用することをお勧めします。

上記の画像のように、AWS managed service を使用して利点を最大化できます。

business logic APIとして利用できる3つのオプションです。

AWS App Runner で build、deploy、container ベースのウェブアプリケーションを管理運用でき、管理ポイントのオーバーヘッドを削減します。また、流行する開発言語もサポートする最適なマネージドサービスです。

こうして作られた modern style の frontend & backend アーキテクチャが上記のとおりです。

これでデータベースだけを決定すればよく、一般的に最もよく使われ、リファレンスも多くのSQLを考慮するようになります。

しかし、サービスの初期から大量のデータを管理する必要があるか? の質問に対する答えは No です。言い換えれば、SQLではなくNoSQLも十分な選択肢になる可能性があります。

他にもNoSQLの導入を考慮すべき要素は以下の通りです。

1) 応答時間遅延のないアプリケーション
2) meta-dataに基づくデータ型
3) 非関係型データ
4) スキーマを必要としない柔軟なデータ
5) 入力が頻繁なデータ

SQLとして、Amazon Auroraは優れたパフォーマンスと管理の利便性、強力なセキュリティで急速に成長してきました。

オンデマンドで自動スケールアウトが可能なAurora Serverless v2を紹介します。

最後に、上の図のようなモダンなスタイルのアーキテクチャで構成されています。

10000ユーザーを超えると、どのような問題が発生しますか？さまざまなサービスを追加すると複雑さが増し、パフォーマンスが低下し、データも大量に蓄積されます。

Frontend 領域の scalability 拡張は cloudfront を考慮してみます。グローバルサービスをサポートし、backend呼び出しを減らし、cachingで応答速度を上げることができます。

サービスモニタリングにはcloudwatch、x-rayを推奨し、Machine Learning（ML）が効率的に役立つと考えられます。

スケール拡張用のチューニングポイントを見つけることができますが、データベース拡張が必要な場合は、Aurora Severless v2:scaling は cpu と memory、storage でサービス運用に影響を与えずに拡張が非常に容易です。

scaleupだけでなく、最大15台までのread replica拡張が可能で、multi-AZに安定した拡張と運用が可能になります。また、Amazon RDS Proxyでscaling、failover、db access contol機能まで提供する。

このように構成した DB scale 拡張された様子は上記と同じです。

RDSデータだけでなくキャッシュデータが必要な場合は、RedisまたはElastiCacheが必要です。

cache まで追加された data tier の構成図です。

完成した data tier の拡張アーキテクチャです。

backend apiとしてのApp Runnerのスケールアップは、内部的には以下のようにECS fargate単位でリソースが割り当てられ、スケールアウトが柔軟にサポートされます。request がなくなると idle 状態に自動的に scale in されて provisionした min サイズ維持し、コストを効果的に節約できるようになります。