Rust CI/CDの深淵：Dockerとコンパイラ・アーキテクチャを掌握する最適化戦略
Rustのビルド時間は、大規模プロジェクトにおいて開発者の生産性を直接削り取る「最大の敵」だ。特にCI/CD環境において、単に`docker build`を叩くだけでは、Rustの強力な型システムと単相化（monomorphization）がもたらす膨大なコンパイル負荷に押し潰される。
本稿では、単なる環境構築の域を超え、コンパイラの挙動とDockerのレイヤー構造を同期させ、CI時間を極限まで圧縮する「Rustコンパイラ・アーキテクトのためのCI/CD戦略」を提示する。
—
1. ベースイメージの選択：`rust-slim`か`distroless`か
公式の`rust`イメージをそのまま使うのは、CI環境のビルド時間をドブに捨てるに等しい。
- ビルドフェーズ: `rust:1.75-slim-bookworm` を推奨する。`alpine`（musl）は魅力的だが、リンク時のトラブルや一部クレートの互換性で時間を浪費するリスクがある。GLIBC環境を維持しつつ、不要なドキュメントやヘッダを削ぎ落とした`slim`が最もバランスが良い。
- ランタイムフェーズ: `gcr.io/distroless/cc-debian12` 一択だ。シェルすら存在しないバイナリのみの環境は、セキュリティ面での攻撃対象領域（Attack Surface）を最小化し、イメージサイズを劇的に減らす。
—
2. マルチステージビルドによる「依存関係の分離」ハック
Rustのビルドにおいて、最もコストが高いのは「依存クレートのコンパイル」だ。ソースコードを変更するたびに `cargo build` を実行していては、インクリメンタルビルドの恩恵を十分に受けられない。
ここで、「偽のメインコード」を挿入するテクニックを使う。
1. ビルド環境の構築
FROM rust:1.75-slim-bookworm AS builder
2. 依存関係だけを先にキャッシュさせるための空プロジェクト生成
WORKDIR /app
RUN USER=root cargo new –bin app
WORKDIR /app/app
Cargo.tomlだけを先にコピー
COPY Cargo.toml Cargo.lock ./
依存関係のみをコンパイル（ここでレイヤーがキャッシュされる）
RUN cargo build –release
3. 本体のソースコードをコピー
COPY src ./src
タイムスタンプを更新して再コンパイルを強制
RUN touch src/main.rs && cargo build –release
4. 実行用ステージへバイナリを抽出
FROM gcr.io/distroless/cc-debian12
COPY –from=builder /app/app/target/release/app /usr/local/bin/app
CMD [“/usr/local/bin/app”]
この構成の肝は、`Cargo.toml`のみを先行してコンパイルし、Dockerのレイヤーキャッシュを「クレートの依存ツリー」として機能させる点にある。
—
3. GitHub Actionsにおける「キャッシュ戦略」の真髄
GitHub Actionsの `actions/cache` を使う際、単に `target/` をキャッシュするだけでは不十分だ。Rustのビルドアーティファクトは非常に巨大であり、キャッシュのアップロード・ダウンロード時間がコンパイル時間を追い越す「オーバーヘッド」が発生する。
真の最適化：`sccache`の導入
`sccache` を使うことで、共有メモリやS3を介してコンパイル結果をキャッシュできる。
GitHub Actionsの設定例
steps:
- uses: actions/checkout@v4
- name: Setup SCCACHE
run: |
# SCCACHEをインストールし、CIのキャッシュバックエンドを設定
curl -L https://github.com/mozilla/sccache/releases/download/v0.7.4/sccache-v0.7.4-x86_64-unknown-linux-musl.tar.gz | tar xz
echo “RUSTC_WRAPPER=$(pwd)/sccache/sccache” >> $GITHUB_ENV
- name: Build
run: cargo build –release
これにより、複数のブランチや過去のビルドから「関数単位のコンパイル結果」が再利用されるため、クリーンビルドに近い状態でも爆速で完了する。
—
4. コンパイラ・パラメータのチューニング：リンクの壁を越える
大規模なRustプロジェクトでは、最終段階の「リンク」がボトルネックになる。これを解決するには `mold` リンカーの導入が必須だ。
ビルド環境にmoldをインストールし、Cargoに指示を出す
RUN apt-get update && apt-get install -y mold
ENV RUSTFLAGS=”-C link-arg=-fuse-ld=mold”
`mold` は従来の `bfd` や `gold` と比較して、並列処理能力が圧倒的だ。リンク時間は、特に巨大なバイナリにおいて数倍から数十倍の短縮が見込める。
—
5. 伝説的アーキテクトからの提言：メトリクスの可視化
CI/CDを組むだけで満足してはいけない。ビルド中にどのクレートが最もコンパイル時間を食っているのかを把握せよ。
全てのビルドでプロファイリングを行う
cargo build –timings
このコマンドで生成される `target/cargo-timings/timing-YYYY-MM-DD-HH-MM-SS.html` をCIのアーティファクトとして保存せよ。このレポートには、どのクレートが並列化を阻害し、どのクレートが直列的なビルドを強いているかが克明に記されている。
まとめ：Rustエンジニアリングの極致
Rustのビルド環境構築において、「設定を一度作って終わり」はあり得ない。依存関係の変化に合わせてレイヤーを最適化し、`sccache`でコンパイル結果を共有し、`mold`でリンクを加速させる。
これらの技術スタックを組み合わせることは、単なるCIの効率化ではなく、開発者の思考のコンテキストスイッチを最小化し、創造的なコーディングに集中させるための「環境設計」に他ならない。
貴殿のパイプラインに、この最適化を今すぐ導入し、コンパイルの待ち時間にコーヒーを淹れる暇を削り取ってほしい。それが、世界最高峰のエンジニアが歩む道である。