アーキテクチャ選定をやってみよう

アーキテクチャ選定をやってみよう勉強会

1. システムの概要 2. アーキテクチャ選定のルール 3. Q1〜Q7 アーキテクチャ選定 4. Q8 おまけ
目次

システムの概要

4 システムの概要 ⚫投票システムです ⚫PCまたはスマホのWEBブラウザからアクセスして投票を行います ⚫投票にはユーザ登録が必要ですが、基本的に個人情報は必要ありません ⚫一人一票で、投票のロストは極力避けなければなりません ⚫投票中に情勢はわかる必要がありますが、正確な情報である必要はありません ⚫投票終了後に、改めて集計処理を行い、正確な結果を出力します

5 非機能要件 ⚫アクセス集中にも耐えられるようにする必要があります ⚫登録ユーザ数は100万人規模を想定 ⚫投票期間中のピーク時には数万リクエスト/秒のアクセスが見込まれます ⚫投票の開始直後と締切間際にアクセスが集中する傾向があり、 ⚫通常時の10倍以上のスパイクに対応する必要があります x10

アーキテクチャ選定

7 アーキテクチャ選定のルール ⚫フロントエンド、認証基盤、バックエンド、インフラ、データベースの基本的なWEBアプリケーション構成を前提とします ⚫各設問で選択肢から1つを選んでください ⚫回答後、別画面の構成図に随時反映していきます

8 Q1. フロントエンドのフレームワークフロントエンドにどのフレームワークを採用しますか？ A. React（SPA / Vite）クライアント側で画面を描画する構成 B.
Next.js（SSR / SSG）サーバー側で画面を生成しキャッシュも活用できる構成 C. Vue.js（SPA / Nuxt） Reactと同様にクライアント描画、Nuxtならサーバー描画も可 D. Astro（静的サイト生成）ビルド時にHTMLを生成する軽量な構成 Frontend Hosting Auth Backend Database 監視失敗対策

9 Q2. フロントエンドのホスティングフロントエンドをどこにホスティングしますか？ A. S3 + CloudFront（SPA配信）静的ファイルをS3に置き、CDNで高速配信する構成 B.
Vercel（Next.js等のSSR対応） Next.js開発元のホスティング、SSRをそのままデプロイ可能 C. Cloudflare Pages（エッジ配信）世界中のエッジサーバーでコンテンツを配信する構成 D. ECS / Fargate上のコンテナでSSR配信自前のコンテナ環境でSSRサーバーを動かす構成 Frontend Hosting Auth Backend Database 監視失敗対策

10 Q3. バックエンドの実行基盤 APIをどのコンピューティング基盤で動かしますか？ A. サーバレス（API Gateway + Lambda）リクエストが来た時だけ起動、使った分だけ課金
B. コンテナ（ECS / Fargate） Dockerコンテナを常時稼働、柔軟なスケーリング C. コンテナオーケストレーション（EKS / Kubernetes）大規模コンテナ群を自動管理、運用コストは高い D. 仮想サーバ + オートスケーリング（EC2 / Auto Scaling）従来型のサーバー構成、負荷に応じて台数を増減 Frontend Hosting Auth Backend Database 監視失敗対策

11 Q4. データベースの選定投票データをどのデータストアに永続化しますか？ A. リレーショナルDB（RDS / Aurora MySQL /
PostgreSQL）テーブル構造でデータ管理、複雑な集計クエリが得意 B. NoSQL / キーバリューストア（DynamoDB）キーでデータを管理、大量の書き込みに強くスケールしやすい C. インメモリデータストア（MemoryDB / ElastiCache）メモリ上で超高速に読み書き、容量あたりのコストは高い D. 分散データベース（Aurora DSQL / TiDB）複数リージョンにデータを分散、大規模向けだが構成が複雑 Frontend Hosting Auth Backend Database 監視失敗対策

12 Q5. 認証基盤ユーザ登録・ログインをどの仕組みで実現しますか？ A. Amazon Cognito AWSのマネージド認証サービス、手軽だがスケール上限に注意 B. OSSの認証基盤（Keycloak）
自前で構築・運用、サーバー増強でスケール上限を自分で制御可能 C. Auth0 SaaS型の認証基盤、高機能だがユーザ数に応じてコスト増 D. Firebase Authentication Googleのマネージド認証、モバイル向けだがWebでも利用可 Frontend Hosting Auth Backend Database 監視失敗対策

13 Q6. 監視どのレイヤーの監視を最も重視すべきだと思いますか？ A. フロントエンドユーザ体験の劣化（表示速度・エラー）を検知 B. 認証基盤ほぼ全リクエストで通る箇所、ここが落ちると全機能停止
C. バックエンド APIの応答速度やエラー率を監視 D. データベース書き込み・読み取りの遅延やコネクション枯渇を検知 Frontend Hosting Auth Backend Database 監視失敗対策

14 Q7. 投票の失敗対策負荷が高まった際に、投票のロストを避けるためにどのような対策を講じますか？ A. キューを導入して受付を優先し、DBへの書き込みを非同期化する受付だけ即完了、DB書き込みは順番に処理してスパイクを吸収 B. フロントで受付完了を即座にフィードバックし、処理は後続で行う UI上は即完了表示、裏側で非同期処理（失敗時のリカバリが複雑）
C. 投票の受付数を制限して、ピーク時の負荷を抑える流量制限で過負荷を防ぐが、投票できないユーザが発生する可能性 D. バックエンドのスケーリングを自動化してリアルタイム処理するサーバーを自動増強、ただしスケール完了まで時間がかかる場合あり Frontend Hosting Auth Backend Database 監視失敗対策

おまけ

16 Q8. おまけ主催者（兼安さん）を絶対に逃さないインシデント管理を考えてください A. CloudWatch Alarms → SNS →
Slackに通知 B. PagerDuty連携でスマホに電話 C. Slack通知 + メンション爆撃 D. スマートホーム連携で自宅の照明を全点灯 E.自宅のプリンターが「インシデント発生」をA4用紙に無限印刷

アーキテクチャ選定をやってみよう

アーキテクチャ選定をやってみよう

山本竜也

Other Decks in Education

Featured

Transcript