GitLabでCIプラットフォームを変革したIndeed社の戦略

編集者からのお知らせ：GitLabでは、当社ブログの執筆者として、カスタマーコミュニティのメンバーをお招きすることがあります。今回のブログ記事では、Indeed社のCIプラットフォームマネージャーを務めるCarl Myers氏に、GitLabに関する経験を共有していただきました。

Indeedは、「We help people get jobs.（人々の仕事さがしを支援する）」というミッションを掲げています。Indeedは、月間3億5,000万人以上のユニークビジターを持つ、世界最大の求人サイト（外部サイト）です。

Indeedのエンジニアリングプラットフォームチームは「We help people to help people get jobs.（人々の仕事さがしを支援する人を支援する）」というモットーを掲げており、これは会社のミッションとは少し異なるものです。20年近くにわたり、常に求職者を第一に考えるデータドリブンのエンジニアリング文化を醸成してきました。この文化を推進する中で、当社はこのアプローチを実現し、日々エンジニアが求職者によい結果を届けられるようにするためのツールの構築に責任を持って取り組んでいます。

わずか11人から成るIndeedのCIプラットフォームチームは、GitLabの継続的インテグレーション（CI）を導入したことで、社内の数千人のユーザーを効果的にサポートできるようになりました。このほかにも、IndeedはGitLab CIへの移行により次のメリットを得ました。

• 1日あたりのパイプライン実行数が79%増加
• CIハードウェアコストを10～20%削減
• サポート負担の軽減

CIプラットフォームの進化：Jenkinsから拡張性に優れたソリューションへ

多くの大手テクノロジー企業と同様に、当社は会社の成長に伴い、当時利用可能なオープンソースや業界標準のソリューションを用いてCIプラットフォームを段階的に構築してきました。2007年、Indeedのエンジニアが20人にも満たなかった頃、チームではHudson（Jenkinsの前身）を使用していました。

20年近くにわたる成長を経た現在、Indeedには数千人のエンジニアが在籍しています。新しい技術が登場するたびに、段階的に改善に取り組み、2011年頃にはJenkinsに移行しました。また、AWS EC2を使用して、ほとんどのワークロードを動的なクラウドワーカーノードに移行することにも成功しました。しかし、Kubernetes時代に突入すると、システムのアーキテクチャが限界に達しました。

Jenkinsのアーキテクチャは、クラウドを前提に設計されていません。Jenkinsは、パイプラインの重要な部分を実行し、特定のタスクをワーカーノードに割り当てる役割を持つ『コントローラー』ノードを使用して動作します（ワーカーノードはある程度水平にスケーリングが可能）。しかし、コントローラーのスケーリングは手動で調整する必要があります。

ジョブが多すぎて1つのコントローラーに収まらない場合、ジョブを複数のコントローラーに手動で分割する必要があります。CloudBees社は、こうしたボトルネックを軽減するための対策として、CloudBees Jenkins Operations Centerをはじめとする、複数のコントローラーを一元管理するソリューションを提案しています。しかし、各コントローラーは依然として脆弱な単一障害点となり、Kubernetes環境での運用には困難があります。ノードのロールアウトやハードウェアの障害などのアクティビティはダウンタイムを引き起こします。

Jenkins自体に内在する技術的な制約に加えて、自社のCIプラットフォームにも、社内プロセスが原因で発生した問題がいくつかありました。たとえば、各リポジトリ内のコードからジョブを生成するためにGroovy Jenkins DSLを使用していたため、各プロジェクトがコピー＆ペーストされた独自のジョブパイプラインを持つことになり、その結果、数百ものバージョンが生成され、メンテナンスや更新が困難になりました。Indeedのエンジニアリング文化は柔軟性を重視し、チームが別々のリポジトリで作業することを許容していますが、その柔軟性により、チームは定期的にメンテナンスを行わなければならず、多大な時間を費やさせる負担要因となっていました。

こうした技術的負債を認識した当社は、「Golden Pathパターン（英語）」に目を向けました。このパターンは、柔軟性を保ちながら、アップデートを簡素化し、プロジェクト間で運用の一貫性を促進するための標準的な手順を提供するものです。

IndeedのCIプラットフォームチームは11人ほどのエンジニアで構成されており、決して規模は大きくないものの、サポートリクエストへの対応、アップグレードやメンテナンスの実施、そしてグローバル企業としての常時サポート体制の確保を通じて、数千人のユーザーサポートにあたっています。

当社のチームは、GitLabインスタンスだけでなく、アーティファクトサーバーや共有ビルドコード、さらに複数のカスタムコンポーネントを含むCIプラットフォーム全体をサポートしているため、業務量は非常に多岐にわたります。そのため、既存のリソースを最大限に活用し、課題に対処する計画が必要でした。

GitLab CIへの移行

主要なステークホルダーとの慎重な設計レビューを経て、当社は全社的にJenkinsからGitLab CIへ移行することを決定しました。GitLab CIを選んだ主な理由は次のとおりです。

• すでにGitLabをソースコード管理に使用していたため。
• GitLabは、当社がCIに求める機能をすべて備えた包括的なソリューションであるため。
• GitLab CIの設計は拡張性に優れ、クラウドにも対応しているため。
• GitLab CIは、テンプレートを拡張して新たなテンプレートを作成できるという点が、当社の「Golden Path」戦略と合致していたため。
• GitLabがオープンソースソフトウェアであり、さらにGitLabチームが当社の修正提案に常に協力的であったことから、柔軟性と安心感を得られたため。

GitLab CIプラットフォームの一般提供を正式に発表した時点で、すでに全ビルドの23%がGitLab CI上で行われていました。これは、個々のユーザーの自主的な取り組みや早期導入者のおかげです。

しかし、移行の課題は「ロングテール」にありました。Jenkinsには多くのカスタムビルドが存在するため、自動移行ツールはほとんどのチームに適用できませんでした。新しいシステムの利点の多くは、旧システムを完全に停止（0%）にするまで実現しません。そうして初めてハードウェアを停止し、CloudBeesのライセンス費用を削減できるようになるのです。

機能の同等性とゼロからの再出発の利点

Indeedでは多様な技術をサポートしていますが、最も一般的な言語はJava、Python、JavaScriptです。これらの言語は、ライブラリの構築、デプロイ可能なサービス（ウェブサービスやアプリケーションなど）、およびcronジョブ（データレイク内のデータセットを構築するような、定期的に実行されるプロセス）を作成するために使用されます。これらの言語は、Javaライブラリ、Pythonのcronジョブ、JavaScriptのウェブアプリケーションといったプロジェクトタイプのマトリックスを形成しており、Jenkinsではそれぞれに対して事前定義されたスケルトンがありました。そのため、これらすべてのプロジェクトタイプに対応する「Golden Path」テンプレートをGitLab CIでも作成する必要がありました。

ほとんどのユーザーは推奨されたパスをそのまま使用できましたが、カスタマイズが必要な場合でも「Golden Path」は有用な出発点になりました。必要な部分だけを調整しながら、将来的には一元管理されたテンプレートが更新されるたびに、その利点を享受することができます。

当社はすぐに、カスタマイズが必要なユーザーでさえ「Golden Path」の採用に前向きであり、少なくとも試用を望んでいることがわかりました。もし以前のカスタマイズが必要であれば、後から追加することができたからです。これは驚くべき結果でした。大幅なカスタマイズに投資してきたチームはそれを手放すことに抵抗があるだろうと思っていましたが、大多数のチームはもはやそれを気にしなくなっていたのです。これにより、多くのプロジェクトを非常に迅速に移行することができました。プロジェクトに「Golden Path」（インクルードを含む6行ほどの小さなファイル）を追加するだけで、あとは各チームがそれを活用して進めることができました。

インナーソースによる救済

CIプラットフォームチームは、「外部からのコントリビュートを優先する」というポリシーを採用し、社員全体の参加を促進しました。このアプローチは「インナーソース」と呼ばれることもあります。私たちは、外部からのコントリビュート（自分たちのチーム以外からのコントリビュート）を促進するために、テストやドキュメントを作成しました。カスタマイズを望むチームは、そのカスタマイズを、Golden Pathに組み込んで、機能フラグを使用して共有できるようになりました。これにより、カスタマイズを行ったチームは自分たちの作業を他のチームと共有できるようになっただけでなく、そのカスタマイズがCIプラットフォームチームのコードベースの一部になったため、将来的にそのカスタマイズが壊されないことを保証できるようになりました。

この取り組みには、特定のチームが必要な機能を求めて待機することなく、自分たちでその開発に取り組めるようになったという利点もありました。たとえば、「その機能は数週間後に実装する予定ですが、もし早めに必要であれば、ぜひコントリビュートしてください」と伝えることができます。結果的に、同等性に必要な多くのコア機能がこのようなアプローチで開発され、チームのリソースでは実現できないほど迅速かつ質の高い形で提供されました。このモデルがなければ、移行は成功しなかったでしょう。

予定より早く、予算内で達成

チームのCloudBeesライセンスは2024年4月1日に期限切れになりました。これに伴い、完全移行を達成するための挑戦的な目標を設定しました。当時、ビルド全体の80%（全プロジェクトの60%）でCIにJenkinsが使用されていたことを考えると、この目標は特に野心的だったと言えます。つまり、2,000以上のJenkinsfilesを新たに書き直すか、Golden Pathのテンプレートに置き換える必要があったのです。

この目標を達成するために、チームはドキュメントやサンプルコードを提供し、可能な限り機能を実装したほか、ユーザーが機能を追加できるように支援しました。

また、定期的なオフィスアワーを設け、誰でも質問をしたり、移行の支援を求めたりできるようにしました。さらに、移行に関連するサポートの質問を、一部を除いて他のどの質問よりも優先しました。CIプラットフォームはGitLab CIのエキスパートとなり、その専門知識をチーム内および組織全体で共有しました。

自動移行はほとんどのプロジェクトでは実現できませんでしたが、カスタマイズがまれな比較的小規模なプロジェクトには有効であることがわかりました。チームはSourcegraphの一括変更キャンペーンを作成し、数百のプロジェクトを移行するためにマージリクエストを送信しました。そして、ユーザーにその承認を促しました。

ユーザーからの成功事例を広く共有し、ユーザーがGolden Pathに新しい機能を追加するたびに、「GitLab CIに移行するとこれらの機能が無料で利用できる」と宣伝しました。これらの機能には、ビルトインのセキュリティやコンプライアンススキャン、CIビルドのSlack通知、他の内部システムとのインテグレーションなどがあります。

さらに、積極的な「screamテスト」キャンペーンを実施しました。しばらく実行されていない、または成功していないJenkinsジョブを自動的に無効にし、必要であれば再度有効にできるとユーザーに通知しました。これは、手間をかけずに実際に必要なジョブを特定できる効果的なアプローチでした。前回のCI移行（JenkinsからJenkinsへの移行）以降、一度も実行されていない数千のジョブがあり、これらをほぼすべて安全に無視できることがわかりました。

2024年1月には、例外が明示的に要求されない限り、すべてのJenkinsコントローラーが読み取り専用（ビルド不可）になると発表しました。コントローラーに関する所有情報が大幅に改善され、組織の構造に合致していたため、ジョブよりもコントローラーに焦点を当てることが合理的でした。コントローラーのリストはジョブのリストよりもはるかに管理しやすいものでした。

例外を認めるために、ユーザーにはスプレッドシートでコントローラーを見つけ、その横に連絡先情報を入力してもらうよう依頼しました。これにより、フォローアップできる利害関係者の最新リストを確実に取得できるだけでなく、ユーザーからも絶対に必要なジョブを明確に知らせてもらうことができました。ピーク時には約400ものコントローラーがありましたが、1月には220に減少し、そのうち例外を必要とするのは54のコントローラーだけでした（そのうちいくつかはチームで所有し、テストやカナリアのために使用していました）。

私たちは、約50チームの管理可能なリストをチーム内で分担し、各チームの移行の進捗状況を聞き取りし始めました。1月、2月中に、そして一部のチームは2月28日までに私たちの支援なしで移行を完了させる予定であり、他のチームはその時点までのプロジェクト廃止を計画していることが判明しました。そして、ごく少数のチームが期限内に完了できるか非常に心配していました。

私たちはこの少数のチームと協力し、きめ細やかな個別対応サービスを提供しました。私たちには移行を代行する上での専門知識が不足しているものの、そのチームの特定分野の専門家と協力できることを説明しました。一部のプロジェクトでは、私たちがコードを書き、そのチームがレビューを行い、他のプロジェクトではそのチームがコードを書き、私たちがレビューを行いました。最終的に、すべての努力が実を結び、8か月前に宣言した日に、Jenkinsを無事に廃止することができました。

成果：CI効率とユーザー満足度の向上

Jenkins CIプラットフォームのピーク時には、1日あたり14,000以上のパイプラインが実行され、数千のプロジェクトをサポートしていました。現在、GitLab CIプラットフォームは、1日あたり40,000以上のパイプラインを処理し、通常は25,000以上のパイプラインが日常的に稼働しています。各パイプラインのジョブごとの増分コストはJenkinsと同程度ですが、コントローラーを実行するためのハードウェアのオーバーヘッドがなくなりました。これらのコントローラーは、単一障害点であり、スケールの制限要因でもあったため、プラットフォームを人工的にセグメント化せざるを得ませんでした。正確な比較は難しいものの、このオーバーヘッドがなくなったことで、CIハードウェアコストは10～20%削減できたと考えています。さらに、GitLab CIはクラウド上で自動的にスケールし、複数の可用性ゾーンで動作する耐障害性を備えているほか、テンプレート言語には優れた公開ドキュメントがあるため、サポートの負担も軽減されています。

特筆すべきもうひとつの利点としては、現在、Golden Pathの採用率が70%を超えていることです。これにより、私たちが改善策をロールアウトすれば、Indeedの5,000以上のプロジェクトは、特別な操作をせずにすぐにそのメリットを享受できるようになることがわかりました。この結果、一部のジョブをよりコスト効率の高いARM64インスタンスに移行したり、ユーザーのビルドイメージをより簡単に更新したりできるようになりました。また、他のコスト削減の機会をより適切に管理することも可能になりました。最も重要なことは、ユーザーが新しいプラットフォームに満足していることです。

著者について： Carl Myers氏はカリフォルニア州サクラメント在住で、Indeed社のCIプラットフォームチームのマネージャーを務めています。Carl氏は、約20年にわたるキャリアを通じて、大小さまざまな企業で、エンジニアのニーズを満たし、その能力を引き出すための社内ツールやデベロッパー向けプラットフォームの構築に尽力してきました。

謝辞： この移行プロジェクトは、Tron Nedelea氏、Eddie Huang氏、Vivek Nynaru氏、Carlos Gonzalez氏、Lane Van Elderen氏、そしてCIプラットフォームチームの他のメンバーの尽力なしには実現できませんでした。チームはまた、プロジェクト全体を通じて、合意やリソースの確保、そして社内全体の調整に尽力していただいたDeepak Bitragunta氏とIrina Tyree氏のリーダーシップに、特に感謝しております。最後に、コード、フィードバック、バグレポートに貢献し、プロジェクトの移行を支援してくださったIndeed社の皆様に感謝申し上げます。

この記事は、Indeedエンジニアリングブログに掲載された「How Indeed Replaced Its CI Platform with GitLab CI」の編集版です。