Amazon Web Services ブログ

Simple Replay ユーティリティで Amazon Redshift RA3 への移行評価を簡易化

本記事は Amazon Web Services, Senior Analytics Specialist Solutions Architect である Manash Deb, Senior Database Engineer である Srinath Madabushi によって投稿されたものです。

Amazon Redshift は、高速かつフルマネージドであり広く普及しているクラウドデータウェアハウスです。標準 SQL を使用して、データウェアハウス、業務データベース、データレイク全体でエクサバイト単位のデータを処理できます。Amazon Redshift では様々なワークロードに対応するために複数のノードタイプが用意されており、要件に応じて RA3、DC2、DS2 から選択できます。RA3 は最新のインスタンスタイプで、コンピューティングとストレージを個別にスケーリングして料金を支払うことができます。また、クラスター間のデータ共有やアベイラビリティーゾーン間のクラスター再配置などの高度な機能も使用できます。アップグレード時のノード数とノードタイプに関する推奨事項の詳細については、RA3 ノードタイプへのアップグレードを参照してください。

マネージドストレージを備えた新しい Amazon Redshift RA3 ノードを使用して、クラウドデータウェアハウスを拡張し、コストを削減 と Amazon Redshift ベンチマーク: RA3 と DS2 インスタンスタイプの比較 では、DS2 から RA3 への移行の利点を詳細に説明しています。既存の DS2 をお使いのお客様に加え、DC2 をお使いのお客様の多くも、RA3 のメリットについて学び、パフォーマンスを評価した後に RA3 へ移行しました。しかし、この新しい RA3 ノードタイプのパフォーマンスを評価するためには、既存のワークロードを手動で再現する必要があります。

Simple Replay ツールを使用することで what-if 分析を実行し、様々な条件におけるワークロードのパフォーマンスを評価できます。例えば RA3 などの新しいインスタンスタイプで本番ワークロードのベンチマークテストをしたり、新しい機能を評価したり、異なるクラスター構成を評価することができます。また、COPY および UNLOAD ステートメントを使用した、データ取り込みおよびエクスポートを行うパイプラインのリプレイのサポートも強化されています。ワークロードのリプレイを始めるには、Amazon Redshift GitHub リポジトリ からツールをダウンロードします。

この投稿では、Amazon Redshift Simple Replay ユーティリティを使用して Amazon Redshift RA3 インスタンスの評価を自動化する手順について説明します。旧世代の DS2 および DC2 ノードタイプを使用して Amazon Redshift で本番ワークロードを実行している場合、このソリューションを使用することでソースとなる本番クラスターからワークロードのログを自動的に抽出し、本番から分離された環境でワークロードをリプレイすることができます。これにより、2つの Amazon Redshift クラスターのパフォーマンスの直接比較をシームレスに行うことができます。

前提条件

このソリューションでは、AWS CloudFormation を使用して必要なすべてのリソースを自動的に AWS アカウントへプロビジョニングします。詳細については、AWS CloudFormation の開始方法を参照してください。
このソリューションの前提条件として、次の手順を完了する必要があります。これらの手順、およびその後のデプロイを実行するには、AWS アカウントの管理者権限が必要になる場合があります。
Amazon Redshift コンソールから、ソースの Amazon Redshift クラスターで監査ログ作成を有効化し、ログファイルを保存する Amazon Simple Storage Service (Amazon S3) バケットの場所を指定します。詳細については、データベース監査ログ作成を参照してください。
パラメータグループの enable_user_activity_logging を true に変更します。詳細については、コンソールを使用したパラメータグループの管理を参照してください。
クラスターを再起動します。
CloudFormation テンプレートをデプロイする予定の AWS アカウントで Amazon Elastic Compute Cloud (Amazon EC2) キーペアを作成します。詳細については、Amazon EC2 を使用してキーペアを作成する を参照してください。

ソリューションの概要

このソリューションは、ワークロードの抽出 (Extract) とリプレイ (Replay) を実行する 2 つの CloudFormation テンプレートで構成されています。抽出とリプレイのテンプレートは、 Amazon Redshift クラスターがホストされているのと同じアカウントに両方をデプロイすることが可能であり、推奨されます。もしくは次の図に示すように本番アカウントで抽出テンプレートを実行し、分離された開発アカウントでリプレイテンプレートを実行して評価を行うことも可能です。


このプロセスでは AWS Step Functions と AWS Lambda を使用して、抽出とリプレイのためのエンドツーエンドのワークフローをオーケストレートします。1つ目のテンプレートはソースとなるアカウントに抽出アプリケーションをデプロイします。これにより Amazon Redshift 監査ログ用の S3 バケットから監査ログが抽出され、リプレイ用に作成された新しい S3 バケットへ格納されます。またクラスターの手動スナップショットを作成し、リプレイ用アカウントに復元を許可します。


2 つ目のテンプレートは、開発アカウントにリプレイアプリケーションをデプロイします（ソースのアカウントでリプレイを実行しない場合）。これは抽出アプリケーションで出力した Amazon S3 上のファイルを使用し、リプレイの自動評価サマリーを生成します。

エンドツーエンドのワークフロー: 抽出プロセス

抽出プロセスは、抽出対象の期間を入力することで開始します。ソースとなるクラスターから監査ログを自動的に抽出し、そのアカウントの新しい S3 バケットにこれらのログを保存します。また Simple Replay ユーティリティがインストールされた、サイズが m5.large の Amazon EC2 インスタンスをデプロイします。次の図はソリューションのアーキテクチャを示しています。次の図は、抽出プロセスで用いる AWS Step Functions ステートマシンです。

ステートマシンは以下のステップを実行して、ソースクラスターのメタデータを抽出 S3 バケットへ抽出します。
ソースクラスターが使用可能な状態になるまで待ちます。
ソースクラスターから手動スナップショットを作成します。識別子は ra3-migration-evaluation-snapshot- とクラスター識別子を連結した文字列です。
リプレイプロセスを実行するターゲットアカウントにスナップショットを許可します。
ソースクラスター設定パラメータを抽出 S3 バケットにアップロードします。
抽出プロセスを実行してソースクラスターからログを取得し、抽出 S3 バケットに配置します。
抽出 CloudFormation テンプレートは、抽出プロセスの初回の実行を自動的に開始します。ただし、次のコードのように入力パラメーター start_time と end_time を指定してステートマシンに渡すことでいつでも抽出プロセスを再実行できます。

{"input": {"start_time": "<<Extract_Start_Time>>", "end_time": "<<Extract_End_Time>>"}}

start_time と end_time の値は ISO-8601 形式の日時 (例: 2021-03-05T12:30:00+00:00) に置き換えてください。次のスクリーンショットは、ステートマシンの実行のインプットです。


抽出プロセス用の CloudFormation テンプレートは、ソースクラスターがホストされているのと同じアカウントにデプロイする必要があります。このテンプレートでは、次のパラメータを指定する必要があります。

  • SourceRedshiftClusterEndpoint – 非 RA3 のソースクラスターエンドポイント。ポート番号とデータベース名を含みます。
  • AccountIdForReplay – 別のアカウントでリプレイプロセスを実行する場合は、このパラメータに 12 桁の AWS アカウント ID を入力します。同じアカウントで抽出とリプレイプロセスを実行している場合は、N/A を入力します。
  • SimpleReplayStartTime – ソースクラスターから抽出プロセスを初回実行する際に使用する、 ISO-8601 形式の開始時刻です (例: 2021-01-20T 21:41:16+00:00) 。これは、後で抽出ステートマシンに入力する JSON から変更できます。
  • SimpleReplayEndTime – ソースクラスターから抽出してターゲット RA3 クラスターでリプレイする際に使用する、ISO-8601 形式の終了時刻です。これは、後で抽出ステートマシンに入力する JSON から変更できます。開始時刻と終了時刻の差が24時間を超えないようにしてください。
  • ExtractSystemTables – これはオプションであり、ソースクラスターのシステムテーブルを抽出する場合に使用します。このパラメータは No に設定することを推奨します。これは、ソースクラスターからシステムテーブルのアンロードを実行するために、AWS Identity and Access Management ロールをソースクラスターに追加するためです。
  • EndUserIamRoleName – 抽出・リプレイの評価を実行する可能性があるエンドユーザーの IAM ロール名です。このパラメータを使用して、管理者以外のユーザーが AWS リソースに対する他のアクセス権限なしで抽出・リプレイステートマシンを実行できるようにします。エンドユーザー権限を設定しない場合は、N/A と入力します。
  • EC2InstanceAMI – Amazon Linux 2 ベースの EC2 インスタンス用の AMI です。コンプライアンス要件で必要でない限り、このパラメータのデフォルトの AMI を使用することを推奨します。

テンプレートをデプロイした後、テンプレートの [出力] タブに移動します。このタブには、リプレイプロセスのデプロイに必要な関連パラメータが表示されます。

エンドツーエンドのワークフロー: リプレイプロセス

本ソリューションの 2 番目のステップでは、抽出プロセスが実行されたのと同じアカウント、または同じリージョンの別のアカウントに CloudFormation テンプレートを使用してリプレイプロセスをデプロイします。
このプロセスでは、2 つの Amazon Redshift クラスターをプロビジョニングします。1 つはソースクラスターと全く同じ構成のレプリカクラスターで、もう 1 つは RA3 構成のターゲットクラスターです。Simple Replay ユーティリティがインストールされた M5 ファミリーの 2 つの EC2 インスタンスをデプロイし、抽出されたワークロードをこれらのクラスターで同時にリプレイします。リプレイプロセスでは、ソースクラスターのワークロードを正確に模倣するためにクエリとトランザクションの間の時間間隔が保持されるため、このプロセスには、抽出プロセスの実行中に指定した start_time から end_time の期間とほぼ同じ時間がかかります。次の図は、ソリューションのアーキテクチャを示しています。


次の図は、リプレイプロセスの Step Functions ステートマシンを示しています。

ステートマシンは以下のステップを実行して、抽出 S3 バケットへ抽出されたワークロードをリプレイします。

  1. Amazon Redshift パラメータグループを、ソースクラスターのパラメータグループと同じ設定に更新します。このパラメータグループは、抽出プロセスの一部として抽出 S3 バケットに保存されています。
  2. レプリカクラスターとターゲットクラスターが存在しない場合は、それらのクラスターの作成を並列で開始します。レプリカクラスターはソースクラスターとまったく同じ構成で作成され、ソースクラスターが RA3 の Elastic resize に対応している場合、ターゲットクラスターは RA3 構成で作成されます。構成は CloudFormation テンプレートのデプロイ時に指定したものです。ターゲットの RA3 構成が Elastic resize に対応していない場合は、レプリカクラスターと同じ設定でターゲットクラスターが作成されます。
  3. 前のステップで、Elastic resize との互換性がないために非 RA3 構成でターゲットクラスターを作成した場合、クラスターが使用可能になったときに、そのクラスターで Classic resize が実行されます。
  4. ターゲットクラスターまたはレプリカクラスターが一時停止状態の場合、クラスターを再開します。
  5. ターゲットクラスターまたはレプリカクラスターが利用可能な状態にあり、そのクラスターでリストア (該当する場合) が完了すると、自動パフォーマンス比較に必要ないくつかの Amazon Redshift オブジェクトをクラスターのパブリックスキーマにセットアップする SQL スクリプトが実行されます。
  6. ターゲットクラスターとレプリカクラスターの両方のセットアップが完了すると、両方のクラスターでリプレイプロセスが同時に実行されます。これにより、ソースクラスターから抽出されたすべての SQL が実行されます。トランザクションの順序と時間間隔はソースクラスターと同じになるよう維持されます。
  7. リプレイプロセスが完了すると、クエリ統計がレプリカクラスターからアンロードされ、ターゲット RA3 クラスターにロードされます。これにより、 RA3 クラスター同士の直接のパフォーマンス比較が可能になります。

リプレイプロセスの CloudFormation テンプレートは、リプレイプロセスの初回実行を自動的に開始します。また、パラメータなしでステートマシンを実行することでいつでもプロセスを再実行できます。このテンプレートでは、次のパラメータを指定する必要があります。

  • SourceAccountNumber – 抽出プロセスを実行した、ソースのAWSアカウントID。抽出スタックの [出力] タブに表示されます。
  • SourceAccountSimpleReplayS3Bucket – 抽出テンプレートによって作成された抽出 S3 バケット。スタックの [出力] タブに表示されます。
  • SourceRedshiftClusterEndpoint – ポート番号とデータベース名を含む、非 RA3 のソースクラスターエンドポイント (スタックの [出力] タブに表示されます)。
  • SourceRedshiftClusterKMSKeyARN – ソース Redshift クラスターが暗号化されている場合、AWS Key Management Service (KMS) のキーの ARN (Amazon Resource Name) (スタックの [出力] タブに表示されます) 。ソースクラスターが暗号化されている場合は、同じアカウントで抽出とリプレイを実行する必要があります。
  • SourceRedshiftClusterMasterUsername – ソースクラスターのプライマリユーザーアカウントに関連付けられているユーザー名 (スタックの [出力] タブに表示されます)。
  • SourceRedshiftClusterPrimaryDatabase – ワークロードをリプレイするソースクラスター内のプライマリデータベース名。Amazon Redshift は、dev という名前のデフォルトデータベースを自動的に作成しますが、プライマリデータベースではない場合があります。デプロイメントに基づいて値を入力してください。複数のデータベースがある場合は、データベースの抽出とリプレイを一度に1つずつ実行する必要があります。
  • TargetRedshiftClusterNodeType – プロビジョニングされる RA3 ノードのタイプ。RA3 ノードタイプへのアップグレードで提案されているように、ノードタイプとノード数を使用することをお勧めします。
  • TargetRedshiftClusterNumberOfNodes – クラスター内のコンピュートノードの数。
  • EndUserIamRoleName – 抽出・リプレイ評価を実行する可能性があるエンドユーザーの既存の IAM ロール名。このパラメータを使用して、管理者以外のユーザーが AWS リソースに対する他のアクセス権限なしで抽出・リプレイステートマシンを実行できるようにします。エンドユーザー権限を設定しない場合は、N/A を入力します。
  • GrantS3ReadOnlyAccessToRedshift – 抽出プロセスとリプレイプロセスを同じアカウントにデプロイする場合は、このパラメータに Yes を設定します。これにより、アカウント内の Amazon Redshift から COPY 文をリプレイするために、Amazon Redshift ターゲットクラスターとレプリカクラスターへの Amazons3ReadOnlyAccess が付与されます。それ以外の場合は、ファイルを手動でコピーし、抽出 S3 バケットの最新の抽出フォルダにある copy_replacement.csv ファイルを修正し、リプレイ S3 バケットの config/replay.yaml ファイルで COPY 文のパラメータを true に設定する必要があります。
  • VPC – クラスターと EC2 インスタンスをデプロイする、既存の Amazon Virtual Private Cloud (Amazon VPC)。
  • SubnetId – クラスターと EC2 インスタンスをデプロイする VPC 内の既存のサブネット。
  • KeyPairName – リプレイ EC2 インスタンスへの SSH を許可する既存のキーペア。
  • OnPremisesCIDR – SQL クライアントからターゲットクラスターとレプリカクラスターにアクセスするための既存のインフラストラクチャの IP 範囲 (CIDR 表記)。不明な場合は、お使いの PC の CIDR アドレスを設定します。例えば、デスクトップ PC の IP アドレスが 10.156.87.45 の場合は、10.156.87.45/32 を入力します。
  • EC2InstanceType – Simple Replay ユーティリティのコードベースをホストする EC2 インスタンスタイプ。クラスターのデータサイズが 1 TB 未満の場合は、large インスタンスタイプを使用できます。大きなワークロードの場合、クラスターからクエリ結果を取得する際に EC2 インスタンスがボトルネックとならないよう、より大きなインスタンスタイプを推奨します。
  • EC2InstanceVolumeGiB – EC2 インスタンスボリュームのサイズ (GiB 単位) 。30 GiB 以上にしておくことを推奨します。
  • EC2InstanceAMI – Amazon Linux 2 ベースの EC2 インスタンス用の AMI 。コンプライアンス要件に必要な場合以外は、このパラメータを変更しないでください。

アクセス権限とセキュリティ

AWS CloudFormation でこのソリューションをデプロイするには、抽出とリプレイのプロセスをデプロイする予定の AWS アカウントの管理者アクセス権が必要です。いずれのテンプレートも、EndUserIamRoleName の入力パラメータを設定します。このパラメータを使用すると、管理者以外のユーザーがシステムリソースに対する広範な権限なしでプロセスを実行できます。
CloudFormation テンプレートは、最小権限の原則に基づいてセキュリティのベストプラクティスを使用して必要なすべてのリソースをプロビジョニングし、アカウントの VPC 内にすべてのリソースをホストします。EC2 インスタンスと Amazon Redshift クラスターは同じセキュリティグループを共有しており、EC2 インスタンスへの SSH アクセスは許可されていません。Amazon Redshift ターゲットクラスターとレプリカクラスターへのアクセスは、CloudFormation テンプレートパラメーターの OnPremisesCIDR で制御されます。このパラメーターは、オンプレミスのユーザーが Amazon Redshift ポートへ SQL クライアントを使用して新しいクラスターに接続できるようにするために設定する必要があります。
すべてのリソースのアクセス許可は、Amazon Redshift、Lambda、ステップ関数、および Amazon EC2 に適切なアクセス権限を付与する IAM ロールを使用して制御されます。読み取りおよび書き込みアクセス権限は抽出プロセスによって作成された S3 バケットに対して、リプレイプロセスで使用される AWS アカウントに付与され、そのバケットの設定を読み取って更新することができます。

RA3 のパフォーマンスを評価する

リプレイステートマシンの初回の実行が完了すると、リプレイテンプレートがデプロイされた AWS アカウントの Amazon Redshift コンソールで、RA3 ターゲットクラスターと RA3 以外のレプリカクラスターを表示できるはずです。リプレイを繰り返すたびに、ターゲット RA3 クラスターのパブリックスキーマに次のテーブルとビューが自動的に作成され、クラスター同士のパフォーマンスを直接比較できます。

  • source_target_comparison — 2 つのクラスターがワークロードのリプレイにかかった時間の比較サマリーです。Amazon Redshift キューとユーザー名でグループ化された total_query_time_saved_seconds 列を提供しており、最終的な評価に非常に役立ちます。
  • source_target_comparison_raw — クエリごとに 2 つのクラスターにかかった時間の詳細な比較を提供します。
  • replica_cluster_query_stats — レプリカクラスターで実行されたリプレイのクエリレベルのメトリクスを格納します。
  • target_cluster_query_stats — RA3 クラスターで実行されたリプレイのクエリレベルのメトリクスを格納します。
  • source_cluster_query_stats — ソースクラスターのクエリレベルのメトリクスを格納します。このテーブルは、ソースクラスターの STL ログビューに依存しており、2〜5 日間しか保持されないため、空の可能性があります。詳細については、ログ記録のための STL ビューを参照してください。
  • detailed_query_stats — query_stats テーブルを作成し、STL ログビューからこれらの統計情報を入力するために使用するロジックを提供します。

コストとタイムラインに関する考慮事項

このテンプレートを AWS アカウントで実行すると、新しい Amazon Redshift クラスターと 3 つの EC2 インスタンスがプロビジョニングされるため、コスト管理に気をつける必要があります。リザーブドインスタンスがない場合は、オンデマンドインスタンスとして課金される場合があります。評価が完了したら、CloudFormation スタックを削除することを推奨します。これにより、抽出およびリプレイ用の 2 つの S3 バケットを除くすべての関連リソースが削除されます。また、使用していないときはクラスターを一時停止することを推奨します。詳細については、Amazon Redshift の料金 および Amazon EC2 の料金 を参照してください。

制約事項

Simple Replay とこの自動化プロセスには、いくつかの既知の制約があります。

  • Amazon S3 への監査ログの配信に遅延がある場合、抽出プロセスが失敗することがあります。その場合は、前回の実行時とは異なる時間間隔を選択して、抽出ステートマシンを再実行する必要があります。
  • 複数のコネクションにまたがった依存関係がある SQL クエリは元の実行順序が保証されません。
  • ターゲットクラスターが外部テーブルにアクセスできない場合、Redshift Spectrum クエリはリプレイされません。
  • BIND 変数を含むクエリはリプレイされません。
  • JDBC を使用したリプレイはサポートされていません。
  • 大規模なデータ取得が同時に発生すると、Amazon EC2 クライアントに負荷がかかることがあります。このような場合には、より大きな EC2 インスタンスが必要になる場合があります。
  • 監査ログには、本番クラスターに送信されなかった SQL が含まれる場合があります。これらの SQL はリプレイの対象となります。

本番環境の Amazon Redshift クラスターと直接比較するのではなく、レプリカクラスターとターゲットクラスターを比較することで、これらの制約の影響を最小限に抑えることができます。

まとめ

Amazon Redshift RA3 インスタンスは、以前のインスタンスと比較して多くの新たな利点があります。RA3 インスタンスタイプへの移行を検討しているが評価にかかる労力を懸念されている場合、Amazon Redshift Simple Replay ユーティリティを使用することで、RA3 ノードへの移行評価を簡易かつシームレスに実行できます。
RA3 インスタンスタイプのパフォーマンスが十分な場合は、本番クラスターでサイズ変更を実行することで RA3 へ移行できます。本番クラスターのサイズ変更にかかる時間は、Elastic Resize と Classic Resize のどちらを使用したかによりますが、テスト用の RA3 クラスターを作成するのと同程度かかります。また、本番クラスターのサイズ変更操作を実行する前に手動スナップショットを作成することを推奨します。

原文はこちらです。
本ブログは Solutions Architect の濱岡が翻訳しました。