RDS記事タイトルとURLをコピーするCS課佐竹です。最近暑いので、色が青いRDSでも弄って涼を取ろうと思い、RDSについて記載します。classを変更したい」そう思った時、どのようなシナリオ・手順が考えられるでしょうか。ここでは一般的なModifyで実施する方法から、可能な限り停止時間を短くするような方法、そしてAurora本体のアップグレードにも対応するような方法と、合わせて5つの方法をご紹介したいと思います。インスタンスクラスと呼ばれていることはご存じでしょうか。インスタンスクラスになります。公式ページでも「インスタンスタイプ」と表記されていたりして、よくわかりません。インスタンスクラス」と記載します。勢いでインスタンスタイプと書いてしまう場合もあるかもしれませんが、見逃してください。最初に、説明の元ネタとなります構成図をご紹介します。以下の図のように、EC2とRDS(Aurora)が1台ずつで構築されている環境があるとします。EC2とAurora間にはコネクションが存在しています。今回、この「r4.large」のAuroraを「r5.large」に変更したいとします。パターン別に見てみましょう。Modifyパターン最初にご紹介するのは、最も一般的な変更方法です。インスタンスクラスを変更します。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.htmlModifyのコマンドはマネジメントコンソールもしくはAPIで実行するのみです。インスタンスクラスが変更された後に起動します。図で表すと、以下のように「一時的にコネクションは切断」されます。状態に戻り再度利用可能となります。この変更方法ですが、適用タイミングのオプションが2種類あり、タイミングを選択可能です。immediately」で即時実行する1を選択した場合、変更は即時適用されず、次回のメンテナンスウィンドウに持ち越されます。土日や夜間に変更(シャットダウンを伴う)を行いたい場合はこの方法を選択可能です。インスタンスクラスの変更時においては即時シャットダウンが実行されます。静止時間はインスタンスクラスやDBの状況に応じて変わるため一概に何分とは明言できませんが、5分から20分程度はかかるであろうというのが私の経験則です。実際に静止している時間を見積もられたい場合は、検証環境を複製頂き実際の作業にて静止時間を測定頂くのがより正確です。本パターンのメリットデメリット、そしてシナリオを以下に記載します。Failoverパターン次にご紹介するのは、ベストプラクティスと言えるであろうFailover(フェイルオーバー)パターンです。Replica)を追加します。Replicaは変更予定の「r5.large」で作成します。インスタンスクラスでも問題ありません。追加しましたら、AuroraでFailoverを手動で実行します。Failover中は一時的にAuroraに接続ができなくなりますが、非常に短い時間で済みます。Failoverのダウンタイムについては「よくある質問」のページに記載があるため、こちらより引用します。よって自動的に処理されるため、アプリケーションは管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。反転させ、正常なレプリカを指定します。指定されたレプリカは新しいプライマリに昇格します。30秒以内に完了と記載がある通り非常に短時間で完了します。私が検証した限りでは15秒程度で完了していました。インスタンスクラスが入れ替わった状態になります。これでインスタンスクラスの変更は完了です。Replicaを削除することでコストを削減することも可能です。先にこの手法がベストプラクティスと記載しましたが、以下もその理由の1つです。これもまた「よくある質問」からの引用ですがご紹介します。Replicaではデータ損失はありません。この点がAuroraのFailoverの素晴らしい点です。本パターンのメリットデメリット、そしてシナリオを以下に記載します。Aurora複製パターン少々特殊な事情がある場合に検討の余地があるAurora複製パターンのご紹介です。インスタンスとしてAuroraクラスターをもう1台作成します。time」を利用し直前の状態で複製するのが最も良い手法です。同じEndpoint名は記載ができませんため、別のEndpointを利用する点に注意してください。Snapshotを利用して新しいAuroraを作成しはじめてからはデータベースに差分が発生してしまう点にも十分注意が必要です。インスタンスは停止してしまうか、書き込みをやめて読み込みだけにするのが良いでしょう。新しいAuroraの作成が完了したら、向き先を新しいAuroraのEndpointに切り替えます。手順としてはこれだけになります。同じEndpoint名を引き継ぎたい場合は「前のAuroraクラスター」の名称を上図のように変更してから書き換えることが可能です。することで元の環境を一時的に保持することができます。元の環境がいらなければ最初から消してしまい、空いたEndpoint名を引き継ぐという手も可能です。インスタンスクラスを変更するという点だけを見れば、パターン2の「Failoverパターン」より劣ります。「別のDBインスタンス」になっている点がメリットになる場合があります。「Auroraのアップグレードを合わせて行いたい」場合です。他にもパラメータグループを変更したい場合なども有用です。本パターンのメリットデメリット、そしてシナリオを以下に記載します。Replicationパターン基本的には、先に紹介しました「Aurora複製パターン」と同様です。複製した後、複製元と複製先でレプリケーションを行います。このレプリケーションの実装方法は以下の公式ドキュメントをご参考ください。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html先の手法ではSnapshotから複製した後はひたすら差分が発生してしまうため、それを何らかの方法で回避する必要がありましたが、レプリケーションを行うことでこれを回避可能です。上図ですが、切り替えを行うタイミングではレプリケーションを止めると同時にEC2からのアクセスも止めることになるでしょう。あとは先ほどと同様に別のEndpoint名に接続します。元の環境がいらなくなれば削除します。このパターンでは、運用が非常にシビアな本番環境にてダウンタイムをほぼ0で切り替えを行う場合に有効です。先ほどと同様にAuroraのアップグレードを挟み込むこともできるのがメリットになります。本パターンのメリットデメリット、そしてシナリオを以下に記載します。Replicaパターン最後は、使っている例を見たことがないのですが実現が可能と想像しているパターンです。先ほどまで記載しましたパターンの1~4は全て実際に行われたことがあるパターンとなっておりますがこちらのパターンは私の想像で記載しております。Replica」を利用したパターンです。Replicaを作成します。この時点で少しだけ何かおかしい気がしますが、このまま続けます。Replicaはマスターに昇格(Promote)ができます。スタンドアロンのDBクラスターとなったのが上図です。これは以下のドキュメントにも記載があります。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html#AuroraMySQL.Replication.CrossRegion.Promote最後にEndpoint名を新しいEndpoint名に切り替えて完了です。この手法はAuroraが持つ基本的な機能のみで「Auroraを複製しかつ特定のポイントでレプリケーションを停止しスタンドアロンに昇格できる」という点で優れています。Regionを超えてしまうという最大のデメリットがあり、こればかりはどうしようもありません。Replicaが昇格できるようになればこの手法もどこかで日の目を見ることがあるかもしれませんが、現状Cross-regionでしか実現できないため、このような形でのご紹介となりました。インスタンスは再起動されるとのことです。インスタンスクラスを変更する手法をまとめてみました。各パターン名は以下の通りです。考えておりますが、この2つをとってもよく理解して使い分けが必要だとご理解頂けたかと思います。パターンが望まれる場合もありますので、合わせて紹介しております。Replicaなんて機能があったのか」とだけでも思って頂けたら嬉しいです。それでは、暑い夏が続きますが皆さんくれぐれも体調には気を付けてください。エンジニアブログの記事一覧はコチラマネージドサービス部所属。2010年1月からAWSを利用してきています。AWSのコスト削減、最適化を得意としています。2009-引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。