Amazon Web Services ブログ

集中型アーキテクチャから分散型アーキテクチャへ:データ共有が Amazon Redshift のワークロードを微調整する方法

この記事は From centralized architecture to decentralized architecture: How data sharing fine-tunes Amazon Redshift workloads の翻訳記事です。

Amazon Redshift は迅速、ペタバイト規模でスケールが可能かつ最適なコストパフォーマンスを提供するクラウドデータウェアハウスです。標準 SQL と既存のビジネスインテリジェンス ( BI ) ツールを使用して、すべてのデータを迅速、簡単、かつ費用対効果の高い方法で分析できます。現在、何万ものお客様がビジネスクリティカルなワークロードを Amazon Redshift 上で実行しています。

ビッグデータ分析用のデータが長年にわたって大幅に増加しているため、一部のお客様から Amazon Redshift のワークロードをどのように最適化すべきかという質問が寄せられています。この記事では、Amazon Redshift RA3 ノード、データ共有、クラスターの一時停止と再開を使用して Amazon Redshift クラスターのワークロードを最適化する方法について説明します。その他のコスト最適化方法については、Getting the most out of your analytics stack with Amazon Redshift を参照してください。

Amazon Redshift の主な機能

まず、主な機能をいくつか確認しましょう。

  • RA3 ノード — Amazon Redshift RA3 ノードには、コンピューティング能力とストレージを個別に最適化できる新しいマネージドストレージモデルが採用されています。これらには非常に重要な機能がいくつかあり、その1つがデータ共有です。RA3 ノードでは一時停止と再開の機能もサポートしているため、クラスターが使用されていない間はオンデマンド課金を簡単に中断できます。
  • データ共有 — Amazon Redshift のデータ共有により、単一クラスターにおける Amazon Redshift の使いやすさ、パフォーマンス、コスト面でのメリットを、データを共有しながらマルチクラスターデプロイにまで拡張できます。データ共有により、コピーや移動を必要とせずに、Redshift クラスター間のデータに瞬時に、きめ細かく、高速にアクセスできます。同じまたは異なる AWS アカウントの Amazon Redshift クラスターと、またリージョン間でライブデータを安全に共有できます。スキーマ、テーブル、ビュー、ユーザー定義関数など、さまざまなレベルでデータを共有できます。また、Amazon Redshift Serverless 上で更新された最新かつ一貫した情報を共有することもできます。さらに、データへのアクセスを必要とするさまざまなユーザーや企業に合わせて調整できる、きめ細かなアクセス制御も提供します。ただし、Amazon Redshift でのデータ共有にはいくつかの制限があります。

ソリューションの概要

このユースケースでは、お客様は分析ワークロードのデータウェアハウスとして Amazon Redshift を頻繁に使用しており、Amazon Redshift がビジネスにもたらした可能性と利便性を享受しています。主に Amazon Redshift を使用して、BI 用にユーザーの行動データを保存および処理しています。データはここ数か月で毎日数百ギガバイトも増加しており、部署の従業員は営業時間中、BI プラットフォーム上の Amazon Redshift クラスターに対してクエリを継続的に実行しています。

一部のデータがすべてのワークロードで使用されるため、同社では 1 つの Amazon Redshift クラスターで 4 つの主要な分析ワークロードを実行しています。

  • BI プラットフォームからのクエリ — さまざまなクエリが主に営業時間中に実行されます。
  • 1 時間毎の ETL — この抽出、変換、ロード ( ETL ) ジョブは、毎時間の最初の数分で実行されます。通常、所要時間は約40分です。
  • 日次の ETL — 運用チームはその日のうちに日次レポートを取得する必要があるため、この ETL ジョブは営業時間中に 1 日 2 回実行されます。通常、各ジョブには 1.5 ～ 3 時間かかります。これは 2 番目にリソースを大量に消費するワークロードです。
  • 週次の ETL — このジョブは毎週日曜日の早朝に実行されます。これは最もリソースを大量に消費するワークロードです。この作業には通常 3 ～ 4 時間かかります。

分析チームは RA3 ファミリーに移行し、Amazon Redshift クラスターのノード数を何年にもわたって 12 に増やしました。特に他のワークロードが実行中の場合、データサイズの都合上 BI ツールのクエリ平均実行時間を許容できる時間内に抑えるためです。

しかし、ETL タスクの実行中はパフォーマンスが低下し、 実行時間が長くなることに気付きました。そのため、分析チームは Amazon Redshift クラスターを最適化するソリューションを検討したいと考えています。

ETL タスクの実行中に CPU 使用率が急上昇するため、AWS チームが最初に考えたのは、ワークロードと関連データをクラスターサイズの異なる複数の Amazon Redshift クラスターに分離することでした。ノードの総数を減らすことで、Amazon Redshift のコストを削減したいと考えていました。

一連の話し合いの結果、AWS チームは、お客様が全ワークロードを 12 ノードの Amazon Redshift クラスターに保持している理由の 1 つとして、“特に Amazon Redshift クラスターの全ワークロードのパフォーマンスに大きな影響を与える ETL ワークロードを実行中に、BI プラットフォームからのクエリパフォーマンスを損なうことなく管理したい”という点に気付きました。問題となっているのは、データウェアハウス内の多くのテーブルが複数のワークロードによって読み書きされる必要があり、そしてデータ共有のプロデューサーだけが共有されたデータを更新できる点です。

Amazon Redshift クラスターを複数のクラスターに分割する際の課題は、データの一貫性です。ETL ワークロードによる読み取りと BI ワークロードによる書き込みが必要なテーブルもあれば、その逆のテーブルもあります。そのため、データを 2 つの Amazon Redshift クラスターに複製したり、BI クラスターからレポートクラスターへのデータ共有のみを作成したりする場合、顧客はすべての Amazon Redshift クラスター間でデータの一貫性を保つためのデータ同期プロセスを開発する必要があり、このプロセスは非常に複雑で保守が困難になる可能性があります。

お客様のワークロードを深く理解するためにさらに分析した結果、AWS チームはテーブルを 4 つのグループに分けることができることを発見し、マルチクラスターの双方向データ共有ソリューションを提案しました。このソリューションが目指すのは、 Amazon Redshift を使用して定期実行ワークロード用クラスターを一時停止および再開することで Amazon Redshift のランニングコストを削減できるように、ワークロードを別々の Amazon Redshift クラスターに分割することです。なぜなら、クラスターが一時停止中であっても、それぞれのクラスターはワークロードで必要とするデータへ引き続きアクセスすることが可能だからです。このソリューションでは、複雑なデータ同期プロセスを構築することなく、データの一貫性要件を満たす必要があります。

次の図は、古いアーキテクチャ (左) と新しいマルチクラスターソリューション (右) を比較したものです。

Improve the old architecture (left) to the new multi-cluster solution (right)

ワークロードとデータの分割

4 つの主要なワークロードの特性から、ワークロードを長時間実行ワークロードと定期実行ワークロードの 2 つのカテゴリに分類しました。

長時間実行されるワークロードは、BI プラットフォームと 1 時間毎の ETL ジョブのものです。1 時間毎の ETL ワークロードの実行には約 40 分かかるため、分離した Amazon Redshift クラスターにそのジョブを移行し、1 時間毎にクラスターを一時停止して再開しても、得られるコスト削減効果はわずかです。そのため、BI プラットフォームと同じクラスター上で実行することにします。

定期実行されるワークロードは、日次および週次の ETL ジョブのものです。通常、日次ワークロードは約1時間40分から3時間かかり、週次ワークロードには通常3〜4時間かかります。

データ共有計画

次のステップは、各カテゴリの全データ (テーブル)に対する アクセスパターンを特定することです。次の 4 種類のテーブルを特定しました。

  • タイプ 1 — テーブルは長時間実行されるワークロードによってのみ読み取りと書き込みが行われます
  • タイプ 2 — テーブルは長時間実行されるワークロードによって読み書きされ、定期的に実行されるワークロードからも読み取られます
  • タイプ 3 — テーブルは、定期的に実行されるワークロードによって読み書きされ、長時間実行されるワークロードからも読み取られます
  • タイプ 4 — テーブルは定期的に実行されるワークロードによってのみ読み書きされます

幸い、全ワークロードから書き込みの必要のあるテーブルはありません。したがって、Amazon Redshift クラスターを 2 つの Amazon Redshift クラスターに分けることができます。1 つは長時間実行のワークロード用で、もう 1 つは 20 個の RA3 ノードを使用した定期実行のワークロード用です。

長時間実行クラスターと定期実行クラスター間で双方向のデータ共有を作成しました。タイプ 2 のテーブルでは、長時間実行クラスターをプロデューサーとして、定期実行クラスターをコンシューマーとしてデータ共有を作成しました。タイプ 3 のテーブルでは、定期実行クラスターをプロデューサーとして、長時間実行クラスターをコンシューマーとしてデータ共有を作成しました。

次の図は、このデータ共有構成を示しています。

The long-running cluster (producer) shares type 2 tables to the periodic-running cluster (consumer). The periodic-running cluster (producer’) shares type 3 tables to the long-running cluster (consumer’)

長時間実行クラスター (プロデューサー) は、タイプ 2 のテーブルを定期実行クラスター (コンシューマー) と共有します。定期実行クラスター (プロデューサー) は、タイプ 3 のテーブルを長時間実行クラスター (コンシューマー) と共有します。

Amazon Redshift クラスター全体で双方向のデータ共有を構築

このセクションでは、Amazon Redshift クラスター全体で双方向のデータ共有を構築する手順について説明します。まず、後に長時間実行クラスターとなる元の Amazon Redshift クラスターのスナップショットを取得しましょう。

Take a snapshot of the long-running-cluster from the Amazon Redshift console

それでは、定期実行ワークロード用に 20 個の RA3 ノードからなる Amazon Redshift クラスターを作成しましょう。次に、タイプ 3 とタイプ 4 のテーブルを定期実行クラスターに移行します。必ず ra3 ノードタイプを選択してください。( Amazon Redshift Serverless はデータ共有もサポートしており、2022 年 7 月に一般提供が開始されたため Amazon Redshift Serverless も選択肢となり得ます)。

Create the periodic-running-cluster. Make sure you select the ra3 node type.

長時間実行クラスターから定期実行クラスターへのデータ共有を作成

次のステップは、長時間実行クラスター(プロデューサー)のテーブルを定期実行クラスター(コンシューマー)へ共有します。次の手順を実施してください。

  1. 定期実行クラスターで、次のクエリを実行して名前空間を取得します。
SELECT current_namespace;

必ず名前空間を記録してください。

  1. 長時間実行クラスターで、次のようなクエリを実行します。( ltop は long-to-periodic の略です)
CREATE DATASHARE ltop_share SET PUBLICACCESSIBLE TRUE;
ALTER DATASHARE ltop_share ADD SCHEMA public_long;
ALTER DATASHARE ltop_share ADD ALL TABLES IN SCHEMA public_long;
GRANT USAGE ON DATASHARE ltop_share TO NAMESPACE '[定期実行クラスターの名前空間]';
  1. 次のコマンドを使用して、長時間実行クラスターから定期実行クラスターへのデータ共有を検証できます。
SHOW datashares;
  1. データ共有を検証後、次のクエリで長時間実行クラスターの名前空間を取得します。
SELECT current-namespace;

必ず名前空間を記録してください。

  1. 定期実行クラスターで次のコマンドを実行します。長時間実行クラスターの名前空間を使用して、長時間実行クラスターから定期実行クラスターへのデータ共有からデータをロードします。
CREATE DATABASE ltop FROM DATASHARE ltop_share OF NAMESPACE '[長時間実行クラスターの名前空間]';
  1. 長時間実行クラスターから定期実行クラスターへのデータ共有内テーブルに対し、読み取りアクセス権があることを確認します。

定期実行クラスターから長時間実行クラスターへのデータ共有を作成

次のステップは、定期実行クラスターから長時間実行クラスターへのデータ共有を作成することです。前のステップで取得した長時間実行クラスターと定期実行クラスターの名前空間を使用します。

  1. 定期実行クラスターで、次のようなクエリを実行して、定期実行クラスターから長時間実行クラスターへのデータ共有を作成します。( ptol は periodic-to-long の略です)
CREATE DATASHARE ptol_share SET PUBLICACCESSIBLE TRUE;
ALTER DATASHARE ptol_share ADD SCHEMA public_periodic;
ALTER DATASHARE ptol_share ADD ALL TABLES IN SCHEMA public_periodic;
GRANT USAGE ON DATASHARE ptol_share TO NAMESPACE '[長時間実行クラスターの名前空間]';
  1. 次のコマンドを使用してデータ共有を検証します。
SHOW datashares;
  1. 長時間実行クラスターでは次のコマンドを実行します。定期実行クラスターの名前空間を使用して、定期実行クラスターから長時間実行クラスターへのデータ共有からデータをロードします。
CREATE DATABASE ptol FROM DATASHARE ptol_share OF NAMESPACE '[定期実行クラスターの名前空間]';
  1. 定期実行クラスターから長時間実行クラスターへのデータ共有内テーブルに対し、読み取りアクセス権があることを確認します。

この段階では、ワークロードを 2 つの Amazon Redshift クラスターに分割し、2 つの Amazon Redshift クラスター間で双方向のデータ共有を構築しました。

次のステップは、2 つの Amazon Redshift クラスターの正しいエンドポイントを使用して統合テストを実行できるように、さまざまなワークロードコードを更新することです。

定期実行用 Amazon Redshift クラスターを一時停止して再開する

定期実行ワークロードを実行する crontab スクリプトを更新してみましょう。2 つの更新を行います。

  1. スクリプト開始時に、定期実行用 Amazon Redshift クラスターが一時停止していた場合に再開させるため、 Amazon Redshift のチェック及びクラスターを再開する API を呼び出します。
aws redshift resume-cluster　--cluster-identifier [定期実行クラスターのID]
  1. ワークロードが完了したら、クラスター ID を指定して Amazon Redshift 一時停止クラスター API を呼び出してクラスターを一時停止します。
aws redshift pause-cluster --cluster-identifier [定期実行クラスターのID]

結果

ワークロードを新しいアーキテクチャに移行した後、同社の分析チームは結果を検証するためにいくつかのテストを実行しました。

テストによると、すべてのワークロードのパフォーマンスが向上しました。

  • ETL ワークロードの実行期間中、BI ワークロードが約 100% 速くなりました
  • 1 時間毎に実行される ETL ワークロードが約 50% 速くなりました
  • 日次ワークロードを最大 3 時間から約 40 分に短縮されました
  • 週次ワークロードを最大 4 時間から約 1.5 時間に短縮されました

すべての機能は正常に動作し、テスト期間中に新しいデータが 10% 以上追加されましたが、新しいアーキテクチャのコストは約 13% しか増加しませんでした。

学習内容と制限

ワークロードを異なる Amazon Redshift クラスターに分離したところ、いくつかのことがわかりました。

  • 日次および週次の ETL ワークロードによるリソースの競合がなくなったため、BI ワークロードのパフォーマンスは 100% 速くなりました。
  • 定期実行クラスターでの ETL ワークロードの所要時間は大幅に短縮されました。これは、ノード数を増やし、かつ BI 及び1 時間毎の ETL ワークロードによるリソースの競合がなくなったためです。
  • 新しいデータが 10% 以上追加された場合でも、 Amazon Redshift RA3 ファミリーのクラスター一時停止および再開機能を使用したため、Amazon Redshift クラスターの総コストは 13% しか増加しませんでした。
    その結果、Amazon Redshift クラスターのコストパフォーマンスが 70% 向上しました。

ただし、このソリューションにはいくつかの制限があります。

  • Amazon Redshift の一時停止および再開機能を使用するには、Amazon Redshift の一時停止および再開 API を呼び出すコードを、定期実行クラスターで ETL ワークロードを実行するすべてのスケジュールされたスクリプトに追加する必要があります。
  • Amazon Redshift クラスターの一時停止と再開には数分かかります、これらのプロセス中は課金されません。
  • Amazon Redshift クラスターのサイズは、ワークロードに応じて自動的にスケールインおよびスケールアウトできません。

次のステップ

パフォーマンスを大幅に改善したので、次は長時間実行クラスターのノード数を減らして Amazon Redshift のコストを削減する可能性を検討できます。

他に考えられる最適化としては、Amazon Redshift Spectrum を使用してクラスターストレージ上の Amazon Redshift のコストを削減する方法があります。Amazon Redshift Spectrum を使用すると、複数の Amazon Redshift クラスターが Amazon Simple Storage Service ( Amazon S3 ) 内にある構造化または半構造化データセットに対して同時にクエリを投げ、同じデータセットを取得することができます。クラスター毎にデータのコピーを作成したり、データを Amazon Redshift テーブルにロードしたりする必要はありません。

Amazon Redshift Serverless は、AWS re: Invent 2021 でプレビュー版として発表され、 2022 年 7 月に一般提供が開始されました。Amazon Redshift Serverless は、データウェアハウスの容量を自動的にプロビジョニングしてインテリジェントにスケーリングし、あらゆる分析において最高水準のパフォーマンスを実現します。ワークロードの実行中に使用された 1 秒単位のコンピューティング量に対してのみ課金されます。既存の分析アプリケーションや BI アプリケーションに変更を加えることなく、このシンプルさを活用できます。また、AWS アカウント内または複数の Amazon Redshift Serverless インスタンス間で、読み取り目的でデータを共有することもできます。

そのため、Redshift Serverless を使用することで定期実行クラスターを一時停止および再開するためのスクリプトが不要になるので管理を容易にする可能性や、ワークロードの粒度を改善できる可能性も検討できます。

まとめ

この記事では、RA3 ノード、データ共有、クラスターの一時停止と再開を使用して Amazon Redshift クラスターのワークロードを最適化する方法について説明しました。また、コード変更を最小限に抑えてワークロードのパフォーマンスを向上させるために、マルチクラスターの双方向データ共有ソリューションを実装するユースケースについても調査しました。ご質問やご意見がございましたら、コメント欄にご記入ください。

翻訳はプロフェッショナルサービスの石黒が担当しました。原文はこちらです。