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
implemented @grzesiek @ayufan @grzesiek @thaoyeager @darbyfrey devops release 2020-08-26

クラウドネイティブのビルドログ

クラウドネイティブとKubernetesの採用は、GitLabにとって、プロジェクトの背後にある企業としての成長を加速させる2つの大きな追い風のうちの1つであると認識されています。

この取り組みについては、インフラチームのハンドブックに詳しく書かれています。

従来のビルドログ

従来のジョブログは、ローカル共有ストレージの可用性に大きく依存していました。

GitLab Runnerが新しい部分的なビルド出力を送信するたびに、この出力をディスク上のファイルに書き込みます。なぜなら、GitLab RunnerはAPIリクエストを実行するたびに異なるマシンに接続するかもしれないからです。ジョブが完了するとトレースファイルの内容がオブジェクトストアに送られるため、Sidekiqもファイルにアクセスする必要があります。

新しいアーキテクチャ

新しいアーキテクチャでは、ビルドログをファイルに書き込む代わりにRedisにデータを書き込みます。

Redisにデータをチャンク単位で保存し、必要なチャンクサイズに達したらオブジェクトストアにマイグレーションします。

簡略化したシーケンス図を以下に示します。

sequenceDiagram autonumber participant U as User participant R as Runner participant G as GitLab (rails) participant I as Redis participant D as Database participant O as Object store loop incremental trace update sent by a runner Note right of R: Runner appends a build trace R->>+G: PATCH trace [build.id, offset, data] G->>+D: find or create chunk [chunk.index] D-->>-G: chunk [id, index] G->>I: append chunk data [chunk.index, data] G-->>-R: 200 OK end Note right of R: User retrieves a trace U->>+G: GET build trace loop every trace chunk G->>+D: find chunk [index] D-->>-G: chunk [id] G->>+I: read chunk data [chunk.index] I-->>-G: chunk data [data, size] end G-->>-U: build trace Note right of R: Trace chunk is full R->>+G: PATCH trace [build.id, offset, data] G->>+D: find or create chunk [chunk.index] D-->>-G: chunk [id, index] G->>I: append chunk data [chunk.index, data] G->>G: chunk full [index] G-->>-R: 200 OK G->>+I: read chunk data [chunk.index] I-->>-G: chunk data [data, size] G->>O: send chunk data [data, size] G->>+D: update data store type [chunk.id] G->>+I: delete chunk data [chunk.index]

NFS 結合

2017年、私たちはNFSインフラストラクチャのスケーリングの深刻な問題を経験しました。NFSをCephFSに置き換えようとしましたが、失敗しました。

その時以来、NFSクラスタのオペレーションとメンテナンスのコストが大きく、Kubernetesにマイグレーションすることを決めたら、GitLabを共有ローカルストレージとNFSから切り離す必要があることが明らかになりました。

  1. NFSは単一障害点になるかもしれません
  2. NFSは垂直方向にしか確実にスケールできません。
  3. Kubernetesへの移行は、マウントポイントの数を一桁増やすことを意味します。
  4. NFSは非常に信頼性の高いネットワークに依存しますが、Kubernetes環境ではそれが難しい場合があります。
  5. NFS上に顧客データを保存することは、さらなるセキュリティリスクを伴います。

NFSをデカップリングせずにGitLabをKubernetesに移行すると、複雑さが爆発し、メンテナンスコストがかかり、可用性に甚大な悪影響を及ぼします。

イテレーション

  1. 共有ローカルストレージに依存しない新しいアーキテクチャの実装
  2. パフォーマンスとエッジケースを評価し、新アーキテクチャを改善するための反復作業。
  3. クラウド・ネイティブ・ビルド・ログの正しさ検証メカニズムの設計
  4. パフォーマンスと正しさに関する観測可能性メカニズムの構築
  5. 本番環境への段階的ロールアウト

新しいアーキテクチャを本番環境に対応させ、GitLab.com で有効にするために必要な作業は、GitLab.comepicの Cloud Native Build Logsで追跡されていました。

GitLab.com でこの機能を有効にすることは、新しいアーキテクチャを一般的に誰でも使えるようにするためのサブタスクです。

ステータス

この変更はGitLab.comで実装され、有効になりました。

私たちはこの機能をより弾力的で観測可能なものにするためのエピックに取り組んでいます。