Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。

クラスタリングについて

GitHub Enterprise Server クラスタリングを利用することで、GitHub Enterprise Server を構成するサービス群を複数のノードにまたがってスケールアウトできるようになります。

クラスタリングのアーキテクチャ

GitHub Enterprise Serverは、一連のサービスから構成されています。 クラスタでは、これらのサービスは複数のノードにまたがって動作し、リクエストはそれらのノード間でロードバランスされます。 変更は、冗長なコピーと共に個別のノードに自動的に保存されます。 ほとんどのサービスは、同じサービスの他のインスタンスと同等のピア群です。 ただし、mysql-serverredis-server のサービスは例外です。 これらは、1 つ以上のレプリカ ノードを持つ 1 つのプライマリ ノードで動作します。

詳細については、クラスタリングに必要なサービスに関するページを参照してください。

クラスタリングは組織に適切か?

クラスタリングは、負荷を複数のノードに分配することによってスケーラビリティを向上させます。 この水平スケーリングは、数万の開発者を持つような組織に適しているかもしれません。とはいえ、冗長性のあるスケーラブルなクラスタのセットアップは複雑であり、かつ、注意深い計画が必要です。 この追加の複雑さによって、インストール、システム災害復旧およびアップグレードについて計画することが必要となります。

GitHub Enterprise Server ではノード間のレイテンシが低いことが必要であり、地理的に離れた場所にまたがる冗長性を意図したものではありません。

クラスタリングは冗長性を提供しますが、High Availability構成を置き換えることを意図したものではありません。 詳細については、「高可用性の構成」を参照してください。 プライマリ/セカンダリフェイルオーバー設定はクラスタリングよりもはるかにシンプルであり、多くの組織の要求に応えます。 詳細については、「クラスタリングと高可用性の違い」を参照してください。

注: GitHub Enterprise Server 上の GitHub Packages は、現在クラスタリングをサポートしていません。

クラスタリングを利用するには?

クラスタリングは特定のスケーリングの状況のために設計されており、すべての組織を対象としたものではありません。 クラスタリングをご検討される場合は、専任の担当者または GitHub の営業チーム にお問い合わせください。