ニアリアルタイムなログ収集・変換・分析基盤の選択
全国のスキー場に設置した約80台の気象観測ゲートウェイが、積雪量と風速のログを絶え間なく送信しています。運用チームは、流れ込むログを継続的に受け取り、おおむね60秒間隔でまとめてオブジェクトストレージに書き出したいと考えています。書き出す前にタイムスタンプの正規化と観測地点マスタの付与という変換処理を挟む必要があり、蓄積されたファイルに対しては後からアドホックな SQL 集計を実行したいという要望もあります。ゲートウェイは今後300台規模まで増える見込みで、サーバーの管理はできる限り避けたいという方針です。
この要件を満たす最も適切な構成はどれですか。
解説を読む（正解: C）
Amazon Data Firehose (旧称 Amazon Kinesis Data Firehose) は、ストリーミングデータを受け取ってバッファリングし、Amazon S3 などの宛先へ自動的に配信するフルマネージドサービスです。配信ストリームにはバッファサイズとバッファ間隔を設定でき、間隔は最短60秒まで短縮できるため「約1分ごとにまとめて書き出したい」という要件にそのまま合致します。さらに Firehose にはレコード変換機能があり、指定した Lambda 関数を Firehose 側が自動的に呼び出して整形やマスタ情報の付与を行えるほか、JSON から Parquet への形式変換もサポートします。S3 に置かれたファイルは Amazon Athena がサーバーレスで直接 SQL クエリできるため、インスタンスを一切運用せずに収集から分析までを完結でき、ゲートウェイが300台に増えても Firehose 側が自動的にスケールします。したがって選択肢 C が最適です。選択肢 A はスケジュール起動のポーリング型であり、継続的に流れてくるログをニアリアルタイムに取り込めず、台数の増加に応じて取得ロジックとエラー処理の運用負荷が跳ね上がります。選択肢 D は Kinesis Data Streams 自体は妥当ですが、コンシューマーを EC2 で自作・運用する手間がかかり方針に反するうえ、Athena は DynamoDB テーブルを標準では直接クエリできません (別途フェデレーテッドクエリ用コネクタの構築が必要です)。選択肢 B は Amazon EBS が単一インスタンスにアタッチするブロックストレージであり、Athena がその上のファイルをクエリすることはできないため、分析基盤の保存先として成立しません。
ストリーミングデータの変換と S3 への配信
スマート農業サービスを運営する企業が、圃場に設置した数万台のセンサーから毎秒数万件の JSON レコードを受信しています。これらのデータは後日の分析のために列指向の Apache Parquet 形式へ変換したうえで、Amazon S3 のデータレイクへ蓄積する必要があります。変換はリアルタイムである必要はなく、数分程度の遅延は許容されます。運用管理の手間を最小限にしたい場合、最も適した方法を 1 つ選択してください。
解説を読む（正解: D）
Amazon Data Firehose (旧 Amazon Kinesis Data Firehose) は、ストリーミングデータを Amazon S3 や Amazon Redshift、OpenSearch Service などの宛先へ自動配信するフルマネージドサービスです。バッファサイズやバッファ間隔を指定するだけでニアリアルタイム (数十秒から数分) に配信され、AWS Glue データカタログのスキーマを参照した Parquet や ORC への形式変換、Lambda によるレコード変換、圧縮や暗号化も組み込み機能として利用できます。数分の遅延が許容され、変換したうえで S3 に蓄積したいという今回の要件にはこれが最適で、シャード管理やコンシューマーアプリの実装も不要なので運用負荷が最小になります (D)。B の Kinesis Data Streams は取り込みと保持を行うストリームですが、S3 への自動保存機能は持たず、コンシューマーを自分で実装する必要があるため誤りです。C の Kinesis Video Streams は映像や音声などの時系列メディア向けのサービスで、JSON レコードの形式変換用途には合いません。A の Managed Service for Apache Flink はストリーム処理エンジンで、リアルタイム集計には強力ですが、要件はリアルタイム処理ではなく S3 への蓄積であり、ダッシュボード表示だけではデータレイクに保存されません。
ストリーミング取り込みと Parquet 変換の構成
全国配送網を持つ物流企業が、配送トラック 8,000 台の車載端末から 1 分間隔で位置情報と冷蔵コンテナの温度データを送信しています。データは数分程度の遅延であれば許容されるため、ニアリアルタイムで Amazon S3 のデータレイクに蓄積し、翌日以降に Amazon Athena で分析したい。スキャン量に応じた分析コストを抑えるため、取り込み時に JSON から Apache Parquet 形式へ変換する必要があります。運用管理の負荷を最小限に抑えつつこの要件を満たす構成はどれか。
解説を読む（正解: A）
ストリーミングデータを S3 のデータレイクへ継続的に取り込む場合、送信されてくる小さなレコードをバッファリングしてまとまったファイルにまとめ、分析に適した列指向フォーマットへ変換する処理が必要になります。この一連の処理をマネージドで提供するのが Amazon Data Firehose です。A が正解で、Firehose は配信ストリームにデータを送るだけでバッファサイズやバッファ間隔に応じて自動的にレコードをまとめ、AWS Glue Data Catalog に登録されたテーブルスキーマを参照するレコード形式変換機能によって JSON を Apache Parquet や ORC へ変換したうえで S3 に配信します。シャード管理もサーバー管理も不要で、数分の遅延を許容するニアリアルタイム要件と運用負荷最小化の両方に合致します。B は実現自体は可能ですが、コンシューマーアプリケーションのデプロイ、シャード数の調整、チェックポイント管理、障害時の再処理を自前で運用する必要があり、要件である運用負荷の最小化に反します。C はバッチ処理であるためニアリアルタイム性が失われるうえ、端末が直接 PUT した膨大な小さいオブジェクトが S3 に残り、EMR クラスターのライフサイクル管理という追加運用も発生します。D の SQS と Lambda の組み合わせでは、Parquet は複数レコードをまとめた列指向ファイルであるため 1 メッセージごとに書き出すと極端に小さいファイルが大量発生して Athena の性能が劣化し、バッファリングと集約のロジックをすべて自作する必要があります。