DEA-#16

AWS Lake Formation は、データレイク内のデータに対するきめ細かなアクセスコントロール機能を提供します。その中の一つである 行レベルセキュリティ (行レベルフィルター) を使用すると、ユーザーやロールごとに、クエリ結果に含める行を動的にフィルタリングできます。この問題では、「国がカナダのお客様」という特定の条件に合致する行へのアクセスを制限する必要があります。行レベルフィルターを使えば、country = 'Canada' のような条件式を設定し、この条件に一致する行をクエリ結果から除外する、といった制御が可能です。これにより、基盤となるデータを変更することなく、セキュリティ要件を満たすことができ、 運用上の労力を最小限に抑える という要件にも合致します。

AWS Glue には、ETL プロセスを強化するための機械学習 (ML) 変換機能が組み込まれています。その中の一つである FindMatches 変換 は、問題文の要件である「 共通の一意の識別子を持っていない場合でも、一致するレコードを識別する 」という、いわゆる「名寄せ」や「レコードリンケージ」のタスクを解決するために特化した機能です。
この変換は、まず人間が手動で一部のレコードをマッチングさせたサンプルデータ (ラベリングデータ) を基にモデルをトレーニングします。トレーニングが完了すると、そのモデルを使用してデータセット全体から重複しているレコードや、異なるデータソース間で同じ実体を指すレコードを自動的に識別・グルーピングできます。これにより、手作業では困難な大規模データセットのクレンジングと統合を効率的に行うことが可能です。

AWS CloudTrail は、AWS アカウント内での API 呼び出しを記録し、監査やコンプライアンス対応に利用されるサービスです。CloudTrail には主に「管理イベント」と「データイベント」の 2 種類のイベントがあります。

・管理イベント: リソースの設定変更など、コントロールプレーンオペレーションを記録します (例 : S3 バケットの作成・削除) 。
・データイベント: リソース内でのデータ操作 (データプレーンオペレーション) を記録します (例 : S3 オブジェクトの取得・アップロード・削除) 。

問題の要件である「S3 バケット内のオブジェクト操作 (PUT, POST, DELETE など)」は、まさに データイベント の対象です。CloudTrail の証跡 (Trail) を作成し、データイベントを有効にして対象の S3 バケットを指定するだけで、 自動的に API 呼び出しが記録され、指定した別の S3 バケットにログファイルが保存 されます。この方法は、カスタムコードの開発や他のサービスとの複雑な連携が不要なため、 最も運用労力が少なく 、要件に完全に合致しています。

AWS Glue Studio は、ETL(抽出、変換、ロード) ジョブを視覚的に構築できるサービスです。その中に、Detect PII という強力な組み込み変換機能があります。この機能は、名前、住所、クレジットカード番号といった一般的な個人を特定できる情報 (PII) のパターンを 自動で識別 し、マスキングや置換といった難読化処理を行うことができます。
これにより、開発者は PII を検出・処理するための複雑なロジックを自前でコーディングする必要がなくなり、問題の要件である「 最も少ない運用工数 」を達成できます。作成した ETL ジョブを AWS Step Functions でオーケストレーションするのは、データパイプラインを管理する上で一般的かつ堅牢な構成です。

AWS Glue は、サーバーレスで ETL 処理を実行できるサービスであり、主に「Apache Spark ジョブ」と「Python シェルジョブ」の 2 種類のジョブタイプを提供しています。問題の要件では、処理対象のファイルサイズが 100MB 未満 と、単一のマシンで十分に処理できる小規模なデータです。このような場合、大規模なデータセットを並列処理するために設計された Apache Spark 環境は 過剰なスペック となります。

AWS Glue Python シェルジョブ は、Spark 環境を起動せず、シンプルな Python 環境でスクリプトを実行します。これにより、Spark ジョブに比べて以下のメリットがあります。

• コスト効率 : Spark ジョブは最低でも 2DPU(Data Processing Unit) から起動しますが、Python シェルジョブは最小 0.0625 DPU という、より小さなリソースで実行できます。これにより、 処理コストを大幅に削減 できます。
• 起動時間 : Spark クラスターの初期化が不要なため、 ジョブの起動が高速 です。

Pandas は Python でデータ分析や操作を行うための強力なライブラリであり、100MB 程度の CSV ファイルの変換処理には最適です。したがって、「最もコスト効率よく」という要件を満たすには、この選択肢が最も適切なソリューションとなります。

AWS Glue ジョブのブックマーク機能 は、ETL ジョブがどのファイルを処理したかを追跡し、次回の実行時に同じファイルを再処理しないようにするための仕組みです。しかし、Amazon Redshift のような JDBC 接続先データベースにデータを書き込む場合、AWS Glue はトランザクションの完了をもって「処理が成功した」と判断し、ブックマークを更新します。

スクリプト内でデータを書き込んだだけではトランザクションは完了せず、最後に 明示的に commit ステートメント (例 : connection.commit () ) を呼び出す 必要があります。この commit がないと、データが書き込まれたように見えてもトランザクションが完了していないため、AWS Glue はジョブが正常に完了したと見なせず、 ブックマークの状態を更新しません 。その結果、次回のジョブ実行時に、前回と同じ S3 ファイルが再び処理対象となってしまいます。

Amazon Data Firehose は、ストリーミングデータを Amazon S3 などの送信先に、ほぼリアルタイムで簡単に配信できるフルマネージドサービスです。このサービスには、データをまとめてから送信先に書き込むためのバッファリング機能があります。バッファリングは「バッファサイズ」と「 バッファ間隔 」の 2 つの条件で制御され、どちらかの条件が先に満たされた時点でデータが配信されます。

問題の要件は「 最も少ないレイテンシー 」でのデータ配信です。これを実現するには、バッファ間隔を可能な限り短く設定するのが基本方針になります。Amazon Data Firehose は S3 宛てでもバッファ間隔を短い秒単位（0〜900 秒の範囲）で指定でき、追加の処理がない構成では数秒程度で配信されるケースもあります。

この選択肢では、バッファ間隔を 5 秒 に設定しており、S3 に到達するまでの遅延を最小化できます。さらに、S3 への書き込み、スケーリング、失敗時の再試行、スループット変動への追従などをマネージドで吸収できるため、同程度の秒単位レイテンシーを狙う場合でも、カスタム実装に比べて安定して低遅延を維持しやすい構成です。

なお、Amazon Managed Service for Apache Flink は、ストリームデータの高度な分析や変換（集計・ウィンドウ処理など）を行うためのフルマネージドサービスです。必須要件が「低レイテンシー配信のみ」の場合は Firehose 単体でも成立しますが、選択肢 D のように Flink を組み合わせれば、S3 に保存する前にストリーム処理を挟む余地も残しつつ、配信自体は Firehose の低レイテンシー設定で最短化できます。