ある企業が、大量の IoT デバイスからセンサーデータ(1 秒間に最大 100 万件のメッセージ)をリアルタイムで受信・処理・保存するシステムを構築したい。データの受信と処理を分離し、スパイク時でもデータを取りこぼさずに処理したい。最も適切なアーキテクチャはどれか。
- A. Amazon API Gateway のエンドポイントで各デバイスからのメッセージを受信し、Lambda で直接処理して RDS に保存する。
- B. Amazon Kinesis Data Streams でデータを受信(シャード数を必要量にスケール)し、AWS Lambda または KCL アプリケーションでリアルタイム処理する。処理済みデータは Amazon S3 または DynamoDB に保存する。
- C. Amazon SQS 標準キューでメッセージを受信し、Auto Scaling グループの EC2 インスタンスで処理する。
- D. AWS IoT Core で全デバイスを管理し、メッセージブローカーでルーティングした後に Amazon SQS FIFO キューで順序保証して処理する。
解答と解説を見る
正解: B
Kinesis Data Streams は毎秒数百万レコードの大量ストリームデータを処理できる高スループットのサービスである。シャードを増やすことで受信スループットをスケールでき(1シャード = 1MB/s受信・1,000レコード/s)、最大 7 日間のデータ保持により受信と処理の非同期化も実現できる。Lambda または KCL でリアルタイム処理も可能。選択肢CのSQS は高スループットだが、1 秒 100 万件のような超高頻度では Kinesis の方が専用設計で適している。また SQS はメッセージ順序保証が FIFO のみでパーティション分割機能がない。選択肢AのAPI Gateway + Lambda はリクエスト数に応じたコストが非常に高くなり(100 万件/秒では 1 秒で 100 万 Lambda 起動)、現実的ではない。選択肢DのSQS FIFO はスループット上限(300 TPS、バッチで 3,000 TPS)が 100 万件/秒には大きく不足し、要件を満たせない。
📚 関連サービスの解説: Amazon Kinesis ・ AWS Lambda