AWS DEA無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。
問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題1から10問抜粋しております。
多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。
特別価格： 通常2,600円 → 1,500円
講師クーポン適用で42%OFF
講師クーポン【図解付き詳細解説】AWS DEA-C01完全攻略問題集 | 構成図＆グラフ解説付き
この資格を活かしたキャリア情報
DEA資格の取得後にどんなキャリアが開けるか、詳しくはこちら：
→ DEA合格者の転職市場価値と求人傾向
AWS資格全体のキャリア活用法：
→ AWS資格は転職・キャリアアップでどう活きる？資格別市場価値と実体験
問題文：
大手製造業は、全国の拠点から集約した受注データを単一のAmazon S3データレイクに保存しています。このデータレイクには1日あたり約40万件の受注レコードが追加され、家電事業部（CE）と産業機器事業部（IE）のアナリストが、週に数回、売れ筋製品の傾向や在庫の偏りを調べるために集計クエリを実行しています。データガバナンス部門は、各アナリストが自分の所属する事業部の受注レコードだけを参照できるようにしつつ、運用の手間を最小限に抑えたいと考えています。 この要件を満たすソリューションはどれですか。
選択肢：
A. 受注データのS3バケットをLake Formationにデータレイクロケーションとして登録し、行レベルセキュリティのデータフィルターで事業部別の行を制御します。
B. 受注データを拠点に近いAWSリージョンへ複製し、アナリストには所属事業部に応じた権限を割り当てます。
C. AWS Glue Data Catalogに、事業部ごとの受注データ用テーブルを個別に定義します。各アナリストには、所属する事業部のテーブルへのSELECT権限だけを付与します。
D. Amazon QuickSightの行レベルセキュリティを設定し、事業部ごとの権限ルールでダッシュボードに表示される受注データの行を制限します。
正解：A
A. 受注データのS3バケットをLake Formationにデータレイクロケーションとして登録し、行レベルセキュリティのデータフィルターで事業部別の行を制御します。
正解 Lake Formationはデータレイクの権限を一元管理するサービスです。行レベルセキュリティ（Row-Level Security）を使うと、単一テーブルのまま行単位で表示範囲を絞れます。事業部ごとの行フィルター式を持つデータフィルターを定義し、SELECT権限を付与する際にアナリストのIAMロールへ関連付けると、クエリ実行時にそのロールに紐づく行だけが自動的に返り、テーブルを分ける必要がありません。事業部の追加もフィルターと権限付与の追加だけで済み、中央集権的なガバナンスを保ちながら最小限の設定で要件を満たします。
B. 受注データを拠点に近いAWSリージョンへ複製し、アナリストには所属事業部に応じた権限を割り当てます。
不正解 リージョンを分けても、アクセス制御の単位が変わるわけではありません。リージョンは物理的なインフラの場所であって、データの参照範囲を制限する仕組みではないため、同じリージョン内のアナリストは他事業部の受注レコードにもアクセスできてしまいます。複数リージョンへの複製は同期や一貫性の維持、クロスリージョンの転送コストという追加の負担も生みます。
C. AWS Glue Data Catalogに、事業部ごとの受注データ用テーブルを個別に定義します。各アナリストには、所属する事業部のテーブルへのSELECT権限だけを付与します。
不正解 事業部ごとに個別のテーブルを用意する方式は、技術的には機能しますが、運用の手間が大きくなります。事業部が増えるたびにテーブル定義と権限設定をやり直す必要があり、同じ受注データを複数のテーブルに分けることでデータの整合性維持も難しくなります。スキーマ変更の際は全テーブルに個別に反映しなければならず、管理コストが膨らみます。
D. Amazon QuickSightの行レベルセキュリティを設定し、事業部ごとの権限ルールでダッシュボードに表示される受注データの行を制限します。
不正解 QuickSightの行レベルセキュリティは、QuickSightのデータセットやダッシュボードで閲覧者に見せる行を制限する機能です。閲覧者はルールで許可された行しか表示されませんが、この制御はQuickSight内部にしか効かず、S3のデータレイク本体へのアクセス（Athenaなどのクエリ）を制限するものではありません。アナリストがデータレイクを直接クエリすれば、所属外の事業部の受注レコードも参照できてしまいます。データレイク全体のアクセス制御という要件は満たせません。
全体的な説明
問われている要件
- S3データレイクに統合された受注データへのアクセスを事業部別に制限すること
- 各アナリストが自事業部の受注レコードにのみアクセスできるようにすること
- 全社横断の分析を支える既存のデータレイクを活用すること
- 運用の手間を最小限に抑えて実装すること
前提知識
AWS Lake Formationについて
AWS Lake Formationは、データレイクの構築、保護、管理を数日で行えるようにするサービスです。 データカタログの作成、データ変換、きめ細かいアクセス制御、データ監査などの機能を提供します。S3に保存されたデータをデータレイクロケーションとして登録することで、Lake Formationの権限管理機能を使用してアクセスを制御できます。
行レベルセキュリティとデータフィルターの仕組み
Lake Formationのデータフィルターは、テーブルへのアクセス時に行と列を制限する機能です。 行フィルター式はPartiQLのWHERE句に相当する構文サブセットで定義し、式の長さは2048文字未満に収める必要があります。フィルターを作成し、SELECT権限を付与するプリンシパルごとに関連付けることで、同じテーブルでもプリンシパルによって異なるデータ行を表示できます。行フィルター式で使えるデータ型はSTRING、CHAR、VARCHAR、INT、LONG、BIGINT、FLOAT、DECIMAL、DOUBLE、BOOLEAN、STRUCTで、ARRAYとMAPは使用できません。
従来のアクセス制御方法との比較
テーブル分割やビュー作成によるアクセス制御は、新しい条件が追加されるたびに手動での設定変更が必要です。 Lake Formationの行レベルセキュリティでは、データを1つのテーブルに保ったまま、プリンシパル（IAMロールやIAM Identity Centerのユーザー・グループ）にデータフィルター付きのSELECT権限を付与するだけでよいため、新しいアナリストの追加や事業部の追加時にも最小限の設定変更で対応できます。また、Athena（エンジンバージョン3以降）、Redshift Spectrum、EMR、Glueなど複数のクエリエンジンで一貫したアクセス制御が適用されます。 なお、Amazon QuickSightにも行レベルセキュリティの機能はありますが、これはダッシュボード上の表示制御であって、データレイク本体へのアクセスを制限するものではありません。Amazon QuickSightは2025年10月にAmazon Quick Suiteへ統合され、現在はQuick Suiteの一機能として提供されていますが、行レベルセキュリティの考え方はこの問題の文脈のまま理解して問題ありません。
アーキテクチャ図の解説
アーキテクチャ図
受注データを格納したS3バケットをLake Formationのデータレイクロケーションとして登録し、Glue Data Catalogと連携してメタデータを管理します。その上でデータフィルター（行レベルセキュリティ）をSELECT権限に関連付けると、Athenaでクエリを実行する時点で、アナリストの所属事業部に応じた行だけが自動的に絞り込まれます。家電事業部のアナリストには家電の受注行だけが、産業機器事業部のアナリストには産業機器の受注行だけが返ります。テーブルを事業部ごとに分ける方式と違い、事業部の追加はフィルターとIAMロールの関連付けだけで済み、単一テーブルのまま一貫性を保てます。データをリージョンで分けたり、事業部ごとにテーブルを分けたり、BIツール側の表示制御に頼ったりする方式では、このきめ細かい制御をデータレイク全体に対して最小の運用負荷で実現できません。
アーキテクチャ図
全事業部の受注を統合したテーブルから、家電事業部のアナリストがクエリを実行すると business_unit=CE という条件が自動付与されて家電の受注行だけが返り、産業機器事業部のアナリストには business_unit=IE が適用されて産業機器の受注行だけが返ります。重要なのは、フィルターがデータを物理的に複製・分割するのではなく、クエリ実行時に行の条件を付与するだけという点です。そのため新しい事業部を追加する場合も、フィルター条件とIAMロールの関連付けを追加するだけで対応でき、テーブルやETLの再構成は不要です。この仕組みを「データを事業部ごとに分けて格納する」と誤解すると、不要なテーブル複製や変換処理を増やして運用負荷を逆に高めてしまいます。
解くための考え方
受注データは単一のテーブルにまとまっています。テーブルを分割せずに行単位で参照範囲を変えられる仕組みが、最も運用負担を抑えられます。 テーブルを事業部ごとに分ける案は、事業部が増えるたびにテーブル定義・権限設定・ETLの再構築が続き、データの一貫性も損ないます。データをリージョンで分ける案は、リージョンがアクセス制御の単位ではないため要件を満たしません。QuickSightの行レベルセキュリティで制御する案は、制御がダッシュボード表示に限られ、データレイク本体へのアクセスを止められません。 これに対し、Lake Formationの行レベルセキュリティは、S3のデータをそのままデータレイクロケーションとして登録し、データフィルターをIAMロールに関連付けるだけで行単位の制御ができます。事業部の追加もフィルター条件の追加だけで済むため、管理コストを最も低く抑えられます。 参考資料
問題文：
金融サービス企業のリスク管理部門は、市場動向や経済指標、格付け情報など複数のサードパーティデータプロバイダーが公開するデータセットを、既存のリスク分析プラットフォームへ毎日取り込みたいと考えています。アナリストは日次で更新される外部データを自社のリスク計測ワークフローにそのまま組み込み、レポートの精度を高めたいと考えています。同社は、データセットの調達と統合に必要な労力と時間を最小限に抑えたいと考えています。 運用の手間を最小にしながらこの要件を満たすソリューションはどれですか。
選択肢：
A. API呼び出しを使用して、AWS DataSyncからサードパーティのデータセットにアクセスし、既存の分析プラットフォームに統合します。
B. Amazon AppFlowを使用して、サードパーティのデータセットにアクセスし、統合します。
C. AWS Data Exchangeでデータセットをサブスクライブし、API呼び出しで取得して分析プラットフォームへ統合します。
D. AWS Glue Data Catalogを使用して、サードパーティのデータセットにアクセスし、統合します。
正解：C
A. API呼び出しを使用して、AWS DataSyncからサードパーティのデータセットにアクセスし、既存の分析プラットフォームに統合します。
不正解 AWS DataSyncは、オンプレミスとAWS間、AWSストレージサービス間、さらにAzure Blob StorageやGoogle Cloud Storageなど他クラウドのストレージとの間で、データ転送を自動化するマネージドサービスです。 NFS、SMB、HDFS、オブジェクトストレージなど、すでにアクセス権を持つストレージ同士でファイルやオブジェクトを移動する用途に設計されており、データプロバイダーが販売する商用データセットを検索・購読して取り込む仕組みは備えていません。 この選択肢ではデータセットの調達手段が別途必要になり、調達と統合の労力を最小化するという要件を満たせません。
B. Amazon AppFlowを使用して、サードパーティのデータセットにアクセスし、統合します。
不正解 Amazon AppFlowは、SalesforceやServiceNowなどのSaaSアプリケーションとAWSサービスの間で、データを双方向に連携するフルマネージド統合サービスです。 接続先ごとに自社のアカウントと認証情報を用意したうえでフローを構成する仕組みであり、複数のデータプロバイダーが公開する商用データセットを一箇所で検索し、サブスクリプション形式で購読する機能はありません。 市場動向や格付けなどの外部データセットを調達する段階を解決できないため、この要件には適しません。
C. AWS Data Exchangeでデータセットをサブスクライブし、API呼び出しで取得して分析プラットフォームへ統合します。
正解 AWS Data Exchangeは、サードパーティのデータセットを検索、サブスクライブ、利用するために設計されたサービスです。多数のデータプロバイダーが公開する商用データセットやAPIにアクセスでき、IAM認証による統一的なアクセス方式と請求の一元化を提供します。サブスクリプションベースでデータセットに簡単にアクセスでき、独自のデータ取得パイプラインを構築する必要がありません。APIベースのデータセットとファイルベースのデータセットの両方をサポートし、プロバイダーが新しいリビジョンを公開した際の自動エクスポートやEventBridgeイベントによる通知も利用できるため、日次で更新される外部データの取り込みを最小限の労力で実現できます。
D. AWS Glue Data Catalogを使用して、サードパーティのデータセットにアクセスし、統合します。
不正解 AWS Glue Data Catalogは、データレイク内のデータに関するメタデータ（テーブル定義、スキーマ、パーティション情報など）を一元管理するカタログサービスです。 自社データの所在や構造を管理するためのものであり、サードパーティが公開する商用データセットを検索・購読して取得する機能はありません。 外部データセットの取得にはAWS Data Exchangeを使用します。
全体的な説明
問われている要件
- リスク分析プラットフォームをサードパーティのデータセットで強化すること
- 市場動向・経済指標・格付け情報などの外部データセットを既存の分析基盤に毎日統合すること
- データセット調達と統合に必要な労力と時間を最小限に抑えること
- 運用の手間を最小にしながらソリューションを実装すること
前提知識
AWS Data Exchangeについて
AWS Data Exchangeは、AWSクラウド内でサードパーティのデータを簡単に検索、サブスクライブ、利用できるサービスです。 金融、気象、マーケティングなど多数のデータプロバイダーが商用データセットを公開しています。データセットの形式は、ファイル、API、Amazon Redshift、Amazon S3データアクセスなど複数がサポートされています。IAM認証による統一的なアクセス方式を提供し、すべての料金はAWS請求に統合されます。プロバイダーが新しいリビジョンを公開したときに自動でAmazon S3へエクスポートする設定や、Amazon EventBridgeイベントを利用した後続処理の起動もできるため、日次更新のデータを継続的に取り込む運用を自動化できます。
AWS DataSyncについて
AWS DataSyncは、オンプレミスとAWS間、AWSサービス間、さらに他クラウドのオブジェクトストレージとの間でデータを自動的に移動するデータ転送サービスです。 NFS、SMB、HDFS、S3、EFS、FSx、Azure Blob Storage、Google Cloud Storageなどのストレージシステム間でのデータ移動をサポートします。帯域幅の最適化、データ検証、暗号化などの機能を提供しますが、いずれも転送元にアクセスできることが前提であり、商用データセットを購読して調達する機能はありません。主にデータ移行やハイブリッド／マルチクラウド構成での継続的なデータ転送に使用されます。
AWS Glue Data Catalogについて
AWS Glue Data Catalogは、データレイク内のテーブル定義やスキーマなどのメタデータを一元管理するカタログサービスです。 クローラーやETLジョブが参照するテーブル情報を保持し、AthenaやRedshift Spectrumなどのクエリエンジンから利用されます。自社データの所在と構造を管理するためのものであり、外部のデータプロバイダーが公開する商用データセットを購読する機能はありません。
Amazon AppFlowについて
Amazon AppFlowは、Salesforce、ServiceNow、Google AnalyticsなどのSaaSアプリケーションとAWSサービス間でデータを双方向に連携する統合サービスです。 SaaSアプリのレコードやイベントをS3やRedshiftへ移行する用途に適していますが、データプロバイダーが公開するライセンス付きのデータセットを検索・購読する機能はありません。外部データセットの取得にはAWS Data Exchangeが適しています。
解くための考え方
サードパーティのデータセットを毎日取り込むには、専用に設計されたサービスを使うのが最も効率的です。 AWS Data Exchangeは、まさにこの目的のために設計されたサービスであり、データプロバイダーが公開するデータセットを簡単にサブスクライブして利用できます。 他の選択肢で挙げられているサービスを評価すると、DataSyncはストレージ間のデータ転送用であり、サードパーティデータプロバイダーへの接続機能はありません。 Glue Data Catalogは自社データのメタデータ管理用、AppFlowはSaaSアプリとのデータ連携用であり、いずれも商用データセットの購読には適していません。 AWS Data Exchangeを使用すると、サブスクリプション手続きだけでサードパーティのデータセットにアクセスでき、独自のデータ取得パイプラインを構築する必要がありません。 APIやファイルとしてデータを取得でき、新しいリビジョンの自動エクスポートやEventBridgeイベントと組み合わせれば、日次更新の取り込みまで含めて運用の手間を最小限にできます。 参考資料
問題文：
ある物流会社のデータエンジニアは、オンプレミスのデータセンターに保管している約7TBの配送・在庫データをAmazon S3バケットへ安全に移行する必要があります。このデータは毎日約4%（およそ280GB）が更新され、配送管理チームが翌朝のルート最適化や在庫分析に使うため、変更分を夜間に自動でS3バケットへ反映する必要があります。データにはCSVやJSONなど複数の形式のファイルが混在しています。データエンジニアは、この転送処理を自動化し、毎日決まった時刻に実行されるようにスケジュールしたいと考えています。 最も運用効率の高い方法でデータを転送するには、どのAWSサービスを使用すべきですか。
選択肢：
A. Amazon S3 Transfer Acceleration
B. AWS DataSync
C. AWS Direct Connect
D. AWS Transfer Family
正解：B
A. Amazon S3 Transfer Acceleration
不正解 S3 Transfer Accelerationは、クライアントとS3バケットの間の長距離ファイル転送を高速化する機能です。CloudFrontのエッジロケーションを経由させてアップロードを速めますが、継続的なデータ同期を前提にした機能ではありません。個々のアップロードを高速化するだけで、変更ファイルの自動検出やスケジュール実行、整合性検証は提供しません。毎日更新される大量のファイルを定期同期する用途では、DataSyncに比べて運用の手間が増えます。
B. AWS DataSync
正解 AWS DataSyncは、オンプレミスストレージとAWSストレージサービス間のデータ転送に特化したマネージドサービスです。変更されたファイルだけを自動で検出して転送する増分同期に対応しており、日々更新される配送・在庫データを効率よく同期できます。転送中のデータ整合性検証、帯域幅の調整、タスクのスケジュール実行を標準で備えています。オンプレミス側にエージェントを1つ配置してタスクをスケジュールするだけで、定期的な自動転送を運用できます。セキュリティ面では転送中のデータをTLSで暗号化し、S3の暗号化機能とも連携できます。
C. AWS Direct Connect
不正解 AWS Direct Connectは、オンプレミス環境とAWSの間に専用のネットワーク接続を確立するサービスです。接続の品質や帯域幅を高めることはできますが、データ転送そのものを自動化したり、スケジュール実行したり、増分を検出したりする機能は提供しません。転送経路となる基盤を用意するサービスであり、転送処理の管理やオーケストレーションは別途自前で組み立てる必要があります。さらに物理的な接続の確立が必要なため、運用開始までに時間がかかります。
D. AWS Transfer Family
不正解 AWS Transfer Familyは、SFTP・FTPS・FTP・AS2といったプロトコルでファイルを送受信するためのマネージドエンドポイントを提供するサービスです。クライアントが接続してファイルをアップロード・ダウンロードする経路を用意しますが、変更ファイルの自動検出や増分同期、タスクのスケジュール実行、転送中の整合性検証といった機能は持ちません。毎日決まった時刻に差分だけを同期するには、スケジュールと増分判定の仕組みをクライアント側で自前構築する必要があり、運用の手間が増えます。
全体的な説明
問われている要件
- オンプレミスからS3へ約7TBの配送・在庫データを転送する
- 毎日約4%（およそ280GB）ずつ変更されるデータの夜間増分同期
- 転送処理の自動化と毎日決まった時刻でのスケジュール実行
- 運用効率を最大化するソリューションの選択
前提知識
AWS DataSyncについて
AWS DataSyncは、オンプレミスストレージとAWSストレージの間、およびAWSストレージサービス同士の間のデータ移動を簡素化・自動化するマネージドデータ転送サービスです。 NFS、SMB、HDFS、オブジェクトストレージなど様々なソースから、Amazon S3、Amazon EFS、Amazon FSx（Windows File Server、Lustre、OpenZFS、NetApp ONTAP）への転送をサポートします。1回のタスクで大量のデータを転送できます。転送されるデータはTLSで暗号化され、転送後のデータ整合性検証も標準で提供されます。
DataSyncの増分転送機能
DataSyncは、転送の前にソースとデスティネーションの両方のコンテンツとメタデータをスキャンして差分を洗い出し、変更されたデータだけを転送します。 変更の判定に使う属性（更新日時やサイズ、所有権・アクセス許可などのメタデータ）はタスク設定で選択できます。転送後の検証では、ファイルやオブジェクトのチェックサムとメタデータを比較して整合性を確認します。日次の同期タスクでは、変更された約4%のデータのみが転送されるため、ネットワーク帯域幅とコストを抑えられます。
オンプレミスからAWSへのデータ転送オプション
データ転送には複数の選択肢があり、要件に応じてサービスを使い分けます。 DataSyncは継続的な同期と自動化に最適です。AWS Transfer FamilyはSFTP・FTPS・FTP・AS2でファイルを送受信するエンドポイントを提供しますが、増分検出やスケジュール実行はクライアント側の実装が必要です。AWS Snow Familyはネットワーク帯域が限られた環境での大規模なオフライン転送に使います。Direct Connectはネットワーク接続の基盤を提供しますが、転送の自動化は別途必要です。
アーキテクチャ図の解説
アーキテクチャ図
オンプレミスのストレージに置いた配送・在庫データは、DataSyncエージェントを介してS3へ増分同期します。エージェントはソースとデスティネーションの差分を検出し、変更されたファイルだけをTLSで暗号化してDataSyncサービスへ送信します。DataSyncタスクにcron式またはrate式（最短で1時間間隔）でスケジュールを設定しておくと、毎日の同期が人手を介さずに自動実行され、S3への書き込み後には整合性検証が行われます。エージェントをオンプレミス側に1つ配置するだけでこの一連の処理が完結するため、運用負荷が小さく済みます。ここで専用線や単純なアップロード高速化を選ぶと、増分検出とスケジュール実行を自前で組み立てる必要が生じ、毎日更新される大容量データの同期では運用効率が大きく下がります。
解くための考え方
約7TBの初期転送、毎日約4%の増分転送、自動化とスケジュール実行が必要です。AWS DataSyncはこの要件に合致するマネージドサービスです。オンプレミスにエージェントを1つ配置するだけで、増分の検出、転送の実行、整合性の検証が自動化されます。タスクのスケジュールを設定すれば、定期同期が人手を介さずに実行されます。 AWS Transfer FamilyはSFTPなどのプロトコルエンドポイントを提供するだけで、増分検出やスケジュール実行は自前実装が必要です。Direct Connectはネットワーク接続の基盤であり、転送の自動化機能はありません。 S3 Transfer Accelerationは個々のアップロードを高速化しますが、増分の自動検出やスケジュール機能はありません。 DataSyncなら、エージェントを1つ置くだけで増分検出・転送・整合性検証とスケジュール実行まで自動化できます。 参考資料
問題文：
ある保険会社は、オンプレミスのMicrosoft SQL Serverデータベースに約1200万件の保険契約データを保存しています。契約管理チームは毎月末に、解約・更新・新規加入の状況を集計するため、オンプレミスデータベースからAmazon RDS for SQL Serverデータベースへ契約データを移行しています。最近、この月次のデータ移行コストが増加していることに気づきました。 この会社は、コスト効率の良い方法でデータをAWSへ移行する必要があります。あわせて、データベースにアクセスするアプリケーションの停止時間をできるだけ短く抑える必要があります。 これらの要件を満たすために、この会社はどのAWSサービスを使用すべきですか。
選択肢：
A. AWS DataSync
B. AWS DMS
C. AWS Direct Connect
D. AWS Lambda
正解：B
A. AWS DataSync
不正解 DataSyncはオンプレミスとAWSのストレージ間でファイルを転送するサービスで、S3やEFS、FSxなどファイルベースの受け渡しに最適化されています。データベースのテーブルやレコード単位の移行には対応しておらず、SQL Serverのスキーマやデータ型を解釈して処理する機能もありません。契約データをレコード単位で正しく移すには、データベース移行専用のDMSのようなサービスが要ります。
B. AWS DMS
正解 DMSはデータベース移行専用のマネージドサービスです。オンプレミスのSQL ServerからRDS for SQL Serverへの同種間移行に対応し、継続レプリケーションを使えばソースを稼働させたまま移行を進められるため、アプリケーションの停止時間を短く抑えられます。料金は利用したリソース分の従量課金で、月次の契約データ移行でも余計な固定費がかかりません。変更データキャプチャ（CDC）で差分だけを転送できる点も、移行コストの削減につながります。
C. AWS Direct Connect
不正解 Direct ConnectはオンプレミスとAWSを専用線でつなぐネットワーク接続サービスです。安定した帯域と低レイテンシを提供しますが、データベースの中身を移す処理は担いません。抽出・変換・ロードといった移行ロジックは別途自前で組む必要があります。さらに物理的な接続の立ち上げに時間がかかり、月額の固定費用も発生するため、月末のバッチ移行に対しては投資が過剰です。
D. AWS Lambda
不正解 Lambdaはイベントに応じてコードを実行するサーバーレス基盤であり、データベース移行そのものを担うサービスではありません。移行処理を自前で書くことは可能でも、1回の実行は最大15分という上限があるため、1200万件規模の契約データをまとめて移すには不向きです。さらにSQL Server間で必要なスキーマやデータ型の対応、差分の追跡をすべて自前実装することになり、開発と運用の両方で手間が大きく増えます。
全体的な説明
問われている要件
- オンプレミスSQL ServerからAmazon RDS for SQL Serverへ約1200万件の契約データを移行する
- コスト効率の良いソリューション
- データベースを使うアプリケーションの停止時間をできるだけ短く抑える
- 月次の定期的なデータ移行
前提知識
AWS Database Migration Serviceについて
AWS DMSは、データベース移行専用のフルマネージドサービスです。同種間移行（SQL ServerからSQL Server）と異種間移行（OracleからPostgreSQLなど）の両方をサポートしています。 継続的レプリケーション機能により、移行中もソースデータベースを稼働させ続けられ、ダウンタイムを最小化できます。実行基盤はレプリケーションインスタンスを自分でサイズ指定する方式のほか、負荷に応じて容量が自動調整されるDMSサーバーレスも選べ、いずれも使用量に応じた従量課金です。
データ移行方法の選択について
データベース移行では、完全ロード、変更データキャプチャ（CDC）、またはその組み合わせを選択できます。CDCを使用すると、最初の完全ロード後は変更されたデータのみを転送するため、転送量とコストを削減できます。 月次の定期移行であれば、CDC機能を活用して差分データのみを効率的に同期できます。
ネットワーク接続サービスとの違い
AWS Direct Connectはネットワーク層のサービスであり、データ移行ロジックは提供しません。AWS DataSyncはNFS・SMB・HDFS・オブジェクトストレージなどファイル/オブジェクト単位の転送サービスであり、データベースのテーブルやレコードを解釈して移行する用途には対応していません。 データベース移行には、テーブルとデータ型のマッピング、移行タスクの進捗管理、データ検証といった機能が必要であり、これらを提供するのがAWS DMSです。異種間移行で必要になるスキーマ変換についても、DMSスキーマ変換やAWS SCTが用意されています。
アーキテクチャ図の解説
アーキテクチャ図
オンプレミスのSQL ServerからRDS for SQL Serverへの移行は、DMSのレプリケーションインスタンスを中継して段階的に進めます。初回は完全ロード（Full Load）で全契約データをコピーし、その後は変更データキャプチャ（CDC）が変更分だけを検出して継続的に同期します。ソースのSQL Serverは稼働させたまま移行できるため、データベースを使うアプリケーションのダウンタイムを最小限に抑えられます。レプリケーションインスタンスは必要なサイズを選択でき、使用量に応じた従量課金となるため、月次バッチ移行でもコストを抑えられます。専用線やファイル転送サービスを選ぶと、スキーマ変換やレコード単位の同期を自前で実装する必要が生じ、稼働継続とコスト効率を両立できません。
解くための考え方
オンプレミスのSQL ServerからAmazon RDS for SQL Serverへ、コストを抑えつつダウンタイムを最小にして移します。データベース移行に特化したサービスから検討します。AWS Direct Connectはネットワーク接続サービス、AWS DataSyncはファイル転送サービスであり、いずれもデータベース移行の機能を持っていないため除外できます。 AWS Lambdaは汎用的なコンピューティングサービスですが、実行時間に上限があり、1200万件の契約データを移すロジックを自前実装する必要があるため、運用コストと開発工数の観点から適切ではありません。 AWS DMSはデータベース移行に特化したサービスであり、SQL Server間の同種間移行をネイティブにサポートしています。継続的レプリケーション機能によりソースデータベースを稼働させたまま移行できるため、ダウンタイムを最小限に抑えられます。 また、従量課金モデルと変更データキャプチャ機能により、初回の完全ロード以降は差分だけを転送すればよく、実際に使ったリソースと転送量のみに課金されるため、月次移行のコストも抑えられます。 参考資料
問題文：
オンライン小売企業のデータエンジニアが、AWS Glue ETLジョブを使用してAWS上にデータパイプラインを構築しています。このデータエンジニアは、1日あたり約5万件の注文データを保持するAmazon RDS for PostgreSQLと、約30万件の商品レビューを保持するMongoDBからデータを処理し、集計・変換を実行して、変換されたデータを分析用にAmazon Redshiftにロードする必要があります。マーケティング部門が販売傾向をほぼリアルタイムに把握できるよう、データ更新は30分ごとに発生する必要があります。 運用の手間を最小限に抑えてこれらの要件を満たすには、どのタスクの組み合わせが必要ですか。（2つ選択）
選択肢：
A. AWS Glue接続を使用して、データソースとAmazon Redshift間の接続を確立します。
B. Redshift Data APIを使用して、変換されたデータをAmazon Redshiftにロードします。
C. AWS Lambda関数を使用して、ETLジョブを30分ごとにスケジュールおよび実行します。
D. AWS Glue DataBrewを使用して、分析用にデータをクリーニングおよび準備します。
E. AWS Glueトリガーを設定して、ETLジョブを30分ごとに実行します。
正解：A、E
A. AWS Glue接続を使用して、データソースとAmazon Redshift間の接続を確立します。
正解 Glue接続は、複数のデータストアへの接続情報を一箇所で定義してジョブから再利用できる機能です。RDS for PostgreSQL、MongoDB、Redshiftへの接続文字列・認証情報・VPC設定をジョブコードから切り離せるため、接続先の情報が変わってもコードを直さずに済みます。Secrets Managerと連携して認証情報を安全に管理できる点も、運用の簡素化につながります。
B. Redshift Data APIを使用して、変換されたデータをAmazon Redshiftにロードします。
不正解 Redshift Data APIは、接続を維持せずSQLを非同期実行できるAPIで、サーバーレス環境からRedshiftへアクセスする場面で便利です。ただしGlue ETLジョブはAmazon Redshift用のSparkコネクタを標準で備えており、Glue接続を指定するだけでRedshiftへ書き込めます。Data APIを別途呼び出す実装を足すと、処理が増えて運用の手間がかさみます。
C. AWS Lambda関数を使用して、ETLジョブを30分ごとにスケジュールおよび実行します。
不正解 LambdaとEventBridgeを組み合わせてGlueジョブを起動すること自体は可能です。しかしGlueには同じことを実現する組み込みトリガーがあるため、関数のコード・IAMロール・EventBridgeルールという追加の管理対象を作る必要はありません。同等の結果をより少ない部品で得られるGlueトリガーに比べ、運用の手間が増えます。
D. AWS Glue DataBrewを使用して、分析用にデータをクリーニングおよび準備します。
不正解 DataBrewはGUIでデータをクリーニング・整形できるノーコードツールです。ただし処理がすでにGlue ETLジョブとして定義済みのため、DataBrewを重ねて導入すると変換の実装が二重化します。30分ごとの実行にDataBrewを組み込むには追加の連携設定も必要になり、運用の手間を逆に増やします。
E. AWS Glueトリガーを設定して、ETLジョブを30分ごとに実行します。
正解 GlueトリガーはETLジョブの定期実行を宣言的に設定できる組み込み機能です。時間ベースのトリガーを30分間隔で定義すれば、外部のスケジューラや専用スクリプトを追加せずにジョブを自動実行できます。設定はGlueコンソールやAPIから行え、実行履歴やエラー監視もそのままGlue上で一元管理できるため、運用の手間を最小限に抑えられます。
全体的な説明
問われている要件
- Amazon RDS for PostgreSQLの注文データとMongoDBの商品レビューを取得
- データの集計・変換を実行
- Amazon Redshiftへロード
- 30分ごとのデータ更新
- 運用の手間の最小化
前提知識
AWS Glue ETLジョブについて
AWS Glueは、フルマネージドのETLサービスです。Apache Sparkを基盤としており、大規模なデータ処理をサーバーレスで実行できます。 PythonまたはScalaでETLスクリプトを記述し、データカタログで管理されるテーブル定義を使用してデータの抽出、変換、ロードを行います。ジョブの実行に必要なコンピューティングリソースは自動的にプロビジョニングされ、ジョブ完了後に解放されます。
AWS Glueトリガーの仕組み
Glueトリガーには主に3種類あります。スケジュールトリガーはcron式で定期実行を設定でき、条件付きトリガーは他のジョブやクローラーの完了状態（成功・失敗・タイムアウトなど）を検知して実行を開始し、オンデマンドトリガーは手動またはAPI経由で実行します。ワークフロー内であればAmazon EventBridgeのイベントを受けて起動するイベントトリガーも利用できます。 30分ごとの実行であればスケジュールトリガーを使用し、cron(0/30 * * * ? *) のような形式で設定します。Glueのcron式は分・時・日・月・曜日・年の6フィールドで指定します。
AWS Glue接続の役割
Glue接続は、外部データストアへの接続情報をカプセル化するオブジェクトです。JDBC URL、認証情報、VPCサブネット、セキュリティグループなどの設定を保存し、複数のジョブやクローラーで共有できます。 RDS for PostgreSQL、RedshiftなどJDBC互換データベースに加え、MongoDBおよびMongoDB Atlas用の組み込み接続タイプも用意されており、専用コネクタを別途導入せずに接続できます。認証情報はAWS Secrets Managerのシークレットを参照する形で保持でき、コンソールの接続テスト機能で設定の正確性を事前に検証できます。
アーキテクチャ図の解説
アーキテクチャ図
RDS for PostgreSQLとMongoDBからデータを抽出し、集計・変換してRedshiftへロードします。Glue Triggerが30分ごとのスケジュール実行を担い、Glue Connectionが各データソースへの接続情報（JDBC URL・認証情報・VPC設定）を一元管理します。Glue ETLジョブはApache Sparkベースでサーバーレスに動作し、注文データと商品レビューを集計・変換して分析用の形へ整えます。接続情報をGlue Connectionへ集約しておくと、認証情報が変わってもジョブコードを修正する必要がなく、パイプラインの維持コストが下がります。スケジューリングをLambdaとEventBridgeで自前実装したり、DataBrewやRedshift Data APIを追加したりすると、同じ処理を実現するのに管理対象が増えて運用オーバーヘッドが逆に高まります。
解くための考え方
スケジューリングと接続管理は、自前実装を増やさずに済ませます。まずスケジューリングでは、Glueに組み込まれたトリガーを使えば、ジョブの定期実行を宣言的な設定だけで実現できます。一方、LambdaとEventBridgeを組み合わせてトリガーする案は、関数のコードやIAMロール、ルールの管理が増え、同じ結果を得るのに管理対象が膨らみます。 次に接続管理では、Glue接続を使えばRDS for PostgreSQL、MongoDB、Redshiftへの接続情報（JDBC URL・認証情報・VPC設定）を一箇所に集約でき、認証情報が変わってもジョブコードの修正が不要になります。DataBrewによる追加のデータ準備やRedshift Data APIによるロードは、ETLジョブがすでに処理を担う前提では二重の実装となり、運用オーバーヘッドを増やします。 参考資料
問題文：
ある企業は、約200台のセンサーから得られるログデータを対象に、Apache Sparkジョブを実行するプロビジョニング済みのAmazon EMRクラスターの導入を計画しています。1日あたり約50TBのログが蓄積され、データ分析チームはこれを数か月単位で保持しながら継続的に分析します。チームには、長時間にわたって継続実行するワークロードを高い信頼性のもとで処理しつつ、ランニングコストを抑えることが求められています。あわせて、現行の分析基盤と同等の処理性能を維持することも条件です。 これらの要件を最もコスト効率よく満たすリソースの組み合わせはどれですか。（2つ選択）
選択肢：
A. データを恒久的に保持するストアとして、クラスターとは独立したAmazon S3を使用します。
B. プライマリノードの購入タイプを、すべてスポットインスタンスに指定します。
C. コアノードとタスクノードに、Gravitonプロセッサ搭載のインスタンスタイプを使用します。
D. データを恒久的に保持するストアとして、クラスター内のHDFS（Hadoop Distributed File System）を使用します。
E. コアノードとタスクノードに、x86アーキテクチャのインスタンスタイプを使用します。
正解：A、C
A. データを恒久的に保持するストアとして、クラスターとは独立したAmazon S3を使用します。
正解 S3は99.999999999%（イレブンナイン）の耐久性を持ち、EMRクラスターの稼働とは独立してデータを保持します。EMRFS経由のアクセスが最適化されており、クラスターを止めてもデータは残ります。容量がほぼ無制限なので、日々増えるログを長期間ため続けても追随できます。
B. プライマリノードの購入タイプを、すべてスポットインスタンスに指定します。
不正解 プライマリノードにスポットインスタンスを指定すること自体は可能ですが、プライマリノードはクラスター管理とHDFSのNameNodeを担うため、容量回収で中断されるとクラスター全体が停止します。長時間実行するワークロードを高い信頼性で動かすという条件がある以上、プライマリノードはオンデマンド（必要ならマルチプライマリ構成）にすべきです。
C. コアノードとタスクノードに、Gravitonプロセッサ搭載のインスタンスタイプを使用します。
正解 m6g・c6g・r6g（Graviton2）やm7g・c7g・r7g（Graviton3）といったGravitonインスタンスでは、EMRのSparkワークロードにおいて同等のx86系と比べて最大30%のコスト削減と最大15%の性能向上がAWSから示されています。Armアーキテクチャの高い電力効率により同じ処理をより安く実行でき、処理性能を落とさずにランニングコストを下げられます。
D. データを恒久的に保持するストアとして、クラスター内のHDFS（Hadoop Distributed File System）を使用します。
不正解 EMRのHDFSはコアノードに紐づくインスタンスストアやEBSボリューム上に構築され、これらのボリュームはクラスター終了時にインスタンスとともに削除されるため、保持していたデータも同時に失われます。1日約50TBのログを数か月保持するという要件に対しては、ノードを増設し続けない限り容量も不足します。永続性・可用性・拡張性のいずれの面でも長期保管用のデータストアには適しません。
E. コアノードとタスクノードに、x86アーキテクチャのインスタンスタイプを使用します。
不正解 x86系（Intel／AMD）でも処理自体は問題なく動きますが、EMRのSparkワークロードではGraviton搭載インスタンスを選んだ場合と比べて最大30%割高になり、性能面でも優位はありません。同等の処理性能を保ちながらランニングコストを抑えるという要件に対して、あえてx86を選ぶ理由がないため不適切です。
全体的な説明
問われている要件
- Amazon EMR上でApache Sparkによるログデータの大規模分析を行う
- 約200台のセンサーから集まる1日約50TBのログを数か月単位で保持しながら分析する
- 長時間実行するワークロードを高い信頼性で運用する
- ランニングコストを抑えつつ現行と同等の処理性能を維持する
前提知識
Amazon EMRのストレージ選択
EMRで使えるストレージは、HDFS、EMRFS（S3）、ローカルファイルシステムの3種類です。HDFSはクラスターのインスタンスストレージを使うため、終了時にデータが消えます。一方、EMRFSはS3をHDFS互換のファイルシステムとして扱い、クラスターとは独立した永続ストレージとして推奨されます。
AWS Gravitonプロセッサの特徴
GravitonはAWSが設計したArmベースのプロセッサです。EMRのSparkワークロードでは、Graviton2ベースのインスタンスによって同等のx86系と比べ最大30%のコスト削減と最大15%の性能向上が得られるとAWSが公表しています。後継のGraviton3はGraviton2比でさらに高速で、EMR on EKSのSparkベンチマークでは最大19%の性能向上が報告されています。EMRはm6g・c6g・r6g（Graviton2）に加え、c7gなどGraviton3世代のインスタンスタイプもサポートしています。
EMRのノード構成
EMRクラスターはプライマリ・コア・タスクの3種類のノードで構成されます。プライマリノードは管理とタスクの割り当て、コアノードはHDFSデータの保持とタスク実行、タスクノードはタスク実行のみを担います。プライマリノードの障害はクラスター全体に波及するため、可用性の確保が重要です。長時間稼働するクラスターでは、プライマリノードを3台構成にするマルチプライマリ（高可用性）オプションも利用できます。
スポットインスタンスの使いどころ
スポットインスタンスはオンデマンド料金より最大90%安価ですが、AWSが容量を回収する際に中断されます。タスクノードでの利用は推奨されますが、プライマリノードやデータを保持するコアノードに適用すると、高い信頼性が求められる場面ではリスクになります。
アーキテクチャ図の解説
アーキテクチャ図
計算を担うクラスターとデータの置き場所を分離します。プライマリノードはクラスター全体の管理という単一障害点を握るため、中断されると全ノードに波及するスポットではなくオンデマンドインスタンスを割り当てます。コアノードとタスクノードにはGravitonインスタンスを使い、計算コストを抑えつつ処理性能を保ちます。データはインスタンス上のHDFSへ置かず、EMRFSを介してAmazon S3に読み書きするため、クラスターを終了しても失われません。ここで管理とデータ保持を同じノードに担わせたままコアノードまでスポット化すると、中断時に処理だけでなく保持中のデータまで同時に失う恐れがあります。
解くための考え方
コストを抑えつつ信頼性も確保します。長期間稼働するワークロードでは、クラスターの寿命とデータの寿命を切り離すことが大切です。HDFSはクラスターに紐づくため終了とともに失われますが、Amazon S3なら耐久性・可用性・拡張性を備えた永続ストレージとして機能します。次にコンピューティングを見ると、Graviton搭載インスタンスはEMRのSparkワークロードで同等のx86系と比べて最大30%のコスト削減と最大15%の性能向上が得られるため、コストと性能の両方を満たします。最後に購入タイプです。スポットインスタンスは安価ですが、プライマリノードに使うと中断時にクラスター全体が巻き添えになります。信頼性が要件にある以上、プライマリノードのスポット化は避けるべきです。永続ストレージにS3を使い、コアノードとタスクノードにGravitonインスタンスを使う組み合わせが、コストと信頼性を両立します。 参考資料
問題文：
ある鉄道会社のデータエンジニアは、Amazon Athenaを使用してAmazon S3にある予約・運賃データを分析しています。収益分析チームが路線ごとの年間運賃収入を比較するため、データエンジニアは数百万件の予約レコードを保持するbooking_dataテーブルから集計クエリを作成しています。booking_dataテーブルは以下の構造を持っています。
CREATE EXTERNAL TABLE booking_data ( route_name STRING, fare_amount DOUBLE, booking_date DATE ) STORED AS PARQUET LOCATION ‘s3://transit-bucket/booking-data/’;
データエンジニアは、booking_dataテーブルから複数の路線の2023年の運賃額を取得するクエリを作成しました。しかし、以下のクエリはエラーを返し、結果を取得できません。
SELECT route_name, sum(fare_amount) FROM booking_data WHERE year = 2023 GROUP BY route_name
データエンジニアはこれらの要件を満たすためにAthenaクエリをどのように修正すべきですか。
選択肢：
A. GROUP BY 句の後ろに HAVING sum(fare_amount) > 0 を追加して、運賃合計が0より大きい路線だけに絞り込むようにします。
B. GROUP BY 句を削除して、全レコードを1つに集約した運賃合計だけを返すように変更します。
C. 集計関数を sum(fare_amount) から count(*) に変更して、運賃ではなく行数を数えるようにします。
D. WHERE year = 2023 を WHERE EXTRACT(year FROM booking_date) = 2023 に変更します。
正解：D
A. GROUP BY 句の後ろに HAVING sum(fare_amount) > 0 を追加して、運賃合計が0より大きい路線だけに絞り込むようにします。
不正解 HAVING句はGROUP BYによる集計が終わった後の結果行を絞り込むための構文であり、運賃合計が0を超える路線だけに限定する条件を足しても、WHERE句が参照している列名そのものは変わりません。Athenaは実行前の解析段階でテーブル定義に無い列を検出し、列を解決できないというCOLUMN_NOT_FOUNDのエラーでクエリを失敗させるため、集計後の絞り込みを追加しても結果は得られません。
B. GROUP BY 句を削除して、全レコードを1つに集約した運賃合計だけを返すように変更します。
不正解 GROUP BY句を外すと集計の単位が失われ、全レコードの運賃額を合計した1行だけが返るため、路線ごとの年間運賃収入を比較したいという要件を満たせなくなります。さらに、WHERE句が参照している列名は変わらないままなので、テーブル定義に存在しない列を解決できないというAthenaのエラーも残り、クエリは実行前の解析段階で失敗し続けます。
C. 集計関数を sum(fare_amount) から count(*) に変更して、運賃ではなく行数を数えるようにします。
不正解 集計関数を`count(*)`に変えると、運賃額の合計ではなく予約レコードの行数を数えることになり、クエリの目的自体が変わってしまいます。路線ごとの運賃額合計という要件を満たせないうえ、存在しない列の参照エラーも残ったままです。集計方法の変更は、このフィルタリングの問題とは無関係です。
D. WHERE year = 2023 を WHERE EXTRACT(year FROM booking_date) = 2023 に変更します。
正解 元のクエリは「year」という名前の列を参照していますが、テーブル定義にその列はなく、日付情報は「booking_date」列に格納されています。この列から年の部分を取り出すには、EXTRACT(year FROM booking_date)のようにEXTRACT関数を使います。これで2023年のレコードだけが正しく絞り込まれ、路線ごとの運賃額合計が得られます。
全体的な説明
問われている要件
- Amazon Athenaでの予約・運賃データ分析クエリのトラブルシューティング
- 収益分析チームによる2023年の複数路線の運賃額の取得
- 存在しないカラムを参照しているクエリエラーの修正
- 日付型カラムから年を抽出する正しいフィルタリング条件の適用
前提知識
Amazon Athenaのクエリについて
Amazon Athenaは、S3に保存されたデータに対してSQLクエリを実行できるサーバーレスのインタラクティブクエリサービスです。 現行のAthenaエンジンバージョン3はTrino（エンジンバージョン2まではPresto）をベースとしており、標準的なANSI SQLと多くの組み込み関数をサポートしています。 データのスキーマはAWS Glue Data Catalogで管理され、テーブル定義に基づいてクエリが実行されます。
日付・時刻関数について
EXTRACT関数は、日付や時刻の値から特定の部分（年、月、日など）を抽出するSQL標準関数です。 構文はEXTRACT(部分 FROM 日付カラム)で、例えばEXTRACT(year FROM booking_date)はbooking_dateカラムから年を取得します。 日付型カラムに対して年でフィルタリングする場合、直接「year」という名前のカラムが存在しない限り、EXTRACT関数を使用する必要があります。Athenaでは同じ処理をyear(booking_date)という短縮形の関数でも記述できます。なお、カラムに関数を適用した条件はパーティションの絞り込み（プルーニング）が効かないため、日付でのフィルタが頻繁な大規模テーブルでは年や月をパーティションキーとして設計しておくとスキャン量を減らせます。
SQLのWHERE句とGROUP BY句について
WHERE句はデータ取得前にレコードをフィルタリングし、GROUP BY句は結果を指定したカラムでグループ化します。 WHERE句で参照するカラム名は、実際にテーブルに存在するカラム名と一致している必要があります。 存在しないカラム名を指定した場合、Athenaはエラーを返し、クエリの実行が失敗します。 テーブルスキーマを正確に理解し、適切なカラム名を使用することがクエリ作成の基本です。
解くための考え方
元のクエリでは「WHERE year = 2023」という条件を使用していますが、これは「year」という名前のカラムが存在することを前提としています。 問題文で提示されたテーブル定義を確認すると、booking_dataテーブルには以下のカラムが定義されています：
- route_name (STRING型)
- fare_amount (DOUBLE型)
- booking_date (DATE型)
つまり、「year」という独立したカラムは存在せず、日付情報は「booking_date」カラムに格納されています。 存在しないカラム「year」を参照しているため、クエリはエラーを返します。 EXTRACT関数を使用してbooking_dateカラムから年の部分を抽出します。 正しい構文は「EXTRACT(year FROM booking_date) = 2023」となります。 これにより、booking_dateカラムを持つすべてのレコードに対して正しく2023年のフィルタリングが適用され、すべての路線について2023年の運賃データが正しく集計されます。 他の選択肢について：
- count(*) への変更は集計の目的を変えてしまい、運賃額の合計という要件を満たしません。
- HAVING句の追加はyearカラムが存在しないという根本的な問題を解決せず、クエリはエラーのままです。
- GROUP BY句の削除は路線別の集計ができなくなるため、複数路線の運賃額を取得するという要件を満たしません。
EXTRACT関数でbooking_dateから年を取り出せば、存在しない year カラムを参照するエラーが解消されます。 参考資料
問題文：
あるオンラインゲーム会社は、プレイヤーのゲームプレイログを格納するAmazon Redshiftプロビジョンドクラスターを運用しています。1日あたり約8000万レコードのプレイログが追加され、分析チームは毎朝、前日のプレイヤー行動を集計したKPIを確認しています。Redshiftクラスターには5つの予約済みra3.4xlargeノードがあり、キー分散を使用しています。 データエンジニアは、ノードの1つで頻繁にCPU負荷が90%を超えていることに気づきました。そのノードで実行されるSQLクエリはキューに入れられています。他の4つのノードは通常、日常の運用中にCPU負荷が15%未満です。 データエンジニアは現在のコンピュートノード数を維持したいと考えています。また、データエンジニアは5つすべてのコンピュートノード間で負荷をより均等に分散させたいと考えています。 これらの要件を満たすソリューションはどれですか。
選択肢：
A. 予約ノードのインスタンスタイプをra3.4xlargeからra3.16xlargeにアップグレードします。
B. 分散キーを、カーディナリティ（一意の値の数）が最も大きいテーブル列に変更します。
C. ソートキーを、SQLのSELECT文のWHERE句で最もよく使われるデータ列に変更します。
D. プライマリキーを、SQLのSELECT文のWHERE句で最もよく使われるデータ列に変更します。
正解：B
A. 予約ノードのインスタンスタイプをra3.4xlargeからra3.16xlargeにアップグレードします。
不正解 ra3.16xlargeへ大型化すればノードあたりのvCPUとメモリは増えますが、行がどのノードへ置かれるかは分散キーの値のハッシュで決まるため、キーの値が偏っている限り同じ行が同じ配置先へ集まり続け、特定ノードへの集中は再発します。処理能力を増やして症状を薄めるだけの対処であり、データの偏りという根本原因は残ったまま、コストだけが大きく増えます。
B. 分散キーを、カーディナリティ（一意の値の数）が最も大きいテーブル列に変更します。
正解 キー分散では分散キーの値をハッシュして行の配置先を決めます。一意の値が少ない列を選ぶと特定ノードへ行が偏りますが、カーディナリティ（一意の値の数）が大きい列を選べば行がノード間へ均等に散らばり、クエリ時の負荷も平準化されます。これがノード数を変えずに負荷集中を解消する方法です。
C. ソートキーを、SQLのSELECT文のWHERE句で最もよく使われるデータ列に変更します。
不正解 ソートキーが決めるのはスライス内でのデータの物理的な並び順で、ブロックごとに最小値と最大値を記録したゾーンマップにより不要なブロックを読み飛ばせるようになります。効果はスキャン量の削減であって、行をどのノードやスライスへ置くかを決めるのは分散スタイルと分散キーです。WHERE句で多用する列へ変えても配置は変わらず、1ノードへの負荷集中は残ります。
D. プライマリキーを、SQLのSELECT文のWHERE句で最もよく使われるデータ列に変更します。
不正解 Redshiftのプライマリキーは参照整合性のヒントにすぎず、強制もされないため、データの分散やソートには影響を与えません。WHERE句で多用される列に変更しても行の配置先は変わらず、負荷の偏りは解消されません。分散スタイルと分散キーの見直しこそが本質的な対処です。
全体的な説明
問われている要件
- 現在のコンピュートノード数（5ノード）の維持
- 5つのノード間での負荷の均等な分散
- 1つのノードでのCPU負荷集中（90%超）の解消
- 他のノードの低稼働（15%未満）の改善
前提知識
Amazon Redshiftの分散スタイルについて
Redshiftには4つの分散スタイルがあります。AUTO（既定。テーブルのサイズに応じてRedshiftが最適なスタイルを自動選択）、EVEN（ラウンドロビンで均等分散）、KEY（指定列の値でハッシュ分散）、ALL（すべてのノードにコピー）です。 キー分散では、分散キーの値に基づいてハッシュ関数が適用され、同じ値を持つ行は同じノードスライスに配置されます。これはジョイン時のデータ移動を最小化できますが、分散キーの選択が重要です。
分散キーの選択基準
分散キーには高いカーディナリティ（多くの一意の値）を持つ列を選択することが推奨されます。カーディナリティが低い列（少数の一意の値しかない列）を選択すると、特定のノードにデータが偏るスキュー（データの偏り）が発生します。 理想的な分散キーは、値が均等に分布し、頻繁にジョインに使われる列です。ゲームタイトルのように値の種類が少ない列ではなく、セッションIDのように値が広く分布する列が適しています。偏りが起きているかどうかはSVV_TABLE_INFOビューのskew_rows列などで確認でき、分散スタイルや分散キーはALTER TABLEのALTER DISTSTYLE／ALTER DISTKEYで既存テーブルのまま変更できます。適切なキーが見つからない場合はEVENやAUTOに切り替える判断もあります。
ソートキーと分散キーの違い
ソートキーはディスク上のデータの物理的な並び順を制御し、範囲スキャンの性能を高めます。一方、分散キーはデータがどのノードに配置されるかを決定します。 ソートキーの変更はノード間の負荷分散には影響せず、分散キーの変更がノード間の負荷分散に直接影響します。
アーキテクチャ図の解説
アーキテクチャ図
分散キーに低カーディナリティの列（ゲームタイトル列）を選ぶと、データスキューが起きます。キー分散では分散キーの値にハッシュを適用して行の配置先を決めるため、値の種類が少ない列を選ぶと、特定のゲームタイトルに紐づく大量の行が同じノードへ偏ります。ゲームタイトルは高々数十種類しかなく、人気タイトルには特に多くのプレイログが集中するため、偏りが顕著になります。その結果、1つのノードだけCPU負荷が90%を超えてクエリがキューに入り、残り4ノードは15%未満で遊んでいるという不均衡が生じます。ソートキーやプライマリキーを変更しても行の配置先は変わらないため、この症状は解消されません。負荷の偏りの根本原因はノード性能ではなく分散キーの選び方にあると見抜くことが出発点です。
アーキテクチャ図
分散キーを高カーディナリティの列（セッションID列）へ変更すると、負荷が均等になります。セッションIDのように値が広く分布する列を選ぶと、ハッシュによって行がノード間へ統計的に均等に散らばり、5つのノードすべてがほぼ同じCPU負荷（約20%）で動作するようになります。セッションIDはプレイごとに一意な値を持つため、ハッシュの出力が幅広く散らばり、特定ノードへの集中が起きにくくなります。この変更はノード数を増やしたりインスタンスを大型化したりせず、分散キーを見直すだけで実現できる点が重要です。ノードをアップグレードしても、値の偏りが残る限り過負荷ノードへの集中は再発します。分散キーのカーディナリティを高めることが、ノード間の負荷均等化に対する本質的な対処です。
解くための考え方
Redshiftクラスターで1つのノードに負荷が集中し、他のノードが低稼働です。これはデータスキュー（偏り）の症状です。現在キー分散を使用していることが問題文に記載されており、分散キーの選択が不適切です。 まず、ソートキーとプライマリキーの変更を検討します。ソートキーはデータの物理的な並び順を制御しますが、どのノードにデータが配置されるかには影響しません。 プライマリキーはRedshiftでは参照整合性のヒントとして使われますが、強制されず、データ分散にも影響しません。これらの変更では負荷の不均衡は解消されません。 ノードのアップグレードは、過負荷のノードの処理能力を増やしますが、データ分散の偏りという根本原因を解決しません。 また、要件では現在のノード数を維持することが求められており、アップグレードは不要なコスト増加につながります。 分散キーをより高いカーディナリティを持つ列に変更することで、データがハッシュ関数によってより均等にノード間へ分散されます。 これにより、特定のノードへのデータ集中が解消され、クエリ実行時の負荷も5つのノード間で均等に分散されます。分散キーを適切に選べば、ノード間の負荷は均等になります。 参考資料
問題文：
ある企業は、約100万台のIoTデバイスが送信するJSON形式のデータをAmazon S3バケットに保存しています。デバイスは1日あたり約2億件のテレメトリを送信します。同社は四半期ごとにデバイスのファームウェアをアップグレードするため、そのたびにデータ構造が変わる場合があります。同社はこのIoTデータを含むデータカタログを作成し、データサイエンスチームが利用状況の分析や故障予兆の検知に使えるよう、分析用にAmazon Redshiftへ取り込む予定です。 この要件を最もコスト効率よく満たすソリューションはどれですか。
選択肢：
A. AWS Glue Data CatalogとSchema Registryを用意し、取り込み処理をAmazon Redshift Data APIを呼ぶAWS Lambdaユーザー定義関数（UDF）とAWS Step Functionsのワークフローで組み立てて、Redshift Serverlessへロードします。
B. AWS Glue Data Catalogでテーブルを管理し、AWS Glue Schema Registryでスキーマのバージョンを追跡します。AWS Glueワークロードでデータの取り込みをオーケストレーションし、Amazon Redshift Serverlessへロードします。
C. Amazon Redshiftプロビジョニング済みクラスターを立ち上げ、S3のデータを直接クエリするAmazon Redshift Spectrumの外部スキーマを作成し、ストアドプロシージャでデータをRedshiftへロードします。
D. Amazon Athenaのワークグループを用意し、AthenaでApache Sparkを使ってS3のデータを探索します。ワークグループ配下のスキーマとテーブルを分析部門に提供します。
正解：B
A. AWS Glue Data CatalogとSchema Registryを用意し、取り込み処理をAmazon Redshift Data APIを呼ぶAWS Lambdaユーザー定義関数（UDF）とAWS Step Functionsのワークフローで組み立てて、Redshift Serverlessへロードします。
不正解 この案はAWS Glue Data CatalogとSchema Registryを使っており、メタデータ管理とスキーマ進化の追跡という要件は満たしています。しかし、Amazon RedshiftのLambda UDFはSQLクエリの中から呼び出されるスカラー関数を実装するための仕組みであり、データ取り込みのオーケストレーションを担う用途には向いていません。加えてLambda関数のコード作成・管理やStep Functionsのワークフロー定義といった追加の開発・運用作業も発生します。AWS Glue自体がジョブのスケジューリングとワークフローによるETLオーケストレーション機能を備えているため、別途Step Functionsを組み合わせる必然性は低く、開発工数の分だけコスト効率でも劣ります。
B. AWS Glue Data Catalogでテーブルを管理し、AWS Glue Schema Registryでスキーマのバージョンを追跡します。AWS Glueワークロードでデータの取り込みをオーケストレーションし、Amazon Redshift Serverlessへロードします。
正解 AWS Glue Data CatalogはAWSのマネージドメタデータリポジトリサービスで、データのスキーマやテーブル定義を一元管理できます。AWS Glue Schema Registryはスキーマのバージョン管理と進化を自動的に追跡する機能を提供し、IoTデバイスのアップグレードによるデータ構造の変更に柔軟に対応できます。AWS Glueはサーバーレスのデータ統合サービスで、ETLジョブの作成と実行が容易です。Amazon Redshift Serverlessは使用量に応じた課金モデルで、プロビジョニング済みクラスターよりコスト効率に優れています。この構成はすべてサーバーレスまたはマネージドサービスで組まれており、運用負荷が低くコスト効率が高いソリューションです。
C. Amazon Redshiftプロビジョニング済みクラスターを立ち上げ、S3のデータを直接クエリするAmazon Redshift Spectrumの外部スキーマを作成し、ストアドプロシージャでデータをRedshiftへロードします。
不正解 Amazon Redshiftプロビジョニング済みクラスターはノードが常時稼働するため固定費用が発生し、使用量に応じたスケーリングができません。データカタログの作成という要件に対して、Redshift Spectrumの外部スキーマはGlue Data Catalogなどのメタストアを参照してS3上のデータをクエリする仕組みであり、Spectrum自体がスキーマのバージョン管理や進化の追跡を行うわけではありません。また、プロビジョニング済みクラスターの管理、ストアドプロシージャの開発・保守など運用負荷が高くなります。スキーマの変更への柔軟性もAWS Glue Schema Registryと比べて劣ります。コスト効率の観点で、サーバーレス構成と比べて不利です。
D. Amazon Athenaのワークグループを用意し、AthenaでApache Sparkを使ってS3のデータを探索します。ワークグループ配下のスキーマとテーブルを分析部門に提供します。
不正解 Amazon AthenaはS3上のデータに対するサーバーレスクエリサービスとして優れていますが、この案はデータカタログの作成という主要な要件に直接対応していません。Athenaワークグループはクエリの実行環境を管理するもので、メタデータリポジトリとしての機能は持っていません。Apache Sparkによるデータ探索は分析には有用ですが、スキーマの進化を追跡して管理する機能が欠けています。IoTデバイスのアップグレードに伴うデータ構造の変更を体系的に管理するには、AWS Glue Schema Registryのような専用のスキーマ管理機能が必要です。
全体的な説明
問われている要件
- JSON形式のIoTデータをS3に保存している
- 四半期ごとのファームウェア更新によりデータ構造が変更される可能性がある
- データカタログを作成してデータをインデックス化したい
- データサイエンスチームがデータカタログとRedshiftを利用する
- 最もコスト効率の良いソリューションが求められている
前提知識
AWS Glue Data Catalogについて
AWS Glue Data Catalogは、AWSのマネージドメタデータリポジトリサービスです。 テーブル定義、スキーマ情報、パーティション情報などのメタデータを一元管理でき、Amazon Athena、Amazon Redshift Spectrum、Amazon EMRなど複数のAWSサービスと統合されています。 Apache Hive Metastoreと互換性があり、既存のHiveベースのワークロードからの移行も容易です。
AWS Glue Schema Registryの特徴
AWS Glue Schema RegistryはApache Avro、JSON Schema、Protocol Buffersなどのスキーマを管理するサービスです。 スキーマのバージョン管理、互換性チェック、スキーマ進化の追跡機能を提供します。 IoTデータのようにデータ構造が変更される可能性がある場合に、スキーマの変更を体系的に管理できます。 リージョンごとに最大10000のスキーマバージョンを保持できます。
Amazon Redshift Serverlessの特徴
Amazon Redshift Serverlessは、データウェアハウスのコンピューティングリソースを自動的にプロビジョニング・スケーリングするサービスです。 使用したコンピューティング容量に対してのみ課金されるため、断続的なワークロードではプロビジョニング済みクラスターより大幅にコストを削減できます。 クラスター管理の運用負荷がなく、即座にクエリを実行開始できます。
AWS Glueの統合機能
AWS Glueはサーバーレスのデータ統合サービスで、ETLジョブの作成、スケジューリング、モニタリングを統合的に管理できます。 Data CatalogとSchema Registryが同一サービス内で連携するため、メタデータ管理とデータ処理のワークフローをそのままつなぎます。
アーキテクチャ図の解説
アーキテクチャ図
IoTデバイスが送るJSONデータは、カタログ管理・スキーマ管理・取り込み・分析までサーバーレスのサービスだけで一貫して処理します。デバイスはデータをS3へ送り、Glue Schema Registryがスキーマを登録してGlue Data Catalogへ連携します。Glue Workflowがカタログのテーブル定義を参照してデータをRedshift Serverlessへロードし、分析部門はそのデータをクエリしてインデックス化します。すべてマネージドまたはサーバーレスで構成されるため、使用量に応じた課金で済みます。プロビジョニング済みクラスターや独自のLambda・Step Functionsを組み合わせる構成は、固定費や開発工数が増えるため、コスト効率で劣ります。
アーキテクチャ図
デバイスのアップグレードでデータ構造が変わっても、Schema Registryがバージョン履歴を保持して互換性を自動検証します。Schema v1からフィールドが追加されたv2、さらに構造が変わったv3まで、各バージョンが順に登録され、互換性チェックを経てGlue Data Catalogへ最新のスキーマが反映されます。リージョンごとに最大10000のスキーマバージョンを保持できるため、変更を体系的に管理できます。分析部門は常に最新のスキーマ情報を参照してデータをクエリできます。スキーマ進化を追跡する仕組みを持たない構成では、構造変更のたびに手動でテーブル定義を直す必要が生じ、カタログの信頼性が損なわれます。
解くための考え方
IoTデータのデータカタログ作成とスキーマ変更への対応を、コスト効率よく実現します。データカタログの作成、スキーマ変更への柔軟な対応、コスト効率の3点が重要です。 データカタログの作成にはAWS Glue Data Catalogが最も適しており、これはAWSのデータ分析サービスと広く統合されたマネージドサービスです。 スキーマ変更への対応については、AWS Glue Schema Registryがスキーマのバージョン管理と進化を自動追跡する機能を提供しています。 IoTデバイスのアップグレードによるデータ構造変更という状況に対して、この機能は非常に適しています。 コスト効率の観点では、サーバーレスサービスの組み合わせが最も有利です。 プロビジョニング済みのRedshiftクラスターは固定費用が発生するため、Redshift Serverlessの方がコスト効率に優れています。 各構成を比べると、AWS Glue Data Catalog、Schema Registry、Glueワークロード、Redshift Serverlessで組む案は、すべてサーバーレス・マネージドのコンポーネントで構成されています。 一方、Lambda UDFとStep Functionsを使う案は、同等の機能を実現するために追加のコンポーネントと開発工数が必要となり、コスト効率が劣ります。 Redshiftプロビジョニング済みクラスターの案は固定費用の観点で不利であり、Athenaワークグループの案はデータカタログ機能が不足しています。 参考資料
問題文：
ある物流会社が、各営業所の配送実績に関するメトリクスを分析のために収集しています。運行管理チームは、配送の定時達成率を高めるためのインサイトを得られるかどうかを、小規模な検証で確認しようとしています。 検証では、1日あたり約30万件の配送記録を .csv 形式で含む Amazon S3 のオブジェクトを使用し、Amazon Athena でデータをクエリします。データは配送日で S3 バケット内をパーティション分割しており、数か月で数十TBまで増える見込みです。 データ量が増えるにつれて、会社はクエリの応答速度を上げるためにストレージ構成を最適化したいと考えています。 この要件を満たすソリューションの組み合わせはどれですか。（2つ選択）
選択肢：
A. クエリに必要な列だけを読み込めるように、.csv データを Apache Parquet 形式に前処理します。
B. Amazon Athena でクエリするのと同じ AWS アカウント内にある S3 バケットを使用します。
C. Amazon Athena のクエリを実行するのと同じ AWS リージョン内にある S3 バケットを使用します。
D. パーティション全体のスループットを高めるために、Amazon S3 のオブジェクトキーの先頭にランダムな文字列を付与します。
E. クエリに必要な列だけを取得するために、.csv データを JSON 形式に前処理します。
正解：A、C
A. クエリに必要な列だけを読み込めるように、.csv データを Apache Parquet 形式に前処理します。
正解 Parquetは列指向のフォーマットで、Athenaのクエリ性能を大きく改善します。必要な列だけを選択的に読み込めるため不要な列のスキャンを省け、実行時間とコストが下がります。圧縮効率も高くCSV比で容量を50〜75%削減できることがあり、行グループのメタデータによるプッシュダウンでWHERE句に合わないブロックを読み込み前に除外できます。Athenaはスキャン量課金なので、Parquet化はコスト削減にも直結します。
B. Amazon Athena でクエリするのと同じ AWS アカウント内にある S3 バケットを使用します。
不正解 バケットとAthenaが同一アカウントかどうかは、性能には直接効きません。IAMポリシーとバケットポリシーを正しく設定すれば、別アカウントのS3データにもAthenaからアクセスできます。性能に効くのはアカウントではなくリージョンの一致です。アカウントの一致は管理や権限の話であり、応答速度とは無関係です。
C. Amazon Athena のクエリを実行するのと同じ AWS リージョン内にある S3 バケットを使用します。
正解 AthenaとS3バケットを同一リージョンに置くのは、クエリ性能の最適化では基本です。リージョン内の転送は低レイテンシで完了するため応答が速く、リージョンをまたぐとネットワーク遅延と転送コストが加わります。処理サービスとストレージを同じリージョンへ揃えるのはAWSのベストプラクティスで、性能とコストの両方に効きます。
D. パーティション全体のスループットを高めるために、Amazon S3 のオブジェクトキーの先頭にランダムな文字列を付与します。
不正解 キー先頭へランダム文字列を足すのは、過去に推奨された古いS3最適化です。現在のS3はプレフィックスごとに毎秒3,500件の書き込みと5,500件の読み取りを処理でき、多くのワークロードでこの手法は不要です。むしろキーの先頭が変わることで配送日によるパーティションプルーニングが効かなくなり、Athenaの性能を下げるおそれがあります。
E. クエリに必要な列だけを取得するために、.csv データを JSON 形式に前処理します。
不正解 CSVをJSONへ変換しても、性能面の改善はほぼありません。JSONも行指向のテキスト形式なので、一部の列しか使わないクエリでも行全体を読み込みます。応答速度を上げるにはParquetやORCのような列指向フォーマットへの変換が有効で、JSONはファイルサイズの増加やパース処理の負担でかえって遅くなるおそれがあります。
全体的な説明
問われている要件
- 1日約30万件の配送実績メトリクスを CSV で S3 に保存している
- Athena でデータをクエリしている
- データは配送日でパーティション分割されている
- 数か月で数十TBまで増えるデータに対してクエリ性能を高めたい
- ストレージ構成を最適化したい
前提知識
Amazon Athena の性能最適化の要素
Athena のクエリ性能は、データフォーマット、圧縮、パーティショニング、リージョンの配置など複数の要素に影響されます。 Athena はスキャンしたデータ量で課金されるため、性能最適化はコスト最適化と直結します。効率的なクエリには、これらの要素を総合的に整える必要があります。
列指向フォーマットの利点
Apache Parquet と Apache ORC は、分析クエリ向けの列指向ストレージフォーマットです。 データを列単位で格納するため、特定の列だけを効率的に読み込めます。たとえば 100 列のテーブルから 5 列だけを選ぶクエリでは、約 95% のスキャンを回避できます。 同じ列の値がまとまることで圧縮効率も高まり、Parquet は行グループ単位のメタデータ（最小値・最大値）によるプッシュダウンも可能です。
リージョン配置と性能
Athena と S3 バケットを同じリージョンに置くことは性能最適化の基本です。 リージョン間の転送には物理的な距離によるレイテンシが生じ、大量スキャンのクエリではこの遅延が積み重なって性能に響きます。同一リージョンなら AWS の内部ネットワーク経由で最小のレイテンシでアクセスできます。
S3 の性能特性
Amazon S3 はリクエストレートが改善され、パーティション分割されたプレフィックスごとに毎秒 3,500 件の書き込み（PUT/COPY/POST/DELETE）と 5,500 件の読み取り（GET/HEAD）を処理でき、プレフィックスを増やせばこの上限を線形にスケールさせられます。 かつて推奨されたランダムプレフィックスは現在では多くのワークロードで不要です。むしろ配送日などの論理的なパーティション構造を保つことで、Athena のパーティションプルーニングが有効に働きます。
アーキテクチャ図の解説
アーキテクチャ図
データを保存する S3 と、それを読み込む Athena を同じリージョンに置きます。配送実績のメトリクスを保存した S3 バケットと Athena が同一リージョンにあれば、転送がリージョン内の低レイテンシな経路で完結し、クエリの応答が速くなります。逆に S3 だけを別リージョンに置くと、クエリのたびにリージョン間の転送が発生し、レイテンシと転送コストが加算されます。データ量が増えるほどこの遅延は無視できなくなります。圧縮やフォーマットを最適化しても、リージョンが離れていればこの遅延は解消されないため、配置は性能改善の前提となる選択です。アカウントが異なっていてもアクセスは可能で、性能に効くのはアカウントではなくリージョンの一致です。
アーキテクチャ図
CSV を行指向から列指向の Parquet へ変換します。CSV は 1 行分の全列をまとめて格納するため、一部の列だけを参照するクエリでも全データをスキャンします。これを ETL 処理で Parquet に変換すると、列ごとにまとめて格納され、必要な列だけを選択的に読み込めるようになります。Parquet は圧縮効率も高く、ストレージ容量を削減できます。変換は一度行えば以降のクエリすべてに効くため、データが増えるほど効果が大きくなります。行指向のままでは、パーティションを切っても列単位の読み飛ばしはできない点に注意が必要です。なお、JSON は行指向のテキスト形式のため、Parquet のような列単位の読み飛ばし効果は得られません。
アーキテクチャ図
列指向フォーマットでスキャン量が減る仕組みを、具体的なクエリで示しています。配達 ID と所要時間だけを日付で絞り込むクエリに対し、CSV では全列を読み込みますが、Parquet では指定した 2 列と絞り込みに使う日付列だけを読み込み、残りの列はスキップします。行グループ単位のメタデータ（最小値・最大値）を使うプッシュダウンにより、条件に合わないブロックは読み込み前に除外されます。スキャン量の削減は Athena の課金対象データ量も減らすため、クエリ性能とコストの両方に効きます。列指向にすることで、参照しない列の読み込みを省けるため、カラム数が多いテーブルほど効果が大きくなります。また、圧縮とプッシュダウンが組み合わさることで、クエリの応答時間とスキャン料金の双方が下がります。
解くための考え方
Athena でクエリする CSV データの性能を高めます。まずデータフォーマットの最適化を考えます。CSV は行指向のテキスト形式で、参照する列が少なくても全データを読み込みます。Apache Parquet への変換は、列指向の利点を活かせる最も効果的な最適化です。プッシュダウンにより WHERE 句に合わないデータブロックをスキップできるため、スキャン量を大きく減らせます。 次にインフラの配置を考えます。Athena と S3 を同じリージョンに置くことは、ネットワークレイテンシを最小化する基本要件であり、AWS のベストプラクティスです。 ランダムプレフィックスの付与は現在の S3 では不要で、パーティション構造を壊すおそれがあるため不適切です。JSON への変換も列指向の利点がないため、有意な改善になりません。アカウントの一致は性能には影響せず、重要なのはリージョンの一致です。 Parquet 形式へ変換し、Athena と S3 を同じリージョンに置けば、スキャン量と転送遅延の両方を下げられます。 参考資料
スポンサーリンク
以下スポンサーリンクです。
この記事がお役に立ちましたら、コーヒー1杯分（300円）の応援をいただけると嬉しいです。いただいた支援は、より良い記事作成のための時間確保や情報収集に活用させていただきます。