GitHub Enterprise Serverの高可用性のための検索アーキテクチャ再構築

GitHubで皆さんが操作する多くの部分は検索に依存しています。GitHub Issuesページのような検索バーやフィルタリング機能はもちろんのこと、リリースページ、プロジェクトページ、イシューやプルリクエストの件数表示などの中核にもなっています。検索がGitHubプラットフォームの中心的な部分であることを踏まえ、私たちはこの1年間、さらに堅牢なものにする取り組みを行ってきました。つまり、GitHub Enterprise Serverの管理に費やす時間を減らし、お客様が最も関心を持つことに注力する時間を増やすことを意味します。 近年、GitHub Enterprise Serverの管理者は、検索に最適化された特殊なデータベーステーブルである検索インデックスに特に注意を払う必要がありました。メンテナンスやアップグレードの手順を正確な順序で守らなかった場合、検索インデックスが破損して修復が必要になったり、ロックされてアップグレード中に問題を引き起こしたりする可能性がありました。高可用性（HA）設定を導入していない場合の簡単な背景説明をすると、HAはシステムの一部が故障してもGitHub Enterprise Serverを円滑に稼働し続けるように設計されています。書き込みとトラフィックをすべて処理するプライマリノードと、同期を保ち必要に応じて引き継ぐことができるレプリカノードがあります。 ![image](https://github.blog/wp-content/uploads/2026/03/CCR.png?resize=1280%2C720) この困難の多くは、私たちが選択した検索データベースであるElasticsearchの以前のバージョンがどのように統合されていたかから生じています。HA構成のGitHub Enterprise Serverインストールでは、リーダー/フォロワーパターンを使用します。リーダー（プライマリサーバー）はすべての書き込み、更新、トラフィックを受け取ります。フォロワー（レプリカ）は読み取り専用に設計されています。このパターンはGitHub Enterprise Serverのすべての操作に深く根付いています。 ここでElasticsearchは問題に直面し始めました。プライマリノードとレプリカノードの両方をサポートできなかったため、GitHubのエンジニアリングチームはプライマリノードとレプリカノードにまたがるElasticsearchクラスターを作成する必要がありました。これによりデータの複製が簡単になり、さらに各ノードがローカルで検索リクエストを処理できるため、いくつかのパフォーマンス上の利点も得られました。 ![image](https://github.blog/wp-content/uploads/2026/03/CCR-1.png?resize=1280%2C720) 残念ながら、サーバー間でのクラスタリングの問題は、最終的に利点を上回り始めました。例えば、Elasticsearchはいつでもプライマリシャード（書き込みの受信/検証を担当）をレプリカに移動させることができました。そのレプリカがメンテナンスのために停止させられた場合、GitHub Enterprise Serverはロック状態に陥る可能性がありました。レプリカはElasticsearchが正常になるのを待ってから起動しますが、Elasticsearchはレプリカが再参加するまで正常になることができませんでした。 いくつかのGitHub Enterprise Serverリリースにわたって、GitHubのエンジニアはこのモードをより安定させようと試みました。Elasticsearchが正常な状態にあることを確認するチェックや、状態のずれを修正しようとする他のプロセスを実装しました。クラスターモードから脱却できる「検索ミラーリング」システムの構築を試みるまでに至りました。しかし、データベースレプリケーションは非常に困難であり、これらの取り組みには一貫性が必要でした。 何が変わったのか？ 数年にわたる作業の末、私たちは現在、Elasticsearchのクロスクラスターレプリケーション（CCR）機能を使用してHA構成のGitHub Enterpriseをサポートできるようになりました。 「でもデイビッド、それはクラスター間のレプリケーションでしょう？それがここでどのように役立つのですか？」 ご質問ありがとうございます。このモードでは、複数の「シングルノード」Elasticsearchクラスターを使用するように移行しています。現在、各Enterpriseサーバーインスタンスは独立したシングルノードElasticsearchクラスターとして動作します。 ![image](https://github.blog/wp-content/uploads/2026/03/CCR-2.png?resize=1280%2C720) CCRにより、Elasticsearchによって厳密に制御され、ネイティブでサポートされる方法でノード間のインデックスデータを共有できます。データがLuceneセグメント（Elasticsearchの基盤となるデータストア）に永続化された後にコピーします。これにより、Elasticsearchクラスター内で確実に永続化されたデータを複製していることが保証されます。 言い換えれば、Elasticsearchがリーダー/フォロワーパターンをサポートするようになったことで、GitHub Enterprise Serverの管理者は、重要なデータが読み取り専用ノードに残ってしまう状態に置かれることはなくなります。 内部の仕組み Elasticsearchには自動フォローAPIがありますが、それはポリシーが存在した後に作成されたインデックスにのみ適用されます。GitHub Enterprise ServerのHAインストールにはすでに長期間存続するインデックスのセットがあるため、既存のインデックスにフォロワーを接続し、将来作成されるものに対して自動フォローを有効にするブートストラップステップが必要です。 そのワークフローがどのようなものかのサンプルを以下に示します： function bootstrap_ccr(primary, replica): # それぞれの現在のインデックスを取得 primary_indexes = list_indexes(primary) replica_indexes = list_indexes(replica) # システムインデックスを除外 managed = filter(primary_indexes, is_managed_ghe_index) # フォロワーパターンがないインデックスについては、 # その契約を初期化する必要がある for index in managed: if index not in replica_indexes: ensure_follower_index(replica, leader=primary, index=index) else: ensure_following(replica, leader=primary, index=index) # 最後に、新しいインデックスが自動的にフォローされるように # 自動フォロワーパターンを設定する ensure_auto_follow_policy( replica, leader=primary, patterns=[managed_index_patterns], exclude=[system_index_patterns] ) これは、GitHub Enterprise ServerでCCRを有効にするために作成した新しいワークフローの1つに過ぎません。フェイルオーバー、インデックス削除、アップグレードのためのカスタムワークフローを設計する必要がありました。Elasticsearchはドキュメントレプリケーションのみを処理し、インデックスのライフサイクルの残りの部分は私たちが責任を持ちます。 CCRモードの始め方 新しいCCRモードの使用を開始するには、support@github.comに連絡し、GitHub Enterprise Serverの新しいHAモードを使用したい旨を伝えてください。必要なライセンスをダウンロードできるように、あなたの組織を設定します。 新しいライセンスをダウンロードしたら、`ghe-config app.elasticsearch.ccr true`を設定する必要があります。それが完了すると、管理者は`config-apply`を実行できます。 GitHub Enterprise Serverが再起動すると、Elasticsearchはインストールを新しいレプリケーション方法を使用するように移行します。これにより、すべてのデータがプライマリノードに統合され、ノード間のクラスタリングが解除され、CCRを使用したレプリケーションが再起動されます。この更新は、GitHub Enterprise Serverインスタンスのサイズによっては時間がかかる場合があります。 新しいHA方法は現在オプションですが、今後2年間でデフォルトにする予定です。GitHub Enterprise管理者が十分な時間をかけてフィードバックを提供できるようにしたいと考えていますので、今が試す時期です。 GitHub Enterprise Serverの管理をよりシームレスな体験にするために、新しいHAモードの使用を開始されることを楽しみにしています。 高可用性GitHub Enterprise Serverデプロイメントで検索を最大限に活用したいですか？サポートに連絡して、新しい検索アーキテクチャを設定してください！ この投稿「How we rebuilt the search architecture for high availability in GitHub Enterprise Server」は、The GitHub Blogに最初に掲載されました。

GitHub Enterprise Serverの高可用性のための検索アーキテクチャ再構築

背景や根拠まで確認しますか？

調べる

選ぶ

サイト