まえがき

RedshiftとはSQLを使用して構造化、半構造化データを分析できるDWH(データウェアハウス)です。
Redshiftクラスター1台に対して複数のノードで構成されています。

①　伸縮自在なサイズ変更

オプションから伸縮自在なサイズ変更が選択できる場合は、このサイズ変更により、ノードタイプかノード数、またはその両方を変更します。
ノード数のみを変更すると、クエリが一時的に停止され、接続は開かれたまま維持されることに注意してください。
伸縮自在なサイズ変更には 10 ～ 15 分かかります。
サイズ変更のオペレーション中は、クラスターは読み取り専用になります。

②　従来型サイズ変更

従来型のサイズ変更を使用して、ノードタイプかノード数、またはその両方を変更します。
伸縮自在なサイズ変更では使用できない設定でサイズを変更する場合、このオプションを選択します。
データ サイズによっては、サイズ変更操作に 2 時間以上、最大で数日かかる場合があります。
サイズ変更のオペレーション中は、ソースクラスターは読み取り専用になります。

③　スナップショット、復元、およびサイズ変更

従来のサイズ変更オペレーションの間、確実にクラスターを使用するためには、既存のクラスターをコピーしておきます。
その後に、クラスターのサイズを新しく変更します。スナップショットの取得後にソースクラスターに書き込まれたデータは、手動でコピーする必要があります。
新しく作成されたターゲットクラスターへの手動によるデータコピーは、移行が完了した後に行う必要があります。

④　高速の従来型サイズ変更

高速の従来型サイズ変更は、その速度が伸縮自在のサイズ変更と同等で、また、従来型サイズ変更と同様の機能を備えています。
このサイズ変更オペレーションには、主に 2 つの段階があります。ステージ 1 (クリティカルパス) では、データがソースクラスターからターゲットクラスターに移行され、ソースクラスターは読み取り専用モードになります。
ステージ 2 (オフクリティカルパス) では、以前のデータ配信スタイルで行われたデータの再配布が、バックグラウンドで完了します。
この段階の所要時間は、分散するボリュームとクラスターのワークロードによって異なります。

今回はその中でも、 ①伸縮自在なサイズ変更を実施する上での注意点を解説したいと思います。

内容

伸縮自在なサイズ変更は、従来型サイズ変更と比較したポイントを以下にまとめます。

  • 従来型サイズ変更では2 時間以上、最大で数日かかる所を10 ～ 15 分で実現が可能です。
  • 伸縮自在なサイズ変更実行中は、Redshiftクラスターは読み取り専用になります。
  • ノードの追加可能台数に制限がある。ノードタイプによって制限値は変更されます。

この伸縮自在なサイズ変更の使い所としては
なるべく短時間でRedshiftのノード数を追加したい場合に最適かと考えます。

「伸縮自在なサイズ変更」の注意点

選択可能なノード数は以下2つの条件で更新されたベースとなるノード台数から算出される。

  • Redshiftクラスターが作成された時点のノード台数
  • 従来型サイズ変更を実施した時点のノード台数

「伸縮自在なサイズ変更」で変更可能なノード台数の制限値

ノードタイプ 増台制限 減少制限
ra3.16xlarge 4倍 1/4
ra3.4xlarge 4倍 1/4
ra3.xlplus 2倍 1/4
dc2.8xlarge 2倍 1/2
dc2.large 2倍 1/2
ds2.8xlarge 2倍 1/2
ds2.xlarge 2倍 1/2

※参照リンク：次の表は、柔軟なサイズ変更をサポートする各ノード タイプの成長と縮小の制限を示しています。

よくあるトラブルシューティング例

Q. 以下構成のRedshiftを構築後「伸縮自在なサイズ変更」を実施しノード台数を２倍の8にしました。しかし再度実行するとノード台数が2倍の値である16 を指定できないですが、なぜでしょうか？

① Redshiftクラスターをノード4台で構築

作成したRedshiftクラスターのノードタイプ 作成時のノード台数
a3.xlplus 4

②1度目「伸縮自在なサイズ変更」実行し、ノード台数を8に変更

作成したRedshiftクラスターのノードタイプ 作成時のノード台数
ra3.xlplus 8

③2度目「伸縮自在なサイズ変更」実行し、ノード台数を16台に変更したいが選択不可

作成したRedshiftクラスターのノードタイプ 作成時のノード台数
ra3.xlplus 16を指定できない

原因

「伸縮自在なサイズ変更」で選択可能なノード台数は以下条件の2つから算出される。

・Redshiftクラスターが作成された時点のノード台数

・従来型サイズ変更を実施した時点のノード台数

よって今回はRedshift作成時のノード台数が4でベース値となってしまい、2倍のノード台数8までしか選択できなくなっています。

ドキュメント一部抜粋：https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/managing-cluster-operations.html#elastic-resize

伸縮自在なサイズ変更には以下の制約があります。
〜〜〜
・ソース vs ターゲットクラスターサイズ - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類の設定は、元のクラスターのノード数と、サイズ変更したクラスターのターゲットノードタイプによって決まります。使用可能な設定を確認するには、コンソールを使用します。

では、どのように「伸縮自在なサイズ変更」でノード台数に16を指定できるか

A. 「従来型サイズ変更」を実施することでベース値が8にリセットされます。その後「伸縮自在なサイズ変更」実行し16までノード台数増加が可能です。

まとめ

「伸縮自在なサイズ変更」は短い時間でノードタイプとノード台数を変更することが可能でとても便利です。
反面、現在のRedshiftクラスターの「伸縮自在なサイズ変更」で選択可能なノード台数が何台なのか。ベースとなる値を認識しておく事が重要です。
予め「伸縮自在なサイズ変更」で選択可能な台数を認識することが運用などの面では必須かと考えられます。

この記事を書いた人

クラウドインテグレーション事業部 MSPセクション
上地航平（うえちこうへい）

iret cloudpackでは24時間365日体制のMSP部隊を自社で抱えており、お客様へ監視運用保守の負荷を軽減できるcloudpackサービスを提供しています。

MSP? 運用? 何それ気になる！という方はこちら！ → 雲勉@オンライン【勉強会】24時間365日運用業務を支えるMSPの仕組み