Amazon Redshift クラスター - Amazon Redshift

Amazon Redshift クラスター

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

Amazon Redshift クラスターの概要

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

注記

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

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

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

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

クラスターを起動するときに、オプションの 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.4xlarge 12 96 4 64 TB1 2–322 4096 TB2,3
ra3.16xlarge 48 384 16 64 TB1 2–128 8192 TB3

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

2 ra3.4xlarge ノードタイプは、32 個のノードで作成できますが、伸縮自在なサイズ変更で最大 64 個のノードに変更できます。

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

高密度ストレージノードタイプ
ノードサイズ vCPU RAM (GiB) ノードごとのデフォルトスライス 1 ノードあたりのストレージ ノード範囲 合計容量
ds2.xlarge 4 13 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 console および Amazon CloudWatch メトリクスを使用して、クエリのパフォーマンスを監視できます。クラスターの価格とパフォーマンスのバランスを維持するために、必要に応じてノードを追加または削除することもできます。追加のノードをリクエストしたときは、Amazon Redshift でデプロイメント、ロードバランシング、およびデータメンテナンスの詳細がすべて管理されます。クラスターパフォーマンスの詳細については、「Amazon Redshift クラスターのパフォーマンスをモニタリングする」を参照してください。

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

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

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

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

Amazon Redshift クラスターは、選択した Amazon Redshift のノードタイプとサイズ用に構成された Amazon Elastic Compute Cloud (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 アカウントに論理的に分離された 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 の製品詳細ページを参照してください。

EC2-Classic

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

クラスターを起動する

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

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

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

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

  4. Amazon Redshift クラスターを起動します。クラスターを作成するには、Amazon Redshift console を使用するか、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.4xlarge ノードタイプは、クラスターバージョン 1.0.14104以降でのみ使用できます。Amazon Redshift コンソールを使用して、既存のクラスターのバージョンを表示できます。詳細については、「クラスターメンテナンスバージョンの確認」を参照してください。

RA3 ノードタイプを使用するときは、必ず新しい Amazon Redshift コンソールを使用してください。元のコンソールでは、すべての RA3 オペレーションがサポートされているわけではありません。

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

Amazon Redshift マネージドストレージの使用

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

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

RA3 ノードタイプの管理

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

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

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

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

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

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

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

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

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

次の表に、RA3 ノードタイプにアップグレードする際の推奨事項を示します。

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

ds2.xlarge

1–7

なし

既存の ds2.xlarge クラスターを保持するか、dc2.large クラスターにアップグレードします。ローカルディスクに十分なデータがない場合、dc2.large にアップグレードすると、パフォーマンスが向上し、コストが削減されます。

ds2.xlarge

8–128

ra3.4xlarge

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

ds2.8xlarge

2–15

ra3.4xlarge

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

ds2.8xlarge

16–128

ra3.16xlarge

ds2.8xlarge の 2 つのノードごとに、ra3.16xlarge のノードを 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–15

なし

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

dc2.large

16–128

ra3.4xlarge

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

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

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

すでに DS2 リザーブドノードを購入済みの場合は、DS2 リザーブドノードを RA3 リザーブドノードに変換する方法について、AWS にお問い合わせください。詳細については、AWS に問い合わせるには、「マネージドストレージを使用する Amazon Redshift RA3 インスタンス」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DC2 ノードタイプを使用するクラスターは、仮想プライベートクラウド (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.8xlarge クラスターに直接復元することはできません。

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

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

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

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

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

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

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

    • 行を削除し、テーブルのバキューム処理を行います。

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

  • 移行中はクラスターを使用できない場合があります。クラスターのサイズを変更すると、オペレーション中は、クラスターが読み取り専用モードに設定される場合があります。Amazon Redshift コンソールのクラスターリストから [cancel resize (サイズ変更をキャンセル)] を選択して、サイズ変更オペレーションが完了する前にキャンセルできます。詳細については、「Amazon Redshift でのクラスターのサイズ変更」を参照してください。

詳細については、「Amazon Redshift スナップショット」を参照してください。

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

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

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

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

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

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

メンテナンスウィンドウ

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

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

次のリストは、デフォルトでメンテナンスウィンドウが割り当てられる各 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

  • アジアパシフィック (ムンバイ) リージョン: 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 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 以降の新しいリリースが公開されるまでは更新されません。

プレビュートラック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

Amazon Redshift 用の新しいコンソールが利用可能です。使用しているコンソールに基づき、[新しいコンソール] または [元のコンソール] の手順を選択します。新しいコンソールの手順はデフォルトで開いています。

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

  1. AWS マネジメントコンソールにサインインし、Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで [CLUSTERS] を選択します。

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

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

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

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

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

  1. AWS マネジメントコンソールにサインインし、Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションペインで [Clusters] を選択します。

  3. ロールバックするクラスターを選択し、[ステータス] タブを選択します。

    ロールバック先のバージョンが利用できる場合、そのバージョンが詳細ページの [ステータス] タブに表示されます。

    
                            ロールバックバージョンの詳細画面
  4. [リリースするロールバック (リリース番号)] を選択します。

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

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

注記

Amazon Redshift 用の新しいコンソールが利用可能です。使用しているコンソールに基づき、[新しいコンソール] または [元のコンソール] の手順を選択します。新しいコンソールの手順はデフォルトで開いています。

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

  1. AWS マネジメントコンソールにサインインし、Amazon Redshift コンソール (https://console.aws.amazon.com/redshift/) を開きます。

  2. ナビゲーションメニューで [CLUSTERS] を選択し、リストからクラスター名を選択してその詳細を開きます。[Query monitoring (クエリのモニタリング)]、[Cluster performance (クラスターのパフォーマンス)]、[Maintenance and monitoring (メンテナンスとモニタリング)]、[Backup (バックアップ)]、および [Properties (プロパティ)] タブ、[Schedule (スケジュール)] タブなど、クラスターの詳細が表示されます。

  3. [Maintenance and monitoring (メンテナンスとモニタリング)] タブを選択し、詳細を確認します。

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

注記

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

コンソールの [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 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 コンソールからアラームを削除できます。

クラスターステータス

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

ステータス 説明
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 設定を更新しています。