本記事の対象読者と前提
本記事は、クラウドインフラの管理、Infrastructure as Code、
技術選定、少人数でのシステム運用に関心を持つ実務者を対象としている。
ただし、本記事は Pulumi の実装手順を解説するものではない。
また、Pulumi と Terraform の優劣を比較する記事でもない。
本記事の目的は、DataLiner が Infrastructure as Code をどのように捉え、
どのような判断基準から Pulumi を採用したのかを整理することである。
重要なのは、Pulumi そのものではない。
DataLiner がインフラ管理に何を求め、その結果としてなぜ Pulumi という選択に至ったのかである。
本記事で参照する主な情報
本記事では、Infrastructure as Code、Pulumi、Terraformに関する技術的特徴について、
以下の一次情報を参照している。
Pulumi
Pulumi Documentation
参照内容
- Pulumi の基本思想
- 一般的なプログラミング言語によるインフラ定義
- TypeScript を含む複数言語対応
- コンポーネント化、再利用、スタック管理
Terraform
Terraform Documentation
https://developer.hashicorp.com/terraform/docs
参照内容
- Terraform の基本思想
- HCL によるインフラ定義
- 宣言的なリソース管理
- 状態管理と実行計画
OpenTofu
OpenTofu Documentation
参照内容
- Terraform 互換のオープンソース IaC ツールとしての位置付け
- 将来的な再評価候補としての確認
AWS CDK
AWS CDK Documentation
https://docs.aws.amazon.com/cdk/v2/guide/home.html
参照内容
- AWS CDKの基本思想
- 一般的なプログラミング言語によるインフラ定義
- AWS CloudFormationを通じたAWSリソースのプロビジョニング
- Constructによる再利用可能なクラウドコンポーネント
1. インフラもソフトウェアとして管理する
1.1 IaCが必要になった背景
クラウドインフラは、管理画面から手作業で構築することもできる。
最初の一回だけであれば、それでも問題に見えるかもしれない。
しかし、運用が続くと状況は変わる。
設定変更が増える。
環境が増える。
一時的な修正が残る。
誰が、いつ、何を変えたのかが分からなくなる。
こうなると、インフラは徐々に属人化していく。
見た目には動いている。
しかし、再現できない。
説明できない。
安全に変更できない。
この状態は、小規模な組織ほど危険である。
人が少ないからこそ、一つひとつの変更履歴や判断の記録が重要になる。
DataLinerでは、インフラを一度作って終わりのものとは考えていない。
継続的に改善し、必要に応じて見直し、将来の変更にも耐えられる形で管理したかった。
そのため、Infrastructure as Code を前提にする必要があった。
1.2 手作業管理の問題
手作業によるインフラ管理には、いくつかの問題がある。
第一に、再現性が低い。
同じ環境をもう一度作ろうとしても、手順が曖昧であれば再現できない。
第二に、変更履歴が残りにくい。
コンソール上で変更した設定は、後から差分として確認しづらい。
第三に、レビューが難しい。
アプリケーションコードであれば、Pull Requestを通じて変更内容を確認できる。
しかし、手作業のインフラ変更は、事前にレビューしづらい。
第四に、属人化しやすい。
担当者の頭の中にだけ構成が存在する状態になる。
これは、長期運用において大きなリスクである。
1.3 DataLinerがIaCに求めたもの
DataLinerがIaCに求めたものは、単なる自動化ではない。
重要だったのは、次の要素である。
- 再現性
- 変更履歴
- レビュー可能性
- 保守性
- 将来の再評価可能性
インフラ構成をコードとして管理できれば、Gitで履歴を追うことができる。
変更前に差分を確認できる。
レビューもできる。
同じ定義から環境を再構築することもできる。
これは、少人数で運用するDataLinerにとって重要だった。
一人で作るからこそ、未来の自分が分かる形で残す必要がある。
小規模だからこそ、雑にしてよいわけではない。
むしろ小規模だからこそ、仕組みで支える必要がある。
2. DataLinerにおける技術選定の前提
2.1 TypeScriptを中心技術として扱う
DataLinerでは、Webフロントエンドを中心にTypeScriptを重要な技術基盤として扱っている。
表玄関や語り部の座でも、Astro、React、TypeScriptを中心に構築している。
これは単に流行しているからではない。
型によって構造を明示できる。
コンポーネント化しやすい。
再利用しやすい。
AIによるコード生成やレビュー支援とも相性が良い。
こうした理由から、DataLinerではTypeScriptを中心技術の一つとして位置付けている。
そのため、インフラ管理においても、できるだけ同じ技術的な筋肉を使いたいと考えた。
アプリケーションはTypeScriptで書く。
しかしインフラはまったく別の言語や記法で管理する。
それも選択肢ではある。
しかしDataLinerのような小規模な体制では、技術スタックが増えすぎること自体が負担になる。
学習コストも増える。
レビュー観点も分散する。
コードの再利用や設計思想も分かれやすい。
だからこそ、IaCにもTypeScriptの知識を活かせることは大きな意味を持っていた。
2.2 少人数運用における統一性
DataLinerは大きな開発組織ではない。
開発、運用、設計判断の多くを少人数で担う必要がある。
このような体制では、技術の統一性が重要になる。
技術が増えれば、管理対象も増える。
管理対象が増えれば、判断コストも増える。
判断コストが増えれば、運用の継続性が落ちる。
だからDataLinerでは、できるだけ同じ考え方で扱える技術を選びたい。
アプリケーション開発とインフラ管理を完全に別物として扱うのではなく、
どちらもコードとして扱い、Gitで管理し、Pull Requestでレビューする。
この運用に寄せることが重要だった。
Pulumiは、この方針と相性が良かった。
3. なぜPulumiだったのか
3.1 一般的なプログラミング言語でIaCを書ける
Pulumiの特徴の一つは、TypeScriptを含む一般的なプログラミング言語で
インフラを定義できることである。
DataLinerにとって、これは大きな利点だった。
TypeScriptでインフラを定義できれば、アプリケーション開発で使っている知識をIaCにも活かせる。
変数、関数、型、モジュール、パッケージ分割。
こうしたプログラミング言語の仕組みを使って、インフラ定義を整理できる。
もちろん、これは万能ではない。
一般的なプログラミング言語で書けるということは、書き方の自由度も高いということである。
自由度が高ければ、設計を誤る余地もある。
しかしDataLinerでは、その自由度を制御しながら、型安全性や再利用性を活かす方針を取った。
3.2 型安全性と再利用性
インフラ定義では、名前、ID、ARN、リージョン、環境名など、多くの値を扱う。
これらを文字列として雑に扱うと、設定ミスが起きやすい。
TypeScriptであれば、型によってある程度の構造を表現できる。
また、共通処理を関数やモジュールとして切り出すこともできる。
環境ごとの差分も整理しやすい。
同じような定義を何度も書くのではなく、再利用可能な形にまとめられる。
DataLinerでは、こうした再利用性を重視している。
なぜなら、一人または少人数で運用する場合、
同じ知識を複数箇所に散らすことが大きな負債になるからである。
変更箇所が増える。
修正漏れが起きる。
環境差分が分かりにくくなる。
それを避けるために、DRYの考え方をIaCにも持ち込みたかった。
Pulumiは、そのための選択肢として適していた。
3.3 アプリケーション開発と同じ開発体験に寄せる
DataLinerでは、アプリケーション開発においてGit、Pull Request、レビュー、
変更履歴を重視している。
IaCも同じ流れで扱いたかった。
インフラ変更を特別扱いしない。
アプリケーションコードと同じように、差分を確認し、レビューし、履歴を残す。
この運用に寄せることで、インフラ変更の心理的な距離を下げることができる。
インフラは一部の専門家だけが触るものではなく、コードとして扱える対象になる。
もちろん、これは慎重さを失ってよいという意味ではない。
インフラ変更は影響範囲が大きい。
だからこそ、コード化し、レビューし、履歴を残す必要がある。
4. TerraformではなくPulumiを選んだ理由
4.1 Terraformを否定しているわけではない
ここで明確にしておきたい。
DataLinerがPulumiを採用したことは、Terraformを否定するものではない。
Terraformは非常に広く使われているIaCツールであり、実績も豊富である。
HCLによる宣言的な記述は、インフラ定義において強力な選択肢である。
チーム規模、既存資産、運用体制によっては、Terraformの方が適している場合も十分にある。
本記事で述べているのは、
Pulumiが一般的に優れている
という話ではない。
DataLinerの技術方針と制約に照らしたとき、Pulumiの方が合っていた
という話である。
4.2 判断基準からの帰結
DataLinerが重視したのは、次の点だった。
- TypeScriptを中心技術として活かせること
- アプリケーション開発と近い感覚で扱えること
- 型安全性を活用できること
- 共通化や再利用がしやすいこと
- 少人数でも継続運用しやすいこと
- Gitによる変更履歴管理と相性がよいこと
これらの判断基準を並べたとき、Pulumiは自然な選択肢だった。
Pulumiを使いたかったから採用したのではない。
TypeScriptを中心とした開発体験、
少人数での運用、
再現性と変更履歴管理、
これらを重視した結果として、Pulumiが選ばれたのである。
4.3 AWS CDKではなくPulumiを選んだ理由
Pulumiを採用するにあたり、同じくTypeScriptでIaCを書ける選択肢として
AWS CDK も検討対象になり得る。
AWS CDK は、TypeScript、JavaScript、Python、Java、C#、Go などの
一般的なプログラミング言語でクラウドインフラを定義できるフレームワークである。
また、AWS CDK は AWS CloudFormation を通じてAWSリソースをプロビジョニングする
仕組みであり、AWSに深く統合されたIaCの選択肢である。
そのため、AWS上のシステムだけを対象とし、AWSのベストプラクティスや
Constructを積極的に活用したい場合には、AWS CDKは有力な選択肢になる。
一方で、DataLinerでは、IaCをAWS専用の仕組みとして閉じすぎないことも重視した。
現時点ではAWSを中心に利用している。
しかし、今後もすべてのリソースがAWSだけで完結するとは限らない。
例えば、GitHub、SaaS、外部サービス、DNS、監視基盤など、
クラウドインフラの周辺にはAWS以外の管理対象も存在する。
そのため、DataLinerでは、
「AWSを管理するためのIaC」
ではなく、
「インフラと周辺リソースをコードで管理するためのIaC」
として捉えたかった。
この観点では、Pulumiの方がDataLinerの考え方に合っていた。
PulumiはAWS専用のIaCではなく、複数のクラウドやサービスを対象にできる。
もちろん、これはAWS CDKが劣っているという意味ではない。
AWS上に閉じた構成であれば、AWS CDKは非常に自然な選択肢である。
しかしDataLinerでは、将来的な管理対象の広がりや、
AWS以外のリソースも含めた統一的な管理を考えた結果、Pulumiを採用した。
5. Pulumi採用における注意点
5.1 自由度が高いことはリスクでもある
Pulumiは一般的なプログラミング言語でインフラを定義できる。
これは利点である。
しかし同時に、リスクでもある。
自由度が高いということは、設計のばらつきが生まれやすいということでもある。
書き方を揃えなければ、複雑なコードになってしまう。
抽象化しすぎれば、かえって読みにくくなる。
関数化や共通化を進めすぎれば、インフラ定義の意図が見えにくくなることもある。
そのため、Pulumiを使う場合でも、設計方針や命名規則、モジュール分割の考え方を持つ必要がある。
道具が優れていても、運用設計がなければ負債になる。
これは、いかにも人類らしい落とし穴である。
5.2 将来的な再評価可能性
DataLinerでは、Pulumiを採用している。
しかし、将来も必ずPulumiを使い続けると決めているわけではない。
技術選定は、固定された信仰ではない。
状況が変われば、選択も変わる。
チーム体制が変わるかもしれない。
運用規模が変わるかもしれない。
TerraformやOpenTofuの方が適する状況になるかもしれない。
その可能性は残している。
重要なのは、現時点の判断基準に対して、どの選択が適しているかである。
DataLinerにおいては、現時点でPulumiが適していた。
それ以上でも、それ以下でもない。
5.3 DataLinerにおけるPulumi運用の改善点
Pulumiを採用したことで、TypeScriptによるIaC、型安全性、再利用性といった
利点を得ることができた。
一方で、Pulumiは自由度が高い。
そのため、運用ルールを持たずに使うと、構成が複雑化するリスクがある。
DataLinerでは、今後Pulumi運用を安定させるために、
以下のような最小ルールを整備していく必要がある。
- スタックの分割方針を明確にする
- 環境ごとの差分管理の考え方を整理する
- Secretや機密情報の扱いを明文化する
- 共通化しすぎない粒度を決める
- Pull Request時のレビュー観点を整理する
特に重要なのは、共通化の粒度である。
IaCは共通化すればするほど良いわけではない。
過度な抽象化は、かえって構成の意図を見えにくくする。
少人数で運用するDataLinerでは、
「再利用できること」
と
「読んで分かること」
のバランスを取る必要がある。
Pulumiは、そのまま使えば自然に良い運用になる道具ではない。
よい運用にするためには、設計方針とレビュー観点が必要である。
おわりに
本記事では、DataLinerがなぜIaCとしてPulumiを採用したのかを整理した。
重要なのは、Pulumiが優れているかどうかではない。
Terraformが劣っているかどうかでもない。
DataLinerがインフラ管理に何を求めたのか。
どのような制約の中で運用する必要があったのか。
どのような技術方針を持っていたのか。
その結果として、Pulumiが選ばれたのである。
技術選定とは、道具の勝ち負けを決めることではない。
判断基準を定め、その基準に照らして選ぶことである。
DataLinerにおけるPulumi採用は、その一つの記録である。