はじめに
こんにちは！any株式会社でプロダクトチームに所属しているエンジニアのfumiyanです！
弊社が提供しているナレッジ経営クラウドのQastでは、RDBMSとしてAmazon RDS for MySQL（以下、RDSと表記）を採用しています。本記事では、RDSからAmazon Aurora MySQL（以下、Auroraと表記）へ移行した取り組みについて解説します。
移行作業が無事終わった際に、メンバーが喜んでくれました！
移行背景
前提として、RDSからAuroraへ移行する背景には、Auroraの特徴に記載されている数多くのメリットを享受できる点があります。高可用性やスケーラビリティ、パフォーマンス向上に加え、運用管理の負担を軽減できることが大きな理由です。主な利点は以下のとおりです。
- 公式ベンチマークテストで、標準的なMySQLと比較して最大5倍、標準的なPostgreSQLと比較して最大3倍のスループットが見込める
- 最大15個のリードレプリカを作成できるので、容易にスケールアウトが可能で、これにより読み取り性能が向上し高いスケーラビリティを実現できる
- プライマリー（ライター）で障害が発生した場合、自動フェイルオーバーによりリードレプリカをプライマリーに昇格可能
- データは3つのAZにまたがるクラスターボリュームに保存され、高い耐障害性を確保
- ストレージサイズが自動スケーリングされるため、余分な容量を事前に確保する必要がない
- Serverlessを選定することができ、運用面でさらに負担を軽減できる
デメリットとしては、利用できるエンジンがMySQLやPostgreSQLに限定されていること、最新バージョンへの対応が遅れるなどがあります。ただし、これらの点を考慮しても、メリットの方が大きいので移行する判断を取りました。
準備・確認
Auroraへの移行にあたり、主に以下の準備と確認を行いました。
- Provisioned or Serverless選定
- コスト試算
- 移行方法選定
- テスト環境およびステージング環境のリハーサルと確認作業
その他にも、Auroraの仕様確認、サブネットグループ・セキュリティグループ・カスタムパラメータグループといった事前のインフラ設定、接続先の確認、IaCにおける設定値の変更、テスト環境とステージング環境の移行後のテストなど、各種の準備と確認を実施しました。
Provisioned or Serverless選定
Auroraへの移行にあたり、コンピューティングタイプとしてProvisionedとServerlessの2種類から選定可能ですが、以下の理由によりProvisionedを選定しました。
- メトリクスから変動の激しいワークロードではないことを確認
- ProvisionedとServerlessを併用できるため、まずはProvisionedで運用を開始しつつ、一部にServerlessを適用して運用する、あるいはケースに応じて移行するのが望ましいと判断（例：プライマリーはProvisioned、リードはServerless）
- ACU値をより正確に見積もりたい
- バッファプールで最適化ができており、スケールダウンとアップ時のメモリの動きを詳細に確認したい
公式ドキュメントや、Serverlessを導入と運用している他社様の事例記事も参考にして選定しました。以降は、Provisionedを前提とした解説となります。
コスト試算
先ほど挙げた移行のメリットを享受できたとしても、コストが現状の数倍またはそれ以上に膨らんでしまっては、プロダクト運用上の大きな課題となります。そこで、詳細なコスト試算を行いました。料金については料金体系を参考にし、インスタンス料金・ストレージ料金・I/Oリクエスト料金を基に算出した結果は、許容範囲内に収まりました。
また、I/Oリクエストをメトリクスで確認したところ、現状ではI/O最適化を利用する必要はなく、スタンダードで十分でした。さらに、インスタンスタイプについてはメモリ最適化を継続しつつ、プロセッサをGraviton4に変更しました。
移行方法選定
移行方法については、公式ドキュメントで提示されている2つの案を参考に、案1と案2を作成し、比較検討のうえ選定しました。
案1：RDSのスナップショットからAuroraを作成して移行
- RDSのスナップショット作成
- スナップショットの移行でAuroraを選択して作成
- RDSとAurora間でレプリケーションの仕組みを構築
- RDSに対して書き込み停止
- レプリケーションのラグが0になっていることを確認
- 接続先をAuroraに変更
- アプリケーションのデプロイ
案2：RDSからAurora リードレプリカを作成して移行
- RDSに対してAurora リードレプリカを作成
- RDSに対して書き込み停止
- レプリケーションのラグが0になっていることを確認
- Auroraを昇格
- 接続先をAuroraに変更
- アプリケーションのデプロイ
接続先をAuroraに切り替える際、各接続先情報を手作業でAuroraのエンドポイントに書き換えるのは手間がかかり、ダウンタイムが長引く原因となります。さらに、設定漏れが発生するリスクもあります。そこで事前に、RDSのエンドポイントをDNSのCNAMEレコードで管理し、そのCNAMEを参照するようにしておきます。これにより、Auroraへの切り替え時にはCNAMEレコードの値をAuroraのエンドポイントに変更するだけで済み、作業効率と安全性を高められます。その他に、RDSへの書き込みを停止する前に移行作業用のメンテナンス画面を用意しておくことで、作業をより安全に進めるとともに、ユーザーがアクセスした際の混乱を防ぐことができます。
最後にアプリケーションをデプロイする理由としては、一部アプリケーションがコネクションプールで管理されているので、デプロイをすることによってアプリケーションが再起動されてコネクションがAuroraの方に接続されるようにするためです。また、アプリケーション側で接続失敗時にAurora用のコネクションプールの新たな接続をする仕組みの導入もありましたが、デプロイが短時間で直ぐにできる仕組みになっているため、今回はデプロイを選択しました。
上記を踏まえると、案1・案2いずれの場合もダウンタイムを最小限に抑えつつAuroraの接続テストが可能であり、安全に切り替えを実施でき、データの整合性も担保できます。そのうえで、案2は独自のレプリケーション機構を設定する必要がなく、移行方法が複雑にならないため、案2を採用しました。なお、DMSによる移行も候補にはありましたが、今回のユースケースには案1または案2の方が適していました。
テスト環境およびステージング環境のリハーサルと確認作業
上記で示した移行方法を基盤として、詳細な作業手順書を作成し、その手順書に基づいて本番環境と同一の流れでリハーサルと確認作業を実施しました。リハーサルを事前に行うことで、作業工程に潜む問題点や不備を早期に発見し、あらかじめ対策を講じることが可能となります。また、リハーサルを通じて作業担当者が手順に慣れることで、本番作業においても迷いなく進められるようになり、作業効率や精度の向上が期待できます。
さらに、事前確認によって問題の再現性や発生条件を把握しておけば、万が一本番作業中や作業完了後に予期せぬトラブルが発生した場合でも、落ち着いて迅速かつ適切に対応できる体制を整えることができます。このようにリハーサルと確認を徹底することは、単なる事前準備にとどまらず、本番作業の安全性や信頼性を高め、最終的には全体の品質向上につながる重要なプロセスとなります。
エムスリーさんが公開していた記事では、大規模なメンテナンス作業を実施する際に準備しておくべき事項が整理されています。その中ではリハーサルの重要性を説明してくれており、非常に参考になる内容なので、一読をおすすめします。
移行作業
移行方法で選定した案2を元に、実際に移行作業を解説します。
RDSに対してAurora リードレプリカを作成します。Auroraに設定するサブネットグループ、セキュリティグループ、カスタムパラメータグループは、事前に作成しておく必要があります。
Aurora リードレプリカの設定値を入力し、作成が完了しました。構成としては、プライマリーがRDS、レプリカクラスターがAuroraになっています。マルチAZ配置を有効にしているため、ライターとリーダーが存在します。マルチAZ配置を行っていない場合は、ライターのみが存在します。
レプリケーションが正常に動作している場合、状態は「レプリケーション中」と表示されます。この画面でレプリケーションの遅延が発生していないかどうかも確認できます。
また、Auroraに対して以下のクエリを実行することで、レプリケーションの正常性および遅延の有無を確認できます。重要な値としては、Slave_IO_RunningとSlave_SQL_RunningがともにYesであり、Last_IO_ErrorとLast_SQL_Errorにエラーが出ていなければ正常に動作しています。さらに、Seconds_Behind_Masterが0の場合は遅延が発生していません。
SHOW SLAVE STATUS;
次に、RDSへの書き込みを停止するため、パラメータグループのread_onlyを1に設定します。
その次にレプリケーションのラグが0になっていることの確認は、先ほどあげたマネージコンソールかクエリで確認できます。
レプリケーションのラグが0になっていることを確認できたら、Auroraを選択し昇格させます。
昇格が成功すると、以下のようにロールがリージョン別クラスターとなりRDSから分離されます。
最後に、DNSのCNAMEレコードをAuroraのエンドポイントに変更すれば作業は完了です。その後、アプリケーションの疎通確認を行ってください。メンテナンス画面を設定している場合は、忘れずに解除してください。
まとめ
最後までお読みいただき、ありがとうございました！
本番環境におけるDB移行作業は、一つの小さな判断ミスや作業上の不備が、大規模な障害やサービス停止といった重大なリスクに発展しかねません。そのため、細心の注意を払って取り組む必要があります。ただ、事前に十分な調査を行い、考えられるリスクを洗い出したうえで、綿密なリハーサルを繰り返し実施すれば、不安要素を大幅に減らすことが可能です。準備を重ねることで、本番当日はスムーズかつ計画通りに移行作業を完遂することができ、安心して運用を継続する体制を整えることができるはずです！
Discussion