Amazon AuroraのDB インスタンスクラス変更方法まとめ

CS課佐竹です。
最近暑いので、色が青いRDSでも弄って涼を取ろうと思い、RDSについて記載します。

はじめに
Amazon AuroraのDB インスタンスクラス変更方法
まとめ

はじめに

「Amazon Aurora の DB Instance classを変更したい」そう思った時、どのようなシナリオ・手順が考えられるでしょうか。ここでは一般的なModifyで実施する方法から、可能な限り停止時間を短くするような方法、そしてAurora本体のアップグレードにも対応するような方法と、合わせて5つの方法をご紹介したいと思います。

Modifyパターン
Failoverパターン
Aurora複製パターン
Replicationパターン
Cross-region Read Replicaパターン

ところで、皆さんRDSのインスタンスタイプはDB インスタンスクラスと呼ばれていることはご存じでしょうか。EC2ではインスタンスタイプと言われているものが、RDSになるとDB インスタンスクラスになります。しかし、公式ページでも「インスタンスタイプ」と表記されていたりして、よくわかりません。よくわかりませんが、このブログでは一貫して「DB インスタンスクラス」と記載します。ただ、勢いでインスタンスタイプと書いてしまう場合もあるかもしれませんが、見逃してください。

Amazon AuroraのDB インスタンスクラス変更方法

最初に、説明の元ネタとなります構成図をご紹介します。以下の図のように、EC2とRDS(Aurora)が1台ずつで構築されている環境があるとします。EC2とAurora間にはコネクションが存在しています。

今回、この「r4.large」のAuroraを「r5.large」に変更したいとします。ではパターン別に見てみましょう。

1: Modifyパターン

最初にご紹介するのは、最も一般的な変更方法です。Amazon Auroraの機能である「Modify」コマンドを利用してDB インスタンスクラスを変更します。

Amazon Relational Database Service (RDS) » Aurora のユーザーガイド » Amazon Aurora DB クラスターの管理 » Amazon Aurora DB クラスターの変更 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html

ModifyのコマンドはマネジメントコンソールもしくはAPIで実行するのみです。Modifyコマンドを実行し、DB インスタンスクラスを変更するとAuroraはシャットダウンされ、DB インスタンスクラスが変更された後に起動します。図で表すと、以下のように「一時的にコネクションは切断」されます。

Modify が問題なく完了すると、Auroraは Available 状態に戻り再度利用可能となります。

この変更方法ですが、適用タイミングのオプションが2種類あり、タイミングを選択可能です。

「Apply during the next scheduled maintenance window」で次回のメンテナンスウィンドウで実行をする
「Apply immediately」で即時実行する

1を選択した場合、変更は即時適用されず、次回のメンテナンスウィンドウに持ち越されます。土日や夜間に変更（シャットダウンを伴う）を行いたい場合はこの方法を選択可能です。2を選択した場合は即時実行されるため、DB インスタンスクラスの変更時においては即時シャットダウンが実行されます。静止時間はインスタンスクラスやDBの状況に応じて変わるため一概に何分とは明言できませんが、5分から20分程度はかかるであろうというのが私の経験則です。実際に静止している時間を見積もられたい場合は、検証環境を複製頂き実際の作業にて静止時間を測定頂くのがより正確です。

本パターンのメリットデメリット、そしてシナリオを以下に記載します。

メリット
- シングル構成のためシンプル
- シングル構成のため低コスト
デメリット
- 最も長い静止点を伴う
- 「RDSを本番環境で停止運用しないほうが良い理由について」にも記載した通り、シャットダウンを伴うためインスタンスクラスの枯渇が起きた場合はより長い静止点を伴ってしまう場合がある
この手法が向いているシナリオ
- 検証環境もしくはある程度の静止点が許容可能な本番環境

2: Failoverパターン

次にご紹介するのは、ベストプラクティスと言えるであろうFailover（フェイルオーバー）パターンです。

まずはAmazon AuroraにReader(Read Replica)を追加します。

Amazon Relational Database Service (RDS) » Aurora のユーザーガイド » Amazon Aurora DB クラスターの管理 » DB クラスターに Aurora レプリカを追加する https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html

追加を行うRead Replicaは変更予定の「r5.large」で作成します。念のため記載しますと、AuroraのRead ReplicaはマスターであるWriterと別のDB インスタンスクラスでも問題ありません。
追加しましたら、AuroraでFailoverを手動で実行します。

Failover中は一時的にAuroraに接続ができなくなりますが、非常に短い時間で済みます。Failoverのダウンタイムについては「よくある質問」のページに記載があるため、こちらより引用します。

Q: フェイルオーバー中はどのようなことが起き、どのくらいの時間がかかりますか? フェイルオーバーは Amazon Aurora によって自動的に処理されるため、アプリケーションは管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。

同一、または異なるアベイラビリティーゾーンに Amazon Aurora レプリカを作成している場合、障害が発生すると、Aurora は DB インスタンスの正規名レコード (CNAME) を反転させ、正常なレプリカを指定します。指定されたレプリカは新しいプライマリに昇格します。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。

Failover は、30秒以内に完了と記載がある通り非常に短時間で完了します。私が検証した限りでは15秒程度で完了していました。

Failover が完了しますと、先ほどとDB インスタンスクラスが入れ替わった状態になります。これでインスタンスクラスの変更は完了です。

あとは不要となったRead Replicaを削除することでコストを削減することも可能です。

先にこの手法がベストプラクティスと記載しましたが、以下もその理由の1つです。これもまた「よくある質問」からの引用ですがご紹介します。

機能	Amazon Aurora レプリカ	MySQL レプリカ
レプリケーション数	最大 15	最大 5
レプリケーションタイプ	非同期的 (ミリ秒単位)	非同期的 (秒単位)
プライマリへのパフォーマンスの影響	低	高
レプリカのロケーション	リージョン内	クロスリージョン
フェイルオーバーターゲットとして機能	はい (データ損失なし)	はい (数分間データ損失の可能性)
自動フェイルオーバー	はい	いいえ
ユーザー定義のレプリケーション遅延サポート	いいえ	はい
プライマリに対する異なるデータまたはスキーマのサポート	いいえ	はい

「フェイルオーバーターゲットとして機能」に記載がありますが、AuroraのRead Replicaではデータ損失はありません。この点がAuroraのFailoverの素晴らしい点です。

本パターンのメリットデメリット、そしてシナリオを以下に記載します。

メリット
- ダウンタイムが30秒以内である
- Read Replicaが作成された時点でインスタンスの確保が完了しているため、キャパシティ不足による影響を受けない
デメリット
- 一時的にRead Replicaを作成するため、コスト増となる
- Modifyよりも手順としては手間がかかる（Read Replicaの作成、Failover、Read Replicaの削除という3ステップ）
この手法が向いているシナリオ
- 30秒程度の静止点が許容される本番環境

3: Aurora複製パターン

少々特殊な事情がある場合に検討の余地があるAurora複製パターンのご紹介です。

今回は、Read Replicaの追加ではなく、新しいDB インスタンスとしてAuroraクラスターをもう1台作成します。作成元は前環境のSnapshot(バックアップ)を利用しますが、実際は「Restore to point in time」を利用し直前の状態で複製するのが最も良い手法です。なお同じEndpoint名は記載ができませんため、別のEndpointを利用する点に注意してください。また、Snapshotを利用して新しいAuroraを作成しはじめてからはデータベースに差分が発生してしまう点にも十分注意が必要です。可能なら、EC2 インスタンスは停止してしまうか、書き込みをやめて読み込みだけにするのが良いでしょう。

新しいAuroraの作成が完了したら、向き先を新しいAuroraのEndpointに切り替えます。手順としてはこれだけになります。

もし同じEndpoint名を引き継ぎたい場合は「前のAuroraクラスター」の名称を上図のように変更してから書き換えることが可能です。こうすることで元の環境を一時的に保持することができます。

もちろん、元の環境がいらなければ最初から消してしまい、空いたEndpoint名を引き継ぐという手も可能です。

この手法は通常通りDB インスタンスクラスを変更するという点だけを見れば、パターン2の「Failoverパターン」より劣ります。しかし「別のDBインスタンス」になっている点がメリットになる場合があります。例えば「Auroraのアップグレードを合わせて行いたい」場合です。他にもパラメータグループを変更したい場合なども有用です。

本パターンのメリットデメリット、そしてシナリオを以下に記載します。

メリット
- 別のDBインスタンスとして構築するため、Auroraのアップグレードやパラメータグループの更新を合わせて行ってから切り替えができる
- 以前のDBインスタンスを保持することが可能
デメリット
- 複製したAuroraでは構築後からデータの差分が発生する問題を回避する必要がある
- Endpoint名の引継ぎを行う場合は一度前の環境のEndpointを解放する必要がある
この手法が向いているシナリオ
- データの差分を吸収可能な状態で、Auroraのアップグレード等を行ってから切り替えたい場合

4: Replicationパターン

基本的には、先に紹介しました「Aurora複製パターン」と同様です。ただし複製した後、複製元と複製先でレプリケーションを行います。

このレプリケーションの実装方法は以下の公式ドキュメントをご参考ください。

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html

先の手法ではSnapshotから複製した後はひたすら差分が発生してしまうため、それを何らかの方法で回避する必要がありましたが、レプリケーションを行うことでこれを回避可能です。

上図ですが、切り替えを行うタイミングではレプリケーションを止めると同時にEC2からのアクセスも止めることになるでしょう。

あとは先ほどと同様に別のEndpoint名に接続します。

元の環境がいらなくなれば削除します。このパターンでは、運用が非常にシビアな本番環境にてダウンタイムをほぼ0で切り替えを行う場合に有効です。また、先ほどと同様にAuroraのアップグレードを挟み込むこともできるのがメリットになります。

本パターンのメリットデメリット、そしてシナリオを以下に記載します。

メリット
- 別のDBインスタンスとして構築するため、Auroraのアップグレードやパラメータグループの更新を合わせて行ってから切り替えができる
- 以前のDBインスタンスを保持することが可能
- ダウンタイムがほぼ0で切り替えが可能
デメリット
- Endpoint名を引き継がず（基本的には）切り替えを許容する必要がある
- 手順が（非常に）複雑であり、また時間がかかる
この手法が向いているシナリオ
- ダウンタイムが許容されない環境でDB インスタンスクラスを変更しながらAuroraのアップグレード等も行いたい場合

5: Cross-region Read Replicaパターン

最後は、使っている例を見たことがないのですが実現が可能と想像しているパターンです。先ほどまで記載しましたパターンの1～4は全て実際に行われたことがあるパターンとなっておりますがこちらのパターンは私の想像で記載しております。これは2016年6月にリリースされました「Cross-region Read Replica」を利用したパターンです。

まず、別のRegion（今回はシンガポールリージョン）にRead Replicaを作成します。

この時点で少しだけ何かおかしい気がしますが、このまま続けます。

そして Cross-region Read Replica の場合のみ、そのRead Replicaはマスターに昇格（Promote）ができます。そしてスタンドアロンのDBクラスターとなったのが上図です。これは以下のドキュメントにも記載があります。

AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケート https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html#AuroraMySQL.Replication.CrossRegion.Promote

最後にEndpoint名を新しいEndpoint名に切り替えて完了です。

この手法はAuroraが持つ基本的な機能のみで「Auroraを複製しかつ特定のポイントでレプリケーションを停止しスタンドアロンに昇格できる」という点で優れています。ただし、Regionを超えてしまうという最大のデメリットがあり、こればかりはどうしようもありません。Inter-regionでもRead Replicaが昇格できるようになればこの手法もどこかで日の目を見ることがあるかもしれませんが、現状Cross-regionでしか実現できないため、このような形でのご紹介となりました。ちなみにですが、昇格をさせるとDB インスタンスは再起動されるとのことです。

メリット
- Auroraの機能だけでスタンドアロンの複製環境を生み出せる
デメリット
- Regionを跨ぐためにEndpoint名が変更される点を許容する必要がある
- Regionを跨ぐためにRegion超えのネットワーク通信料が発生する
- 別Regionの利用準備が必要となる
この手法が向いているシナリオ
- 募集中

まとめ

今回はAmazon AuroraのDB インスタンスクラスを変更する手法をまとめてみました。各パターン名は以下の通りです。

Modifyパターン
Failoverパターン
Aurora複製パターン
Replicationパターン
Cross-region Read Replicaパターン

現実的に採用されるのは、多くの場合 [1] か [2] だと考えておりますが、この2つをとってもよく理解して使い分けが必要だとご理解頂けたかと思います。また、独立した環境を先に用意してから切り替えるという [3] または [4] のパターンが望まれる場合もありますので、合わせて紹介しております。 [5] は「Cross-region Read Replicaなんて機能があったのか」とだけでも思って頂けたら嬉しいです。

それでは、暑い夏が続きますが皆さんくれぐれも体調には気を付けてください。