【要約】Cloud Run Worker Pools を Terraform で立てたら毎回 drift した [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が Cloud Run Worker Pools を Terraform で管理しようとする際、設定の不整合やリソース特性に起因する問題に直面する。具体的には以下の課題がある。
- ・公式ドキュメントのサンプルに従い
scaling_mode = "MANUAL"を記述すると、apply 後も常に差分（drift）が検出され、解消されない。 - ・Cloud Run サービスと異なり、負荷に応じたオートスケールが機能しない。
- ・インスタンス数を変更しても新しいリビジョンが作成されないため、従来のデプロイフローが適用できない。
// Approach
筆者は、Worker Pools の挙動を実測検証し、Terraform での適切な管理手法を提示している。具体的には以下のステップを踏んでいる。
- ・Pub/Sub、Artifact Registry、Worker Pool を組み合わせた一連の構築フローを定義。
- ・Buildpacks 利用時に
Procfileを用いて起動コマンドを明示し、ワーカーとして動作させる。 - ・Terraform の drift 問題に対し、
scaling_modeの記述を削除することで回避。 - ・
manual_instance_countのみを指定し、デフォルト値（MANUAL）に任せることで差分を解消する。
// Result
Terraform を用いた Worker Pools の安定的な管理手法が示された。具体的な成果は以下の通りである。
- ・
scaling_modeの記述を省略することで、terraform planでの不要な差分を完全に解消。 - ・CI/CD パイプラインにおいて、drift によるビルド失敗を防ぐ運用が可能になった。
- ・Worker Pools が「負荷ではスケールせず、手動指定でのみ増減する」という特性を実証的に明確化し、設計ミスを防ぐ知見を提供した。
Senior Engineer Insight
> Worker Pools は、HTTP リクエスト駆動ではない非同期処理において極めて強力な選択肢だ。しかし、オートスケールを期待して設計すると、スパイク時に処理遅延を招くリスクがある。スケーリングは外部メトリクスを用いた自作の仕組みが必要だ。また、Terraform の provider バグは、公式ドキュメントを盲信せず、実機検証を行う重要性を改めて示している。