これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～

Copyright 2018 DELiGHTWORKS Inc. All Rights Reserved.
DELiGHTWORKS Inc.
これで怖くない！？大規模環境で体験するDB負荷対策
～垂直から水平の彼方へ～

自己紹介
名前：甲英明（Kabuto Hideaki）
これまで社内SEとして、基幹系、医療系システム、BtoB向けWEBサービス、BtoC向け音楽・
書籍コンテンツ配信サービスのインフラ設計～保守、運用など業界問わず携わる
2017年にディライトワークス株式会社でインフラエンジニアとして入社
海外向けコンテンツの立ち上げメンバーとしてインフラ周りを担当
現在は組織・プロジェクトを横断的にインフラ基盤の設計・構築・運用などを担っています

会社紹介（ディライトワークス）
2014/1/22に設立したまだ若い会社です。
従業員数は、380名(2018年7月現在派遣社員、業務委託含む)
「ただ純粋に、面白いゲームを創ろう。」
好評配信中のタイトルです。
Fate/Grand Order（好評配信中）
Fate/Grand Order Arcade（好評稼働中）
Fate/Grand Order VR feat.マシュ・キリエライト（好評配信中）
バンドやろうぜ！（好評配信中）
※企画・開発・運用を行っています。
他にも開発中のタイトルがございます。

アジェンダ
第一章なぜいま垂直分割から水平分割なのか？
第二章水平分割への移行課題は？
最終章どのように移行を実現できたのか？

Copyright 2018 DELiGHTWORKS Inc. All Rights Reserved. 5
第一章開演

なぜいま垂直分割から水平分割なのか？

まずは垂直分割の経緯から遡ってみます

それは突然の出来事でした...
2016年5月

これまで1台だったDBを分割すること
に...

Copyright 2018 DELiGHTWORKS Inc. All Rights Reserved.10
DB分割とは
Aテーブル
Bテーブル
Cテーブル
Dテーブル
Eテーブル
Fテーブル
Eテーブル
Fテーブル
Eテーブル
Fテーブル
・・・・
水平分割
（同テーブルのID単位による分割）
垂直分割
（テーブル単位による分割）

今回テーブルのデータが肥大化し、１台
のDBではインデックスがメモリに載らな
くなり、性能劣化が現れたため検討...

そのとき垂直か？水平か？
差し迫った負荷対策で、その時は十分な
検討時間がなかった...
実装と移行が比較的容易である選択を
行った...

結果、垂直分割を実施した...
まずは４分割
その後５分割、６分割
テーブル分割で当座をしのぐ日々...

そして再び機会が巡り...
2018年1月

テーブルの肥大化が進み
参照クエリのレイテンシが顕著に増加し始め
た...
slaveを追加し、対応を実施したが現状の
ペースでデータ量が増加した場合の懸念が
あった...

当時の垂直分割サーバ構成
IIS 8.5 (Amazon EC2 Windows Server 2012 R2)
.NET Framework 4.5 + ASP.NET MVC 5
c4.8xlarge x 45
MySQL 5.6 (Amazon Aurora)
db.r4.16xlarge x 18（master x 6、slave x 12）
Redis 2.8 (Amazon ElastiCache)
cache.r3.4xlarge x 2
Memcached (Amazon ElastiCache)
cache.r3.2xlarge

今回はまだ十分に検討する時間がある...
前回出来なかった水平分割の再検討いつ
やるの？
今でしょう！！

検討案として
・垂直と水平の組み合わせ
・すべてを水平に切り替える
この2択になった...

垂直構成の問題点として
1ユーザの処理が１つのトランザクショ
ンに載らないため、データ不整合が発生
しやすい...

また垂直と水平が混在している構成だと
垂直テーブルが肥大化する度に移行が必
要なる...
プログラムの複雑さも増し運用コストが
高くなる...

そうなると水平に一本化するのが必然
これまでの守りから、
今こそ攻めに転じる時！！

このようにして
DB水平分割プロジェクトが始動
することになった...

第一章終演

第二章開演

水平分割への移行課題は？

課題として
・何をキーとして分割を行うか？
・何分割する必要があるか？
・どのように移行を行うか？
・ダウンタイムはどの程度必要か？
・失敗した場合の切り戻しはどうするか？

内外問わず有識者からの意見を私たちは
求め検討した...
そして答えが...

何をキーとして分割を行うか？
答えは、ユーザID...
更新が1つのトランザクションに載るた
め、垂直分割時のデータ不整合問題を改
善することができる

何分割する必要があるか？
出来るだけ今回の分割作業で最後にした
い
答えは、20分割...

どのように移行を行うか？
最終的にこの2案で検討することに...
案①として
AWS Database Migration Service
（DMS）を利用する

DMSとは
データベースをすばやく安全に AWS に移行できま
す。移行中でもソースデータベースは完全に利用可
能な状態に保たれ、データベースを利用するアプリ
ケーションのダウンタイムは最小限に抑えられます。
とあり、Aurora間での移行も可能
https://aws.amazon.com/jp/dms/

どのように移行を行うか？
案②として、
ログデータを利用する

ログデータを利用する場合
アプリケーションから吐かれたlogを全
てkinesisで送りlambdaもしくは取り
込み専用のサーバを用意しデータを入れ
る

では最終的にどのように移行を行うか？
答えは、案①のDMSを利用する方針に決定
・ダウンタイムを極力減らす移行が可能
・ログデータはDB更新でエラー発生した際、
ログとDBに差異が発生するリスクがある

ダウンタイムはどの程度必要か？
答えは、数時間...
DMSでのライブマイグレーション後の切
替作業の時間を想定

失敗した場合の切り戻しは？
答えは、ダブルライト方式およびリカバ
リー環境をDMSで準備する
またXAトランザクションを検討する

ダブルライト方式とは
・移行完了後、まだ移行前DBを残す
・参照クエリは移行後DBを参照する
・更新クエリは両方のDBを更新する

XAトランザクションは
AWSよりAmazon Aurora MySQLではXAト
ランザクションはパフォーマンス面で影響が
出る可能性があるとの事で最終的には断念...
・Amazon Aurora MySQL での XA トランザクションの使用
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/AuroraMySQL.BestPra
ctices.html#AuroraMySQL.BestPractices.XA

このようにして
課題の洗い出しを行っていった...

移行課題を整理すると
・ユーザIDを分割IDとして利用する
・20分割で移行を行う
・DMSで移行を行う
・ダウンタイムは数時間（想定）
・切り戻しはダブルライト方式とDMSでリカバ
リー環境を準備する

第二章終演

最終章開演

どのように移行を実現できたのか？

このような構成で
DB水平分割の移行
を行いました...

DMS移行構成例
水平分割するDB ??台水平分割しないDB 1台
移行後移後前DMS
スレーブクラスター
マスタークラスター
DMS切り戻し
・・・・・・・・・・・・・・・・・・・・

移行プロセスとして
・スケジュールの確定
・DMSによる移行方法の確立
・負荷試験の実施
・リハーサルの実施
・本番移行を決行

スケジュールは
2018/7をターゲットに決定
移行準備期間は、2018/3～2018/7

DMSによる移行方法の確立について
まず水平分割化に伴い、全てのテーブル
を精査・再設計を実施した
そしてDMSのタスクによる移行を実施

DMSタスクとは
3つの主なフェーズで構成される
・既存のデータの全ロード（FullLoad）
・キャッシュされた変更の適用
・継続的なレプリケーション（CDC）
レプリケーションインスタンス上で実行されるタスク

移行手順案として
最終的にこの2案をベースに検討した...
・移行元DB Dump→リストア→DMSタスクでCDCレプリ
ケーション
・移行元DB→DMSタスクでFullLoad→CDCレプリケーション

AWS DMSを使用するには
・レプリケーションサーバーを作成する
・データストアに関する接続情報を持つソースエンドポイン
トとターゲットエンドポイントを作成する
・ソースデータストアとターゲットデータストアの間でデー
タを移行するには、1つ以上の移行タスクを作成する
ソースエンドポイント
ターゲットエンドポイント

最終的なDMS移行手順として
・移行先DBにスキーマ流し込み（index定義
無し）→ FullLoad →Index作成→CDCレプ
リケーション

なぜこの手順に
最初にスキーマだけを流しておくと、あとは
DMSが全て移行してくれる
Indexを事前に作成しておくと、FullLoadに時
間が掛かり移行が完了しない...

DMSのタスクで移行を行うには
当初ソースフィルタにてソースからターゲッ
トに指定した条件（ユーザID % 20）
でデータを移行を想定...

しかし想定外の事が
ソースフィルタの条件に関数がサポート
されていないため、フィルタ用カラムを
追加する必要が発生...

移行先DB指定（０~19）するカラム
を追加するには
FastDDL（lab mode）によるカラム追加を検討した...
問題なく数十億レコードのテーブルでも1秒以下で完了するこ
とができた
※本番でのlab mode利用は推薦されていない為、十分検証が必要です。
今回はメンテナンス時に、一時的に利用しました...

そして追加カラムに分割IDを挿入するに
は
稼働中に負荷を掛けないように時間を掛
けて分割IDを挿入する方法で実施

移行方法を整理すると
・事前にFastDDLで分割用カラムを追加
・カラムにソースフィルタの分割IDを追加
・DMSで移行を実施
移行先DBにスキーマ流し込み（index定義無し）→
FullLoad →Index作成→CDCレプリケーション

負荷試験の実施について
事前にこちらを準備する...
・本番環境同様の環境を準備する
・サーバアプリケーションの全APIを検証し、
シナリオ作成を準備する

詳細はこの後のLTで
そして負荷試験ツールにより、本番同様のシ
ナリオを実行する事で、早期に問題を発見→
修正を繰り返すことで開発期間の短縮および
信頼性を担保することが実現できた
また限界・耐久テストを実施し、正常動作の
処理上限値を確認できた

リハーサルの実施について
事前にリハーサル用のDMS環境を準備する...
ソースは本番DBクロスリージョンレプリカ

しかし高負荷を掛けた環境では
DMSのCDCレイテンシが増加し続ける事象
が発生した...
そのため同一リージョン（AZ）に別slave環
境を準備したが、それでも事象が改善され
ず...

原因は複数のタスクで一つのSlave環境の
Masterを参照させる場合、binlogスレッド
が複数起動し、mutexの奪い合いが発生し
た...
そのためbinlogの処理速度が落ち、結果レプ
リケーション遅延が発生することが判明...

最終的には、負荷を掛けない環境で、
DMSによる移行を実施することを判断し、
併せて各ソースのbinlog保持期間を長め
に設定した

次にDMS移行後の整合性確認は
当初、DMSタスクの検証機能を利用予定だった
が、フィルタを利用するとソースとターゲットで
データが異なるため、DMSの機能では検証でき
なくなるため、今回は利用できず...
・AWS DMS タスクの検証（制約事項を参照）
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Validating.html

そのため他の方法を検討することに
mysqldbcompareでソースDBとリカバリーDBとの比較に
代用しようとしたが、データチェックで差分があるとデータ
比較でインスタンスが高負荷となり接続できなくなる事象が
発生...
結局、行数チェックとスキーマの比較にのみ利用、データの
整合性についてはchecksum tableを利用した...

最後にDMS移行後の障害テストは
ダブルライト方式およびシングル切替時
の負荷を掛けた状況で、正常系・異常系
テストを実施し、想定通りの動作が確認
できた

本番移行について
準備
・本番slave環境、DMSタスク、レプリケー
ションインスタンス、ターゲットDB
・ソースDBの各テーブルに分割用カラムを追加
・カラムにユーザーIDの剰余IDを追加

移行メンテナンススケジュール
其の一
・夜間計画メンテナンスを実施
・DMSによる移行を実施
・ダブルライト方式に切替
其の二
・後日、データ整合性確認を実施
・問題なければダブルライトを停止

本番移行作業の手順は
夜間計画メンテナンスを実施し、DMSによ
る移行作業を決行...
移行後、ダブルライト方式に切替を実施
稼働中の動作および負荷を監視した...

移行後、後日に整合性確認を実施
しかし切り戻し環境でデータ不整合が見つ
かった...
すべてDMSによる移行後DB→切り戻しDB
へのFullLoad時のデータ移行漏れであった...

原因は、ソース・ターゲットの
wait_timeoutが短かった為（60秒）
timeoutしたリクエストがロストされてい
た...
今回は28800秒に変更し、切り戻し環境への
再移行を実施する事で問題が解消した

改めて整合性をすべて確認後、ダブルラ
イトを停止し、切替が完了した
最後に少し問題が発生したが、全ての移
行作業が完了！！

水平分割後サーバ構成
IIS 8.5 (Amazon EC2 Windows Server 2012 R2)
.NET Framework 4.5 + ASP.NET MVC 5
c4.8xlarge x 45
MySQL 5.6 (Amazon Aurora)
Redis 2.8 (Amazon ElastiCache)
cache.r3.4xlarge x 2
Memcached (Amazon ElastiCache)
cache.r3.2xlarge

まとめ
75
今回は十分な準備期間あり、負荷試験ツールの
存在やAWSサポート支援など受けれる環境と
揃っており、無事にやり切り事が出来ました！

「ただ純粋に、面白いゲームを創ろう。」
ここには誰もが挑戦する場があります！
ぜひ仲間となり一緒に挑戦しましょう！！

ご清聴ありがとうございました。

これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～

Similar to これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～ (20)

これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～