[RDS] Aurora インスタンスのサブネットを移動させてみた

[RDS] Aurora インスタンスのサブネットを移動させてみた

Clock Icon2017.02.26

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

こんにちは、菊池です。

Amazon RDSで一度作成したインスタンスのサブネット配置を変更する場合、スナップショットを作成して、別のインスタンスとしてリストアするのが一般的な方法です。そのため、スナップショット作成/リストアの間に更新が行われないように静止点の確保が必要であり、サービスの停止時間がそれなりに発生してしまいます。

しかし、複数のリードレプリカが作成可能で、リードレプリカをマスタに昇格可能である Amazon Aurora であれば、わずかな停止時間でサブネットの移動が可能と考え、試してみました。

やりたいこと

以下のように、Multi-AZ構成で起動している Aurora のインスタンスを、同じVPC内の別のサブネットへ移動させることを考えます。ケースとしては、当初、ELB/EC2/RDSを同じサブネットで構築してサービスしていた状態から、Public/Privateに分けた構成に整理したいというのを想定しています。

aurora_subnet_01

手順

以下のような手順で実施しました。

  1. Subnet Group を移行先のサブネットが含まれるように変更
  2. リードレプリカを移行先のサブネットに作成
  3. 移行先サブネットにマスタをフェイルオーバー
  4. 元のサブネットのリードレプリカを削除

1. Subnet Groupの変更

次の手順2.で作成するリードレプリカが移行先のサブネットに起動するよう、Subnet Groupを変更します。

aurora_subnet_02

現状のクラスタに割り当てられているSubnet Groupを選択して編集します。

aurora_subnet_06

元のサブネットを削除し、移行先のサブネットを追加します。

aurora_subnet_07

現状起動しているサブネットを削除しても、起動中のインスタンスに影響はありませんでした。

2. リードレプリカの作成

リードレプリカを2台追加します。

aurora_subnet_03

手順1. でSubnet Groupを変更しておくことで、移行先のサブネットに起動してくれます。

aurora_subnet_08

起動が完了したら、期待したサブネットに起動しているか確認しましょう。

]$ nslookup test-aurora-a-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:		10.0.0.2
Address:       	10.0.0.2#53

Non-authoritative answer:
Name:  	test-aurora-a-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 10.0.2.118

$ nslookup test-aurora-c-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:		10.0.0.2
Address:       	10.0.0.2#53

Non-authoritative answer:
Name:  	test-aurora-c-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 10.0.3.74

10.0.2.0/24と10.0.3.0/24のサブネットに起動しています。

3. フェイルオーバーを実行

フェイルオーバーを実行し、新たに作成したリードレプリカをマスタに昇格させます。

aurora_subnet_04

フェイルオーバーでは、どのリードレプリカをマスタにするかを指定することはできません。期待通りに新しいサブネットのインスタンスがマスタに昇格するよう、あらかじめフェイルオーバー優先順位を変更しておきましょう。

優先順位を確認/設定したら、フェイルオーバーを実行します。実行前のクラスタエンドポイントを確認しておきます。

$ nslookup test-aurora-1.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:		10.0.0.2
Address:       	10.0.0.2#53

Non-authoritative answer:
test-aurora-1.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com    	canonical name = test-aurora-a-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com.
Name:  	test-aurora-a-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 10.0.0.109

マスタは10.0.0.0/24のサブネットにいることがわかります。

フェイルオーバーを実行します。フェイルオーバー中は接続断が発生することにご注意ください。

aurora_subnet_09

 

実行後、再度クラスタエンドポイントを確認します。

$ nslookup test-aurora-1.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:		10.0.0.2
Address:       	10.0.0.2#53

Non-authoritative answer:
test-aurora-1.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com    	canonical name = test-aurora-a-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com.
Name:  	test-aurora-a-2.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 10.0.2.118

マスタが10.0.2.0/24のサブネットに移動しました

4. 元のサブネットのリードレプリカを削除

最後に、元のサブネットに残ったリードレプリカを削除します。

aurora_subnet_05

リードレプリカをインスタンスエンドポイントで指定して参照していた場合には、先に接続先の変更を実施する必要がありますのでご注意ください。

aurora_subnet_10

削除が終われば完了です。

さいごに

いかがでしたでしょうか。

Auroraを使うことで、他のDBエンジンではできないサブネットの移動も、最小限の停止時間で実現可能でした。複数のリードレプリカやリードレプリカをマスタに昇格可能であるというAuroraの特徴は、性能やスケーラビリティだけではなく、運用面でも優れた特性だと実感しました。

 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.