ストコン売上集約大規模同時接続アーキテクチャ

概要

対象ユースケース: コンビニ大手（ローソン想定、約14,600店）のストコン AWS 移行案件における売上データ集約。全店から売上イベントが秒単位で同時に飛んでくる環境で、平均 2,433 TPS・ピーク 10,000 TPSを AWS マネージドサービスで捌く構成。

設計思想: 同期的に DB まで書くのではなく、API Gateway と DynamoDB の間に SQS を挟んで非同期化することで、スパイク吸収・リトライ責任分界・DB throttling の緩衝材とする。DynamoDB Streams 経由で EventBridge に fan-out し、重処理は ECS Fargate に、データレイクは Firehose で S3 に、と責務を分離する。

関連学習ノート: WBS 3.2.1 大規模同時接続設計（ハンズオンメモ） §6 の統合アーキテクチャを図化。

データフロー

Main POS → DynamoDB（主パス）

POS 店舗端末 (14,600店) → Route53 DNS → CloudFront Edge → API Gateway (10k RPS throttle, WAF) → SQS Standard (2,433 TPS) → Consumer Lambda (Reserved 500) → DynamoDB On-Demand

Stream DynamoDB Streams → データレイク

DynamoDB Streams → EventBridge custom bus → Kinesis Firehose (batched) → S3 Data Lake (raw, partitioned)

Heavy 重処理（集計・突合）

EventBridge → ECS Fargate (CPU 70% target AS) → DynamoDB On-Demand

Error 障害時経路

SQS (poison message) → DLQ → SNS Alert Topic (オンコール通知)

Obs 観測経路

Lambda / Fargate → CloudWatch Metrics & Alarms → SNS API Gateway → X-Ray Tracing

レイヤー構成

レイヤー	AWSサービス	用途
店舗（オンプレ）	POS 店舗コントローラ × 14,600	各店舗で売上イベント生成、HTTPS で AWS 送信
エッジ	Route53, CloudFront	DNS フェイルオーバ・エッジキャッシュ（静的コンテンツのみ）
Ingress	API Gateway (REST), WAF	API throttling（デフォルト 10,000 RPS / region）・認証（IAM または API Key）・不正アクセス防御
非同期バッファ	SQS Standard + DLQ	スパイク吸収、リトライ責任分界、at-least-once 配信、poison メッセージ隔離
主コンピュート	Lambda (Reserved Concurrency 500)	SQS からのイベント pull、DynamoDB への PutItem。同時実行上限で DB throttling を制御
重コンピュート	ECS Fargate + Application Auto Scaling	集計・突合など Lambda 15分制限を超える処理。CPU 70% target で自動追随
主ストレージ	DynamoDB On-Demand (sales-events)	書き込み毎にキャパ自動調整。ピーク 40,000 WCU まで対応
Fan-out	DynamoDB Streams, EventBridge custom bus	下流への非同期配信。ストリーム消費者の追加が既存パスに影響しない
データレイク配信	Kinesis Firehose, S3	バッチ書き込みで S3 コスト最適化、Parquet 変換、日付パーティション
観測	CloudWatch, X-Ray, SNS	メトリクス・ログ・分散トレーシング・アラート通知（夜間オンコール接続）

設計のポイント

1. API Gateway の直後に SQS を挟む理由
Lambda を直接 API Gateway に繋ぐと、同期実行の同時実行数上限（default 1,000）に張り付いた瞬間にクライアント 429 が出る。SQS を挟むことで書き込み側に背圧を吸収させ、Lambda 側は Reserved Concurrency 500 で DB throttling を上流から制御できる。年末年始・GW のピーク時もクライアント側には成功レスポンス（202 Accepted）を返しつつ、内部で非同期処理できる。

2. SQS は Standard 選択、FIFO にしない
売上データは「イベント単位で idempotent」（店舗 ID + タイムスタンプでユニーク化可能）なので、順序保証より throughput 優先。Standard は unlimited throughput、FIFO は 3,000 msg/s（batch化で）まで。14,600店×10イベント/分 = 2,433 TPS は Standard の得意領域。

3. DynamoDB On-Demand を選択、Provisioned にしない
全店一斉棚卸や月次締めなどアクセスパターンが予測困難なため、On-Demand の自動スケール（30秒以内に2倍まで）を優先。Provisioned で Auto Scaling を組むとスケール遅延でスロットリングが発生する。ただし月額コストは On-Demand のほうが2〜3倍高いため、定常運用が見えた Phase で Provisioned 移行を検討。

4. DynamoDB Streams + EventBridge で fan-out
主パス（Lambda PutItem）と下流処理（データレイク配信・重処理）を疎結合にする。Lambda は DynamoDB に書くだけで責任完了。Streams が変更をキャプチャ、EventBridge が rule で下流にルーティング。新しい消費者（例: リアルタイムダッシュボード）を追加しても主パスに影響しない。

5. DLQ + CloudWatch + SNS の最小観測セット
poison メッセージは SQS visibility timeout と maxReceiveCount（3回）超過で自動的に DLQ へ。DLQ のメッセージ数を CloudWatch Alarm で監視し、SNS トピック経由で PagerDuty/Slack に通知。店舗運用を止めないため夜間オンコール必須。

コスト概算

ap-northeast-1 (東京) リージョン基準の月額概算。実際の費用は利用量により変動します。為替レート: $1 = 150円

サービス	構成	Dev (月額)	Prod (月額)
API Gateway (REST)	$3.50/100万リクエスト	$10-30 (1,500-4,500円)	$250-500 (37,500-75,000円)
CloudFront	エッジキャッシュ + 転送	$5-15 (750-2,250円)	$50-200 (7,500-30,000円)
Route53	Hosted Zone + Query	$1-3 (150-450円)	$5-15 (750-2,250円)
WAF	Web ACL + ルール	$5-10 (750-1,500円)	$15-30 (2,250-4,500円)
SQS Standard + DLQ	$0.40/100万リクエスト	$5-15 (750-2,250円)	$80-150 (12,000-22,500円)
Lambda (Consumer)	Reserved 500, 200ms/実行	$20-50 (3,000-7,500円)	$400-800 (60,000-120,000円)
ECS Fargate	0.5 vCPU × 平均 4 task	$30-60 (4,500-9,000円)	$200-400 (30,000-60,000円)
DynamoDB On-Demand	$1.25/100万WCU	$50-150 (7,500-22,500円)	$2,500-5,000 (375,000-750,000円)
DynamoDB Streams	含む（On-Demand 内）	$0 (0円)	$50-100 (7,500-15,000円)
EventBridge	$1.00/100万イベント	$2-5 (300-750円)	$80-150 (12,000-22,500円)
Kinesis Firehose	$0.029/GB 取り込み	$5-15 (750-2,250円)	$100-250 (15,000-37,500円)
S3 Data Lake	Standard + Infrequent Access	$10-30 (1,500-4,500円)	$300-800 (45,000-120,000円)
CloudWatch + X-Ray + SNS	メトリクス + ログ + トレース	$20-40 (3,000-6,000円)	$200-400 (30,000-60,000円)
合計		$163-423 (約24,450-63,450円)	$4,230-8,795 (約634,500-1,319,250円)

前提条件: Dev=10店舗試験、Prod=14,600店 × 売上イベント10件/分 × 24h = 約2.1億件/月。データレイク保存2TB/月、Hot データ 500GB。重処理 Fargate は平均 4 task・ピーク 20 task。

コスト最適化: DynamoDB On-Demand は定常運用後に Provisioned + Auto Scaling に切替で 40-60% 削減可能。Firehose のバッチ化（buffer size 128MB / interval 900s）で S3 PUT リクエスト料金削減。Lambda は ARM64 (Graviton2) で 20% 削減。年末年始凍結期間は Fargate 最小 task を 2→1 に絞ってコスト削減。

学習ポイント

非同期ミドルウェアを挟む原則 — リクエスト層と永続化層の間にキュー（SQS/Kinesis/SNS）を挟むと、書き込み側のスパイクと DB キャパのミスマッチを吸収できる。同期構成だとピーク時にクライアントまでエラーが波及するが、非同期構成ではクライアントに 202 Accepted を返しつつ内部で時間稼ぎができる。「急ぎじゃない書き込みは非同期」は大規模システムの基本原則。
責任分界と疎結合の設計（Pub/Sub 原則） — DynamoDB Streams + EventBridge によって、主パス（書き込み）と下流処理（データレイク・集計・通知）を完全に分離。新しい消費者を追加しても主パスに影響しない。これは Pub/Sub の教科書的なパターンで、案件を問わず適用できる。
Throughput を数値で試算する習慣 — 「14,600店×10件/分 = 2,433 TPS」を起点に、各 AWS サービスのデフォルトキャパ（API Gateway 10k RPS / SQS unlimited / DynamoDB On-Demand 40k WCU）と比較してボトルネック候補を洗い出す。設計前に数値試算するだけでサイジング議論が具体化する。
On-Demand と Provisioned の選択基準 — On-Demand は「予測困難な高バースト」に最適、Provisioned は「定常的に高スループット」に最適。コストは Provisioned のほうが 40-60% 安いが、スケール遅延を吸収できない。PoC/Pilot は On-Demand で開始、定常運用が見えた段階で Provisioned 移行、が定石。
DLQ + Alarm + 通知の最小観測セット — 分散システムで「メッセージが消えた」「詰まった」を検出する最小構成は DLQ + CloudWatch Alarm + SNS の3点セット。これをテンプレ化して全案件に適用する。コンビニのような 24/365 運用では夜間オンコール接続まで含めて観測基盤の一部。