はじめに
こんにちは。プラットフォーム事業本部第１開発部アカウントサービスグループ所属の中島暢哉と申します。
今回の記事では、DMM.comの会員サービスで使用しているデータベースをオンプレミスからクラウド（Amazon Aurora MySQL）に移設した際の具体的な方法や、そこで発生した問題について紹介します。
DMM会員基盤について
私たちのチームでは 4,101 万人（2023年2月時点）の DMM のアカウントを管理するサービスを開発・運用しています。プロダクトの性質上、DMMのほぼ全サービスと繋ぎ込みしており、幅広いサービスとの連携や多くのステークホルダーとの関わりがあるプロダクトです。
また、ほぼ全サービスと繋ぎ込みをしている関係上、トラフィック量も非常に多く、サービスが停止することによる影響が非常に大きいプロダクトとなっております。
DB移設を行う理由
データベースをクラウドに移行する理由は以下になります。
（１）会員サービス全体をクラウドに
以前までは、会員サービスすべてがオンプレミスのサーバー上で稼働していました。
クラウド化を目指していた理由としては、開発サイクルの高速化やスケールを容易するために実施していました。
会員サービスはプロダクトの性質上、他のサービスの影響を受けやすく、セールや動画の限定配信等による突発的なトラフィック上昇が起こりやすいプロダクトになっています。
オンプレミス環境だと突発的にアクセスが来た際に、すぐスケールアウトすることが難しいためクラウドへの移行を計画していました。
（２）見えにくいコストの見える化
オンプレミスの場合、DBを載せているマシンの費用だけでなく、そのマシンを配置しているデータセンターでの管理費やインフラチームの運用費など、見えにくいコストが多く存在します。
クラウドへ移行することで、コンソール上で利用サービスごとの料金を確認できるようになり、システムの利用傾向からリザーブドインスタンスによってコストを節約したりする選択肢も生まれてきます。
これらの恩恵を受けるため、クラウドへ移行したいという思いもありました。
移設方法
移設前構成はクラウドに配置しているアプリケーションが３種類のオンプレミス環境のMySQL DBに接続していました。
移設のおおまかな流れについては以下になります。作業内容の詳細や選定理由について解説します。
Amazon Aurora MySQLの構築
オンプレミス環境ではMySQL 5.6を利用していましたが、クラウド移設にあたりAmazon Aurora MySQL バージョン 2（MySQL 5.7互換）を採用しました。
理由としては、MySQL 5.6互換のバージョン１のサポート終了期限が間近であったことや、MySQL 5.7系でアプリケーションを動かしテストを実行したところ大きな問題なく成功できたことから採用しています。
Aurora MySQLのスペックについては、オンプレミスDBがさばいていたリクエスト量を元に一時的に選定を行い、現在動いている環境とは別に構築Aurora MySQLに接続したアプリケーションに対して負荷試験を実施することで選定を行いました。
また、アプリケーションからDBへ直接接続を行わず、Amazon RDS Proxy を利用して接続するような構成にしました。
RDS Proxyを採用した理由に可用性の向上が挙げられます。Aurora MySQLに限らず、フェイルオーバーが発生すると一時的にDBにアクセスできなくなりますが、RDS Proxyを採用することで最大66%ほどダウン時間を短縮させることができます。
会員システムがダウンするとDMMのサービスに影響してしまうため、もし発生した場合のダウンタイムを短くするために採用しました。
AWS Database Migration Serviceでデータ移行
データ移行作業では、AWS Database Migration Serviceを利用してデータのフルロード作業とレプリケーション設定を行いました。
選定理由としては、データ移行とレプリケーションが容易に設定・実行できることや、移行したデータが正しく移設できたどうかの検証機能もあることから採用しています。
AWS Database Migration Serviceについて
移設前までは会員に関するDBが３種類存在していました。今までの運用から３つに分けていることによるデメリットが大きくなってしまったため、1つに統一させる対応も実施を行いました。
方法としてはAWS Database Migration Serviceのテーブルマッピング機能を利用して、DB定義の変更を行いつつデータ移行を行っています。
テーブルマッピング機能について
AWS Database Migration Serviceにはデータ移行後検証機能がありますが、一部条件下では検証できない場合があります。
AWS DMS データ検証 制限事項
今回移設した一部テーブルで制限に引っかかってしまい、一部手動でデータ検証を行いました。大まかな手順は以下図となっております。
1. AWS Database Migration Serviceを用いてフルロード、レプリケーション、データ検証の実施
2. オンプレミスのSlaveバックアップ用のDBに対して、Masterからのレプリケーションを停止
データ移行元となるDBのレプリケーションを一時停止し、新規でデータが投入されない状態を作ります。この状態でAurora MySQLとオンプレミスの移行元に利用しているDBのデータ内容が一致していれば、データ移行が問題なく成功できたと判断できます。
3. 手順１で検証ができないテーブルのダンプファイルを各DBから取得し、オンプレミスとAuroraで差分が無いかを確認
作業用のEC2インスタンスを作成します。EC2インスタンス上でオンプレミスDBとAurora MySQLに対して検証が実施できないテーブルに対してMySQLのダンプファイルを取得し、ダンプファイルのデータ差分を確認することでデータ検証を実施しました。
4. 手順２で停止したレプリケーションを再開
アプリケーションのリクエスト切り替え
AWS Database Migration Serviceを用いたデータ移行作業後、アプリケーションのリクエスト切り替えを実施しました。以下が手順となります。
1. アプリケーションの更新系リクエストをメンテナンスに変更
切り替え作業では、データの更新処理を行うAPIのみメンテナンスを行った上で作業を実施しました。
切り替え作業時に更新処理がはいることでデータ不整合やエラー等が発生する可能性があるため、安全策を取ってメンテナンスを入れることにしました。
更新系のみのメンテナンス設定にした理由としては、会員基盤がDMMのほぼすべてのサービスが利用しており全部をメンテナンスにした際のユーザー損失が非常に大きかったこと、更新処理が止まっていれば想定されるトラブルが防げたことから更新系のみメンテナンス設定をするように変更しました。
2. 更新処理を含めた動作確認を実施
3. AWS Database Migration Serviceより新規でデータが更新されなくなったことを確認
レプリケーション遅延によるデータの連携漏れがないかの確認を実施しました。AWS Database Migration Serviceのコンソール上からレプリケーション状況を確認することができます。
AWS DMS タスクのモニタリング
4. リクエスト向け先をAurora向け先のアプリケーションに変更
発生した問題
今回の移設に当たりいくつか問題が発生しました。ここではいくつか紹介します。
- ５分ごとに発生した性能劣化
- データベースログの欠損
５分ごとに発生した性能劣化
DBの移設前に本番環境同等の検証環境を構築し、負荷試験を実施していたところ、30分おきにアプリケーションのAPIレイテンシーの悪化が確認され、最終的に5分おきに悪化するようになりました。
詳細を確認したところアプリケーションのAPIレイテンシーの悪化と同タイミングでDB側でのレイテンシー悪化も確認できたことから、おそらくDB側で問題が発生しているのではないかと考えました。
原因の詳細を確認するためスロークエリログを用いて負荷試験中の全クエリのログ確認を行ったところ、悪化するタイミングでは共通して「FLUSH AUDIT LOGS」や「FLUSH GENERAL LOGS」のFLUSHステートメントの発生が確認され、またFLUSHステートメントの実行時間分、各クエリでロックが発生していることも確認しました。
結論としては、FLUSHステートメント起因でロックが発生してしまい、アプリケーションで発行したクエリに影響していることが原因でした。
ログを保存する以上回避することができなかったことや性能悪化がごくわずかだったため、今回は悪化する事象を許容する形で対応を進めました。
データベースログの欠損
負荷試験を実施していたところ、ある時点を境に急激に Amazon CloudWatch の PutLogEvents 料金が上昇している事象が発生しました。
料金が上昇した原因を確認したところ、試験で利用していたAmazon Aurora MySQLで保存しているデータベースログを格納しているロググループに対して、「IncomingLogEvents」の数値が跳ね上がっていることを確認できました。
この期間中は長期間の負荷試験を実施していましたが、負荷量を変化させる等のオペレーションは特に行っていないことから、おそらくAmazon Aurora MySQLでなにか起きたのでは無いかと思い、調査とサポートケースへ問い合わせを行いました。
AWSのサポートケースに問い合わせを行ったところ、Amazon AuroraからAmazon CloudWatchへ送信しているログの流速が変化したためとの回答があり、実際のログを見ると連携されるログ数に変化があったことが判明しました。
リクエスト数は同じであるはずなのにログ数に違いがあることから、反映されるべきログが欠損している可能性を疑い調査を行ったところログが欠損していることを確認しました。
DBログ出力の挙動に関しては以下資料にて仕様が記載されています。今回のケースでは、Aurora MySQLが発行するログ量に対してCloudWatchに連携が間に合わず、連携前にファイルが削除されてしまったためログ欠損が起きていました。
この事象については、出力するログを削減することで問題の解決を行いました。
Amazon Aurora MySQLには「エラーログ」「スロークエリログ」「全般ログ」「監査ログ」の４つのログを保存することができます。その中でも「監査ログ」を保存していましたが、特に制限することなく全部のイベントを出力させるようにしていました。
今回の対応としては、すべてのログの中から個人情報を扱う観点より必要なログを出力するように制限をかける対応を実施しました。結果としてログ欠損を回避することに成功しています。
Aurora MySQLの監査ログについて
その他の案としては、Auroraの機能の１つである「データベースアクティビティストリーミング」を利用する方法や、Auroraのインスタンス数を増やして１台あたりのログ出力数を減らす方法が挙げられました。しかしこれらの案ではコストの面や保守面での負担増加に対して懸念点があったため、今回は採用しない方向としました。
今回は料金増加が原因でたまたま発覚しましたが、この事象が起きなければ気づいていなかったかもしれません。もしすでにAmazon Aurora MySQLを使われている方がいれば一度確認することをおすすめします。
まとめ
今回の記事ではデータベースをオンプレミスからクラウドへ移行するまでの方法と発生した問題について紹介しました。
この内容がデータベースをクラウド移行を考えている方や移設方法を検討している方のお役に立てれば幸いです。
宣伝
私たちのチームでは 4,101 万人（2023年2月時点）の DMM のアカウントを管理するサービスを運用しています。
国内トップレベルのトラフィックを求められる環境でのシステム設計、開発が行える環境です。
メンバーを募集しているので、興味があればぜひこちらからご応募お待ちしております
