Timee Product Team Blog

タイミー開発者ブログ

GitHubマージキューTIPS：キューの詰まりを可視化し、デプロイフローを最適化する

GitHub

こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@euglena1215) です。

GitHubマージキューTIPSシリーズ、前回までに、マージメソッドの制約やCIの高速化といったTIPSを共有してきました。今回は、マージキューのポテンシャルを最大限に引き出すためのパラメータチューニングと、そのために不可欠なキューの状態の可視化について解説します。

デプロイ効率と安定性のトレードオフ

マージキューには、その挙動をコントロールするためのいくつかのパラメータが存在します。

  • Build concurrency：マージキューのCIを同時に実行する並列数。
  • Minimum/Maximum pull requests to merge：一度のデプロイ（マージ）に含めるPRの最小数と最大数。

これらのパラメータは、効率性と安定性という、二つの相反する要素を調整するために使用します。

  • 効率性（デプロイの速さ）：開発者の待ち時間を短縮するため、PRを迅速にマージすることが求められます。
  • 安定性（変更の分離）：問題発生時の影響範囲を限定し、原因特定を容易にするため、一度にマージする変更は少なくすることが望ましいです。

例えば、Maximum pull requests to merge を10に設定するとデプロイのスループットは向上しますが、障害発生時には10個のPRの中から原因を特定することが困難になります。逆に1に設定すると、原因特定は容易になりますが、PRが多数待機している場合に待ち時間が増加します。

キューの長さを計測する必要性

この関係を考慮してパラメータを調整するには、「現在のマージキューで待機しているPRがどの程度あるか」というデータが必要です。キューに待機しているPRがなければ設定を変更する必要はありませんが、常に多数のPRが待機している場合は、CIの並列数を増やすなどの対策を検討する必要があります。

しかし、キューの長さや待ち時間といった情報は、GitHubの標準機能では提供されていません。このため、キューの長さを計測し、可視化する仕組みを構築しました。

キューの長さを計測する方法

私たちのチームでは、GitHub Actionsを利用してキューの長さを計測し、Datadogへ送信しています。

その実装で利用している方法を紹介します。

ghコマンドによるキュー長の取得

GitHubマージキューの現在の長さは、GitHubのGraphQL APIを通じて取得できます。ghコマンドを使えば、これを1行のコマンドで簡単に行えます。

使用するコマンドは以下の通りです。

QUEUE_COUNT=$(gh api graphql -f query='
  query {
    repository(owner: "THIS_IS_ORG_NAME", name: "THIS_IS_REPO_NAME") {
      mergeQueue(branch: "DEFAULT_BRANCH_NAME") {
        totalCount: entries {
          totalCount
        }
      }
    }
  }
' --jq '.data.repository.mergeQueue.totalCount.totalCount')

このコマンドは、GraphQLクエリで必要なデータ (totalCount) を指定し、ghコマンドの--jqフラグでレスポンスから値を直接抽出しています。

このコマンドを、on.merge_group（PRがマージキューに追加された時）をトリガーにしたGitHub Actionsで実行します。その結果をモニタリングツール（私たちの場合はDatadog）に送信することで、キューの長さを時系列グラフとして可視化できます。

マージキューに入っている Pull Request の数の時系列グラフ

このダッシュボードによって「どの時間帯にマージが集中するのか」「現在のパラメータ設定でキューが効率的に処理されているか」といった状況を把握できるようになりました。

データに基づくパラメータ調整の実際

このダッシュボードを2週間運用した結果、私たちのチームでは同時にマージキューに積まれていたPRは最大でも3件であることが分かりました。

この実績データに基づき、安定性をさらに高めるため、パラメータを以下のように調整しました。

  • Maximum pull requests to merge: 変更前 5 → 変更後 3
  • Build concurrency: 変更前 10 → 変更後 6

一度にマージするPR数を実績値（3件）に合わせ、ビルドの並列数（Build concurrency）をその2倍に設定しました。これにより、リソースを効率的に使いつつ、より安定した運用を目指しました。

まとめ

マージキューは導入するだけでも一定の効果がありますが、その効果を高めるには、開発の規模や状況に応じてパラメータを継続的に調整することが重要です。その調整は、勘や感覚ではなく、今回紹介したような可視化されたデータに基づいて行うことが推奨されます。

今回はキューの可視化とパラメータ調整について解説しました。次回以降も、マージキューをより効果的に活用するための情報をお届けします。