Workhorseへの新機能追加

GitLab WorkhorseはGitLabのスマートなリバースプロキシです。以下のような長いHTTPリクエストを処理します：

  • ファイルのダウンロード
  • ファイルのアップロード
  • Git のプッシュとプル。
  • Git アーカイブのダウンロード。

Workhorse自体は機能ではありませんが、GitLabのいくつかの機能はWorkhorseなしでは効率的に動作しません。

一見すると、WorkhorseはHTTPストリームを処理してRuby on Railsコントローラのロジックを減らすためのパイプラインのように見えます。しかし、そのように扱ってはいけません。Workhorseに機能をオフロードしようとするエンジニアは、しばしば当初の予想よりも多くの作業が必要であることに気づきます：

  • 新しいプログラミング言語ですし、GitLabのエンジニアの中でGoの開発者は数人しかいません。
  • Workhorseには厳しい要件があります：
    • それはステートレスであること。
    • メモリとディスクの使用量を厳重に管理する必要があります。
    • その過程でリクエストが遅くなるようなことがあってはなりません。

新機能の追加は避けるべき

新機能の追加は、絶対に必要で他に選択肢がない場合にのみ行うことをお勧めします。RailsコードベースとWorkhorseの間で機能を分割することは、技術的負債をもたらす意図的な選択です。システムが複雑になり、2つのコンポーネント間の結合が増えます：

  • Workhorseを使った機能構築にはかなりの複雑性コストがかかるため、RailsリクエストとSidekiqジョブをベースにした設計を好むべきです。
  • RailsとSidekiqを使う方がRailsとWorkhorseを使うよりも手間がかかる場合でも、長期的にはRailsとSidekiqの方がメンテナーが楽です。WorkhorseはGitLab独自のものですが、Rails-and-Sidekiqは業界標準です。
  • ウェブリクエストに関するグローバルな動作については、Workhorseの代わりにRackミドルウェアを使うことを検討してください。
  • 一般的に言えば、RailsとWorkhorseを使うのは、HTTPクライアントが長いリクエストのようなRailsで実装するのが妥当な動作を期待する場合に限られます。

長いリクエストとは何ですか?

WorkhorseとPumaのRAM使用量は1桁違います。ミリ秒より長い時間コネクションを開いていると、Ruby on Railsコントローラに到達した後にRAMが占有されるため問題になります。データ転送とHTTPロングポーリングです。いくつか例を挙げます：

  • git push.
  • git pull.
  • アーティファクトのアップロードまたはダウンロード。
  • 新しいジョブを待つ CI Runner。

クラウドネイティブインストールの増加に伴い、Workhorseの機能セットはオブジェクトストレージの直接アップロードを追加するために拡張されました。この変更により、共有ネットワークファイルシステム(NFS) ドライブの必要性がなくなりました。

それでもまだWorkhorseに新しい機能を追加すべきだとお考えでしたら、Workhorseのメンテナーにイシューを発行して説明してください：

  1. 実装したい内容
  2. 私たちのRubyコードベースで実装できない理由。

Workhorseのメンテナーが状況を判断する手助けをしてくれます。