IoTデバイスから毎秒数万件のテレメトリを受信し、デバイスごとの時系列順序を保ったまま、リアルタイムの異常検知と分析基盤への蓄積という2つの処理を並行して行いたいです。片方の処理に不具合があった場合は、直近24時間分のデータを読み直して再処理できる必要があります。最も適したサービスはどれですか？

解説

Kinesis Data Streamsはパーティションキー単位（シャード内）で順序を保証し、レコードを保持期間（既定24時間、最大365日）の間ストリーム上に残します。複数のコンシューマーが同じレコードを独立した位置から読めるため、並行処理と再処理の両方の要件を満たします。

選択肢ごとの解説

実務での使いどころ

Amazon Kinesis Data Streams は、大量のレコードをリアルタイムに取り込み、一定期間ストリーム上に保持する分散ストリーミングサービスである。ストリームはシャードという単位に分かれ、プロデューサーが指定するパーティションキーのハッシュでレコードの配置先シャードが決まる。同じパーティションキーのレコードは必ず同じシャードへ入り、シャード内では投入順に読み出されるため、「デバイスごと」「ユーザーごと」といった単位での順序保証が実現できる。キャパシティモードにはプロビジョンド（シャード数を自分で管理）とオンデマンド（トラフィックに応じて自動調整）がある。 キューとの決定的な違いは、レコードが「消費されても消えない」点にある。コンシューマーは自分の読み取り位置（イテレーター）を持ち、保持期間（既定 24 時間、最大 365 日）の間はいつでも過去のレコードを読み直せる。この性質により、複数のコンシューマーアプリケーションが同じストリームを互いに干渉せず独立して読めるファンアウト構成が自然に組める（拡張ファンアウトを使えばコンシューマーごとに専有スループットも確保できる）。一方 SQS はメッセージを 1 つのコンシューマーが処理して削除するワークキューであり、削除後の読み直しはできず、標準キューでは順序も保証されない。SNS はプッシュ型のファンアウトができるが、標準トピックには保持と再読み取りの仕組みがない。単純に S3 や Redshift、OpenSearch へ流し込むだけなら、シャード管理が不要な Amazon Data Firehose のほうが適する場合もある。 SAA-C03 では「順序を保ちたい」「複数の処理へ同じデータを流したい」「一定期間さかのぼって再処理したい」「毎秒数万件のストリーミング」というキーワードが揃ったら Kinesis Data Streams が正解になる。逆に「重複を避けつつ 1 回だけ処理したい」「厳密な順序が必要なジョブキュー」であれば SQS FIFO、「疎結合なタスク分散」なら SQS 標準キューという読み分けになる。