DEA#02

同時実行スケーリングを使用する

「同時実行スケーリング」 を有効にすることで 読み取りと書き込みのキャパシティを動的に拡張 できるため正解です。

具体的には、Amazon Redshift の ワークロード管理 (WLM) は、クラスター内のリソースを効率的に配分するための機能であり、キューレベルで 同時実行スケーリング を有効にすることで、ユーザー定義のキューの待機時間が一定以上になった場合に、自動的に追加のコンピューティングリソースをプロビジョニングします。これにより、需要の変動に応じて読み取りと書き込みのキャパシティを自動で拡張 し、クラスターのパフォーマンスを最適化することができます。この機能は、特に大規模なデータウェアハウス操作において、性能の向上 と リソースの効率的な利用 を実現します。

※同時実行スケーリングを使用する
同時実行スケーリング機能を使用すると、一貫した高速のクエリパフォーマンスで、数千の同時ユーザーと同時クエリをサポートできます。同時実行スケーリングが有効になっている場合、Amazon Redshift は自動的に新たなクラスターキャパシティーを追加し、読み取りと書き込み両方でクエリの増加に対応します。クエリをメインクラスターと同時実行スケーリングクラスターのどちらで実行しても、ユーザーには最新のデータが表示されます。

WLM キュー を設定することで、どのクエリを同時実行スケーリングクラスターに送信するかを管理できます。同時実行スケーリングを有効にすると、対象となるクエリはキュー内に待機することなく、同時実行スケーリングクラスターに送信されるようになります。
参考URL : 同時実行スケーリングを使用する - Amazon Redshift
参考URL : 同時実行スケーリングキューの設定

■以下は間違いです。
・Redshift クラスターの 1 日あたりの使用量クォータの同時実行スケーリングを有効にします。
→「同時実行スケーリング」 は使用量クォータではなく、クラスターの性能管理とリソース最適化のための機能であるため間違いです。1 日あたりの使用量クォータは、コスト管理やリソースの使用制限に関連する設定であり、同時実行スケーリングの有効化とは無関係です。

・新しい Redshift クラスターを作成する際の設定で、同時実行スケーリングを有効にします。
→「同時実行スケーリング」は既存のクラスターの WLM 設定で有効化できます。新しい Redshift クラスターを作成する必要はないため間違いです。

・A.Redshift Serverless ワークグループのワークロード管理 (WLM) で同時実行スケーリングを有効にします。
→Amazon Redshift Serverless ワークグループのワークロード管理 (WLM) ではなく、Amazon Redshift クラスターの WLM キューレベルで同時実行スケーリングを有効にすることが必要であるため間違いです。Amazon Redshift Serverless は異なるサービスであり、既存の RA3 ノードを使用するクラスターに適用される設定ではありません。

AWS Glue ワークフロー

「AWS Glue ワークフロー」 を使用することで、Microsoft SQL Server のテーブルのクロール、抽出、変換、Amazon S3 へのロードを一元管理し、最もコスト効率が良いため正解です。

具体的には、AWS Glue ワークフロー は、データの ETL (抽出、変換、ロード) プロセスを自動化し、管理するためのサービスであり、複数の ETL ジョブと前提条件を一つのワークフローとして組み合わせることができます。この機能により、Microsoft SQL Server からデータを抽出し、変換して Amazon S3 バケットにロードするプロセスを簡単に設定できます。さらに、データパイプラインの調整が必要な場合にも、AWS Glue ワークフロー を使用することで、複雑なスクリプトや外部の調整ツールを用いずに、プロセスの管理と調整を行うことができるため、コストと労力の両面で効率的です。

※AWS Glue のワークフローの概要
AWS Glue では、ワークフローを使用して、複数のクローラ、ジョブ、トリガーが関与する複雑な ETL (抽出、変換、ロード) アクティビティを作成および視覚化できます。各ワークフローは、そのすべてのジョブとクローラーの実行と監視を管理します。ワークフローは各コンポーネントを実行すると、実行の進行状況とステータスを記録します。これにより、より大きなタスクの概要と各ステップの詳細が得られます。AWS Glue コンソールは、ワークフローをグラフとして視覚的に表現します。

例 : ワークフローのグラフ

参考URL : AWS Glue のワークフローの概要

■以下は間違いです。
・AWS Step Functions
・Amazon Managed Workflows for Apache Airflow (Amazon MWAA)
→「AWS Step Functions」 と 「Amazon Managed Workflows for Apache Airflow (Amazon MWAA)」 は、複数の AWS サービスや外部サービス間でのタスクの調整や自動化に特化したサービスです。これらのサービスは、ワークフローの管理やタスク間の依存関係の設定などを効率的に行うことができますが、データの ETL (抽出、変換、ロード) を直接実行する機能は持っていません。ETL プロセスを実行するには、AWS Glue や他のデータ処理サービスを組み合わせて使用する必要があります。

・AWS Glue Studio
→「AWS Glue Studio」 は、AWS Glue の機能を使用して ETL ジョブを視覚的に設計、開発するためのユーザーフレンドリーなインターフェースを提供します。しかし、これはジョブの作成と管理に特化しており、データパイプライン全体の調整や複数の ETL ジョブとその依存関係を管理する AWS Glue ワークフロー のような包括的な調整機能は提供していないため間違いです。

AWS Secrets Manager への接続認証情報の保存

・AWS Secrets Manager に認証情報を保存します。
→「AWS Secrets Manager」 はセキュリティの観点から認証情報を管理するための推奨されるサービスのため正解です。このサービスは、機密情報を保存し、適切なアクセス権を持つユーザーのみがその情報にアクセスできるように設計されています。

・AWS Glue ジョブの IAM ロールに、保存された認証情報へのアクセスを付与します。
→「AWS Glue ジョブの IAM ロールに保存された認証情報へのアクセス権を付与する」ことで、ジョブ実行時に Secrets Manager から直接認証情報を安全に取得できます。これにより、ハードコーディングや不適切な認証情報の管理リスクを軽減し、セキュリティポリシーに沿った運用ができます。

※AWS Secrets Manager への接続認証情報の保存
AWS Secrets Manager を使用してデータストアの接続認証情報を入力することをお勧めします。このように Secrets Manager を使用すれば、AWS Glue は ETL ジョブのランタイムやクローラー実行の際にシークレットにアクセスでき、認証情報を安全に保つことができます。
参考URL : AWS Secrets Manager への接続認証情報の保存

■以下は間違いです。
他の選択肢は、認証情報をジョブパラメータや Amazon S3 バケット内の設定ファイルに保存する方法はセキュリティリスクが高いため間違いです。

・AWS Glue ジョブを使用して、Amazon S3 バケット内の設定ファイルから認証情報にアクセスします。
→Amazon S3 バケット内の設定ファイルから認証情報にアクセスする方法は、セキュリティのベストプラクティスに反しています。これは、認証情報を安全な方法で管理するために設計されたサービス (例えば AWS Secrets Manager) を使用していないため、潜在的なセキュリティの脆弱性を生み出す可能性があります。

・AWS Glue のジョブパラメータに認証情報を保存します。
・Amazon S3 バケットにある設定ファイルに認証情報を保存します。
→これは、不適切なセキュリティプラクティス です。これらの方法では、認証情報が暗号化されていない形で保存される可能性があり、不正アクセスのリスクを高めます。

Lake Formation での行レベルのアクセスコントロールによるデータレイクの保護

「AWS Lake Formation」 を使用して行と列のデータアクセスを制限することで、要件を満たしながら運用上のオーバーヘッドを最小限に抑えることができるため正解です。

具体的には、AWS Lake Formation は、Amazon S3 上に構築されたデータレイクでのセキュリティ管理を簡素化し、細かなアクセス制御を提供します。これにより、企業は行レベルおよび列レベルのデータアクセスを特定のチームに提供できます。AWS Lake Formation は、Amazon Athena、Amazon Redshift Spectrum、および Amazon EMR からの Apache Hive を含む様々な分析ツールからのアクセス管理に対応しています。これにより、運用上のオーバーヘッドを最小限に抑えつつ、安全かつ効率的にデータアクセスの管理が可能になります。

※行レベルのアクセスコントロールによるデータレイクの保護
AWS Lake Formation の行レベルのアクセスコントロールを使用すると、データコンプライアンスおよびガバナンスポリシーに基づいて、テーブル内の特定の行へのアクセスを提供できます。数十億のレコードを格納する大きなテーブルがある場合、さまざまなユーザーやチームがアクセスして表示できるデータを、許可した範囲に限定する方法が必要です。行レベルのアクセスコントロールは、データを保護するとともに、ジョブの実行に必要なデータへのアクセス許可をユーザーに付与するシンプルでパフォーマンスの高い方法です。Lake Formation は、一元的な監査とコンプライアンスレポートを通じて、どのプリンシパルが、どのデータに、いつ、どのサービスを通じてアクセスしたかを特定します。
参考URL : 行レベルのアクセスコントロールによるデータレイクの保護

※Lake Formation でのデータフィルタリングとセルレベルのセキュリティ
Lake Formation は、列レベルのセキュリティ、行レベルのセキュリティ、およびセルレベルのセキュリティを実現するために、データフィルタリングを使用します。ソースデータにネストされた構造が含まれている場合は、ネストされた列にデータフィルターを定義して適用できます。
参考URL : Lake Formation でのデータフィルタリングとセルレベルのセキュリティ - AWS Lake Formation

■以下は間違いです。
・データレイクのストレージに Amazon Redshift を使用します。Redshift セキュリティポリシーを使用して、行と列でデータアクセスを制限します。Apache Spark と Amazon Athena フェデレーテッドクエリを使用してデータアクセスを提供します。
→「Amazon Redshift」 は主にデータウェアハウスソリューションであり、大規模なデータレイクを構築するためのストレージとしては最適ではありません。Redshift セキュリティポリシーは、Redshift 内のデータに対するアクセス制御に適していますが、Amazon S3 上に構築されたデータレイク全体の細かなアクセス制御には対応していません。

・データレイクのストレージに Amazon S3 を使用します。Amazon EMR 経由で Apache Ranger を使用して、行と列でデータアクセスを制限します。Apache Pig を使用してデータアクセスを提供します。
→この方法は Apache Hive や Apache Pig を介してデータにアクセスする際の行や列レベルでのアクセス制御を可能にするものの、Amazon Athena や Amazon Redshift Spectrum といったサービスからのデータアクセス制御には直接対応していません。また、Apache Pig を使用してデータアクセスを提供するという部分は、要件において指定されたツールと異なります。

・データレイクのストレージに Amazon S3 を使用します。S3 アクセスポリシーを使用して、行と列でデータアクセスを制限します。Amazon S3 経由でデータアクセスを提供します。
→Amazon S3 のアクセスポリシーは主にバケットレベルまたはオブジェクトレベルのアクセス制御に使用され、行や列レベルの精細なデータアクセス管理はできないため間違いです。

S3 Select

「Amazon S3 Select」 は、オブジェクトストレージ内のデータから特定のデータのみを効率的に取得する機能を提供します。このサービスを使用することで、Amazon S3 に格納されている Apache Parquet 形式のデータから、特定の列のみを直接クエリできます。S3 Select を利用することで、全体のデータセットをダウンロードし処理する代わりに、必要なデータのみを抽出できるため、実行時間とコストを大幅に削減できます。

※Amazon S3 Select を使用して、サーバーまたはデータベースなしでデータをクエリする
以前は、データをクエリするにはデータベースにロードする必要がありました。データベースのデプロイに加えて、顧客は検索を有効にするためにアプリケーションとウェブサイトをデプロイする必要があります。データベースと関連リソースをデプロイする代わりに、S3 Select と呼ばれる S3 機能を利用して、完全にサーバーレスな電話帳検索ツールを作成します。
参考URL : Amazon S3 Select を使用して、サーバーまたはデータベースなしでデータをクエリする

※Amazon S3 Select を使用したデータのフィルタリングと取得
Amazon S3 Select を使用してこのデータをフィルタリングする場合、Amazon S3 が転送するデータの量を抑えることで、このデータの取得に必要なコストを削減し、レイテンシーを抑えることができます。

Amazon S3 Select は、CSV、JSON、または Apache Parquet 形式で保存されたオブジェクトを操作します。また、GZIP や BZIP2 で圧縮されたオブジェクト (CSV と JSON 形式のオブジェクトのみ) や、サーバー側で暗号化されたオブジェクトにも使用できます。結果の形式 (CSV または JSON) や、結果のレコードを区切る方法は指定できます。
参考URL : Amazon S3 Select を使用したデータのフィルタリングと取得

※(引用) Amazon S3 Select
S3 バケット内に保存したオブジェクトに対し、SQL 文を用いてデータの一部分のみを取り出すことができるサービスです。アプリケーションが必要なデータのみ取得ができるので、パフォーマンスの向上が期待できます。
文章・画像引用 :Amazon S3 Select を使って S3 オブジェクトの特定データを抽出する。

■以下は間違いです。
・S3 オブジェクトで AWS Glue クローラーを実行します。Amazon Athena で SQL SELECT ステートメントを使用して、必要な列をクエリします。
→「AWS Glue クローラー」を実行し、Amazon Athena を使用して SQL SELECT ステートメントで必要な列をクエリする方法は、データソースのスキーマを認識し、クエリ可能なデータカタログを作成するための追加のステップを含みます。このプロセスは、特に 1 回限りの簡単なデータクエリタスクには、不要な運用上の複雑さと時間のかかるセットアップを伴うため間違いです。

・S3 オブジェクトを使用し、必要な列をクエリするために AWS Glue DataBrew プロジェクトを準備します。
→DataBrew の使用は探索的データ分析やデータのクリーニングに適しているため、単一列をクエリすることはできないため間違いです。

・AWS Lambda 関数を構成して、S3 バケットから pandas データフレームにデータをロードします。必要な列をクエリするために、データフレームに SQL SELECT ステートメントを記述します。
→この方法は、データの前処理やデータフレームへの変換など、余計な手間とコンピューティングリソースを必要とします。これは、1 回限りのタスクにおいて求められる運用上のオーバーヘッドを最小限に抑えるという要件に反します。

gp2 から gp3 に移行する

ボリュームタイプの変更 は、運用上のオーバーヘッドを最小限に抑えながら、Amazon EC2 インスタンスの中断なく Amazon EBS ストレージを gp2 から gp3 にアップグレードできるため正解です。

具体的には、Amazon EBS の汎用 SSD ストレージタイプを gp2 から gp3 へ直接変更することで、データの複製や移行を伴わずにアップグレードを完了できます。この方法は Amazon EC2 インスタンスの運用を中断することなく行うことができ、運用上のオーバーヘッドを大幅に削減します。また、ボリュームタイプ の変更は、Amazon EBS コンソール、AWS Command Line Interface (AWS CLI)、または AWS Software Development Kit (SDK) を使用して簡単に行えます。これにより、ボリュームサイズ、IOPS 、および スループット の新しい値を指定することにより、必要に応じてストレージのパフォーマンスを最適化できます。

※gp2 から gp3 に移行する
現在 gp2 ボリュームを使用している場合は、Amazon EBS Elastic Volumes を使用して ボリュームを変更する オペレーション を使用してボリュームを gp3 に移行できます。Amazon EBS Elastic Volumes オペレーションを使用して、Amazon EC2 インスタンスを中断することなく、既存のボリュームのボリュームタイプ、IOPS、およびスループットを変更できます。コンソールを使用してボリュームを作成したり、スナップショットから AMI を作成したりする場合、ボリュームタイプには、汎用 SSD gp3 がデフォルトで選択されます。それ以外の場合は、gp2 がデフォルトで選択されます。このような場合、gp2 を使用する代わりに、ボリュームタイプとして gp3 を選択できます。
参考URL : gp2 から gp3 に移行する

■以下は間違いです。
・AWS DataSync を使用して、新しい gp3 ボリュームを作成します。元の gp2 ボリュームから新しい gp3 ボリュームにデータを転送します。
→「AWS DataSync」 を使用して新しい gp3 ボリュームを作成し、元の gp2 ボリュームから新しい gp3 ボリュームにデータを転送する方法も、データの転送プロセスが必要であり、さらに AWS DataSync のセットアップと運用に追加の手間とコストがかかります。これらの方法はすべて、直接的なボリュームタイプの変更に比べて、より多くのステップと高い運用負担を伴うため間違いです。

・新しい gp3 ボリュームを作成します。データを新しい gp3 ボリュームに徐々に転送します。転送が完了したら、新しい gp3 ボリュームを EC2 インスタンスにマウントして、gp2 ボリュームを置き換えます。
→新しい gp3 ボリュームを作成し、データを新しい gp3 ボリュームに徐々に転送し、転送が完了したら新しい gp3 ボリュームを Amazon EC2 インスタンスにマウントして gp2 ボリュームを置き換える必要があります。この方法も、データ転送とストレージの再構成により、運用の複雑さが増します。

・gp2 ボリュームのスナップショットを作成します。スナップショットから新しい gp3 ボリュームを作成します。新しい gp3 ボリュームを EC2 インスタンスにアタッチします。
→この方法には、Amazon EBS の gp2 ボリュームのスナップショットを作成し、そのスナップショットから新しい gp3 ボリュームを作成し、そして新しい gp3 ボリュームを Amazon EC2 インスタンスにアタッチするという複数の手順が含まれます。これは、データの転送と新しいボリュームのセットアップに追加の時間と手間を要します。

AWS Glue API の呼び出し

Amazon S3 にデータを書き込む際に Boto3 AWS Glue create_partition API を呼び出すことで、AWS Glue Data Catalog が S3 ストレージと即時に同期できます。これにより、データエンジニアは新しいパーティションが追加されるたびに手動で介入することなく、AWS Glue Data Catalog が常に最新の状態を保つことを保証できます。この方法は、レイテンシーを最小限 に抑えることができます。

※Python での AWS Glue API の呼び出し
Boto 3 クライアント API のみ使用することができます。
参考URL : Python での AWS Glue API の呼び出し
参考URL : create_partition

■以下は間違いです。
・AWS Glue クローラーを毎朝実行するようにスケジュールします。
・AWS Glue コンソールから MSCK REPAIR TABLE コマンドを実行します。
→いずれも新しいデータパーティションが作成されてからカタログに反映されるまでに時間がかかります。これは、クローラーやコマンドが定期的にしか実行されないため、新しいパーティションの追加が即座に反映されず、レイテンシーが発生 する原因となります。

・AWS Glue CreatePartition API を毎日 2 回手動で実行します。
→このプロセスは自動化されていないため、毎回手動で API を呼び出す必要があります。これは時間がかかる上に人的ミスが発生するリスクも伴い、非効率的 のため間違いです。