https://developersblog.dmm.com/entry/2024/01/23/110000

1.はじめに

プラットフォーム開発本部ユーザーレビューグループの松井です。
私はDMM.comのユーザーレビュー基盤の開発でテックリードをしています。
今回は、レビュー基盤のデータベースのクラウド移行についてお話しします。

2.現状と課題

現在AWS環境で稼働するレビュー基盤ですが、20年以上もの長期にわたりオンプレミス環境で稼働するデータベース（以下DB）も存在しています。

長年の運用に伴い、DBでは次のようなさまざまな問題を抱えていました。

古いバージョン「MySQL 5.6」の利用
サポート期限の終了に伴い、「MySQL 8.0」への大幅な更新が必須
ストレージエンジン「MyISAM」の不具合
使用頻度が年々高くなったことでソートアボート等のエラーがほぼ毎日発生
リソース不足の発生
使用頻度が年々高くなると同時にCPU、容量等のリソース不足が発生
（クエリ発行数が膨大（月10億クエリ〜）で5年前の数倍の量）
システム影響範囲の複雑化
レビュー基盤ではAPIを通じてデータアクセスを標準化しているが、API非対応のシステムや各部署からのDB直参照のクエリがある。そのため各システムへの影響範囲が複雑化している

昨今DB障害の問題が表面化し、急遽、DBをリプレイスすることが決定しました。

3.移行環境

新環境のDBとして「Amazon Aurora MySQL 3.0.4」を選択しました。次のような選定理由が挙げられます。

システム連携の容易さ
レビュー基盤の大部分がAWS環境で構築されていたため、他システムとの連携も容易であったこと
MySQL最新バージョンの互換性
Auroraは最新のMySQL 8.0に対する互換性が高いだけでなく、MySQL 8.0のLTSバージョンである「Aurora MySQL 3.0.4」を提供していること
スケーラビリティ
柔軟なスケールアウト/アップができ、リソース不足の問題も同時に解決できそうであったこと

4.移行方法

4.1 binlog同期

DB移行のプロジェクトでは「既存システムのダウンタイムをいかに抑え、新DBに移行するか」 が重視すべき考慮事項です。

そのため一般的には、新旧のDB間で事前にデータ同期させ、既存システムを新DBへ切り替える方法が採用されます。

今回は次の事例の中の「binlog同期」という方法を採用しました。

この方法は、旧DBの変更ログを新DBに適用する方法で、開発工数の削減とリアルタイム同期が可能です。

1.ダブルライト	2.トリガー同期
アプリケーションから新旧DBにデータを同時に書き込みする方法・アプリケーションの改修やトランザクションの整合性維持が必要	旧DBにトリガーを設定し、新DBと同期する方法・トリガーにより旧DBの負荷が高くなる傾向にある。トリガーの開発が必要、CDC（変更データキャプチャ）レプリケーションの一手法

3.定期同期	*4.binlog同期（今回採用）**
旧DBから新DBへ一定の間隔でデータをコピーする方法・スクリプト開発が必要で同期先にはタイムラグが発生する	旧DBの変更ログ（SQL操作ログ等）を新DBに適用しデータをコピーする方法・DBをリアルタイムで最新の状態に保てる。システム改修が不要、CDC（変更データキャプチャ）レプリケーションの一手法

4.2 多段レプリケーション

binlog同期を採用する場合、新旧DB間でバイナリログの互換性を保つ必要があります。異なるバージョンのDB間で直接レプリケーションを行うと問題が生じるためです。

また旧DBへ直接アップグレードする際には既存運用の停止が必要で、仮に更新が失敗した場合にはシステムダウンのリスクを伴うことから「多段レプリケーション」という手法を採用しました。

この手法は、旧DBのクローンを段階的に生成し（レプリケーション）、アップグレードすることで安定稼働を目指します。

次の図のようにMySQL5.6から始め、5.7を経由し、最終的には8.0.28までアップグレードする方法で、各ステップでレプリケーションエラーを抑制します。

5.移行三大リスク

DB移行プロジェクトでは、「データ整合性の問題」「同期のダウンタイムの問題」「システム切替のリスク」 の３つの主要なリスクが存在します。この点について説明します。

5.1 データ整合性の問題

データ同期の際に新旧DBの環境の違いからさまざまなエラーが発生し、これらの対応を一つずつ進めてきました。

AuroraではInnoDBおよびUTF8が使用されますが、現在のDBにおいては標準の環境のためこちらに合わせる必要があります。

◾️主要な環境差異

	旧DB	新DB
バージョン	MySQL5.6 (GA日：2013年2月)	Aurora MySQL 3.0.4（GA日：2023年07月）
ストレージエンジン	MyISAM	InnoDB
文字コード	EUC-JP	UTF8mb4
Timezone	JST	UTC

◾️エラー発生の事例
・ストレージエンジンの差異によりマージテーブルに対するクエリが新DBに発行されない
・タイムゾーンの差異により新DBで時刻ずれが発生する
・文字コードの差異により新DBの環境で文字化けが発生する (特にレビュー基盤では絵文字、常用漢字以外の日本語も使われるケースが多く発生しやすい）
・特殊構文のためREPLACE等の構文が新DBに反映されない

5.2 同期のダウンタイムの問題

実は、前述したデータ同期作業においても、通常は一時的なシステム停止を伴います。更新頻度の高いDBにおいては新旧DBで最新状態を完全に一致させる際に、旧DBの更新を一時停止(*1)する必要があります。

これらの停止作業によりレビュー投稿の機能が使用できなくなるため、関連部署との調整に多大な労力が必要です。

ここまで労力を使い同期をやり直すことになっては大問題です。

5.3 システム切替のリスク

データ同期後に各種アプリケーションの接続先を新DBに順次変更しますが、その際に新DBに不具合や障害が発生した場合、アプリケーション側で接続先をロールバックする必要があります。

ここで注意すべきこととしては、移行の複雑性がある場合(*2)、ロールバックが容易ではなくなることがあります。

この部分もできる限り柔軟に対応できないといけません。

6.移行リスクへの対策

そのため、三大リスクに対して各対策を講じました。

対策イメージ

1.データ整合性の問題▶️ 「新旧DBの整合性チェック」

Amazon SageMakerのNoteBook Instance内にスクリプトを配置し、データの整合性を定期監視します。新旧DBのレコード・カラムからハッシュ値を生成し同期差分があれば、その箇所を通知します。

Jupyter NoteBookにより更なるデータ分析と原因特定も可能です。

またSageMakerは本来機械学習向けのサービスですが、新旧DBに大きな環境差異があり高度なデータ整合性が要求されたことから利用しています。(*3)

2.同期のダウンタイムの問題▶️ 「DMSによるダウンタイムなし移行の実現」

AWS Data Migration Serviceで過去データから最新状態の同期を一括で実施します。このシステムは旧DBの更新を停止させずにダウンタイムなしの移行を実現することが可能です。(*4)

また同期が中断した場合においても中断ポイントから再開し、最新状態まで旧DBの更新を停止せずに復帰させることが可能です。

3.システム切替のリスク▶️ 「DB接続先変更の容易化」

各種アプリケーションを改修し、新旧DB間での接続先を容易に切り替えられるようにします。

基本はAPIを通じてDBをアクセスする改修をしますが、API非対応のアプリケーションについても新旧DB間での迅速なロールバック機能(*5)を実装します。

7.アジャイル移行アプローチの実現

これら３つを導入したことで、必要に応じていつでも１からデータ移行とシステム切替が可能 となりました。

つまり何度でも移行プロセスにトライできる仕組み、「アジャイル移行アプローチ」 を我々のプロジェクトで実現しました。

このように対応することでまず新DBに移行し、システムを切り替え、新規の問題に対して迅速に対処するといった継続的な改善を可能としました。

今回これらアプローチの選択理由として「2.現状と課題」に記載したようなDBエラーが収束しなかったため、「何よりもまずDBを優先して入れ替える」 という要件があったためです。(*6)

まだ実施途中ではありますが、完全移行された暁には当初のDBが抱えていた問題を一掃できるものと思っています。

8.まとめ

いかがだったでしょうか。

多くの企業にとって、長年運用してきたDBのクラウド移行は共通課題であり、なかでも「データの整合性」「同期のダウンタイム」「システム切替」 といった共通リスクに対する一つの方法論を、今回我々のチームで行ったDB移行の事例を踏まえてご紹介してきました。

少しでも参考になれば幸いです。

著者プロフィール ：松井高宏 DMM.comプラットフォーム開発本部のエンジニア。ユーザーレビューグループのチームリーダー兼テックリードとして、月間数十万件の投稿を処理するレビュープラットフォームの開発・運用を実施。8年以上の経験を活かし、最新技術を駆使しDMMの顧客体験向上に貢献している。