データベースプラットフォーム

現在の GitLab.com アーキテクチャ

GitLab.com は、Terraform、Chef、および複雑なタスクのための Ansible によって GCP の仮想マシン上で管理される 4 つの PostgreSQL クラスターを使用しています。 Cells では、大幅に多くの PostgreSQL クラスターを作成したいと考えており、50 Cell が必要な場合は 50 以上の PostgreSQL クラスターが必要になります。

@startuml
component "Rails"
component "Container Registry"

database "main"
database "ci"
database "registry"
database "embedding"

component "pgbouncer" as pgbouncermain
component "pgbouncer" as pgbouncerci
component "pgbouncer" as pgbouncerregistry
component "pgbouncer" as pgbouncerembedding

"Rails" --> pgbouncermain
pgbouncermain --> "main"

"Rails" --> pgbouncerci
pgbouncerci --> "ci"

"Rails" --> pgbouncerembedding
pgbouncerembedding --> "embedding"


"Container Registry" --> pgbouncerregistry
pgbouncerregistry --> "registry"


:User: --> "Rails"
:User: --> "Container Registry"
@enduml

現在、単一の本番データベースをホストする 4 つの異なるデータベースクラスターがあります。

データは organization_id によってシャーディングされ、organization_id は 1 つの Cell に存在できます。

Cells のロールアウト中、データのほとんどは現在のデータベースクラスターに残るため、これらの大規模なモノリシックシステムの要件にも対応することが重要です。

将来のアーキテクチャ

今後の Cells プロジェクトでは要件が異なります。 現在の見積もりでは、各 Cell は現在のモノリスと比較して比較的少数のユーザーをホストするため、多数の小さなデータベースクラスターをホストし、短期間でそれらを作成するという新たな課題が生じます。

正確な要件は時間とともに発展しますが、以下が要求されています:

• API を介したデータベースクラスターの作成と削除（Cell のプロビジョニングの一部となる）。
• リファレンスアーキテクチャのサイズまでのデータベースクラスター: 50,000 ユーザー API: 1000 RPS、Web: 100 RPS、Git（プル）: 100 RPS、Git（プッシュ）: 20 RPS。
• 最大 2,000 の Cell とデータベースクラスター。

現在の自動化には、各クラスターに専用の Chef ロールを作成するなど、多くの手動ステップが含まれています。 新しいクラスターを作成するための変更プロセスは、複数のマージリクエストとピアレビュー、そして Change Request による実行を必要とする最大のオーバーヘッドです。 これは新たに与えられた要件とは相容れません。

ただし、Cells は 1 つの Cell から始まる反復的な方式で開始され、1 つのデータベースクラスターが必要になります。 したがって、現在のプラットフォームは少なくとも Cells 1.0 には使用でき、すべてのデータが新しい Cell ローカルデータベースクラスターに保存されるまで維持できます。

また、複数の小規模 Cell への完全なシャーディングの前に、現在のデータを新しいデータベースプラットフォームに移行することも可能です。 これが望ましい場合は、現在のモノリスの要件もターゲットプラットフォームで満たす必要があります。

要件

要件は、GitLab.com のモノリシックデータストアに現在必要なものと、個々の Cell に見込まれるものに分けられます。

要件は以下のカテゴリーに分類できます。 それらは 高い、中程度、低い のいずれかになります。

• 高い: GitLab.com を運用するために必要。
• 中程度: 現在運用に必要だが、置き換えが可能。
• 低い: あれば望ましい。

共通要件

現在のプラットフォーム要件

パフォーマンス

パフォーマンスは重要な要素です。最初のタスクはパフォーマンスの概要を定義し、それが満たされているかどうかをテストするための信頼性の高い方法を確立することです。

{- TODO: パフォーマンス要件とテスト手順を定義する -}

以下の負荷ピークを観察しており、参考として使用できます:

• プライマリでの ~100k 読み書き TPS
  • Main プライマリでの ~80k TPS
  • CI プライマリでの ~32k TPS
• スタンバイ間で分散された ~1M 読み取り専用 TPS
  • Main スタンバイでの ~714k TPS
  • CI スタンバイでの ~150k TPS

Cells 要件

TODO: パフォーマンス要件を定義し、異なるステークホルダーと確認する。@rnienaber と議論し、最大のリファレンスアーキテクチャから始めます。

• 最大約 50,000 ユーザー、最大のリファレンスアーキテクチャ: 最大 50,000 ユーザー API: 1000 RPS、Web: 100 RPS、Git（プル）: 100 RPS、Git（プッシュ）: 20 RPS
• これは将来増加する可能性があるか、または現在のすべてのユーザーをホストするために数百の Cell が必要になる可能性があります。

分解

GitLab.com のアプリケーションデータは現在、Main と CI の 2 つの別々のデータベースクラスターに分解されています。 分解「セキュアおよびソフトウェアサプライチェーンセキュリティ関連テーブルを別の Postgres DB に分解する」によって、現在のプラットフォームにより多くのヘッドルームとスケーラビリティを得るために Main データベースをさらに分解できるかどうかを評価しています。

Cells では、組織をより少ない飽和 Cell に移動することで水平スケーリングするという設計上の選択があります。 Cells は分解が合理的な規模になるまで垂直スケールすべきではありません。 そのため、Cells 内での分解は必要なく、現在の Dedicated / GET / Cells ツールではサポートされて いません。 将来的に GET と Dedicated で分解のサポートを追加することは、中程度の複雑さのタスクとして可能です。

これに沿って、Cell ごとに単一のデータベースクラスターのみがプロビジョニングされ、必要なすべてのデータベースをホストできます。

概要 - 可能なソリューション

PostgreSQL 以外の提供

AlloyDB のように特定レベルの PostgreSQL 互換性を主張する非 PostgreSQL について簡単に検討しました。 コストとリスクが期待されるメリットとの比較において意味のある割合にないという結論に達しました。 さらなる調査を正当化する PostgreSQL 自体の固有の欠点は現在ありません。

詳細は以下を参照してください:

• Alternatives To Postgres DB (Google Spanner vs AlloyDB)
• Switching to a proprietary database, instead of PostgreSQL

Cloud SQL

Cloud SQL は Google の標準的な PostgreSQL 提供です。 これはカスタムフォークであり、アップストリームリリースと 100% 互換性があると主張されており、Cloud SQL ドキュメントでは単に PostgreSQL と呼ばれています。 GitLab は現在、Cloud SQL をサポートされた PostgreSQL 実装として認識しています。

上記の情報のほとんどは公式の Cloud SQL ドキュメントにあります。GCP チームから口頭で見積もりをもらいました（ミーティングノート Discuss Cloud SQL and AlloyDB with GitLab (internal)を参照）。

検証すべき事項

Cells イテレーションに基づいてスコープを分割 https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/#cells-iterations

Cells 1.0（初期スコープ）

（フォーカス: Cells 1.0 リリースの基盤的な検証と統合タスク）

Cells 1.0 のターゲットは、SaaS GitLab.com 提供を使用する社内顧客向けのソリューションを提供し、Cells の基盤的な作業を行うことです。

• CloudSQL のデータベース可観測性と自動テレメトリー収集ツールを GitLab の可観測性スイートに評価・統合する。
  • クエリインサイトは現在の可観測性ツールの十分な代替になるか？
  • Cloud SQL メトリクスと Cloud SQL システムインサイトを監視ツールにエクスポートする方法を検証する
  • CloudSQL クエリインサイトを監視ツールに統合する方法は？
  • PostgreSQL ログを Elastic にエクスポートする方法は？
• CloudSQL のバックアップとリカバリー戦略（ポイントインタイムリカバリー（PITR）を含む）を検証し、ゾーンの停止またはハードウェア障害時のダウンタイムを最小化するために CloudSQL の高可用性（HA）設定を確認する。
• SSL/TLS 証明書の設定と検証により、PostgreSQL 接続が暗号化されることを確認する。
• 自動ストレージ増加の動作 – 複数の連続したストレージ増加をトリガーし、増加間の「クールオフ」期間、運用上の遅延、パフォーマンス低下を観察する。
• インスタンススケーリングのダウンタイム – HA あり/なしでスケールアップ/ダウン時のダウンタイムを測定する。
• マイナーバージョンアップグレードの影響 – HA あり/なしでのマイナーバージョンアップグレード中のダウンタイムを検証する。

Cells 1.5（将来の検討事項と機能強化）

（フォーカス: 後のイテレーションの機能と検証）

Cells 1.5 のターゲットは、Cells 1.0 アーキテクチャを基に構築された SaaS GitLab.com 提供を使用する既存および新規エンタープライズ顧客向けの移行ソリューションを提供することです。

• 書き込みと読み取り専用ワークロードの両方に対して接続プーリングソリューションを検証する:
  • VM 上の PgBouncer
  • CloudSQL データベース接続管理 / Managed Connection Pooling (MCP)。セルフマネージドの PgBouncer と比較して機能が制限されています。
• CloudSQL Proxy を評価する
• データベース移行オプションを比較する:
  • ネイティブ論理レプリケーション - 論理レプリケーション機能（pglogical）
  • CloudSQL データベース移行サービス
  • また、CloudSQL からデータを移行するオプションも評価する。
• 50k リファレンスアーキテクチャでの PostgreSQL メジャーバージョンアップグレードの時間と影響を評価する。
  • CloudSQL には AWS RDS Blue/Green デプロイメントの直接的な相当物がないため、ソリューションを社内で設計する必要があります。
• 読み取りレプリカまたはバックアップからの新しいクラスターの作成にどのくらいかかるか？ 10GB、100GB、1TB、2TB？
• 遅延レプリカを含むディザスタリカバリオプションを評価する。
• ストレージ増加のパフォーマンス影響 – 手動ストレージ増加前後のクエリパフォーマンスを測定する。
• 高負荷ストレステスト – 大量のデータセットをロードし、持続的な書き込み集約的な操作を CloudSQL がどのように処理するかを測定する。

Dedicated デプロイメントとの差分を評価する

• より細かい粒度（10 秒未満）の拡張モニタリングを、カスタムクエリ（例: pg_stat_activity、pg_stat_statements）を含む Postgres Exporter と、より頻繁なスクレイピングを行う Prometheus を使用して実装するオプションを評価する。
• スタンバイレプリカへの読み取り操作のオフロードを評価する。
• 「Enable auto minor version upgrade」を評価する。
• 「Dedicated Log Volume」によるパフォーマンス改善を評価する。
• ロギングレベルを上げて、スロークエリ、一時使用、autovacuum、ロック待機、接続/切断、DDL 文をキャプチャする。
• pg_stat_statements 設定を構成する。
• auto_explain をロードして設定する。
• 「論理バックアップ」ソリューションを実装する。
• Cloud Monitoring と Alerting を確認する。

k8s Operator

現在、実行可能と思われる複数の利用可能な Operator がありますが、要件が満たされることを確認するための詳細な評価とベンチマークが重要です。 ゼロダウンタイムアップグレードが欠けている可能性がある機能の一つです。 現在も独自の自動化を維持しており、Operator がこの機能を提供するまで適応させることができます。

検証すべき事項

• 候補の比較（4〜5 週間）
  • CYBERTEC PostgreSQL Operator（zalando と商用サポート）
  • CloudNativePG

Amazon RDS PostgreSQL

Amazon Relational Database Services PostgreSQL は AWS のマネージドデータベースサービスで、PostgreSQL コミュニティバージョンと完全な互換性を提供します。実際、Amazon は PostgreSQL コミュニティバイナリをRDS インスタンスの基盤となるインフラストラクチャにパッケージしてデプロイするだけです。 GitLab は現在、Amazon RDS PostgreSQL をサポートされた PostgreSQL 実装として認識しています。

検証すべき事項

• RDS パフォーマンスインサイトメトリクスをエクスポートする方法を検証する
• PostgreSQL ログを Elastic にエクスポートする方法は？
• 書き込みと読み取り専用ワークロードの両方に対して接続プーリングソリューションを検証する
  • VM 上の pgbouncer
  • RDS Proxy
• 移行オプションを比較する
  • ネイティブ論理レプリケーション
  • Amazon データベース移行サービス
• 50k リファレンスアーキテクチャでのメジャーバージョンアップグレードの時間と影響を評価する
  • Blue/Green デプロイメントも評価する
• 読み取りレプリカまたはバックアップからの新しいクラスターの作成にどのくらいかかるか？ 10GB、100GB、1TB
• Blue/Green メジャーバージョンアップグレード方法でデータベースサービスのダウンタイムはどのくらいか？
  • Blue/Green デプロイメント中の影響を軽減するために pgbouncer または RDS Proxy がリクエストを保持できるかどうかもテストする必要があります。

現在の Dedicated-RDS デプロイメントとの差分を評価する

• 小さな粒度（10 秒未満）での Enhanced Monitoring の有効化のコスト
• スタンバイレプリカへの読み取り操作のオフロードを評価する
• 「Enable auto minor version upgrade」を評価する
• 「Dedicated Log Volume」によるパフォーマンス向上を評価する
• ロギングレベルを上げる: スロークエリ、一時使用、autovacuum、ロック待機、接続/切断、DDL 文
• pg_stat_statements 設定を構成する
• auto_explain をロードして設定する
• 「論理バックアップ」ソリューションを実装する
• アラームを確認する: RDS イベントサブスクリプション、AWS Cloud Watch

現在の自動化のリファクタリング

GitLab.com のすべての PostgreSQL クラスターをホストするための現在のプラットフォームは主に Terraform と Chef に基づいており、GCP の仮想マシンを管理しています。 一部の複雑な操作は Ansible によってオーケストレーションされています。

このアーキテクチャの現在の主な問題は歴史的な成長と技術的負債です。 単一または少数固定のデータベースクラスターをホストするために設計されています。 理論的には任意の数のクラスターをホストすることは可能ですが、手動のステップとオーバーヘッドが必要です。

これらの非効率性は、多数のデータベースクラスター（例: >100）をホストするという推定要件とは相容れません。

例:

• 各データベースクラスターに対して複数の Chef ロールを作成する必要があります
• 各データベースクラスターに対して手動でネットワークサブネットを定義して設定ファイルに記述する必要があります
• ポリシーとして、本番環境の各データベースクラスターに相当するものがステージング環境にある必要があります

これらの欠点とボトルネックは、Chef による自動化の改善や別のツールセットへの置き換えによって解消できます。

Cells 1.0

Cells 1.0 は Cells の最初のイテレーションであり、2024 年中に GA となる予定です。 この最初のイテレーションでは限られた数のテストユーザーとプロジェクトのみをホストするため、完全な要件はありません。 これはデータベースプラットフォームを学習し、イテレーションする機会です。

開発中に Cell の数は 1 から最大 10 まで増加する可能性があります。 2 番目の Cell が作成されるまでに数ヶ月かかると見込まれており、2 番目のクラスターが必要になります。

Cloud SQL は現在、与えられた高優先度の要件を満たしていませんが、それらを完全に含むロードマップもありません。 それにもかかわらず、Cells 1.0 のタイムラインをブロックしないように、一時的に Cloud SQL を使用します。 そのため、関連するリスクとボトルネックを認識し、同意します。

• 最終プラットフォームへの移行にはダウンタイムが発生します！
• サービスの品質は GitLab.com と同等にはなりません。
  • 深いレベルのサポートに対する明確な SLO がありません。
  • 合理的なダウンタイムでのメジャーバージョンアップグレードができません。
• この解決策を 50k ユーザーのターゲットに向けて確実に成長させることはできず、すでに 3k ユーザーで接続プーリングに問題が生じています。

要件を満たすソリューションの発見を優先し、Cells 1.0 の後に利用可能にします。 最も有望な候補は、PostgreSQL as a Service のような体験を提供する既存の k8s PostgreSQL Operator です。

Cells 1.x

Cells 1.0 で強調されているように、長期的な要件に十分なプラットフォームを構築するリソースを解放するために、一時的なソリューションとして Cloud SQL から始めます。

最初のフェーズでは、利用可能な k8s Operator を評価し、完全な評価のための最も適合する候補を絞り込みます。

現在のデータベースプラットフォーム

現在のデータベースプラットフォームは将来の成長において制限がありますが、現在飽和の限界には達していません。 データベースがいつボトルネックになるかは明確ではありませんが、分解前の過去の経験に基づくと、200% の規模のデータベースは運用上の課題をもたらします。

データベースが 2 倍のサイズになるまでの時間についての予測は現在ありませんが、次の 24 ヶ月以内（2026 年まで）にはそれが起きないと見込むのが妥当です。

これは、重要なデータを Cell に移行するか、ここでもデータベースプラットフォームを改善/変更するための十分な時間を与えます。

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