GitLab Geoの真髄：物理的制約を超越する分散開発アーキテクチャの構築
世界各地にエンジニアが散らばるグローバル開発において、「`git clone` に時間がかかる」「大規模リポジトリのLFSダウンロードでCIが止まる」といった事象は、単なる遅延ではなく、組織の生産性を奪う致命的なレイテンシだ。
GitLab Geoは、単なる「ミラーリング」ではない。これは、GitLabという巨大なアプリケーションのステートを、光速の制約に従いながらグローバルに同期させる高度な分散システムである。本稿では、一般的なドキュメントを飛び越え、Geoの内部アーキテクチャを掌握し、極限まで最適化するための知見を共有する。
—
1. 内部アーキテクチャ：なぜGeoは「単なるミラー」ではないのか
Geoの核となるのは、「プライマリ・ノード（読み書き）」と「セカンダリ・ノード（読み取り専用）」の非同期複製アーキテクチャだ。
- データベースの複製: PostgreSQLのストリーミングレプリケーション（物理レプリケーション）をベースにしている。
- Gitデータ: `Gitaly`のレプリケーション・マネージャが、プライマリの `Gitaly` からセカンダリへイベント駆動で同期を行う。
- LFS/添付ファイル: `Object Storage`（S3等）を利用する場合、Geoによる同期だけでなく、ストレージレベルのレプリケーションを組み合わせることが、可用性と速度を両立する唯一の解だ。
上級者のハック: Geoの同期状態を監視する際、管理画面を見るのは素人だ。内部的には `gitlab-ctl geo-status` を叩き、JSON出力をPrometheusへ流し込み、同期ラグ（`db_replication_lag_seconds` や `git_replication_lag_seconds`）をGrafanaで可視化せよ。ミリ秒単位の遅延を許容できない拠点は、そもそもネットワークトポロジーを見直すべきだ。
—
2. パフォーマンス最適化の極致：Gitalyの限界を突破する
Geoを導入しても、Gitalyの設定が甘ければ意味がない。特に大規模リポジトリを扱う場合、以下のパラメータ調整は必須だ。
Gitalyのメモリ・CPU最適化
Geoセカンダリは、プライマリからのフェッチが集中する。`gitaly` の設定ファイルで以下を調整し、スループットを最大化せよ。
/etc/gitlab/gitaly/config.toml
[git]
同時実行されるGitコマンドの数を制御。ノードのコア数に応じて調整
max_parallelism = 32
[storage]
キャッシュディレクトリを高速なNVMe上に配置し、I/O待ちを根絶する
cache_directory = “/mnt/nvme/gitaly/cache”
—
3. 完全自動フェイルオーバーの設計思想
「Geoのフェイルオーバーが怖い」というエンジニアをよく見かける。だが、失敗を許容し、自動復旧する仕組みこそが信頼性の源泉だ。
自動フェイルオーバーを実装する際は、GitLabの公式ドキュメントにある「手動」の手順を鵜呑みにせず、GitLab Geo Node API を叩くスクリプトをCI/CDから分離された制御プレーン上で実行せよ。
自動フェイルオーバー制御スクリプトの断片（概念）
!/bin/bash
監視ノードから実行し、プライマリの死活を検知して昇格させる
実際にはConsul等のサービスディスカバリと組み合わせるべき
PRIMARY_URL=”https://primary.gitlab.example.com”
SECONDARY_URL=”https://secondary.gitlab.example.com”
ヘルスチェック
status=$(curl -s “${PRIMARY_URL}/-/health”)
if [ “$status” != “OK” ]; then
echo “Primary down. Promoting Secondary…”
# セカンダリをプライマリに昇格させるコマンド
gitlab-ctl promote-to-primary
# DNSの切り替えを自動化（Route53 API等をコール）
aws route53 change-resource-record-sets –hosted-zone-id …
fi
—
4. 現場で震えるための「極限ハック」：LFSとキャッシュ戦略
最も現場を苦しめるのは、巨大なLFSオブジェクトの同期だ。これをスマートに解決する手法は以下の通り。
1. Geo Proxy: セカンダリノードへのHTTPリクエストを、プライマリへ透過的にプロキシする設定を有効化せよ。これにより、ユーザーはノードを意識することなく、シームレスな体験を得られる。
2. CDNの活用: セカンダリからのLFSフェッチが頻発する場合、セカンダリをオリジンとしたCDN（CloudFront等）を噛ませろ。これにより、拠点内のローカルキャッシュが効き、Gitalyの負荷を劇的に削減できる。
3. データベースの最適化: レプリケーション遅延を防ぐため、`postgresql.conf` の `max_standby_streaming_delay` を適切に設定せよ。デフォルト設定は往々にして控えめすぎる。
—
結論：Geoは「物理」をハックするツールである
GitLab Geoを導入するということは、単なるインフラの冗長化ではない。「物理的な距離という制約を、ソフトウェアの力で無効化する」という挑戦だ。
ネットワーク遅延を計測し、GitalyのI/Oを極限までチューニングし、APIを通じてフェイルオーバーを自動化する。ここまで突き詰めて初めて、Geoは「強力な武器」となる。
次回のデプロイメントで、もし海外拠点のエンジニアから「GitLabが速くなった」という声が上がれば、君のGeoアーキテクチャは成功した証だ。それが、DevOpsスペシャリストとしての最大の勲章である。