Upgrade to Pro — share decks privately, control downloads, hide ads and more …

12年目を迎えた『ガールフレンド(仮)』におけるデータベースの負債解消への道のり【CAGC2024】

CyberAgent
March 08, 2024
13k

 12年目を迎えた『ガールフレンド(仮)』におけるデータベースの負債解消への道のり【CAGC2024】

本セッションではPC/スマートフォン向けゲーム『ガールフレンド(仮)』のデータベースの負債とその解消の道のりをご紹介します。
当ゲームではデータベースにMySQLを採用しており、長年の運用を続けていく中で下記のような課題が発生してきました。
「突発的なユーザー増加で更新負荷に耐えられない」
「データ容量が肥大化しパフォーマンスやコストの悪化」
これら課題に対しどのような手段で対応したのか、またその対応によって新たな負債が生まれることとなったその経緯と解決策の歴史を解説します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=m7XRYTxp

Copyright © CyberAgent, Inc.

CyberAgent

March 08, 2024
Tweet

More Decks by CyberAgent

Transcript

  1. 鬼海 雄太 @fat47 2 2012年  - Ameba事業本部のインフラエンジニア - ソーシャルゲームやコミュニティ系Webサービスを担当 2016年 -

    株式会社QualiArtsが子会社として設立される - 引き続き所属チームがインフラ関連を担当 2024年現在 - メディア事業の横断SREとしてAmebaブログ関連サービスなど兼務 株式会社サイバーエージェント  メディア統括本部 サービスリライアビリティグループ
  2. 現在の『ガールフレンド(仮)』の構成図簡略版 5 APP サーバ メインDB Source [MySQL] メインDB Replica メインDB

    Replica メインDB Replica [MySQL] APP サーバ APP Cache サーバ Cache サーバ Cache Load Balancer イベントDB Source [MySQL] メインDB Replica メインDB Replica イベントDB Replica [MySQL] ヒストリDB Source [MySQL] メインDB Replica メインDB Replica ヒストリDB Replica [MySQL] ユーザー (スマホ / PC ) レプリケーション プライベートクラウド
  3. 現在の『ガールフレンド(仮)』の構成図簡略版 6 APP サーバ メインDB Source [MySQL] メインDB Replica メインDB

    Replica メインDB Replica [MySQL] APP サーバ APP Cache サーバ Cache サーバ Cache Load Balancer イベントDB Source メインDB Replica メインDB Replica イベントDB Replica ヒストリDB Source メインDB Replica メインDB Replica ヒストリDB Replica ユーザー (スマホ / PC ) レプリケーション 本日お話するのはこのDBについて↑
  4. 14 レプリカにバイナリログイベント送信〜レプリカのリレーログ記録 SQL実行 プロセス データ バイナリログ BinlogDump スレッド ソース レプリカ

    I/O スレッド リレーログ SQL スレッド データ バイナリログ MySQLのレプリケーションによってレプリカにデータが反映される流れ
  5. 15 レプリカのSQLスレッドの処理が追いつかず遅延 SQL実行 プロセス データ バイナリログ BinlogDump スレッド ソース レプリカ

    I/O スレッド リレーログ SQL スレッド データ バイナリログ MySQLのレプリケーションによってレプリカにデータが反映される流れ
  6. 16 ※現在のMySQLではSQLスレッドの並列化オプションがあるが当時は存在せず SQL実行 プロセス データ バイナリログ BinlogDump スレッド Source Replica

    I/O スレッド リレーログ SQL スレッド データ バイナリログ SQL スレッド SQL スレッド MySQLのレプリケーションによってレプリカにデータが反映される流れ
  7. 19 レプリカを4つのグループに分けてフィルタリング設定 Source Replica Card 変則レプリケーション:レプリケーションフィルター Replica Gift Replica Other

    Replica All カード関連テーブルのみ ギフトボックス関連テーブルのみ カードとギフトボックス以外のテーブルのみ すべてのテーブル
  8. 変則レプリケーション導入後のメインDB構成 20 メインDB Source メインDB Replica メインDB Replica メインDB Replica

    「CARD」 APP サーバ APP サーバ APP Load Balancer ユーザー (スマホ / PC ) レプリケーション プライベートクラウド メインDB Replica メインDB Replica メインDB Replica 「GIFT」 メインDB Replica メインDB Replica メインDB Replica 「OTHER」 メインDB Replica 「ALL」 書き込みクエリー 読み取りクエリー
  9. 23 pt-online-schema-change(pt-osc)とは • Percona社が公開しているPercona Toolkitに含まれるツールの一つ • オンラインでMySQLのスキーマ変更が可能になる • 変則レプリケーション構成の前から使用していた replicate-ignore-tableを指定したレプリカがいる環境で障害発生

    • pt-osc実行後、レプリカ側でreplicate-ignore-tableで指定しているはずの テーブルで全件データコピーが始まり、レプリケーションが遅延し続けた • replicate-do-table指定のレプリカでは発生しない pt-online-schema-changeが利用できない
  10. 26 1. ソースで障害がおきてMHA Managerがダウンを検知 MySQL MHAでのフェイルオーバーの流れ Source Replica 1 Replica

    2 MHA Manager MHA Node MHA Node MHA Node レプリケーション 監視・昇格オペレーション
  11. 27 2. MHA Managerがレプリカ構成の再確認と新ソースの決定 Source Replica 1 (新Source) Replica 2

    MHA Manager MHA Node MHA Node MHA Node 監視・昇格オペレーション MySQL MHAでのフェイルオーバーの流れ
  12. 28 3. 各Nodeが全サーバからデータを収集して差分の修正適用 Source Replica 1 (新Source) Replica 2 MHA

    Manager MHA Node MHA Node MHA Node ・リレーログ解析 ・バイナリログ生成、適用 MySQL MHAでのフェイルオーバーの流れ
  13. 29 4. レプリケーション再設定実行 Replica 1 (新Source) Replica 2 MHA Manager

    MHA Node MHA Node 監視・昇格オペレーション レプリケーション MySQL MHAでのフェイルオーバーの流れ
  14. 31 • MHAはすべてのレプリカが同じフィルタリングルールである必要がある ◦ 変則レプリケーションでは利用不能 ◦ MHAを利用した即時フェイルオーバーができなくなった MySQL MHAを利用した冗長化ができない [error]

    Replication filtering check failed All slaves must have same replication filtering rules. Check SHOW SLAVE STATUS output and set my.cnf correctly. [warning] Bad Binlog/Replication filtering rules: 変則レプリケーション利用時のMHA起動のエラー文
  15. 32 全テーブルデータを持っている「Replica All」DBを手動で昇格させても、 非同期レプリケーションの為、他のReplicaとデータが揃っている保証がない Replica Card Replica Gift Replica Other

    新Source (旧Replica All) MySQL MHAがない状態でソースDBで障害が起きると 旧Sourceの ポジション: 101  まで実行済み 旧Sourceの ポジション: 100  まで実行済み 旧Sourceの ポジション: 102 まで実行済み 旧Sourceの ポジション: 101  まで実行済み レプリケーション
  16. 35 現ソースがダウンしても、次期ソースとその配下のレプリカ群は同期がとれている 35 Source Card Gift Other Replica All 旧Sourceの

    ポジション: 101  まで実行済み 旧Sourceの ポジション: 102  まで実行済み 待機系 Card 待機系 Gift 待機系 Other 待機系 All 旧Source ポジション: 101 相当 まで実行済み レプリケーション 多段レプリケーション構成によるデータコピーの回避
  17. 39 MySQLのストレージエンジンの一種 このストレージエンジンが設定されているテーブルは、更新クエリを受け付けるが データは破棄して更新しない これを各Replicaのグループごとに設定することでフィルタリングと同様の状態にした Blackhole Storage Engineとは Source Card

    カード関連テーブルのみInnoDB、 それ以外Blackhole Gift Other All ギフトボックス関連テーブルのみInnoDB、 それ以外Blackhole カードとギフトボックス関連テーブルのみInnoDB、 それ以外Blackhole すべてのテーブルがInnoDB レプリケーション