クロスリージョン・クロスアカウントで Aurora Serverless v2 の移行を検証してみた

Yuko OSAKI

2022.06.08

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

こんにちは、prismatix事業部の大崎です。

EC/CRMプラットフォーム prismatix のSREチームではインフラやアプリケーションを安定稼働させるため、より良い新しいアーキテクチャの検討なども行っています。その取り組みの中で、4月に一般公開された Aurora Serverless v2 の検証を行ったのでご紹介します。

prismatixとはどんなサービスか、どのような組織なのか興味を持たれた方は是非以下のエントリをご覧下さい。

prismatix(プリズマティクス)事業部のことがよくわかるWebページやブログエントリ、YouTube動画 n選

はじめに

今回の検証ではprismatix内で以下の2点を確認することを主な目的として行いました。

既存の Aurora から Aurora Serverless v2 への移行手順
MySQL5.7 から MySQL8.0 にアップグレードした際のマイクロサービスへの影響

※ Aurora Serverless v2 への移行が最適かどうかまでは今回検証していません。

また、Aurora2 から Aurora3 へのアップグレードのより詳細な検証や、DevelopersIOを実際に Aurora Sreverless v2 に移行した記事は以下を参照ください。

検証の流れ

今回は既存の検証用データを有している環境への影響を最小限にするため、Serverless v2 検証用の別環境にAuroraを立てることにしました。クロスリージョンかつクロスアカウントでの検証なのでややイレギュラーではありますが、流れは以下の通りです。

リソース情報

移行元
- 環境：検証用データを有している環境(アカウントA)
- リージョン：オレゴン(us-west-2)
- DB情報：Aurora2(5.7.mysql_aurora.2.04.9) / db.r5.large / CMK暗号化(単一リージョン)
移行先
- 環境：Aurora Serverless v2検証用環境(アカウントB)
- リージョン：東京(ap-northeast-1)
- DB情報：Aurora Serverless v2(8.0.mysql_aurora.3.02.0) / 0.5-2.0ACU / CMK暗号化(単一リージョン)

流れ

東京リージョンにアカウントBと共有可能なAurora暗号化用のKMS(CMK)を作成
Aurora2 のスナップショット取得後、東京リージョンにコピー
2.でコピーしたスナップショットをアカウントBと共有

--- 以降、移行先のアカウントBで実施 ---
共有スナップショットより復元（Aurora3へアップグレード）
Aurora3 からAurora Serverless v2 へインスタンスクラス変更
マイクロサービスの向き先を Aurora Serverless v2 に変更してシナリオテスト実施

手順

東京リージョンにアカウントBと共有可能なAurora暗号化用のKMS(CMK)を作成

今回は移行元の環境にマルチリージョンキーのAurora暗号化用CMKがないため、外部アカウントのアクセスを許可する設定を入れ新規作成しました。マルチリージョンキーがある場合、キーポリシーに以下の共有設定を追加するのみで大丈夫です。（参考：他のアカウントのユーザーに KMS キーの使用を許可する）

  {
    "Sid" : "Allow use of the key",
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : "arn:aws:iam::<AWSアカウントID>:root"
    },
    "Action" : [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ],
    "Resource" : "*"
  }, {
    "Sid" : "Allow attachment of persistent resources",
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : "arn:aws:iam::<AWSアカウントID>:root"
    },
    "Action" : [ "kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant" ],
    "Resource" : "*",
    "Condition" : {
      "Bool" : {
        "kms:GrantIsForAWSResource" : "true"
      }
    }
  }

マルチリージョンキーのCMKを作成する場合はこちらの記事を参考にしていただければと思います。

Aurora2 のスナップショット取得後、東京リージョンにコピー

移行元のAurora2のスナップショットを取得します。（参考：DB スナップショットの作成）

スナップショットの作成が完了したら、送信先リージョンで東京リージョンを選択し、事前に作成したCMKを指定して暗号化します。

※Auroraの暗号化有無に関わらず、クロスアカウントでスナップショットを直接異なるリージョンに復元することはできなかったため、移行元のアカウントA内で東京リージョンにコピーする手順を踏んでいます。

コピーしたスナップショットをアカウントBと共有

東京リージョンに移動してスナップショットがコピーされていることを確認し、アカウントBへの共有設定をします。

共有スナップショットより復元（Aurora3へアップグレード）

アカウントBの東京リージョンのスナップショットの「自分と共有」でアカウントAより共有されたスナップショットがあることを確認し、選択します。

キャパシティータイプは「プロビジョニング済み」、バージョンは「Aurora MySQL 3.02.0」を選択します。（ ※ キャパシティータイプで「サーバレス」を選択すると、Aurora Serverlessで利用可能な「Aurora(MySQL 5.7)2.07.1」しか選択出来ません。）

DBインスタンスクラスは「メモリ最適化クラス」で「db.r5.large」を選択し、復元します。

※DBインスタンスクラスで「サーバレス」を選択し復元を試みると以下のようなエラーメッセージが出ます。まず、プロビジョニングされたDBインスタンスとして復元する必要があります。（参考：既存のクラスターで Aurora Serverless v2 を使用する）

Aurora3 からAurora Serverless v2 へインスタンスクラス変更

スナップショットの復元が完了したらDBインスタンスクラスで「Serverless v2」を選択し、変更を実施します。

※最大ACUを0.5にしても15分ほどで変更は完了しましたが、CPUが100％に貼り付いたため、後から2ACUに増強しました。

マイクロサービスの向き先を Aurora Serverless v2 に変更してシナリオテスト実施

各マイクロサービスでDB接続先として設定されているRoute53のレコードのCNAMEの値を Aurora Serverless v2 のエンドポイントに変更します。

※RDSなどエンドポイントをもつサービスをRoute53とセットで利用することで、今回のような一時的な試験の際もアクセス元の設定変更不要で容易に切り替えができます。（参考：【初心者向け】エンドポイントを持つサービス（RDSなど）とRoute53をセットで使うことのメリット）

検証してみた感想

クロスリージョンでのスナップショットコピーやクロスアカウントでの共有等それぞれ独立で見かける手順に加え、Aurora Serverless v2アップグレードと初めの作業を一連で行うのはやや苦労しました。複雑な作業をする際には事前に流れを組み立ててから行う重要性を改めて実感しました。
MySQL5.7 から MySQL8.0 のアップグレード影響の詳細は割愛しますが、予約語の追加など変更点も多くあり、サービス全体の影響調査・対応は慎重に行う必要があると感じました。 Aurora2(MySQL 5.7 互換)のEOLはまだ明らかにはなっていませんが、まずはMySQLのアップグレードを優先して検討していきたいです。
複数のマイクロサービスを提供し、環境数も多い prismatix において、Aurora Serverless v2 への移行がベストであるか結論づけるには整理すべきことが多くあります。コストや性能、運用しやすさなど様々な観点から今後も継続して検証していきます。