Amazon Redshift DC2 から RA3 および Amazon Redshift Serverless へのアップグレードのベストプラクティス

Amazon Redshift は、標準 SQL と既存のビジネスインテリジェンス（BI）ツールを使用してデータを簡単かつ費用対効果高く分析できる、高速でペタバイト規模のクラウドデータウェアハウスです。何万もの顧客が Amazon Redshift を利用してエクサバイト規模のデータを分析し、複雑な分析クエリを実行して、最高のコストパフォーマンスを実現しています。

完全マネージド型の AI 駆動による Massively Parallel Processing（MPP）アーキテクチャを備えた Amazon Redshift は、迅速かつコスト効率的にビジネス意思決定を推進します。以前、Amazon Redshift はコンピュート集約型ワークロードに最適化された DC2（Dense Compute）ノードタイプを提供していました。しかし、これらはコンピュートとストレージを独立してスケーリングする柔軟性に欠け、現在利用可能な多くの最新機能をサポートしていませんでした。分析需要の増大に伴い、多くのお客様が DC2 から RA3 または Amazon Redshift Serverless へアップグレードしています。これらは独立したコンピュートとストレージのスケーリングを提供し、データ共有、ゼロ ETL 統合、Amazon Redshift ML による組み込みの人工知能および機械学習（AI/ML）サポートなどの高度な機能を備えています。

この記事では、ターゲットアーキテクチャと移行戦略を計画するための実践的なガイドを提供し、アップグレードオプション、主要な考慮事項、および成功したシームレスな移行を促進するためのベストプラクティスをカバーしています。

DC2 ノードから RA3 および Redshift Serverless へのアップグレードプロセス

アップグレードへの第一歩は、新しいアーキテクチャをどのようにサイジングすべきかを理解することです。このために、AWS はプロビジョニングされたクラスター用の推奨表を提供しています。Redshift Serverless エンドポイントの構成を決定する際は、RPU とメモリの関係を調べることで、コンピューティング容量の詳細を評価できます。各 RPU は 16 GiB の RAM を割り当てます。ベース RPU 要件を見積もるには、DC2 ノードクラスターの合計 RAM を 16 で割ります。これらの推奨事項は、初期ターゲットアーキテクチャのサイジングに関するガイダンスを提供しますが、ワークロードのコンピューティング要件に依存します。要件をより適切に見積もるには、Redshift Test Drive を使用して潜在的な構成を実行する概念実証の実施を検討してください。詳細については、「Redshift Test Drive を使用してワークロードに最適な Amazon Redshift 構成を見つける」および「Amazon Redshift で概念実証を実施する」を参照してください。ターゲット構成とアーキテクチャを決定した後、アップグレード戦略を構築できます。

アーキテクチャパターン

最初のステップは、ソリューションのターゲットアーキテクチャを定義することです。「Amazon Redshift のパフォーマンスを大規模に最適化するためのアーキテクチャパターン」で提示されているオプションから、ユースケースに最も適合するメインのアーキテクチャパターンを選択できます。次の図に示すように、主に2つのシナリオがあります。

執筆時点では、Redshift Serverless には手動のワークロード管理機能がなく、すべてが自動ワークロード管理で実行されます。独立したスケーリングとより良いパフォーマンスを実現するために、ユースケースに基づいてワークロードを複数のエンドポイントへ分離することを検討してください。詳細については、「Amazon Redshiftのパフォーマンスを大規模に最適化するためのアーキテクチャパターン」を参照してください。

アップグレード戦略

DC2 ノードから RA3 ノードまたは Redshift Serverless へのアップグレード時には、2つのアップグレードオプションから選択できます：

リアーキテクチャ：最初のステップでは、ワークロードを評価してモダンなデータアーキテクチャの導入効果があるかを判断します。次に、DC2 ノードからのアップグレードと同時に、既存プラットフォームのリアーキテクチャを実施します。
段階的アプローチ：これは2段階の戦略です。第1段階では、ターゲットの RA3 または Serverless 構成への単純な移行を行います。第2段階では、最先端の Redshift 機能を活用してターゲットアーキテクチャをモダナイズできます。

通常、段階的なアプローチを推奨しています。これにより、将来の最適化を可能にしながら、よりスムーズな移行が実現できます。段階的アプローチの第1段階は、以下のステップで構成されています：

既存の DC2 クラスターに相当する RA3 ノードまたは Redshift Serverless の構成を評価します。プロビジョニングされたクラスターのサイジングガイドラインまたはサーバーレスエンドポイントのコンピューティング容量オプションを使用します。
Redshift Test Drive を使用して、非本番環境で選択したターゲット構成を検証します。この自動化ツールにより、本番ワークロードのシミュレーションプロセスが簡素化されます。さまざまな潜在的なターゲット構成で包括的な what-if 分析を実行できます。
特定のターゲット構成の価格対性能比に満足できたら、次のセクションで詳述する方法のいずれかを使用してアップグレードプロセスに進みます。

Redshift RA3 インスタンスと Redshift Serverless は、ゼロ ETL、Amazon Redshift Streaming Ingestion、データ共有を使用したマルチウェアハウス書き込み、独立したコンピュートとストレージのスケーリングなど、強力な新機能へのアクセスを提供します。これらのメリットを最大限に活用するために、現在のアーキテクチャの包括的なレビュー（段階的アプローチの第2段階）を実施し、Amazon Redshiftの最新機能を使用したモダナイゼーションの機会を特定することをお勧めします。例えば：

データ共有を使用したマルチウェアハウスアーキテクチャを実装し、ワークロードを分離してパフォーマンスを向上させる
現在、トランザクショナルソースから Amazon Redshift へのデータ転送に AWS Database Migration Service（AWS DMS）を使用している場合は、ゼロ ETLを実装して運用を効率化し、メンテナンスのオーバーヘッドを削減する

アップグレードオプション

DC2 から RA3 または Redshift Serverless へのクラスターのリサイズまたはアップグレードには、スナップショットの復元、Classic resize、Elastic resize の3つの方法から選択できます。

スナップショットの復元

スナップショット復元方式は、既存の（ソース）クラスターのスナップショットを取得することから始まる順次的なプロセスに従います。このスナップショットは、希望する性能で新しいターゲットクラスターを作成するために使用されます。作成後、データがターゲットクラスターに正しく転送されたことを確認して、データの整合性を検証することが不可欠です。重要な考慮事項として、最初のスナップショット後にソースクラスターに書き込まれたデータは、同期を維持するために手動で転送する必要があります。

この方式には以下の利点があります：

既存の DC2 クラスターに影響を与えることなく、新しい RA3 または Serverless セットアップの検証が可能
異なる AWS リージョンまたはアベイラビリティーゾーンへの復元の柔軟性を提供
移行中の書き込み操作に対するクラスターのダウンタイムを最小限に抑える

ただし、以下の考慮事項に留意してください：

セットアップとデータの復元は、Elastic resize よりも時間がかかる場合があります。
スナップショット作成後にソースクラスターに書き込まれた新しいデータは、ターゲットへの手動コピーが必要になるため、データ同期の課題に直面する可能性があります。このプロセスは完全な同期を達成するために複数回の反復が必要になる場合があり、カットオフ前にダウンタイムが必要になることがあります。
新しい Redshift エンドポイントが生成されるため、接続の更新が必要になります。元のエンドポイントを維持するため、両方のクラスターの名前変更を検討してください（新しいターゲットクラスターが元のソースクラスターの名前を採用するようにしてください）。

Classic resize

Amazon Redshift はターゲットクラスターを作成し、バックアップおよび復元を使用してソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータは、新しいクラスターに正確に転送されます。ソースクラスターは最初に再起動し、数分間使用できなくなるため、ダウンタイムは最小限に抑えることができます。すぐに再開され、バックグラウンドでリサイズが継続される間、読み取りと書き込みの両方の操作が可能になります。
Classic resize は2段階のプロセスです：

ステージ1（クリティカルパス）：このステージでは、ソースとターゲットの構成間でメタデータの移行が行われ、ソースクラスターが一時的に読み取り専用モードになります。この初期フェーズは通常、短時間で完了します。このフェーズが完了すると、クラスターは読み取りおよび書き込みクエリで使用可能になります。KEY 分散スタイルで最初に構成されたテーブルは一時的に EVEN 分散を使用して保存されますが、プロセスのステージ2でオリジナルの KEY 分散に再分散されます。
ステージ2（バックグラウンド操作）：このステージは、データを元の分散パターンに復元することに焦点を当てています。この操作は、主要な移行プロセスに影響を与えることなく、低優先度でバックグラウンドで実行されます。このステージの期間は、再分散されるデータ量、進行中のクラスターワークロード、使用されているターゲット構成など、複数の要因によって異なります。

全体的なリサイズ期間は、主に処理されるデータ量によって決まります。Amazon Redshift コンソールで進行状況を監視するか、変換中のテーブルの完了率を表示する SYS_RESTORE_STATE システムビューを使用して監視できます（このビューへのアクセスにはスーパーユーザー権限が必要です）。
Classic resize アプローチには、以下の利点があります：

すべての可能なターゲットノード構成がサポートされています
ソースクラスターの包括的な再構成により、データスライスがノードごとのデフォルトに再バランスされ、ノード間でデータが均等に分散されます

ただし、以下の点に留意してください：

ステージ2 では、最適なパフォーマンスのためにデータを再分散します。しかし、ステージ2 は低い優先度で実行され、ビジーなクラスターでは完了までに長時間かかることがあります。プロセスを高速化するには、KEY DISTSTYLE を持つテーブルに対して ALTER TABLE DISTSTYLE コマンドを手動で実行できます。このコマンドを実行することで、データの再配布を優先的に実行でき、進行中のステージ2 プロセスによる潜在的なパフォーマンス低下を軽減できます。
ステージ2 のバックグラウンド再分散プロセスのため、リサイズ操作中はクエリの完了に時間がかかることがあります。軽減策として同時実行スケーリングの有効化を検討してください。
データ分散を高速化するため、リサイズを開始する前に不要で使用されていないテーブルを削除してください。
リサイズ操作に使用されるスナップショットは、この操作専用になります。そのため、テーブルの復元やその他の目的には使用できません。
クラスターは仮想プライベートクラウド（VPC）内で動作する必要があります。
このアプローチでは、Classic resize を開始する前に取得した新しいまたは最近の手動スナップショットが必要です。
ビジネスへの影響を最小限に抑えるため、オフピーク時間またはメンテナンスウィンドウ中に操作をスケジュールすることをお勧めします。

Elastic resize

Elastic resize を使用してノードタイプを変更する場合、Amazon Redshift は順次プロセスに従います。まず既存のクラスターのスナップショットを作成し、そのスナップショットの最新データを使用して新しいターゲットクラスターをプロビジョニングします。バックグラウンドでデータが新しいクラスターに転送される間、システムは読み取り専用モードのままです。リサイズ操作が完了に近づくと、Amazon Redshift は自動的にエンドポイントを新しいクラスターにリダイレクトし、元のクラスターへのすべての接続を停止します。このプロセス中に問題が発生した場合、システムは通常、手動介入を必要とせずに自動ロールバックを実行しますが、そのような障害は稀です。
Elastic resize にはいくつかの利点があります：

平均 10 ～ 15 分で完了する迅速なプロセスです
ユーザーはプロセス中もデータへの読み取りアクセスを維持でき、中断は最小限に抑えられます
クラスターエンドポイントは操作中および操作後も変更されません

このアプローチを検討する際は、以下の点に留意してください：

Elastic resize 操作は、EC2-VPC プラットフォームを使用するクラスターでのみ実行できます。そのため、Redshift Serverless では利用できません。
ターゲットノード構成は、既存のデータに対して十分なストレージ容量を提供する必要があります。
すべてのターゲットクラスター構成が Elastic resize をサポートしているわけではありません。そのような場合は、Classic resize またはスナップショット復元を検討してください。
プロセスが開始された後、Elastic resize を停止することはできません。
データスライスは変更されません。これにより、データまたは CPU の偏りが発生する可能性があります。

アップグレード推奨事項

次のフローチャートは、適切な Amazon Redshift アップグレード方法を選択するための意思決定プロセスを視覚的にガイドします。

Amazon Redshift をアップグレードする際、その方法はターゲット構成と運用上の制約によって異なります。Redshift Serverless の場合は、常にスナップショット復元方式を使用します。RA3 プロビジョニングクラスターにアップグレードする場合は、2つのオプションから選択できます。ダウンタイムを伴う完全なメンテナンスウィンドウが許容できる場合はスナップショット復元を使用し、ダウンタイムを最小限に抑えたい場合は Classic resize を選択します。Classic resize は、データスライスをノードごとのデフォルトにリバランスし、ノード間でデータを均等に分散させるためです。特定の範囲内での特定のノードタイプの変更（例：DC2 から RA3）には Elastic resize を使用できますが、Elastic resize はスライス数を変更しないため、データや CPU の偏りが生じる可能性があり、後で Redshift クラスターのパフォーマンスに影響を与える可能性があるため、推奨されません。ただし、既存のクラスターでノードを追加または削減する必要がある場合は、Elastic resize が引き続き主要な推奨事項となります。

移行のベストプラクティス

移行を計画する際は、以下のベストプラクティスを検討してください：

Amazon Redshift Advisor または Amazon CloudWatch を使用して、移行前の評価を実施する。
ユースケースとワークロードに基づいて、適切なターゲットアーキテクチャを選択する。Redshift Test Drive を使用して、適切なターゲットアーキテクチャを決定する。
手動スナップショットを使用してバックアップを作成し、自動ロールバックを有効にする。
ステークホルダーにタイムライン、ダウンタイム、変更内容を伝える。
新しいアーキテクチャの詳細とエンドポイントでランブックを更新する。
ベンチマークとデータチェックサムを使用してワークロードを検証する。
最終同期と切り替えにはメンテナンスウィンドウを使用する。

これらのプラクティスに従うことで、パフォーマンス、コスト、運用の継続性のバランスを取りながら、低リスクな移行を実現できます。

結論

Redshift DC2 ノードから RA3 ノードまたは Redshift Serverless への移行には、パフォーマンス、コスト効率、および最小限の中断をサポートするための構造化されたアプローチが必要です。ワークロードに適したアーキテクチャを選択し、移行後のデータとワークロードを検証することで、組織はデータプラットフォームをシームレスに最新化できます。このアップグレードにより長期的な成功が促進され、チームは RA3 のスケーラブルストレージまたは Redshift Serverless の自動スケーリング機能を最大限に活用しながら、コストとパフォーマンスを最適化できるようになります。

著者について

Ziad Wali は、AWS のアナリティクススペシャリストソリューションアーキテクトです。データベースとデータウェアハウジングにおいて10年以上の経験を持ち、信頼性が高く、スケーラブルで効率的なソリューションの構築を得意としています。仕事以外では、スポーツや自然の中で過ごすことを楽しんでいます。

Omama Khurshid は、Amazon Web Services のアナリティクスソリューションアーキテクトです。彼女は、さまざまな業界のお客様が信頼性、拡張性、効率性に優れたソリューションを構築できるよう支援することに注力しています。仕事以外では、家族との時間を過ごしたり、映画鑑賞、音楽鑑賞、新しい技術の学習を楽しんでいます。

Srikant Das は、Amazon Web Services のアナリティクススペシャリストソリューションアーキテクトとして、アナリティクスと AI においてスケーラブルで堅牢なクラウドソリューションを設計しています。技術的な専門知識に加えて、魅力的なブログを通じて旅行の冒険やデータインサイトを共有し、ソーシャルメディア上で分析的な厳密さとストーリーテリングを融合させています。

翻訳は、ソリューションアーキテクトの駒野が担当しました。原文はこちらです。

Amazon Web Services ブログ