DEA-#16

AWS Lake Formation は、データレイク内のデータに対してテーブル / 列 / 行レベルのきめ細かなアクセスコントロールを提供します。要件は「国がカナダのお客様」に該当する 特定の行 をユーザーに見せないことです。Lake Formation の 行レベルセキュリティ (行レベルフィルター) は、データフィルターとして「行フィルター述語 (Row filter expression)」を定義し、ユーザーやロール (プリンシパル) ごとにクエリ結果へ反映させます。

たとえば country = 'Canada' の行を除外したい場合、country <>'Canada' のような述語をデータフィルターに設定することで、基盤となる S3 上のデータ自体を変更せずに、参照結果から該当行だけを確実に取り除けます。これにより、データの複製や別テーブル運用などを追加せずに実現でき、 運用上の労力を最小限に抑える という要件にも合致します。

AWS Glue には、データクレンジングや統合を支援する機械学習 (ML) 変換が用意されており、その代表が FindMatches 変換 です。問題文の要件「 共通の一意の識別子を持っていない場合でも、一致するレコードを識別する 」は、氏名・住所・メールアドレスなどが「完全一致しない」複数データソース間で同一人物 (同一実体) を特定する、いわゆる「名寄せ (Entity Resolution / Record Linkage)」に該当します。

FindMatches は、この名寄せを行うために、まず人間が「同じ」「違う」を判断したサンプル (ラベリングデータ) を使用してモデルをトレーニングします。学習済みモデルを ETL ジョブ内で適用すると、データセット内の重複レコードや、異なるデータセット間で同じエンティティを指すレコードを自動的にスコアリング・グルーピングし、マッチしたレコードに同一グループ (マッチ ID) として印を付けられます。これにより、後続処理で「同一人物ごとの集約」「重複排除」「統合されたマスタデータの作成」などを効率よく実装できます。

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 の判定ロジックや難読化処理を自前で実装・保守する必要がなくなり、要件である「 最も少ない運用工数 」を満たします。さらに、AWS Step Functions は、Glue ジョブの実行順序制御、リトライ、エラー分岐などをマネージドに実装できるため、データパイプラインを堅牢にオーケストレーションできます。

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

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

• コスト効率 : Spark ジョブはワーカーを用いた分散実行が前提となり、最小構成でも複数 DPU 相当 (例 : 1 DPU 相当のワーカーを複数台) で実行されます。一方で Python シェルジョブは 0.0625 DPU または 1 DPU を割り当て可能で、最小 0.0625 DPU(デフォルト) という、より小さなリソースで実行できます。これにより、 小規模データの処理コストを大幅に削減 できます。
• 起動時間 : 分散実行基盤 (ワーカー群) の初期化が不要なため、 ジョブの立ち上がりが軽く短時間バッチに向く という利点があります。

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

AWS Glue ジョブのブックマーク機能 は、ETL ジョブがどの入力 (S3 オブジェクトなど) を処理したかの状態を保持し、次回以降の実行で同じ入力を重複処理しないための仕組みです。ブックマークはジョブ単位で管理され、スクリプトが job.init () で最新の状態を取得し、各ソース / 変換 / シンクは transformation_ctx によって状態要素として紐づけられます。

重要なのは、 これらの状態要素はジョブの処理が終わっただけでは保存されず、スクリプトの末尾で job.commit () が呼び出された時点でアトミックに保存される という点です。したがって、Amazon Redshift への書き込み自体が成功していても、job.commit () がないと AWS Glue は「今回どの S3 ファイルを処理済みとして確定したか」を記録できず、 ブックマークが更新されないため次回実行時に同じ S3 ファイルを再び処理対象として扱ってしまいます 。

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

問題の要件は「 最も少ないレイテンシー 」でのデータ配信です。これを実現するには、バッファ間隔を可能な限り短く設定するのが基本方針になります。Amazon Data Firehose は S3 宛てでもバッファ間隔を短い秒単位 (0 〜 900 秒の範囲) で指定でき、バッファ間隔を 0 秒に近づけるほど数秒以内の配信を狙えます。

ただし、これらは「バッファリングのヒント」であり、Firehose は内部最適化や送信先の状況に応じて、指定値どおりに厳密には動作しない (前倒し / 遅延 / 分割などが起こり得る) 点に注意が必要です。それでも、要件が「最小レイテンシー」である限り、バッファ間隔を短くすることが最短化の最重要ポイントになります。

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

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