【セミナー】「これで怖くない!?　大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～」垂直分割から水平分割への移行実現とその課題

アカツキとディライトワークスは、8月3日に合同で「FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会」を開催した。これはゲーム開発、運用エンジニアに向けての大規模サーバサイド技術勉強会である。
 
本稿では、ディライトワークスによる講演「これで怖くない!?　大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～」の内容についてレポートする。
 
なお本稿で紹介している講演は、「FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会」で2本目に実施されたものである。1本目の、アカツキのエンジニア長井昭裕氏による「大規模環境におけるRuby on Rails on AWSでの最適化事例」については、別途アップされた記事にてご確認いただきたい。
 
【関連記事】
・【セミナー】アカツキ「大規模環境におけるRuby on Rails on AWSでの最適化事例」実例とその対処から学ぶAWS
 

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

 
1本目講演を終えた長井氏に続き、ステージにはディライトワークスの甲英明氏が登壇した。
 

▲ディライトワークスのインフラエンジニア、甲英明氏。現在は組織・プロジェクトを横断的にインフラ基盤の設計・構築・運用を担っている。
 
まずは、甲氏が垂直分割をすることになった経緯から遡る。発端は2016年5月。これまで1台だったDB（Datebase）を分割することになったという。
 

▲DB分割の説明。テーブル単位で分割するものを垂直分割、同じテーブルのID単位で分割するものを水平分割という。
 
今回、テーブルのデータが肥大化し、1台のDBではインデックスがメモリに載らなくなり、性能劣化が現れたため検討することになった。差し迫った負荷対策で、その時は水平か垂直か充分な検討時間を確保できなかったという。そこで、その時にとれる最善の策として、実装と移行が比較的容易である選択を行った。
 
その結果、垂直分割を実施。まずは4分割。その後5分割、6分割……。テーブル分割によって当座の負荷をしのぐという日々を過ごしていたとのこと。
 
それから時は流れ2018年1月。テーブルの肥大化が進み、参照クエリのレイテンシが顕著に増加し始めた。slaveを追加し対応を実施したが、現状のペースでデータ量が増加した場合、これ以上どう対策をしていくのかの懸念があったという。
 

▲当時の垂直分割サーバ構成。特にDBに関してはAmazon Auroraを使っていた。db.r4.16xlargeを18台（master6台、slave12台）で、かなり力業でねじ伏せている状態。
 
ただし今回は、前回と異なって充分に検討する時間があった。そこで、前回は出来なかった水平分割の再検討を実施することになった。この時、下記の2択が検討案として挙がったという。
 
・垂直と水平の組み合わせ
・すべてを水平に切り替える
 
垂直構成の問題点として、1ユーザーの処理が1つのトランザクションに載らないため、どうしてもデータ不整合が発生しやすい環境にあるというものがある。また、垂直と水平が混在している構成だと、垂直テーブルが肥大化する度に移行が必要となる。また、プログラムの複雑さも増し、その結果運用コストが高くなるというデメリットもあった。
 
そうなると答えはひとつ。水平に一本化するのが必然であった。これまでの守りから、いまこそ攻めに転じる時！　と決意したと甲氏。こうして、DB水平分割プロジェクトが始動することになった。
 

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

 
水平分割への移行課題として、下記のものが挙げられた。
 

▲これらの課題に対して、内外問わず有識者の意見を求めて検討が重ねられた。
 
まず、何をキーとして分割を行うか。これに対して出された答えは、ユーザーID。更新が1つのトランザクションに載るため、垂直分割時のデータ不整合問題を改善することが出来る。
 
次に、何分割する必要があるか。可能ならば、今回の分割作業で最後にしたいと考えて出した答えは、20分割であった。これまでの実績を見て、20分割であればある程度は大丈夫であろうという結論が導き出されたのだ。
 
どのように移行を行うかという問題に対しては、最終的に下記の2案で検討されることになった。
 
・AWS Datebase Migration Service（DMS）を利用する
・ログデータを利用する
 
DMSは公式の説明を引用すると「データベースをすばやく安全に、AWSに移行できる。移行中でもソースデータベースは完全に利用可能な状態に保たれ、データベースを利用するアプリケーションのダウンタイムは最小限に抑えられる」といったサービス。Aurora間での移行も可能である。
 
ログデータを利用する場合、アプリケーションから吐かれたすべてのlogをすべてkinesisで送り、lambdaもしくは取り込み専用のサーバを用意してデータを取り込む。
 
最終的に、1案目である「DMSを利用する」方針に決定した。決定理由としては、ダウンタイムを極力減らす移行が可能であるということ。また、ログデータはDB更新でエラーが発生した際、ログとDBに差異が発生するリスクがあるということ。
 
ダウンタイムはどの程度必要か、という問題に対して想定した答えは「数時間」である。DMSでのライブマイグレーション後の切り替え作業の時間を想定したとのこと。
 
最後に、失敗した場合の切り戻しについては、ダブルライト方式およびリカバリー環境をDMSで準備。また、XAトランザクションを検討するということになった。
 

▲ダブルライト方式とはどのようなものかの解説。
 
検討中であったXAトランザクションは、Amazon Aurora MySQLではXAトランザクションはパフォーマンス面で影響が出る可能性があるため、最終的に断念するに至ったという。
 

▲移行課題を整理。このように課題の洗い出しを行っていった。
 

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

 
DBの水平分割の移行は、下記のような構成で行われた。
 

▲本番のマスタークラスタの横でスレーブのクラスタを作る。それをDMSで参照し、DMSのタスクで新しい水平分割用DBを作成する。作成したDBをさらにDMSで切り戻し用のDBとして垂直の環境を作る。
 

▲移行プロセス。
 
スケジュールは、2018年7月をターゲットに決定。これは『Fate/Grand Order』3周年のタイミングである。この時に想定される負荷に耐えられるような環境を作ることを目標にした。移行準備期間は2018年3月～7月。
 
DMSによる移行方法の確立について。まずは水平分割化に伴い、すべてのテーブルを精査して、再設計を実施した。それを基に、DMSタスクによる移行を実施した。
 

▲DMSタスクの解説。
 
移行手順案は、最終的に下記の2案をベースに検討が行われた。
 
・移行元DB Dump→リストア→DMSタスクでCDCレプリケーション
・移行元DB→DMSタスクでFullLoad→CDCレプリケーション
 

▲AWS DMSを使用する手順。
 
最終的なDMS移行手順は、少し変更が加えられて下記のようになった。
 
・移行先DBにスキーマ流し込み（index定義無し）→FullLoad→index作成→CDCレプリケーション
 
なぜこの手順になったかというと、最初にスキーマだけを流しておくとあとはDMSがすべて移行してくれるのだという。indexを事前に作成しておくと、FullLoadに時間がかかり移行が完了しないという問題もあった。
 
DMSのタスクで移行を行うためには、当初ソースフィルタにてソースからターゲットに指定した条件（ユーザーID ％ 20）でデータ移行を想定していた。しかし、想定外のことがあった。DMSの仕様上、ソースフィルタの条件に関数がサポートされていないために泣く泣く断念。フィルタ用カラムを追加する必要が発生したのだ。
 

▲フィルタ用カラムを追加するため、具体的に行ったこと。
 
そして追加カラムに分割IDを挿入するには、稼働中に負荷をかけないように時間をかけて分割IDを挿入する方法を実施した。
 

▲移行方法のまとめ。
 
次に、負荷試験の実施について。負荷試験前に、下記の準備を行った。
 
・本番環境同様の環境を準備する
・サーバアプリケーションの全APIを検証し、シナリオ作成を準備する
 
負荷試験ツールにより本番同様のシナリオを実行することで、早期に問題を発見、修正を繰り替えすことで開発期間の短縮および信頼性を担保することが実現した。またその環境で限界、耐久テストを実施し、正常動作の処理上限値を確認できた。
 
それを基にしてリハーサルを実施。事前にリハーサル用のDMS環境の準備を実施した。ソースは、本番DBのクロスリージョンレプリカを使用している。しかし、高負荷をかけた環境では、DMSのCDCレイテンシが増加し続ける事象が発生した。そのため、同一リージョン（AZ）に別slave環境を準備する対策を施した。それでも事象は改善されず、調査を行うことになった。
 
その結果、原因は複数のタスクで1つのslave環境のMasterを参照させる場合、binlogスレッドが複数起動し、mutexの奪い合いが発生したことにあった。そのためbinlogの処理速度が落ち、結果レプリケーション遅延が発生することが判明した。最終的には、負荷をかけない環境でDMSによる移行を実施することを判断し、併せて各ソースのbinlog保持期間を長めに設定したという。
 
次に、DMS移行後の整合性確認について。当初、DMSタスクの検証機能を利用する予定だったが、フィルタを利用するとソースとターゲットでデータが異なるため、DMSの機能では検証できなくなる。このような理由から、今回は利用できなかったとのこと。
 

▲上記のように、他の方法の検討が行われた。
 
最後に、DMS移行後の障害テストはダブルライト方式およびシングルに切り替えた時の負荷をかけた状況で、正常系・異常系テストを実施。想定通りの動作が確認できた。
 
これらを基に、本番移行が実施されることとなった。本番移行の準備は、下記の通り。
 
・本番slave環境、DMSタスク、レプリケーションインスタンス、ターゲットDB
・ソースDBの各テーブルに分割用カラムを追加
・カラムにユーザーIDの剰余IDを追加
 

▲移行メンテナンススケジュール。
 
本番移行作業の手順は、下記の通り。
 
・夜間計画メンテナンスを実施し、DMSによる移行作業を決行
・移行後、ダブルライト方式に切り替えを実施。稼働中の動作および負荷を監視した
 
移行後、後日に整合性確認を実施したところ、切り戻し環境でデータ不整合が見つかった。DMSによる移行後DBと切り戻し用DBへのFullLoad時のデータ移行で漏れが発生していたのだ。その原因は、ソースとターゲットのwait_timeoutがデフォルトの60秒になっていたため、timeoutしたリクエストがロストされていた。そこで対策として、28800秒に変更。切り戻し環境への再移行を実施することで問題は解決した。
 
改めて整合性をすべて確認後、ダブルライトを停止し、切り替えが完了した。最後に少し問題が発生したが、これですべての移行作業が完了した。
 

▲水平分割後のサーバ構成。
 
甲氏は、今回は充分な準備期間があり、負荷試験ツールの存在やAWSサポート支援などが受けられる環境が揃っていたため、無事にやりきることが出来たとまとめた。
 
本勉強会はこのあとも、希望者によるLT（5分プレゼン）や懇親会が行われ、多くのエンジニアが情報交換と交流を活発に行った。懇親会では名物のカレーなどが振る舞われ、参加者を楽しませた。
 

▲アカツキのイベント名物カレー。このカレーを楽しみにしている参加者も多い。柔らかいチキンと本格的なスパイスの香りが楽しめるが辛すぎず、非常においしいカレーであった。 

 


(C)Akatsuki Inc.