クラスターのサイズ変更 - Amazon Redshift
伸縮自在なサイズ変更[従来のサイズ変更]

クラスターのサイズ変更

データウェアハウスの容量とパフォーマンスのニーズが変わるため、クラスターサイズを変更して、Amazon Redshift のコンピューティングとストレージオプションを最大限に活用することができます。

サイズ変更操作には次の 2 つのタイプがあります。

  • 伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードなど、ノードタイプを変更することもできます。伸縮自在なサイズ変更は、通常は短時間で完了し、平均で 10 分かかります。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。

    • 既存のクラスターにノードを追加または削減するが、ノードタイプは変更しない場合 - これは一般的にインプレースサイズ変更と呼ばれます。このタイプのサイズ変更を実行すると、実行中のクエリの一部は正常に完了しますが、他のクエリは操作の一部として破棄される場合があります。

    • クラスターのノードタイプの変更 - ノードタイプを変更すると、スナップショットが作成されて、ソースクラスターから新しいノードタイプで構成されるクラスターにデータが再分配されます。完了すると、実行中のクエリは破棄されます。インプレースのサイズ変更のように、すぐに完了します。

  • 従来のサイズ変更 - ノードタイプ、ノード数、またはその両方を、伸縮自在なサイズ変更と同様に変更できます。従来のサイズ変更は完了するまでに時間がかかりますが、ノード数の変更または移行先のノードタイプが、伸縮自在なサイズ変更の範囲内に収まらない場合は便利です。例えば、ノード数の変更が非常に大規模な場合に当てはまります。

伸縮自在なサイズ変更

同じタイプのノードを追加または削除する場合、伸縮自在なサイズ変更操作には、次の段階があります。

  1. 伸縮自在なサイズ変更は、クラスターのスナップショットを作成します。該当する場合、このスナップショットには常にノード用にバックアップしないテーブルが含まれています。(RA3 など、一部のノードタイプには、バックアップしないテーブルがありません。) 自動スナップショットを無効にしているため、クラスターに最近のスナップショットがない場合、バックアップオペレーションに時間がかかることがあります。(サイズ変更操作を開始する前の時間を最小限に抑えるため、自動スナップショットを有効にするか、サイズ変更を開始する前に手動スナップショットを作成することをお勧めします。) 伸縮自在なサイズ変更を開始し、スナップショット操作が現在進行中の場合、スナップショット操作が数分以内に完了しないと、伸縮自在なサイズ変更が失敗することがあります。詳細については、「Amazon Redshift スナップショットとバックアップ」を参照してください。

  2. このオペレーションはクラスターのメタデータを移行します。クラスターは数分間使用できません。クエリの大部分は一時的に停止され、接続は開いた状態になります。ただし、一部のクエリは削除される可能性があります。この段階は短い。

  3. セッション接続が回復し、クエリが再開します。

  4. 伸縮自在なサイズ変更は、バックグラウンドでノードスライスにデータを再分配します。クラスターは読み取りと書き込み操作に利用できますが、一部のクエリは実行に時間がかかる可能性があります。

  5. 操作が完了すると、Amazon Redshift はイベント通知を送信します。

伸縮自在なサイズ変更を使用してノードタイプを変更する操作は、同じタイプのノードを追加または削除する操作と似ています。まず、スナップショットが作成されます。新しいターゲットクラスターはスナップショットの最新データでプロビジョニングされ、データはバックグラウンドの新しいクラスターに転送されます。この期間中、データは読み取りのみ可能です。サイズ変更が完了間近になると、Amazon Redshift はエンドポイントを更新して新しいクラスターを指し、ソースクラスターへのすべての接続が破棄されます。

伸縮自在なサイズ変更が失敗することはまずありません。ただし、障害が発生した場合、ほとんどのケースでロールバックが自動的に行われ、手動による介入は必要ありません。

リザーブドノード (DS2 リザーブドノードなど) がある場合、サイズ変更を実行する際に RA3 リザーブドノードへのアップグレードができます。このアップグレードは、伸縮自在なリサイズを実行するか、コンソールを使用してスナップショットからの復元を実行するときに使用できます。このコンソールは、このプロセスについて説明します。RA3 ノードへのアップグレードの詳細については、「RA3 ノードタイプへのアップグレード」を参照してください。

伸縮自在なサイズ変更は、テーブルをソートしたり、ディスク容量を解放したりしないため、バキュームオペレーションに代わるものではありません。詳細については、「テーブルのバキューム処理」を参照してください。

伸縮自在なサイズ変更には以下の制約があります。

  • 伸縮自在なサイズ変更とデータ共有クラスター - データ共有のプロデューサーであるクラスターでノードを追加または削除すると、Amazon Redshift がクラスターメタデータを移行している間、コンシューマーから接続できません。同様に、伸縮自在なサイズ変更を実行して新しいノードタイプを選択した場合、接続がドロップされ、新しいターゲットクラスターに転送される間、データ共有は利用できません。どちらのタイプの伸縮自在なサイズ変更でも、プロデューサーは数分間利用できません。

  • 共有スナップショットからデータを転送しているクラスターで伸縮自在なサイズ変更を実行するには、クラスターで少なくとも 1 つのバックアップを使用できる必要があります。バックアップは、Amazon Redshift コンソールのスナップショットのリスト、describe-cluster-snapshots CLI コマンド、または DescribeClusterSnapshots API オペレーションで表示できます。

  • プラットフォーム制限 - 伸縮自在なサイズ変更は、EC2-VPC プラットフォームを使用するクラスターでのみ利用できます。詳細については、「クラスターの作成時に EC2-VPC を使用する」を参照してください。

  • ストレージの考慮事項 - 新しいノード設定では、既存データに十分なストレージを確保する必要があります。ノードの追加または設定の変更が必要な場合があります。

  • ソース vs ターゲットクラスターサイズ - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類は、ソースクラスターのノード数と、サイズ変更したクラスター用に選択されたノードタイプによって決まります。使用可能な設定を確認するには、コンソールを使用します。また、action-type resize-cluster オプションで describe-node-configuration-options AWS CLI コマンドを使用することもできます。Amazon Redshift コンソールを使用したメタデータの編集の詳細については、クラスターのサイズ変更 を参照してください。

    次の CLI コマンドの例では、使用可能な設定オプションを確認できます。この例では、mycluster という名前のクラスターは dc2.large 8 ノードクラスターです。

    aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

    このコマンドは、各オプションの推奨ノードタイプ、ノード数、およびディスク使用率を含むオプションリストを返します。返される設定は、特定の入力クラスターに基づいて異なります。resize-cluster CLI コマンドのオプションを指定するときに、これらの返された設定のいずれかを選択できます。

  • 追加ノードの上限 - 伸縮自在なサイズ変更には、クラスターに追加できるノードに制限があります。例えば、dc2 クラスターでは、ノード数が 2 倍までの伸縮自在なサイズ変更をサポートします。例えば、4 ノード型 dc2.8xlarge クラスターにノードを追加して 5 ノードのクラスターにしたり、8 ノードになるまでさらにノードを追加できます。

    注記

    拡大と縮小の制限は、元のノードタイプ、元のクラスター内のノード数、または最後に行った従来のサイズ変更に基づいて決まります。伸縮自在なサイズ変更が拡大または縮小の制限を超える場合は、従来のサイズ変更を使用してください。

    ra3 ノードタイプには、ノード数を既存の数の 4 倍まで増やすことができるものもあります。例えば、クラスターが ra3.4xlarge ノードまたは ra3.16xlarge ノードで構成されているとします。この場合、伸縮自在なサイズ変更を使用して、8 ノードのクラスターのノード数を 32 に増やすことができます。または、制限値を下回る値も選択できます。(クラスターを 4 倍に拡張できるかどうかは、ソースクラスターのサイズによることに注意してください。) クラスターに ra3.xlplus ノードがある場合、制限値は 2 倍になります。

    すべての ra3 ノードタイプでは、ノード数を既存の数の 4 分の 1 に減らすことができます。例えば、ra3.4xlarge ノードを持つクラスターのサイズを 12 ノードから 3 ノードに、または最小値を超えた値に減らすことができます。

    次の表は、伸縮自在なサイズ変更がサポートされている各ノードタイプの増加の制限値と削減の制限値を示しています。

    元のノードタイプ 増加制限値 削減制限値

    ra3.16xlarge

    		 4 倍 (例えば、4 ノードから 16 ノード)

    数字の 4 分の 1 (例えば、16 から 4 ノード)

    ra3.4xlarge

    4 倍

    		 数字の 4 分の 1

    ra3.xlplus

    2 倍 (例えば、4 ノードから 8 ノード)

    数字の 4 分の 1

    dc2.8xlarge

    2 倍

    数字の 2 分の 1 (例えば、16 から 8 ノード)

    dc2.large

    2 倍

    数字の 2 分の 1

    ds2.8xlarge

    2 倍

    数字の 2 分の 1

    ds2.xlarge

    2 倍

    数字の 2 分の 1
    注記

    RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択 — RA3 ノードを含むクラスターから別のノードタイプ（DC2 や DS2 など）にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。

[従来のサイズ変更]

伸縮自在なサイズ変更でサポートされないクラスターサイズやノードタイプの変更が伴うユースケースは、従来のサイズ変更で処理します。従来のサイズ変更を実行すると、Amazon Redshift はターゲットクラスターを作成し、データとメタデータをソースクラスターからそのクラスターに移行します。

RA3 への従来のサイズ変更では、可用性が向上します

ターゲットノードタイプが RA3 の場合、従来のサイズ変更が強化されています。これを行うために、ソースとターゲットのクラスター間でバックアップと復元オペレーションを利用します。サイズ変更が始まると、ソースクラスターが再起動し、数分間使用できなくなります。その後、クラスターは読み取りおよび書き込みオペレーションで使用可能になり、サイズ変更はバックグラウンドで続行します。

クラスターの確認

RA3 クラスターへの従来のサイズ変更を実行したときに最高のパフォーマンスと結果を得るには、次のチェックリストを完了します。チェックリストに従わないと、読み取りまたは書き込みオペレーションの実行など、RA3 ノードでの従来のサイズ変更のメリットの一部が得られない場合があります。

  1. データのサイズは 2 ペタバイト未満でなければなりません。(1 ペタバイトは 1,000 テラバイトに相当します)。データのサイズを検証するには、スナップショットを作成してそのサイズを確認します。次のクエリを実行してサイズを確認することもできます。

    SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;

    svv_table_info テーブルはスーパーユーザーにのみ表示されます。

  2. 従来のサイズ変更を開始する前に、10 時間以内の手動スナップショットがあることを確認してください。存在しない場合は、スナップショットを作成します。

  3. 従来のサイズ変更の実行に使用したスナップショットは、テーブルの復元やその他の目的には使用できません。

  4. クラスターは VPC 内にある必要があります。

RA3 への従来のサイズ変更によるソートおよび分散オペレーション

RA3 への従来のサイズ変更中に、EVEN 分散として移行された分キー分散のあるテーブルは、元の分散スタイルに戻されます。この期間は、データのサイズとクラスターの負荷状況によって異なります。クエリワークロードは、データ移行よりも実行が優先されます。詳細については、「分配スタイル」を参照してください。この移行プロセス中は、データベースの読み取りと書き込みの両方が機能しますが、クエリが完了するまでに時間がかかることがあります。ただし、同時実行スケーリングでは、クエリワークロード用のリソースを追加することでこの間にパフォーマンスを向上させることができます。SYS_RESTORE_STATE ビューと SYS_RESTORE_LOG ビューの結果を表示することで、データ移行の進行状況を確認できます。モニタリングの詳細については、以下を参照してください。

クラスターのサイズが完全に変更されると、次のソート動作が発生します。

  • サイズ変更によってクラスターのスライス数が増えると、KEY 分散テーブルは部分的にソートされなくなりますが、EVEN テーブルはソートされたままになります。また、ソートされたデータの量に関する情報は、サイズ変更の直後は最新でない可能性があります。キーの回復後、自動バキュームによってテーブルが時間の経過とともにソートされます。

  • サイズ変更によってクラスターのスライス数が少なくなると、KEY 分散テーブルと EVEN 分散テーブルの両方が部分的にソートされなくなります。自動バキュームにより、テーブルが時間の経過とともにソートされます。

テーブルの自動バキュームの詳細については、「テーブルのバキューム処理」を参照してください。コンピューティングノードのスライスの詳細については、「データウェアハウスシステムアーキテクチャ」を参照してください。

ターゲットクラスターが RA3 である場合の従来のサイズ変更手順

従来のサイズ変更は、ターゲットクラスタータイプが RA3 で、前のセクションで説明した前提条件を満たしている場合、次の手順で構成されます。

  1. ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。

    BACKUP NO で作成したテーブルやマテリアライズドビューなどのデータベースリレーションは、従来のサイズ変更では保持されないことに注意してください。詳細については、「REFRESH MATERIALIZED VIEW」を参照してください。

  2. 再起動後、データベースは読み取りと書き込みが可能になります。さらに、データ共有が再開されます。これにはさらに数分かかります。

  3. データがターゲットクラスターに移行されます。ターゲットノードタイプが RA3 の場合、データ移行中に読み取りと書き込みが可能です。

  4. サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。

  5. サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。

サイズ変更の進行状況は、Amazon Redshift コンソールで確認できます。クラスターのサイズ変更にかかる時間は、データ量に左右されます。

注記

RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択 — RA3 ノードを含むクラスターから別のノードタイプ (DC2 や DS2 など) にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。

ターゲットクラスターが RA3 である場合の従来のサイズ変更のモニタリング

進行中のプロビジョニングされたクラスターの従来のサイズ変更 (キー分散を含む) をモニタリングするには、SYS_RESTORE_STATE を使用します。変換中のテーブルの完了率が表示されます。データにアクセスするには、スーパーユーザーである必要があります。

従来のサイズ変更を実行するときに不要なテーブルを削除します。これを行うと、既存のテーブルをより迅速に分散できます。

ターゲットクラスターが RA3 でない場合の従来のサイズ変更手順

ターゲットノードタイプが RA3 以外 (DS2 など) である場合、従来のサイズ変更は次の手順で構成されます。

  1. ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。

    BACKUP NO で作成したテーブルやマテリアライズドビューなどのデータベースリレーションは、従来のサイズ変更では保持されないことに注意してください。詳細については、「CREATE MATERIALIZED VIEW」を参照してください。

  2. 再起動後、データベースは読み取り専用になります。データ共有が再開されます。これにはさらに数分かかります。

  3. データがターゲットクラスターに移行されます。データベースは読み取り専用のままです。

  4. サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。

  5. サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。

サイズ変更の進行状況は、Amazon Redshift コンソールで確認できます。クラスターのサイズ変更にかかる時間は、データ量に左右されます。

注記

ターゲットクラスターが RA3 でない場合、または前のセクションで説明した RA3 ターゲットクラスターの前提条件を満たしていない場合、大量のデータを含むクラスターのサイズを変更するには、数日または場合によっては数週間かかることがあります。

また、クラスターの使用済みストレージ容量は、従来のサイズ変更後に増加する可能性があることにも注意してください。これは、従来のサイズ変更の結果としてクラスターにデータスライスが追加された場合、通常のシステム動作です。クラスター内のノード数が同じままでも、こうした追加容量の使用が発生する場合があります。

伸縮自在なサイズ変更 vs 従来のサイズ変更

次の表は、2 つのサイズ変更タイプの動作を比較しています。

伸縮自在なサイズ変更 vs 従来のサイズ変更
Behavior 伸縮自在なサイズ変更 [従来のサイズ変更] コメント
システムデータ保持 伸縮自在なサイズ変更は、システムログデータを保持します。 従来のサイズ変更は、システムテーブルとデータを保持しません。 ソースクラスターで監査ログ記録を有効にしている場合、サイズ変更をしたあと、Amazon S3 または CloudWatch でログへのアクセスを継続できます。これらのログは、指定したデータポリシーに応じて保持または削除することができます。
ノードタイプの変更

ノードタイプが変わらない場合、伸縮自在なサイズ変更: インプレースのサイズ変更すると、ほとんどのクエリが保持されます。

新しいノードタイプを選択した状態で伸縮自在なサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセスが完了すると、クエリは破棄されます。

 クラシックサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセス中にクエリは破棄されます。
セッションとクエリの保持 伸縮自在なサイズ変更では、ソースクラスターとターゲットでノードタイプが同じである場合、セッションとクエリが保持します。新しいノードタイプを選択する場合、クエリは破棄されます。 クラシックサイズ変更では、セッションとクエリは保持されません。クエリが破棄されます。 クエリを削除すると、パフォーマンスが低下することが予想されます。サイズ変更操作は、使用負荷が低い時間に行うのが最適です。
サイズ変更操作のキャンセル

伸縮自在なサイズ変更をキャンセルすることはできません。

Amazon Redshift コンソールのクラスター詳細から [Cancel resize (サイズ変更のキャンセル)] を選択すると、従来のサイズ変更オペレーションが完了する前にキャンセルできます。

サイズ変更のキャンセルに要する時間は、キャンセルするとき、サイズ変更オペレーションのどのステージにあるかによって異なります。この操作を実行すると、キャンセル操作が完了するまでクラスターを利用できません。サイズ変更操作が最終ステージに達している場合、キャンセルできません。

RA3 クラスターへの従来のサイズ変更では、キャンセルできません。

サイズ変更のスケジューリング

クラスターのサイズ変更オペレーションをスケジュールして、使用率の増加を予想してスケールアップしたり、コスト削減のためにスケールダウンしたりすることができます。スケジューリングは、伸縮自在なサイズ変更と従来のサイズ変更の両方に使えます。Amazon Redshift コンソールでスケジュールのセットアップできます。詳細については、[Managing clusters using the console] (コンソールを使ってクラスター管理) の「クラスターのサイズ変更」を参照してください。AWS CLI または Amazon Redshift API 操作を使用して、サイズ変更をスケジュールすることもできます。詳細については、AWS CLI コマンドリファレンスの「create-scheduled-action」または Amazon Redshift API リファレンスの「CreateScheduledAction」を参照してください。

スナップショット、リストア、およびサイズ変更

伸縮自在なサイズ変更は、Amazon Redshift クラスターのサイズを変更する最速の方法です。伸縮自在なサイズ変更オプションを選択できず、クラスターにほぼ恒常的な書き込みアクセスが必要な場合は、次のセクションで説明している、スナップショットと復元オペレーションを使用します。この方法では、スナップショットが作成された後でソースクラスターに書き込まれたデータは、ターゲットクラスターに切り替えた後、手動でコピーする必要があります。コピーにかかる時間によっては、両方のクラスター内のデータが同じになるまで、この操作を数回繰り返す必要がある場合もあります。その後で、ターゲットクラスターに切り替えられます。このプロセスは、ターゲットクラスターのすべてのデータが使用可能になるまでに、既存のクエリに悪影響を及ぼす可能性があります。ただし、データベースへの書き込みができない時間は最短になります。

スナップショット、復元、従来のサイズ変更アプローチでは、次のプロセスを使用します。

  1. 既存のクラスターのスナップショットを作成します。既存のクラスターがソースクラスターです。

  2. スナップショットを作成した時刻を記録します。そうすることで、スナップショット後のデータをターゲットデータベースにロードするための抽出、処理、ロード (ETL) プロセスを再実行する必要がある時点を識別できるようにします。

  3. 新しいクラスターにスナップショットを復元します。この新しいクラスターがターゲットクラスターです。サンプルデータがターゲットクラスターにあることを確認します。

  4. ターゲットクラスターのサイズを変更します。ターゲットクラスターに関して、新しいノードタイプ、ノード数、その他の設定を選択します。

  5. ソースクラスターのスナップショット作成後に発生した ETL プロセスでロードされたデータを確認します。ターゲットクラスターには、同じデータを同じ順序で再ロードしてください。進行中のデータロードがある場合、ソースクラスターとターゲットクラスターのデータが同じになるまで、このプロセスを数回繰り返します。

  6. ソースクラスターで実行中のすべてのクエリを停止します。これを行うには、クラスターを再起動するか、スーパーユーザーとしてログオンし、PG_CANCEL_BACKEND コマンドおよび PG_TERMINATE_BACKEND コマンドを使用できます。クラスターを再起動すると、クラスターが使用できないことを最も簡単に確認できます。

  7. ソースクラスター名を変更します。たとえば、examplecluster から examplecluster-source に変更します。

  8. 変更前のソースクラスター名を使用して、ターゲットクラスターの名前を変更します。たとえば、ターゲットクラスターの名前を examplecluster に変更します。これ以降、examplecluster を含むエンドポイントを使用するアプリケーションは、ターゲットクラスターに接続します。

  9. ターゲットクラスターに切り替えた後、ソースクラスターを削除し、すべてのプロセスが期待どおりに動作することを確認します。

または、データをターゲットクラスターに再ロードする前にソースとターゲットクラスターの名前を変更することもできます。このアプローチは、依存するシステムやレポートをすぐに最新状態にしてターゲットクラスターに反映する必要がない場合に有効です。この場合、ステップ 6 は前述のプロセスの最後に移動されます。

名前変更プロセスは、アプリケーションが引き続き同じエンドポイントを使用してクラスターに接続する必要がある場合にのみ必要になります。これが必要ない場合は、クラスターの名前を変更せずにそのクラスターに接続するアプリケーションを、ターゲットクラスターのエンドポイントを使用するように更新することもできます。

クラスター名を再利用するのには、いくつかの利点があります。最初に、エンドポイントが変わらないため、基盤となるクラスターを変更しても、アプリケーションの接続文字列を更新する必要がありません。次に、Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) の通知などの関連項目が、クラスター名に固定されます。これは、クラスターにセットアップした同じアラームと通知を継続して使用することができるということです。この継続的な使用は、アラームや通知などの関連項目を再設定することなく、柔軟にクラスターのサイズを変更する必要がある本番稼働用環境では特に重要です。