仕事はともかくとして, 個人として趣味エンジニアリングと野球データ分析の人です.
このブログは先日（2024/3/8）に開催された「第22回 酒とゲームとインフラとGCP」の発表および質疑応答から生まれたエントリーとなります.
現地も大変盛り上がりましたし, スライドも殊の外に反響を頂いて*1驚いています.
この場を借りてお礼申し上げます🙏
発表後, 現地ではいくつかの質疑応答や会話, ディスカッションがありましてその中で最も印象に残った件がこちら.
何故Terraformを書いたのですか?シェルスクリプトでも良いのではないでしょうか?
そうですよね, 単に個人開発（趣味）で作っているものでTerraformとGitHub ActionsでのCI/CD（この件は後日別に発表&ブログ書きます）まで頑張らなくても, shellでサクッとgcloudコマンド叩いてデプロイでも全然良いのでは?となるのは当然の反応かなと思います*2.
この質問に対して私は,
- 個人開発したシステムは毎年使うかつ構成が複雑化したので時間を投資してTerraformで書きました.
- Shellでも良かった（実際gcloudコマンドを叩くシェルも書いてた）のですが, 事故りそうだったので置き換えました.
- Terraformの知見・経験を貯める意味でもやってみた.
的な回答をしました（正確なコメントは覚えてませんがニュアンスはこれ*3）.
こんな感じで1枚のスライドに（雑に）収めたものの, もうちょっと補足があってよいのかなと思ったのでブログに残そうと思います.
それなりに根拠があるんでね.
なお, あくまでも私shinyorkeの個人的な見解・意見かつ趣味の話であり, 所属団体・企業を代表する意見ではないことを予め断っておきます*4.
TL;DR
自分が携わっているシステム・プロダクトが複雑かつデプロイ回数増えそうだったらIaC入れておけ, 個人開発（趣味）だったとしても.
1年後いや半年, 3ヶ月後の自分が救われる可能性があります, IaCしておくと...という話を「LeanとDevOpsの科学」の個人版みたいなノリでお送りします.
我思うIaC
というわけでIaCのはなしをしますがこのエントリーで話したいことは「デプロイ回数（少ない⇔多い）」「アーキテクチャ（シンプル⇔複雑）」の2軸で表す以下の四象限で終わってしまいます.
何を持ってして「デプロイが多い・少ない」「アーキテクチャが複雑・シンプル」かは個々人の判断にお任せしますが,
- 毎日とまでいかなくても週に一度以上, 本番環境にデプロイしている.
- 一つのアプリケーションを構成するのにフロントエンド, バックエンドそれぞれサーバがあってDBはクラウドのマネージドなサービスを利用している.
とかこういう感じに書くと「ああデプロイ多そうだし複雑だよね」って思うんじゃないかなと思います（どっちも私の主観ですが）.
オチをざっくり言ってしまうと,
デプロイの回数が多くて複雑なシステムだったらIaCやっとけ, シンプルだったとしてもデプロイ多ければやっとけ.
が回答となります.
デプロイが多かったらやろう
「デプロイの回数」はIaC化する上で明確な基準かなと個人的には思っています.
アプリケーションに何かしらの機能を追加（もしくはbugfix）してデプロイ, みたいな営みを楽にやりたいのはエンジニア共通の願望だと私は思っています, これはデプロイの回数が多いシステムであればあるほどそう思いますし, デプロイの手順が複雑だったら泣いちゃいます*5.
私が個人開発で作っている野球データ基盤は,
- メジャーリーグから提供されるデータにて仕様変更の可能性*6がある.
- データの取得タイミング*7など, シーズン中でも対応すべきエンジニアリングの事項がある.
- リファクタリング*8とか含めて月に1, 2回は触るだろうなー
という想定（というより去年までの経験）の元, 「これはTerraform入れたら楽やぞ！」ってなりました.
構成が複雑だったらやろう
「複雑なシステムはコード化（IaC化）しておけ」も個人的には明確な判断軸であると思っています.
「構成が複雑」は色々意見あると思いますが,
- ネットワーク構成
- サーバの台数
- アプリとDB, もしくはマイクロサービス同士の依存関係
考えるとキリが無いんじゃないかなと思います, 個人的には各クラウドサービスでシンプルに作る選択肢が増えた一方, 「シンプルなハズだったのに中々の構成になりそう🤔」みたいな事も増えた気がします*9.
という前提で私の話をすると,
こうやってお絵描きするとシンプルに見えるし, なんかカッコよい気もしますが,
ワイ「Cloud Runで動くアプリが3つ, Cloud Pub/Subが2つ, Workflow（詳細は前回のブログを御覧ください.）を動かすためのschedulerが一つ, それに紐づくService Accountとそのbinding...いくつあったっけ😇*10」
自宅の書斎で, 外のカフェ（と飲み屋）で作りながら常にこの悩み*11があり, 「なんかやっぱ複雑じゃね!?」となりTerraformで管理することを決意しました.
ちなみにオライリーのTerraform本曰く,
Infrastructure as Codeの利点とは
という記載が第一章にありますが, 複雑になればなるほど利点に授かれるのでやっておきましょう.
ちなみに良い本ですよこちらは.
小さいシステムはどうする?
「IaCは時と場合による」かなと. このタイミングは他にやることがいっぱいあると思われるため.
デプロイ回数がさほど多くなく, アプリケーションも小さい（例えばSlack Bot, 例えば個人のWebサイト）モノでインフラがシンプルだったりインフラよりコードを書く方頑張りたいのであればIaCは明確に不要, 入れるにしても最後で良いのかなと思います.
仕事はともかくとして, 個人開発や個人的なアプリなレベルであれば,
- FirebaseやHerokuといったフルマネージドなサービスで作ってしまう. これであればコマンドベースでデプロイできる, 自動化もし易い*16.
- Slack BotみたいになにかのHookで動く（UIがない）アプリならAWS LambdaやCloud Functionsなどの関数系マネージドサービス（いわゆるFunction as a Service, 通称FaaS）を利用する.
これで十分かなと.
ちなみに私が取る手段はFaaSが最も多いかもしれません.
FaaSで済むものならこれで十分すぎます.
我々は何故IaCに悩むのか?
「デプロイ回数」「複雑性」に特化して「IaC（もしくはTerraform）は必要か?」をまとめましたが, そもそも入れるか入れないかで悩む*17のはこの辺かなと思っています.
- 「IaC化のメリットがわからん」 - Terraformナニソレ美味しいの?的なご意見.
- 「Shellじゃだめなのか?」 - 既にコード書いてやってるじゃん！何が違うのかというご意見.
- 「学習コストが高い（覚えるのが辛い）」 - Shellの次にAnsible覚えたのにまた新しい道具覚えるのか!?的なご意見.
こちらについても考えを書きますねと.
メリットがわからん
敢えて抽象的なメリットを言うと「開発者と運用者のストレス軽減効果」があります&これが中長期で地味に効いてきます.
Infrastructure as Codeの利点とは
- セルフサービス
- スピードと安全性
- ドキュメント化
- バージョン管理
- バリデーション
- 再利用性
- 幸福
という記載が第一章にあります（再掲）が, これが全てかなと思います&気になる方はオライリーのTerraform本の第一章を読んでください.
また, これはエンジニアな組織的な観点で言うと,
「継続的デリバリのプラクティスを導入すると、デリバリのパフォーマンスが向上し、組織文化に好影響が及ぶ。さらに、燃え尽き症候群（バーンアウト）やデプロイ関連の負荷が軽減される」
※「LeanとDevOpsの科学」第5章より引用.
「継続的デリバリ」の対象にIaCが入るのであれば全く持って同じこと（デリバリーパフォーマンスの向上と組織文化への影響）が言えます, 一度IaCの作業に慣れたら手作業に戻りたいと思う人はごく少ない*18んじゃないかなと思います.
個人開発だと自分ひとりなので組織文化は無いかもですが笑, 少なくとも自分に降りかかるトイルは減るので有効かなと.
Shellじゃダメなの?
Shell（&ChefやAnsible）などの「手続き型な作業自動化」以上に, Terraformのような「宣言型な作業自動化」の方が受けられるメリットが多いのでオススメです特にクラウドは.
この違いをざっくり書くと,
- 手続き型
- 宣言型
- 「Infraのあるべき姿」をツール上で記載し, 実行する（自動化する）.
- 人が見て「インフラ設計（blueprint）」「パラメータシート」と見比べた場合直感的.
- 宣言的かつ冪等性がある状態となるのでテストがし易い, ヒューマンエラーによる事故が軽減できる （無くなるとは言ってない）.
「1台のLAMPサーバに全部入ってます」みたいな構成ならShellなどの手続き型が直感的*21ですが, 「AWS Lambda関数3つにAPI GatewayとDynamo DBが」みたいな「クラウドあるある」な構成*22であれば宣言型の方が合っているハズ.
なので皆さんTerraformを使うのではと.
学習コストが高い
実行可能なスニペットが転がっているのでまず触ってみよう, Google Cloudの場合は特に.
Terraformに限らず, IaCツールは全般的に覚えるのがとっつきにくいのは事実としてあると思います.
ただ最近は技術ブログやクラウドサービスの公式ドキュメントでTerraformのスニペットやサンプルが増えているので, まずは写経してから覚えるとか良いかもです.
私は今回のサービスを作るにあたり, 「Cloud Run チュートリアルで Pub/Sub を使用する」というチュートリアルを写経してから実装したのですが, こちらにはTerraformのスニペットがあり, 触りながらファイルの構成や実行などを確認できたので最高でした.
Terraformに限った話だと利用者が増えていると思うのでこういうサイトがもっと増えると思います&真似してやってみたら案外覚えるのでやってみるのが吉です.
結び
というわけで, 「個人開発にTerraformは必要か否か?」という話をIaCの必要性および一部DevOpsの文脈で書いてみました.
通常の個人開発では導入判断したうえでやって良いと思いますが, あると幸せなのは保証します（もしくはIaC化不要なマネージドサービスで作っちゃうか）.
なお, このブログでは「IaC化の次のリリース自動化どうすんねん?」という話も近日中に書く予定です.
最後までお読みいただきありがとうございました.
Appendix - 参考書籍
「LeanとDevOpsの科学」および「詳解 Terraform 第3版 ―Infrastructure as Codeを実現する」が主たる参考書籍・文献となります.
さらに深みをもたせたいかたは「クラウドストラテジー」も是非.
こちらも一部参考にしました.
*1:裏話ですが本来このスライドは後続する別のイベントで登壇する内容のdry run（壁打ち）的な内容でした, ちゃんと書いているとはいえ本番仕上がりではないので本人的には驚きです笑
*2:質問・コメントされた方の意見の想像ですが多分そんなに外してないと思います.
*3:個人開発かつ趣味なのでやりたかったのでやった, という元も子もない答えも一応あります笑
*4:正直に言うと仕事での判断軸はまた別ですしそれは流石にここでは書きません（個人の見解・意見から逸脱するため）.
*5:みんなが好きそうな言葉で言う所の「トイル」って奴です. 滅したくなるやつ.
*6:実際あったこととして, 去年から変化球の種類が増えて（オオタニサンがよく投げる「Sweeper」っていう曲がりが大きいスライダーが追加）, 改修とデータの再取得という中々大変なイベントがありました.
*7:例えばオールスターの時期は止めるなど.
*8:これは趣味もありますがPyCon JPなどのカンファレンスに備えた準備とかそういうのもあります.
*9:例えば私はCloud RunやApp Engineみたいなサーバレス系のサービスが好きですが, 実現したい事をやろうとすると周辺のサービス（ストレージやDB, セキュリティなど）で他のモノと組み合わせるピタゴラスイッチがどうしても生まれるので結局複雑じゃね?って思っています.
*10:これはどのクラウドサービス使っていてもあるあるだと思います.
*11:悩み, と書きましたがエンジニアリング的には健全な悩みかつ自分が必要なものを好きに作ってるのでまあ面白いですよと笑.
*12:terraformコマンドで誰でもできる, 自動化しやすいの意味.
*13:デプロイのプロセスの省略可, terraformへの委譲により自動化しやすい, 提供スピードにも影響するの意味.
*14:terraformにはvalidationやdry run（terraform plan）があるのでそこで確認できるやで, の意味.
*15:インフラの手入れ・デプロイというOps（運用）ではなく, 新機能の開発やリファクタリングといったDev（開発）に集中できる喜びってあるよね?の意味.
*16:学習コストの問題はありますがそれは目をつぶっておくとして（小声）
*17:もしくは「必要性の検討」「やる理由（やらない理由）を見つける」の件と思っていただいて大丈夫です.
*18:個人的な感覚ではゼロ人じゃないのが興味深いポイントだったりします（意訳・色んな理由で好む人もわずかながら居ます, 私の経験上）.
*19:例えばサーバを作ろうとしているのに既にいるとか
*20:触っちゃいけないインスタンスを壊したり, 不要なリソースの削除漏れでコストが増したりなど
*21:ここは慣れている手段がベストだと思います, ストレスを感じないのが大事.
*22:この手のアーキはまさにTerraformやServerless Frameworkでやらないと爆死するパターンと認識.
