IoT センサーデータ基盤のサーバーレス化
農業 IoT を推進する団体が、25,000 台以上の土壌水分センサーを圃場に設置しています。各センサーは継続的に更新データを送信しており、1 回の更新のサイズは 500 KB 未満です。現在はオンプレミスのアプリケーションサーバー群がこれらの更新を受信し、生データを人が読める形式に変換して、オンプレミスのリレーショナルデータベースサーバーに書き込んでいます。データアナリストは単純な SQL クエリでこのデータを参照しています。
団体はアプリケーション全体の可用性を高め、メンテナンス作業にかかる労力を削減したいと考えています。アプリケーションサーバーの更新やパッチ適用といったメンテナンスはダウンタイムの原因となっており、その間は残りのサーバーだけでは負荷を捌ききれずセンサーデータが失われています。
ソリューションアーキテクトはどの構成を推奨すべきですか。
解説を読む（正解: B）
Amazon Data Firehose (旧 Kinesis Data Firehose) は、ストリーミングデータを受け取ってバッファリングし、S3 などの宛先へ配信するフルマネージドなサービスです。取り込み量に応じて自動的にスケールし、配信の再試行やバックアップも組み込みで備えているため、サーバーの台数管理やパッチ適用が不要です。配信の途中で AWS Lambda を呼び出してレコードを変換でき、レコード形式変換によって Apache Parquet のような列指向形式で S3 に保存することもできます。Amazon Athena は S3 上のデータに対して標準 SQL を実行できるサーバーレスのクエリサービスで、Parquet 形式であればスキャン量が減り、クエリの速度とコストの両面で有利になります。
正解の構成では、受信から変換、保存、分析までがすべてマネージドサービスで構成されるため、パッチ適用によるダウンタイムもデータ損失も発生せず、アナリストは従来どおり単純な SQL で分析を継続できます。
他の選択肢は要件を十分に満たしません。A と C はデータの最終的な保存先を Aurora MySQL としています。Aurora はマネージドですが、2 万台を超えるセンサーからの継続的な書き込みを受け止めるにはインスタンスサイズやストレージの見積もりとスケーリングの管理が必要で、時系列データを行指向のリレーショナルデータベースに蓄積し続けるのはコスト面でも不利です。加えて C は S3 への保存後に改めてインポートする二重処理が発生します。D は保存形式と分析方法は適切ですが、単純な形式変換のために Managed Service for Apache Flink のアプリケーションを開発し、処理能力 (KPU) やアプリケーションのバージョンを管理し続ける必要があり、Firehose と Lambda の組み合わせに比べて運用の労力が大きくなります。Flink はウィンドウ集計やストリーム結合といった複雑なリアルタイム処理が必要な場合に選ぶべき選択肢です。
IoT センサーデータの低コストな S3 取り込みパイプライン
農業テック企業が、全国の圃場に設置した数千台の土壌センサーからのデータを収集する基盤を構築しています。デバイスは AWS IoT Core にデータを送信し、最終的には Amazon S3 上のデータレイクに蓄積します。S3 に格納する前に、各レコードへ圃場マスタと気象情報を突き合わせた属性を付与する必要があります。センサーは 10 秒間隔で送信し、収集から 45 分以内に S3 で参照できれば業務要件を満たします。AWS IoT Core に届いたデータを購読して処理している他のアプリケーションは存在しません。この要件を最もコスト効率よく満たすソリューションはどれですか。
解説を読む（正解: D）
AWS IoT Core の課金は、接続、メッセージング (パブリッシュ/サブスクライブ)、ルールエンジンの評価などに分かれています。ルールにしか流さず、他のサブスクライバーが存在しない場合は Basic Ingest を使うことで、パブリッシュ/サブスクライブのメッセージング料金を発生させずに直接ルールへデータを送れるため、取り込み段階のコストを大きく削減できます。さらに、10 秒間隔の小さなレコードを 1 件ずつ Lambda で処理して S3 に書くと、Lambda の呼び出し回数と S3 の PUT リクエスト数がそのままコストになり、大量の小さなオブジェクトも生成されます。正解の選択肢は、ルールアクションから Amazon Data Firehose へ流し、バッファリング間隔を 900 秒 (15 分) に設定してレコードをまとめ、Firehose のデータ変換機能で Lambda をバッチ単位で呼び出して拡充し、S3 へ配信します。バッファ時間を含めても 45 分の鮮度要件に十分収まり、呼び出し回数と PUT 回数を大幅に削減できます。1 件ごとに Lambda を起動して S3 に書く選択肢は、機能的には動作しますが呼び出し回数とリクエスト数が最大になりコスト効率で劣ります。Timestream を経由する選択肢は、S3 に格納するだけの用途に時系列データベースの書き込み・保存・クエリ費用が上乗せされ、実装も複雑になるため不適切です。Kinesis Data Streams を使う選択肢は、シャードの時間課金が常時発生し、コンシューマー Lambda が個別に PutObject を呼ぶため、Firehose のフルマネージドなバッファリングと比べてコストと運用負荷の両面で不利です。
Aurora のデータベースアクティビティストリームによる監査
中東の決済処理会社は、複数リージョンに展開した Amazon Aurora MySQL DB クラスターで加盟店の決済データを管理しています。監督官庁の規制により、データベースに対するすべてのアクティビティ (接続と認証、SELECT を含むクエリ、DML と DDL) をニアリアルタイムで収集し、改ざんできない形式で 7 年間保管したうえで、後から任意の期間を検索できるようにする必要があります。データベース管理者自身が監査ログを操作できない仕組みも求められています。この要件を満たすソリューションはどれですか。
解説を読む（正解: D）
Amazon Aurora のデータベースアクティビティストリームは、DB クラスターへの接続、認証、SQL 文の実行といったあらゆるアクティビティをニアリアルタイムで外部に送出する監査機能です。ストリームはデータベースエンジンの外側で生成され、AWS KMS のキーで暗号化されたまま Amazon Kinesis Data Streams に配信されるため、データベース管理者が内容を改ざんしたり停止したりできない点が、規制対応で重視されます。正解の構成では、この Kinesis データストリームを Amazon Data Firehose (旧 Kinesis Data Firehose) で消費し、暗号化したうえで Amazon S3 に継続的に配信します。S3 に集約すればライフサイクルポリシーと Object Lock により 7 年間の長期保管と改ざん防止を安価に実現でき、AWS Glue のカタログと Amazon Athena で任意の期間を SQL で検索できます。EventBridge を使う選択肢は、データベースアクティビティストリームの配信先が Kinesis Data Streams であり EventBridge へ直接送出されないため、構成として成立しません。AWS DMS の CDC を使う 2 つの選択肢は、CDC がトランザクションログから読み取れるデータ変更 (INSERT/UPDATE/DELETE) しか捕捉できず、SELECT や接続・認証といったアクティビティを記録できないため、すべてのデータアクティビティを監査するという要件を満たしません。加えて OpenSearch Service や Redshift へロードする構成は、7 年間の低コストな長期保管という要件に対して費用対効果が悪く、Redshift への定期クエリはニアリアルタイム性も失われます。