CIパイプラインにおけるfan-out / fan-inとは?

著者 Kaveh Alemi·Latchkey

fan-outは1つのステージを多数の並列jobに分割し、fan-inはそのすべてを待って結果を結合します。両者を組み合わせることで、CIは速度のために横に広がり、その後1つの判定へと収束できます。

fan-out/fan-inは並列パイプラインの基本的な形です。作業を複数のjobに分散させてwall-clock時間を削減しつつ、最終的には集約された1つのgate結果で終える方法です。

Fan-out

パイプライン上の1つのポイントが、並行して実行される多数の独立したjobへと分岐します - テストスイートをshardに分割する、複数のtargetをbuildする、matrixを実行するなどです。各ブランチは分離されており、それぞれ自身のrunner上で進行します。

Fan-in

並列作業のあとに、1つのjobがfan-outされた*すべての*jobに依存し、それらが完了して初めて実行されます。それらの出力を集約します - テストレポートをマージする、coverageを結合する、あるいは単にすべてのブランチが成功した場合のみgreenになるgateとして機能します。

needs: collects the fan-out

jobs:
  test:
    strategy: { matrix: { shard: [1, 2, 3, 4] } }
  report:
    needs: test   # fan-in: waits for all shards

使う理由

速度: N個の並列shardは、直列時間のおよそ1/Nで完了します。
1つのfan-in gateが、ステージ全体に対して明確なpass/failを1つ与えます。
集約(coverage、レポート)が1か所で行われます。

落とし穴

fan-outは課金対象分数を倍増させ、runnerプールを溢れさせてキューイングを引き起こすことがあります。fan-in jobは同期ポイントです - 最も遅いブランチと同じ速さにしかならないため、アンバランスな分割(1つのshardが他より極端に重い)は並列性を無駄にします。shardをバランスさせましょう。

重要なポイント

fan-outは多数の独立したjobを並列に実行し、fan-inはそれらの結果を結合します。
より多くの課金対象分数と引き換えに、より短いwall-clock時間を得るトレードオフです。
fan-in jobはgateであり同期ポイントです - 最も遅いブランチと同じ速さにしかなりません。
1つの重いブランチが並列性を打ち消さないよう、shardをバランスさせましょう。

よくある質問

What is What is Fan-Out / Fan-In in CI Pipelines??

Fan-out/fan-in is the fundamental shape of a parallel pipeline. It is how you cut wall-clock time by spreading work across jobs while still ending with one aggregated, gating result.

Fan-out?

A single point in the pipeline branches into many independent jobs that run concurrently - splitting a test suite into shards, building several targets, or running a matrix. Each branch is isolated and progresses on its own runner.

Fan-in?

After the parallel work, a single job depends on *all* of the fanned-out jobs and runs only once they complete. It aggregates their outputs - merging test reports, combining coverage, or simply acting as the gate that is green only if every branch passed.

Pitfalls?

Fan-out multiplies billable minutes and can flood a runner pool, causing queueing. The fan-in job is a synchronization point - it is only as fast as the slowest branch, so an unbalanced split (one shard far heavier than the rest) wastes the parallelism. Balance the shards.