Redshift Serverless に provisioned cluster から移行してみた

はじめに

Redshift Serverless が 7/13 に GA されました。従来の Redshift (provisioned cluster) では、クラスターを構成するインフラを意識しながらデプロイする方式でした。Redshift Serverless ではインフラ管理が不要となり、より簡単に、より運用負担を軽減してご利用いただけます。データを準備して Redshift Serverless に取り込むだけで分析ができ、料金は使用した分だけ発生します。これにより、利用頻度が少ない分析処理や夜間のみ実行されるワークロードなど、データウェアハウスを常時利用しないユースケースの場合に、効果的にご利用いただけます。

従来の provisioned cluster でサポートされている機能のほとんどは、Redshift Serverless でサポートされています。表現を変えると、今まで使っていたアプリケーションからは、今までと同じ方法で Redshift Serverless にアクセスできるという仕組みなっています。

provisioned cluster と Redshift Serverless の違いが気になる方は、次の Document を参照ください。

• https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/serverless-console-comparison.html

気になる料金については、つぎの URL で詳細が説明されています。

• https://aws.amazon.com/jp/redshift/pricing/

大事そうな部分を抜粋します。Redshift Serverless では、主に次の2種類の料金が発生します。

• RPU (Redshift Processing Unit) と呼ばれる、コンピュートキャパシティ
• RMS (Redshift Managed Storage) と呼ばれる、ストレージ容量

RPU はざっくり表現すると、Redshift Serverless に投げられるクエリーを処理するためのコンピュートリソースの概念です。クエリーが投げられたときに、RPU と呼ばれるリソースが稼働します。そして、処理が終わったら RPU 部分のコンピュートリソースは解放されます。料金面では、RPU が動いている時間分だけ、コンピュートキャパシティの料金が発生します。RPU 料金のイメージについては、YouTube の動画 で詳細に紹介されていたので、画像を引用します。

2:00:00 から 2:15:00 の間に、RPU が 5 分 30 秒 利用されている時の概念図です。RPU の料金が発生するのは、青いボックスが存在している 5 分 30 秒 部分だけです。それ以外のアイドル時間では、RPU の料金は発生しません。また、 クエリー課金ではなく、RPU の実行時間課金というのもポイントです。2:00:00 から 2:03:00 の 3 分間で 3 つのクエリーを実行していますが、RPU としては 「3分間」の料金しか発生しません。表現を変えると、RPU が稼働している期間に、クエリーを詰め込んだほうがコストパフォーマンスが良いという考え方になっています。

このように、Redshift を利用しない時間がある使い方では、Redshift Serverless でよりコスト最適化が出来るようになります。

provisioned cluster から Serverless に移行する

ここまで簡単に Redshift Serverless の紹介をしてきましたが、今までの provisioned cluster から Redshift Serverless に移行する方法が気になります。移行方法が AWS Document で紹介されています。

• https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-migration.html

provisioned cluster で作成したスナップショットから、Redshift Serverless として復元することで簡単に移行が出来ます。それでは実際に試してみましょう。

環境について

Redshift のデータを QuickSight で適当に可視化している環境を対象にしています。

Redshift Serverless に切り替えたときに、QuickSight 側の変更作業も合わせて確認していきます。

provisioned cluster でスナップショットを取得する

provisioned cluster を選択して、Create snapshot を選択します。

Snapshot の名前を指定して、Create snapshot を選択します。

Snapshot の作成処理が開始され、数分後に作成完了となりました。

Redshift Serverless を作成

スナップショットから復元するために、復元先の Redshift Serverless の Namespace が必要です。Namespace や Workgroup は Redshift Serverless で出てきた概念となっており、異なるリソースを管理する概念です。ざっくりな表現を Document から引用します。

Namespace は、データベースオブジェクトとユーザーをまとめたものです。Workgroup は、コンピュートリソースの集合体です。RPU、VPC、およびセキュリティグループのような計算リソースをまとめてグループ化します。

• https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-namespace.html

わかったようなわからないような表現ですが、スナップショットから復元するには Namespace が必要なので、まずは作っていきましょう。Redshift Serverless のメニューを選択します。

VPC などを選びたいので、Customize settings を選択します。

namespace の名前を指定します。

admin のユーザー名とパスワードを指定します。

IAM Role を適当に指定します。

それとなく Log の取得にチェックをいれてみます。

Workgroup に関する設定を入れていきます。VPC などの設定を行います。

Save configuration を押します。

作成処理が進みます。

数分で作成が終わりました。Continue を押します。

Redshift Serverless の作成が完了しました。

スナップショットから Redshift Serverless を復元する

スナップショットから Redshift Serverless を復元していきます。スナップショットを選択して、Restore to serverless namespace を選択します。

復元先の default Namespace のデータが全て上書きされるので、「本当にいい？」と聞かれています。問題ないので、Restore を押します。既に Redshift Serverless を使ったことが有る場合は、Namespace の選択を注意しましょう。

復元が進みます。

一定時間後、Available に変わりました。

Workgroup の Endpoint をメモっておきます。

簡単に動作確認

Redshift query editor v2 を使って、Redshift Serverless を対象にクエリーを実行できることを簡単に確認します。

QuickSight から Redshift Serverless に切り替え

QuickSight の Analysis は、provisioned cluster のデータセット customer-redshift-provisioned を参照して簡単な可視化を行っています。(テーブルで出しているだけなので、ほんとに簡単な可視化ですいません)

Redshift Serverless をデータセットとして登録します。New dataset を選択します。

Redshift を選択します。

Workgroup のエンドポイントなどを指定します。

元々のデータセットと同じ設定をします。

Edit/Preview data を押します。

名前を指定して、Save を押します。

Redshift Serverless のデータセットが出来上がりました。

元々 provisioned cluster を参照していた Analysis から、Dataset の編集を行います。

Replace を押します。

Serverless の方を選択して、Select を押します。

Replace を押します。

データセットの参照先を、Redshift Serverless に出来ました！

検証を通じてわかったこと

• 1 RPU は、16 GB のメモリを提供する。最低 RPU が 32、最高 RPU が 512 となる。デフォルトの Base RPU は 128 となる。

  • Base RPU を上げて、実行時間を短くすることで、コストとパフォーマンスのバランスを取る考え方もある
  • https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/serverless-considerations.html

• RPU は、クエリ数に合わせて自動的にスケーリングされる

  • https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/serverless-billing.html

  • クエリ数が増えると、Amazon Redshift Serverless では、一貫したパフォーマンスを提供するため、自動的にスケーリングされます。

• Base RPU を変更すると、数分間 Redshift Serverless が使えなくなる

  • When you save your changes, Redshift Serverless is not available for a few minutes. Do you want to continue?

• Redshift の provisioned cluster から、Redshift Serverless には、スナップショットを使って簡単に移行できる。

• Redshift Serverless を初めて利用するときに、300 USD の無償クレジットが付いてくる

  • https://aws.amazon.com/jp/redshift/pricing/

  • これまでに Amazon Redshift Serverless を利用したことがない場合、Amazon Redshift Serverless をお試しいただくと、コンピューティングとストレージの利用に対して 90 日間の有効期限付き 300 USD のクレジットが付与されます。このクレジットの消費率は、実際の使用量と Serverless エンドポイントのコンピューティング性能に依存します。

• Redshift Serverless の検証クレジットの残高と有効期限は、Dashboard で確認が可能

• 手元の環境で、128 RPU と、32 RPU を使って、TPC-H のデータをつかった速度比較をおこなった。
  • 結果、128 RPU の方が 32 RPU に比べて、10倍 ~ 18倍くらい早かった。
  • もちろんデータの容量などや設計方法によって異なる部分なので、性能検証をしたうえで、最適な RPU を選ぶのが良いと思う。
  • RPU 数 x 実行時間 = 料金という考え方なので、RPU 数を多くしても実行時間が短くなるなら、それが最もコスパが良いこともありえる。

参考 URL

Migrating a provisioned cluster to Amazon Redshift Serverless
https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-migration.html

Get Started with Analytics in Seconds with Amazon Redshift Serverless - AWS Online Tech Talks
https://www.youtube.com/watch?v=juItNAqfrJ4