Amazon Redshift の 可用性と耐久性について

2015.12.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

先日お客様よりRedshiftの構成や可用性、耐久性、データの復元などのご質問をいただきましたので 想定される障害についてどのような復旧対応が行われるのかまとめました。

引用はAmazon Redshift のよくある質問の 可用性と耐久性 から引用しています。

ドライブ障害

Q: 1 つのノードのドライブに障害が発生した場合、データウェアハウスクラスターの可用性とデータ耐久性はどうなりますか?

Amazon Redshift データウェアハウスクラスターはドライブに障害が発生した場合でも継続して利用できますが、特定のクエリに対するパフォーマンスがわずかに低下します。ドライブに障害が発生すると、ノード内の他のドライブに格納されている障害ドライブのデータの複製が、透過的に使用されます。さらに、データを正常なドライブに移動させるか、移動できない場合はノードの交換が行われます。 単一ノードのクラスターは、データのレプリケーションをサポートしません。ドライブに障害が発生した場合、S3 のスナップショットからクラスターを復元する必要があります。実稼働には少なくとも 2 つのノードを使用することをお勧めします。

ノード内でドライブは内部的に冗長されていますので基本的には自動的に復旧しますがパフォーマンスが低下する場合があります。

シングルノード構成

他のドライブとデータが冗長化されている場合、単一ドライブでの障害は自動復旧されサービス利用可能です。 自動復旧ができない場合スナップショットからの復旧が必要です。

マルチノード構成

ノード内でドライブが冗長されているので1つのドライブに障害が発生したとしても、 冗長化による別のドライブの複製されたデータにより入出力が行われ、処理が続行されますのでサービス利用可能です。

他のドライブにデータの移動ができない場合はノード交換が自動的に行われデータは別のノードから復元されますが ノード交換が終わるまではサービス利用不可となります。

ノード障害

Q: 個々のノードに障害が発生した場合、データウェアハウスクラスターの可用性とデータ耐久性はどうなりますか?

Amazon Redshift はデータウェアハウスクラスター内の障害ノードを自動的に検知し、障害ノードの交換を行います。データウェアハウスクラスターは代替ノードがプロビジョニングされてデータベースに追加されるまで、クエリと更新を行うことはできません。Amazon Redshift は代替ノードを即座に利用可能にし、まず最も高い頻度でアクセスされるデータを S3 から取得します。こうすることで、可能な限り速やかにクエリの実行を再開できるようになります。 単一ノードのクラスターは、データのレプリケーションをサポートしません。ドライブに障害が発生した場合、S3 のスナップショットからクラスターを復元する必要があります。実稼働には少なくとも 2 つのノードを使用することをお勧めします。

Redshiftは障害ノードを自動的に検知し、障害ノードの交換を行います。 ノードの交換が完了するまではサービス利用不可となります。

シングルノード構成

シングルノードの場合データのレプリケーションは行われないのでスナップショットからの復旧が必要となります。

マルチノード構成

ノード間でデータが冗長化されているのでノード障害の際は自動的にノードの入れ替えが行われます。 ノード交換時には、クライアントの接続が全て切断され、実行中のクエリはロールバックが発生します。 またプロビジョニングが完了するまではサービス利用不可となります。

ノード交換後、別のノードに冗長化されているデータが入れ替え後のノードに転送されますが その間パフォーマンスがわずかに低下します。 復元が完了していないデータが必要とされた場合、即座にデータの取得がおこなわれますが応答の低下が発生いたします。

AZ障害

Q: データウェアハウスクラスターのアベイラビリティーゾーン(AZ)が機能停止した場合に、データウェアハウスクラスターの可用性とデータ耐久性はどうなりますか?

Amazon Redshift データウェアハウスクラスターのアベイラビリティーゾーンが使用不能になった場合は、アベイラビリティーゾーンの電力供給とネットワークアクセスが回復するまではクラスターを利用できません。データウェアハウスクラスターのデータは維持されているので、アベイラビリティーゾーンが再び利用可能になり次第、Amazon Redshift データウェアハウスの使用を開始できます。さらに、同一リージョン内の新規アベイラビリティーゾーンに対して既存のスナップショットを復元することもできます。最も高い頻度でアクセスされるデータが最初に復元されるため、可能な限り速やかにクエリの実行を再開できます。

アベイラビリティゾーン障害はシングルノード構成、マルチノード構成で対応は同じですが 障害の度合いや復旧までの許容時間により復旧までのプロセスが変わります。

シングルノード構成、マルチノード構成

  • 復旧まで待つ場合

ネットワーク障害等により AZ へ接続できない状態ではアベイラビリティーゾーンの障害復旧まで利用不可となりますがデータは維持されます。

  • 復旧まで待てない場合

アベイラビリティーゾーンの障害復旧まで待てない場合はスナップショットから復旧する必要がありますがデータはスナップショットのデータとなります。

注意点

スナップショットからのリストアの際には「Cluster Identifier」を設定しますが、 ほかのクラスタと重複することはできません。

アベイラビリティゾーンの障害の際に既存のクラスタが削除できない場合は別名で設定が必要で、 エンドポイント名が変更されることになりクライアントからの接続には注意が必要です。

サービス影響の判断について

Redshiftマネジメントコンソールにて「Cluster Status」と「DB Health」を確認します。

Redshift_·_AWS_Console

Redshift_·_AWS_Console_1

こちらの値が以下の値の場合、サービス可能な状態と判断が可能です。

Cluster Status : available Database HealthHealth : healthy

Cluster Status のステータスの意味につきましては下記ドキュメントをご覧ください。

クラスターステータス | Amazon Redshift 管理ガイド

まとめ

Redshiftの障害における復旧内容についてまとめました。 下記参考URLで確認できますがブログも参考にしていただければ幸いです。

参考リンク