みなさん、Amazon Redshift Serverlessを使ったことはありますか？
プロビジョンドタイプと異なり、サーバレスの強みを生かした高可用性、高スケーラビリティ、コストメリット有りと使いやすさ抜群のサーバレスタイプですが、
サーバレス特有のコンピューティングキャパシティの考え方を理解すると、よりメリットを享受することが出来そうです。
今回自分が携わったプロジェクトでRedshift Serverlessを構築したので、その際に分かったこと・試したことを記事にまとめてみました。
※最新情報についてはAWS公式ドキュメントを参照ください。
Redshiftプロビジョンドタイプとサーバレスタイプの違い
まずRedshiftとは、フルマネージド型のデータウェアハウスサービスです。
高速なリアルタイム分析が得意で、BIツールと連携も可能なため、企業の意思決定に大いに役立つサービスです。
プロビジョンドタイプはクラスタの管理が必要で、クラスタのサイズを手動で設定する必要がありますが、サーバレスタイプはワークロードに応じて自動でスケーリングします。
後に説明する「ベース容量」から「最大容量」までの範囲で自動でスケーリングがおこなわれるため、コスト効率化、運用負荷削減に有効です。
コンピューティングキャパシティの考え方
Redshift Serverlessでは、コンピューティングキャパシティをRPU（Redshift Processing Unit）という単位で設定します。
1つのRPUは16GBのメモリを提供します。
設定箇所としては「ベース容量」、オプションで「最大容量」、「使用制限」があるので、それぞれワークロードのクエリパフォーマンスや目標コストに応じてRPUを設定していきます。
ベース容量（設定はマスト）
クエリの処理に使用するコンピューティングリソースの基本容量をここで設定します。
デフォルト値は128RPUで、8RPU から512RPU まで8単位で調整可能です。
ベース容量を大きく設定することで、クエリのパフォーマンスが向上します。
最大容量（設定はオプション）
RedshiftがスケールアップできるRPUの上限をここで設定します。
クエリ実行開始時は「ベース容量」で設定したRPUで処理が実行されますが、クエリの負荷に応じてこの「最大容量」まで自動でスケーリングされます。
使用制限（設定はオプション）
Redshiftの使用を制限したい場合はここで設定します。
頻度（毎日/毎週/毎月）、制限RPU数、アクション（ログ出力/アラート/クエリ無効）が設定できます。
Redshiftはクエリの実行に使用されたRPU時間に応じて課金されるため、これ以上コストをかけたくない、という目安がある場合には設定がお勧めです。
ベース容量と最大容量の決め方
ベース容量と最大容量はどのように定めるのが良いでしょうか？
また設定後に「容量を変更すべき」という判断の基準をどのように持っておけば良いのでしょうか。
ここからは自分が実際に試してみた設定値決めの方法をご紹介します。
ざっくりとRPU設定値を決める
RPUは基本的には、「データ量」と「クエリの複雑さ、頻度」で考えていきます。
仮で、以下要件の場合のベース容量を考えてみます。
・Redshiftでの分析の元となるデータ量は3TB程度。
・分析のために実行するクエリは集計などのSQL文。実行時間は平日の勤務時間内。
「データ量」で考えると、公式ドキュメントで「8、16、24RPU の基本RPU容量は、128TB 未満のデータが必要なワークロードを対象としています。」との記載があり、今回の対象データは3TBであることから、8～24RPUを選択の候補とします。
「クエリの複雑さ、頻度」で考えると、正直どの程度データ分析でRedshiftを使用するかによるため、一旦16RPUを選択し、検証の中で設定値を調整していく形とします。
検証で設定値をチューニングする
上記の形で一旦設定したRPUが適切かどうかを実際の利用シーンを想定してクエリを実行してみることで、設定値の妥当性を判断します。
RPU値をチューニングする時には、以下2点をポイントとしてチェックすると良いです。
- ComputeCapacityメトリクス
クエリ実行すると様々なメトリクスが取得できますが、その中の[ComputeCapacity]メトリクスをCloudWatchで確認することで、クエリ実行時に使用されているRPUが分かります。
メトリクスの値がベース容量のRPUから最大容量のRPUにスケールアップし、最大容量に近い時間が多い場合は「ベース容量が足りていない」と判断する材料になります。
ただし、クエリについては単一のクエリからの負荷増加に応じたRPUスケールアップはおこなわれず、同時実行クエリのみがスケールアップの対象であることを念頭においておくことが必要です。 - クエリ実行時間
以下の方法でクエリ実行時間を確認し、想定内の実行時間であるかを評価する方法も有効です。SYS_QUERY_HISTORYビュー
Redshift内でSQLを実行しビューを表示させ、クエリ実行に関する詳細情報を確認する方法。
例えば「elapsed_time」を表示させると、クエリの実行時に消費した合計時間がわかります。
elapsed_time ：クエリの実行が消費した合計時間（マイクロ秒）。監査ログ
監査ログを有効にし、クエリ実行時間に関する情報を確認する方法。
QueryDuration ：クエリを完了するまでの平均時間（マイクロ秒）。
QueryRuntimeBreakdown ：クエリステージごとの、クエリが実行された合計時間（ミリ秒）。
まとめ
コンピューティングキャパシティの考え方を理解して、パフォーマンス的にもコスト的にも有効に使用できると良いですね。
最後まで読んでいただきありがとうございました！
この記事が皆さんのお役に立てれば幸いです。