FY26 - ホステッドランナー
目次
背景
GitLab ホステッドランナー（別名 GitLab.com のホステッドランナー）は、チームをまたいだ協業によって管理・デプロイ・維持されています。SRE はサービスの本番環境におけるスケーラビリティと信頼性を確保するためのデプロイソリューションを支援し、場合によってはリードします。
FY25 において、SRE は以下のランナー関連の取り組みを時系列順に支援しました。
- AWS でのベータリリースにおける Dedicated ランナーの支援
- 新しいランナータイプの提供: Medium および Large ARM64 ベースのランナー
- PoC - Dedicated ランナーアーキテクチャを用いたホステッドランナーのデプロイの探索
- .com ホステッドランナーのスケーラビリティを妨げていた VPC ピアリング上限の解決策の発見
- すべての .com ランナーシャード全体への VPC 再設計の実装
- Terraform における .com ランナー環境の差異の統合
FY26 では、ランナーチームがランナーの運用作業をよりセルフサービスで実施できるようにすることに注力します。
北極星（目指す姿）
GitLab ホステッドランナーの完全自動化・ハンズオフのスケーラビリティと保守性を実現し、最小限の手動介入でシームレスかつ継続的な運用を確保します。
現状の課題
以下のセクションでは、現状の課題を取り上げます。改善が最も必要な領域に焦点を当てることは悲観的に見えるかもしれませんが、私たちのセットアップとプロセスは 1 年前と比べてより良い状況にあります。ただし、理想とはまだ遠く、改善の余地があります。
知識のサイロ化
ホステッドランナーの維持・スケーリングに関する情報へのアクセスが限られています。専門知識を持つエンジニアが少数に限られており、プロセスが十分に文書化されていません。
スケーラビリティの疲弊
新しいランナータイプの提供と既存ランナーのスケーリングのいずれについても、スケーラビリティのプロセスは手作業が多く、負担が大きく、人的ミスが起きやすく、反復的で退屈です。
コスト効率
一部のシャードのコスト効率は理想とはほど遠い状況です。FinOps チームはこのデータへのアクセス手段を持っていますが、データに基づいて行動したり判断を下したりする権限がありません。さらに、代替デプロイ方法の探索や .com ランナーのホスティングコスト削減のための現在の CPU 使用率把握への投資も行っていません。
FY26 の目標
工数レベルの凡例:
- LF: 低工数（Low Effort）
- MF: 中工数（Medium Effort）
- TF: 大工数（Tremendous Effort）
知識の透明化
目標:
- デプロイとスケーラビリティに関するドキュメントの品質向上（MF）
- 発見しやすく、アクセスしやすい情報の作成（LF）
- チームをまたいだ透明性向上のためにドキュメントを CR テンプレートに変換（LF）
- ランナーチームとのランブック所有権の移管調整（MF）
関連リンク:
スケーラビリティの疲弊
目標: 既存シャードのスケーリングプロセスの自動化:
- ランナーのトラッカーに Epic/Issue を作成して以下を実施（LF）:
- 既存ツール（deployer および GRIT）の改善
- プロセスをパイプラインに組み込むことを検討
- 代替デプロイソリューションのリサーチ（例: k8s 上の runner-manager の再検討）
関連リンク:
コスト効率
目標:
- FinOps と連携して目標を策定（LF）
- 既存シャード全体で合理的なコスト効率を達成（MF）
- より費用対効果の高いホスティング方法の探索（MF）
- リソース使用量の最適化（TF）
関連リンク:
