いかにしてGitHubはSpokesでデータセンタ間レプリケーションを実現したか

GitHubのインフラストラクチャエンジニアであるMicheal Haggerty氏が、同社のレプリケーションシステムであるSpkesを遠隔地で動作させるために、GitHubが実施したエンジニアリングについて解説したブログを発表した。この中には、ラウンドトリップの削減、3フェーズコミットの導入、参照更新パフォーマンスの最適化など、さまざまな調整が含まれている。

レジリエンスの最大化とレイテンシの削減のため、GitHubはデータセンタ間でリポジトリを複製する必要がある、とHaggerty氏は説明する。障害が発生した場合には、別の地理的ロケーションでレプリカを使用可能にする必要がある。パフォーマンス向上のためには、ユーザに最も近いレプリカを提供しなければならない。

Spokesはこのようなユーザリポジトリのレプリケーションを実行し、同期を保証する目的でGitHubが開発したシステムである。プロキシとして機能し、このレプリケーションをGitアプリケーションのレベルで透過的に実行する。当初はレプリカを機能させるために近くに置く必要があったのだが、レイテンシの削減と参照更新の最適化により、この制限を段階的に克服したとHaggerty氏は説明する。

レプリカを広範囲にする上での最初の問題はレイテンシの増加であり、これがSpokesの維持可能なGit参照更新の最大速度を制限していた。大部分のユーザにとっては問題ないが、プッシュを重要な要件とするGitワークフローが一部にある、とHaggerty氏は指摘する。

そもそも、ほとんどのユーザは頻繁にプッシュしたりしません。しかしながら、7,000万近いリポジトリをホストしていれば、まったく予想もしないワークフローを使用するプロジェクトもあるものです。とんでもないユースケースでない限りGitHub Just Workを実現すべく、私たちは努力を重ねています。

氏はさらに、GitHub自身が多数の参照更新を生成している点も説明している。例えば、プルリクエストがマージあるいはリベース可能かをサイトが指示した場合、その判断は内部テストの実行結果に基づいて行われる。さらに、特定のブランチに対して多数のプルリクエストが存在して、そのブランチがプッシュされる場合には、このテストをすべてのプルリクエストに対して実行しなければならない。

レイテンシを克服した方法のひとつはネットワークのラウンドトリップの削減だった、とHaggerty氏は書いている。GitHubでは、レプリカの更新に3フェーズコミットを使用すると同時に、更新順序を保証するために分散ロックも使用している。この方法は4つのラウンドトリップを生成するが、それほど高価ではない、と氏は説明する。この方法には、ネットワークコールの完了を待つ間に処理が終了していることを保証する目的もある。

Haggerty氏はまた、GitHubのエンジニアたちがGitプロジェクトにオープンソースコントリビューションを行なったことも述べている。ひとつは参照更新のトランザクションで、参照更新を実行するレプリカの可用性に基づいたトランザクションのコミットあるいはロールバックを可能にする。もうひとつは、参照更新に関連する多数のオペレーション自体のスピードアップだ。

さらにHaggerty氏は、Spokesがレプリカを比較するために、それぞれのカスタムチェックサムを比較する方法について説明している。これが一致すれば、コンテントの内容は同じである。チェックサムはゼロからではなくインクリメンタルに計算されているため、計算コストはそれほど高くない。

帳簿(Booking keeping)の更新も統合して、より少数のトランザクションにしている。1件の処理に3分の1秒を要する場合があるため、ひとつのコミットから数百件の帳簿更新が発生するような状況ではこれが有効だ、とHaggerty氏は説明する。

実施した作業の詳細を記した完全なブログは、オンラインで閲覧可能だ。