はじめに
この記事はMIXI DEVELOPERS Advent Calendar 2025 シリーズ2の12日目の記事です．
こんにちは！株式会社MIXI 開発本部 AIモデリンググループでMLエンジニアをしているShuNです．本稿ではKubeflow Pipelines(KFP) v2をGCP上に構築するためのterraformによるインフラ管理，manifests, GitHub Actionsを使用したCICDについて述べます．これらの成果物はOSSとして公開していますので詳細に関しては併せてご覧ください．チームや研究室で導入を考えている方がいればお役に立つと嬉しいです．なお，本稿で紹介するものはセキュリティ面にも一定の注意をした構築になってますが，staging環境の用意などはしていないので，本番システムで利用する際はご注意ください．
実験管理基盤
我々のチームはAI関連の研究開発や事業部門と連携したプロダクトへのAI/MLの実装に携わっており，立ち上げから約1年が経過しています．これまで各メンバーはGCP上で個別にインスタンスやnotebookを立ち上げ，環境構築を行って実験してきました．チームが小規模であれば問題は少ないのですが，規模が大きくなると次のような課題が顕在化・予想されました．
- 他メンバーの実験内容を確認しづらい
- 実験再現に複雑な手順が必要となり，属人化する
- 既存の成果物を知らずに再作成してしまう（componentやpipelineの再利用性が低い）
- 各自が自由にクラウドにリソースを立てることで乱立し，コスト増大を招く
ここで, component はデータ前処理・学習・推論などの処理単位，pipeline はそれらを組み合わせた一連の処理フローを指します．PipelineはDirected Acyclic Graph (DAG)で表され，各nodeがcomponentに対応します．
図1: 簡易的なML Pipelineの例
これらの課題はKFPなどの実験管理基盤によって解決可能です．一度，実験向けのパイプラインを作成することができればそれを再利用することで簡単に実験をjobとして実行し，共有，管理をすることができます．実験管理基盤に使用できるツールは他にもあるのですが，社内外での事例を参考にしつつ，我々のグループも同様に検証をすることにしました．
Kubeflow Pipelinesについて
Kubeflow Pipelines (KFP) は，機械学習ワークフローをコンテナベースで構築・実行・管理するためのオープンソースプラットフォームです．データ取得・前処理・学習・評価といった一連の処理をPython DSLで定義し，Kubernetes(k8s)上でオーケストレーションします．コンテナ化された各処理をk8s上で実行するため，GKEなどクラウドマネージドサービスとの親和性が高く，スケーラビリティに優れることがメリットとしてあります．
現在も開発が進んでいますが，執筆時点ではenv/gcpのmanifestsはv2では正常にデプロイすることが少なくとも筆者が試した限りではできません．また，ドキュメントでも言及がありません．GCPのマネージドサービスを使用しつつ，KFP v2をデプロイする難易度が高かったこと，インフラの管理が煩雑になったことが本稿の執筆の動機になっています．
なお，env/devをクラスターにデプロイすること自体は手順に従えば簡単に行うことができます．これでも良いとは思うのですがDBのメンテナンス，DB向けのnode groupの作成，PV, PVCの管理などを考慮する必要が出てきます．
本稿の目的
ここまでの背景を踏まえた上で，本稿の目的はGoogle Cloud Storage(GCS)やCloud SQLなどのマネージドサービス，terraformによるIaC，GitHub ActionsによるCICDを活用しながらKFP v2をGCP上にデプロイすることです．それでは早速，内容について紹介します．
Terraformによるインフラ管理
まず，全体の大まかなアーキテクチャ図は次のようになっています．
図2: 全体アーキテクチャ
ClusterはPrivate VPCに紐づけられて作成されています．そのため，外部との通信，例えばDockerHubやHuggingFaceなどの関連サービスとの通信はNAT経由で行われます．サービスはチーム向けの独自ドメインで公開するようにしています．エンドポイント(Ingress)はIdentity-Aware Proxy(IAP)で保護されており，システムは許可されたユーザーからしかアクセスすることはできません．図2の中ではLBと表記していますが，これはkubernetes.io/ingress.class: "gce"をannotationに指定したIngressをデプロイすることで自動的に作成されます(参考)．
GCS, Cloud SQLはそれぞれArtifact，実験などに関するmetadataの保管のために使用されます．Cloud SQLはprivateの設定で作成し，Cluster内のpodとの通信にはVPC Peeringを経由します．
また，KFPのシステムで使用するGCPのサービスアカウントとその設定をする必要があります．ここでの設定とはWorkload Identity Federationを使用するためにGCPサービスアカウントとmanifestsで作成されるk8sサービスアカウントをリンクすることを指します．以上から，terraformでは以下のリソースを作成，設定することになります．詳細はソースコードを参照ください．
- VPC, VPC Peering, NATなどのネットワーク関連のリソース
- クラスターをVPC nativeで作成するため
- VPCとCloud SQLの通信のため
- システムと外部サービスとの通信のため
- クラスター, node-pool, scaling設定などのGKE関連のリソース
- 例えば，GPU machineのnode groupの設定など
- GCS
- Artifactの保管のため
- terraformのbackendをgcsに設定した場合は
tfstateの管理も
- Cloud SQL
- 実験やpipelineのmetadataの管理
- Service Account
- GCPリソースの操作で使用される
- IAP Client
- Ingressを保護する
ただし，IAP向けのOAuth ClientはTerraformでは管理しておらず，コンソールから作成するようにしています．これはterraformの該当moduleが非推奨となっているためです(参考)．
Manifests
基本的に公式リポジトリを流用しています．変更点としては独自ドメインにIAP認証をつけて公開するようにしている点と，cloud-sqlの使用に伴って不要になるPVCなどの削除を行なっている点，そして安定した運用をするために元のリポジトリではmasterを参照している部分を2.14.4などの特定のtagを指すようにした点です．これらはあくまでパッチですので，基本的には公式のmanifestをそのまま使用させてもらっている形になります．独自ドメインを使用しない場合はinverse-proxyのresourceを使用してデプロイすることもできます．その場合はIAP関連のパッチを外すようにしてください．
CICD
CICDを導入することでリポジトリのterraformとGCPの状態，manifestsとクラスターの状態が一致するようにしています．ArgoCDなどは使用しておらず，あくまで簡易的なものです．また，pipelineを自動でデプロイする仕組みも作成してあります．
Terraform関連
Mainブランチのterraform/に変更があった際に，自動的にapplyが走り，prではlint check, planが実行されます．Applyの自動実行を使用する場合はWorkload Identity Federation用のサービスアカウントを先に作成しておく必要があることに注意してください(参考)．
Manifests関連
Mainブランチのmanifestsに変更があった際にapplyが自動的に走り，prではyamlのlint-checkが実行されます．こちらもapplyの自動実行を使用する場合はWorkload Identity Federation用のサービスアカウントが必要になります．
Pipeline関連
Mainブランチのpipelinesに変更があったときにクラスター上のKFPに自動でpipelineをdeployするようにしています．prを通過したmainブランチのstableなpipelineとシステム上のpipelineの状態を一致させる意図があります．
まとめ
本稿では，Kubeflow Pipelines v2をGCP上に構築するためのインフラ設計について紹介しました．Terraform，Manifest，GitHub Actionsを活用することで，チームでの実験管理基盤を効率的に構築・運用できる構成を示しました．
主なポイントは以下の通りです：
- Private VPC + NAT + IAPによるセキュアなネットワーク構成
- GCS・Cloud SQLなどマネージドサービスの活用による運用負荷軽減
- TerraformによるIaCでインフラ管理
- CICDによりリポジトリとクラスター状態の一貫性を維持
公式のenv/gcpマニフェストがそのままでは動作しない課題がありましたが，本稿の構成により回避できます．小規模チームでの導入の参考になれば幸いです．筆者はインフラの専門家ではないので，成果物には至らない点があるかもしれません．その際はお気軽にコメントやGitHubのissueからお知らせいただければと思います．
ライセンス，免責事項
本稿で扱うKubeflow Pipelines, 公開した成果物はApache License 2.0の下で配布されています．
本記事の内容を利用したことにより生じたいかなる損害についても，筆者および所属組織は一切の責任を負いかねます．利用される場合は自己責任でお願いいたします．
Discussion