バイナリ肥大化という「静かなる脅威」を断つ：Rust極限最適化の深淵
Rustのバイナリサイズ問題に直面したとき、多くのエンジニアは「とりあえず `strip` すればいい」と考えがちだ。しかし、現代の分散システムやエッジコンピューティングにおいて、数メガバイトの削減は単なるディスク容量の問題ではない。それはロード時間の短縮であり、メモリバスの圧迫低減であり、CI/CDにおけるデプロイパイプラインのI/Oボトルネックの解消そのものである。
今日は、Rustのバイナリを限界まで削ぎ落とし、筋肉質な実行環境を構築するための「最後の一手」を伝授する。
—
1. `opt-level = “z”` の真実と代償
多くのドキュメントには `opt-level = “3”` が推奨されているが、サイズを最優先するなら `z` を選択すべきだ。
`opt-level = “z”` は、LLVMに対して「速度よりもサイズ」を絶対優先するように指示する。単なる最適化の抑制ではなく、関数インライン化のしきい値を極限まで下げ、ループ展開を抑制することで、コードセクション（.text）の肥大化を物理的に防ぐ。
Cargo.toml
[profile.release]
opt-level = “z” # サイズ削減を最優先
lto = “fat” # リンク時最適化を全モジュールで実行。関数重複を排除
codegen-units = 1 # コンパイル時間を犠牲に、最適化の網羅性を最大化
panic = “abort” # スタックアンワインド機能を削除。例外処理用のメタデータを排除
アーキテクトの視点：
`panic = “abort”` は非常に強力だ。Rustのデフォルトである `unwind` は、スタックの巻き戻し情報を各関数に埋め込む。これがバイナリを数％〜十数％膨らませる主犯だ。これを切り捨てることは、バイナリサイズと実行時の決定論的挙動の両面で極めて有効な戦略となる。
—
2. シンボルの解体と `strip` の科学
`strip` コマンドでデバッグシンボルを削除するだけでは甘い。ELFバイナリには、実行に不要なセクションが依然として残っている。
Dockerマルチステージビルドでの最適化戦略
CI環境では、以下の構成を標準とせよ。`cargo-strip` を用いることで、標準の `strip` よりも攻撃的にセクションを破壊できる。
構築ステージ
FROM rust:1.75-slim-bookworm AS builder
RUN cargo install cargo-strip
ビルド実行
RUN cargo build –release –target x86_64-unknown-linux-musl
バイナリの極限圧縮
.comment, .note, .debug 等のセクションを破壊的に排除
RUN cargo strip -s
実行ステージ（最小限のDistroless等へ）
FROM gcr.io/distroless/static-debian12
COPY –from=builder /app/target/release/myapp /myapp
ENTRYPOINT [“/myapp”]
知見：
`cargo strip -s` は単なるシンボル削除を超え、実行に関与しないメタデータを徹底的にパージする。静的リンク（musl）と組み合わせることで、OSライブラリへの依存をゼロにしたまま、数MBの単一バイナリが完成する。
—
3. リンク時最適化（LTO）の深層：なぜ「fat」なのか
`lto = “fat”` は、全コンパイル単位を単一のLLVMビットコードモジュールに統合する。これにより、クロスモジュール・インライン化が限界まで効くようになる。
しかし、注意が必要だ。`lto = “fat”` はメモリを激しく消費する。大規模なプロジェクトでは、CIのコンテナメモリが `OOM Killer` に倒される可能性がある。
最適化ハック：
メモリ制約が厳しいCI環境では、`lto = “thin”` を使用しつつ、`codegen-units = 1` を併用せよ。これにより、メモリ消費を抑えつつ、可能な限りの最適化を適用できる。
—
4. 未踏の地：`wasm-opt` の流用とバイナリの「削り出し」
もしターゲットがWasmであれば `wasm-opt` が定石だが、ネイティブバイナリにおいても「不要なコードの静的解析」は重要だ。
`cargo-bloat` をCIパイプラインのチェックゲートに組み込むのが、真のエキスパートの作法だ。
肥大化している関数を特定する（CIでの回帰テストに組み込む）
cargo bloat –release –crates –message-format json > bloat_report.json
このJSONを監視し、特定の閾値を超えた場合にデプロイをブロックする仕組みを作る。「なぜ肥大化したのか」をコミット単位で追跡することで、依存ライブラリの選定ミスや、テンプレートメタプログラミングの暴走を早期に検知できる。
—
まとめ：DevOpsの最終目標
ここまでの設定をまとめると、あなたのプロジェクトの `Cargo.toml` はこうあるべきだ。
[profile.release]
opt-level = “z”
lto = “fat”
codegen-units = 1
panic = “abort”
strip = true # 1.45以降のCargoならこれだけでstripされる
バイナリの最適化は、単なる趣味ではない。それは、「ソフトウェアがどのようにメモリ上に配置され、どのようにCPUに読み込まれるか」というハードウェアとの対話そのものだ。
この設定を施した瞬間、あなたのサービスは起動時間が短縮され、コンテナのプル時間は劇的に改善し、インフラコストは確実に下がる。これこそが、アーキテクトがコードの行数ではなく、「バイナリという物理的成果物」に魂を込める理由である。
さあ、ビルド時間を少し犠牲にして、完璧なバイナリを手に入れようではないか。