GitHub、肥大化したメインMySQLクラスタをVitessで機能単位に分割

単一巨大MySQLクラスタVitessによる垂直シャーディング

GitHub.comの中核データを支える巨大なMySQLクラスタが限界に近づき、Vitessの垂直シャーディング機能を使いテーブル群をサービス無停止で別クラスタへ移動した。

課題

単一クラスタmysql1が2019年時点で秒間95万クエリを処理し限界に近づいていた

アプローチ

スキーマドメインで論理分割しVitessの垂直シャーディングでクラスタを本番無停止で分離

効果

2019〜2021年で合計秒間120万クエリを処理する体制へ、ホスト負荷は平均半減

背景

GitHubは当初、Ruby on Railsと単一のMySQLデータベースで構築されていた。10年以上の成長を経て、メインクラスタ「mysql1」に依存が集中する構成は深刻な問題を生んでいた。2019年時点でmysql1は平均秒間95万クエリを処理していたが、スケーリング圧力は急速に高まっており、単一障害点となったこのクラスタの問題はユーザープロフィール、リポジトリ、Issue、プルリクエストなどコア機能全体に波及するリスクを抱えていた。

移行のプロセス

GitHubのデータベースエンジニアリングチームは段階的なアプローチを採用した。

関連テーブルを論理的にグループ化する「スキーマドメイン」を`db/schema-domains.yml`で定義し、例えばGist機能ではgists、gist_comments、starred_gistsを同一ドメインに属させた
SQLリンターを実装してクロスドメインクエリを開発段階で検出し、ActiveRecordに新メソッドを追加して`/* cross-schema-domain-query-exempted */`によるアノテーション対応も可能にした
データ移行では、MySQL用のスケーリングレイヤーであるVitessの垂直シャーディング機能と、独自開発した書き込みカットオーバープロセスを併用した
書き込みカットオーバープロセスはMySQLのGTIDを活用し、cluster_aからcluster_bへの切り替えをわずか数十ミリ秒で実現した

結果

2019年から2021年にかけて、テーブル群は複数クラスタへ分散された。

合計で秒間120万クエリ（レプリカが秒間112.5万クエリ、プライマリが秒間7.5万クエリ）を処理する体制になった
各ホストの平均負荷は半減した
データベース関連インシデントも大幅に減少した

学び

GitHubは信頼性を最優先し「退屈で実証済み」の技術を活用する方針を重視した。Vitess単一依存のリスクを避けるため複数の独立したツールを保有する戦略を採り、今後は水平シャーディングとの組み合わせで長期的なスケーラビリティを確保していくとしている。

2022-03-01

他の事例も見る