はじめに
はじめまして！
チャットコマースサービス「CARU」でPdMをしている satoharu と申します。
先日 tfuka が技術選定の記事を公開しましたが、これらのインフラは Pulumi という構成管理ツールで管理しています。
日本でのプロダクトでの導入事例を耳にしたことがなく、また初めて聞いた方も多いのではないでしょうか。
今回は、なぜ構成管理に Pulumi を採用したのか、また、実際に採用してどうだったのかをご共有できればと思います。
Pulumiって何?
Pulumi は、インフラをコード管理するためのIaCのツールの一種です。IaCのツールとしては、Terraformが有名ですね。
TerraformがHCL言語で管理する一方、PulumiはGoやTypeScriptなど、アプリケーションエンジニアが普段使いしている言語で管理できることが大きな特徴です。
なお、Pulumiの仕組みは以下のようになっており、構成管理に触れたことのある方なら、お馴染みでは無いでしょうか。
なぜPulumiを選択したの？
当時のチーム状況を鑑みて、他のツールと比べてPulumiが合っていると判断しました。
当時のチーム状況
当時、チームにはインフラエンジニアはいませんでした。また、インフラエンジニアがチームにいないのは、一時的ではなく、将来的にも採用予定はありませんでした。
そのため、チームに在籍していたバックエンドエンジニア3名でインフラの管理をする必要がありました。加えて、構成管理経験のあるバックエンドエンジニアは、1名のみでした。
重視した観点
上記チーム状況を踏まえ、ツールの選定には、以下を重視しました。
- 運用コストの安さ
- 学習コストの低さ
- 今のチームは勿論、今後チームメンバーの入れ替わりが発生しても、開発スピードを落とさずにメンテナンスすることができる
- ドキュメントの豊富さ
- コミュニティの発展具合
- 学習コストの低さ
- 現時点で扱っているGCPリソースは最低限対応していて欲しい
- GCP外のリソース管理ができたり、リソースへの対応スピードが早かったりすると、尚可
選択肢
この内、特に有力な選択肢に上がったのは、以下の3つです。
Terraform
IaC界のデファクトスタンダードです。
公式ドキュメントが豊富なだけでなく、コミュニティも発展しており、開発に詰まっても近しい課題を抱えた方々の事例を参考にすることができます。
HCL言語で、インフラを管理します。
CDK for Terrafrom
AWS CDKのバックエンドを、Terraformにしたもので、Terraformのラッパーです。
HCL言語ではなく、GoやTypeScriptでインフラを管理できるようにしているのが特徴です。
Pulumi
先ほどご紹介した内容に付け加えると、公式ドキュメントが非常に豊富です。
一方で、コミュニティは発展しておらずで、他社の導入事例も見当たらないため、行き詰まった際の問題解決が難しいのではと思われました。
ただ、ハンズオンで使用感を確認してみると、どうやら(僕たちが利用予定の)リソースのAPIが、Terraformとほぼ同じであるということがわかりました。そのため、Terraformのコミュニティでやり取りされている内容が、Pulumiでもそのまま参考にできそうだ、ということが見えてきました。
比較結果
各ツールを比較したところ、Pulumiが最もチームに合っていると判断しました。
| Terraform | CDK for Terraform | Pulumi | |
|---|---|---|---|
| 運用コストの安さ | △ ~ ⚪︎ | △ | ⚪︎ |
| リソースの対応 | ⚪︎ | ⚪︎ | ⚪︎ |
| 所感 | チームで扱う言語が増えることだけがネック | 公式ドキュメントはあるが、詳細な使用方法を見たい場合は、Terraformのドキュメントに案内される → 結局HCLを読めないといけない&HCLからの読み替えのコストがかかる |
チームの実情に最も合っている。 実務運用したことは無いが、Terraformの知見がそのまま参考にできることで、その課題をカバーできそう。 |
どのように開発しているのか
設計思想
Pulumi公式からは、ディレクトリ構成のベストプラクティスは発表されていないようです。
とは言え、先ほど触れたように、Pulumiの思想はTerraformと近しいため、Terraformのベストプラクティスをベースに設計しました。
以下をポイントにしています。
- 各マイクロサービス間で再利用可能なmoduleを作成する
- マイクロサービス用のディレクトリを作成し、事前定義したmoduleを組み合わせる
具体的には、以下のような構成にしています。
infrastructure/
├ index.ts // エントリポイント
├ Pulumi.prod.yaml // prodの設定
├ Pulumi.stg.yaml // stgの設定
│
└ services // マイクロサービスごとのリソースのまとまり
│ ├ common/ // どのマイクロサービスにも依らないリソース
│ ├ serviceA/
│ │ ├ dns.ts // 例.resource/gcp/dns.tsの共通処理を呼び出して、マイクロサービス固有のリソースを作成する
│ │ ├ ...
│ │ └ lb.ts // 例.resource/gcp/lb.tsの共通処理を呼び出して、マイクロサービス固有のリソースを作成する
│ ├ ...
│ └ serviceC/
│ ├ dns.ts // 例.resource/gcp/dns.tsの共通処理を呼び出して、マイクロサービス固有のリソースを作成する
│ ├ ...
│ └ lb.ts // 例.resource/gcp/lb.tsの共通処理を呼び出して、マイクロサービス固有のリソースを作成する
│
└ resources // servicesで利用するために共通化されたリソース
└ gcp/ // プロバイダ毎に設定
├ dns.ts
├ ...
└ lb.ts
たとえば、resources/gcp/ 配下にはDNSやLoad Balancerなどの共通リソースを定義しておき、
それらを services/serviceA/ や services/serviceB/ などの各マイクロサービス用のディレクトリ内で import して再利用しています。
これにより、同様の構成が必要なマイクロサービス間での重複した実装を避けることができています。
普段の開発
以下のような流れで、開発を進めています。
他の構成管理ツールと比べても、特段真新しいステップは無いと思います。なお、後述しますが、CI/CDを構築していないのが現状の課題です。
- STG環境で、実際にリソースを反映させながら実装する
- PROD環境に適用できるか、Dry Runする
- 1と2が問題無ければmainブランチにマージ
なお、レビュー時には、Dry Runの結果もレビューする - PROD環境に適用する
1年ほど運用してみて
本番環境に導入してから、1年が過ぎました。実際に導入してみての所感を以下に、記載します。
開発体験が良い&運用コストが安い
当初期待したいた、運用コストの安さの恩恵を充分に受けられています
基本的には、Pulumiの公式ドキュメントと後述のPulumi AIの利用で事足りています。必要に応じてTerraformのコミュニティの事例も参考にしており、コミュニティの小ささという課題を感じさせません。
構成管理初挑戦のバックエンドエンジニアのメンバーも、構成管理独特の概念に慣れる必要はありましたが、それを乗り越えた後は、スッと開発/運用に入ることができています。
僕自身は、前職でTerraformを利用していたのですが、アプリケーションの実装時とインフラの実装時で利用する言語の思想が違っていて、頭のコンテキストを切り替えるのがややストレスに感じていました。Pulumiでは、アプリケーションの実装とインフラの実装を、地続きで行えて開発体験が良いです。
Pulumi AIの精度が高い
Pulumi AIとは、自然言語で問い合わせると、Pulumiのコードを提案してくれる生成AIツールです。
有名な生成AIツールにはClaudeやChatGPTがありますが、Pulumiに特化しているという点で、出力結果の精度が2段くらい高い感があります。
Pulumi導入当初に、手動で作成していたマイクロサービスを全てPulumiに移管する際に、このツールとひたすらペアプロをしていました。リリースまでのスケジュールがタイトな中で、Pulumiを導入まで持っていけたのは、Pulumi AIで工数削減できたことが大きいです。
CI/CDを構築していない
これは反省点です。先ほどもお伝えしたように、現在は構成管理に対してCI/CDを構築していません。(※各マイクロサービスのCI/CDは構築しています)
そのため、手動で静的チェックしていたり、リリース時にマイクロサービスのリリースフローと少し異なっていたり、と課題が見えています。
既存のCI/CDツール(ex. GitHub Actions)以外にも、Pulumi CloudというPulumi向けのCI/CDを内包したツールもあり、これらの使用を検討しています。
おわりに
日本での導入事例をほぼ見かけないツールを、本番運用することはチャレンジでしたが、導入して良かったと言える状態には持っていけました。
構成管理ツールの選定に迷っているプロダクトの、参考になれば幸いです。
構成管理に限らず、弊社では技術的なチャレンジを続けています。
今後もそのチャレンジを発信していくので、楽しみにしていただければと思います。
株式会社CyberACEのテックブログです。開発チームが日々の業務で得た技術的な学びや知見を発信します。主な技術スタック: TypeScript, Go, React, Next.js, AWS, GCP cyberace.co.jp
Discussion