サムネイル

はじめに

この記事は DMMグループ Advent Calendar 2024 の19日目の記事です。

こんにちは。プラットフォーム開発本部第2開発部決済グループ購入チームの川嶋です。

今回は、購入チームがAmazon Aurora v2 から v3 へ無停止でバージョンアップ を行った際の作業内容について共有します！

Amazon Aurora v3 へバージョンアップを行った経緯

Amazon Aurora v3 へのバージョンアップを決断した大きな理由は、利用中のAmazon Aurora v2が2024年10月にサポート終了（EOL） を迎えることでした。

EOL後も延長サポートは提供されるものの、2024年12月以降は延長サポート利用金 が発生し、無視できないほど費用がかかると判断しました。また、Amazon Aurora v3 の追加機能による開発効率向上の恩恵が受けられるのも大きな理由でした。

バージョンアップの要件と課題について

バージョンアップに対する要件

無停止でバージョンアップを実施すること

DMMの全サービスの決済処理が止まってしまうことで起こりうる機会損失を避ける必要があります。

バージョンアップに対する課題

購入チームが提供しているAPIを利用するのではなく、購入チームのデータベースを直接参照してしまっている決済外のサービスへの影響を最小限に抑えること

Amazon Aurora v2からオンプレデータベースへのレプリケーションが貼られており、オンプレデータベースを直接参照しているサービスが存在していました。

APIやバッチのテストが不足している

Unit Test が存在しないAPIが多数存在したことから、バージョンアップ起因で発生するエラーをCIで担保できない状態でした。

バージョンアップを行うために実施したこと

バージョンアップ用のv3クラスターと切り戻し用のv2クラスターの作成

決済グループ内の他チームが先行してAmazon Auroraのバージョンアップを実施していましたが、購入チームではAmazon RDS Proxyを採用していたため、完全には同じ対応を踏襲できませんでした。

既存のアーキテクチャ 既存のアーキテクチャー

本番相当の負荷を掛けながら、Amazon RDS Proxyの接続先をAmazon Aurora v2からAmazon Aurora v3へ切り替えた際の挙動を検証しました。データの不整合が発生しないことが確認できたため、アプリケーションのエンドポイントを変更せずに対応する方針を採用しました。

step 1. Amazon Aurora v2(切り替え前)からスナップショットを取得し、Amazon Aurora v3（切り替え後）およびAmazon Aurora v2（切り戻し用）クラスターを作成 既存のアーキテクチャー

step 2. bin_logを用いてAmazon Aurora v2（切り替え前） → v3（切り替え後）への単方向レプリケーションを実施 既存のアーキテクチャー

step 3. アプリケーションの向き先をAmazon Aurora v3（切り替え後）へ切り替え 既存のアーキテクチャー

step 4. Amazon Aurora v2（切り替え前）およびAmazon Aurora v2（切り戻し用）を撤去 既存のアーキテクチャー

単体テストが不足しているAPIやバッチの実装

不足していた25本のAPIの Unit Test は、2名体制で約3週間にわたり集中的に実装し、カバーしました。仕様不明のAPIや、バグを含むAPIもあり、有識者と認識合わせを行いながら進めました。

負荷試験の実施

プラットフォーム開発本部のMSAグループの提供ツールを用いて、Amazon Aurora v2 と v3 の負荷比較を実施しました。

ツールの詳細については、以下の記事をご参照ください。

k8s 上の負荷試験基盤でロードテストを効率化するために新機能を追加した話

本番環境相当のデータ を使用し、主要な参照系・更新系APIのシナリオテストを行いました。特に本番同様のリクエストパターンを構築するため、ユーザー履歴分布の分析に苦労しました。

データベースを直接参照している決済外のサービスのエンドポイント変更調整

直接参照をしているサービスの数が多く、各サービスとの調整とバージョンアップの影響調査などを並行で進めるのは厳しく、途中で他の方をアサインしていただき調整周りの作業を巻き取っていただきました。

調査

まずはインフラ部門にオンプレ環境へのアクセスログを依頼するところから開始しました（この時点では直接参照があることは把握していましたが、数は把握していませんでした）。結果、10個のサービスが購入チームのデータベースを直接参照していることが分かりました。主な用途として、バッチを使って、サービス側と購入側のデータの不整合が無いかの確認や、購入関連のデータを取得するために直接参照しておりました。

方針

直接参照しているサービスは前述でも述べたとおり、Amazon Aurora v2 からオンプレデータベースへレプリケーションが貼られており、Amazon Aurora v3 へバージョンアップ後はオンプレDBのデータは更新されない状態になります。バージョンアップ後にオンプレへのレプリケーションを貼る案も考慮しましたが、バージョン差異による懸念や最終的にはオンプレ脱却を目指しているため、直接参照しているサービスのAmazon Aurora v3 へのエンドポイントへ変更していただく方針にしました。

本来であれば、この機会にAPI提供を行って直接参照自体を廃止したかったのですが、EOL期限の兼ね合いから断念しました。

移行計画

以下のステップで各サービスの担当者に依頼して、ご協力いただきました。

STG環境のエンドポイントをAmazon Aurora v2 のリーダーエンドポイントに変更後、バッチの実行と挙動確認（万が一、Amazon Aurora v3 で問題が発生した場合は、Amazon Aurora v2 に切り戻す必要があったため、Amazon Aurora v2 での挙動確認も行いました）
STG環境のエンドポイントを本番環境相当のレコードを保持している検証用 Amazon Aurora v3 のリーダーエンドポイントに変更後、バッチの実行と挙動確認
PRD環境のエンドポイントをAmazon Aurora v3 のリーダーエンドポイントに変更後、バッチの実行と挙動確認

Amazon Auroraへ移行後のバッチの所要時間はオンプレに比べて、全体的に増加傾向にありました。Amazon RDS Proxyの仕様により、クエリまたはトランザクションの応答時間には平均で5ミリ秒のレイテンシーが発生するためでした。