持続可能性の為のモダンデータアーキテクチャ最適化 : 第二部 – 統合データガバナンス、データ移動、目的別分析

このブログは Sam Mokhtari, Dr. Ali Khoshkbar, Sandipan Bhaumik によって執筆された内容を翻訳したものです。原文はこちらを参照して下さい。

このブログシリーズの第一部「持続可能性の為のモダンデータアーキテクチャ最適化 : 第一部 – データ取り込みとデータレイク」では、モダンデータアーキテクチャにおける 1) データ取り込み、2) データレイクの柱に焦点を当てました。このブログ記事では、3) 統合データガバナンス、4) データ移動、5) 目的別分析の柱に含まれるコンポーネントを最適化するためのガイダンスとベストプラクティスを紹介します。
図 1 は、モダンデータアーキテクチャのさまざまな柱を示しています。これには、データ取り込み、データレイク、統合データガバナンス、データ移動、および目的別分析の柱が含まれます。

図 1. AWS のモダンデータ分析リファレンスアーキテクチャ

3. 統合データガバナンス

一元化されたデータカタログは、ストレージレイヤーのデータセットに関するビジネスのメタデータとテクニカルメタデータを保存する役割を担います。管理者はこのレイヤーに権限を適用し、セキュリティ監査のイベントを追跡します。

データディスカバリー

データ共有を増やし、データの移動や重複を減らすには、様々なユーザーペルソナに対してデータ検出と明確なアクセス制御を可能にする必要があります。これにより、重複するデータ処理のアクティビティが減ります。組織内の各チームが、この一元化されたカタログを利用することができます。ファーストパーティデータ (売上データなど) またはサードパーティデータ (株価、気候変動のデータセットなど) を提供します。ソースから繰り返しデータを取得する必要はなく、データへのアクセスは 1 回だけで済みます。

AWS Glue データカタログでは、メタデータの追加と検索のプロセスを簡素化できます。AWS Glue クローラーを使用して既存のスキーマを更新し、新しいデータセットを発見します。スケジュールを慎重に計画して、不要なクロールを減らしてください。

データ共有

AWS Lake Formation などのサービスを使用して、様々なデータコンシューマー向けに明確に定義されたアクセス制御メカニズムを確立します。これにより、きめ細かなアクセス制御で組織単位の間でデータセットを共有できるようになり、重複するコピーや移動が減ります。Amazon Redshift データ共有を使用すると、データウェアハウス間でデータをコピーする必要がなくなります。

明確に定義されたデータセット

明確に定義されたデータセットと関連するメタデータを作成して、不必要なデータ処理や操作を回避します。これにより、追加のデータ操作に起因するリソース使用量を削減できます。

4. データ移動

AWS Glue は、サーバーレスで従量課金制のデータ移動機能を提供します。サーバーやクラスターを立ち上げて管理する必要はありません。数十テラバイトのデータを処理できる ETL パイプラインを設定します。

パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えるには、AWS Glue の Auto Scaling を使用してください。

ユースケースごとに AWS Glue ワークフローを作成するのではなく、AWS Glue ブループリントを使用することで、同様のユースケースの AWS Glue ワークフローを作成して共有できます。AWS Glue ジョブブックマークは、以前に処理されたデータを追跡できます。

本番前のジョブ、テスト、1 回限りのデータロードなど、緊急性が低い、または時間に左右されないデータ統合ワークロードには、Glue Flex ジョブの使用を検討してください。Flex では、AWS Glue ジョブは専用のハードウェアではなく、予備のコンピューティング能力で実行されます。

複数のデータフレーム間の結合は、Spark ジョブでは一般的な操作です。ノード間のデータのシャッフルを減らすには、マージされたデータフレームの 1 つが実行中のすべてのノードで複製できるほど小さい場合、broadcast joins を使用します。

最新の AWS Glue バージョンでは、ワークロードにさらに多くの新しい効率的な機能が提供されています。

5. 目的に合わせた分析

データ処理モード

リアルタイムデータ処理オプションには、継続的にコンピューティングリソースを使い、より多くのエネルギー消費が必要です。持続可能性を最大限に高めるには、トレードオフを評価し、最適なバッチデータ処理のオプションを選択してください。

バッチおよびインタラクティブなワークロードの要件を特定し、Amazon EMR で一時的なクラスターを設計します。スポットインスタンスを使用し、インスタンスフリートを設定することで、使用率を最大化できます。

エネルギー効率を向上させるために、Amazon EMR Serverless を使用すると、データ処理のジョブにリソースを過剰にプロビジョニングしたり、プロビジョニングが不十分になったりすることを回避できます。Amazon EMR Serverless は、アプリケーションが必要とするリソースを自動的に判断し、これらのリソースを収集してジョブを処理し、ジョブが終了するとリソースを解放します。

Amazon Redshift RA3 ノードはコンピューティング効率を向上させることができます。RA3 ノードでは、ストレージを拡張せずにコンピューティングをスケールアップまたはスケールダウンできます。Amazon Redshift Serverless を選択すると、データウェアハウスの容量をインテリジェントにスケーリングできます。これにより、最も要求が厳しく予測不可能なワークロードでも、より高速なパフォーマンスを実現できます。

エネルギー効率の高い変換とデータモデル設計

データ処理とデータモデリングのベストプラクティスは、組織の環境への影響を軽減できます。

Amazon Redshift クラスター内のノード間での不必要なデータ移動を避けるため、テーブル設計のベストプラクティスに従ってください。

Amazon Redshift の自動テーブル最適化 (ATO) を使用して、使用パターンに基づいてテーブルを自動調整することもできます。

Amazon Athena または Amazon Redshift の EXPLAIN 機能を使用して、クエリを調整および最適化します。

Amazon Redshift Advisor は、パフォーマンス統計と運用データに基づいてデータウェアハウスを最適化するための具体的でカスタマイズされた推奨事項を提供します。

Amazon EMR または Amazon OpenSearch Service を、AWS Graviton などの電力効率の高いプロセッサに移行することを検討してください。AWS Graviton 3 は、他の CPU と比較して 2.5 ～ 3 倍のパフォーマンスを実現しています。Graviton 3 ベースのインスタンスは、同等の EC2 インスタンスと同じパフォーマンスで消費電力が最大 60% 少なくなります。

アイドルリソースを最小化

EMR クラスターの auto scaling を使用するか、Amazon Kinesis Data Streams On-Demand を採用して、パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えます。

AWS Trusted Advisor は、十分に活用されていない Amazon Redshift クラスターを特定するのに役立ちます。使用していないときは Amazon Redshift クラスターを一時停止し、必要に応じて再開します。

エネルギー効率の高い消費パターン

データを Amazon Redshift にコピーするのではなく、Amazon Athena または Amazon Redshift Spectrum を使用してその場でデータをクエリして 1 回限りの分析を行うことを検討してください。

必要に応じて、頻繁にクエリを実行できるようにキャッシュレイヤーを有効にします。これは、Amazon Redshift などのサービスに組み込まれている result caching に追加されるものです。また、ソースデータが頻繁に変更されないすべてのクエリには、Amazon Athena Query Result Reuse を使用してください。

Amazon Redshift または Amazon Aurora PostgreSQL で利用できるマテリアライズドビュー機能を使用して、不必要な計算を回避してください。

Amazon Athena フェデレーテッドクエリまたは Amazon Redshift フェデレーテッドクエリを利用し、データストア全体でフェデレーテッドクエリを使用すると、データ移動を減らすことができます。個別の Amazon Redshift クラスター間でクエリを実行する場合は、これらのクラスター間のデータ移動を減らす Amazon Redshift データ共有機能の使用を検討してください。

環境の持続可能性の為の改善追跡と評価

持続可能性に向けたワークロード最適化の成功を評価する最適な方法は、プロキシメトリクスと作業単位の KPI を使用することです。これは、ストレージの場合は 1 トランザクションあたりの GB 数、コンピューティングの場合は 1 トランザクションあたりの vCPU 分です。

表 1 には、改善の度合いを測るメトリクスとして、分析サービスで収集できる特定のメトリクスが示されています。これらは、この記事で取り上げた最新のデータアーキテクチャの各柱に該当します。

テーブル 1. モダンデータアーキテクチャの柱となるメトリクス

まとめ

このブログ記事では、モダンアーキテクチャの統合データガバナンス、データ移動、目的別分析の柱の下でプロセスを最適化するためのベストプラクティスを紹介しました。

詳細を知りたい場合は、AWS Well-Architected Framework の持続可能性の柱や、持続可能性のためのアーキテクチャに関するその他のブログ投稿をご覧ください。

アーキテクチャに関するその他のコンテンツをお探しの場合は、AWS アーキテクチャセンターを参照して、リファレンスアーキテクチャ図、精査されたアーキテクチャソリューション、Well-Architected のベストプラクティス、パターン、アイコンなどを確認してください。

このブログは、ソリューションアーキテクトの福田哲也が翻訳しました。