LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Pulumiとは何か　プログラミング言語で書くIaCの仕組み

Pulumiとは、TypeScript・Python・Go・C#・Javaなど汎用プログラミング言語を使ってクラウドインフラを定義するIaC(Infrastructure as Code、インフラ構成をコードで管理する手法)ツールを指します^*1。専用言語であるTerraformのHCLとは異なり、既存の開発言語とそのエコシステムがそのまま使えます。

Pulumi公式は「Pulumi programs, written in general-purpose programming languages, describe how your cloud infrastructure should be composed」と説明しています^*1。つまりプログラムはインフラの構成方法を記述したコードそのものです。対応言語はTypeScript・JavaScript・Python・Go・.NET(C#)・Java・Pulumi YAMLで、いずれも同等の機能を持ち、全プロバイダーの全リソースを利用できます^*4。

汎用言語で書けることの実務上の意味は、ループ・条件分岐・クラス・パッケージ管理・IDEの補完機能といった、開発者が普段使っている仕組みをインフラ定義にそのまま持ち込める点です^*5。似た環境を複数リージョンに展開する処理も、for文や関数として表現できます。

プログラム・スタック・リソース　Pulumiの基本構成要素

Pulumiのプログラムはプロジェクトという単位のディレクトリに置かれます。公式では「Programs reside in a project, which is a directory that contains source code for the program and metadata on how to run the program」と定義されています^*1。プロジェクトの中にプログラム本体と実行に必要なメタデータが含まれる形です。

プログラムを実際にクラウドへ反映するには、CLIコマンドpulumi upを実行します。このとき生成される、プログラムの独立した実行インスタンスをスタックと呼びます^*1*3。スタックはdev・staging・productionのような環境ごとに分けて運用でき、各スタックは個別の設定値を持てます。設定はPulumi.<stack名>.yamlファイルで管理され、pulumi config setコマンドを通じて追加する仕組みです^*3。

プログラム内で新しいインフラを宣言する際は、リソースオブジェクトを割り当てます。リソースのプロパティは、そのインフラに期待する状態（望ましい構成）に対応させる形で記述します^*1。VPC・データベース・コンテナサービスなど、クラウド上の構成要素はすべてこのリソースとして表現されます。

State管理の2方式　Pulumi Cloudとセルフマネージドバックエンド

PulumiはState（現在のインフラ構成を記録した状態情報）を、2種類のバックエンドのいずれかで管理します。1つはPulumi Cloudというマネージドサービス、もう1つは自社で管理するセルフマネージドバックエンドです^*2。

Pulumi Cloudは、公式が「an easy-to-use, secure, and reliable hosted application」と位置づけるホスト型サービスで、デフォルトのバックエンドにあたります^*2。ポリシーやセーフガード機能を備えているため、複数人での協業がしやすくなります。加えてトランザクション型のAPIでチェックポイントを記録するため、更新中に一部の処理が失敗した場合でも復旧しやすい設計です^*2。

一方のセルフマネージドバックエンドでは、AWS S3・Azure Blob Storage・Google Cloud Storage・S3互換ストレージ・PostgreSQL・ローカルファイルシステムなど、任意の場所にStateを保存できます^*2。公式は「you gain control over where your state is located at the expense of having to handle security, state management, auditing」と述べており、保存先を自社で選べる代わりに、セキュリティ・状態管理・監査といった運用責任を自分たちで負う必要があります^*2。またセルフマネージドバックエンドは非トランザクション型のプロトコルに限られるため、一部の障害発生時にPulumi Cloudのような透過的な復旧はできません^*2。

どちらを選ぶかは、社内のセキュリティ基準・既存のクラウド運用体制・複数チームでの協業要件によって変わります。すでに監査ログ基盤や既存のストレージ運用が整っている企業であれば、セルフマネージドを選ぶ余地があります。そうでない場合は、運用負荷を抑えられるマネージド型から始める判断も成立します。

TerraformのHCLとの違い　言語・分岐・テストの観点で比較

Terraformは専用のドメイン固有言語であるHCL(HashiCorp Configuration Language)を使用します^*5。HCLは「引数」と「ブロック」という2つの構文要素を中心に構成され、公式も「a rich language designed to be relatively easy for humans to read and write」と説明する、人間が読み書きしやすい宣言的な言語です^*6。

Pulumiとの主な違いは、汎用プログラミング言語かドメイン固有言語かという点にあります^*5。Terraformにもfor_eachやcount、条件式といった宣言的な繰り返し・分岐表現はありますが、Pulumiは言語そのもののループ・条件分岐・クラス・パッケージ管理・IDE機能を丸ごと利用できる点で自由度が異なります^*5。

State管理の既定値にも違いがあります。Terraformは既定でローカルファイルにStateを保存し、S3やHCP Terraformなどのリモートバックエンドを追加で選択する構成です^*5。Pulumiは既定でPulumi CloudがState管理を担い、必要に応じてセルフマネージド型に切り替えます^*2*5。シークレット管理についても、Pulumiは値を転送中・保存時ともに暗号化しプラグイン可能なKMS(鍵管理サービス)プロバイダーに対応する一方、Terraformは機密値をState内で暗号化しない設計のため、Vaultなど外部ツールとの連携が推奨されています^*5。

テスト手法も異なります。Pulumiは汎用言語であることを生かし、プログラムと同じ言語のテストフレームワークでユニットテストを書けます。公式は外部呼び出しをモック化した高速なメモリ内テストとしてユニットテスト、リソースの入出力値にアサーションを実行するプロパティテスト、一時的な環境に実際にデプロイして動作を確認する統合テストの3種類を挙げ、多くのチームでこの組み合わせが有効な戦略になるとしています^*8。Terraformの検証は主にplanの差分確認やポリシーチェックが中心で、コードとしての単体テストの位置づけはPulumiと異なります。

既存Terraform資産との相互運用　プロバイダーブリッジと変換ツール

すでにTerraformで構築済みのインフラがある企業でも、Pulumiへの移行や併用は段階的に進められます。Pulumi公式は変換用CLIコマンドpulumi convert --from terraformを提供し、HCLで書かれた構成をTypeScript・Python・Go・C#のいずれかのPulumiプログラムに変換できるとしています^*7。既存のTerraformモジュールやTerraform 1.4系の主要機能、大半の組み込み関数の変換に対応しています^*7。

すでに稼働しているリソースをPulumi管理下に取り込む場合は、pulumi import --from terraformコマンドでTerraformのStateファイル（.tfstate）を指定し、対象のPulumiスタックへリソースを取り込む方法があります^*7。取り込まれたリソースは削除保護（protected）が付与された状態でインポートされます^*7。

プロバイダー面での相互運用も進んでいます。Pulumiのプロバイダーには2つの実装方式があり、一部はPulumi Terraform Bridgeを介してTerraformプロバイダーのスキーマを取り込む「ブリッジ型」です^*6。さらに「Any Terraform Provider」という機能を使えば、Pulumi公式のネイティブ対応がないTerraformプロバイダーであっても、pulumi package add terraform-provider <プロバイダー名>を実行するだけで、型定義付きのPulumi SDKをその場で生成し利用できます^*6。これにより数千種類のTerraformプロバイダーに、実質的にPulumiからアクセスできる状態になっています^*6。

既存のTerraform資産を一度に全て置き換える必要はありません。新規プロジェクトだけPulumiで書き始め、既存基盤とはプロバイダー・インポート機能で接続するという段階的な移行も選択肢になります。

外注が必要になる3つの局面　内製で止まりやすい工程

Pulumi導入で内製が止まりやすい局面は主に3つあります。第一に、プログラミング言語でのインフラ設計に慣れた人材の確保です。Pulumiは汎用言語で書けるがゆえに、インフラの知識に加えてTypeScriptやGoなどの言語設計・テスト設計の経験も求められます^*4*8。この両方を兼ね備えた人材は、社内の既存体制だけでは確保しづらいことがあります。

第二に、既存Terraform資産からの移行判断です。変換コマンドや相互運用の仕組みは用意されていますが^*7、どの範囲をPulumiに寄せ、どの範囲をTerraformに残すかという設計判断には、両ツールの仕組みを理解した上での見極めが必要です。判断を誤ると、二重管理によって保守対象が増えるリスクがあります。

第三に、State管理方式の選定と運用ルール整備です。Pulumi Cloudかセルフマネージドかという選択は^*2、社内のセキュリティ基準・監査要件・既存のクラウド運用ルールとの整合を取りながら決める必要があります。この設計を誤ると、後からState移行という手間のかかる作業が発生することもあります。

外注・内製の判断軸　体制・スキル・移行範囲で見極める

外注と内製のどちらを選ぶかは、3つの軸で整理すると判断しやすくなります。1つ目は言語・テストスキルの有無です。社内にTypeScriptやPythonでのアプリケーション開発経験者がいても、インフラリソースの設計・テスト戦略の経験がなければ、立ち上げ期は外部の知見を借りる選択が合理的です。

2つ目は既存Terraform資産の規模です。小規模な新規プロジェクトから始める場合は内製でも進めやすいものの、既存の大規模なTerraform資産を段階的に移行する場合は^*7、変換ツールの挙動理解と移行計画の設計に専門知見が必要になります。

3つ目はState管理・運用ルールの整備状況です。Pulumi Cloudを使うか、セルフマネージドバックエンドで既存の監査基盤に統合するかという判断は^*2、既存のクラウド運用ポリシーとの整合性を確認しながら決める必要があります。判断を先送りにすると、複数チームが異なるState運用ルールで進めてしまう事態になりかねません。

これらの判断を内製だけで進めるには、インフラ・言語・既存資産の3領域にまたがる知見をチーム内に揃える必要があります。立ち上げ期に外部パートナーへ相談し、設計方針を固めた上で内製化を進める進め方も選択肢になります。

失敗コストとLASSICの支援体制　CTA直前に確認する要点

State管理方式の選定を誤ると、後からState移行という手戻り作業が発生します。特にセルフマネージドバックエンドを選んだ後にPulumi Cloudへ切り替える、あるいはその逆を行う場合は、State内容の整合性確認や移行手順の設計が必要になり、稼働中のインフラに影響を与えるリスクがあります^*2。

既存Terraform資産の移行判断を誤ると、TerraformとPulumiの二重管理状態が長期化する恐れもあります^*7。どの範囲をいつまでにPulumiへ移すかという計画がないまま変換を始めると、一部のリソースだけが移行済みで残りが未移行という中途半端な状態が固定化しやすくなります。

Pulumi導入を内製で進めるには、クラウドプロバイダーのAPI知識・プログラミング言語でのテスト設計・既存Terraform資産の読み解きという複数領域の知識が同時に必要です。LASSIC IT事業部は、元請（プライムベンダー）としてシステムの保守・運用を受託する体制のもとで、IaC導入の設計から既存基盤との相互運用まで一貫して支援します。State管理方式の選定や移行範囲の設計といった、後戻りしにくい判断が必要な工程から相談いただくことで、二重管理や手戻りのリスクを抑えながら導入を進められます。

まとめ：Pulumi導入を外注で進める3つの判断軸

本稿ではPulumiの基本概念、TerraformのHCLとの違い、既存Terraform資産との相互運用、そして外注・内製の判断軸を整理しました。要点を3つに集約すると、第一に、Pulumiは汎用プログラミング言語でインフラを記述できる点がTerraformとの主な違いです^*5。第二に、State管理はPulumi Cloudとセルフマネージドの2方式があり、社内の運用体制に応じた選定が欠かせません^*2。第三に、既存Terraform資産とは変換ツールやプロバイダーブリッジを通じて段階的に相互運用できます^*7。これらの判断を的確に進めるには、インフラ・言語・既存資産という複数領域の知見が必要になるため、立ち上げ期の外部パートナー活用が導入の後戻りを防ぐ有効な手段になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Pulumi「Pulumi Concepts」（Pulumi公式ドキュメント）
2. *2　出典：Pulumi「State and Backends」（Pulumi公式ドキュメント）
3. *3　出典：Pulumi「Stacks」（Pulumi公式ドキュメント）
4. *4　出典：Pulumi「Languages & SDKs」（Pulumi公式ドキュメント）
5. *5　出典：Pulumi「Pulumi vs. Terraform」（Pulumi公式ドキュメント）
6. *6　出典：Pulumi「Resource Providers」／HashiCorp「Configuration Syntax」
7. *7　出典：Pulumi「Migrating from Terraform」（Pulumi公式ドキュメント）
8. *8　出典：Pulumi「Testing」（Pulumi公式ドキュメント）

Tweet