はじめに
はじめまして、NTTデータ九州 デジタルビジネス推進室 パブリッククラウドチームの小薗です。
クラウド需要が高まる中、クラウドを活用したシステム開発・運用には特有の課題や難しさがあります。
今回、クラウド活用支援で得た知見のうち、直近携わったビッグデータ分析基盤（データウェアハウス, Amazon Redshift）のスケーリングに関するナレッジを共有したいと思います。
本記事で話すこと
- Amazon Web Services（AWS）が提供するデータウェアハウスサービス Redshift RA3 の基本概要とスケーリング手段
- 負荷状況に応じて、適切なスケーリングを選定するための基本的な判断基準および判断フロー
本記事で話さないこと
データウェアハウスのスケーリングは、最適なクエリ、最適なテーブル設計・分散スタイル等が適用されていることを前提に実施される必要があります。
今回、これらの最適化が既に実施されているものとし、以下については言及しません。
- クエリチューニング
- データベース設計（データモデリング）
- スキーマ・テーブル設計の最適化
- キー設計の最適化
- Redshift ワークロード管理（WLM）の最適化
- Redshift 分散スタイル・分散キーの最適化
本記事の構成
- Redshift RA3 の基本概要
- Redshift RA3 でのスケーリング手段
- スケーリング手段の適用判断基準および判断フロー
- 最後に
1. Redshift RA3 の基本概要
Redshift RA3 のアーキテクチャ
コンピュートとストレージを分離したアーキテクチャを採用する最新世代（執筆時点）のノードタイプです。
従来の DC2 や DS2 といったインスタンスタイプでは、ストレージが各コンピュートノードにローカルアタッチされた構造でしたが、
インスタンスタイプ RA3 では、Redshift がマネージドで管理する専用ストレージレイヤ（Redshift Managed Storage (RMS, 実体はS3)）にデータが分離され、柔軟なスケーリングとコスト最適化が可能となりました。
特徴
-
ストレージの分離
ノードのローカルストレージ容量に縛られることなく、RMS上でペタバイト規模のデータを保存可能
ホットデータはノードローカルSSDにキャッシュ、コールドデータは自動的にRMSへオフロードされることで高速なクエリパフォーマンスとコスト最適化を両立 -
高いスケーラビリティ
ワークロードの変化に応じて、迅速かつ効率的にリソースを調整可能 -
パフォーマンス要件で選択
必要なパフォーマンスに応じて、ノード数やノードタイプを柔軟に選択可能
2. Redshift RA3 でのスケーリング手段
ワークロードに応じて適切なスケーリングを実現するためには、以下３つの異なる次元でスケーラビリティを評価することが重要です。
スケーラビリティの３次元
-
コンピュート
単一クエリの純粋な処理能力（CPU/メモリ） -
並列処理
単一の巨大クエリを分散並列実行する能力 -
同時実行性
多数の独立クエリを同時処理する能力
Redshift RA3 で利用可能なスケーリング手段
上記３次元に対応する、Redshiftで提供されるスケーリング手段とその特徴を以下に示します。
| 次元 | スケーリング手段 | 特徴 |
|---|---|---|
| コンピュート |
ノードタイプ変更 （垂直スケーリング） |
・ コンピュートノード当たりのCPU/メモリ性能を柔軟に変更可能 ・ 単一クエリの単処理性能が向上 |
| 並列処理 |
ノード数変更 （水平スケーリング） |
・ 単一クエリの並列処理性能が向上 ・ リソース使用率に余裕がある場合にはノード数を減らしコスト最適化◎ |
|
ノードタイプ変更 （水平スケーリング） |
・ ノードタイプを変更するとノードのデフォルトスライス数も変わる [*1] ⇒ 単一クエリの並列処理性能も直接的に改善可能 |
|
| 同時実行性 |
同時実行スケーリング （自動クラスタ追加） |
・ 一時的なクラスタ単位のスケールアウトが可能 ・ 多数のクエリが同時実行されるワークロードでキューへのクエリ滞留を解消 ・ 同時実行スケーリングクラスタでは実行不可なクエリあり [*2] |
[*1] ノードタイプの詳細
[*2] 同時実行スケーリングに関する制限
※ ①のノードタイプの変更は水平スケールもされるが、本質的には垂直スケーリングとしての性質が強い。
ノードタイプの変更に伴いスライス数が増え水平スケールされるのは、より高性能なノードタイプが大規模データ処理を前提として設計されており、クラスタあたりの処理能力を高めるための副次的な結果。
3. スケーリング手段の適用判断基準および判断フロー
２節までは、Redshift RA3 のスケーリングを検討する上で必要となる前提知識を説明しました。
３節では実際に、どういった負荷状況に対し、どのスケーリング手段を適用することが適切か判断するための基本的な基準を示します。
また、各スケーリングの適用による効果や留意事項についても押さえます。
| No. | スケーリング | 検討すべき主な状況(判断基準) | 効果・留意点 |
|---|---|---|---|
| ① |
ノードタイプの変更 （垂直水平スケーリング） |
・ CPU使用率が常に高止まり （CPUUtilization > 85%） ・ メモリ不足によるディスクスピルが頻発 (システムテーブル”SVL_QUERY_SUMMARY”の ”is_diskbased”列の"true"発生率 > 20%) |
・ 単一クエリの単性能が向上 ・ 同時実行数の上限自体は変わらない |
| ② |
ノード数の増減 （水平スケーリング） |
・ 単一巨大クエリの実行時間が長いがCPUに余裕あり ⇒ホットデータがノード上SSDに収まりきらず I/O 待ち （Read/Write Latency > 数十ミリ） ・ リソースが過剰でコストを最適化したい（削減時） |
・ 単一クエリの並列処理能力が向上 （SSD及びディスク I/O の拡張） ・ クラスタ全体の処理スループットが向上 ・ コスト効率の最適化（削減時） |
| ③ |
同時実行スケーリング （自動スケーリング） |
・ 多数の同時アクセスでクエリがキュー待ち （常に WLM キューの待機クエリ数 > 0） ・ 負荷変動が大きくスパイク的な高負荷が発生 （CPUUtilizationで負荷確認） |
・ピーク時のクエリ待ち時間を削減 ・コスト効率良くバースト負荷に対応 ・各クエリ自体の速度は向上しない ⇒複数クエリの同時実行数(並列度)が向上 |
スケーリングの判断フロー
判断方針：必要な性能を段階的に調整できるスケーリング判断フローとする
- 変動ワークロードでないか
- 変動ワークロードでクエリが常にキュー待ちしている状況では ③の同時実行スケーリング を適用
- 複数クエリの同時実行性能向上が主目的
- 複数クエリの同時実行性能向上が主目的
- 変動ワークロードであるがクエリのキュー待ちがない、または恒常的なワークロードの場合、ステップ２に遷移
- CPU使用率は高止まりしていないか
- 高止まりしている場合、純粋な単性能不足のため ①のノードタイプ変更(スケールアップ) を適用
- 単一クエリの単性能向上が主目的
- 単一クエリの単性能向上が主目的
- 高止まりしていない場合、ステップ３と４を順に確認
- 大量データを操作する単一クエリで、Read/Write レイテンシーが高くなっていないか(ディスク I/O 待ちの影響)
- レイテンシーが高まっている場合、ディスクI/O 待ちを改善するため、②のノード数の増加 を適用
- SSD 拡張によるディスク I/O 性能の向上が主目的
- ここではネットワーク I/O 待ちはないとする
- SSD 拡張によるディスク I/O 性能の向上が主目的
- レイテンシーが低い状態の場合、ステップ４を確認
- メモリ不足によるディスクスピルは発生していないか
- 発生している場合、②のノード数の増加 を適用し、段階的にメモリ増加
- 発生していない場合、現在のコンピュートリソースは妥当または過剰リソースと判断
コスト削減したい場合は、ノード数のスケールイン、ノードタイプのスケールダウンの順に、段階的に検討
4. 最後に
Redshift のスケーリング検討では、ワークロード特性、運用状況、コスト要件に応じて柔軟にスケーリング手段を選定・適用していくことが重要です。
本記事が Redshift RA3 のスケーリング検討の一助となれば幸いです。
執筆日・免責事項
この記事は2025年12月時点の情報に基づいて作成しています。
記載されているサービスの機能や仕様は変更される可能性があります。
実際の活用にあたっては、最新の公式ドキュメントをご確認ください。