Amazon Web Services ブログ

Amazon Redshift DC2 ノードタイプから Amazon Redshift Serverless へのアップグレード

Amazon Redshift は、完全マネージド型のペタバイト規模のクラウドデータウェアハウスサービスです。Amazon Redshift を使用することで、ペタバイト規模の構造化データおよび半構造化データに対して複雑なクエリを迅速かつ効率的に実行でき、他の AWS サービスとシームレスに統合できます。

Amazon Redshift Serverlessは、データウェアハウスインフラストラクチャのセットアップ、管理、スケーリングを行うことなく、数秒で分析を実行およびスケーリングできるようサポートします。要求の厳しいワークロードに対して高速なパフォーマンスを提供するために、データウェアハウスの容量を自動的にプロビジョニングし、基盤となるリソースをインテリジェントにスケーリングします。また、使用したコンピューティング容量に対してのみ料金をお支払いいただきます。さらに、Amazon Redshift マネージドストレージを使用することで、ストレージとコンピューティングを個別にスケーリングし、使用したストレージに対してのみ料金をお支払いいただくことで、データウェアハウスをさらに最適化できます。

Amazon Redshift dense compute (DC2) インスタンスから Amazon Redshift Serverless へデータウェアハウスをアップグレードすることでこれらの利点が得られ、ユーザーエクスペリエンスの向上と運用の簡素化を実現し、より効率的でスケーラブルなデータ分析ソリューションを提供します。

この記事では、DC2 インスタンスから Amazon Redshift Serverless へのアップグレードプロセスをご紹介します。以下の内容を取り上げます：

  1. 現在のセットアップの評価とアップグレードの適否の判断
  2. アップグレードの計画と準備
  3. アップグレードプロセスのステップバイステップの手順
  4. アップグレード後の最適化とベストプラクティス

Amazon Redshift Serverless にアップグレードする理由

Amazon Redshift Serverless を使用することで、データウェアハウスインフラストラクチャを管理することなく、分析を実行およびスケールできます。DC2 インスタンスから Amazon Redshift Serverless にアップグレードすると、次のようなメリットが得られます。

  • 運用の簡素化：コンピュートクラスターのセットアップ、チューニング、管理を必要とせずに、データにアクセスして分析できます。
  • 自動パフォーマンス最適化：自動スケーリングとAI 主導のスケーリングおよび最適化により、要求の厳しい変動の激しいワークロードに対して一貫した高パフォーマンスと簡素化された運用を実現します。
  • 従量課金制：柔軟な料金体系により、アクティブな使用時のみ課金され、使用した分だけ支払います。
  • オンラインメンテナンス：Amazon Redshift Serverless は、メンテナンスウィンドウを必要とせずにシステムの更新とパッチを自動的に管理し、データウェアハウスのシームレスな運用を支援します。
  • ストレージとコンピュートの分離：Amazon Redshift マネージドストレージにより、コンピュートとストレージを個別にスケーリングして支払うことで、コストを管理できます。
  • 新機能へのアクセス：データ共有への書き込み、Redshift ストリーミングの取り込み、ゼロ ETL、その他の機能を含む高度な機能を使用できます。

サイジングガイダンス

DC2 から Amazon Redshift Serverless へアップグレードするには、サイズの同等性を理解する必要があります。次の表は、DC2 ノードタイプからアップグレードする際の推奨サイジング構成を示しています。
Redshift Processing Unit (RPU) 構成の可用性は AWS リージョンによって異なることに注意してください。

既存のノードタイプ 既存のノード数 Amazon Redshift Serverless へのアップグレード
DC2.large 1–4 4 RPU から開始
DC2.large 5–7 8 RPU から開始
DC2.large 8–32 DC2.large の 8 ノードごとに 8 RPU を追加
DC2.8xlarge 2–32 ノードごとに 16 RPU を追加（最大 1,024 RPU まで）

これらのサイジング見積もりは、Amazon Redshift Serverless を最大限に活用できるよう調整された柔軟な出発点を提供します。お客様のニーズに最適な構成は、コストとパフォーマンスの望ましいバランスや、ワークロードの特定のレイテンシーとスループット要件などの要因によって異なります。特定の要件に基づいてサイジングをさらに最適化するには、以下のアプローチを使用します。

  • ワークロードの事前テスト：Amazon Redshift Serverless に移行する前に、非本番環境でワークロードのパフォーマンス要件を評価します。Amazon Redshift Test Drive ユーティリティは、さまざまなサーバーレス構成で本番ワークロードをシミュレートすることで、このプロセスを簡素化します。結果を使用して、パフォーマンスとコストの最適なバランスを特定し、構成について情報に基づいた決定を下すことができます。DC2からServerless へのアップグレードでTest Drive ユーティリティを使用するためのステップバイステップのガイダンスについては、Amazon Redshift Migration Workshop を参照してください。移行前にこれらのパフォーマンステストを実行することで、本番環境にデプロイする前に構成に必要な調整を特定できます。
  • 本番環境での監視：ワークロードをデプロイした後、典型的なワークロードを表す期間にわたってパフォーマンスとリソース使用率を注意深く監視します。監視メトリクスに基づいて、パフォーマンスとコストの最適なバランスを達成するために、必要に応じてリソースをスケールアップまたはスケールダウンできます。
  • AI 主導のスケーリングと最適化：ワークロードのニーズに合わせて Amazon Redshift Serverless を自動的にサイジングするために、AI 主導のスケーリングと最適化を備えた Amazon Redshift Serverless の使用を検討してください。

本番前のテストと継続的な本番環境のモニタリングを組み合わせたサイジング検証への体系的なアプローチにより、Amazon Redshift Serverless の構成がワークロードに適合していることを確実にできます。

Amazon Redshift Serverless へのアップグレード

Amazon Redshift Serverless にアップグレードするには、次の図に示すように、スナップショット復元を使用して Amazon Redshift から Amazon Redshift Serverless に直接移行できます。スナップショット復元では、ユーザーとその関連する権限、設定、スキーマ構造に加えて、データとオブジェクトが復元されます。移行にスナップショット復元を使用することで、本番環境の Amazon Redshift DC2 クラスターに影響を与えることなく、ターゲットの Amazon Redshift Serverless ウェアハウスを検証できます。また、スナップショット復元を使用して、Amazon Redshift DC2 ワークロードを異なるリージョンやアベイラビリティーゾーンに移行することもできます。

スナップショット復元を使用した移行の前提条件

  1. 名前空間を持つ Amazon Redshift Serverless ワークグループを作成します。詳細については、名前空間を伴うワークグループの作成を参照してください。
  2. Amazon Redshift Serverless はデフォルトで暗号化されています。Amazon Redshift Serverless は、組織のセキュリティポリシーに準拠できるよう、名前空間の AWS KMS キーの変更もサポートしています。
  3. 復元しようとしている Amazon Redshift Serverless 名前空間が Amazon Redshift Serverless ワークグループに関連付けられていることを確認します。
  4. プロビジョニングされた Amazon Redshift クラスターから Amazon Redshift Serverless に復元するには、AWS Identity and Access Management (IAM) ユーザーまたはロールに次の権限が必要です：redshift-serverless:RestoreFromSnapshot、CreateNamespace、および CreateWorkgroup。詳細については、Amazon Redshift Serverless の復元を参照してください。

コンソールを使用したアップグレード

スナップショット復元方式を使用して DC2 クラスターを Amazon Redshift Serverless にアップグレードするには、Amazon Redshift の AWS マネジメントコンソールで以下の手順を実行します。

  1. Redshift コンソールで、ナビゲーションペインの [クラスター] を選択します。クラスターを選択し、[メンテナンス] を選択します。
  2. [スナップショットを作成] を選択して、既存の Amazon Redshift プロビジョンドクラスターの手動スナップショットを作成します。
  3. スナップショット識別子を入力し、スナップショット保持期間を選択してから、[スナップショットを作成] を選択します。
  4. リストから Amazon Redshift Serverless に復元するスナップショットを選択し、[スナップショットを復元] を選択してから [サーバーレス名前空間への復元] を選択します。
  5. [名前空間を選択] で、ドロップダウンリストからターゲットのサーバーレス名前空間を選択し、[復元]を選択します。
  6. 復元にかかる時間はデータ量によって異なります。
  7. 復元が完了したら、Amazon Redshift Query Editor v2または任意の SQL クライアントを使用して Amazon Redshift Serverless ワークスペースに接続し、データ移行を確認します。

詳細については、プロビジョニングされたクラスターのスナップショットを作成するを参照してください。

AWS CLI を使用したアップグレード

AWS Command Line Interface (AWS CLI) で以下の手順を使用して、スナップショット復元方式により DC2 クラスターを Amazon Redshift Serverless にアップグレードします。

  1. ソースクラスターからスナップショットを作成します: 
    aws redshift create-cluster-snapshot --cluster-identifier <your-dc2-cluster-id>  --snapshot-identifier <your-snapshot-name>
  2. スナップショットが存在することを確認します: 
    aws redshift describe-cluster-snapshots --snapshot-identifier <your-snapshot-name>
  3. スナップショットを Amazon Redshift Serverless 名前空間に復元します: 
    aws redshift-serverless restore-from-snapshot --snapshot-arn "arn:aws:redshift:<your-region>:<your-account-number>:snapshot:<source-cluster-id>/<your-snapshot-name>" --namespace-name <your-serverless-namespace> --workgroup-name <your-serverless-workgroup> --region <your-region>

詳細については、AWS CLI を使用したクラスタースナップショットからの復元を参照してください。

Amazon Redshift Serverlessへのアップグレードのベストプラクティス

Amazon Redshift から Amazon Redshift Serverless へのアップグレード時に推奨されるベストプラクティスは以下の通りです。

  • アップグレード前:
    • サイジングガイダンスを使用して、適切なターゲット構成を決定します。
    • Amazon Redshift Test Drive を使用して概念実証 (POC) を実行し、ターゲット構成を検証します。
    • CNAME の使用を検討します。正規名 (CNAME) レコードは、Amazon Redshift クラスターのエンドポイントのエイリアスを作成するために使用できる DNS レコードの一種です。
    • インターリーブソートキーを使用している場合、プロビジョニングされたクラスターのスナップショットをサーバーレス名前空間に復元すると、Amazon Redshift は自動的にそれらを複合キーに変換します。詳細については、Amazon Redshift Serverless を使用する際の考慮事項を参照してください。
    • Amazon Redshift Serverless の一部の概念と機能は、Amazon Redshift プロビジョニングデータウェアハウスの対応する機能とは異なります。これには、システムテーブルとビュー、監査ログ、エンドポイント名の違いが含まれます。これらの違いの完全なリストについては、Amazon Redshift Serverless と Amazon Redshift プロビジョニングデータウェアハウスの比較を参照してください。
    • Amazon EventBridge を使用した Amazon Redshift Serverless のイベント通知を購読し、移行プロセス中のイベントの通知を受け取ります。
  • アップグレード後:
    • 既存の接続を更新 : Amazon Redshift Serverless に移行すると、新しいエンドポイントが作成されます。ビジネスインテリジェンスやその他のレポートツールへの既存の接続を更新してください。
    • 可観測性と監視 : システムビューを使用するデータ監視ツールがある場合は、オープンまたは空のトランザクションがないことを確認してください。ベストプラクティスとして、トランザクションを終了することが重要です。オープントランザクションを終了またはロールバックしない場合、Amazon Redshift Serverless はそれらのトランザクションに対して RPU を使い続けます。
    • アクセス : dbUser および dbGroups での IAM 認証を使用する場合、アプリケーションはGetCredentials API を使用してデータベースにアクセスできます。詳細については、IAM を使用した接続を参照してください。
    • システムビュー : Amazon Redshift Serverless で利用可能な統合システムビューのリストを確認してください。

ワークロードの性質、またはAmazon Redshift Serverless 使用時の考慮事項に記載されている考慮事項のいずれかにより、ワークロードが Amazon Redshift Serverless に適していない場合は、RA3 サイジングガイダンスに従って Amazon Redshift RA3 インスタンスにアップグレードします。

コスト面の考慮事項

このセクションでは、Amazon Redshift Serverless のコストを理解し、管理するための情報を提供します。

  • 予測可能な使用パターンがある場合は、事前に容量を予約することでサーバーレスコンピューティングのコストを削減できます。
  • Amazon Redshift Serverless は、ワークロードに基づいて自動的に容量を調整します。最大 RPU 制限を設定することで、システムがスケールアップできる上限を設定し、コストを管理できます。
  • Amazon Redshift Serverless はコンピューティングユニットとしてRPUを使用します。デフォルトでは 128 RPU から開始しますが、特定のワークロードニーズと SLA 要件に合わせて、ベース RPU を 4 から 1,024 RPU の範囲で調整できます。詳細については、Amazon Redshift Serverless の請求を参照してください。
  • Amazon Redshift Serverless は、30 分ごと、またはノードあたり 5 GBのデータ変更が発生した場合のいずれか早い方で、自動的にリカバリポイントを作成します。リカバリポイント間の最小間隔は 15 分です。すべてのリカバリポイントは、デフォルトで 24 時間保持されます。

より長期間バックアップを保持する必要がある場合は、手動バックアップを作成できます。手動バックアップには追加のストレージコストが発生します。

  • Amazon Redshift Serverless の AI 主導スケーリングと最適化により、シンプルなスライダーでコンピューティングリソースを簡単に調整し、予算とパフォーマンスニーズのバランスを取ることで、コストを削減できます。

クリーンアップ

今後の料金が発生しないようにするには、前提条件の手順の一部として作成した Amazon Redshift Serverless インスタンスまたはプロビジョニングされたデータウェアハウスクラスターを削除してください。詳細については、ワークグループの削除およびクラスターのシャットダウンと削除を参照してください。

結論

この投稿では、Amazon Redshift DC2 インスタンスを Amazon Redshift Serverless にアップグレードするメリットに加えて、アップグレードのための様々なオプションといくつかのベストプラクティスについて説明しました。アップグレードを実施する前に、対象となる Amazon Redshift Serverless の構成を決定し、テスト環境および開発環境で Amazon Redshift Test Drive ユーティリティを使用して検証することが重要です。

この投稿のガイダンスを実装して、今すぐ Amazon Redshift Serverless へのアップグレードを始めましょう。ご質問がある場合やサポートが必要な場合は、アーキテクチャおよび設計のガイダンス、さらに概念実証や実装のサポートについて、AWS サポートにお問い合わせください。

著者について

Nita Shah


Nita は、ニューヨークを拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。彼女は 20 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift を専門としています。顧客がエンタープライズ規模の適切に設計されたアナリティクスおよび意思決定支援プラットフォームを設計・構築することを支援することに注力しています。

Ricardo Serafim


Ricardo は AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。2007 年以来、企業のデータウェアハウスソリューションを支援してきました。

Bryan Cottle

Bryan は Amazon Web Services のシニアテクニカルプロダクトマネージャーです。彼は分析データベースに情熱を注いでおり、特に Amazon Redshift を専門としています。そこでは、顧客のコスト最適化、価格戦略のナビゲート、データベース移行の成功支援を行っています。

Sémir Naffati

Sémir は、フランス・パリを拠点とする AWS のシニアワールドワイドスペシャリストソリューションアーキテクトです。データとアナリティクスにおける 25 年以上の経験を持ち、エンタープライズ顧客の複雑なクラウド変革を支援することを専門としています。彼の専門知識は、レガシーデータベースシステム(Oracle、SQL Server)から最新のクラウドネイティブアーキテクチャ(Redshift、Iceberg)およびAIサービスまで幅広く及びます。顧客が最も困難なデータ課題を解決し、スケーラブルでコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。

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