ニアリアルタイムなログ収集・変換・分析基盤の選択
全国のスキー場に設置した約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 ストレージクラスとサーバーレス SQL 分析のコスト最適化
オンライン学習サービスを運営する企業が、受講者から提出される演習ログを AWS 上に蓄積する仕組みを新たに構築しています。ログは CSV 形式で Amazon S3 に配置され、分析チームが標準 SQL で集計してレポートを作成します。集計対象になるのは提出から 7 日以内のログで、この期間は問い合わせに対して即座に読み出せる必要があります。7 日を過ぎたログは監査目的で保管するだけで、参照されることはほとんどありません。運用負荷とコストを最小限に抑えられる構成を 1 つ選択してください。
解説を読む（正解: B）
Amazon S3 はアクセス頻度に応じた複数のストレージクラスを持ち、S3 ライフサイクルルールによってオブジェクトを自動的に安価な階層へ移行できます。また Amazon Athena は S3 上のファイルに対して標準 SQL を直接実行できるサーバーレスのクエリサービスで、スキャンしたデータ量に対してのみ課金され、クラスターの構築や管理は不要です。本シナリオは「7 日間は即時読み出しが必要」「その後はほとんど参照されない」という典型的なライフサイクル要件であるため、まず S3 Standard に置いて即時アクセス性を確保し、7 日経過後に S3 Glacier Flexible Retrieval へ移行するルールを設定する B が、要件を満たしながら長期保管コストを最小化します。集計を Athena で行うことで常時稼働の分析基盤が不要になり、運用負荷も抑えられます。A は最初から Deep Archive に置くため、7 日以内の即時読み出し要件を満たせません。Deep Archive は復元に数時間を要するアーカイブ専用クラスだからです。C の Amazon Kinesis Data Streams はリアルタイムのストリーム取り込みと保持を担うサービスであり、S3 に蓄積済みのデータへ標準 SQL を実行する用途には適合しません。D は EBS が単一インスタンスからのブロックアクセスを前提とするストレージであるうえ、Redshift クラスターを常時稼働させるため費用も運用負荷も最大になり、コスト最適とは言えません。
S3 上のデータをそのまま分析するクエリサービスの選択
農業機械メーカーが、圃場に設置したセンサーから届くテレメトリを AWS Lambda で加工し、結果を JSON 形式で Amazon S3 バケットへ書き出すリアルタイム分析基盤を運用しています。データサイエンスチームは、この蓄積データに対して集計や結合を含む大規模な分析を行いたいと考えていますが、分析のたびに別のデータストアへロードする ETL 処理と、それに伴う二重のストレージコストは避けたいという方針です。データを移動させずに S3 上でそのまま高度な分析を実行できるサービスを選定してください。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、D）
Amazon S3 に蓄積したデータをその場で分析できる「クエリ・イン・プレース」型のサービスを使うと、分析のたびにデータウェアハウスへロードする ETL 工程と、その分の二重のストレージコストを省くことができます。Amazon Athena は Presto / Trino をベースとしたサーバーレスのクエリサービスで、S3 上の JSON、CSV、Parquet などに標準 SQL を直接実行でき、クラスターの起動やインフラ管理は不要です。Amazon Redshift Spectrum は既存の Amazon Redshift クラスターから S3 上のファイルを外部テーブルとして参照し、クラスター内のテーブルと結合したうえで大規模な集計を実行できます。
本シナリオの要件は「データを他の分析アプリケーションへ移動することなく高度なビッグデータ分析を実施する」ことなので、いずれもデータを動かさずに SQL で分析できる A の Amazon Athena と D の Amazon Redshift Spectrum が適合します。
B の Amazon ElastiCache は Redis / Memcached 互換のインメモリキャッシュで、参照の高速化には有効ですが分析クエリエンジンではなく、S3 上のファイルを直接クエリすることもできません。C の S3 Select は単一オブジェクトの中から条件に合う行や列を抜き出す軽量な機能で、複数オブジェクトを横断した結合や大規模集計はできず、高度なビッグデータ分析という要件には力不足です。E の Amazon DynamoDB は低レイテンシーのキーバリューストアであり、利用するにはまず S3 のデータを取り込む必要があるうえ、アドホックな分析 SQL の実行にも向いていません。