• 要約
• 目標
• 課題
  • 主キーを保存する容量が不足していました：To-Doone
  • 一部の CI/CD データベーステーブルが大きすぎます：進行中
  • キューイングメカニズムが大きなテーブルを使用していました：To-Doone
  • 大量のデータの移動は困難です：進行中
• 提案
• イテレーション
• ステータス
• 誰

CI/CD スケーリング

要約

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

GitLab CI/CDは最初のリリースから長い道のりを歩んできましたが、パイプラインビルドのデータストレージの設計は2012年からほとんど変わっていません。私たちはPostgreSQLのci_builds テーブルにすべてのビルドを保存しています。GitLab.comで毎日500万以上のビルドを作成しているため、データベースの限界に達し、開発速度が遅くなっています。

2021年2月1日、GitLab.comは作成されたCI/CDビルドが10億を突破しました。2022年2月には、データベースに保存されたCI/CDビルドが20億に達しました。ビルドの数は指数関数的に増え続けています。

下のスクリーンショットは2021年の初めに作成した予測ですが、これはかなり正確であることがわかりました。

目標

1日に2,000万ビルドを処理できるようにすることで、将来の成長を可能にします。

課題

将来の成長を維持するためには、CI/CD製品のアーキテクチャを更新する必要があります。

主キーを保存する容量が不足していました：To-Doone

ci_builds テーブルの主キーは整数値で、シーケンスで生成されます。歴史的に、Railsはテーブルの主キーを作成するときに整数型を使用していました。2012年に ci_builds テーブルを作成したときにも、デフォルトを使用していました。Rails5のリリース以降、Railsの動作が変わりました。フレームワークは現在、8バイト長のbigint 型を使用していますが、ci_builds テーブルの主キーをまだbigint にマイグレーションしていません。

2021年初頭、私たちはci_builds 2021年12月までに ci_buildsテーブルに主キーを格納する整数型の容量がなくなると見積もっていました。もし、ci_builds 実行可能な回避策や緊急計画がないままこのような事態が起こっていたら、GitLab.comはダウンしていたでしょう。 ci_buildsInt4配列で利用可能な主キーを使い果たしていた多くのテーブルの一つにすぎません。

2021年10月までに、私たちのデータベース・チームはすべての危険なテーブルの主キーを大きな整数にマイグレーションすることができました。

詳細は関連エピックをご覧ください。

一部の CI/CD データベーステーブルが大きすぎます：進行中

ci_builds テーブルには20億以上の行があります。このテーブルには何テラバイトものデータが格納されており、インデックスのサイズもテラバイト単位になります。

このデータ量は、私たちのCI PostgreSQLデータベースで経験する多くの性能問題に貢献しています。

問題のほとんどは、PostgreSQLデータベースが内部でどのように動作しているか、データベースが稼働しているノードのリソースをどのように利用しているかに関連しています。私たちはCIのプライマリデータベースノードの垂直スケーリングの限界にあり、GitLab.comが依存しているCIデータベースの全体的なパフォーマンス、安定性、スケーラビリティ、予測可能性にci_builds テーブルが悪影響を及ぼすのを頻繁に目にします。

また、開発環境では問題ないと思われるクエリがGitLab.comでは動作しないことがあるため、テーブルのサイズは開発者の開発速度を妨げます。環境間のデータセットサイズの違いは、最も単純なクエリでさえもパフォーマンスを予測することを難しくしています。

ci_builds をさらに拡張する可能性を制限しているため、チームメンバーや幅広いコミュニティメンバーはベリファイ領域に貢献するのに苦労しています。私たちの静的解析ツールは、このテーブルにこれ以上のカラムを追加することを妨げています。新しいクエリを追加することは、データセットのサイズとテーブルを使用して実行されるクエリの量から予測不可能です。これは開発者の開発速度を著しく妨げ、本番環境でのインシデントに貢献します。

また、今後数年間で、指数関数的な大幅な成長が見込まれています。

FacebookのProphetを使った予測によると、2024年の前半には、GitLab.comで毎日2,000万ビルドが作成されるようになると予想されています。これに対して、現在作成されているのは約500万です。これは2021年の10倍の成長です。

ステータス2021年10月現在、ci_builds_metadata テーブルにビルドオプションと変数を書き込むことで、ci_builds テーブルの増加率を減らしました。また、最大のCI/CDデータベーステーブルを時間減衰パターンを使ってパーティショニングすることに取り組んでいます。

キューイングメカニズムが大きなテーブルを使用していました：To-Doone

テーブルが非常に大きいため、保留中のビルドのキューを構築するために使用したメカニズム（キューは1つだけではありません）は、あまり効率的ではありませんでした。保留中のビルドは、ci_builds テーブルに保存されているビルドのごく一部ですが、処理する順番を決めるために、この大きなデータセットからビルドを見つける必要がありました。

この仕組みは非常に非効率的で、本番環境で頻繁に問題を引き起こしていました。その結果、CI/CDのApdexスコアが大幅に低下し、時には本番環境のパフォーマンスが大幅に低下することさえありました。

パフォーマンスと信頼性を改善するために検討した戦略は他にも複数ありました。私たちはRedisキューイングや、キューの構築に使用するSQLクエリを高速化する別のテーブルを使用することを検討しました。私たちは後者を採用することにしました。

2021年10月、私たちはGitLab.comでのビルド・キューイングの新しいアーキテクチャの出荷を終えました。そして、新しいアーキテクチャを一般に公開しました。

大量のデータの移動は困難です：進行中

我々はci_builds テーブルに大量のデータを保存しています。このテーブルのいくつかのカラムには、ユーザーが提供したデータがシリアライズされて格納されています。カラムci_builds.options には600ギガバイト以上、ci_builds.yaml_variables には300ギガバイト以上のデータが格納されています（2021年2月現在）。

これは、確実に別の場所に移動する必要がある多くのデータです。残念ながら、現在、私たちのバックグラウンドマイグレーションは、この量のデータを大規模にマイグレーションするのに十分な信頼性がありません。カラム間、テーブル間、パーティション間、あるいはデータベースシャード間で、このデータを確実に移行できるメカニズムを構築する必要があります。

バックグラウンドマイグレーションを改善するための努力はデータベースチームが行います。

ステータス進行中。別のアーキテクチャ設計図に記載される更なる改善を出荷する予定です。

提案

CIスケーリングの取り組みをどのように進めたいかについて、2021年初頭に行われたオリジナルの提案を以下に掲載します：

GitLabのCI/CDプロダクトを、今後数年で予想される規模に対応できるようにすることは、多段階の取り組みです。

まずは、今緊急に必要なことに集中したいと思います。主キーのオーバーフローリスクを修正し、データベースのパーティショニングとシャーディングに取り組んでいる他のチームのブロックを解除する必要があります。

ラージテーブルを使用しているビルドキューイングメカニズムなど、既知のボトルネックや他のチームの足かせとなっているものを改善したいのです。

CI/CDメトリクスを拡張することは、システムがどのように動作し、どのような成長を期待すべきかをより良く把握するために重要です。これにより、ボトルネックを特定し、より高度なキャパシティプランニングを実行することが容易になります。

次のステップは、CI/CDデータの強い時間減衰特性をどのように活用できるかをよりよく理解することです。これはCI/CDデータセットを分割してCI/CDデータベースのテーブルサイズを縮小するのに役立つかもしれません。

イテレーション

次のCI/CDスケーリング目標を達成するために必要な作業は、CI/CDスケーリングエピックで追跡されます。

1. ✓ GitLab.comの主キーを大きな整数にマイグレーション。
2. ✓ GitLab.com でビルドキューイングの新しいアーキテクチャを実装。
3. 新しいビルドキューイングのアーキテクチャを一般的に利用できるようにします。
4. 時間減衰パターンを使用してCI/CDデータを分割します。

ステータス

2021.01.21に作成、2021.04.26に承認。

ステータス進行中。

誰

提案

DRI

ドメインの専門家