Amazon Redshift でプロビジョニングされたクラスターを使用する際の考慮事項

クラスターの作成後に、機能を使用できるリージョン、メンテナンスタスク、ノードタイプ、使用制限についての情報をこのセクションで確認できます。

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

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 リージョンの時間を示します。

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

クラスターをプログラムで、または Amazon Redshift コンソールを使用して変更すると、スケジュールされたメンテナンスウィンドウを変更できます。[メンテナンス] タブではメンテナンスウィンドウが表示され、メンテナンス期間を確認したり、クラスターのメンテナンス実施日時を設定したりできます。

クラスターはメンテナンスウィンドウ外で再起動することがあります。これが発生する理由はいくつかあります。もう 1 つの一般的な理由は、クラスターに問題が検出され、正常な状態に戻すためのメンテナンスオペレーションが行われていることです。詳細については、「Amazon Redshift クラスターがメンテナンスウィンドウ外で再起動したのはなぜですか?」という記事を参照してください。この問題が発生する理由に関する詳細情報が記載されています。

メンテナンスの遅延

クラスターのメンテナンスウィンドウを変更する場合は、メンテナンスを最長 45 日まで延期できます。例えば、クラスターのメンテナンスウィンドウが水曜日の 8:30～9:00 (UTC) に設定されていて、その時間にクラスターにアクセスする必要がある場合、メンテナンスを延期できます。

メンテナンスを延期しても、Amazon Redshift は引き続きハードウェアの更新やその他の必須のセキュリティ更新をクラスターに適用します。更新中は、クラスターを使用できません。

次回のメンテナンスウィンドウ中にハードウェアの更新またはその他の必須のセキュリティ更新が予定されている場合、Amazon Redshift は [保留中] カテゴリで事前に通知を送信します。保留中のイベント通知の詳細については、「Amazon Redshift プロビジョニングされたクラスターのイベント通知」を参照してください。

Amazon Simple Notification Service (Amazon SNS) からイベント通知を受け取ることもできます。Amazon SNS イベント通知のサブスクライブの詳細については、「Amazon Redshift クラスターイベント通知のサブスクリプション」を参照してください。

クラスターのメンテナンスを延期すると、延期した後の次回のメンテナンスウィンドウは延期できません。

クラスターのメンテナンスの詳細については、以下のドキュメントを参照してください。

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

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

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

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

プレビュートラック

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

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

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

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

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

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

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

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

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

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

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

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

Amazon Redshift での使用制限の管理

制限を定義して、一部の Amazon Redshift 機能の使用状況と関連するコストをモニタリングおよび制御できます。日単位、週単位、月単位の使用制限を作成し、それらの制限に達した場合に Amazon Redshift が自動的に実行するアクションを定義できます。アクションには、定義された制限を超える使用状況を記録するために、システムテーブルにイベントを記録するなどの処理が含まれます。その他の考えられるアクションとしては、Amazon SNS と Amazon CloudWatch でアラートを発生させて管理者に通知したり、さらなる使用を無効にしてコストを管理したりするなどがあります。

各クラスターの使用制限を定義できます。クラスターの作成後、次の機能の使用制限を定義できます。

使用制限は、Amazon Redshift Spectrum および Amazon Redshift の同時実行スケーリングが利用できる AWS リージョンで、リリースバージョン 1.0.14677 以降で利用可能です。

Redshift Spectrum の制限は、1 TB 単位でスキャンされるデータの合計量のしきい値を指定します。同時実行スケーリング制限は、同時実行スケーリングで使用される合計時間のしきい値を 1 分単位で指定します。クロスリージョンデータ共有の制限は、スキャンされるデータの合計量のしきい値を 1 TB 単位で指定します。

制限は、日単位、週単位、または月単位の期間で指定できます (UTC を使用して期間の開始と終了を決定します)。期間の途中で制限を作成した場合、その時点から期間の終了まで制限が測定されます。たとえば、3 月 15 日に月単位の制限を作成した場合、最初の月単位の期間は 3 月 15 日から 3 月 31 日に測定されます。

各機能に対して複数の使用制限を定義できます。制限ごとに異なるアクションを設定できます。考えられるアクションは次のとおりです。

使用制限は、使用制限の定義自体またはクラスターが削除されるまで保持されます。

新しい Amazon Redshift コンソール、AWS CLI、または Amazon Redshift API オペレーションを使用して、使用制限を定義および管理できます。Amazon Redshift コンソールで制限を定義するには、クラスターに移動し、[Actions (アクション)] の [Configure usage limit (使用制限の設定)] を選択します。クラスターに対して定義済みの使用制限を表示するには、クラスターに移動し、[メンテナンス] タブの [使用制限] セクションを選択します。クラスターで利用可能な使用量および消費済みの使用量を表示するには、クラスターに移動します。[クラスターのパフォーマンス] タブを選択し、機能に消費された使用量のグラフを表示します。

次の Amazon Redshift CLI オペレーションを使用して、使用制限を管理できます。詳細については、AWS CLI コマンドリファレンスを参照してください。

次の Amazon Redshift API オペレーションを使用して、使用制限を管理できます。詳細については、「Amazon Redshift API リファレンス」を参照してください。

Amazon Redshift コンソールを使用して使用制限を作成およびモニタリングする方法については、次のビデオをご覧ください。

RA3 ノードがコンピューティングとストレージを分離する方法を理解する

これらのセクションでは、RA3 ノードタイプで使用できるタスクについて詳しく説明し、一連のユースケースへの適用可能性を示し、以前に利用可能だったノードタイプと比較した場合の利点について詳しく説明します。

RA3 ノードの利点と可用性

RA3 ノードには、次のような利点があります。

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

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

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

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 クラスターのノード数を変更するには、次のいずれかの操作を行います。

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

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

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

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

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

この表では、開始時のクラスターノードの種類とサイズを基に推奨事項を示しますが、推奨事項はワークロードのコンピューティング要件によって異なります。要件をより正確に見積もるには、Test Drive を使用して潜在的な構成を実行する概念実証 (POC) の実施を検討してください。Redshift Serverless の代わりに POC データウェアハウス用のクラスターをプロビジョニングします。概念実証の実施に関する詳細については、「Amazon Redshift データベース開発者ガイド」の「Amazon Redshift の概念実証 (POC) を実施する」を参照してください。

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

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

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

RA3 ノードがサポートするネットワーク機能

RA3 ノードは、他のノードでは利用できないネットワーク機能のコレクションをサポートしています。このセクションでは、各機能の簡単な説明とその他のドキュメントへのリンクを示します。