こんにちは！日々の開発、本当にお疲れ様です。
グローバルに展開するチームで開発をしていると、こんなイライラを感じたことはありませんか？
「東京オフィスからはサクサク動くのに、ロンドンやシドニーのメンバーから『Gitのクローンが遅すぎる！タイムアウトする！』って悲鳴があがる……」
「大容量のLFSファイルやコンテナイメージのプルで、海外拠点の朝会前の時間帯にネットワークが完全に死ぬ……」
世界中に散らばる優秀なエンジニアたちが、インフラの物理的な距離のせいでパフォーマンスを落とし、開発スピードが鈍化してしまう。これはCTOやテックリードにとって頭の痛い問題ですよね。
そんな「物理的な距離の壁」を鮮やかにブチ壊してくれるのが、今回紹介する「GitLab Geo」です。
これをマスターすれば、世界中のどこにいるメンバーも、まるで目の前にあるサーバーと通信しているかのような爆速の体験を手に入れることができますよ。さあ、一緒にその仕組みとセットアップの世界へ飛び込みましょう！
—
1. GitLab Geoとは？ ―― 物理の壁を消し去る分散開発の魔法
一言で言うと、GitLab Geoは「世界中にGitLabの読み取り専用ミラーを配置し、グローバル規模で超高速なアクセスと強固な災害対策（ディザスターリカバリ）を実現する仕組み」です。
なぜ「分散」が必要なのか？
通常のGitLab構成（プライマリサイト）を1つだけ世界にポツンと置いておくと、地球の裏側からのリクエストは海底ケーブルを何往復もすることになります。光の速さであっても、物理的な距離（伝搬遅延）はどうしようもありません。
GitLab Geoを導入すると、以下のような構造になります。
- プライマリ（Primary）サイト：
- あなたが普段使っている、データの「書き込み（Push）」も「読み取り（Fetch/Clone）」もできる本丸のGitLabサーバー（例：フランクフルト本拠地）。
- セカンダリ（Secondary）サイト：
- 世界各地（例：東京、シドニー、ニューヨークなど）に置かれる、プライマリのデータをリアルタイムに同期するミラーサーバー。
これにより、東京のメンバーは東京にあるセカンダリサイトに対してクローンやフェッチを行えるため、ネットワークの遅延が劇的に改善されます。
> 💡 先輩からのアドバイス：読み取りだけじゃない！賢いリダイレクト機能
> 「えっ、じゃあプッシュするときはわざわざプライマリのURLに書き換えないといけないの？」いいえ、心配無用です。GitLab Geoは、セカンダリに対して `git push` が行われると、自動的にプライマリへと通信を裏側で転送（プロキシ）してくれます。開発者は「いつも通りのURL」を使うだけでいいのです。
—
2. 読取専用ミラーとレプリケーションの裏側
「ミラーって、どうやってデータを同期しているの？」
ここがGitLab Geoの最も美しい技術的ハイライトです。
GitLab Geoは、単なるファイルのコピーではありません。データベース、Gitリポジトリ、LFS（Large File Storage）オブジェクト、添付ファイル、コンテナイメージなど、GitLabが保持するすべてのデータアセットを安全に同期します。
1. データベースのレプリケーショントラフィック
- プライマリ側のPostgreSQLの変更差分（WAL: Write-Ahead Log）を、PostgreSQLの機能（ストリーミングレプリケーション）を使ってセカンダリ側にリアルタイムで流し込みます。
2. データファイルの同期
- GitリポジトリやLFSなどの実体ファイルは、GitLabがバックグラウンドで監視し、プライマリからセカンダリへ安全に同期（バックグラウンドレプリケーション）します。
もしもの時の「フェイルオーバー（災害対策）」
万が一、プライマリサイトがある地域で大規模な停電や自然災害が発生した場合でも安心です。セカンダリサイトを「昇格（Promote）」させることで、数分でセカンダリを新しいプライマリとして機能させ、ビジネスを継続させることができます。これが究極のBCP（事業継続計画）対策になります。
—
3. 【実践】最小構成で学ぶ！GitLab Geo 基礎セットアップ
それでは、理論はこれくらいにして、実際にGitLab Geoの環境を構築する手順をイメージしていきましょう。
今回は、すでに稼働しているプライマリサイトに対し、新しいセカンダリサイトを1台追加する手順の基本を解説します。
> ⚠️ 注意
> 本番環境での構築には、適切なドメイン設計、SSL証明書、そしてプライマリとセカンダリ間で安全な通信（VPCやVPN）が確保されていることが前提となります。
ステップ1：前提条件の確認
- プライマリとセカンダリで、全く同じバージョンのGitLabがインストールされていること（バージョン違いは絶対にNGです）。
- プライマリとセカンダリの間で、PostgreSQLのポート（通常5432）や内部API通信がファイアウォールで許可されていること。
ステップ2：プライマリサイトでの設定 (`gitlab.rb`)
まず、プライマリサーバー（`gitlab.example.com`）の `/etc/gitlab/gitlab.rb` を編集し、このサーバーがGeoの「プライマリ」であることを明示します。
/etc/gitlab/gitlab.rb (プライマリ側)
外部URLの指定
external_url ‘https://gitlab.example.com’
このノードがGeoプライマリであることを宣言
gitlab_rails[‘geo_node_name’] = ‘primary-node-tokyo’
PostgreSQL外部接続を許可するための設定（セカンダリからのレプリケーション用）
postgresql[‘listen_address’] = ‘0.0.0.0’
postgresql[‘trust_auth_cidr_addresses’] = [‘192.168.10.0/24’] # セカンダリからのCIDRを指定
postgresql[‘max_replication_slots’] = 2
postgresql[‘max_wal_senders’] = 10
変更を反映
sudo gitlab-ctl reconfigure
ステップ3：セカンダリサイトでの設定 (`gitlab.rb`)
次に、新しく用意したセカンダリサーバー（例：`geo-syd.example.com` / シドニー拠点）の設定です。
/etc/gitlab/gitlab.rb (セカンダリ側)
このサイト自身のURL
external_url ‘https://geo-syd.example.com’
このノードがGeoセカンダリであることを宣言
gitlab_rails[‘geo_node_name’] = ‘secondary-node-sydney’
読み取り専用モードを有効化
gitlab_rails[‘geo_secondary_role’] = attivato # (内部フラグ)
※実際には以下の設定を使用します
sidekiq[‘enable’] = false # セカンダリ用の特殊なジョブ制御を行う場合あり
(※詳細なDB接続情報やOAuth連携の設定は公式ドキュメントの高度な手順に沿って行います)
ステップ4：GitLab管理画面でのGeoノード登録
設定ファイルの適用（`gitlab-ctl reconfigure`）が終わったら、プライマリのGitLab管理画面にアクセスします。
1. Admin Area > Geo > Nodes に移動。
2. 「Add node」をクリック。
3. 名前に `secondary-node-sydney`、URLに `https://geo-syd.example.com` を入力し、「This is a secondary node」にチェックを入れて保存します。
これで、データ同期のパイプラインが静かに、しかし力強く動き始めます！
—
4. 精度高い「動作確認」：正しく動いているかテストしよう！
セットアップが終わったら、正しくレプリケーション（同期）が行われているかを自分の手で確かめてみましょう。これがエンジニアにとって一番ワクワクする瞬間です。
動作確認チェックリスト
1. 管理画面での同期ステータス確認
- プライマリの `Admin Area > Geo > Nodes` を見てみましょう。
- シドニーのセカンダリノードに対して、「Replication lag（同期の遅延）」が「0 bps」または数秒以内になっていることを確認します。緑色の健全なステータスが表示されていれば大成功です！
2. 実際にクローンとプッシュを試してみる
- プライマリ側で適当なテスト用プライベートリポジトリを作成します。
- シドニーのセカンダリ側（`https://geo-syd.example.com/…`）のURLを使って、手元のクライアントからクローンしてみましょう。
# シドニーのセカンダリ経由でクローン（爆速で終わるはずです！）
git clone https://geo-syd.example.com/your-group/test-geo-repo.git
cd test-geo-repo
- 次に、ファイルを変更してプッシュしてみます。
echo “Hello GitLab Geo!” >> README.md
git commit -am “Test Geo push”
git push origin main
- ここでマジックが起きます。 セカンダリ（読み取り専用）に向けたはずのプッシュが、裏側でプライマリに転送され、無事にコミットが受理されます！
- そして、数秒後にはプライマリ側からセカンダリ側へデータが巻き戻り（逆流同期され）、他のシドニーのメンバーも最新のコードを秒で取得できるようになります。
—
まとめ：世界が小さくなる感動を味わおう
今回は、GitLab Geoの基本概念から、マルチサイトでのパフォーマンス改善、そしてレプリケーションと動作確認の流れまでを解説しました。
- GitLab Geoは、物理的な距離の遅延を解消する最強の分散インフラ
- 読み取り専用ミラーにより、世界中の拠点でクローンやフェッチが爆速に
- 万が一の障害時も、セカンダリの昇格でビジネスを止めない
これをマスターすれば、あなたの会社の開発チームは「物理的な拠点」の縛りから完全に解放されます。「海外メンバーとのコード共有が遅い」という日々のストレスが嘘のように消え去り、チーム全体の開発ベロシティが一段と跳ね上がるのを実感できるはずです。
ぜひ、次のインフラ設計やスケールアップのタイミングで、GitLab Geoに挑戦してみてください。毎日の開発が、もっと自由で快適になりますよ！