ku-mok
commented
8 months ago - VCでの議論は追えてないので、議論済み or 認識ずれがあるかもしれないですが、ざっとMiroとかIssue見て、インフラ・アーキで考えうることを共有しておきます。
- みなさんAWS用語で会話してる気がするのでAWS想定で
バックエンド（AP）
- スパイク耐性とコスト最適という観点であれば、APサーバはECS（Fargate backended）が順当
- EC2やECS（EC2 backended）はコスト観点、Lambdaはスパイク耐性（上限緩和申請で1,000 req/secより上げることはできはしますが…）から難あり
- スパイク時はAuto ScalingでScalingするまでは一時的に不通になるのは避けれれないが…（緊急地震速報と連動させて予め最小コンテナ数を引き上げるような仕組みは将来的に検討しうるか？）
- コスト的にも途中で死なれて困るような処理はあまりないと思うので、Fargete Spot使えばスケーリングしてもかなりコストは抑えられる想定
- コンテナ（ECSのService）をどこまで分けるかは要検討
- 細かく分けた方がきめ細やかにスケーリングできるが面倒は増える
- LBは今回の要件であればNLB（ALBは急激なスパイクには暖機運転が必要なので）
- WAFが使えないので、セキュリティ面で許容可能かは論点
バックエンド（DB）
- NoSQL前提で話していると思うのでDynamoDBか？また、普段はLowTrafic、災害時に急激なスパイクという特性上、スパイクしたときは割高になってしまうがOndemand Capacityとなる想定。
- Athenaみたいな話もどこかで上がってた思いますが、Webアプリのバックエンド、とくに今回みたいな用途であれば基本的には割高
- 検索要件に耐えられるかは要検証。スケーリングと検索を両立させるなら、検索だけはElastic Searchに投げるのが丸い
- あとは統計情報による集合知みたいなところがコンセプトにあるかと思いますがNoSQLであれば基本的に集計は辛い
- 要件次第ですが、データの追加時にDynamo Streamで集計用のLambdaに流して集計結果をDynamoDBに戻すのが丸そう
- S3 exportでS3に吐いてAthenaなりEMRなりで集計かける手もありますが、リアルタイム性に劣るので多分微妙
フロントエンド
- Next.jsならVercelでやってしまうのが簡単か？
- 細かくAWS上でやるなら、動的要素が少ない管理画面、投票用のUIはほぼ事前に静的生成できると思うので、Cloudfront + S3で配信するのがコスト・スケール性の観点から無難
- 投票結果閲覧用のUIはデータ取得が絡むこと、災害時には閲覧側の回線も輻輳ぎみになることを考えると、データ取得はサーバサイド（ECS）でやる（SSRする）アーキが良さげに思えた
- また、ある程度SSRサーバでキャッシュ（Nextの機能で）することで、バックエンドの負荷も抑えられるはず
構成図イメージ
https://gist.github.com/ku-mok/75fd7a00c27e7ddcc62a4e22dfa603c1
- [ ]
suguru-toyohara
概要
欲しい要件
考えたこと
考えて欲しいこと