リファレンスアーキテクチャ

GitLabリファレンスアーキテクチャは、GitLabの品質チームとサポートチームによって設計され、テストされています。

利用可能なリファレンスアーキテクチャ

ワークフローによっては、以下の推奨リファレンスアーキテクチャを適宜変更する必要があります。ワークロードは、ユーザーのアクティビティ、使用する自動化、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。さらに、表示されるメモリの値は、GCPマシンタイプによって提供されます。異なるクラウドベンダーの場合は、提供されるアーキテクチャに最適なオプションを選択してください。

GitLab パッケージ (Omnibus)

GitLabパッケージが使用されているリファレンスアーキテクチャは以下の通りです：

クラウド・ネイティブ・ハイブリッド

一部の推奨コンポーネントをKubernetesで実行できる、以下のクラウドネイティブハイブリッドのリファレンスアーキテクチャが利用可能です：

開始前

最初に検討すべきことは、セルフマネージド・アプローチがお客様の要件に合っているかどうかということです。

どのようなアプリケーションでも本番稼動は複雑であり、GitLabも同様です。GitLabは可能な限りスムーズな運用を目指していますが、それでも一般的な複雑さはあります。これは選択したデザインによって異なりますが、一般的にはハードウェア、オペレーションシステム、ネットワーク、ストレージ、セキュリティ、GitLab自体など、あらゆる側面を管理する必要があります。これには、環境の初期設定と長期的なメンテナンスの両方が含まれます。

そのため、このルートを選ぶ際には、本番環境でのアプリケーションの運用やメンテナーに関する実務的な知識を持っていることをおすすめします。もしそのような立場にないのであれば、私たちのプロフェッショナルサービスチームがインプリメンテーションサービスを提供していますが、より長期的なマネージドソリューションをお望みの方は、代わりにGitLab SaaSや GitLab Dedicatedといった私たちの他のサービスを検討されることをお勧めします。

アーキテクチャの決定

リファレンスアーキテクチャは、パフォーマンスと弾力性という2つの重要な要素のバランスを取るように設計されています。

これらはGitLabを簡単にスケールアップできるように設計されていますが、どれがあなたの要件に合うかを知るのはまだ難しいかもしれません。

一般的な目安として、パフォーマンスや弾力性の高い環境を望むほど、複雑なものになります。

このセクションでは、選択可能な設計について説明します。最も複雑でないものから始まり、最も複雑なものへと進み、最後にデシジョンツリーで終わります。

スタンドアロン（非HA）

ユーザー数が2,000人以下の環境では、一般的に非高可用性のシングルノードまたはマルチノード環境をデプロイするスタンドアロンアプローチを推奨します。このアプローチでは、リカバリのための自動バックアップなどの戦略を採用し、HAに伴う複雑さを回避しながら、十分なレベルのRPO/RTOを提供することができます。

*[RTO]：Recovery time objective *[RPO]：復旧時点目標

スタンドアロンのセットアップ、特にシングルノードの環境では、 インストールと管理のためのさまざまなオプションがあります。

高可用性(HA)

高可用性は、GitLabセットアップのすべてのコンポーネントが様々なメカニズムを通して障害に対処できることを保証します。しかし、これを実現するのは複雑で、必要な環境も大きくなります。

3,000人以上のユーザーにサービスを提供する環境では、一般的にHA戦略を使用することをお勧めします。この範囲のアーキテクチャはすべて、このような理由から設計上HAが組み込まれています。

高可用性(HA)は必要ですか？

前述したように、HAを実現するにはコストがかかります。各コンポーネントを増設する必要があるため、環境要件は大きくなり、実費とメンテナンス費用が追加されます。

3,000人未満のユーザーを抱える多くのお客様にとっては、バックアップ戦略で十分であり、望ましいとさえ言えます。この場合、リカバリにかかる時間は遅くなりますが、その分アーキテクチャが小さくなり、メンテナンスコストも削減できます。

一般的には、次のような場合にのみHAを採用することをお勧めします：

  • ユーザー数が3,000人以上の場合。
  • GitLabがダウンするとワークフローに致命的な影響が出る場合。

スケールダウンした高可用性(HA) アプローチ

より少ないユーザー数でもHAが必要な場合は、3Kアーキテクチャを調整することで実現できます。

ダウンタイムなしのアップグレード

ゼロ・ダウンタイム・アップグレードは、HAを備えた標準的なリファレンス・アーキテクチャ環境で利用できます（クラウド・ネイティブ・ハイブリッドはサポートされていません）。これにより、アップグレード中も環境を維持することができますが、その結果プロセスが複雑になり、ドキュメントで詳しく説明されているようにいくつかの制限があります。

このプロセスを実行する場合、HAメカニズムが有効になるときにダウンタイムが発生する可能性があることに注意してください。

ほとんどの場合、アップグレードに必要なダウンタイムはそれほど大きくはありません。

クラウド・ネイティブ・ハイブリッド（Kubernetes HA）

HA耐障害性の追加レイヤーとして、Cloud Native Hybridリファレンスアーキテクチャとして知られるKubernetesに選択したコンポーネントをデプロイできます。

これは、標準的なリファレンスアーキテクチャと比較して、より高度なセットアップです。Kubernetesでサービスを実行するのは複雑であることはよく知られています。このセットアップは、Kubernetesに関する知識と経験が豊富な場合にのみ推奨されます。

GitLab Geo (地域横断ディストリビューション/ディザスタリカバリ)

GitLab Geoでは、完全なディザスタリカバリ(DR) セットアップを行うことで、異なる地域での分散環境を実現できます。GitLab Geoは少なくとも2つの独立した環境を必要とします：

  • プライマリサイト
  • レプリカとして機能する1つ以上のセカンダリサイト。

プライマリサイトが利用できなくなった場合、セカンダリサイトの1つにフェイルオーバーできます。

このような高度で複雑な設定は、DRがお客様の環境にとって重要な要件である場合にのみ行ってください。また、各セカンダリサイトをプライマリサイトと同じアーキテクチャにするか、各サイトをHAに設定するかなど、各サイトの設定方法についても決定する必要があります。

クラウドプロバイダーサービス

先に説明したすべての戦略について、PostgreSQLデータベースやRedisなどの同等のクラウドプロバイダーサービス上でGitLabコンポーネントを選択して実行することができます。

詳細については、推奨されるクラウドプロバイダーとサービスをご覧ください。

デシジョンツリー

以下に、上記のガイダンスをデシジョンツリー形式で示します。上記のガイダンスに目を通すことをお勧めします。

%%{init: { 'theme': 'base' } }%% graph TD L1A(<b>What Reference Architecture should I use?</b>) L2A(3,000 users or more?) L2B(2,000 users or less?) L3A("<a href=#do-you-need-high-availability-ha>Do you need HA?</a><br>(or Zero-Downtime Upgrades)") L3B[Do you have experience with<br/>and want additional resilience<br/>with select components in Kubernetes?] L4A><b>Recommendation</b><br><br>3K architecture with HA<br>and supported reductions] L4B><b>Recommendation</b><br><br>Architecture closest to user<br>count with HA] L4C><b>Recommendation</b><br><br>Cloud Native Hybrid architecture<br>closest to user count] L4D>"<b>Recommendation</b><br><br>Standalone 1K or 2K<br/>architecture with Backups"] L1A --> L2A L1A --> L2B L2A -->|Yes| L3B L3B -->|Yes| L4C L3B -->|No| L4B L2B --> L3A L3A -->|Yes| L4A L3A -->|No| L4D L5A("<a href=#gitlab-geo-cross-regional-distribution-disaster--recovery>Do you need cross regional distribution or disaster recovery?"</a>) --> |Yes| L6A><b>Additional Recommendation</b><br><br> GitLab Geo] L4A -.- L5A L4B -.- L5A L4C -.- L5A L4D -.- L5A classDef default fill:#FCA326 linkStyle default fill:none,stroke:#7759C2

要件

リファレンスアーキテクチャを実装する前に、以下の要件とガイダンスを参照してください。

対応CPU

これらのリファレンスアーキテクチャは、最小公倍数のベースライン（Sysbenchベンチマーク）としてIntel Xeon E5 v3 (Haswell)CPUプラットフォームを使用して、Google Cloud Platform(GCP) 上で構築およびテストされました。

より新しい同サイズのCPUもサポートされており、その結果パフォーマンスが向上している可能性があります。Linuxパッケージ環境では、ARMベースの同等品もサポートされています。

note
バースト可能な」インスタンス・タイプは、性能が安定しないため推奨されません。

サポートされるインフラストラクチャ

一般的なガイダンスとして、GitLabは評判の良いクラウドプロバイダー（AWS、GCP、Azure）とそのサービス、または両方を満たすセルフマネージド（ESXi）など、ほとんどのインフラストラクチャ上で動作するはずです：

  • 各リファレンスアーキテクチャに詳述されている仕様。
  • このセクションのすべての要件。

ただし、これはすべての可能性のある順列を保証するものではありません。

詳しくは、推奨クラウドプロバイダーとサービスをご覧ください。

その他のワークロード

これらのリファレンスアーキテクチャは、GitLabの標準的なセットアップを想定して設計・テストされています。

しかし、追加のワークロードは、フォローアップアクションをトリガーすることで、オペレーションへの影響を増大させる可能性があります。例えば、以下のような場合、推奨される仕様を調整する必要があるかもしれません：

一般的なルールとして、必要な変更を通知するために、追加ワークロードの影響を測定するための堅牢な監視を行う必要があります。

スワップなし

スワップはリファレンスアーキテクチャでは推奨されていません。性能に大きな影響を与えるフェイルセーフだからです。リファレンス・アーキテクチャは、スワップを必要としないようにメモリ・ヘッドルームを持つように設計されています。

大規模リポジトリ

リファレンスアーキテクチャは、ベストプラクティスに従ったさまざまな規模のリポジトリでテストされました。

しかし、大きなリポジトリやモノレポ（数ギガバイト以上）は、バイナリファイルやブロブファイルをLFSに保存しないなどのベストプラクティスが守られていない場合、Gitのパフォーマンスや環境そのものに大きな影響を与える可能性があります。

リポジトリはあらゆる環境の中核であり、最適化されないとその影響は多岐にわたります。この影響の例をいくつか挙げます：

  • Git のパッキングオペレーションに時間がかかり、CPU やメモリのリソースを大量に消費します。
  • Git のチェックアウトに時間がかかり、ユーザーと CI/CD パイプラインの両方に影響を与えます。

このように、大きなリポジトリには注目すべきコストがかかり、一般的に処理に多くのリソースを必要とします（場合によっては、かなり多くのリソースを必要とします）。大規模なリポジトリが健全な状態を維持できるようにレビュアーがレビューし、可能な限りサイズを縮小する必要があります。

note
ベストプラクティスが守られておらず、大規模なリポジトリが環境上に存在する場合、安定したパフォーマンスを確保するためにGitalyのスペックを上げる必要があるかもしれません。

より詳細な情報とガイダンスについては、大規模リポジトリの管理ドキュメントを参照してください。

Praefect PostgreSQL

Praefectは独自のデータベースサーバーを必要とし、完全な高可用性を実現するにはサードパーティ製のPostgreSQLデータベースソリューションが必要です。

将来的には、これらの制限に対する組み込みソリューションを提供したいと考えています。それまでは、仕様に沿ったLinuxパッケージを使用して、非HA PostgreSQLサーバをセットアップすることができます。詳細は以下のイシューを参照してください：

note
以下のリストは完全なものではありません。一般的に、ここに記載されていないクラウドプロバイダーも同じ仕様で動作する可能性が高いですが、これは検証されていません。さらに、ここに記載されていないクラウドプロバイダーのサービスに関しては、実装がそれぞれ著しく異なる可能性があるため、慎重になることをお勧めします。

テストと実際の使用を通じて、リファレンスアーキテクチャは以下のクラウドプロバイダーで検証され、サポートされています：

リファレンスアーキテクチャGCPAWSAzureベアメタル
Linuxパッケージ🟢🟢🟡1🟢
クラウドネイティブハイブリッド🟢🟢
  1. Azureでは、スケールが大きくなるとパフォーマンスにイシューが発生するため、現時点では小規模なセットアップ（2kまで）のみを推奨しています。詳細については、Azureの推奨事項のセクションを参照してください。

さらに、以下のクラウドプロバイダーサービスは、リファレンスアーキテクチャの一部として使用するために検証され、サポートされています：

クラウド・サービスGCPAWSベアメタル
オブジェクトストレージクラウドストレージ🟢 S3 MinIO
データベースクラウド SQL🟢RDS
Redisメモリーストア🟢 ElastiCache

データベースサービスに関する推奨事項

外部データベース・サービスを使用する場合は、標準的でパフォーマンスが高く、サポートされているバージョンを実行する必要があります。

サードパーティの外部サービスを使用する場合：

  1. HA LinuxパッケージのPostgreSQLセットアップには、PostgreSQL、PgBouncer、Consulが含まれています。サードパーティの外部サービスを利用する場合、これらのコンポーネントは不要になります。
  2. HAを実現するために必要なノードの数は、Linuxパッケージと比較してサービスによって異なる可能性があり、それに応じて一致させる必要はありません。
  3. ただし、パフォーマンスをさらに向上させるためにリードレプリカによるデータベース負荷分散が必要な場合は、リファレンスアーキテクチャのノード数に従うことをお勧めします。
  4. GitLab Geoを使用する場合、サービスはクロスリージョンレプリケーションをサポートする必要があります。

サポートされていないデータベースサービス

いくつかのデータベース・クラウド・プロバイダー・サービスは、上記をサポートしていないことが知られているか、その他のイシューがあることが判明しており、推奨されていません：

Azureに関する推奨事項

Azureのいくつかの主要サービスにパフォーマンスのイシューが見つかったため、Azureへのデプロイは小規模なアーキテクチャ（2kまで）のみを推奨します。それ以上のアーキテクチャについては、別のクラウドプロバイダーを利用することをお勧めします。

上記に加えて、Azureに固有の追加ガイダンスに注意する必要があります：

  • Azure Database for PostgreSQL Single Serverは、パフォーマンス/安定性の顕著なイシューや不足している機能のため、使用はサポートされていません。
  • 新しいサービス、Azure Database for PostgreSQL Flexible Serverがリリースされました。内部テストでは期待どおりのパフォーマンスを示していますが、本番環境では検証されていないため、現時点では一般的に推奨されません。また、新しいサービスであるため、要件によっては機能が不足していることがあるかもしれません。
    • このサービスでは、現時点では標準的な Postgres 認証のみがサポートされています。Microsoft Azure Active Directory（Azure AD）は互換性がありません。
  • Azure Blob Storageには パフォーマンス制限があることが判明しており、本番環境での使用に影響を与える場合があります。ただし、これはこれまでのところ、当社の最大アーキテクチャ（25k以上）でのみ確認されています。

推奨リファレンスアーキテクチャからの逸脱

一般的なガイドラインとして、リファレンスアーキテクチャから離れれば離れるほど、サポートを得るのが難しくなります。どのような逸脱でも、複雑なレイヤーを導入することになり、潜在的なイシューがどこに潜んでいるかを見つけるための課題が増えます。

リファレンスアーキテクチャでは、公式のLinuxパッケージやHelm Chartを使用して、さまざまなコンポーネントをインストールして設定します。コンポーネントは個別のマシン（仮想化またはベアメタル）にインストールされ、マシンのハードウェア要件は「設定」列に、同等のVM標準サイズは利用可能な各リファレンスアーキテクチャのGCP/AWS/Azure列に記載されています。

同じスペックのDocker（Docker Composerを含む）上でコンポーネントを実行しても、Dockerはサポート面でよく知られているため、問題ないはずです。ただし、追加レイヤであることに変わりはなく、strace をコンテナで簡単に実行できないなど、サポートの複雑さが増す可能性があります。

サポートされていないデザイン

GitLabの環境設計を幅広くサポートするように努めていますが、決定的にうまくいかないとわかっているアプローチもあります。それらのアプローチについては、以下のセクションで詳しく説明します。

Kubernetesにおけるステートフルなコンポーネント

Kubernetes で Gitaly Cluster などのステートフルなコンポーネントを実行することはサポートされていません。

Gitaly Clusterは、VM上での実行のみがサポートされています。Gitaly自体はKubernetesの設計とうまくマッチせず、実行しようとすると重大で複雑な問題につながる可能性があるためです。詳細はエピック6127を参照してください。

これは Postgres や Redis のようなサードパーティのステートフルなコンポーネントにも当てはまりますが、特に非サポートと明記されていない限り、サポートされているクラウドプロバイダのサービスなど、必要であればこれらのコンポーネントのための他のサードパーティのソリューションを検討することができます。

ステートフル・ノードのオートスケール

一般的なガイダンスとして、GitLabの_ステートレスコンポーネント_（GitLab RailsとSidekiq）のみがオートスケーリンググループで実行できます。

Gitalyのようなステートを持つ他のコンポーネントは、この方法ではサポートされていません（詳しくはイシュー2997をご覧ください）。

これは Postgres や Redis のようなサードパーティのステートフルなコンポーネントにも当てはまりますが、特に非サポートと明記されていない限り、サポートされているクラウドプロバイダのサービスなど、必要であればこれらのコンポーネントのための他のサードパーティのソリューションを検討することができます。

1つの環境を複数のデータセンターに分散

1つのGitLab環境を複数のデータセンターにデプロイすることは、データセンターがダウンした場合にスプリットブレインのエッジケースが発生する可能性があるため、サポートされていません。例えば、GitLabセットアップのいくつかのコンポーネント、すなわちConsul、Redis Sentinel、Praefectは、正しく機能するために奇数のクォーラムを必要とし、複数のデータセンターに分割することは、特にこれに影響を与える可能性があります。

複数のデータセンターや地域にGitLabをデプロイするために、私たちは包括的なソリューションとしてGitLab Geoを提供しています。

検証とテスト結果

品質エンジニアリングチームは、リファレンスアーキテクチャのスモークテストとパフォーマンステストを定期的に実施し、コンプライアンスを維持していることを確認しています。

テストを実施する理由

品質部門は、GitLabのパフォーマンスを測定し、改善することに重点を置いています。また、自己管理されているお客様がパフォーマンスの高い設定として信頼できるリファレンスアーキテクチャを作成し、検証することにも重点を置いています。

詳しくはハンドブックのページをご覧ください。

検査方法

テストは、すべてのリファレンスアーキテクチャとクラウドプロバイダーに対して、自動的かつアドホックに行われます。これは2つのツールによって行われます：

全てのクラウドプロバイダー上のコンポーネント間のテスト環境でのネットワークレイテンシは5ミリ秒未満でした。これは観察として共有されたものであり、暗黙の推奨ではありません。

私たちは、テストされたアーキテクチャが他のアーキテクチャにも適用可能な範囲を持つ「テスト・スマート」なアプローチを目指しています。テストでは、GCP上の10k Linuxパッケージのインストールに焦点を当てています。これは、他のアーキテクチャやクラウドプロバイダー、クラウドネイティブハイブリッドの良い指標となることがテストで示されているからです。

スタンダード・リファレンス・アーキテクチャは、プラットフォームにとらわれないように設計されており、Linuxパッケージを通じてすべてがVM上で実行されます。テストは主にGCP上で行われますが、アドホック・テストでは、他のクラウド・プロバイダーの同等スペックのハードウェア上でも、あるいは構内（ベアメタル）で実行した場合でも、同様のパフォーマンスが得られることが示されています。

これらのリファレンスアーキテクチャでのテストは、特定のコード化されたワークロードでGitLabパフォーマンスツールを使って実行され、テストに使用されるスループットはサンプル顧客データに基づいて計算されます。お客様の規模に合ったリファレンスアーキテクチャを選択してください。

各エンドポイントタイプは、1,000ユーザーあたり(RPS) 、以下のリクエスト数/秒でテストされます：

  • API: 20 RPS
  • ウェブ2 RPS
  • Git (Pull)：2 RPS
  • Git (Push)： 0.4 RPS（最も近い整数に丸められます）

結果の解釈

note
私たちのQAチームがGitLabパフォーマンステストツールをどのように活用しているかについてのブログ記事をお読みください。

テストは公開され、結果はすべて共有されます。

以下の表は、リファレンスアーキテクチャに対して行われたテストの詳細と頻度、結果を示しています。追加テストは継続的に評価され、表はそれに応じて更新されます。

リファレンス
アーキテクチャ		GCP (* ベアメタルの代理でもあります)AWSAzure
LinuxパッケージクラウドネイティブハイブリッドLinuxパッケージクラウドネイティブハイブリッドLinuxパッケージ
1k週間
2k週間予定
3k週間週間
5k週間
10k毎日週間週間週間
25k週間
50k週間

ランニングコスト

出発点として、GCP、AWS、LinuxパッケージによるAzureの各リファレンスアーキテクチャの初期コストの詳細を以下の表に示します。

note
クラウド・ネイティブ・ハイブリッドの性質上、静的なコスト計算はできません。また、ベアメタルのコストは各設定によって大きく異なるため、ここには含まれていません。
リファレンス
アーキテクチャ		GCPAWSAzure
LinuxパッケージLinuxパッケージLinuxパッケージ
1k計算コスト計算コスト計算コスト
2k計算コスト計算コスト計算コスト
3k計算コスト計算コスト計算コスト
5k計算コスト計算コスト計算コスト
10k計算コスト計算コスト計算コスト
25k計算コスト計算コストコスト計算
50k計算コスト計算コスト計算コスト

リファレンスアーキテクチャ環境のメンテナー

リファレンスアーキテクチャ環境のメンテナーは、一般的に他のGitLab環境と同じで、このドキュメントの他のセクションで説明されています。

このセクションでは、リファレンスアーキテクチャ特有の注意事項だけでなく、関連する分野のドキュメントへのリンクも見つけることができます。

アップグレード

リファレンスアーキテクチャ環境のアップグレードは、他のGitLab環境と同じです。GitLabのアップグレードセクションに、その詳細な手順があります。

ゼロダウンタイムのアップグレードも可能です。

note
リファレンス・アーキテクチャのアップグレードは、作成時と同じ順序で行う必要があります。

環境のスケーリング

GitLab環境のスケーリングは、可能な限りシームレスに行えるように設計されています。

リファレンスアーキテクチャに関しては、次のサイズを見て、それに応じて調整します。ほとんどのセットアップでは垂直方向のスケーリングしか必要ありませんが、セットアップによって調整できる特定の領域がいくつかあります：

  • 非HA環境からHA環境へスケーリングする場合、様々なコンポーネントをHA形態でデプロイすることが推奨されます：
    • RedisからRedis Sentinel付きマルチノードRedisへ
    • PostgresからConsul + PgBouncerを使用したマルチノードのPostgresへ
    • GitalyからPraefectを使用したGitalyクラスタへ
  • Redisはシングルスレッドであるため、1万ユーザー以上からは複数のHAサーバーに分割することが推奨されます。

逆に、環境が過剰にプロビジョニングされていることを示す堅牢なメトリクスがある場合は、同じプロセスを適用してスケールダウンすることができます。ただし、イシューがないことを確認するために、スケールダウンの際には反復的なアプローチを取る必要があります。

環境の監視方法

GitLab環境を監視するには、GitLabにバンドルされているツールを使うことができますが、必要であればサードパーティのオプションを使うことも可能です。