Aurora のデータベースアクティビティストリームによる監査 中東の決済処理会社は、複数リージョンに展開した Amazon Aurora MySQL DB クラスターで加盟店の決済データを管理しています。監督官庁の規制により、データベースに対するすべてのアクティビティ (接続と認証、SELECT を含むクエリ、DML と DDL) をニアリアルタイムで収集し、改ざんできない形式で 7 年間保管したうえで、後から任意の期間を検索できるようにする必要があります。データベース管理者自身が監査ログを操作できない仕組みも求められています。この要件を満たすソリューションはどれですか。
A AWS Database Migration Service (AWS DMS) の変更データキャプチャ (CDC) タスクを設定し、Aurora DB クラスターをソース、Amazon Data Firehose をターゲットに指定します。Firehose でデータを暗号化して Amazon OpenSearch Service クラスターに配信し、AWS Lambda 関数で異常を検出して Amazon SNS で通知します。 B Aurora DB クラスターでデータベースアクティビティストリームを開始し、Amazon EventBridge でアクティビティイベントを受信します。EventBridge のターゲットとして AWS Lambda 関数を指定し、Lambda 関数でイベントを復号して Amazon S3 に暗号化して保存します。 C AWS Database Migration Service (AWS DMS) の変更データキャプチャ (CDC) タスクを設定し、Aurora DB クラスターをソース、Amazon Data Firehose をターゲットに指定します。Firehose でデータを暗号化して Amazon Redshift クラスターにロードし、定期的なクエリでデータベースアクティビティを分析します。 D Aurora DB クラスターでデータベースアクティビティストリームを開始します。アクティビティストリームは Amazon Kinesis Data Streams に配信されるため、Amazon Data Firehose でそのストリームを消費し、暗号化して Amazon S3 に配信します。S3 のデータは AWS Glue でカタログ化し、Amazon Athena でクエリします。
解説を読む（正解: 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 への定期クエリはニアリアルタイム性も失われます。
IoT テレメトリのリアルタイム取り込みと可視化基盤の選択 洋上風力発電を運営する事業者が、各風車に取り付けた振動・温度・回転数センサーからテレメトリを収集する基盤を AWS に構築します。データはセンサーの世代によって項目が異なる JSON で、1 件あたり数 KB と小さいものの、風車の台数増加に応じて流量が伸び続けます。要件は、(1) 異常の予兆を捉えるため取り込みからダッシュボード表示までの遅延を秒未満に抑えること、(2) リアルタイム異常検知と可視化という 2 つの独立した処理が同じデータを同時に読み取れること、(3) 障害調査のため直近 24 時間分のデータを何度でも再読み取り (リプレイ) できること、(4) 取り込んだデータを即座に全文検索・集計できることです。最も適した構成はどれですか。
A AWS IoT Core でテレメトリを受信し、IoT ルールから Amazon Data Firehose に配信して Amazon OpenSearch Service へ書き込む。可視化には OpenSearch Dashboards を使用する。 B AWS IoT Core でテレメトリを受信し、IoT ルールから Amazon Kinesis Data Streams に送信する。ストリームから Amazon OpenSearch Service へ取り込み、可視化には OpenSearch Dashboards を使用する。 C AWS IoT Greengrass でエッジ側の前処理を行い、Amazon MSK に送信する。Amazon EMR 上の Apache Flink で処理したうえで Amazon DocumentDB に保存し、可視化ツールから参照する。 D Amazon API Gateway でテレメトリを受信し、AWS Step Functions のワークフローで処理を制御する。処理結果を Amazon Neptune に格納し、グラフクエリで分析する。
解説を読む（正解: B） ストリーミング基盤を選ぶときは、配信サービス (デリバリーストリーム) と本来のストリームの違いを理解しておく必要があります。Amazon Data Firehose はバッファサイズまたはバッファ間隔の条件が満たされてから宛先へまとめて配信する仕組みで、OpenSearch 宛てのバッファ間隔は既定で 60 秒から設定します。またデータを保持しないためリプレイができず、同じデータを複数の独立したアプリケーションが個別のペースで読むこともできません。一方 Amazon Kinesis Data Streams はシャードにレコードを保持する真のストリームで、書き込み後ほぼ即座にコンシューマーが読み取れるため秒未満の遅延要件に適合します。保持期間内であれば任意のシーケンス番号から何度でも再読み取りでき、異常検知と OpenSearch への取り込みという 2 つのコンシューマーがそれぞれ独立したチェックポイントで同じストリームを読めます。取り込み先の OpenSearch Service は動的マッピングにより項目が変わる JSON を扱え、OpenSearch Dashboards で即座に検索・可視化できます。よって B が要件をすべて満たします。A は構成としては単純ですが、バッファリングによる遅延、リプレイ不可、コンシューマーのファンアウト不可という 3 つの要件違反があります。C は Greengrass と MSK、EMR 上の Flink を自前で運用する重厚な構成で運用負荷が高く、DocumentDB は時系列テレメトリの全文検索・可視化に最適とは言えません。D は API Gateway と Step Functions によるリクエスト単位のオーケストレーションで高スループットのストリーミングには不向きであり、Neptune は関係性を扱うグラフデータベースでセンサー時系列の分析用途に合致しません。
急増する IoT データ取り込みとデータベース書き込みのスケーリング ある農業テック企業は、全国の圃場に設置したスマートセンサーからのデータを AWS 上で処理しています。センサーは Application Load Balancer の背後にある Amazon EC2 上の API サーバーへデータを送信し、受け取ったデータは 4 TB の汎用 SSD (gp3) ボリュームを使う Amazon RDS for PostgreSQL DB インスタンスに書き込まれます。導入済みセンサーの台数はここ 1 年で数倍になり、来年度はさらに大幅に増える計画です。現在、API サーバーは常時過負荷の状態にあり、RDS のメトリクスでは書き込みレイテンシーの上昇が継続的に観測されています。費用対効果を保ちながら問題を恒久的に解消し、センサーの増設に合わせて拡張できるようにする方法はどれですか。2 つ選択してください。
A 汎用 SSD (gp3) ボリュームのサイズを 8 TB に拡張し、ボリュームの IOPS を引き上げる。 B データベース層を再設計し、Amazon RDS for PostgreSQL の代わりに Amazon Aurora PostgreSQL を採用してリードレプリカを追加する。 C Amazon Kinesis Data Streams と AWS Lambda を利用して、センサーから送信されたデータを取り込み、処理する。 D AWS X-Ray でアプリケーションのボトルネックを分析してデバッグし、負荷に見合う台数まで API サーバーを増設する。 E データベース層を再設計し、Amazon RDS for PostgreSQL の代わりに Amazon DynamoDB を採用する。
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: C、E） 大量のデバイスから絶え間なくデータが届く IoT の取り込み経路では、同期的にリクエストを受けてリレーショナルデータベースへ直接書き込む構成は、デバイス数の増加に対して線形にスケールできません。Amazon Kinesis Data Streams を前段に置くと、取り込みをシャード単位で水平に拡張でき、書き込みのバーストをストリームがバッファとして吸収するため、下流の処理がスパイクの影響を受けにくくなります。ストリームから AWS Lambda を起動すればサーバー管理なしでレコードをバッチ処理でき、常時過負荷の EC2 API サーバー群も不要になります。加えて、時系列的に追記され続けるセンサーデータはキーとタイムスタンプによる書き込みと検索が中心であり、Amazon DynamoDB のようにパーティション単位で自動的に分散するキーバリューストアの方が、単一ライターに制約されるリレーショナルエンジンより書き込みスループットを素直に拡張できます。したがって選択肢 C と E の組み合わせが恒久的な解決になります。選択肢 A は誤りで、ボリューム容量と IOPS を増やしても単一インスタンスの書き込み能力という上限は残り、センサー増設のたびに同じ問題が再発する対症療法にすぎません。選択肢 B も誤りです。Aurora のリードレプリカは読み取りをスケールしますが、書き込みは依然としてライターインスタンス 1 台に集約されるため、観測されている書き込みレイテンシーの根本原因を解消できません。選択肢 D は誤りで、X-Ray は可視化とデバッグには有用なものの、API サーバーを増やすだけではデータベース側の書き込み限界に対処できず、常時稼働インスタンスの増加によりコスト効率も悪化します。