データベース

GitLab は 単一のデータストア に依存する シングルアプリケーション です（厳格な耐久性要件の文脈で使用する用語で、たとえば Redis に対する PostgreSQL のことを指します）。

この指針は GitLab のプロダクト開発を方向づけています。GitLab は SaaS first ではありますが、SaaS only ではありません。データベースに関して言えば、GitLab は単一のデータベースクラスタを持つセルフマネージド構成を、一般的には論理データベースの利用を通じてサポートしています。GitLab.com のように単一のクラスタを複数に展開することは、スケールが必要になった時にのみ検討します。これは、コードベースが安定したままで、スケーラビリティに対応する柔軟なバックエンド戦略を活用できることを意味します。セルフマネージドと GitLab.com は引き続き単一のアプリケーションとして動作し、特にセルフマネージドはシンプルさを提供しつつ、スケールするための柔軟性も提供し続けます。

複数のデータストアを持つこと自体に対する根本的な拒否反応はありませんが、特に多種多様なデータエンジンが関与する場合、過度に多く のデータストアを持つことの落とし穴は避けたいと考えています。追加のデータストアは管理と開発の観点で複雑さをもたらします。新しいデータベースを使用したり、既存のデータベースを採用したりすると、トレードオフが発生し、それを大規模に綿密に管理する必要があります。私たちは別のデータストアをデプロイする前にいくつかのゲートキーパーを設けており、以下のガイドラインは、最良の対応方針が何であるか、そしてどのように進めるかを判断するのに役立つことを意図しています。

これらのガイドラインは、Database Working Group の 用語集 に大きく依拠しています。

新しいデータベースが必要

新しいデータベースが必要 というリクエストは一般的になってきており、シンプルに見えますが、特に新しいサービスや新しいチームにとっては見かけによらず複雑です。

何よりもまず、データベース（あらゆるデータベース）へのアクセスは、本番環境および関連するアクセス制御と手続きの範囲内でのみ発生します。新しいリソースを要求する機能やサービスは、プロダクションレディネスレビュー を経る必要があります。

第二に、その文がどういう意味を持つのか、特に格納とクエリされるべきデータの種類、メインのデータベースとどれだけ密結合しているか、そしてスキーマと設定がどのように管理されるかという点で、十分に理解する必要があります。

第三に、それがリソース利用（必要な空間、トランザクションレート、両者の期待される成長）の観点でどのような意味を持つかを理解する必要があります。

最後に、データが新しいデータストアエンジンを必要とするかどうかを理解する必要があります。なぜなら、本番環境にデプロイされてからは、デプロイ自体、継続的なメンテナンス（アップグレードなど）、可観測性の統合、さらに重要なことに、インシデント時のトラブルシューティングの観点で重大な影響を持つからです。

私たちはリレーショナルデータベース（PostgreSQL）を主要なメタデータ格納エンジンとして使用しています。それに加えて、データ構造ストア（Redis）も使用しています。これは GitLab の機能に不可欠ですが、より動的なデータを格納します。

リレーショナル: PostgreSQL

PostgreSQL は私たちが選んだリレーショナルデータベースエンジンであり、最近まで、プロジェクト、Issue、マージリクエスト、ユーザーなどに関するすべてのメタデータは単一のクラスタに存在していました。そのスキーマは Rails アプリケーション (db/structure.sql) によって管理されています。私たちは一般的にこのデータストアを メインデータベース と呼びます。スケーラビリティのニーズが高まるにつれて、それらに対応するためにいくつかの ベストプラクティス を採用してきました。一部の項目はデータベースから抽出されました（差分が最初でした）。一方、他のものはすでに別個のサービスであり、データの結合要件が低かったため、別の論理データベースやインスタンス（スケール時）にデプロイされました（Registry および Praefect）。さらに、そのスケールゆえに (CI) 分解されたものもあります（そして、密結合を回避する方法を見つけたためです）。

データ構造: Redis

Redis は、キュー (Sidekiq ジョブは JSON ペイロードにジョブをマーシャリングします)、永続的な状態 (セッションデータと排他リース)、およびキャッシュ (ブランチやタグ名などのリポジトリデータ、ビュー部分テンプレート) を含む特殊で非リレーショナルなニーズのために使用されます。Redis はアプリケーションの重要なコンポーネントですが、PostgreSQL と同じ耐久性の制約で使用されているわけではありません。

考慮事項

適切なデータベースを判断するために、4 つの基本的な質問に答える必要があります:

1. アプリケーションのコードベースはどのようなものか?
2. アプリケーションはどのような種類のデータを格納する必要があるか?
3. アプリケーションはデータベースに対してどのような種類のクエリを実行する必要があるか?
4. 消費される空間、トランザクションレート（読み込みと書き込みの両方）、レイテンシの観点で、現在および近い将来にどのようなリソース利用が見込まれるか?

最初の 3 つの質問への回答は、アプリケーションに組み込まれているため事前に分かっている可能性が高く、最後のものは少し明確でない傾向がありますが、正確な回答は不要であり、概算（デプロイ時と少し将来を見通したもの）は必要です。Database、Scalability、Memory などの専門チームは、これらの未知の事項を明らかにするのに役立てます。いずれにせよ、これらの質問への回答は（いくつかの例外を除き）特定のテクノロジーを避けるべきです。追加の入力として、ビジネス上の期待と過去の成長に基づく GitLab.com のスケーリングモデル を参照して、将来のスケーリング要件を理解できます。

デフォルトの答え: メインの Postgres データベース

伝統的に、デフォルトの答えはメインのデータベース（PostgreSQL）を使うことでした。しかし、私たちは主に 3 つの理由でこれが当てはまらなくなった時点に来ている可能性が高いです:

1. GitLab.com で可用性を確保するために、特にトランザクションレート、コネクション、メモリ利用の観点で、メインデータベースの負荷を慎重に管理する必要があります。
2. プロダクトのエコシステムは既存のテクノロジースタックの統合を通じて多様な形で進化しており、より特殊なデータニーズが出てきています。
3. メインの GitLab.com Postgres データベースは OLTP (オンライントランザクション処理) のみを目的としています。特にスケール時には、OLAP (オンライン分析処理) はデータベース、特にクラスタレプリケーションに関して重大な低下をもたらします。

一般に、コードベースがメインの RoR アプリケーションの一部であれば、スキーマが RoR を通じて管理されており、コードがおそらく Rails コードベースとかなり密に結合しているため、ほとんどの場合すでにメインの PostgreSQL データベースを使用しています。しかし、新しいエンティティは慎重に管理される必要があります。可用性を確保するために、容量計画の懸念に対処する必要があるからです。開発の Database Group と Infrastructure Platforms チーム は、この点での最良の情報源です。これは Redis にも当てはまります。

例外

スケーラビリティの懸念により、私たちは現在、CI テーブル を別のクラスタに移動することで、メインデータベースの最初の 機能分解 を実行しています。CI 関連のコードベースはメインの RoR アプリケーションの一部ですが、CI テーブルはメインデータベースの全体サイズの約 40%、書き込みの約 50% を占めています。残りのデータベースとのデータ結合は比較的疎であるため、最小限の変更を行いながら、私たちが構築する新しい技術 (Loose Foreign Keys) を反復しつつ、2 つのデータベース間でデータ整合性を確保できます。

一般的に、別個のクラスタは、データセットのサイズとそれに対応するトランザクションレートの要件が、運用コストとサポートするコードを開発する追加の複雑さに見合うほど大きい場合にのみサポートされます。最初は、これはおそらくメインクラスタの一部としての別個の論理データベースに置かれます。

その他のユースケース

リレーショナル (PostgreSQL)

アプリケーションがメインの RoR アプリケーションのコードベースの 一部ではない 場合 (たとえば、Container Registry、Praefect、Geo Tracking Database)、別のデータベースが唯一の選択肢です。これが論理的なものか独立したクラスタに属するかは、スケールによります。

新しいデータストアエンジン

現在サポートされているデータストアエンジンではアプリケーションの要件を満たせず、新しいデータストアエンジンを環境に導入する必要がある場合があります。これらは非常にまれであるべきですが、一般的には、新しいテクノロジースタックを環境に統合する取り組み (たとえば、買収) や、データニーズが非常に特殊な場合 (たとえば、時系列データ) に発生します。

デューデリジェンスとして、できる限り早く Infrastructure チームを巻き込む必要があります。新しいテクノロジーをサポートするには、トレーニング、デプロイ、設定、メンテナンス (アップグレード)、トラブルシューティングなどの観点で多様な作業が必要になるからです。

ページのソースコードを見る - ページの編集 - please contribute.