GitHubがDGitを密かにロールアウトした。DGitは“distributed Git”の略で，GitHub使用時の信頼性，可用性，性能の向上を目的としてGit上に構築された，分散型の新しいストレージシステムだ。
DGitは，独自に選択された３つの異なるサーバ上に，すべてのリポジトリのコピーを３つ保持することでGitの分散性を活用する，アプリケーションレベルのプロトコルだ。このシンプルなアーキテクチャには信頼性や可用性，性能面で直接的なメリットが数多くある，とGitHubには述べられている。
- リポジトリをホストしている３つのサーバが相互に独立していると仮定すれば，それらがすべて同時に使用できなくなる可能性は極めて低い。
- ユーザの要求を３つのサーバ間でロードバランスすることが可能。要求の主体は参照であるため，３つのサーバ間での同期は必要なく，すぐに処理することができる。これにより，台数通りの3倍に近いパフォーマンス改善が実現する。
- リポジトリ間の“運命共有”を大幅に削減できる。運命共有(fate sharing)とは，非常にアクセス頻度の高い，あるいは極めて巨大なリポジトリとサーバを共有することにより，ひとつないし複数のリポジトリの性能が低下する状況をいう。独立したサーバにリポジトリを複製することによって，３つのサーバすべてに同じ状況が発生する可能性は極めて低くなる。場合によっては，オーバーロードの低いサーバで要求を処理することも可能だ。
- レプリカサーバが近接している必要はなく，別々のアベイラビリティゾーンやデータセンタに配置することもできる。可用性の向上は当然のこと，地理的に近い位置にいるユーザのパフォーマンスも向上する。
DGitを導入することによってGitHubとしては，それまで(およびDGItが展開されている間)使用していたバックアップベースのスキーマを排除することが可能になる。従来のスキーマでは，アクティブな各ファイルサーバに対して，クロスオーバケーブルで接続された専用のスペアサーバが必要だった。スペアサーバとの同期にはDRDBを使用していた。
このスキーマを廃止することにより，GitHubの全体的な仕込みとしては，さらなるメリットもある。
- サーバに障害が発生した場合，保留中の全要求を新しいサーバにルーティングすることにだけ注意を払えばよい。その上で，障害中のサーバを再起動するが，
- 障害の発生したサーバのリプレースを急ぐ必要はない。稼働中の他の２台が，そのサーバの当面の代替になるからだ。
- 専用の予備サーバが不要になるため，ユーザ要求を処理する上でCPUやメモリをより有効に使用することができる。
- 新規サーバの追加や，巨大化とアクセス数増加の続くリポジトリの管理といった， GitHubインフラストラクチャの管理作業が非常にシンプルになる。
DGitは前述のようにGit自体をベースとしていて，RAIDやDRDBなど，他のレプリケーション技術を利用することはできないため，直列化やロック，障害検出，再同期などには独自のアルゴリズムを実装しなくてはならない。InfoQとの会話の中でGitHubは，分散トランザクションの処理に３フェーズコミットプロトコルを使用していること，“１台のホストやラック自体のサービス中断に起因するサービス中断はほぼ解消されている”ことなどを説明してくれた。
前述のようにGitHubは先月から，DGitのロールアウトを段階的に進めている。まず自身のリポジトリ，次に新システムへの同意を取り付けた多数のハイプロファイルな公開リポジトリ，という順番だ。そして昨年２月，リポジトリのバルク移動を開始した。現時点で，GitHubの全データの67%にあたる60%のリポジトリと98%のGistがすでにDGit内で稼働しており，さらに"既存のストレージアーキテクチャからDGitへのインポート作業を24時間態勢で実施中”である，ということだ。