レビュー基盤のDBクラウド化対応.pdf

Transcript

1. © DMM © DMM CONFIDENTIAL PF第一開発部 ユーザーレビューグループ 松井 高宏 レビュー基盤の データベースのクラウド移行 2024-04-12
2. © DMM 1.ユーザーレビューの紹介
3. © DMM 3 💰 • レビューとは、ECサイトによくある商品の感想や評価です • ユーザーは商品購入前にレビューを参考にします • 商品購入時の意思決定に使われる為 、DMMの多くのサービスで利用されます DMMの多くのサービスで利用されます 商品購入を検討 レビューを参考にする ・動画・電書・同人 ・ゲーム・物販 ・レンタル・DMMTV ・FANZATV
4. © DMM 4 • 多くのサービスで利用される為、API全体でアクセス数は月6億〜あります • 過去には400~500msec程のレイテンシでもAPIを利用している事業部から 連絡が来ることもありました APIに大量アクセスと高速なレイテンシが求められます レビューAPI アクセス数（月） 1.レビュー情報一覧取得V2(コンテンツID指定) 3.2億 2.レビューランキング情報一覧取得 (V2) 1.2億 3.レビュー集計情報一覧取得V2（コンテンツID指定） 0.8億 4.物販商品末端用レビュー要素取得API（V2) 0.6億 5.同人商品末端用レビュー要素取得API 0.6億 6.レビュー情報一覧取得 （シーズンID指定） 0.5億 ・・・・・ ・・
5. © DMM 2.直近状況と課題
6. © DMM 6 • 2014年には3000件/月 → 2024年1月には6万件/月 近い投稿数 • 各サービスを色彩で視覚化 ◦ デジタルコンテンツ分野ではユーザーの関心が高まり、その活況を暖色系で表現 ◦ 物理メディアサービスは、市場の変化に合わせて新たな戦略を模索中で寒色系で表現 直近10年で10~20倍レビュー数が急増してます
7. © DMM 7 • DBはオンプレを利用しており、20年前のまま構成が変わってない状況です
 • 数々の対応しましたがもう限界です（Inf談） 結果、DBが毎日クラッシュするようになりました DB遅延に関する状況（ 2023-08） ：https://confl.arms.dmm.com/pages/viewpage.action?pageId=1620551201 数万件以上のエラー発生が 1ヶ月以上、継続
8. © DMM 何よりも優先で DBをクラウド移行 する
 今後サービスから負荷がかかっても問題ない基盤にする 
 

9. © DMM 4.プロジェクト成果と 振り返り
10. © DMM 成果：クラウド移行により安定した基盤を構築できました • AWS Aurora MySQLに移行 • MySQLバージョンも8.0、ストレージエンジン、文字コードも現在標準のものに一新 • AutoScalingにより負荷に応じて自在に対応できるようにしました Before After DBバージョン オンプレミス MySQL5.6 Aurora MySQL 8.0 構成 Master1台/ Slave6台 Master 1台 / Slave 3台 r6g.xlarge ストレージ エンジン MyISAM InnoDB 文字コード EUC-JP UTF8mb4 スケーリング Infに作業依頼し追加 AutoScaling
11. © DMM 11 • 品質　（Q) ：DBリプレイスによりAPIの レイテンシとエラー数の大幅改善 
 • コスト（C) ：自チームにかかる費用、 見積りより大幅に低く $52 (見積は$1400、全社RI適用でinstance費用が$0） 
 • 納期　（D) ：DesignDoc作成時、マイルストーン通り （DB Master切替：2024年3月）
 プロジェクト評価：QCD全て良い結果となりました Design Doc_マイルストーン APIレイテンシとエラー数 切替後 CostExplorer (過去3ヶ月） 切替後
12. © DMM 追加機能：絵文字投稿が可能となりました✌ • DB文字コードも現在標準(utf8)に改めた結果、絵文字投稿が可能になりました👍
 • レビューに深みと色彩を与え、DMMサービスを新たな次元に押し上げました👍
 レビュー投稿 商品レビューの閲覧 （動画以外は対応済）
13. © DMM 今回のプロジェクトにおける難しさとは？ 1. サービスの特性上、常時大量アクセスがある為、停止なく移行が必要な点 2. 新旧DB間の移行環境の差異が大きく、切替時に障害が発生しやすい点 対策 1.DMSによる無 停止移行の実現 DMSでは過去データ移行とリアルタイムデータの同期が同時に設 定可能。データ間で不整合が発生せず、システム停止なく移行が可 能 2.切替リスクの段 階的な軽減 a.整合性の検証 　　新旧DBのハッシュ値を常時比較 b.段階的移行 　　APIの分割リリース 　　DMSのテーブル別同期の機能による新 DBの段階移行 c.柔軟な切り替え対応 　　B/G・ローリングデプロイ 　　データ逆同期の仕組み 　　DB接続先情報の管理 発表時間が限られているので詳細は割愛しますがinsideもご確認ください https://inside.dmm.com/articles/user-review-database-migration/ 旧DB 新DB
14. © DMM プロジェクトまとめ • チーム全員の協力で早期にクラウドで安定した基盤に移行することができました • データ損失やシステム停止等の重大な障害なく、移行することができました ◦ ご対応と協力いただきました皆様、ありがとうございます！！ DMMの今後の成長に向けて基盤強化できました レビューグループでは高速で安定した基盤の構築を目指していきます
15. © DMM ご清聴ありがとうございました
16. © DMM その他の紹介
17. © DMM 想定外の事象 • 5000RPS問題 
 ◦ オンプレDBを直参照している事業部に対し、API利用に切り替えて頂きました。 
 ◦ その際に事業部の切替不具合によりAPIに既存RPSの10倍の負荷（5000RPS）が2時間近くかかりま した。ただスケールアウトの環境が整っていた為、これら高負荷にも耐えることができました 
 ▪ API Pod 3台 -> 20台 
 ▪ DB Slave 3台 -> 6台 
 • テーブルのIndexが効かない問題 
 ◦ DB環境の変更（ストレージエンジンの変更 （MyISAM -> InnoDB) ）により
 Auroraの切替後にAPIのレイテンシが軒並み悪化する事象が発生しました 
 ◦ こちらIndex追加することで、正常なレイテンシに戻すことができました 

18. © DMM 18 • 自チームのスクラムでは個々のタスクが 前後スプリントに与える影響は把握 できますが 長期プロジェクト、特に DB移行に与える将来的な影響が把握しにくい状況 となっています • 解決策 • タスク間の依存関係や影響を下記のように可視化 • クリティカルパスや将来 DB移行に対してどの程度遅延するか移行の Goalから逆算し、 タスク優先度、対応方針をチーム内で共有・日々検討 納期対策：クリティカルパスを意識し、タスク方針を日々検討
19. © DMM 19 2024年3月分の請求額 (CostExplorer) (AWS Support) お調べしましたところ、Organizations 内の別アカウントで保有されている RI が本アカウントに適用されている状況でございます。 オンデマンド DB インスタンスの利用量に RI が適用されており、 現時点ではインスタンスの料金が $0.00 であることをお客様側でも確認いただけることと存じます。 CostExplorer