Amazon Web Services ブログ
DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現
DMM.com は動画配信事業とオンラインゲーム事業、FX 等の金融サービスを主力として、オンライン英会話サービスなど 60 以上のサービスを展開している企業です。DMM.com では、オンプレミスの MySQL で稼働していたユーザーレビュー機能を、Aurora MySQL に移行しています。データの移行は AWS Database Migration Service (DMS) を使用してダウンタイムを最小限に抑えつつ、移行元への逆同期や SageMaker を使用したデータ検証の仕組みなど、様々な工夫をしながら移行を成功させることができました。本ブログでは、DMM.com でオンプレミスの MySQL から Amazon Aurora MySQL へ移行した際に直面した課題やその工夫についてご紹介いたします。
システム概要とデータベースの課題
DMM.com では、DMM TV や DMM ブックスなど様々なサービスを提供しています。そのサービスの多くはユーザーレビュー機能があり、例えば DMM TV では視聴した動画の評価を投稿する際に使われています。このユーザーレビュー機能のサーバーアプリケーションは AWS で稼働していましたが、データベースはオンプレミスの MySQL を採用していました。長年このような構成で運用されていましたが、幾つかの課題を抱えている状況でした。
1. データベースの運用負荷の増加
当該環境では冗長化のために Master High Availability Manager and tools for MySQL (MHA) というクラスタウェアを採用していました。MHA では、2 台のプライマリサーバーと 5 台のセカンダリサーバー、1 台の MHA マネージャーサーバーの合計 8 台でデータベースを冗長化していました。ユーザーレビュー機能は年々多くのシステムから利用されるようになっていて、月間 3 億リクエストを超える状況になっていました。そして、それに伴うスケールアップやスケールアウトなどが頻繁に発生していましたがこのような作業の難易度が高く、準備のために多くの作業工数が必要でした。また、データベースサーバーの障害でフェイルオーバーが発生した時に、スプリットブレインによるデータの不整合が発生するといった事象も出ており、リペア後のパフォーマンス遅延なども発生してしまうなど、エラーへの対処に多くの時間が割かれていました。
2. 旧バージョンによる不具合の発生
ユーザーレビューの機能は 20 年以上オンプレミスで稼働していました。そのため、MySQL のバージョンも 5.6 と古く、保守期限が迫っていました。さらに、テーブルのクラッシュによって読み取りエラーが発生するといった、最新版では改修されているような問題が頻繁に発生していました。
3. リアクティブな障害対応
障害が発生した際に、その障害を検知できないことも課題になっていました。上記のような問題もあり、多い日には 1 日 1 万件以上のアラートが発生していました。そのため、本当に対処が必要なアラートに気づくことができず、事業部や顧客からのクレームや問い合わせによって気づいて対処する、といったリアクティブな対応になってしまっていました。
移行先の検討
これらの課題を改善するために、2023 年 11 月から移行プロジェクトが開始されました。上記の課題が解決できるかどうかはもちろん、可用性やバックトラックなどの独自機能の多さ、DMM.com 社内での実績などを考慮した結果、移行先を Aurora MySQL に決定しました。ただ、Aurora MySQL への移行に向けては、クリアすべき課題がいくつかありました。
1. Aurora MySQL への移行による影響
Aurora MySQL への移行に伴い、MySQL のバージョンを 5.6 から 8.0 にアップグレードする必要がありました。また、MySQL のストレージエンジンを MyISAM から InnoDB に、文字コードを EUC からデフォルトの UTF8 に、タイムゾーンも JST から UTC に変更する必要がありました。
これらの変更点について、多くの時間を使って影響を確認し対処方法を検討していきました。パフォーマンスが劣化するなど影響度が高いクエリについては、一つずつチューニングを実施して対処していきました。また、マージテーブルのような InnoDB では対応していないテーブルに対するクエリも実行されていたため、回避策を検討して修正を進めました。
2. 接続元不明なシステムへの対処
長年この機能を運用していく中で、様々なシステムがこのデータベースにアクセスしている状態でした。この為、Aurora MySQL への移行に合わせて API 化を進める方針でした。どのようなシステムからアクセスしているのかについては、サービス側に協力を依頼してアクセス元を特定していきましたが、アクセス元を全て特定できたかを確認することができず移行時にシステムに影響を与えてしまうリスクがありました。これに対処するため、本番切り替え後に数ヶ月間、 DMS でオンプレミスの MySQL に逆同期を実施することにしました。これにより、Aurora MySQL に移行した後もオンプレミスの MySQL にアクセスしているシステムへの影響を最小限に抑えつつ、アクセス元を特定するような仕組みを構築することができました。
オンプレミスの MySQL には 3 TB のデータがあり、ダウンタイムを抑えて Aurora MySQL に移行する必要がありました。また、移行後の切り戻しを想定した再同期の仕組みを構築する必要があり、下位互換性の問題から MySQL のレプリケーションが使えなかった為、今回の移行では DMS を採用することになりました。DMS を使って実際のデータ移行をしたところ、絵文字や常用漢字ではない文字など、一部の文字で文字化けする事象が発生したため、対処が必要でした。DMS にはデータ検証という移行元と移行先でデータに差異がないかを検知する機能がありましたが、文字化けした文字自体を修正することはできず、文字化けが発生したレコードも大量であったため、DMS のデータ検証機能の採用は現実的ではありませんでした。このような課題を解消する方法を検討した結果、Amazon SageMaker Notebook を採用しました。具体的には、オンプレミスの MySQL から新環境の Aurora MySQL へ、データを DMS のフルロード + CDC で移行していますが、この DMS フルロードタスクの停止後に SageMaker Notebook の Jupyter Notebook から両データベースのレコードを検証する仕組みを実装しました。この仕組みでは、それぞれのデータベースのレコードを pandas のデータフレームに格納して結合し、レコード単位でそれぞれのレビューテキストのハッシュ値を生成して比較します。不一致がある場合には必要に応じて移行元、もしくは移行先のレビューテキストを更新します。その際に修正の内容を差分リストとして記録し、それ以降の更新で利用します。最初に既存データで検証と修正を行い、その後 Python スクリプトに変換して SageMaker Notebook で定期実行できるようにしました。これにより、新たに発生する差異に対して継続的なチェックを実施しました。長期間運用することでほとんどの文字化けを修正することができ、実際の移行時には文字化けの問題がほとんど発生しないレベルで移行することができる状態になりました。
データベース移行とその効果
このような課題に対応しつつ、アプリケーションやデータ移行の入念なテストを実施した後、2024 年 3 月に本番移行を実施しました。DMS による差分同期により、ダウンタイムがほとんど発生しない状態で切り替えられました。移行後に SQL のパフォーマンス問題はありましたがチューニングを実施して対処し、結果として大きな問題はなく移行を完了しました。現在も安定した運用を実現できています。
そして、今回の Aurora MySQL への移行で得た効果は以下の 3 つでした。
1. データベースの運用負荷の低減
Aurora MySQL への移行後、オンプレミスで発生していたスケールアップ時の作業工数がほぼなくなり、スケールアップまでのリードタイムも大きく改善しました。また、オンプレミスで発生していたデータベースサーバーの障害も発生しなくなりました。その結果、多い日には 1 日 1 万件以上発生していた API のエラーやタイムアウトエラーによるアラートが、ほぼゼロになるまで減少しました。
2. サービス品質の向上
アラート数が激減したことにより、事業部や顧客からの指摘で気づくようなこともなくなり、エラーに対してプロアクティブに対応できるようになりました。また、老朽化したサーバーからの移行ということもあり、パフォーマンスも劇的に向上しました。API レイテンシーは全体で 50%、最も利用頻度の高い 3 つの API では最大 70% の改善が見られ、レビュー投稿が遅いといったクレームがなくなりました。
3. コスト削減
オンプレミスでは、8 台のデータベースサーバーで運用していましたが、Aurora MySQL への移行後は最終的に 3 台構成となりました。移行直後は、安定稼働を優先して Aurora MySQL を6 台で構成していましたが、Performance Insights などを使用してチューニングしたり、負荷が増加した時に Auto Scaling でスケールアウトする仕組みを採用して最適化を進めました。これにより、より少ない台数での稼働が可能になり、移行前の想定より 96% のコスト削減を実現できました (Reserved Instanceの採用も含む)。
一方で、Aurora MySQL の課題として、アップグレード時のダウンタイムをあげていました。今後、Aurora MySQL のバージョンのアップグレードに向けて、ダウンタイムを削減するアップグレード方式を検討していくとのことでした。
最後に
DMM.com では、Aurora MySQL への移行によって、コスト削減とサービス品質の向上を同時に実現することができました。
今回の移行の効果について、合同会社 DMM .com プラットフォーム第一開発部ユーザーレビューグループの松井氏、室木氏は、以下のように振り返っています。
“オンプレミス時代では、1 日 1 万件のエラーが発生していて、休日に呼び出されることもあり、常に不安で心理的な負担が大きくなっていました。しかし、Aurora MySQL に移行したことでそのようなストレスがなくなりました。技術的な問題が解消されたことで、サービスの安定性が大幅に向上し、運用面での負担が軽減されました。” (松井氏)
“Aurora MySQL への移行後、「レビュー投稿が遅い、できない」といった技術的な問い合わせがなくなり、UI や書き込み内容のようなサービスそのものの問い合わせが増えるという状況に変わりました。技術的な足かせがなくなったことで、サービス拡張や新しいチャレンジにリソースを向けられるようになったことが、移行による大きなメリットです。” (室木氏)
今後については、Aurora MySQL 移行でできた時間を使って、AI を活用してユーザーレビュー機能のサービス品質向上を進めていく予定とのことでした。