あなたの選択した答えは強調表示されています。
問題1 |
ある企業は、RA3 ノードで稼働する Amazon Redshift クラスターを使用しています。同社は、需要に合わせて読み取りと書き込みのキャパシティを拡張したいと考えています。データエンジニアは、同時実行スケーリングを有効にするソリューションを特定する必要があります。
この要件を満たすソリューションを選択してください。
Redshift Serverless ワークグループのワークロード管理 (WLM) で同時実行スケーリングを有効にします。 | |
Redshift クラスターのワークロード管理 (WLM) のキューレベルで同時実行スケーリングを有効にします。 | |
新しい Redshift クラスターを作成する際の設定で、同時実行スケーリングを有効にします。 | |
Redshift クラスターの 1 日あたりの使用量クォータの同時実行スケーリングを有効にします。 |
問題 1 の説明および補足
Redshift 同時実行スケーリングの有効化方法
正解BRedshift クラスターのワークロード管理 (WLM) のキューレベルで同時実行スケーリングを有効にします。
💡解説のポイント
Amazon Redshift の同時実行スケーリングは、 ワークロード管理 (WLM) のキュー単位で有効化する 機能であるため正解です。
Amazon Redshift の 同時実行スケーリング は、同時実行クエリが急増してキュー待ちが発生する状況で、クエリ処理能力を自動的かつ透過的に拡張する機能です。有効化はクラスター全体の一括スイッチではなく、 ワークロード管理 (WLM) の設定にある各 キュー ごとに行います。具体的には、WLM 設定の対象キューで「同時実行スケーリングモード」を
auto (またはオン) に設定します。これにより、そのキューに投入されたクエリの同時実行数が増えてメインクラスター側で待ち行列が伸びた場合、Redshift は追加の一時的なリソース (同時実行スケーリング用の処理リソース) を起動して、キュー待ちを吸収します。問題文の RA3 ノード はストレージとコンピュートが分離されたアーキテクチャのため、短時間の需要増に対して処理能力を拡張しやすく、BI/ 分析クエリやバッチ処理が重なるタイミングでも「待ち」を抑えやすくなります (※同時実行スケーリングは“何でも書き込みスループットを増やす”機能ではなく、主にキュー待ちを減らして全体の並列処理を押し上げる目的で使います) 。そのため、本問の「需要に合わせた読み込み / 書き込みを含むワークロードの処理能力拡張」という意図に対して、WLM のキュー単位で同時実行スケーリングを有効化する選択肢が最も適切です。
00:00
AWS 公式ドキュメント要約
※同時実行スケーリングの使用 - Amazon Redshift
同時実行スケーリングを管理するには、ワークロード管理 (WLM) を設定します。キューを定義することで、さまざまなタイプのクエリを管理できます。例えば、実行時間の短いクエリと実行時間の長いクエリに異なるキューを定義できます。WLM キューの同時実行スケーリングモードをオンまたは自動に設定することで、同時実行スケーリングを有効にできます。
以下は間違いです
不正解ARedshift Serverless ワークグループのワークロード管理 (WLM) で同時実行スケーリングを有効にします。
→「Redshift Serverless」は、問題文の「RA3 ノードで稼働する Amazon Redshift クラスター 」 (プロビジョニング型) という前提と異なるため間違いです。
Amazon Redshift には、ノードを指定して構成する「プロビジョニング型」と、ワークグループ / 名前空間で利用し処理能力を自動調整する「サーバーレス型 (Redshift Serverless)」があります。問題文は RA3 ノード と明記しており、これはプロビジョニング型クラスターを前提としています。Redshift Serverless はそもそも“同時実行スケーリング (Concurrency Scaling) をキューでオンにする”という設定モデルではなく、サーバーレスの Auto Scaling 機構で処理能力を調整します。したがって、本問の「RA3 クラスターで同時実行スケーリングを有効にする」という要件に適合しません。
問題文に「RA3 ノード」や「DC2 ノード」といった具体的なノードタイプが記載されている場合、それは「プロビジョニング型クラスター」を指していると判断する癖をつけましょう。サーバーレスの場合は「Redshift Serverless」やワークグループ / 名前空間が前提として示されます。
不正解C新しい Redshift クラスターを作成する際の設定で、同時実行スケーリングを有効にします。
→「同時実行スケーリング」は、 “クラスター作成時に有効 / 無効を切り替えるトップレベルの単独設定”ではなく 、WLM のキュー設定として定義するため間違いです。
同時実行スケーリングは、WLM のキュー単位 で「同時実行スケーリングモード (オン / 自動)」を設定して初めて有効化されます。コンソールの操作としては、クラスター作成後に WLM を編集して有効化するのが一般的です (作成時に WLM 設定を投入できる場合があっても、それは“作成時に WLM キューを定義しているだけ”であり、機能の有効化ポイントはあくまでキュー設定です) 。選択肢 C は「クラスター作成時の設定で同時実行スケーリングを有効にする」としており、設定単位・設定場所の理解を誤らせる内容のため不正解です。
Redshift は「クラスター (プロビジョニング)」「WLM(キュー / スロット管理)」「同時実行スケーリング (キューに対する拡張)」が階層的に紐づきます。どの機能が“どの階層 (単位) ”で設定されるかを整理すると、ひっかけに強くなります。
不正解DRedshift クラスターの 1 日あたりの使用量クォータの同時実行スケーリングを有効にします。
→「同時実行スケーリング」を有効化する場所は「使用量クォータ」ではなく、WLM のキュー設定 であるため間違いです。
同時実行スケーリングにはコスト管理の観点があり、使用量 (消費) を制御するための上限設定 (使用量制限 / クォータに相当する考え方) を設けられる場合があります。しかし、これは“使い過ぎを防ぐための制御”であり、 機能そのものを有効化する設定場所ではありません 。有効化はあくまで WLM のキュー設定 で「同時実行スケーリングモード」をオン / 自動にすることで行います。よって選択肢 D は、コスト制御の概念と有効化手順を混同させる引っかけで不正解です。
機能の「有効化 (ON にする場所)」と「コスト / 使用量の制御 (上限・制限)」は別物です。Redshift に限らず、試験ではこの混同を狙った選択肢が頻出します。
この問題の本質
この問題の本質は、Amazon Redshift (プロビジョニング型クラスター) における同時実行スケーリング機能が、ワークロード管理 (WLM) の「キュー単位」で有効化されるという設定単位と手順を正確に理解しているかどうかにあります。
問題2 |
データエンジニアは、Amazon S3 バケットにある Apache Parquet 形式のオブジェクトからデータを読み取る 1 回限りのタスクがあります。データエンジニアは、データの 1 つの列のみをクエリする必要があります。
運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。
AWS Lambda 関数を構成して、S3 バケットから pandas データフレームにデータをロードします。必要な列をクエリするために、データフレームに SQL SELECT ステートメントを記述します。 | |
S3 Select を使用して SQL SELECT ステートメントを作成し、S3 オブジェクトから必要な列を取得します。 | |
S3 オブジェクトを使用し、必要な列をクエリするために AWS Glue DataBrew プロジェクトを準備します。 | |
S3 オブジェクトで AWS Glue クローラーを実行します。Amazon Athena で SQL SELECT ステートメントを使用して、必要な列をクエリします。 |
問題 2 の説明および補足
S3 Select によるサーバー側でのデータフィルタリング
正解BS3 Select を使用して SQL SELECT ステートメントを作成し、S3 オブジェクトから必要な列を取得します。
💡解説のポイント
S3 Select は、S3 オブジェクト内のデータをサーバー側で直接フィルタリングし、 必要な列のみを抽出できる ため正解です。
S3 Select は、Amazon S3 に保存されているオブジェクトに対して、 サーバー側で直接 SQL ライクなクエリを実行できる機能 です。この機能を利用することで、アプリケーションはオブジェクト全体をダウンロードすることなく、必要なデータ (この問題では特定の 1 列) のみを効率的に取得できます。問題の要件である「1 回限りのタスク 」と「 運用上のオーバーヘッドを最小限に 」に対して、S3 Select は以下の点で最適です。
- インフラ不要 : 追加のサービス (Lambda, AWS Glue DataBrew, Athena など) をセットアップする必要がなく、S3 の API を呼び出すだけで利用できます。
- 効率的なデータ取得 : 必要な列のみを抽出するため、 データ転送量が大幅に削減 され、クエリのパフォーマンスが向上し、コストも削減できます。
- サポート形式 : Apache Parquet 形式をサポート しているため、問題の要件に合致します。
- 単一オブジェクト向け : 1 つのオブジェクトから必要な項目だけを取り出す用途に最適です (複数オブジェクト横断の集計・結合などは対象外) 。
00:00
AWS 公式ドキュメント要約
※Amazon S3 Select と S3 Glacier Select を使用したデータからのフィルタリングと取得
Amazon S3 Select を使用すると、アプリケーションはオブジェクトコンテンツ全体を取得して処理する代わりに、オブジェクトコンテンツのサブセットのみを取得できます。オブジェクトコンテンツのサブセットのみを取得すると、パフォーマンスが大幅に向上します。多くの場合、このパフォーマンス向上は 400% にもなります。
Amazon S3 Select は、CSV、JSON、または Apache Parquet 形式で保存されたオブジェクトで機能します。また、GZIP または BZIP2 で圧縮されたオブジェクト (CSV および JSON オブジェクトのみ)、およびサーバー側の暗号化されたオブジェクトでも機能します。取得するデータ形式を、CSV または JSON として指定できます。また、結果のレコードの区切り文字を指定することもできます。
以下は間違いです
不正解AAWS Lambda 関数を構成して、S3 バケットから pandas データフレームにデータをロードします。必要な列をクエリするために、データフレームに SQL SELECT ステートメントを記述します。
→「AWS Lambda 関数」は、 コードの開発やデプロイが必要 であり、 オブジェクト全体をダウンロード するため、運用オーバーヘッドと効率の面で要件を満たさないため間違いです。
この方法では、Lambda 関数のコードを記述し、Parquet を読み取るための依存関係 (例 : pyarrow など) を含むデプロイパッケージの作成・配布が必要になります。これは「 運用上のオーバーヘッドを最小限に 」という要件に反します。さらに、Lambda で pandas を用いて処理する場合、S3 から Parquet オブジェクト全体を取得してメモリ上に展開してから必要列を抽出する流れになりやすく、 データ転送量・実行時間・メモリ使用量が増大 します。1 列しか必要ないケースでは、サーバー側で射影 (列の選択) ができる S3 Select と比べて非効率です。
Lambda はイベント駆動や軽量なデータ処理に強力ですが、「S3 上の単一オブジェクトから必要な列だけを抜き出す」用途では、S3 Select のような特化機能の方が構成も運用もシンプルです。
不正解CS3 オブジェクトを使用し、必要な列をクエリするために AWS Glue DataBrew プロジェクトを準備します。
→「AWS Glue DataBrew」は、 インタラクティブなデータ準備を目的としたサービス であり、 プロジェクトのセットアップが必要 なため、1 回限りの単純な列抽出タスクには過剰でオーバーヘッドが大きいため間違いです。
AWS Glue DataBrew は、データのクレンジング、正規化、変換などを視覚的なインターフェイスで行うためのデータプレパレーションサービスです。単に 1 つの列を抽出するという 1 回限りの単純なタスク には機能が過剰です。DataBrew プロジェクトを作成し、データセットを定義し、レシピを設計してジョブを実行する一連の手順は、「 運用上のオーバーヘッドを最小限に 」という要件に明確に違反します。
DataBrew は「継続的に使うデータセットの整形・品質改善」を効率化するサービスであり、今回のような単発の列抽出には、より軽量な S3 Select が適しています。
不正解DS3 オブジェクトで AWS Glue クローラーを実行します。Amazon Athena で SQL SELECT ステートメントを使用して、必要な列をクエリします。
→「Amazon Athena」は強力ですが、 テーブル定義の作成 (クローラー実行や DDL による作成) やカタログ管理などの前準備が必要 になりやすく、1 回限りのタスク に対しては運用オーバーヘッドとなるため間違いです。
Amazon Athena は S3 上のデータに対して SQL で分析できる強力なサービスで、Parquet との相性も良い一方、クエリを実行するためには「データをどのスキーマで読むか」というテーブル定義が必要です。テーブル定義は AWS Glue クローラーで自動生成することも、Athena で DDL を書いて作成することもできますが、いずれにしてもテーブル作成・スキーマ調整・カタログ運用といった手順が発生しやすく、「1 回限りのタスク 」と「 運用上のオーバーヘッドを最小限に 」という要件に適合しません。今回の要件は「単一オブジェクトから 1 列だけ取り出す」ことであり、追加基盤を立てずに S3 の機能だけで完結できる S3 Select の方が、構成・運用の両面でシンプルです。
Athena は「複数ファイル / 大量データを横断して分析するプラットフォーム」、S3 Select は「単一オブジェクトから必要部分だけを抜き出す軽量ツール」です。この “プラットフォーム vs ツール” の違いで使い分けを整理しましょう。
この問題の本質
この問題の本質は、S3 に保存された単一オブジェクトに対して「必要な列だけ」を取得したいという要件において、追加の基盤構築や前準備を極力避けつつ、サーバー側で射影 (列選択) を実行できる最適解 (S3 Select) を選べるかにあります。
問題3 |
ある企業は、Amazon Elastic Block Store (Amazon EBS) の汎用 SSD ストレージを gp2 から gp3 にアップグレードする計画を立てています。同社は、アップグレードされたストレージへの移行中に、データ損失の原因となる Amazon EC2 インスタンスの中断を防ぎたいと考えています。
運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。
gp2 ボリュームのスナップショットを作成します。スナップショットから新しい gp3 ボリュームを作成します。新しい gp3 ボリュームを EC2 インスタンスにアタッチします。 | |
新しい gp3 ボリュームを作成します。データを新しい gp3 ボリュームに徐々に転送します。転送が完了したら、新しい gp3 ボリュームを EC2 インスタンスにマウントして、gp2 ボリュームを置き換えます。 | |
既存の gp2 ボリュームのボリュームタイプを gp3 に変更します。ボリュームサイズ、IOPS、およびスループットに新しい値を入力します。 | |
AWS DataSync を使用して、新しい gp3 ボリュームを作成します。元の gp2 ボリュームから新しい gp3 ボリュームにデータを転送します。 |
問題 3 の説明および補足
Amazon EBS のオンラインでのボリューム変更機能
正解C既存の gp2 ボリュームのボリュームタイプを gp3 に変更します。ボリュームサイズ、IOPS、およびスループットに新しい値を入力します。
💡解説のポイント
Amazon EBS には、インスタンスを停止することなくボリュームのタイプやパフォーマンスを変更できる「ボリュームの変更」機能があり、 既存ボリュームをそのまま使い続けながら特性だけを切り替えられるため、運用オーバーヘッドを最小化できる ため正解です。
Amazon EBS は、アタッチされている EC2 インスタンスを稼働させたまま、ボリュームのタイプ、サイズ、IOPS、スループットをオンラインで変更する機能をサポートしています。この「ボリュームの変更」操作は、AWS マネジメントコンソール、AWS CLI、または SDK から簡単に行うことができます。この方法の利点は以下の通りです。
- インスタンスの中断なし : ボリュームの変更中に EC2 インスタンスを停止する必要はありません 。アプリケーションは継続して稼働できます。
- データ損失なし : 既存のデータはすべて保持されたまま 、ボリュームの特性 (タイプ / 性能 / 容量) のみが変更されます。
- 最小の運用オーバーヘッド : スナップショットの作成、リストア、ボリュームのデタッチ / アタッチ、マウントポイント切り替えといった移行手順が不要 で、設定変更のみで完結します。
00:00
AWS 公式ドキュメント要約
※Amazon EBS ボリュームを変更する - Amazon Elastic Compute Cloud
ボリュームの変更アクションを使用して、インスタンスからデタッチすることなく、ボリュームのタイプ、サイズ、IOPS パフォーマンスを変更できます。ほとんどの場合、ボリュームの変更は、既存のインスタンスに影響を与えません。ボリュームの変更は無料です。新しいボリューム設定の料金のみが請求されます。
以下は間違いです
不正解Agp2 ボリュームのスナップショットを作成します。スナップショットから新しい gp3 ボリュームを作成します。新しい gp3 ボリュームを EC2 インスタンスにアタッチします。
→「スナップショットからのリストア」は、最終的にボリュームの切り替え (利用先の変更) が必要となり、インスタンス中断リスクや運用オーバーヘッドが発生するため間違いです。
この方法は技術的には可能ですが、以下の手順が必要となり、運用オーバーヘッドが大きくなります。
- gp2 ボリュームのスナップショットを作成します。
- スナップショットから新しい gp3 ボリュームを作成します。
- (同じデバイス / マウントとして置き換える場合) 利用中の gp2 ボリュームを切り離すか、アプリケーションの参照先 (デバイス名・UUID ・マウントポイント) を切り替えます。
- 新しい gp3 ボリュームを EC2 インスタンスにアタッチします。
- OS レベルで新しいボリュームを認識させ、必要に応じてマウント / 設定を変更します。
スナップショットを利用した方法は、ボリュームのバックアップや、別のアベイラビリティーゾーン (AZ) にボリュームを複製する際には有効な手段です。しかし、同じインスタンスでボリュームの特性を変更するだけであれば、「ボリュームの変更」機能の方がはるかにシンプルで効率的です。
不正解B新しい gp3 ボリュームを作成します。データを新しい gp3 ボリュームに徐々に転送します。転送が完了したら、新しい gp3 ボリュームを EC2 インスタンスにマウントして、gp2 ボリュームを置き換えます。
→「手動でのデータ転送」は、新しいボリュームの作成、同期設計、切り替え作業が必要で、 構成も運用も複雑になりオーバーヘッドが大きい ため間違いです。
この方法は、 手動作業が多く、整合性リスクも高い 方法です。`rsync` などでファイルをコピーしている間も元のボリューム側で更新が発生し得るため、整合性を担保するには「書き込み停止 (フリーズ)」「差分同期の設計」「最終切り替え手順 (マウントポイント変更・fstab/ アプリ設定変更)」が必要になります。最終的にボリュームを切り替える際には、 書き込みを止めたうえで参照先を変更 する必要があり、実質的なダウンタイム (または少なくともアプリ停止 / 縮退運転) が避けられません。「運用上のオーバーヘッドを最小限に抑える」という要件とは正反対の方法です。
この方法は、例えばファイルシステム構成を作り直したい、ディレクトリ構成を整理したいなど、ボリュームタイプ変更以外の目的がある場合に検討されます。しかし、本問題のような単純な gp2 →gp3 のアップグレードには適していません。
不正解DAWS DataSync を使用して、新しい gp3 ボリュームを作成します。元の gp2 ボリュームから新しい gp3 ボリュームにデータを転送します。
→「AWS DataSync」はファイルレベルのデータ転送サービスであり、 EBS のボリュームタイプ変更をオンラインで完結させる用途ではない ため間違いです。
AWS DataSync は、主にオンプレミスのファイルサーバーやネットワークファイルシステム、AWS のストレージ (例 :Amazon S3、Amazon EFS など) との間で、ファイル単位のデータ転送を自動化・高速化するサービスです。一方で、EBS はブロックストレージであり、DataSync は「EBS ボリュームそのもの」をソース / 宛先として直接扱ってボリュームタイプを移行する仕組みではありません。また、DataSync が EBS ボリュームを作成することもできません。
仮に EC2 上でファイルレベル転送を行うとしても、結局は「新規ボリューム作成」「同期」「最終切り替え (参照先変更)」が必要になり、選択肢 B と同様に 運用オーバーヘッドが非常に大きく なります。したがって、このユースケースには適合しません。
AWS のサービス選定問題では、各サービスの「主な用途 (レイヤー)」を正確に理解しておくことが重要です。DataSync はファイル転送の最適化であり、EBS の「ボリューム特性の変更 (タイプ / 性能 / 容量)」を最小手数で行う目的には「ボリュームの変更」機能が最短経路です。
この問題の本質
この問題の本質は、Amazon EBS が提供する「ボリュームの変更」機能が、インスタンスを停止することなくオンラインでボリュームタイプやパフォーマンスを変更でき、切り替え作業 (付け替え / 同期 / 参照先変更) を不要にして運用オーバーヘッドを最小化できる点を理解しているかどうかにあります。
問題4 |
企業は、データレイクに使用する Amazon S3 ストレージをパーティション (分割) する必要があります。パーティションでは、s3://bucket/prefix/year=2023/month=01/day=01 形式の S3 オブジェクトキーのパスが使用されます。
データエンジニアは、企業がバケットに新しいパーティションを追加するときに、AWS Glue Data Catalog が S3 ストレージと同期することを保証する必要があります。
これらの要件を最も少ないレイテンシーで満たすソリューションを選択してください。
AWS Glue クローラーを毎朝実行するようにスケジュールします。 | |
AWS Glue CreatePartition API を毎日 2 回手動で実行します。 | |
Amazon S3 にデータを書き込むコードを使用して、Boto3 AWS Glue create_partition API 呼び出しを呼び出します。 | |
AWS Glue コンソールから MSCK REPAIR TABLE コマンドを実行します。 |
問題 4 の説明および補足
AWS Glue Data Catalog へのパーティション追加のリアルタイム同期
正解CAmazon S3 にデータを書き込むコードを使用して、Boto3 AWS Glue create_partition API コールを呼び出します。
💡解説のポイント
S3 へのデータ書き込みと同時に AWS Glue の API を呼び出してパーティションを明示的に作成する ことで、最も少ないレイテンシーで Data Catalog を同期できるため正解です。
この問題の最も重要な要件は「 最も少ないレイテンシー 」で AWS Glue Data Catalog を更新することです。S3 にデータを書き込むアプリケーションは、自身がどのパーティション (年、月、日) にデータを配置したかを正確に把握しています。そのため、データ書き込み処理が成功した直後に、そのアプリケーションのコード内から Boto3(AWS SDK for Python) などを使用して AWS Glue の `create_partition` API を直接呼び出すのが最も効率的です。(パーティションをまとめて登録したい場合は `batch_create_partition` のようなバッチ API を使う設計も有効です。) この方法により、データが S3 に配置されるとほぼ同時にメタデータも Data Catalog に登録され、後続のクエリエンジン (Amazon Athena など) が即座に新しいデータを認識できるようになります。これは、 追加パーティションを能動的に即時登録でき、スキャン待ちや検出遅延が発生しない ため、低レイテンシー要件に最適です。
00:00
AWS 公式ドキュメント要約
※パーティションの操作 - AWS Glue
ETL ジョブまたはクエリで新しいパーティションが作成されたときに、AWS Glue Data Catalog にパーティションを追加できます。CreatePartition アクション (Python: create_partition) を使用して、指定されたテーブルにパーティションを追加します。このアクションを呼び出すと、パーティションのメタデータがデータカタログに追加されます。
以下は間違いです
不正解AAWS Glue クローラーを毎朝実行するようにスケジュールします。
→「クローラーのスケジュール実行」は、 実行間隔分の遅延 (レイテンシー) が発生する ため間違いです。
AWS Glue クローラー は S3 のパスをスキャンして自動でパーティションを検出・登録する便利な機能ですが、ここでは「毎朝実行」という スケジュールベース の運用になっており、データ追加から反映までの遅延が避けられません。データが追加されてからクローラーが実行されるまでの最大 24 時間近く、Data Catalog は古い状態のままになります。これは「最も少ないレイテンシー」という要件を満たしません。
「Glue Data Catalog の更新」と聞くと、まずクローラーを思い浮かべるかもしれませんが、「レイテンシー」や「リアルタイム性」といった要件がある場合は注意が必要です。クローラーは“検出して反映する”方式のため、即時性には欠けることを理解しておきましょう。
不正解BAWS Glue CreatePartition API を毎日 2 回手動で実行します。
→「手動実行」は 自動化されておらず、実行頻度も低い ため、最も少ないレイテンシーという要件を満たせないため間違いです。
API を直接呼び出すという方法自体は正しい方向性ですが、 手動での実行 は運用負荷が高く、ヒューマンエラーの原因にもなります。また、 「毎日 2 回」という頻度 では、データが追加されてから最大 12 時間の遅延が発生する可能性があり、低レイテンシーの要件を満たすことはできません。
API の利用方法が問われる問題では、「どのように呼び出すか」が重要になります。手動での操作は、自動化や即時性が求められるシナリオでは不適切な選択肢となることがほとんどです。
不正解DAWS Glue コンソールから MSCK REPAIR TABLE コマンドを実行します。
→「`MSCK REPAIR TABLE`」はクローラーと同様に、 実行されるまで同期が行われない ため、低レイテンシーの要件を満たせないため間違いです。
`MSCK REPAIR TABLE` コマンドは、S3 に存在するが Data Catalog に登録されていないパーティションを検出して追加する機能です。(一般的には Amazon Athena など、Hive 互換のメタストアを参照するクエリエンジン側から実行します。) 機能的にはクローラーのパーティション検出と同様に、 “存在を探して追加する”バッチ同期 であり、実行した時点でのスナップショットを反映する方式です。手動または定期的に実行する必要があるため、リアルタイム性はなく、低レイテンシーの要件は満たせません。
`MSCK REPAIR TABLE` は手軽にパーティションを同期できる便利なコマンドですが、クローラーと同様に“後追いで検出する”処理です。リアルタイム性が求められる場合は、データ生成側からの能動的な API コールが最適解となります。
この問題の本質
この問題の本質は、AWS Glue Data Catalog のパーティション管理において、検出型のバッチ処理 (クローラー、MSCK) と、イベントドリブンに明示登録する処理 (API 直接呼び出し) の違いを理解し、要件 (低レイテンシー) に最適な手法を選択できるかにあります。
問題5 |
ある企業は、AWS Glue で ETL (抽出、変換、ロード) データパイプラインを作成しました。データエンジニアは、Microsoft SQL Server のテーブルをクロールする必要があります。データエンジニアは、クロールの出力を抽出、変換し、Amazon S3 バケットにロードする必要があります。データエンジニアは、データパイプラインを調整する必要もあります。
これらの要件を最もコスト効率よく満たす AWS のサービスまたは機能を選択してください。
AWS Step Functions | |
AWS Glue ワークフロー | |
AWS Glue Studio | |
Amazon Managed Workflows for Apache Airflow (Amazon MWAA) |
問題 5 の説明および補足
AWS Glue ネイティブのオーケストレーション機能の選択
正解BAWS Glue ワークフロー
💡解説のポイント
AWS Glue のクローラやジョブを連携させる ETL パイプラインの調整には、Glue ネイティブのオーケストレーション機能である Glue ワークフローが最もシンプルでコスト効率に優れる ため正解です。
AWS Glue ワークフローは、複数の AWS Glue クローラー、ジョブ、およびそれらをつなぐトリガー (依存関係・実行順序・条件分岐) を組み合わせて、ETL データパイプラインを構築・視覚化・実行・監視するための機能です。問題の要件である
(1) SQL Server をクローラでクロールしてメタデータを取得 (必要に応じて Data Catalog に反映)
↓
(2) ETL ジョブで抽出・変換
↓
(3) Amazon S3 にロード
という一連の流れは、まさに Glue ワークフローの典型的なユースケースです。ワークフローを使えば、クローラの完了をトリガーにして後続ジョブを自動起動する、失敗時の再実行や分岐を組む、複数ジョブを並列実行する、といった「パイプライン調整」を Glue の機能だけで完結できます。最も重要な点はコスト効率です。AWS Glue ワークフロー自体に追加料金はかからず 、実行されるクローラやジョブ (DPU 利用など) の料金のみが発生します。外部の汎用オーケストレーション基盤を別途用意しなくてよいため、 追加の運用負荷とコストを増やさずに要件を満たせる ことが決め手です。
00:00
AWS 公式ドキュメント要約
※AWS Glue のワークフロー
AWS Glue では、ワークフローを使用して、複雑な ETL (抽出、変換、ロード) アクティビティを作成および視覚化できます。これには、複数のクローラ、ジョブ、およびトリガーが関連しています。各ワークフローは、実行されるすべてのコンポーネントのブループリントとして、AWS Glue コンソールで設計、グラフ化、実行、およびモニタリングできます。コンソールは、ワークフロー内の各ノードの実行ステータスと進行状況をグラフィカルに表示します。これにより、オーケストレーションプロセス全体を簡単にモニタリングし、トラブルシューティングできます。ワークフローは、オンデマンドまたはスケジュールに基づいて実行できます。
以下は間違いです
不正解AAWS Step Functions
→「AWS Step Functions」は、より汎用的なワークフローサービスであり、Glue 内のパイプライン調整にはコスト効率の面で最適ではないため間違いです。
AWS Step Functions は、AWS Lambda 関数や Amazon ECS タスクなどを連携させ、状態管理 (リトライ、分岐、並列、タイムアウト) を含むワークフローを構築するための汎用オーケストレーションサービスです。AWS Glue ジョブやクローラを呼び出すことも可能ですが、今回の要件は「AWS Glue のクローラとジョブの組み合わせ」で完結しています。このケースで Step Functions を採用すると、状態機械 (ステートマシン) の定義・権限設計・エラー処理の実装など、 Glue だけで済むはずの運用・実装を外部に持ち出して複雑化させやすい 点が不利です。さらに Step Functions は (タイプに応じて) 状態遷移や実行回数に基づく課金が発生するため、Glue ワークフローと比べて「最もコスト効率よく」という要件に合致しません。
AWS Glue 以外のサービス (例 : Lambda、SNS、DynamoDB、外部 API など) と密に連携し、複雑な分岐や人手承認などを含めて統合的に制御したい場合は Step Functions が有力です。一方、Glue 内で完結する ETL 連携では、まず Glue ワークフローを選ぶのが基本です。
不正解CAWS Glue Studio
→「AWS Glue Studio」は ETL ジョブを開発するための GUI ツールであり、パイプライン全体を調整 (オーケストレーション) する機能ではないため間違いです。
AWS Glue Studio は、ETL ジョブのスクリプトを 視覚的なインターフェースで開発・作成するための統合開発環境 (IDE) です。ソース、ターゲット、変換処理をボックスとしてつなぎ合わせることで、ノーコード / ローコードで ETL ジョブを設計できます。しかし、Glue Studio 自体は「複数のクローラ・複数ジョブの依存関係を定義し、実行順序を制御する」ためのオーケストレーション機能ではありません。作成したジョブは Glue ワークフローに組み込み、トリガーで連携させて初めてパイプラインとして自動実行できます。つまり、Studio は「作る」ための機能であり、問題文の「データパイプラインを調整 (オーケストレーション) する」という要件の中核を単独では満たせません。
「開発ツール」と「実行・連携 (オーケストレーション) ツール」の役割を区別しましょう。Glue Studio はジョブ設計の生産性を上げる一方、ジョブとクローラの連携・自動実行は Glue ワークフロー (または Step Functions 等) が担当します。
不正解DAmazon Managed Workflows for Apache Airflow (Amazon MWAA)
→「Amazon MWAA」は、非常に高機能ですが、Glue 内のパイプライン調整にはオーバースペックであり、コスト効率の要件を満たさないため間違いです。
Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、オープンソースのワークフロー管理ツールである Apache Airflow をマネージドで提供するサービスです。多様なタスクや複雑な依存関係をコード (DAG) で管理でき、データ基盤全体の統合オーケストレーションに強みがあります。しかし今回の要件は Glue のクローラとジョブの連携が中心であり、MWAA を導入すると Airflow 環境 (スケジューラ / ワーカー等) の維持・運用とそれに伴うコストが発生しやすい ため、過剰な選択になります。Glue ワークフローで十分に満たせる要件に対して MWAA を選ぶのは、「最もコスト効率よく」という制約に反します。
既存の Airflow の知見や DAG 資産を活用したい場合、または Glue 以外 (複数クラウドやオンプレミスを含む) の多数の処理を一元スケジューリングしたい場合に MWAA は有力です。一方、Glue 内で完結するシンプルな ETL 連携は、AWS ネイティブ機能を優先するのが定石です。
この問題の本質
この問題の本質は、AWS Glue 内のコンポーネント (クローラとジョブ) で完結する ETL パイプラインのオーケストレーションには、外部の汎用ワークフローサービスを持ち込むより、ネイティブ機能である Glue ワークフローを使うのが最もシンプルかつコスト効率に優れる点を理解することです。
問題6 |
ある企業がセキュリティレビュー中に、AWS Glue ジョブの脆弱性を特定しました。同社は、Amazon Redshift クラスターにアクセスするための認証情報がジョブスクリプトにハードコードされていることを発見しました。
データエンジニアは、AWS Glue ジョブのセキュリティ脆弱性を修正する必要があります。ソリューションは認証情報を安全に保存する必要があります。
これらの要件を満たす最適な手順の組み合わせを選択してください。(2 つ選択)
AWS Glue のジョブパラメータに認証情報を保存します。 | |
Amazon S3 バケットにある設定ファイルに認証情報を保存します。 | |
AWS Glue ジョブを使用して、Amazon S3 バケット内の設定ファイルから認証情報にアクセスします。 | |
AWS Secrets Manager に認証情報を保存します。 | |
AWS Glue ジョブの IAM ロールに、保存された認証情報へのアクセスを付与します。 |
問題 6 の説明および補足
AWS Secrets Manager と IAM ロールによる認証情報の安全な管理
正解DAWS Secrets Manager に認証情報を保存します。
💡解説のポイント
機密情報を安全に保管・管理するための専用サービスである AWS Secrets Manager を利用する ことで、スクリプトへのハードコーディング (漏洩・使い回し・ローテーション困難) という脆弱性を根本から解消できるため正解です。
AWS Secrets Manager は、データベースの認証情報、API キー、その他のシークレットをライフサイクル全体で保護・管理し、必要に応じてローテーションまで支援する専用サービスです。 KMS により暗号化して安全に保管 し、 IAM ポリシー によって「どのジョブ (ロール) が」「どのシークレットに」「どの操作で」アクセスできるかをきめ細かく制御できます。スクリプト内に固定値として埋め込むのではなく、実行時に Secrets Manager から動的に取得することで、漏洩リスクの低減・権限の最小化・監査 (CloudTrail) を同時に実現できます。
正解EAWS Glue ジョブの IAM ロールに、保存された認証情報へのアクセスを付与します。
💡解説のポイント
AWS Secrets Manager に保存した認証情報をジョブから安全に取得するには、 実行元の IAM ロールに必要最小限の権限を付与する 必要があり、これがベストプラクティスであるため正解です。
AWS Glue ジョブは、指定された IAM ロールの権限で他の AWS サービスにアクセスします。Secrets Manager のシークレット値を取得するには、この IAM ロールに
secretsmanager:GetSecretValue などの 必要な API アクションのみを許可する IAM ポリシーをアタッチ します。さらに、特定のシークレット ARN にスコープを絞ることで「他のシークレットは読めない」状態を作れます。これにより、AWS Glue ジョブは認証情報をコードや設定ファイルに直接保持せずに、安全に取得して Amazon Redshift へ接続できます。
00:00
AWS 公式ドキュメント要約
※AWS Secrets Manager のシークレットを使用した機密情報の受け渡し
AWS の各種サービスでは、AWS Secrets Manager を使用して機密情報を安全に保管・取得し、アプリケーション実行時に参照する設計が推奨されます。Secrets Manager を使用すると、データベース認証情報、API キー、およびその他のシークレットをライフサイクル全体で管理し、必要に応じてローテーションも行えます。
以下は間違いです
不正解AAWS Glue のジョブパラメータに認証情報を保存します。
→「ジョブパラメータ」は機密情報の保管を目的とした仕組みではなく、 権限を持つユーザーに値が参照され得る ため間違いです。
ジョブパラメータ は、スクリプトの動作を外部から制御するための便利な機能ですが、認証情報のような機密データを安全に保管する機構 (専用のアクセス制御、ローテーション、監査の前提) ではありません。コンソールや API 経由で 値が露出する運用になりやすい ため、ハードコーディングと同様に漏洩リスクを抱えます。機密情報は「参照して処理を動かす」引数に置くのではなく、Secrets Manager などの専用ストアに集約して実行時に取得するのが基本です。
ジョブパラメータは、入力 / 出力パスや処理モードの切り替えなど、非機密情報の受け渡しに利用します。機密情報は必ず Secrets Manager や Parameter Store の SecureString を利用する、と覚えましょう。
不正解BAmazon S3 バケットにある設定ファイルに認証情報を保存します。
→「S3 の設定ファイル」に認証情報を保存する方法は、保存・配布・ローテーションの運用が重くなり、 シークレット管理として不適切になりやすい ため間違いです。
Amazon S3 に設定ファイルを置くこと自体は一般的ですが、そのファイル内に認証情報を直接保持すると、閲覧権限を持つ主体がファイルを取得した時点で 認証情報が漏洩し得る という「シークレット配布問題」が残ります。SSE-S3 / SSE-KMS などの暗号化は保管中の保護には有効でも、「誰が中身を読めるか」「いつ・どうローテーションするか」「漏洩時に即時失効できるか」という観点では専用のシークレット管理に劣ります。結果として、機密情報の安全な保管という要件に対して最適解になりません。
S3 にファイルを置くという選択肢は一見すると良さそうに見えますが、「何を」置くかが重要です。認証情報をファイルに書く時点で、そのファイル自体が「シークレット」となり、その管理 (権限・配布・更新・監査) が問題になります。この連鎖を断ち切るのが Secrets Manager です。
不正解CAWS Glue ジョブを使用して、Amazon S3 バケット内の設定ファイルから認証情報にアクセスします。
→この選択肢はアクセス方法を述べていますが、前提となる「S3 の設定ファイルに認証情報を保持する」という設計自体が シークレット管理として最適ではない ため間違いです。
この選択肢は、選択肢 B の方式 (S3 上のファイルに認証情報を持たせる) を実装する手順に過ぎません。保存先がシークレット管理の要件 (最小権限・監査・容易なローテーション・漏洩時の即時切替) に適していない以上、そこから取得する実装をしても根本課題は解消しません。安全に保存するという要件に対して、Secrets Manager + IAM の組み合わせが優先されます。
この選択肢は、B とセットで考える必要があります。B が最適解にならない以上、C も最適解になりません。このように、関連する選択肢をグループ化して判断するのも試験テクニックの一つです。
この問題の本質
この問題の本質は、ジョブスクリプトや設定ファイルなど「漏洩しやすい場所」に認証情報を固定値で持たせるのをやめ、AWS が提供する専用のシークレット管理サービス (AWS Secrets Manager) に集約したうえで、実行ロールの最小権限 (必要なシークレットへの GetSecretValue など) で安全に取得させる設計を理解しているかどうかにあります。
問題7 |
企業は AWS にデータレイクを構築する必要があります。企業は、行レベルのデータアクセスと列レベルのデータアクセスを特定のチームに提供する必要があります。チームは、Amazon Athena、Amazon Redshift Spectrum、および Amazon EMR からの Apache Hive を使用してデータにアクセスします。
運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。
データレイクのストレージに Amazon S3 を使用します。S3 アクセスポリシーを使用して、行と列でデータアクセスを制限します。Amazon S3 経由でデータアクセスを提供します。 | |
データレイクのストレージに Amazon S3 を使用します。Amazon EMR 経由で Apache Ranger を使用して、行と列でデータアクセスを制限します。Apache Pig を使用してデータアクセスを提供します。 | |
データレイクのストレージに Amazon Redshift を使用します。Redshift セキュリティポリシーを使用して、行と列でデータアクセスを制限します。Apache Spark と Amazon Athena フェデレーテッドクエリを使用してデータアクセスを提供します。 | |
データレイクのストレージに Amazon S3 を使用します。AWS Lake Formation を使用して、行と列でデータアクセスを制限します。AWS Lake Formation 経由でデータアクセスを提供します。 |
問題 7 の説明および補足
AWS Lake Formation によるデータレイクの一元的な権限管理
正解Dデータレイクのストレージに Amazon S3 を使用します。AWS Lake Formation を使用して、行と列でデータアクセスを制限します。AWS Lake Formation 経由でデータアクセスを提供します。
💡解説のポイント
AWS Lake Formation が、データレイクに対する 行レベルおよび列レベルのアクセス許可を一元的に管理 し、複数の AWS 分析サービスに適用できるため正解です。
AWS Lake Formation は、データレイクの構築、保護、管理を簡素化するフルマネージドサービスです。このサービスの中核は、AWS Glue Data Catalog に登録されたデータ (データベース / テーブル / パーティションなど) に対して、きめ細かな権限を一元的に定義できる点にあります。 テーブル、列、行、さらにはセルレベルでのアクセス許可 を、Lake Formation の許可 (Permissions) としてまとめて管理できます。
特に「行 / 列レベル」を両立する要件では、Lake Formation の データフィルター (Data filters) により、返却結果を「許可された列のみに限定」「条件に合致する行のみに限定 (= 行レベル)」といった制御を実現できます。これらの設定はデータレイクのガバナンス層として集約されるため、各サービス側で独自の権限実装 (ビューの乱立、データ複製、アプリ側フィルタリングなど) を作り込む必要がありません。
重要なのは、Lake Formation で設定した権限が、Amazon Athena、Amazon Redshift Spectrum、Amazon EMR(Hive / Spark など、Lake Formation 統合を有効化したクラスター) といった統合された AWS の分析サービスに適用される点です。これにより、サービスごとに個別の権限ポリシーを管理する必要がなくなり、データガバナンスが大幅に簡素化され、 運用上のオーバーヘッドを最小限に抑える という要件を満たします。具体的には、LF-Tag(Lake Formation タグ) ベースのアクセスコントロールを用いることで、データアセットと IAM プリンシパル (ユーザー / ロール) にタグを付け、そのタグに基づいてポリシーを定義できるため、権限管理をスケーラブルに拡張できます。
00:00
AWS 公式ドキュメント要約
※AWS Lake Formation とは ? - AWS Lake Formation
Lake Formation は、Amazon S3 のデータに対するきめ細かなアクセスコントロールを提供します。タグベースのアクセスコントロール方法を使用して、ポリシーを大規模に管理できます。テーブル、列、行、およびセルレベルで権限を定義し、Amazon Athena、Amazon Redshift Spectrum、Amazon EMR などの統合 AWS 分析および機械学習サービス全体でこれらのポリシーを適用できます。Lake Formation 許可は、AWS Glue Data Catalog の既存の IAM 権限モデルを拡張します。
以下は間違いです
不正解Aデータレイクのストレージに Amazon S3 を使用します。S3 アクセスポリシーを使用して、行と列でデータアクセスを制限します。Amazon S3 経由でデータアクセスを提供します。
→「S3 アクセスポリシー」は、オブジェクトレベルの制御は可能ですが、 ファイル内の特定の行や列に対するアクセス制御は直接サポートしていない ため間違いです。
S3 のアクセスポリシー (IAM ポリシーやバケットポリシー) は、どのユーザーがどの S3 オブジェクト (ファイル) やプレフィックス (フォルダ) にアクセスできるかを制御するためのものです。しかし、Parquet や CSV といったファイル形式の内部構造を解釈して、特定の行や列へのアクセスを許可・拒否する機能はありません。この要件を満たすには、ビューや派生データを別オブジェクトとして大量に作成する、列ごとにファイルを分割して管理する、アプリケーション側で常にフィルタリングして返す、といった回避策が必要になり、権限の整合性維持やデータ複製が発生して運用オーバーヘッドが著しく増大します。
S3 はデータレイクの「ストレージ層」であり、アクセス制御は「ガバナンス層」の役割です。S3 ポリシーだけでデータレイクのきめ細かな権限管理を完結させようとするのは一般的な誤りです。この問題のように、データの中身に対するアクセス制御が求められる場合は、AWS Lake Formation のような上位のガバナンスサービスを検討する必要があります。
不正解Bデータレイクのストレージに Amazon S3 を使用します。Amazon EMR 経由で Apache Ranger を使用して、行と列でデータアクセスを制限します。Apache Pig を使用してデータアクセスを提供します。
→「Apache Ranger on EMR」は、EMR クラスター内のアクセスは制御できますが、Amazon Athena や Amazon Redshift Spectrum からのアクセスを一元的に管理できない ため間違いです。
Apache Ranger は Hadoop エコシステムで強力なセキュリティ機能を提供し、EMR クラスター上で Hive や Spark の行・列レベルのセキュリティを実装できます。しかし、その効力は Ranger が導入された EMR クラスター (およびその周辺コンポーネント) に限定されます。問題文では、Amazon Athena や Amazon Redshift Spectrum といった EMR 外のサービスからのアクセスも同じ基準で制御する必要がありますが、これらのサービスは EMR クラスターを経由してクエリを実行するわけではないため、Ranger の制御対象外になります。
さらに、Ranger の導入・プラグイン設定・監査ログ運用・ポリシー配布などは設計と保守が必要で、 運用オーバーヘッドが高く 、要件 (最小オーバーヘッド) に反します。加えて、設問では EMR 側のアクセス手段として Apache Hive が明示されているため、「Apache Pig を使用してデータアクセスを提供する」という前提自体も要件と整合しません。
EMR に特化した要件であれば Apache Ranger は有効な選択肢ですが、複数の AWS 分析サービスを横断した一元的なガバナンスが求められる場合は、AWS ネイティブの統合サービスである AWS Lake Formation を検討するのが定石です。サービスの適用範囲を見極めることが重要です。
不正解Cデータレイクのストレージに Amazon Redshift を使用します。Redshift セキュリティポリシーを使用して、行と列でデータアクセスを制限します。Apache Spark と Amazon Athena フェデレーテッドクエリを使用してデータアクセスを提供します。
→「データレイクのストレージに Amazon Redshift を使用する」という構成は、 設問が求める “ S3 上のデータレイクを複数サービスから参照し、同一のガバナンスで行 / 列制御する” という前提と噛み合わない ため間違いです。
Amazon Redshift はデータウェアハウスであり、Redshift 内のテーブルに対しては列レベルの権限 (列単位の GRANT/REVOKE) や行レベルセキュリティ (RLS) など、詳細に設定されたアクセスコントロールを実装できます。しかし、それは「Redshift に取り込んだデータ」に対する制御であり、設問のように Amazon Athena / Amazon Redshift Spectrum / Amazon EMR(Hive) が共通のデータレイク (通常は S3) を参照する構成とは前提が異なります。
また、Amazon Redshift Spectrum は “ Amazon S3 上のデータ” を対象に外部テーブルでクエリする機能です。データの保管先を Redshift にしてしまうと、Spectrum を使う必然性がなくなり、設問のアクセス経路 (Athena / Spectrum / EMR Hive) を同一の権限体系で揃えることもできません。結果として、Athena のフェデレーテッドクエリや Spark 連携を持ち出しても、サービス横断での一元的な行 / 列レベル統制という要件を満たすのが難しく、運用も複雑化します。
「データレイク」と「データウェアハウス」の役割の違いを正確に理解することが重要です。Redshift はデータレイクの「消費者」の一つにはなり得ますが、複数サービス共通のデータレイク基盤 (S3) に対する権限を一元管理する役割は、AWS Lake Formation が担います。アーキテクチャの役割分担を混同しないようにしましょう。
この問題の本質
この問題の本質は、複数の AWS 分析サービスから利用されるデータレイクにおいて、行 / 列レベルの詳細に設定されたアクセスコントロールを一元的かつ低オーバーヘッドで実現するガバナンス層の役割をどのサービスが担うかを理解しているかという点にあります。
問題は全部で 7 問。全て答えられるように頑張りましょう！
|
リスト |
