This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
ongoing @grzesiek @ayufan @grzesiek @jporter @cheryl.li devops verify 2021-09-10

CI/CDデータの時間減衰

要約

GitLab CI/CDはGitLabの中で最もデータと計算量の多いコンポーネントの一つです。2012年の最初のリリース以来、CI/CDサブシステムは大きく進化してきました。2015年9月にGitLabにインテグレーションされ、最も愛されているCI/CDソリューションの1つになりました。

2021年2月1日、GitLab.comはCI/CDビルド数10億を突破し、ビルド数は指数関数的に増え続けています。

GitLab CI/CDは最初のリリースから長い道のりを歩んできましたが、パイプラインビルドのためのデータストレージの設計は2012年からほとんど変わっていません。2021年に私たちはデータベースの分解に取り組み始め、CI/CDデータを別のデータベースに抽出しました。今、私たちはGitLab CI/CD製品のアーキテクチャを改善し、さらなるスケーリングを可能にしたいと考えています。

目標

CI/CDデータストレージの新しいアーキテクチャを実装し、スケーリングを可能にします。

課題

GitLab.comのデータベースには、CI/CDビルドを記述した20億以上の行があります。このデータは、GitLab.comで稼働しているPostgreSQLデータベースに保存されているデータ全体のかなりの部分を占めています。

この量は重大なパフォーマンス問題や開発者の課題に貢献し、しばしばプロダクションインシデントに関係しています。

また、GitLab.comで実行されるビルドの数は、今後数年で大幅に増加することが予想されます。

機会

CI/CDデータは時間の経過とともに減衰します。なぜなら、通常、数ヶ月前のパイプラインは頻繁にアクセスされないか、もはや関連性がないからです。数ヶ月以上前のパイプラインへのアクセスを制限することで、このデータをプライマリデータベースから別のストレージに移すことができます。

アーカイブされたビルドを処理しないようにすることはすでに可能です。ビルドがアーカイブされると、それを再試行することはできなくなりますが、それでも私たちはすべての処理メタデータをデータベースに保持しており、プライマリ・データベースに不足しているリソースを消費しています。

パフォーマンスを向上させ、CI/CDデータストレージのスケーリングを容易にするために、以下の3つのトラックに従うことをお勧めします。

pipeline data time decay

  1. CI/CDビルドのキューイングデータベースのテーブルをパーティショニングします。
  2. CI/CDパイプラインのデータベーステーブルのパーティショニング
  3. ビルド・メタデータ・テーブルの増加率を削減

ビルド・メタデータ・テーブルの増加率を削減

ビルド（あるいはパイプライン）がアーカイブされると、そのパイプラインの処理を再開することはできなくなります。つまり、ビルドを効率的かつ確実に処理するために必要な、PostgreSQLに格納されているすべてのメタデータは、安全に別のデータストアに移動できるということです。

この種のCI/CDデータはCI/CDテーブルに格納されているデータのかなりの部分を占めるため、パイプライン処理データの格納は高価です。いったんアーカイブされたパイプラインの処理へのアクセスを制限すれば、このメタデータを別の場所 - できればオブジェクトストレージ - に移動して、本当に必要になったときに（例えばコンプライアンスや監査の目的で）オンデマンドでアクセスできるようにすることができます。

データの移動が最適なソリューションかどうかを評価する必要があります。メタデータ・エントリーの重複排除やその他の正規化戦略を使って、このデータセットをクエリする能力を維持しながら、より少ないストレージを消費できるかもしれません。最適な解決策を見つけるには技術的な評価が必要です。

エピック：ビルドのメタデータ・テーブルの増加率を削減します。

CI/CDパイプラインのデータベーステーブルのパーティショニング

CI/CDメタデータを別のストアに移動したり、別の方法でメタデータの増加率を抑えたりしても、パイプライン、ビルド、アーティファクトを記述した何十億もの行があるという問題は残ります。オブジェクトストレージに保存するメタデータへの参照を保持し、この情報を一括して確実に取得（または検索）できる必要があります。

オブジェクトストレージにデータを移行しても、CI/CDテーブルの行数を減らすことはできないということです。オブジェクトストレージにデータを移動することは、データサイズの縮小には役立つはずですが、このデータを記述するエントリーの量を減らすことには役立ちません。この制限のため、データベースへの影響（インデックスサイズ、自動バキューム時間、頻度）を減らすためにCI/CDデータをパーティショニングしたいと思います。

ここで意図しているのは、このデータをプライマリデータベースから別の場所に移すことではありません。PostgreSQLのパーティショニング機能を使って、CI/CDデータを格納する非常に大きなデータベーステーブルを複数の小さなテーブルに分割したいのです。

CI/CDデータのパーティショニングにはいくつかのアプローチがあります。有望なのはリストベースのパーティショニングで、パーティション番号はパイプラインに割り当てられ、そのパイプラインに関連するすべてのリソースに伝搬されます。これは、このパーティショニング戦略を自由に拡張できるため、非常に柔軟性があります。例えば、この戦略では、複数のパーティショニング・キーに基づいて任意のパーティション番号を割り当てることができます。

めったにアクセスされないデータのパーティショニングも、一貫性と信頼性を高めるために、ビルドのアーカイブ用に定義されたポリシーに従う必要があります。

エピック：CI/CD パイプラインのデータベーステーブルをパーティショニングします。

このトピックの技術的な詳細については、パイプラインのデータ パーティショニング設計を参照してください。

CI/CDビルドのキューイングデータベースのテーブルをパーティショニングします。

CI/CD Scaleブループリントに取り組んでいる間に、CI/CDビルドをキューに入れて実行するための新しいアーキテクチャを導入しました。

これにより、パフォーマンスを大幅に改善することができました。私たちはこの新しいソリューションを、次のイテレーションに取り掛かる前に必要な中間的なメカニズムだと考えています。次のイテレーションでは、ビルドのキューイングのアーキテクチャをさらに改善する必要があります（PostgreSQLから完全に、あるいは部分的に移行する必要があるかもしれません）。

その間に私たちは、より柔軟で信頼性の高いソリューションに向けた中間段階として、別のイテレーションを出荷したいと考えています。データベースへの影響を減らし、信頼性とデータベースの健全性を向上させるために、新しいキューイングテーブルを分割したいと考えています。

CI/CDキューイングテーブルのパーティショニングは、ビルドアーカイバルのために定義されたポリシーに従う必要はありません。その代わりに、24時間以上前に作成されたビルドはキューから削除する必要があるという長年のポリシーを活用すべきです。このビジネスルールは GitLab CI の初期から製品に存在しています。

エピックCI/CD ビルドをキューイングするデータベーステーブルをパーティショニングします。

このトピックの技術的な詳細については、パイプラインのデータ パーティショニング設計を参照してください。

原則

CI/CDタイムディケイパターンを実装するために使用する3つのトラックは、いずれもいくつかの課題を伴います。実装が進むにつれて、私たちは多くの問題を解決し、これを成功させるために多くの実装の詳細を考案する必要があります。

以下に、このアーキテクチャの青写真に記載されているビジョンを誰もが理解しやすくするために、いくつかの基本原則を文書化しました。

パイプラインデータの削除

古いデータやアーカイブされたデータをデータベースから削除したくなるかもしれませんが、これは避けるべきです。同意がない限り、ユーザーデータを永久に削除することは通常望まれません。しかし、オブジェクトストレージのような別のデータストアにデータを移動することはできます。

アーカイブされたデータが必要になることもあります（コンプライアンスや監査上の理由など）。永久削除がユーザーによって要求または承認されていない限り、必要に応じてこのデータを取得できるようにしたいと思います。

UIでのパイプラインデータへのアクセス

パーティショニングによってCI/CDデータのタイムディケイを実装することは、ユーザーが多くのパーティションに格納されたデータにアクセスできるようにしたい場合、難しいかもしれません。

UIでパイプラインデータにアクセスするシンプルさを維持したいのです。そのためには、他のリソースからパイプラインデータを参照する方法を多少変更する必要がありますが、ユーザーがUIでパイプラインを見つけることを難しくしたくありません。

パイプラインやビルドの一覧ページに “Archived” タブを追加する必要があるかもしれませんが、マージリクエストやデプロイに関連するパイプラインの状態やビルドを表示したいときに、追加のステップやクリックを避けることができるはずです。

また、パイプライン/ビルド一覧ページの “Archived” タブでの検索を無効にする必要があるかもしれません。

APIによるパイプラインデータへのアクセス

APIを通じてパイプラインデータにアクセスするために必要なAPIエンドポイント/エンドポイントを別途構築する必要がある可能性を受け入れます。

新しいAPIでは、ユーザーはパイプライン/ビルドを検索するためにデータが作成された時間範囲を指定する必要があるかもしれません。効率的にするために、一度に2つ以上のパーティションに存在するデータのクエリへのアクセスを制限する必要があるかもしれません。そのためには、ビルドのアーカイブポリシーに等しい期間をサポートする必要があります。

ユーザーが提供するパーティション識別子が必要な場合もありますが、旧APIを使用してアーカイブされたパイプラインデータにアクセスすることは可能です。

イテレーション

3つのトラックはすべて並行して作業することができます：

  1. ビルドのメタデータ・テーブルの増加率の削減。
  2. CI/CD パイプラインのデータベーステーブルをパーティション分割します。
  3. リスト・パーティショニングを使用したCI/CDキューイング・テーブルのパーティショニング

ステータス

進行中

タイムライン

  • 2021-01-21:ParentCI Scalingブループリントのマージリクエストが作成されました。
  • 2021-04-26:CI Scaling ブループリントが承認されマージされました。
  • 2021-09-10:CI/CD data time decay ブループリントの議論が始まりました。
  • 2022-01-07: CI/CD data time decay blueprint がマージされました。
  • 2022-02-01: ブループリントが新しいコンテンツとエピックへのリンクで更新されました。
  • 2022-02-08:パイプライン分割のPoCマージリクエストが開始されました。
  • 2022-02-23:パイプライン分割PoC成功。
  • 2022-03-07: 既存のテーブルをパーティションとしてアタッチする方法が見つかりました。
  • 2022-03-23:パイプラインパーティショニングデザインGoogleドキュメント(GitLab内部)開始：https://docs.google.com/document/d/1ARdoTZDy4qLGf6Z1GIHh83-stG_ZLpqsibjKr_OXMgc.
  • 2022-03-29:パイプラインパーティショニングPoC終了。
  • 2022-04-15:パーティショニングされたパイプラインのデータアソシエーションPoCが出荷されました。
  • 2022-04-30:影響評価のための追加ベンチマーク開始。
  • 2022-06-31:パイプライン・パーティショニング設計ドキュメントのマージリクエストがマージされました。
  • 2022-09-01:パーティショニングを実装するためのエンジニアリング作業が開始されました。
  • 2022-11-01:最も急速に成長しているCIテーブルがパーティショニングされました:ci_builds_metadata.