Sec DB 分解 ワーキンググループ

このワーキンググループの使命は、GitLab 内の Sec データセットの分解を成功させることです

属性

プロパティ値
作成日2024年5月1日
開始日2024年5月13日
終了日2025年8月4日
Slack#wg_sec-database-decomposition（社内からのみアクセス可能）
Google Docワーキンググループ アジェンダ（社内からのみアクセス可能）
Issue ボードEpic ダッシュボードリスト
ミーティング頻度毎週月曜日。録画あり。EMEA および APAC のオプションあり。

完了基準

このワーキンググループの使命は以下の通りです。

  • GitLab.com の主要 DB への負荷を軽減し、将来のスケーラビリティと安定性の課題を支援するために、Sec データセットを別の gitlab_sec データベースへの分解を成功させる。
  • 関連テーブルの GitLab.com DB パフォーマンスと最適化に向けた追加の取り組みの優先順位付けと実装に関連した分解のタイミング、スコープ、および影響を検討する - OKR（GitLab 内部）
  • 機能の同等性、パフォーマンス / ハードウェア要件、異なるサイズの DB に対する改善、および管理者のサポート努力に関するセルフマネージドインスタンスへの分解の影響を評価する。

セルフマネージドまたは Dedicated でのデコンポジションのサポートは、このワーキンググループのスコープ外です。

目標

ワーキンググループのスコープ内で達成したい重要な結果であり、成果が最も望ましい結果を確保するためのものです。

目標備考達成日
可能な限り、実装によって CI 分解の結果と同様に、セルフマネージドユーザーのコストや負担が増加しないようにする。
変更はリファレンスアーキテクチャによって承認され、適切にドキュメント化されている。必要なアドバイスをアドホックに集めるために、リファレンスアーキテクチャトラッカーに Issue を提起する。
分解のプロセスで GitLab.com への混乱を最小限に抑える。カットオーバー前にデータベースへのすべてのトラフィックを停止する必要がある物理レプリケーションを選択する場合、これは避けられない可能性があります。

用語集

推奨用語意味使用しない用語例
クラスターデータベースクラスターは、データを複製する相互接続されたデータベースインスタンスの集合です。GitLab.com の PostgreSQL クラスター（Patroni によって管理）。メインの論理データベースをホストし、プライマリデータベースインスタンスとその読み取り専用レプリカで構成されています。
分解（Decomposition）機能が所有するデータベーステーブルが、複数のデータベースインスタンス上の多くの論理データベースにあります。GitLab.com においては、望ましい分解の成果にはこれらのインスタンスを異なるデータベースサーバーに分離することも含まれます。アプリケーションはさまざまな操作（ID 生成、リバランシングなど）を管理します。Y-Axis、垂直シャーディングコアテーブルとは別の論理データベースにあるすべての Sec テーブル。設計図
インスタンスデータベースインスタンスは、データベースサーバーで実行されている関連プロセスで構成されています。各インスタンスは独自のデータベースプロセスセットを実行します。Physical Database
論理データベース論理データベースはスキーマやテーブルなどのデータベースオブジェクトを論理的にグループ化します。データベースインスタンス内で利用可能で、他の論理データベースとは独立しています。DatabaseGitLab の Rails データベース。
ノードこのワーキンググループの文脈ではデータベースサーバーに相当します。Physical Database
レプリケーションバイアスなしのデータのレプリケーション。X-Axis、クローニング読み取りトラフィックを書き込みトラフィックから分離できるようにするためにデータベースクラスターで行うこと。
WAL（Write Ahead Log）Write Ahead Log は Postgres が挿入されたデータを記録するメカニズムです。WAL レコードは別のプロセスで格納されたデータセットを変更するために処理されます。これらのログはレプリケート可能です。
論理レプリケーションPUB-SUB モデルを介して WAL を転送するために組み込みの Postgres レプリケーションプロセスを使用したデータのレプリケーション
物理レプリケーション書き込まれたディスク上の実際のファイルを新しい物理データベースにコピーすることによるデータのレプリケーション。
アプリケーションレプリケーションGitLab 自体のレプリケーションルーティンの設定によって別のデータベースにデータをレプリケーション。
DB スキーマSQL データベーススキーマはテーブル、ビュー、インデックス、データ型、関数、ストアドプロシージャ、演算子などの名前付きデータベースオブジェクトを含む名前空間です。ドキュメント参照
GitLab DB スキーマ基礎となるデータベース接続を抽象化するアプリケーションレベルのテーブル分類スキーマ。ドキュメント参照
サーバーデータベースサーバーは1つ以上のデータベースインスタンスを実行しているオペレーティングシステムを実行している物理または仮想システムです。Physical Database
テーブルデータベーステーブルは共通のデータ構造（同じ数の属性、同じ順序、位置ごとに同じ名前と型）を持つタプルの集合です（ソース）。
テーブルパーティショニングパーティションテーブルのデータの一部を含むテーブル（水平スライス）。（ソース）Partition
データセット論理データベース内に含まれるテーブルとそのデータのセット。Sec データセットには、脆弱性や依存関係追跡を含む（ただしこれに限定されない）GitLab のセキュリティ機能に関連するすべてのテーブルが含まれます。
フィーチャーセット参照のしやすさのために GitLab 内の何らかの概念に関連付けられた機能のセット。Core、Sec
Coreデータセットまたはフィーチャーセットの観点から、プロジェクト、名前空間、ユーザーなど、標準的な GitLab の操作に関連した情報または機能です。
Secデータセットまたはフィーチャーセットの観点から、脆弱性、依存関係（SBOM）、セキュリティの知見、ポリシーなど、標準的な GitLab の操作に関連した情報または機能です。

概要

GitLab 内では、主要な GitLab データベースサーバーへの負荷を軽減するための強い要求があります。データベースおよびスケーラビリティチームは、長期的に GitLab の成長と安定性を維持するために、データベースサーバーへの継続的な負荷を軽減するためのさまざまな手段を講じています。そのひとつが Cells ですが、短期から中期的に追加の軽減策を提供したいという要望があります。過去の CI 分解が同様の課題に対処したのと同様に、主要データベースからの Sec データセットの分解が強力な解決策として特定されました。

Sec データセットの分解は、これらの機能に関連するデータインタラクションの規模の大きさから、重要なエンジニアリング作業です。このドメインはすべてのデータベース書き込みトラフィックの25%を占めており、フィーチャーセットを拡張し顧客ベースを成長させるにつれて増加する一方です。さらなる統計と技術的な詳細は関連する Epic で確認できます。

GitLab.com 全体のスケーラビリティと安定性の懸念事項となり、継続的に増大するパフォーマンスの懸念から Sec セクションのステージが新機能を実装する能力を著しく制約しているため、このプロジェクトを効果的に達成するための組織的な取り組みを形成する必要があります。

私たちには、過去の CI データベースの分解を達成したデータベーススケーラビリティ ワーキンググループの先行事例と経験から大きく恩恵を受けられるというメリットがあります。しかし、直面する可能性のある主な課題は、既存の Sec コードベースの規模と、顧客ベースへの（なし / 最小限の）中断でオペレーションを継続する必要性です。顧客とのアップタイム SLA 契約のため、完全な GitLab.com のダウンタイムは強く忌避されていますが、私たちのオペレーションの規模によっては、このような分解のための一部のプロセスが実行不可能な場合があります。

メリット

  1. Cells 1.5 に先立って GitLab.com の主要書き込みデータベースへの書き込み負荷を軽減する
  2. 主要データベースを Sec 機能の負荷から分離することで、GitLab オペレーションの安定性を向上させる
  3. 懸念事項の分離により、Core と Sec の両方のフィーチャーセットの全般的なパフォーマンスを向上させる
  4. プラットフォームの安定性を損なう重大な懸念なしに Sec 機能開発のイテレーション速度を向上させる

リスク

  1. 現在未知の期間にわたる重大な開発者のコミットメント。
  2. 新しい分解されたデータベースとそれに関連するレプリカに対する増加したデータベースメンテナンス要件。
  3. Cells 2.0 のリリース前に提供できない可能性がある。
  4. GitLab.com の完全なダウンタイムが必要な場合があり、顧客との調整が難しい可能性がある。

相互依存関係

Sec データはユーザー、プロジェクト、名前空間などの CI や標準的な GitLab データと高度に統合されています。過去の CI 分解は、関連する CI データセットのクエリの相互依存性をうまく解除しましたが、コア GitLab データセットと Sec 機能の間で同じことを行うには多大な努力が必要です。

タイムライン

グループは段階的なロールアウトは主要なデータベースクラスターへの負荷を軽減せず、実施すべき作業量が増加するため推奨しないと判断しました。そのため、すべてのスライスが gitlab.com に同時にロールアウトされます。

進捗

gantt
dateFormat YYYY-MM-DD
title 推定分解タイムライン

section タイムライン
GitLab 分解準備完了 :active , decompose, 2024-07-01, 2025-02-14
スライス外作業 :active, nonslicework, 2024-07-15, 2025-02-14
スライス 1 :active, slice1, 2024-07-23, 2025-01-13
スライス 2 :active, slice2, 2024-08-06, 2024-12-30
スライス 3 :active, slice3, 2024-07-15, 2025-02-10
GitLab アプリケーション分解準備完了 :milestone, allslices, after slice1 slice2 slice3 nonslicework, 0d
フェーズ 1 & 2 : phase12, 2024-09-11, 16w
フェーズ 4 : phase4, 2025-03-14, 3w
フェーズ 5 : phase5, after phase4, 1w
フェーズ 6 : phase6, 2025-03-21, 3w
フェーズ 7 : phase7, after phase6, 1w
ロールアウト完了 :milestone, rollout, 2025-04-19, 1d
axisFormat  %Y-%m-%d

ソース。

分解
スライス完了率推定完了日
スライス 1100%完了
スライス 2100%完了
スライス 3100%完了
スライス外作業97%2025-02

最終更新日: 2025-02-18。

計画

  1. 別の gitlab_sec スキーマを導入する
  2. gitlab_sec データベース接続を導入する（デフォルトでは gitlab_main データベースへのフォールバックを使用）
  3. 並行して、SBOM、セキュリティ、脆弱性コード境界の大まかな順序に従って外部キーとクロスデータベーストランザクションの分解を開始する。各スライスについて以下の分解を実施する：
    1. 参照性の低いテーブル（外部キーが少ない）を移行する
    2. 参照性の高いテーブル（外部キーが多い）を移行する
    3. 対処すべきクロスジョインをホワイトリストに登録して特定する
    4. 対処すべきクロスデータベーストランザクションを特定してホワイトリストに登録する
    5. 以前に特定されたクロスジョインおよびクロスデータベーストランザクションの許可を削除する
  4. 新しい物理データベースへの Sec データセットの安全な移行のための論理レプリケーションパスを策定する
  5. 分解スコープ内のすべてのテーブルに対して単一のレプリケーションイベントを使用してテーブルを移行するための変更リクエストを開く

データ移行提案

詳細についてはロールアウトを参照してください。

  1. 物理から論理レプリケーションを使用して、論理レプリケーションに変換する前に完全な DB をレプリケートします
    1. 分解されたデータベースインスタンスをメインのストリーミングレプリカとしてデプロイする
    2. 新しいデータベースインスタンスへの全 Sec データのレプリケーションを開始する
    3. 同じメイン DB を指す別の sec DB 接続を確立する
    4. GitLab.com が新しい DB 接続を汎用的にすべての Sec 機能に対して使用し始めるために必要なコードを記述する
    5. これは潜在的にリスクの高い操作であるため、本番スナップショットの準備が整っており、失敗時の問題やデータロスについて顧客に十分な情報提供がなされていることを確認する
    6. 新しいデータベースインスタンスを新しいプライマリとして使用する Sec フィーチャーセットの移行テストを開始する（gstg -> canary -> grpd）
    7. 成功した場合、完全なフィーチャーセットに対して分解されたデータベースの使用をグローバルにロールアウトする
  2. GitLab のメインデータベースからレガシーの sec テーブルを切り捨てる

役割と責任

ワーキンググループの役割担当者職位
エグゼクティブステークホルダーJerome NgEngineering Director, Expansion
機能リードGregory HavengaSenior Backend Engineer, Govern: Threat Insights
機能リードLucas CharlesPrincipal Software Engineer, Sec
ファシリテーター AMERNeil McCorrisonManager, Software Engineering
ファシリテーター APACThiago FigueiróManager, Software Engineering
メンバーFabien CatteauStaff Engineer, SSCS: Pipeline Security
メンバーArpit GogiaBackend Engineer, AST: Dynamic Analysis
メンバーSchmil MondererStaff Backend Engineer, APM: Threat Insights
メンバーEthan UrieStaff Backend Engineer, AST: Secret Detection
メンバーJon JenkinsSenior Backend Engineer, Database
メンバーVed PrakashStaff Data Engineer, Data Science
メンバーDylan GriffithPrincipal Engineer, Create
メンバーThong KuahPrincipal Engineer, Data Stores
メンバーRick MarManager, Core Infrastructure

関連パフォーマンスプロジェクト

  1. タプル削減
    • Brian Williams（DRI）
    • Fabien Catteau
    • Michael Becker
  2. 脆弱性管理アプリケーション制限と脆弱性管理保持ポリシー
    • Mehmet Emin Inaç（DRI）
    • Joey Khabie
  3. Cells 1.0
    • Subashis Chakraborty（DRI）

参考資料

参考説明
リンクGitLab デプロイメントアーキテクチャにおける複数データベースサポートレベルの提案。
リンク分解完了に向けた残作業追跡のための Epic ダッシュボード

謝辞

多くの情報、インスピレーション、経験は CI データベースの分解を成功させたデータベーススケーラビリティ ワーキンググループから享受しています。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License