GitHubは数ヶ月前、時折発生していたプッシュ障害の原因を特定し、修正方法を確認するために、Project Cyclopを立ち上げた。その結果、原因がひとつではないことが明らかになったのだが、慎重な分析の成果として、GitHubによれば、プッシュトラフィックを最低でも1桁改善する変更がいくつか確認された。
GitHubといえば、その運用の信頼性の高さで広く知られているのだが、どのようなシステムであっても、何らかの制限や、特定の条件下におけるパフォーマンス不足は存在するものだ、とGitHubのエンジニアScott Arbeit氏は記している。GitHubにおけるこの問題は、リポジトリのプッシュにおいて時折障害が発生することによって明らかになった。特に、大規模なモノリポジトリにおいて、文字通り数千の開発者が同じリポジトリを毎日更新するような場合にそれが顕著だった。
GitHubのエンジニアたちが改善点として最初に特定したのは、リポジトリのメンテナンスだ。これはリポジトリ上で周期的に実行される多数のスクリプトで、パックファイルのアップデートやクローン操作の改善、重複データの排除などを行う。大規模なモノリポジトリの場合、メンテナンスオペレーションが頻繁かつ長時間にわたって実行されるため、結果として障害発生率が高くなっていたのだ。
リポジトリのメンテナンスが失敗すると、プッシュとリファレンス更新のパフォーマンスに影響し、結果としてエンジニアがそれらのリポジトリを再調整するために手作業を行わなければならない場合があります。
GitHubは、パックに含まれていないすべてのオブジェクトをひとつに結合するgit repackを改善することで、障害率をほぼ０まで低減することに成功した。パックにはオブジェクト全体ではなく差分のみを格納するため、比較する必要のあるオブジェクトの数や、オブジェクトの関連性を判定に要する時間のため、計算処理的に高価なものになる可能性がある。これが原因で、メンテナンスタスクにおいて、実行時間の制限によるエラーが多発していたのだ。
高価な比較処理の実行数を制限するために、パラメータを実装することにしました。この値を調整することで、生成されるパックファイルのわずかなサイズ増加と引き換えに、git packを実行するCPU時間を低減することができたのです。
さらなる改善は、失敗したメンテナンスタスクの再実行ポリシを変更することで実現された。特にモノリポジトリにおいては、失敗後7日間はメンテナンスの再スケジュールを行わない、という既定のポリシに問題のあることが分かった。モノリポジトリは頻繁に更新されるものであるからだ。
特定のリポジトリメンテナンスエラーに対して、新たに疑似エラー状態(spurious-failure state)を導入しました。通常これは、メンテナンス中に多数のプッシュトラフィックが発生した場合に発生するものです。これを使用して、メンテナンスを1時間毎、最大3回までリトライするようにしました。
毎時間リトライすることには、ユーザが作業していない、つまり、リポジトリに対するトラフィックの低い時間をキャッチするチャンスが増える、というメリットもあった、とArbeit氏は述べている。
さらに、歴史的な理由のみから、各サーバ上で処理するプッシュの速度を遅くすることで、サーバのパフォーマンスが人為的に制限されていた、という事実も明らかになった。
このパラメータの値を徐々に大きくしていって、プッシュ操作の100パーセントを即時実行できるようにした調査の結果、現行のアーキテクチャであれば、十分過ぎるほどのパフォーマンスのあることが分かりました。
最後の改善は、GitHubが安全のために運用するリポジトリの5つのレプリカ間で、gitリファレンスを更新するために使用されている、3フェーズコミットプロトコルのパフォーマンス制限を排除したことだ。簡単に言うと、プロトコルロックウィンドウ内で各レプリカのチェックサムを計算するのを止めて、ロック取得前に行うようにした。モノリポジトリのリペア操作ではレプリカサーバを最大20～30秒にわたってロックする場合があったが、これによってロックウィンドウ全体を1秒以内に短縮することができた。
これらの変更により、Arbeit氏によれば、巨大なモノリポジトリを運用するユーザの操作性が著しく向上したのみならず、一般ユーザのプッシュパフォーマンスも改善することができたのだ。