Amazon Redshift クラスター - Amazon Redshift

Amazon Redshift クラスター

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

Amazon Redshift クラスターの概要

Amazon Redshift データウェアハウスは、ノードと呼ばれるコンピューティングリソースの集合で、クラスターと呼ばれるグループに編成されています。各クラスターは Amazon Redshift エンジンを実行し、1 つ以上のデータベースを含みます。

注記

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

Amazon Redshift のクラスターとノード

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

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

注記

Amazon Redshift コンソールでクラスターを作成する場合 (https://console.aws.amazon.com/redshift/) は、データのサイズとクエリの特性に基づいてクラスター設定に関する推奨事項を取得できます。このサイズ計算ツールを使用するには、RA3 ノードタイプがサポートされている AWS リージョンのコンソールで [ヘルプ選択] を見つけてください。詳細については、「クラスターの作成」を参照してください。

クラスターを起動するときに指定するオプションの 1 つに、ノードタイプがあります。ノードタイプによって、各ノードの CPU、RAM、ストレージ容量、およびストレージデバイスでのタイプが決まります。

Amazon Redshift ではお客様のワークロードに対処するため、様々なノードタイプをご用意しています。必要なパフォーマンス、データサイズ、その増大によって、RA3 または DC2 をお選びいただくよう推奨します。

マネージドストレージが付属する RA3 ノードでは、コンピューティング性能とマネージドストレージのスケーリングと支払いを独立させることで、データウェアハウスを最適化できます。RA3 では、パフォーマンス要件に基づいてノードの数を選択し、使用したマネージドストレージに対してのみ料金が発生します。日々処理するデータ量を基に、RA3 クラスターのサイズを選択してください。RA3 ノードタイプを使用するクラスターは、仮想プライベートクラウド (VPC) で起動します。RA3 クラスターを EC2-Classic で起動することはできません。詳細については、「VPC でクラスターを作成する」を参照してください。

Amazon Redshift のマネージドストレージでは、各 RA3 ノードに大容量の高性能 SSD を使用し、ローカルストレージの高速化が行われています。また、Amazon S3 によって長期間の耐久性があるストレージが提供されています。1 つのノード内のデータが増加して大容量ローカル SSD のサイズを超えた場合、そのデータは Amazon Redshift のマネージドストレージにより自動的に Amazon S3 にオフロードされます。Amazon Redshift のマネージドストレージに対して支払うのは、データが高性能 SSD 内にあるか Amazon S3 内にあるかにかかわらず、同じ低額な料金です。ますます増大するストレージを必要とするワークロードの場合、マネージドストレージを使用することでデータウェアハウスのストレージ容量を自動的にスケールできます。ノードの追加やそのための支払いは必要ありません。

DC2 ノードでは、ローカル SSD ストレージを使用してコンピューティング負荷の高いデータウェアハウスを持つことができます。必要なノード数はデータサイズとパフォーマンス要件に基づいて選択します。DC2 ノードは高いパフォーマンスを引き出すためローカルにデータを保存し、データのサイズが増えるに従って、さらに多くのコンピューティングノードを追加して、クラスターのストレージ容量を増強できます。圧縮で 1 TB 未満のデータセットでは、最も低い価格で最良のパフォーマンスを得るため、DC2 ノードタイプの利用を推奨します。データ量の増大が予想される場合は、RA3 ノードのご利用をお勧めします。このタイプのノードを使用することで、コンピューティング性能とストレージを別々にサイジングし、最高量の料金とパフォーマンスを活用できます。DC2 ノードタイプを使用するクラスターは、Virtual Private Cloud (VPC) で起動します。DC2 クラスターを EC2-Classic で起動することはできません。詳細については、「VPC でクラスターを作成する」を参照してください。

DS2 ノードはハードディスクドライブ (HDD) を使用して、大容量のデータウェアハウスを作成できるので、代わりに RA3 ノードを使用するようお勧めします。DS2 ノードを使用している場合、アップグレードのガイドラインについては、「RA3 ノードタイプへのアップグレード」を参照してください。ds2.xlarge のノードを 8 個以上使用しているお客様、または数に関係なく ds2.8xlarge ノードをご利用のお客様は、RA3 にアップグレードし、同じオンデマンドコストで、2 倍のストレージとより高いパフォーマンスをご利用になれます。

ノードタイプは、さまざまなサイズで使用できます。ノードサイズとノードの数によって、クラスターのストレージ総容量が決まります。詳細については、「ノードタイプの詳細」を参照してください。

ノードタイプに応じて、1 つのノード (単一ノード) または複数のノード (複数ノード) を使用できます。一部のノードタイプのクラスターのノードの 最小数は 2 ノードです。単一ノードクラスターでは、ノードは機能上リーダーとコンピューティングで共有されます。単一ノードクラスターは、本番稼働ワークロードの実行には推奨されません。マルチノードクラスターでは、リーダーノードとコンピューティングノードは分かれています。リーダーノードは、コンピューティングノードと同じノードタイプです。料金はコンピューティングノードに対してのみ課金されます。

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

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

ノードタイプの詳細

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

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

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

  • ノードあたりのスライスの数は、従来のサイズ変更でクラスターを作成またはサイズ変更するときに、コンピューティングノードがパーティション分割されるデフォルトのスライス数です。

    伸縮自在なリサイズを使用してクラスターのサイズを変更すると、ノードあたりのスライス数が変わる可能性があります。​ ただし、クラスターのすべてのコンピューティングノードのスライスの総数は、伸縮自在なサイズ変更後も変わりません。

    スナップショットからの復元操作を使用してクラスターを作成する場合、ノードタイプを変更すると、元のクラスターから生成されるクラスターのスライスの数が変わることがあります。

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

  • ノード範囲は、Amazon Redshift によりサポートされている、ノードタイプとサイズに対するノードの最小数および最大数です。

    注記

    選択した AWS リージョン内の AWS アカウントに適用されたクォータによっては、さらに少ないノードに制限されることがあります。上限緩和をご希望の場合は、Amazon Redshift 上限緩和申請を送信します。

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

RA3 ノードタイプ
ノードサイズ vCPU RAM (GiB) ノードごとのデフォルトスライス ノードあたりのマネージドストレージクォータ クラスター作成によるノード範囲 マネージドストレージの総容量
ra3.xlplus 4 32 2 32 TB1、5 1~162 1024 TB2、4
ra3.4xlarge 12 96 4 128 TB1 2~323 8192 TB3、4
ra3.16xlarge 48 384 16 128 TB1 2~128 16,384 TB4

1 Amazon Redshift マネージドストレージ用のストレージクォータを示します。

2 ra3.xlplus ノードタイプで、最大 16 個のノードを持つクラスターを作成できます。シングルノードクラスターでは、従来のサイズ変更のみがサポートされます。マルチノードクラスターでは、伸縮自在なサイズ変更により最大 32 個のノードに変更できます。

3 ra3.4xlarge または ra3.16xlarge ノードタイプで、最大 16 個のノードを持つクラスターを作成できます。伸縮自在なサイズ変更で、最大 64 ノードまでノード変更できます。

4 マネージドストレージの合計クォータは、ノードの最大数にノードあたりのマネージドストレージのクォータを掛けたものです。

5 1 ノードの ra3.xlplus クラスターに対するマネージドストレージの合計クォータは 4 TB です。

高密度ストレージノードタイプ
ノードサイズ vCPU RAM (GiB) ノードごとのデフォルトスライス 1 ノードあたりのストレージ ノード範囲 合計容量
ds2.xlarge 4 31 2 2 TB HDD 1~32 64 TB
ds2.8xlarge 36 244 16 16 TB HDD 2~128 2 PB
高密度コンピューティングノードタイプ
ノードサイズ vCPU RAM (GiB) ノードごとのデフォルトスライス 1 ノードあたりのストレージ ノード範囲 合計容量
dc2.large 2 15 2 160 GB NVMe-SSD 1~32 5.12 TB
dc2.8xlarge 32 244 16 2.56 TB NVMe-SSD 2~128 326 TB
dc1.large1 2 15 2 160 GB SSD 1~32 5.12 TB
dc1.8xlarge1 32 244 32 2.56 TB SSD 2~128 326 TB

1 DC1 ノードタイプよりも DC2 ノードタイプをお勧めします。アップグレード方法の詳細については、「DC1 ノードタイプから DC2 ノードタイプへのアップグレード」を参照してください。

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

Amazon Redshift の以前のリリースでは、特定のノードタイプは異なる名前でした。Amazon Redshift API および 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

ノードの数の決定

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

Amazon Redshift コンソールと Amazon CloudWatch メトリクスを使用して、クエリのパフォーマンスをモニタリングできます。クラスターの価格とパフォーマンスのバランスを維持するために、必要に応じてノードを追加または削除することもできます。追加のノードをリクエストしたときは、Amazon Redshift でデプロイメント、ロードバランシング、およびデータメンテナンスの詳細がすべて管理されます。クラスターパフォーマンスの詳細については、「Amazon Redshift クラスターパフォーマンスのモニタリング」を参照してください。

リザーブドノードは、一定量の本番稼働番ワークロードに最適で、オンデマンド料金と比べて大幅な割引を受けることができます。本番稼働設定を検証するために、実験と概念実証を実行した後で、リザーブドノードを購入できます。詳細については、「Amazon Redshift リザーブドノードの購入」を参照してください。

クラスターを一時停止すると、クラスターが一時停止している間にオンデマンド課金が中断されます。この一時停止期間中は、バックアップストレージに対してのみお支払いいただきます。これにより、データウェアハウスの容量を事前にプランニングしたり購入したりする手間が省けます。また、開発環境またはテスト環境をコスト効率のよい方法で管理することができます。

オンデマンドノードとリザーブドノードの料金については、「Amazon Redshift 料金表」を参照してください。

クラスターの作成時に EC2-VPC を使用する

Amazon Redshift クラスターは、選択した Amazon Redshift ノードタイプとサイズに合わせて構成された Amazon EC2 インスタンスで実行されます。EC2-VPC を使用してクラスターを作成します。EC2-Classic をまだ使用している場合は、EC2-VPC を使用してパフォーマンスとセキュリティを向上させることをお勧めします。これらのネットワークプラットフォームの詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドからサポートされているプラットフォームを参照してください。AWS アカウントの設定によって、EC2-VPC または EC2-Classic のどちらを利用できるかが決まります。

注記

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

EC2-VPC

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

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

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

EC2-Classic

EC2-Classic プラットフォームは、2022 年 8 月 15 日をもって提供を終了する予定です。クラスターを EC2-Classic プラットフォームから EC2-VPC プラットフォームに移行することをお勧めします。詳細については、「EC2-Classic の DS2 クラスターを EC2-VPC にアップグレードする」と「EC2-Classic Networking は販売終了になります — 準備方法はこちら」を参照してください。

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

クラスターを起動する

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

  1. クラスターをデプロイする AWS リージョンを決定します。Amazon Redshift が利用可能な AWS リージョンの一覧については、Amazon Web Services 全般のリファレンスで「Amazon Redshift エンドポイントとクォータ」を参照してください。

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

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

  4. Amazon Redshift クラスターを起動します。Amazon Redshift コンソールを使用するか、Amazon Redshift API、AWS CLI、SDK ライブラリを使用してクラスターを作成できます。これらのオプションや関連ドキュメントへのリンクについては、「Amazon Redshift とは」を参照してください。

RA3 ノードタイプの概要

パフォーマンスの向上とストレージ容量を増やすために、DS2 ノードタイプクラスターで実行されている既存のワークロードを RA3 ノードタイプにアップグレードすることをお勧めします。RA3 ノードには、次のような利点があります。

  • ストレージコストを増加させることなく、コンピューティング能力を柔軟に拡張できます。また、コンピューティング能力を過剰にプロビジョニングすることなく、ストレージを拡張できます。

  • ホットデータには高性能の SSD を使用し、コールドデータには Amazon S3 を使用します。したがって、使いやすさ、コスト効率の高いストレージ、高いクエリパフォーマンスを提供します。

  • また、AWS Nitro System 上に構築された高帯域幅ネットワークを使用して、Amazon S3 へのデータのオフロードと取得にかかる時間をさらに短縮できます。

次の場合は、RA3 ノードタイプを選択することを検討してください。

  • コンピューティングをストレージから別にスケーリングできる柔軟性が必要な場合。

  • 合計データの一部を照会します。

  • データ量は急速に増加しているか、急速に増加すると予想されます。

  • パフォーマンスのニーズのみに基づいてクラスターをサイズ変更できる柔軟性が必要です。

RA3 ノードタイプを使用するには、AWS リージョンが RA3 をサポートしている必要があります。詳細については、「AWS リージョンでの RA3 ノードタイプの可用性」を参照してください。

重要

ra3.xlplus ノードタイプは、クラスターバージョン 1.0.21262 以降でのみ使用できます。Amazon Redshift コンソールを使用して、既存のクラスターのバージョンを表示できます。詳細については、「クラスターメンテナンスバージョンの確認」を参照してください。

RA3 ノードタイプを使用するときは、必ず新しい Amazon Redshift コンソールを使用してください。

また、メンテナンストラックを使用する Amazon Redshift オペレーションで RA3 ノードタイプを使用するには、メンテナンストラック値を、RA3 をサポートするクラスターバージョンに設定する必要があります。メンテナンストラックの詳細については、「クラスターメンテナンストラックの選択」を参照してください。

シングルノードの RA3 ノードタイプを使用する場合は、以下の点を考慮してください。

  • AQUA がサポートされます。

  • データ共有のプロデューサーとコンシューマーがサポートされます。

  • ノードタイプを変更する際には、従来のサイズ変更のみがサポートされます。伸縮自在なサイズ変更、またはスナップショットによる復元では、ノードタイプの変更はサポートされません。以下のシナリオがサポートされています。

    • 従来のサイズ変更による、1 ノードの ds2.xlarge から 1 ノードの ra3.xlplus への、およびその逆方向での変更。

    • 従来のサイズ変更による、1 ノードの ds2.xlarge からマルチノードの ra3.xlplus への、およびその逆方向での変更。

    • 従来のサイズ変更による、マルチノードの ds2.xlarge から 1 ノードの ra3.xlplus への、およびその逆方向での変更。

    • 従来のサイズ変更による、1 ノードの dc2.xlarge から 1 ノードの ra3.xlplus への、およびその逆方向での変更。

    • 従来のサイズ変更による、1 ノードの dc2.xlarge からマルチノードの ra3.xlplus への、およびその逆方向での変更。

    • 従来のサイズ変更による、マルチノードの dc2.xlarge から 1 ノードの ra3.xlplus への、およびその逆方向での変更。

Amazon Redshift マネージドストレージの操作

Amazon Redshift マネージドストレージを使用すると、すべてのデータを Amazon Redshift に保存して処理できると同時に、柔軟性が高まってコンピューティング容量とストレージ容量を個別にスケーリングできます。データの取り込みは、引き続き COPY コマンドまたは INSERT コマンドを使用して行います。Amazon Redshift パフォーマンスを最適化し、ストレージ階層間で自動データ配置を管理するために、Amazon Redshift は、データブロックの温度、データブロックの有効期間、ワークロードパターンなどの最適化を利用します。手動操作を行わなくても、Amazon Redshift は必要に応じてストレージを自動的に Amazon S3 に拡張します。

ストレージコストの詳細については、「Amazon Redshift 料金表」を参照してください。

RA3 ノードタイプの管理

コンピューティングとストレージを分離するには、RA3 ノードタイプでクラスターを作成またはアップグレードします。RA3 ノードタイプを使用するには、仮想プライベートクラウド (EC2-VPC) にクラスターを作成します。

RA3 ノードタイプの Amazon Redshift クラスターのノード数を変更するには、次のいずれかの操作を行います。

  • 伸縮自在なサイズ変更オペレーションでノードを追加または削除します。状況によっては、RA3 クラスターからノードを削除することは、伸縮自在なサイズ変更では許可されません。たとえば、2:1 ノード数のアップグレードで、ノードあたりのスライス数が 32 になるとします。詳細については、「クラスターのサイズ変更」を参照してください。 伸縮自在なサイズ変更が利用できない場合は、従来のサイズ変更を使用してください。

  • 従来のサイズ変更オペレーションでノードを追加または削除します。伸縮自在のサイズ変更では利用できない設定にサイズ変更する場合は、このオプションを選択します。伸縮性のあるサイズ変更は、従来のサイズ変更よりも高速です。詳細については、「クラスターのサイズ変更」を参照してください。

AWS リージョンでの RA3 ノードタイプの可用性

RA3 ノードタイプは、次の AWS リージョンでのみ使用できます。

  • 米国東部 (バージニア北部) リージョン (us-east-1)

  • 米国東部 (オハイオ) リージョン (us-east-2)

  • 米国西部 (北カリフォルニア) リージョン (us-west-1)

  • 米国西部 (オレゴン) リージョン (us-west-2)

  • アフリカ (ケープタウン) リージョン (af-south-1)

  • アジアパシフィック (香港) リージョン (ap-east-1)

  • アジアパシフィック (ジャカルタ) リージョン (ap-southeast-3) — ra3.4xlarge ノードタイプと ra3.16xlarge ノードタイプのみがサポートされています

  • アジアパシフィック (ムンバイ) リージョン (ap-south-1)

  • アジアパシフィック (大阪) リージョン (ap-northeast-3)

  • アジアパシフィック (ソウル) リージョン (ap-northeast-2)

  • アジアパシフィック (シンガポール) リージョン (ap-southeast-1)

  • アジアパシフィック (シドニー) リージョン (ap-southeast-2)

  • アジアパシフィック (東京) リージョン (ap-northeast-1)

  • カナダ (中部) リージョン (ca-central-1)

  • 中国 (北京) リージョン (cn-north-1)

  • 中国 (寧夏) リージョン (cn-northwest-1)

  • 欧州 (フランクフルト) リージョン (eu-central-1)

  • 欧州 (アイルランド) リージョン (eu-west-1)

  • 欧州 (ロンドン) リージョン (eu-west-2)

  • 欧州 (ミラノ) リージョン (eu-south-1)

  • 欧州 (パリ) リージョン (eu-west-3)

  • 欧州 (ストックホルム) リージョン (eu-north-1)

  • 中東 (バーレーン) リージョン (me-south-1)

  • 南米 (サンパウロ) リージョン (sa-east-1)

  • AWS GovCloud (米国東部) (us-gov-east-1)

  • AWS GovCloud (米国西部) (us-gov-west-1)

RA3 ノードタイプへのアップグレード

既存のノードタイプを RA3 にアップグレードするには、ノードタイプを変更するための次のオプションがあります。

  • スナップショットからの復元 – Amazon Redshift では、DS2 または DC2 クラスターの最新のスナップショットを使用し、それを復元して新しい RA3 クラスターを作成します。クラスターの作成が完了するとすぐに (通常は数分以内に)、RA3 ノードは本番稼働用ワークロード全体を実行する準備が整います。コンピューティングはストレージから分離されているため、ネットワーク帯域幅が広いので、ホットデータは高速でローカルキャッシュに取り込まれます。最新の DS2 または DC2 スナップショットから復元する場合、RA3 は DS2 または DC2 ワークロードのホットブロック情報を保持し、最もホットなブロックをローカルキャッシュに格納します。詳細については、「スナップショットからのクラスターの復元」を参照してください。

    アプリケーションとユーザーに対して同じエンドポイントを維持するには、新しい RA3 クラスターの名前を元の DS2 または DC2 クラスターと同じ名前に変更します。クラスターの名前を変更するには、Amazon Redshift コンソールまたは ModifyCluster API オペレーションでクラスターを変更します。詳細については、Amazon Redshift API リファレンスから「クラスターの名前変更」または「ModifyCluster API オペレーション」を参照してください。

  • 伸縮自在なサイズ変更 – サイズ変更は、伸縮自在なサイズ変更を使用してクラスターのサイズを変更します。伸縮自在なサイズ変更を使用してノードタイプを変更すると、Amazon Redshift はスナップショットを自動的に作成し、新しいクラスターを作成し、古いクラスターを削除し、新しいクラスターの名前を変更します。伸縮自在なサイズ変更オペレーションはオンデマンドで実行できるほか、任意のタイミングに実行することをスケジューリングすることもできます。既存の DS2 または DC2 ノードタイプクラスターは、伸縮自在なサイズ変更を使用して RA3 にすばやくアップグレードできます。詳細については、「伸縮自在なサイズ変更」を参照してください。

次の表に、RA3 ノードタイプにアップグレードする際の推奨事項を示します。(これらの推奨事項は、リザーブドノードにも適用されます)。

既存のノードタイプ 既存のノード数 推奨される新しいノードタイプ アップグレードアクション

ds2.xlarge

1

ra3.xlplus

1 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

2

ra3.xlplus

2 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

3

ra3.xlplus

2 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

4

ra3.xlplus

3 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

5

ra3.xlplus

4 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

6

ra3.xlplus

4 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

7

ra3.xlplus

5 ノードの ra3.xlplus クラスターを作成します1

ds2.xlarge

8

ra3.4xlarge

2 ノードの ra3.4xlarge クラスターを作成します1

ds2.xlarge

9

ra3.4xlarge

3 ノードの ra3.4xlarge クラスターを作成します1

ds2.xlarge

10

ra3.4xlarge

3 ノードの ra3.4xlarge クラスターを作成します1

ds2.xlarge

11~128

ra3.4xlarge

ds2.xlarge の 4 つのノードごとに、ra3.4xlarge のノードを 1 つ作成します1

ds2.8xlarge

2~15

ra3.4xlarge

ds2.8xlarge の 1 つのノードごとに、ra3.4xlarge のノードを 2 つ作成します1

ds2.8xlarge

16~128

ra3.16xlarge

ds2.8xlarge の 2 つのノードごとに、ra3.16xlarge のノードを 1 つ作成します1

dc2.8xlarge

2~15

ra3.4xlarge

dc2.8xlarge1 の 1 つのノードごとに、ra3.4xlarge のノードを 2 つ作成します。

dc2.8xlarge

16~128

ra3.16xlarge

dc2.8xlarge1 の 2 つのノードごとに、ra3.16xlarge のノードを 1 つ作成します。

dc2.large

1~4

なし

既存の dc2.large クラスターを保持します。

dc2.large

4~15

ra3.xlplus

dc2.large1 の 8 つのノードごとに、ra3.xlplus のノードを 3 つ作成します。

dc2.large

16~32

ra3.4xlarge

dc2.large1 の 8 つのノードごとに、ra3.4xlarge のノードを 1 つ作成します1、2

1ワークロードの要件に応じて、追加のノードが必要になる場合があります。必要なクエリパフォーマンスのコンピューティング要件に基づいて、ノードを追加または削除します。

2dc2.large ノードタイプを使用するクラスターは、32 ノードに制限されます。

一部の RA3 ノードタイプでは、ノードの最小数は 2 個です。RA3 クラスターを作成するときは、この点を考慮してください。

伸縮自在なサイズ変更またはスナップショットによる復元中での DS2 リザーブドノードから RA3 リザーブドノードへのアップグレード

DS2 リザーブドノードがある場合は、Amazon Redshift コンソールまたは AWS CLI を使用して、RA3 リザーブドノードアップグレード機能でそれらをアップグレードできます。コンソールでは、これを行う方法がいくつかあります。

1 つの方法は、伸縮自在なサイズ変更中に DS2 リザーブドノードを RA3 にアップグレードすることです。リザーブドノードがあり、RA3 ノードを選択した場合は、コンソールでリザーブドノードのアップグレードプロセスがガイドされます。技術的な観点から伸縮自在なサイズ変更は、リザーブドとそれ以外のノードの両方で、同じ働きをします。

クラスターサイズを推奨サイズ以外に変更する場合は、伸縮自在なサイズ変更の設定時に RA3 リザーブドノードアップグレードが利用できなくなり、コンソールに表示されません。(この場合でも DS2 リザーブドノードの RA3 へのアップグレードは可能ですが、サイズ変更には変更プロセスの一環として RA3 リザーブドノードアップグレードが含まれません。また、伸縮自在なサイズ変更に対するクラスターサイズ制限のため、希望するクラスターサイズが利用できない場合があることにも注意してください。例えば、4 ノードの DS2 リザーブドノードクラスターがある場合は、3 ノードの RA3 クラスターを選択できない可能性があります。この場合は、従来のサイズ変更を実行して、希望するクラスターサイズを取得することができます。

クラスターのサイズ変更後は、いくつかのステップが実行されます。まず、データが RA3 クラスターに移行されます。次に、DS2 リザーブドノードのリースが RA3 リザーブドノードのリースに変換されます。データ移行にかかる時間は、クラスターのサイズと、サイズ変更が伸縮自在の変更か従来の変更であるかに応じて異なる場合があることに注意してください。従来のサイズ変更の場合、データの移行には数時間かかるのが一般的です。

サイズ変更を開始したら、[Amazon Redshift dashboard] (Amazon Redshift ダッシュボード) で利用できる [Events] (イベント) のメッセージを確認して進行状況を追跡します。サイズ変更に関するイベント通知と、リザーブドノードのアップグレードに関するイベント通知があります。イベントの操作については、「Amazon Redshift のイベント」を参照してください。サイズ変更後、アクティブなサイズ変更済みのクラスターがAWS Management Consoleに表示されます。変換された RA3 リザーブドノードのリースを表示することもできます。コンソールには、ソースの DS2 リザーブドノードが約 1 日間引き続き表示される場合があります。これらの料金は請求されません。RA3 クラスターがアクティブで、変換されたリザーブドノードのリースが生成されていることを確認するまでは、ソースの DS2 リザーブドノードを削除しないでください。

RA3 リザーブドノードのアップグレード機能を使用するためのもう 1 つの方法は、スナップショットからの復元です。RA3 ノードタイプを選択し、DS2 リザーブドノードがあるという場合は、その時点で RA3 リザーブドノードアップグレード機能を選択できます。スナップショットから復元すると、その結果は RA3 リザーブドノードクラスターに格納されます。前述のように、推奨サイズ以外のクラスタサイズを選択した場合、コンソールからは RA3 リザーブドノードのアップグレードを選択できなくなります。

クラスターのサイズ変更およびノードのアップグレードの詳細については、「クラスターのサイズ変更の詳細」を参照してください。ここでは、プロセスに関する詳細な説明と、サイズ変更時にクラスターとデータで発生する点についての回答を参照することができます。伸縮自在なサイズ変更プロセスの各ステップについては、「伸縮自在なサイズ変更」を参照してください。スナップショットから復元する方法の詳細については、「スナップショットからのクラスターの復元」を参照してください。

リザーブドノードの RA3 へのアップグレード (例えば DC2 リザーブドノードの RA3 へのアップグレード) についてさらに質問がある場合は、AWS サポートにお問い合わせください。オンデマンドノードとリザーブドノードの料金については、「Amazon Redshift 料金表」を参照してください。

既に DS2 リザーブドノードを購入済みの場合は、DS2 リザーブドノードを RA3 リザーブドノードに変換する方法について、AWS にお問い合わせください。詳細について AWS に問い合わせるには、「Amazon Redshift RA3 instances with managed storage」を参照してください。

DC1 ノードタイプから DC2 ノードタイプへのアップグレード

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

DC2 ノードタイプを使用するクラスターは、仮想プライベートクラウド (EC2-VPC) で起動する必要があります。

DC1 クラスターが VPC にない場合:

  1. DC1 クラスターのスナップショットを作成します。詳細については、「Amazon Redshift スナップショット」を参照してください。

  2. VPC を作成するか、アカウント内の既存の VPC を選択します。詳細については、「VPC でクラスターを管理する」を参照してください。

  3. VPC の新しい DC2 クラスターにスナップショットを復元します。詳細については、「スナップショットからのクラスターの復元」を参照してください。

DC1 クラスターがすでに VPC にある場合は、以下のいずれかの方法を選択します。

  • このオペレーションの一部として、DC1 クラスターのサイズを変更し、ノードタイプを DC2 に変更します。クラスターは、サイズ変更オペレーション中、使用できません。詳細については、「Amazon Redshift でのクラスターのサイズ変更」を参照してください。

  • DC1 クラスターのスナップショットを作成し、VPC の DC2 クラスターにスナップショットを復元します。詳細については、「スナップショットからのクラスターの復元」を参照してください。

ノードタイプを DC1 から DC2 にアップグレードするときは、以下の点を考慮してください。

  • 100% 満杯の DC1 クラスターは、同等数の DC2 ノードにアップグレードできない場合があります。より多くのディスクスペースが必要な場合は、以下を試すことができます。

    • 使用可能なディスクスペースがより多い設定にサイズを変更します。

    • テーブルを切り詰めるか行を削除して、不要なデータをクリーンアップします。

  • DC2 クラスターは EC2-Classic ネットワーキングをサポートしていません。DC1 クラスターが VPC で実行されていない場合は、DC2 の移行用にクラスターを作成します。詳細については、「VPC でクラスターを管理する」を参照してください。

  • クラスターのサイズを変更すると、オペレーション中は、クラスターが読み取り専用モードに設定される場合があります。詳細については、「Amazon Redshift でのクラスターのサイズ変更」を参照してください。

  • DC1 リザーブドノードを購入した場合、残りの期間に、DC1 リザーブドノードを DC2 ノードにアップグレードできます。AWS CLI で予約を変更する方法の詳細については、「AWS CLI を使ったリザーブドノードのアップグレード」を参照してください。

  • 復元を使用して dc1.large から dc2.large にアップグレードし、ノード数を変更する場合、クラスターバージョン 1.0.10013 以降ではスナップショットが作成されている必要があります。

  • 復元を使用して dc1.8xlarge から dc2.8xlarge にアップグレードする場合、クラスターバージョン 1.0.10013 以降ではスナップショットが作成されている必要があります。

  • 伸縮自在なサイズ変更を使用して DC1 から DC2 にアップグレードし、ノード数を変更する場合、クラスターはクラスターバージョン 1.0.10013 以降である必要があります。

  • アップグレードする dc1.8xlarge クラスターのスナップショットが、バージョン 1.0.10013 より前のクラスターからのものである場合は、最初に dc1.8xlarge クラスターから、ノード数が同じ新しい dc1.8xlarge クラスターにスナップショットを復元します。次に、次のいずれかの方法を使用して、新しい dc1.8xlarge をアップグレードします。

    • 新しく復元されたクラスターからのスナップショットを使用して、dc2.8xlarge にアップグレードします。

    • 伸縮自在なサイズ変更を使用して、新しく復元されたクラスターを dc2.8xlarge にアップグレードします。

EC2-Classic の DS2 クラスターを EC2-VPC にアップグレードする

Amazon Redshift クラスターは、選択した Amazon Redshift ノードタイプとサイズに設定された Amazon EC2 インスタンスで実行されます。パフォーマンスとセキュリティを向上させるため、EC2-VPC を使用して VPC で起動するように EC2-Classic でクラスターをアップグレードすることをお勧めします。

EC2-Classic の DS2 クラスターを EC2-VPC にアップグレードするには

  1. DS2 クラスターのスナップショットを作成します。詳細については、「Amazon Redshift スナップショット」を参照してください。

  2. VPC を作成するか、アカウント内の既存の VPC を選択します。詳細については、「VPC でクラスターを管理する」を参照してください。

  3. VPC の新しい DS2 クラスターにスナップショットを復元します。詳細については、「スナップショットからのクラスターの復元」を参照してください。

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

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

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

Amazon Redshift クラスターをプロビジョンできる、サポート対象のAWS リージョンの一覧については、Amazon Web Services 全般のリファレンスで「Amazon Redshift エンドポイントとクォータ」を参照してください。

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

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

メンテナンスウィンドウ

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

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

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

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

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

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

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

  • アフリカ (ケープタウン) リージョン: 20:00~04:00 UTC

  • アジアパシフィック (香港) リージョン: 13:00~21:00 UTC

  • アジアパシフィック (ジャカルタ) リージョン: 15:00~23:00 UTC

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

  • アジアパシフィック (大阪) リージョン: 13:00~21:00 UTC

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

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

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

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

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

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

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

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

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

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

  • 欧州 (ミラノ) リージョン: 21:00~05:00 UTC

  • 欧州 (パリ) リージョン: 23:00~07:00 UTC

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

  • 中東 (バーレーン) リージョン: 13:00~21:00 UTC

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

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

クラスターをプログラムで、または Amazon Redshift コンソールを使用して変更すると、スケジュールされたメンテナンスウィンドウを変更できます。ウィンドウは 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 以降の新しいリリースが公開されるまでは更新されません。

プレビュートラック

プレビュートラックは選択できない場合があります。プレビュートラックを選択する際は、トラック名も選択する必要があります。プレビュートラックと関連リソースは一時的なものであり、機能的な制限があり、他のトラックで利用できる現行の Amazon Redshift 機能の一部が含まれていない場合があります。プレビュートラックを使用する場合:

  • プレビュートラックを操作する場合は、新しい Amazon Redshift コンソールを使用します。たとえば、プレビュー版の機能で使用するクラスターを作成する場合などです。

  • クラスターを 1 つのプレビューから別のプレビューに切り替えることはできません。

  • クラスターを、現行または末尾トラックからプレビューに切り替えることはできません。

  • 異なるプレビュートラックから作成されたスナップショットから復元することはできません。

  • プレビュートラックは、新しいクラスターを作成する際、またはスナップショットを復元する際にのみ使用できます。

  • 異なるプレビュートラックから作成されたスナップショットから復元したり、あるいはプレビュートラックのクラスターバージョンより後のクラスターメンテナンスバージョンを使って復元したりすることはできません。たとえば、クラスターをプレビュートラックに復元する際、プレビュートラックのバージョンよりも古いクラスターメンテナンスバージョンから作成したスナップショットのみを使用できます。

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

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

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

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

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

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

クラスターの Amazon Redshift コンソールリストの [Release status] (リリースステータス) 列は、クラスターの 1 つがアップグレードに使用できるかどうかを示します。

クラスターバージョンのロールバック

クラスターが最新のクラスターバージョンになっている場合、以前のバージョンまでロールバックすることを選択できます。

各クラスターバージョンに含まれる特徴や改善点の詳細については、「クラスターバージョンの履歴」を参照してください。

以前のクラスターバージョンにロールバックするには

  1. AWS Management Console にサインインして、(https://console.aws.amazon.com/redshift/)でAmazon Redshift コンソール を開きます。

  2. ナビゲーションメニューで [Clusters] (クラスター) を選択します。

  3. ロールバックするクラスターを選択します。

  4. [アクション] で、[Roll back cluster version (クラスターバージョンのロールバック)] を選択します。[Roll back cluster version (クラスターバージョンのロールバック)] ページが表示されます。

  5. ロールバックできるバージョンがある場合は、ページの手順に従います。

  6. [Roll back now (今すぐロールバック)] を選択します。

クラスターメンテナンスバージョンの確認

Amazon Redshift コンソールを使用して、Amazon Redshift エンジンとデータベースのバージョンを確認できます。

クラスターのバージョンを確認するには

  1. AWS Management Console にサインインして、(https://console.aws.amazon.com/redshift/)でAmazon Redshift コンソール を開きます。

  2. ナビゲーションメニューで [Clusters] (クラスター) を選択し、リストからクラスター名を選択してその詳細を開きます。クラスターの詳細が表示されます。これには、[Cluster performance] (クラスターのパフォーマンス)、[Query monitoring] (クエリのモニタリング)、[Databases] (データベース)、[Datashares] (データ共有)、[Schedules] (スケジュール)、[Maintenance] (メンテナンス)、および [Properties] (プロパティ) タブなどがあります。

  3. [Maintenance] (メンテナンス) タブを選択し、詳細を確認します。

  4. [Maintenance (メンテナンス)] セクションで、[Current cluster version (現行のクラスターバージョン)] を見つけます。

注記

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

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

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

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

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

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

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

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

注記

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

クラスターステータス

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

ステータス 説明
available クラスターは実行されていて、利用可能です。
available, prep-for-resize クラスターは伸縮自在なサイズ変更の準備をしています。クラスターは稼働しており、読み取りクエリや書き込みクエリに使用できますが、スナップショットの作成などのクラスターオペレーションは使用できません。
available, resize-cleanup 伸縮自在なサイズ変更オペレーションは、新しいクラスターのノードへのデータ転送を完了します。クラスターは稼働しており、読み取りクエリや書き込みクエリに使用できますが、スナップショットの作成などのクラスターオペレーションは使用できません。
cancelling-resize サイズ変更オペレーションはキャンセルされています。
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 が存在すること、そして設定が正しいことを確認してください。詳細については、「VPC でクラスターを管理する」を参照してください。
incompatible-parameters 関連付けられたパラメータグループの 1 つ以上のパラメータ値に問題があり、パラメータ値の適用ができません。パラメータグループを変更し、無効な値を更新してください。詳細については、「Amazon Redshift パラメータグループを作成します。」を参照してください。
incompatible-restore スナップショットからクラスターを復元時に問題が発生しました。別のスナップショットでクラスターの復元を再度お試しください。詳細については、「Amazon Redshift スナップショット」を参照してください。
modifying Amazon Redshift は、クラスターへの変更を加えています。詳細については、「クラスターの変更」を参照してください。
paused クラスターが一時停止しています。詳細については、「クラスターの一時停止と再開」を参照してください。
rebooting Amazon Redshift がクラスターを再起動しています。詳細については、「クラスターの再起動」を参照してください。
renaming Amazon Redshift は、クラスターに新しい名前を適用しています。詳細については、「クラスターの名前変更」を参照してください。
resizing Amazon Redshift がクラスターのサイズを変更しています。詳細については、「クラスターのサイズ変更」を参照してください。
rotating-keys Amazon Redshift は、クラスターの暗号化キーを更新しています。詳細については、「Amazon Redshift における暗号化キーのローテーション」を参照してください。
storage-full クラスターがストレージ容量限に達しました。ノードを追加するためにクラスターのサイズ変更をするか、または別のノードサイズを選択してください。詳細については、「クラスターのサイズ変更」を参照してください。
updating-hsm Amazon Redshift は HSM 設定を更新しています。