大規模Pulumiプロジェクトの処方箋：数千リソースの地獄と戦う「プレビュー・デプロイ高速化」の極意
テックリードの私たちが、インフラのコード化（IaC）において最も直面したくない悪夢は何か？
それは、たった数行のセキュリティグループの変更を加えただけなのに、`pulumi preview` の完了までに 15分以上 待たされる瞬間だ。
リソース数が数千規模に達したプロダクション環境のPulumiスタックにおいて、デフォルト設定のまま運用を続けることは、チーム全体の開発サイクルを殺す行為に等しい。エンジンとプロバイダの対話メカニズム、依存関係のグラフ構造、そしてステートの肥大化。これらを正しく理解し、メスを入れなければ、あなたのCI/CDパイプラインは常にボトルネックの炎に包まれることになる。
本稿では、Pulumiの内部挙動の深淵に踏み込み、プレビューとデプロイの速度を劇的に引き上げるための実践的なチューニング手法を余すところなく伝授する。
—
1. ボトルネックの特定：敵を知ることから始めよ
「なぜ遅いのか？」を推測で語るのは三流のエンジニアだ。まずは計測する。
Pulumiには、パフォーマンス劣化の原因を暴くための強力な環境変数が用意されている。
デバッグログと詳細なタイムスタンプを出力してプレビューを実行
PULUMI_DEBUG_GCL=true PULUMI_LOG_LEVEL=debug pulumi preview –logflow 2> pulumi_perf.log
このログから、以下の2点を確認せよ。
1. リフレッシュ（Refresh）フェーズに時間がかかっていないか？
クラウド上の実リソースとステートの同期（`–refresh`）は、数千リソースある環境では数分〜数十分のオーバーヘッドを生む。
2. プロバイダのRPC（gRPC）呼び出しで詰まっていないか？
Pulumiエンジンと各クラウドプロバイダ（AWS, Azure, GCPなど）はgRPCで通信している。ここでの直列処理がボトルネックの最大の原因だ。
—
2. プロバイダの並列度（Parallelism）チューニング
デフォルトでは、Pulumiは一定の並列度でリソースの作成・更新を行う。しかし、近年のマルチコアCPU環境やクラウドAPIのレートリミットの枠内において、このデフォルト値は保守的すぎることが多い。
`pulumi up` または `pulumi preview` 実行時に `–parallel` フラグ（または環境変数 `PULUMI_PARALLELISM`）を調整せよ。
並列度をデフォルト（通常は8程度）から一気に64へ引き上げる
pulumi up –parallel=64
⚠️ 現場の罠：レートリミット（Throttling）との戦い
並列度を上げれば上げるほど速くなるわけではない。AWSのIAMやEC2、GCPのIAM APIなどは、短時間に大量のリクエストを送りつけると容赦なく `RateExceeded` や `429 Too Many Requests` を返す。
プロバイダ側のリトライロジックを信頼しつつ、インフラ全体のAPI特性に応じた「スイートスポット（一般的には32〜64）」をベンチマークで導き出す必要がある。
—
3. 依存関係の最適化：不必要な暗黙的依存（Implicit Dependencies）の排除
Pulumi（およびTypeScript/Python/Go等のホスト言語）は、コード内の変数参照を通じて依存関係グラフを構築する。ここに設計上の不備があると、「本当は並列に処理できるはずのリソース群が、直列に処理される」という悲劇が起きる。
アンチパターン：巨大な単一スタックと不適切なスコープ
全てのVPC、Kubernetesクラスター、データベース、そして数百のマイクロサービスのIAMロールを1つのスタックに詰め込んでいないか？
// 悪い例：全てのIAMロールがVPCの完了を無駄に待たされている構造
const vpc = new aws.ec2.Vpc(“main”, { … });
// vpcオブジェクトを不必要に参照することで、暗黙的な依存関係が生まれ、
// VPCの構築が完全に終わるまで、後続の無関係なリソースの評価が遅れることがある
const policies = createHundredsOfPolicies(vpc.id);
解決策：明示的な依存分離と `dependsOn` の最小化
依存関係は必要最小限に絞る。また、出力値（Output）の伝播によって意図せぬ直列化が起きていないか、`pulumi graph` コマンドで依存関係の有向非循環グラフ（DAG）を定期的に視覚化せよ。
依存関係グラフをDOT形式で出力し、SVGに変換して視覚的ボトルネックを発見する
pulumi graph –node-out | dot -Tsvg > stack_graph.svg
—
4. 状態ファイル（State）の分割設計：ドメイン駆動型インフラストラクチャ
数千リソースを抱えるモノリシックなスタックは、いかにCPUを増やそうとも限界が来る。ステートファイルのサイズ肥大化は、シリアライズ/デシリアライズ、暗号化/復号、そしてS3等のバックエンドとの通信において致命的なレイテンシを生む。
スケールする分割パターン
インフラをドメインごとに垂直分割（Vertical Partitioning）し、スタック間参照（Stack References）で結合するアーキテクチャを採用せよ。
- Stack A (`core-network`): VPC, Subnets, Route Tables (変更頻度：極めて低)
- Stack B (`data-stores`): RDS, ElastiCache (変更頻度：低)
- Stack C (`microservices`): ECS/EKS Services, Lambda (変更頻度：高)
スタック間のデータ共有は `pulumi.StackReference` を用いる。
// Stack C から Stack A のVPC IDを安全に参照する
const networkStack = new pulumi.StackReference(“my-org/core-network/production”);
const vpcId = networkStack.requireOutput(“vpcId”);
これにより、日々のデプロイ対象となるのは `microservices` スタックのみとなり、プレビュー時間は秒単位まで短縮される。
—
5. プロの実践知：開発スピードを最大化するエコシステムと設定
ここからは、日々のオペレーションで爆発的な効果を発揮する「隠れたキラー設定」を公開する。
A. 絶対入れるべき神プラグイン・ツール
1. `pulumi-izing` や各クラウドプロバイダの公式 Language Server
IDE（VSCodeなど）での補完速度が落ちるとIaCの生産性は半減する。言語ランタイムのメモリ割り当てを増やす設定を忘れるな。
2. `direnv` + `.envrc` による環境の自動切り替え
スタックやAWSプロファイルの手動切り替えミスを撲滅する。
B. チーム開発で共有すべき `Pulumi.yaml` のベストプラクティス構成
プロジェクトルートの `Pulumi.yaml` には、プロジェクト全体の挙動を制御するオプションを明記せよ。
name: enterprise-core-infrastructure
runtime:
name: nodejs
options:
packagemanager: pnpm # 高速なパッケージマネージャーを指定
description: Production-grade enterprise infrastructure stack with optimized performance.
config:
pulumi:tags:
value:
environment: production
managed-by: pulumi
タイムアウトやプロバイダ設定のグローバル制御（必要に応じて）
options:
resourceOptions:
# デフォルトのタイムアウト延長やプロバイダのバージョン固定
version: “>= 3.0.0”
C. 開発効率をブーストする隠しコマンド＆ショートカット
- スタックの高速切り替え:
毎回 `pulumi stack select` を叩くのは時間の無駄だ。
# エイリアスを ~/.zshrc に仕込めば一瞬
alias ps=”pulumi stack”
alias pu=”pulumi up –parallel=32″
alias pp=”pulumi preview –parallel=32″
- 完全なリフレッシュを避ける日常のプラクティス:
CI/CD以外で安易に `–refresh` を使わないこと。実リソースとのドリフト（差異）が確実に疑われる場合のみ、ピンポイントで `–target` オプションを活用してプレビュー範囲を絞れ。
# 特定のリソースだけを対象にプレビュー・更新し、爆速でフィードバックを得る
pulumi preview –target=”urn:pulumi:prod::my-proj::aws:s3/bucket:Bucket\$my-bucket”
—
結び：エンジニアリングの主導権を取り戻せ
「Pulumiが遅い」のではない。私たちの設計が、ツールのポテンシャルを縛り付けていたのだ。
並列度の最適化、暗黙的依存の排除、そしてドメイン境界に基づくステートの分割。これらを実践した瞬間から、あなたのCI/CDパイプラインは見違えるほど軽快に動き出し、インフラエンジニアとしてのストレスは霧散するはずだ。
待ち時間にコーヒーを淹れに行く時間はもう終わりだ。秒速でフィードバックを得るモダンなインフラ開発環境を、今すぐあなたの手で構築せよ。