Amazon Redshift
クラスター管理ガイド (API バージョン 2012-12-01)

Amazon Redshift クラスター

移行のセクションでは、Amazon Redshift クラスターと呼ばれる一連のコンピューティングノードを起動してデータウェアハウスを作成する方法の基本を学習します。

概要

Amazon Redshift データウェアハウスは、ノードと呼ばれるコンピューティングリソースのコレクションであり、これらはクラスターと呼ばれるグループを構成します。各クラスターは、1 つの Amazon Redshift エンジンを実行し、1 つ以上のデータベースを含みます。

注記

現時点では、Amazon Redshift バージョン 1.0 エンジンを利用できます。ただし、エンジンの更新に伴い、複数の Amazon Redshift エンジンバージョンを選択できるようになる可能性があります。

コンソールの [Cluster Version (クラスターのバージョン)] フィールドで、クラスターの Amazon Redshift エンジンとデータベースのバージョンを決定できます。数字の最初の 2 つのセクションはクラスターのバージョンで、最後のセクションはクラスターのデータベースの固有の改訂番号です。次の例では、クラスターバージョンが 1.0 で、データベースの改訂番号が 884 です。

注記

コンソールでは、1 つのフィールドにこの情報が表示されますが、Amazon Redshift API では ClusterVersionClusterRevisionNumber の 2 つのパラメータになります。詳細については、『Amazon Redshift API Reference』の「クラスター」を参照してください。

Amazon Redshift には [バージョンアップグレードの許可] という設定があり、クラスターの Amazon Redshift エンジンの新しいバージョンが利用可能になると、エンジンを自動的にアップグレードするかどうかを指定できます。この設定はデータベースバージョンのアップグレードには影響しません。データベースバージョンは、クラスターに指定したメンテナンス期間中にアップグレードされます。Amazon Redshift エンジンのアップグレードはメジャーバージョンのアップグレードで、Amazon Redshift データベースのアップグレードはマイナーバージョンアップグレードです。バージョンの自動アップグレードは、メジャーバージョンに対してのみ無効にできます。マイナーバージョンアップグレードのメンテナンスウィンドウの詳細については、「メンテナンスウィンドウ」を参照してください。

Amazon Redshift のクラスターおよびノード

Amazon Redshift クラスターは、ノードで構成されています。クラスターごとに、リーダーノードと 1 つまたは複数のコンピューティングノードがあります。リーダーノードは、クライアントアプリケーションからクエリを受け取ってクエリを解析し、クエリ実行プランを作成します。次に、これらのプランの並列実行をコンピューティングノードと調整し、コンピューティングノードからの中間結果を集計します。最終的にクライアントアプリケーションに結果を返します。

コンピューティングノード、はクエリ実行プランを実行し、これらのクエリを処理するためにデータをコンピューティングノード間で伝送します。中間結果は、リーダーノードに送られて集計されてから、クライアントアプリケーションに送り返されます。リーダーノードおよびコンピューティングノードの詳細については、『Amazon Redshift Database Developer Guide』の「データウェアハウスシステムのアーキテクチャ」を参照してください。

クラスターを起動するときに、オプションの 1 つとしてノードタイプを指定します。ノードタイプによって、各ノードの CPU、RAM、ストレージ容量、およびストレージデバイスでのタイプが決まります。高密度ストレージ (DS) ノードタイプはストレージに最適化されています。高密度コンピューティング (DC) ノードタイプはコンピューティングに最適化されています。

DS2 ノードタイプは、大容量データのワークロードに合わせて最適化されており、ハードディスクドライブ (HDD) ストレージを使用します。

DC2 ノードタイプおよび前世代の DC1 のノードタイプは、パフォーマンスを集中的に使用するワークロードに適しています。DC ノードタイプはソリッドステートドライブ (SSD) ストレージを使用するため、DS ノードタイプに比べて I/O が高速ですが、ストレージスペースは少なくなります。

DC2 ノードタイプを使用するクラスターは、Virtual Private Cloud (VPC) で起動します。DC2 クラスターを EC2 クラシックモードで起動することはできません。詳細については、「VPC でクラスターを作成する」を参照してください。

選択するノードタイプは、以下の 3 点に大きく依存します。

  • Amazon Redshift 内にインポートするデータの量

  • データベースで実行するクエリとオペレーションの複雑さ

  • これらのクエリとオペレーションからの結果に依存するダウンストリームシステムのニーズ

ノードタイプは、さまざまなサイズで使用できます。DS2 ノードは、xlarge サイズと 8xlarge サイズで使用できます。DC2 ノードは、large サイズと 8xlarge サイズで使用できます。ノードサイズとノードの数によって、クラスターのストレージ総容量が決まります。

ノードタイプに応じて、1 つのノード (単一ノード) または複数のノード (複数ノード) を使用できます。8xlarge クラスターの最小ノード数は 2 です。単一ノードクラスターでは、ノードは機能上リーダーとコンピューティングで共有されます。マルチノードクラスターでは、リーダーノードとコンピューティングノードは分かれています。

Amazon Redshift は、各リージョンの各 AWS アカウントのリソースにクォータを適用します。クォータは、アカウントがリージョン内の特定のリソースタイプに作成できるリソースの数を制限します (ノードやスナップショットなど)。Amazon Redshift リソースに適用するデフォルトのクォータの詳細については、『アマゾン ウェブ サービス全般のリファレンス』の「Amazon Redshift の上限」を参照してください。上限緩和をご希望の場合は、Amazon Redshift 上限緩和申請を送信します。

クラスターのコストは、リージョン、ノードタイプ、ノードの数、ノードが事前に予約されているかどうかによって異なります。ノードのコストについては、「Amazon Redshift の料金表」ページを参照してください。

DC1 ノードタイプから DC2 ノードタイプへの移行

DC1 クラスターを新しい DC2 ノードタイプに移行すると、向上したパフォーマンスを利用できます。

DC2 ノードタイプを使用するクラスターは、Virtual Private Cloud (EC2-VPC) で起動する必要があります。クラスターが VPC (EC2-CLASSIC) にない場合は、最初にクラスターのスナップショットを作成し、次に以下のオプションのいずれかを選択します。

  • dc1.large クラスターから、VPC の dc2.large クラスターに直接復元します。

  • EC2-CLASSIC の dc1.8xlarge クラスターから、最初に VPC の dc1.8xlarge クラスターに復元し、次に dc1.8xlarge クラスターのサイズを dc2.8xlarge クラスターのサイズに変更します。dc2.8xlarge ノードタイプのスライス数は dc1.8xlarge ノードタイプと異なるため、dc2.8xl クラスターに直接復元することはできません。

クラスターが VPC にある場合は、以下のオプションのいずれかを選択します。

  • dc1.large クラスターから、VPC の dc2.large クラスターに直接復元します。

  • dc1.8xlarge クラスターから、dc1.8xl クラスターのサイズを dc2.8xlarge クラスターのサイズに変更します。dc2.8xlarge ノードタイプのスライス数は dc1.8xlarge ノードタイプと異なるため、dc2.8xlarge クラスターに直接復元することはできません。

詳細については、「Amazon Redshift スナップショット」および「クラスターのサイズ変更」を参照してください。

ノードタイプの詳細

以下のテーブルは、各ノードタイプとサイズのノード仕様をまとめたものです。最初の 2 つテーブルでは、以下の見出しに特定の意味があります。

  • vCPU は各ノードの仮想 CPU の数です。

  • ECU は、各ノードの Amazon EC2 計算ユニットの数です。

  • RAM は、各ノードのギビバイト (GiB) 単位のメモリ量です。

  • 1 ノードあたりのスライスとは、コンピューティングノードでパーティション分割されたスライスの数です。

    伸縮自在なリサイズを使用してクラスターのサイズを変更すると、ノードあたりのスライス数が変わる可能性があります。​

  • ストレージは、各ノードのストレージの容量とタイプです。

  • ノード範囲は、Amazon Redshift がノードタイプとサイズに対してサポートするノードの最小数と最大数です。

    注記

    前述のように、指定したリージョン内の AWS アカウントに適用されたクォータによっては、さらに少ないノードに制限されることがあります。

  • 全容量とは、ノード範囲で指定されているノードの最大数をデプロイした場合のクラスターのストレージ合計容量です。

重要

DS1 ノードタイプは廃止されています。新しい DS2 ノードタイプは DS1 より高いパフォーマンスを追加料金なしで提供します。DS1 リザーブドノードを購入した場合は、DS2 ノードタイプに移行するためのサポートについて、redshift-pm@amazon.com までお問い合わせください。

高密度ストレージノードタイプ

ノードサイズ vCPU ECU RAM (GiB) 1 ノードあたりのスライス 1 ノードあたりのストレージ ノード範囲 総容量
ds2.xlarge 4 13 31 2 2 TB HDD 1–32 64 TB
ds2.8xlarge 36 119 244 16 16 TB HDD 2–128 2 PB

高密度コンピューティングノードタイプ

ノードサイズ vCPU ECU RAM (GiB) 1 ノードあたりのスライス 1 ノードあたりのストレージ ノード範囲 総容量
dc1.large 2 7 15 2 160 GB SSD 1–32 5.12 TB
dc1.8xlarge 32 104 244 32 2.56 TB SSD 2–128 326 TB
dc2.large 2 7 15.25 2 160 GB NVMe-SSD 1–32 5.12 TB
dc2.8xlarge 32 99 244 16 2.56 TB NVMe-SSD 2–128 326 TB

ノードタイプの以前の名前

Amazon Redshift の以前のリリースでは、ノードタイプは異なる名前でした。Amazon Redshift API および AWS Command Line Interface (AWS CLI) では古い名前を使用できます。ただし、古い名前を参照するスクリプトは更新し、現在の名前を使用することをお勧めします。現在の名前と以前の名前は、次のとおりです。

ノードタイプの以前の名前

現在の名前 以前の名前
ds2.xlarge ds1.xlarge、dw.hs1.xlarge、dw1.xlarge
ds2.8xlarge ds1.8xlarge、dw.hs1.8xlarge、dw1.8xlarge
dc1.large dw2.large
dc1.8xlarge dw2.8xlarge

ノードの数の決定

選択するノードの数は、データセットのサイズおよび希望するクエリパフォーマンスによって決まります。例として高密度ストレージノードタイプを使用すると、32 TB のデータがある場合、16 個の ds2.xlarge ノードか、2 個の ds2.8xlarge ノードを選択できます。データの増分が少ない場合は、ds2.xlarge ノードサイズを選択すると 2 TB ずつ拡張できます。一般的に、データの増分が多い場合は、ds2.8xlarge ノードサイズを選択することをお勧めします。

Amazon Redshift はクラスターのすべてのコンピューティングノードにクエリを分散し、並列で実行するので、クラスターにノードを追加するとクエリパフォーマンスを向上させることができます。また、Amazon Redshift はクラスター内のすべてのコンピューティングノードにデータも分散します。2 つ以上のコンピューティングノードを持つクラスターを実行する場合は、各ノードのデータが常に別のノードのディスクにミラーリングされ、データ損失が発生するリスクが減少します。

どちらを選択しても、Amazon Redshift consoleと Amazon CloudWatch メトリクスのクエリパフォーマンスをモニタリングできます。また、必要に応じてノードを追加または削除して、最適に動作するようにストレージとパフォーマンスのバランスをとることもできます。追加のノードをリクエストしたときは、Amazon Redshift でデプロイメント、ロードバランシング、およびデータメンテナンスの詳細がすべて管理されます。クラスターパフォーマンスの詳細については、「Amazon Redshift クラスターのパフォーマンスをモニタリングする」を参照してください。

より長い期間 (1 年以上など)、継続してクラスターの実行を維持する予定の場合、1 年間または 3 年間、コンピューティングノードを予約することで、料金を大幅に節約することができます。コンピューティングノードを予約するには、リザーブドノードというサービスをご購入ください。予約する個々のコンピューティングノードについて、1 つのサービスを購入します。コンピューティングノードを予約した場合、クラスターが実行されているかどうかにかかわらず、固定の前払い料金と時間料金をお支払いいただきます。ただし、時間料金は、オンデマンドの使用料金よりも大幅に安くなります。詳細については、「Amazon Redshift リザーブドノードの購入」を参照してください。

クラスターのサイズ変更

最初にクラスターをプロビジョニングした後にストレージとパフォーマンスの要件が変更された場合、クラスターのサイズを変更できます。ノードを追加または削除してクラスターをスケールインまたはスケールアウトできます。また、別のノードタイプを指定してクラスターを拡大または縮小することもできます。

たとえば、さらにノードを追加したり、ノードタイプを変更したり、単一ノードクラスターをマルチノードクラスターに変更したり、マルチノードクラスターを単一ノードクラスターに変更したりすることができます。ただし、変更後のクラスターが、現在のデータを保持するのに十分な大きさであることを確認する必要があります。変更後のサイズが不十分な場合、サイズの変更は失敗します。API を使用するときは、ノードタイプ、ノードサイズ、ノードの数のいずれかのみを変更する場合でもすべて指定する必要があります。

以下にリサイズプロセスを示します。

  1. リサイズプロセスを開始すると、Amazon Redshift はリサイズリクエストを承認するイベント通知を送信し、新しい (ターゲット) クラスターのプロビジョニングを開始します。

  2. 新しい (ターゲット) クラスターがプロビジョニングされると、Amazon Redshift はリサイズが開始されたというイベント通知を送信し、読み取り専用モードで既存の (ソース) クラスターを再開します。再起動すると、クラスターへの既存の接続はすべて終了します。すべての完了しなかったトランザクション(コピーも含めて)は、ロールバックされます。クラスターが読み取り専用モードの場合、クエリの読み取りはできますが、クエリの書き込みはできません。

  3. Amazon Redshift は、ソースクラスターからターゲットクラスターにデータをコピーし始めます。

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

  5. リサイズが完了すると、Amazon Redshift はリサイズが完了したというイベント通知を送信します。ターゲットクラスターに接続し、クエリの読み取りと書き取りの実行を再開できます。

クラスターのサイズを変更するとき、サイズ変更が完了するまでは読み取り専用モードのままです。Amazon Redshift consoleのクラスターの [ステータス] タブでサイズ変更の進捗を確認することができます。クラスターのサイズ変更にかかる時間は、各ノードのデータ量に左右されます。通常、サイズ変更処理には数時間から 1 日かかります。ただし、データ量が多いクラスターではさらに時間がかかることもあります。これは、データが元のクラスターの各ノードからコピー先のクラスターのノードに並列コピーされるためです。クラスターのサイズ変更の詳細については、「Amazon Redshift でのクラスターのサイズ変更」および「クラスターのサイズ変更」を参照してください。

サイズ変更の操作中、Amazon Redshift はテーブルをソートしません。クラスターのサイズを変更すると、Amazon Redshift は分散方式に基づいてデータベースのテーブルを新しいコンピューティングノードに分散し、ANALYZE を実行して統計を更新します。削除対象としてマークされた行は転送されないため、テーブルの再ソートが必要な場合は VACUUM のみを実行する必要があります。詳細については、『Amazon Redshift Database Developer Guide』の「テーブルのバキューム処理」を参照してください。

クラスターがパブリックであり、VPC 内に存在する場合、サイズ変更後もリーダーノードの elastic IP アドレス (EIP) は変更されません。クラスターがプライベートであり、VPC 内に存在する場合、サイズ変更後もリーダーノードのプライベート IP アドレスは変更されません。クラスターが VPC 内に存在しない場合、サイズ変更オペレーションの一部として、新しいパブリック IP アドレスがリーダーノードに割り当てられます。

クラスターのリーダーノード IP アドレスを取得するには、以下に示すように dig ユーティリティを使用します。

dig mycluster.abcd1234.us-west-2.redshift.amazonaws.com

リーダーノード IP アドレスは、以下に示すように結果の ANSWER SECTION の末尾にあります。

クラスターの起動用にサポートされているプラットフォーム

Amazon Redshift クラスターは、選択した Amazon Redshift のノードタイプとサイズ用に構成された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されます。EC2-Classic か EC2-VPC のどちらかのプラットフォームで Amazon Redshift クラスターを起動できます。これらのプラットフォームは、Amazon EC2 インスタンスに対してサポートされています。これらのプラットフォームの詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「サポートされているプラットフォーム」を参照してください。利用可能なプラットフォームは、ご利用の AWS アカウントの設定によって異なります。

注記

SQL クライアントツールと Amazon Redshift データベースとの接続問題を防止するには、以下の 2 つの方法のいずれかを実行することをお勧めします。パケットサイズの交渉をホストに許可する着信ルールを設定できます。または、Amazon EC2 インスタンスのネットワークインターフェイス (NIC) で最大転送単位 (MTU) を 1500 に設定して、TCP/IP ジャンボフレームを無効化できます。上記の方法の詳細については、「クエリがハングして、クラスターに達しない場合がある」を参照してください。

EC2-Classic プラットフォーム

EC2-Classic プラットフォームでは、クラスターは他の AWS ユーザーと共有する単一のフラットネットワーク内で稼働します。EC2-Classic プラットフォームでクラスターをプロビジョニングする場合は、クラスターに 1 つ以上の Amazon Redshift クラスターセキュリティグループを関連付けて、クラスターへのアクセスを制御します。詳細については、「Amazon Redshift クラスターセキュリティグループ」を参照してください。

EC2-VPC プラットフォーム

EC2-VPC プラットフォームでは、クラスターは論理的に AWS アカウントに限定された Virtual Private Cloud (VPC) 内で稼働します。EC2-VPC プラットフォームのクラスターをプロビジョニングする場合は、クラスターに 1 つ以上の VPC のセキュリティグループを関連付けて、クラスターへのアクセスを制御します。詳細については、Amazon VPC ユーザーガイド の「VPC のセキュリティグループ」を参照してください。

VPC でクラスターを作成するには、最初に VPC のサブネット情報を指定して Amazon Redshift クラスターサブネットグループを作成してから、クラスターの起動時にサブネットグループを指定する必要があります。詳細については、「Amazon Redshift のクラスターサブネットグループ」を参照してください。

Amazon Virtual Private Cloud (Amazon VPC) に関する詳細については、Amazon VPC の製品詳細ページを参照してください。

プラットフォームの選択

AWS アカウントは、インスタンスを両方のプラットフォームで起動できるか、EC2-VPC だけで起動できるかが、リージョンごとに決まっています。アカウントがサポートしているプラットフォームを確認し、クラスターを起動するには、次の操作を行います。

  1. クラスターをデプロイする AWS リージョンを決定します。Amazon Redshift を利用できる AWS リージョンのリストについては、『アマゾン ウェブ サービス全般のリファレンス』の「リージョンとエンドポイント」を参照してください。

  2. 選択した AWS リージョンでアカウントがサポートしている Amazon EC2 プラットフォームを確認します。この情報は、Amazon EC2 コンソールで確認できます。手順については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「サポートされているプラットフォーム」を参照してください。

  3. アカウントが両方のプラットフォームをサポートしている場合は、Amazon Redshift クラスターをデプロイするプラットフォームを選択します。アカウントが EC2-VPC のみをサポートしている場合は、VPC にクラスターをデプロイする必要があります。

  4. Amazon Redshift クラスターをデプロイします。Amazon Redshift consoleを使用して、または Amazon Redshift API、CLI、SDK ライブラリを使用してプログラムでクラスターをデプロイすることができます。これらのオプションや関連ドキュメントへのリンクについては、「Amazon Redshift とは?」を参照してください。

リージョンとアベイラビリティゾーンの考慮事項

Amazon Redshift は、複数の AWS リージョンで利用できます。デフォルトでは、Amazon Redshift は、選択した AWS リージョン内のランダムに選択されたアベイラビリティーゾーン (AZ) にクラスターをプロビジョニングします。すべてのクラスターノードが同じ AZ にプロビジョニングされます。

Amazon Redshift が特定の AZ で使用できる場合、オプションでその AZ をリクエストできます。たとえば、1 つの AZ で Amazon EC2 インスタンスが既に実行されている場合、同じ AZ 内に Amazon Redshift クラスターを作成して、レイテンシーを低減させることができます。また、可用性を高めるために別の AZ を選択することもできます。Amazon Redshift は AWS リージョンの一部の AZ では利用できない可能性があります。

Amazon Redshift クラスターをプロビジョニングすることができる、サポートされている AWS リージョンのリストについては『アマゾン ウェブ サービス全般のリファレンス』の「リージョンとエンドポイント」を参照してください。

クラスターのメンテナンス

Amazon Redshift は定期的にメンテナンスを実行して、クラスターにアップグレードを適用します。更新中は Amazon Redshift クラスターで通常のオペレーションを実行することはできません。クラスターのメンテナンス方法を制御する方法がいくつかあります。たとえば、クラスターにアップデートをいつ展開するかを制御できます。また、クラスターが常に最新のリリースバージョンを実行するのか、以前にリリースされたバージョンから最新のリリースバージョンを実行するのかを選択することもできます。最後に、必須ではないメンテナンスアップデートをしばらく延期することもできます。

メンテナンスウィンドウ

Amazon Redshift により、1 週間 (月曜日から日曜日まで) のうちのランダムな日に、リージョンごとに決められた 8 時間のうちのランダムな 30 分間、メンテナンスウィンドウが割り当てられます。

デフォルトの メンテナンスウィンドウ

次のリストは、デフォルトでメンテナンスウィンドウが割り当てられる各リージョンの時間を示します。

  • 米国東部(バージニア北部) リージョン: 03:00–11:00 UTC

  • 米国東部 (オハイオ) リージョン: 03:00–11:00 UTC

  • 米国西部 (北カリフォルニア) リージョン: 06:00–14:00 UTC

  • 米国西部 (オレゴン) リージョン: 06:00–14:00 UTC

  • カナダ (中部) リージョン: 03:00–11:00 UTC

  • アジアパシフィック (ムンバイ) リージョン: 16:30–00:30 UTC

  • アジアパシフィック (ソウル) リージョン: 13:00–21:00 UTC

  • アジアパシフィック (シンガポール) リージョン: 14:00–22:00 UTC

  • アジアパシフィック (シドニー) リージョン: 12:00–20:00 UTC

  • アジアパシフィック (東京) リージョン: 13:00–21:00 UTC

  • 欧州 (フランクフルト) リージョン: 06:00–14:00 UTC

  • 中国 (北京) リージョン: 13:00–21:00 UTC

  • 中国 (寧夏) リージョン: 13:00–21:00 UTC

  • 欧州 (アイルランド) リージョン: 22:00–06:00 UTC

  • 欧州 (ロンドン) リージョン: 22:00–06:00 UTC

  • EU (パリ) リージョン: 23:00–07:00 UTC

  • 欧州 (ストックホルム) リージョン: 23:00–07:00 UTC

  • 南米 (サンパウロ) リージョン: 19:00–03:00 UTC

メンテナンスイベントが特定の週に予定されている場合、割り当てられた 30 分のメンテナンスウィンドウ中に開始されます。メンテナンスの実行中、Amazon Redshift で実行中のクエリまたはその他の操作は終了します。ほとんどのメンテナンスは 30 分のメンテナンスウィンドウ中に完了しますが、メンテナンスタスクの一部はウィンドウが閉じた後も実行を続ける場合があります。スケジュールされたメンテナンスウィンドウの間に実行されるメンテナンスタスクがない場合、クラスターは次にスケジュールされたメンテナンスウィンドウまで通常どおり稼働します。

クラスターをプログラムで、または Amazon Redshift consoleを使用して変更すると、スケジュールされたメンテナンスウィンドウを変更できます。ウィンドウは 30 分以上、24 時間以内である必要があります。詳細については、「コンソールを使ったクラスターの管理」を参照してください。

後でメンテナンス

クラスターのメンテナンスウィンドウを変更する必要がある場合、メンテナンスを最長 45 日まで遅延できます。たとえば、クラスターのメンテナンスウィンドウが水曜日の 8:30 ~ 9:00 (UTC) に設定されていて、その時間にクラスターにアクセスする必要がある場合、メンテナンスを後の時間に遅らせることができます。ハードウェアをアップデートする必要がある場合を除き、遅延を指定した場合は、クラスターのメンテナンスは一切行われません。

遅延期間中にハードウェアを更新する必要がある、または他の必須の更新を行う必要がある場合、通知して必要な変更を行います。更新中は、クラスターを使用できません。

クラスターのメンテナンスを遅らせる場合、遅延期間後のメンテナンスウィンドウは必須です。これは遅らせることはできません。

注記

メンテナンスが開始した後で遅らせることはできません。

詳細については、「遅延メンテナンス」を参照してください。

クラスターメンテナンストラックの選択

Amazon Redshift が新しいクラスターバージョンをリリースすると、メンテナンスウィンドウ中にクラスターが更新されます。クラスターを最新の承認済みリリースに更新するか、前のリリースに更新するか制御できます。

メンテナンストラックは、メンテナンスウィンドウ中にどのクラスターバージョンを適用するかを制御します。Amazon Redshift が新しいクラスターバージョンをリリースすると、そのバージョンは最新のトラックに割り当てられ、以前のバージョンは前のトラックに割り当てられます。クラスターのメンテナンストラックを設定します。次の値のいずれかを指定してください。

  • 最新 – 最新の承認済みクラスターバージョンを使用します。

  • – 最新バージョンの前のクラスターバージョンを使用します。

たとえば、現在クラスターはバージョン 1.0.2762 を実行しており Amazon Redshift の最新バージョンが 1.0.3072 であるとします。メンテナンストラック値を [最新] に設定した場合、クラスターは次のメンテナンス期間中に 1.0.3072 (次の承認済みリリース) に更新されます。メンテナンストラック値を [Trailing (前)] に設定した場合、クラスターは 1.0.3072 以降の新しいリリースが公開されるまでは更新されません。

メンテナンストラックの切り替え

通常、クラスターのトラック変更は 1 回のみの決定事項です。トラックを変更するときは注意が必要です。メンテナンストラックを [Trailing (前)] から [最新] に変更すると、クラスターは次のメンテナンス期間中に [最新] トラックリリースバージョンに変更されます。ただし、クラスターのメンテナンストラックを [Trailing (前)] に変更すると、[最新] トラックリリースバージョン後に新しいリリースが出るまで、クラスターは更新されません。

メンテナンストラックと復元

スナップショットはソースクラスターのメンテナンストラックを継承します。スナップショットの作成後にソースクラスターのメンテナンストラックを変更した場合、スナップショットとソースクラスターは別のトラックにあります。スナップショットから復元すると、新しいクラスターは、ソースクラスターから継承されたメンテナンストラックに配置されます。メンテナンストラックは、復元オペレーションが完了した後で変更できます。クラスターのサイズ変更によるクラスターのメンテナンストラックへの影響はありません。

詳細については、クラスターのメンテナンストラックの設定 を参照してください。

クラスターバージョンの管理

メンテナンストラックは一連のリリースです。クラスターが最新のトラックにあるか前のトラックにあるかを判断できます。クラスターを最新のトラックに配置する場合、メンテナンス期間中は、常に最新のクラスターリリースバージョンにアップグレードされます。クラスターを前のトラックに配置する場合、最後にリリースされたバージョンの直前にリリースされたクラスターリリースバージョンが常に実行されます。

Amazon Redshift コンソールリストの [Release Status (リリースステータス)] では、アップグレードできるクラスターがあるかどうかが示されます。

デフォルトのディスク容量アラーム

Amazon Redshift クラスターを作成するとき、クラスターのすべてのノードで使用されているディスク容量の平均比率を監視するように Amazon CloudWatch アラームを任意で設定できます。このアラームをデフォルトのディスク容量アラームと言います。

デフォルトのディスク容量アラームの目的は、クラスターのストレージ容量を監視することです。このアラームは、データウェアハウスのニーズを基に設定できます。たとえば、クラスターのサイズを変更する必要性の指標として警告を使用できます。別のノードタイプにするかノードを追加するため、または今後の拡張に備えてリザーブドノードを購入するためにサイズを変更できます。

ディスクの使用量が、指定した期間、特定の回数の指定した割合に達したとき、または超えたとき、デフォルトのディスク容量アラームがトリガーされます。デフォルトでは、指定した割合に達し、かつ 5 分以上その割合かそれ以上の状態が続いたとき、このアラームがトリガーされます。デフォルトの値は、クラスターを起動した後編集できます

CloudWatch アラームがトリガーされると、Amazon Simple Notification Service (Amazon SNS) により、指定された受取人に、割合がしきい値に達したことを警告する通知が送信されます。Amazon SNS は、トピックを使用して通知を送信する受取人とメッセージを指定します。既存の Amazon SNS トピックを使用できますが、クラスターの起動時に指定した設定に基づいてトピックを作成することもできます。このアラームのトピックは、クラスターを起動した後編集できます。Amazon SNS トピック作成の詳細については、「Amazon Simple Notification Service の使用開始」を参照してください。

クラスターを起動した後、[CloudWatch アラーム] の下のクラスターの [ステータス] ウィンドウからアラームを表示したり編集したりすることができます。名前は percentage-disk-space-used-default-<string> です。アラームを開いて、関連付けられている Amazon SNS トピックを表示し、アラームの設定を編集することができます。既存の Amazon SNS トピックを使用するように選択していない場合、作成されるトピックの名前は、<clustername>-default-alarms (<recipient>) です。たとえば、examplecluster-default-alarms (notify@example.com) のようになります。

デフォルトのディスク容量アラームを設定して編集する方法については、「クラスターの作成」および「デフォルトのディスク容量アラームの編集」を参照してください。

注記

クラスターを削除すると、クラスターに関連付けられているアラームは削除されませんが、トリガーされることもありません。必要がなくなったら、CloudWatch コンソールからアラームを削除できます。

クラスターの名前変更

クラスターに別の名前を使用する必要がある場合は、クラスターの名前を変更できます。クラスターのエンドポイントには、クラスター名 (クラスター識別子とも呼ばれる) が含まれているため、名前の変更が完了した後、新しい名前を使用するようにエンドポイントを変更します。たとえば、既存の examplecluster という名前のクラスターを、newcluster という名前に変更した場合は、newcluster 識別子を使用するようにエンドポイントを変更します。このクラスターに接続するアプリケーションは、新しいエンドポイントで更新する必要があります。

アプリケーションのエンドポイントを変更せずにアプリケーションの接続先のクラスターを変更する場合は、クラスターの名前を変更できます。この場合は、最初に元のクラスターの名前を変更してから、新しい接続先のクラスターを元のクラスターの名前に変更する必要があります。クラスター識別子はアカウントとリージョン内で一意にする必要があり、元のクラスターと変更後のクラスターを同じ名前にできないため、この操作が必要になります。スナップショットからクラスターを復元するときに、依存アプリケーションの接続プロパティを変更したくない場合も、この操作を行います。

注記

元のクラスターを削除する場合は、不要なクラスターのスナップショットを削除してください。

クラスターの名前を変更すると、クラスターの状態は、このプロセスが終了するまで renaming に変わります。クラスターに使用していた古い DNS 名は直ちに削除されますが、キャッシュには数分間残っています。名前を変更したクラスターの新しい DNS 名は、10 分以内で有効になります。名前を変更したクラスターは、新しい名前が有効になるまで使用できません。クラスターが再起動され、クラスターへの既存の接続は削除されます。これが完了すると、新しい名前を使用するようにエンドポイントが変更されます。そのため、名前の変更を開始する前にクエリの実行を停止し、名前の変更後に再起動する必要があります。

クラスターのスナップショットは保持され、クラスターに関連付けられたすべてのスナップショットは、クラスターの名前を変更した後も関連付けを維持します。たとえば、本番稼働用データベースにサービスを提供するクラスターがあり、そのクラスターに複数のスナップショットがあるとします。クラスターの名前を変更し、スナップショットのある本番環境に置き換えると、名前を変更したクラスターに既存のスナップショットが関連付けられます。

Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) イベントの通知は、クラスター名に関連付けられます。クラスターの名前を変更した場合、それに応じてこれらの通知も更新する必要があります。[イベント] ペインの CloudWatch コンソールで CloudWatch アラームを、Amazon Redshift コンソールで Amazon SNS イベント通知を更新できます。クラスターのロードおよびクエリデータには、名前変更前と名前変更後のデータが引き続き表示されます。ただし、パフォーマンスデータは、名前変更プロセスの完了後にリセットされます。

詳細については、「クラスターの変更」を参照してください。

クラスターのシャットダウンと削除

クラスターの実行を停止して料金の発生を防ぐ場合は、クラスターをシャットダウンできます。シャットダウンするときに、オプションで最終スナップショットを作成できます。最終スナップショットを作成する場合、Amazon Redshift はクラスターの手動スナップショットを作成した後、クラスターをシャットダウンします。後でクラスターの実行とデータのクエリを再開する場合は、そのスナップショットを復元できます。

クラスターとそのデータが不要になった場合は、最終スナップショットを作成しないでシャットダウンすることができます。この場合、クラスターとデータは完全に削除されます。クラスターのシャットダウンと削除の詳細については、「クラスターの削除」を参照してください。

クラスターのシャットダウン時に最終的な手動スナップショットを作成するかどうかにかかわらず、クラスターのシャットダウン後、クラスターに関連付けられた自動スナップショットはすべて削除されます。クラスターに関連付けられた手動スナップショットは保持されます。オプションの最終スナップショットも含めて、保持された手動スナップショットは、クラスターをシャットダウンするときに実行中のクラスターが他にない場合、または、実行中の Amazon Redshift クラスターで利用できる無料ストレージ枠を超えている場合、Amazon Simple Storage Service ストレージ料金が課金されます。スナップショットのストレージ料金の詳細については、Amazon Redshift の料金表ページを参照してください。

クラスターステータス

クラスター状態は、クラスターの現在のステータスを表示します。次の表では、各クラスターステータスについて説明します。

ステータス 説明
available クラスターは実行されていて、利用可能です。
available, prep-for-resize クラスターは伸縮自在なサイズ変更の準備をしています。クラスターは稼働しており、読み取りクエリや書き込みクエリに使用できますが、スナップショットの作成などのクラスターオペレーションは使用できません。
available, resize-cleanup 伸縮自在なサイズ変更オペレーションは、新しいクラスターのノードへのデータ転送を完了します。クラスターは稼働しており、読み取りクエリや書き込みクエリに使用できますが、スナップショットの作成などのクラスターオペレーションは使用できません。
available クラスターは実行されていて、利用可能です。
creating Amazon Redshift はクラスターを作成しています。詳細については、「クラスターの作成」を参照してください。
deleting Amazon Redshift はクラスターを削除しています。詳細については、「クラスターの削除」を参照してください。
final-snapshot Amazon Redshift は、クラスターを削除する前に最後のスナップショットを取得しています。詳細については、「クラスターの削除」を参照してください。
hardware-failure

クラスターにハードウェア障害が生じました。

単一ノードクラスターがある場合、そのノードを置き換えることはできません。クラスターを復元するには、スナップショットを使います。詳細については、「Amazon Redshift スナップショット」を参照してください。

incompatible-hsm Amazon Redshift は、ハードウェアセキュリティモジュール (HSM) に接続できません。クラスターと HSM 間の HSM 設定を確認してください。詳細については、「Amazon Redshift でのハードウェアセキュリティモジュールを使用した暗号化」を参照してください。
incompatible-network 基本的なネットワーク設定に問題があります。クラスターを起動する VPC が存在すること、そして設定が正しいことを確認してください。詳細については、「Amazon Virtual Private Cloud (VPC) でクラスターを管理する」を参照してください。
incompatible-parameters 関連付けられたパラメータグループの 1 つ以上のパラメータ値に問題があり、パラメータ値の適用ができません。パラメータグループを変更し、無効な値を更新してください。詳細については、「Amazon Redshift パラメータグループ」を参照してください。
incompatible-restore スナップショットからクラスターを復元時に問題が発生しました。別のスナップショットでクラスターの復元を再度お試しください。詳細については、「Amazon Redshift スナップショット」を参照してください。
modifying Amazon Redshift は、クラスターへの変更を加えています。詳細については、「クラスターの変更」を参照してください。
rebooting Amazon Redshift は、クラスターを再起動しています。詳細については、「クラスターの再起動」を参照してください。
renaming Amazon Redshift は、クラスターに新しい名前を適用しています。詳細については、「クラスターの名前変更」を参照してください。
resizing Amazon Redshift は、クラスターのサイズを変更しています。詳細については、「クラスターのサイズ変更」を参照してください。
rotating-keys Amazon Redshift は、クラスターの暗号化キーを更新しています。詳細については、「Amazon Redshift での暗号化キーの更新」を参照してください。
storage-full クラスターがストレージ容量限に達しました。ノードを追加するためにクラスターのサイズ変更をするか、または別のノードサイズを選択してください。詳細については、「クラスターのサイズ変更」を参照してください。
updating-hsm Amazon Redshift は HSM 設定を更新しています。