この番組はエンジニアの成長は楽しい学びからをモットーに普段勉強した内容をワイワイお届けするラジオになってますはい今日の勉強した内容はテラフォームベストプラクティステラフォームベストプラクティスはいというこれはね何なんでしょうねテラフォームベストプラクティスって調べるとすぐ出てくるサイトなんですけどもうサイト名なんだはい

サイト名がテラフォームベストプラクティシーズっていうすごいな作ったやつの自尊心これ公式じゃないんですよ今のりさんが言った通り公式じゃないのすごいよな公式じゃないのマジ意味わかんないんですけどすごいよなそれ公式じゃないサイトがあってですね俺も作ろっかななんか有名な人というか有識者によって作られたサイトらしいんですけど

まずテラフォームこれあのIACインクラストラクチャーズコードを実現するツールの一つですね多分一番有名くらいじゃないですかそれ系だとむしろ他ってどんなのあったっけアンシブルとかクラウドフォーメーションとかそういうことかアジルとかにもあるんでしょうけどコードでインクラの構成管理するやつなんですがで

非常に申し訳ないんですけどマニュアルは体系的に読んだことあるがベストプラクティスそんなに気にせずに書いてきたかなと思って僕はちょっとベストプラクティス体系的に眺めてみてでその良い設計の勘どころとかあとはまあなあなあでやっちゃってるところちょっと正したいなっていうのが今回のエピソードになってますなるほどなんかその二重でむずいなっていう二重でむずいなっていうのとあれなんですけどはい

テラフォームの部分だけってことですかテラフォームだけですすごいななんかあれってさそもそものインフラ構成自体のベストプラクティス的なところもあるはずじゃないですかあるはずですね一旦そこはさておきテラフォームの機能を使う上でのベストプラクティスってことですかですですですちょっとまだどこにそのベストプラクティス城があるのっていうところあると思うんでそうよねちょっとそのベストプラクティス城を感じてもらうためのちょっと前提情報からいきますわかりました

ノリさんちなみにテラフォーム触ったことあるんですよねまあはるか昔になのでちょっと概念的なところを復習するところからいきたいなと思ってますノリさんと僕はたまたまAWSどっちも触っているのでちょっとAWSベースの話になってしまうかもしれないですけど伝わるように話していきますまず概念の整理なんですけどテラフォームのコードって

1,2,31,2,33層に分かれてます3層に分かれてますか3層に分かれてます3レイヤーありますどういうことだはい

一つ目がリソースと呼ばれるものですねこれリソース何かっていうとテラフォームってどのIACもそうじゃないかこれ宣言的に書いていくようなものなんですけどVPCネットワークですねAWSのVPC作ろうと思ったらAWS VPCっていうリソース作りますとAWS VPCこういう設定ですっていうのを1ブロック中括弧で囲うのかなはい

書くんですけどそれをリソースと呼びますこれ一番ちっちゃい単位一番ちっちゃい単位そのリソースをまとめたやつこれリソースモジュールって言いますリソースモジュールペンパイナップルってこと?ペンパイナップルですね完成してしまいましたねペンパイナップルですねリソースモジュールペンパイナップルこれは例えばそうだな

ラムダサーバーレスでプログラムを実行するエネルギーサービスなんですけどラムダって使おうと思うとラムダだけじゃ動かないんですよというのもこれはちょっとパブリッククラウドの知識ある程度ある人向けなんですけどラムダ単体で実行しようと思った時に例えばじゃあS3のファイル読み込みますみたいな時に

ラムダだけ作っても動かなくてラムダで使うアイアムロール権限を権限を作ってその権限をラムダにつけてあげるみたいなことをしなきゃいけないんですよ他にもネットワーク的に設定がいろいろあるかと思うんですけどそのラムダとラムダに必要な権限を作るのを一つにまとめるみたいな

使い方をしますリソースモジュール動く単位でまとめてるようなイメージですかおっしゃる通りです再利用可能な単位ですねなるほどなるほど例えばEC2とかだったらサーバー立てれると思うんですけどサーバー立てるというかコンピューティングリソース使うっていう感じだと思うんでVPC上に配置したりするみたいなそういうことですかまあ

そうですねただVPCはリソースモジュールEC2と一緒にしない気がしますねしないんだなぜならVPCの中にEC2とラムダがあるかもしれないじゃないですかEC2っていうリソースモジュールペンパイナポーの単位で作っちゃうとラムダだけ作ろうと思った時にVPCないってなっちゃうんでなるほどそうですVPCと多分EC2は分けるただEC2とEC2に使うIAMロール権限は一緒にする気がしますねなるほどなるほど

IAMロールは多分使い回さないしEC2とセットでしか使わないんで例えばそこのアプリケーションでS3使ってたりとかRDSでデータベース使ってたりした場合はそこもペンパイナップル化するわけですかRDSも多分分けるなぜならEC2以外から叩かれるかもしれない確かにみたいなそういう形の流度ですね分かってきたかもほぼほぼAWSサービス単位になりますうんうんうん

例えばフロントエンドにアンプリファイ使ってますバックエンドでAPIゲートウェイとラムダ使ってますデータベースRDSSみたいな感じだったらアンプリファイとアンプリファイややこしいアンプリファイとAPIゲートウェイラムダRDSみたいなそれぞれ一個ずつ食べる形になりますねなるほどこれリソースモジュールですねはい

一般的にはリソースはファイルの中の一要素ですねリソースモジュールも一ファイルの中でガーッと書かれますちょっと

やや語弊があるんですけど基本的に書かれますリソースモジュールリソースって作るときは1ファイルで書けるんですけどリソースモジュールにしようと思ったらリソース作るときに渡したい変数とかがあるんでその変数とか全部ひっくるめてリソースモジュールって呼ぶんで厳密に言うと1フォルダになります1フォルダフォルダになりますリソースモジュールは一旦ふわっとしておいてくださいはい

次そのリソースモジュールをブーンってやったやつペンパイナップアップペンですね出たPPAPこれインフラストラクチャーモジュールでございますインフラストラクチャーモジュールさっき言ったようにマジアンプリファイアややこしいなすみませんS3とクラウドフロントにさせてくださいS3とクラウドフロントこれでフロントエンドホスティングしてますで

ラムタとAPI GatewayとRDSフロントとバックエンドとデータベースそれぞれをリソースモジュールで一個ずつまとめてますそのリソースモジュールをまとめて一つのアプリケーションとして動く単位にしているのがインクロストラクチャーモジュールになりますねこれはもうアプリ単位そうですねこれはアプリ単位にするか複数アプリをまとめるかは正直プロジェクトの戦略次第だと思うんですがただ

後で話しますベストプラクティスに入るところとりあえず3つのレイヤーがあってそれぞれの単位で分かれているこれがPPとPPとPPAPの話ですねPとPPとPPAPねリソースリソースモジュールインクラストラクチャーモジュールあとは知っておくべき登場人物2人今回のベストプラクティスとはあんまり関係ないかもしれないですけど

一つがデータソースってやつですねこれはリソースモジュールとかインクラストラクチャーモジュールの中に入るやつなんですけどデータソース文字通りですねAWS上の情報を取っていきたいな例えばとあるEC2のARNっていうリソースのネーム取っていきたいなみたいなときにその

実際にデプロイされているやつの情報を取ってきてで使えるみたいなはいはいはいこれデータソースってやつですデプロイ後のIPアドレスとか割り振られたそうですねそうですね多分取れんのかなちょっとすいません厳密には分かんないですけどあとはリモートステートと呼ばれる実際にデプロイされている状態を保持しているやつそれはAWS上で持っているやつを取ってきてるんですかえっとですねデフォルトだとローカルでファイルで記録されますうん

最新でデプロイした状態はこれだみたいななのでリモートでテラフォームでデプロイしたのにリモートでAWSコンソールで直接編集した時に差分が出るんですけどその差分はローカルで保存してる俺がやったはずの完成物とリモートの状態が違うから差分が出てるって判断するんですけど

これがリモートステートってやつですねリモートの状態ただ一般的にはローカルで保存するんじゃなくてS3みたいなところで保存しますねクラウド上のどっかのバケットS3にリモートの状態を持っていくことによって複数人の開発者が入っても何デプロイしたはずのものを共通で確認できるようになってますまあそりゃそうだよね各々でいや俺のと違うとか言われてもねいやそうだよってなるもんなそうそうそうそうそうそう

そうだよねって変えてからあなたの方が後にやったもんねみたいなねこれは概念の整理なのでリソースリソースモジュールインフラストラクチャーモジュールをどのようにファイルで分けてどのようなディレクトリにするかあとはプロジェクトによっては位置環境ならいいかもしれないんですけど複数環境あるときにどういう風にするかとかこの辺ちょっと

ベストプラクティス素人なんですよ確かに今ふわっとテラフォームを触った

時のことを思い出したんですけど1個のファイルにも書けるしファイル分割もできるしディレクトリも切れるしいろんなファイル作れるじゃないですかってなった時にこれどこに何を置いてどうしたらどうなのみたいなのが全く分かんなくてとりあえず動けばいい動いたってやった記憶ある動くしね動くしなーと思ってっていう話を今日しますはいえーっと

っていうのでちょっとさっきいろいろどういう風な行動にするのかみたいなのってプロジェクトによるんですよざっくり言うとねプロジェクトによるっていうのはどうよるのかっていうとデプロイっていうか管理しているリソースの量とかあとはインフラの更新頻度どのぐらいとかあとは環境何個あるかとかっていうのによるかなと思うんですけど今日はちょっといろんな話してもあれなんで一つのシーンに絞りますはい

リソース数はそこそこぐらいまあ分かりづらいですね10個とか10個10、20とか1個のファイルに書くと長いよねみたいなさすがに長いよねぐらいなるほどなるほどかつ環境が3つ環境が3つDevStage Proとはいはいはいこういう状況の時にどういう風にフォルダ分けていくのがいいんだろうねっていう話をしていきたいなと思いますはい

まず真っさらな状態からプロジェクトを始める場合このベストプラクティスのページではまずはシンプルに始めていこうぜっていうのでまず全てのコードを一つにまとめて作ってみようみたいな話をしていますまあでもそれは確かにねとなるほどねやっぱりその

まあいやそんなことね普通にプログラム書くときもまあやるかやるねやるなやるやるまあそのもちろんコントローラーに全部書くとかはないけどサービスぐらいからはちょっと1回書いてみるかもなうんそうそうそうそんなイメージあるわテラフォームも一緒ですねでテラフォームの場合ってまあファイルって4種類あります基本的なやつがはい1つがメインメインこれはあの

想像し得るテラフォーム一般的なやつリソースを書いていくやつコマンド実行したら最初に動くファイルみたいなそうエントリーポイントみたいなまあそうですねエントリーポイントでどこ動いてるんだろすみませんマジで厳密にどこ動いてるかわからない厳密にはわかんないなどこ動いてるのかわかんないですけど

リソースを作るものを定義していくのがメイン2つ目はバリアブルズっていうのがあってこれはメインで使う変数を宣言するやつですなんでバリアブルズの方が早く読み込まれてるんじゃねって今思いました確かにな環境変数みたいな変数って

使おうと思った時にメインじゃ定義できないんですよねバリアブルズで定義しなきゃいけないんでっていうのがバリアブルズの2つ目3つ目がアウトプッツこれは作ったリソースから出力して他のファイルで使い回したいとか時にこれ他で使い回せるように定義するやつ例えばどういうことだセキュリティグループとかそういうことセキュリティグループ作ってえー

EC2に割り当てたいときにセキュリティグループ作るリソースモジュールからアウトプッツでセキュリティグループの何?ARNなのかな?IDなのかな?をアウトプッツで出してEC2側でそれを取得してバリアブルズに突っ込んで

メインで使うみたいなアウトプッツは自分で書くわけではないんですか自分で書きます自分で書くんですか明示的に定義するやつがあります他で使いましたやつをってことは作った結果こういうのが出るはずだからみたいなのを書くってことですかそうですねそれは本当にテラフォームのドキュメントに丁寧に書いてます何をアウトプッツとして使えるかみたいなのが

それに基づいて今回こういうのが作られるはずだからこう書けば後でこれを使い回せるよねってなると最後にバージョンズっていうのはこれはほぼ触らないんですけどテラフォームのプロバイダーのバージョンという要件が書いてるようなバージョンこれで動くよみたいなのが書いてるやつですっていう基本の4ファイルがあるんですけどメインにバーって書いていくことから始めましょうっていうのを言ってますとありがたいやった上で

できたものの複雑さによってホルダー分けをしていくようなイメージですねっていうのを踏まえてノリさんに一旦クイズなんですけど最初に言ったリソース数10,20あるようなプロジェクトで環境が3環境ありますうん

どんなディレクトリ構成にしますかえーわかんねーちょっと情報を出すとするとDevStageプロダクションで環境が分かれてるときってリソースにどんな影響があるでしょうリソースにどんな影響があるかというとだいたい構成は同じなんだけど例えばVPCとかそういうネットワーク区切る系のやつは色々変わってくるプラス変数変わんじゃないかなうん

アウトプッツも変わるなうんいやでもアウトプッツは変わるものと変わらないものがあるのかまあなんか例えばですけどうん

リソース名変わりそうですね例えばEC2の名前とかも多分環境名が入ってるはず入れるべきな気がするんでそこだけ変えたいですよね他とかどうでもいいけど構成は同じにしたいからそのためのコピーファイルは作りたくないけど部分的に変わる部分をどうにかしたいつまりバリアブルにバリエーションが発生するそうそうそうそうでその後のリソースの分割?

今ちなみに1アプリケーション動いてる想定ですか?はい多分ねちょっとこれは意地悪問題とまではいかないんですけど空でやるととんでもなく難しいので今ややモヤモヤを抱えた状態で答えを聞いたらよりインプットの刺激があるだろうぐらいの気持ちで問題出したんでなるほどじゃあここら辺で諦めていいですか?諦めていいですわかりましたギブアップっていう感じで真っさらでやろうとするとどうしたらいいんだってなるんですよ

で今の僕が入ってるプロジェクトは人生で初めてデブステージプロトガルプロジェクトなんでうわこうやって分けんだっていうそうなの?はい本当に僕ポックみたいなプロジェクトしかなかったんで今まで初期事業とかIAC登場以後はIACが流行った時は僕エンジニアしてなかったんでそういうことかちょうど企画してましたずっと

企画しながら一回テラフォーム書いてますけど謎にどういう構成になってるかこれGitHubのリポジトリがあるんですけどまずDevStageプロドこのフォルダがありますあとはモジュールズっていうフォルダがありますモジュールズプロジェクトによってはDevStageプロドの親に演舞ってやって演舞と

インビロイメントとモジュールズっていう2つにしておいてインビロイメントの下にDevStage Proってあるかもしれないですけどそれはどっちでもいいと思います言いたいのは環境ブロックとモジュールブロックで分かれてますなるほどモジュールブロックからいきましょう分かりやすいんでモジュールブロックには何入ってるかっていうと

さっき言ったリソースとリソースモジュールが入ってますAPとPPですねもしくはAPリソースモジュールかリソースモジュールが入ってますなので再利用可能な単位でリソースが定義されてますラムダとかAPやゲートAとかこれはなんでしょうねDevStageEnvホルダーの下にあるやつから環境独自の変数みたいなやつを受け取って

吉田にデプロイし分ける作りになってますじゃあDevStageプロトに何が入っているのかというとインクラストラクチャーモジュールが入ってますPPAPですねインクラストラクチャーモジュールって言ってるんですけど最初にPPAPって言っちゃったせいでややこしくなってるんですけど中身はモジュールに入ってるんですよ

結局中身はそっちに入ってて側が入ってますねデブとか側リソースモジュールを呼び出すやつ参照してる感じだよねそうですねインクラストラクチャーモジュールも結局リソースモジュールを呼び出すための箱なんでそのインクラストラクチャーモジュールデブとかステージとかプロドーとかそっちの方で環境独自の値を

渡してモジュールとその値を元に呼び出すことによって環境によって違うデプロイができるみたいなってことは環境の中だったら例えばプロド用だったらプロド用のインフラストラクチャーモジュールがさっきの1ファイルに書かれてたメインのやつとから今までのメインは具体的なことをバシバシ書いてたけど

そうじゃなくてそれぞれが全部参照になってて下辺の部分だけ残ってるよみたいなそんなイメージですかおっしゃる通り完璧にその通りなるほど命名はちょっと分かんないんですけど僕が今やってるところはきれいにやってると信じて言うんですけどDevStageプロドのフォルダの直下にメインがありますDevのメインでそれぞれ

リソースモジュールを呼び出していますメインはMの下にあってモジュールの下にあるのはあくまでリソースモジュールでそのメインとあとはそのメインに変数渡すための変数設定ファイルみたいなのがあってそんなもんだよなあとバージョンズとアウトプッツもないですかアウトプッツはないというような形の構成に

なってるから環境ごとに分けれると例えばさっき言ったEC2の名前に環境名入れたいよねみたいなのは環境ごとの管理してる変数の中にenvイコールdevって書いてるからそのenvの値をモジュール図に渡して名前変えれるしとかあとはそうですね

デブとプロドってセキュリティグループだからIP制限あるとしたら制限したIP違うはずじゃないですかなんならプロドであるプロドで作るべきセキュリティグループデブでいらないみたいなのもあるかもしれないじゃないですか本社のIPからだけアクセスできるようにしてるよみたいなデブとステージングはみたいななんなら逆の方が適切でしたねデブはIP制限してるけどプロドはしないみたいなそうですねそうですね

そもそもメインからセキュリティグループ呼ばないってこともできるんですよねなのでリソースモジュール単位で呼び出す呼び出さないとかはメインでコントロールできるんでWAF作る作らないとかDEVは絶対WAFいらないんでステージングプロダクションはいると思うんですけどじゃあそのDEVのメインインフラストラクションモジュールで

和風作るところ取っ払っておけば和風作らないみたいな構造になってるのがえーそういう中規模大規模のプロジェクトインフラにおけるまあフォルダのベストプラクティスなるほどねなんかフロントエンドみたいなもんですねと言いますとフロントエンドもなんか見た目のコンポーネントだけバーってあって必要なところから呼び出すみたいな感じになってると思うんですけどそれに近しいものを感じましたまあまあ確かにうん

再利用可能な作りになっているという形ですね言うたらバックエンドもそうかもしれないですけどねバックエンドもそうか結局世の中そうなんだ世の中そう世の中そうなんですよだからこそ結構テラフォームってシンプルだと思ってて他のフロントエンドとかバックエンドに比べてだから設計の勘どころみたいなの感じやすいかなと思って題材にしてみた次第でございますなるほど

ちなみにDevProdステージングで分けるじゃないですか別々にデプロイするときは分別みたいなのはどこでやるんですかテラフォームってテラフォームアプライコマンドでデプロイするんじゃないですかその実行する場所は

一番のトップディレクトリじゃなくてデブ配下ステージ配下プロド配下インブロイメントの下の各環境ホルダーの下でテラフォームをアプライすることによってデプロイ分けられますねなるほどそういうことなのかなので環境のファイルごとにステートを管理しているような形になってますねなるほどそうするとデプロイ分けられるしあとはそうですね

構成変わるとか新しいマイクロサービスアプリケーション足されるからAWSサービス足さなきゃってなった時に3環境同時に構成変えてでデブとかステージで試せたからプロドでも絶対大丈夫っていう確信を持ってデプロイができるとなるほどそういうことかちょっと過去のソースコードと見比べたくなったわ今今ちょっと過去テラフォームを使った時のコードを今見つけてこれはってのがあったんですけどはい

今めっちゃちっちゃいやつだったんでシンプルなんですよまずメインがあってアウトプットがあって変数とか特に使ってないんですけど位置環境だったんでなぜかEC2とVPCっていうファイルがあってそういう分け方でするもんですかっていういわゆるリソースモジュール分けてるそういう意味なのかこれなるほどね多分うんうんうん

ちなみになんかそのベストプラクティスのページに小規模の場合のベストプラクティスみたいなのがあってそこだと何書いてたかな小規模だとあれでしたわもう素でしたメインアウトプッツテラフォームステイッツTFバーズですねステイッツを入るあとはバリアブルズベーシックのやつがポン置きされてるだけでしたねそういうことかはい

分けるんだったらモジュールフォルダにした方がいいかもしれないですねそうだよねでも分けてたんですね僕だったら絶対1個で書いちゃうわ多分普通に聞いたみて受け売りで書いたんじゃないかなと思う大事なことですねなるほどっていうのがテラフォームの分け方ですねもう1個最後に話しておこうかなと思ってるのがどういう流度で

分けようかっていうそのテレフォームの実行単位例えばですよ何で想像したらいいかなAmazonECサイトのAmazonあんななんかバックエンドすごいことになってそうじゃないですかまあそれはそうでしょうフロントエンドもあってモバイルサイトをホスティングしてるやつもいてでまあ多分APIがあってDBも多分一個とかじゃないしうん

っていうものがあった時にあれ1個のリポジトリで管理するんですかっていう話リポジトリ分けんの?でこれ何書いてるかっていうとベストプラクティスで1個1個の単位を小さくしましょうとなぜなら実行が重くなるからだから小さくしましょうねみたいな話をしてて今僕プロジェクトで

とんでもない量のアプリがあるんですけどもちろん1個で管理してなくてアプリケーション単位ではないんですけどアプリケーション単位って言っていいのかな例えばですけど複数フロントエンドとバックエンドが3つ並んでたとしたら3つに分けてますそれはクライアントAPIモバイルアップみたいなそういうイメージですか

例えばですね本当にだから一つのサービス丸っと一個で管理するんじゃなくて一個一個分けた方がいいですねそれでいうとね例えば設定アプライして壊すときも影響が小さくなりますしあとは本当に

アプライする時もですしあとはテラフォームプランって言ってこれこのままデプロイしたらどうなるかなっていうのを確認してから基本はデプロイするんですけどその確認するコマンドもAWSのAPIとかめっちゃ呼ぶんでまあまあかかるんですよねなので多分これはアプリケーションごとに分けるのが適切なんじゃないと個人的には思いますそうするとCIシリーズにもいいことあると思っててアプリケーション更新しましたデプロイしようと思った時に

CICDでパイプラインでデプロイってやった時に全環境に対してプランしてアプライするよりも1アプリケーションに対してプランしてアプライした方がデプロイ軽いんですよね圧倒的に切り戻しも楽だし身動き取りやすいあとは量多くても実際にリソース変更しようと思った時にどこ変更したらいいかよくわからなくなるはずなんで量多すぎるとね

なので一個一個は小さくしつつだから適切にリポジトリを分けてちょっとずつプランアプライするような作りだといいんじゃないかなというのがこのベストプラクティシズに書いてましたなるほどね分ける単位むずいなシンプルなアプリだったら分けなくていいと思います結構大規模でマイクロサービス的なものをイメージしてる感じですか例えばで言うと

監視カメラの動画いやーどうしよっかなスーパーに一時期体温計を置いてたじゃないですか動画のやつあー確かに

もうちょっとはちゃめちゃこと言うんですけど画像認識じゃないけどカメラからのデータで入ってきた人の属性情報と体温を蓄積していってそれを見る管理画面みたいなのがあったとしてでそれって多分大きく2つの要素に分かれると思って分析する方と見る方そういう場合は分析する方と見る方でテラフォームのコードを分けるんでしょうねなるほど

分析する方更新したら見る方変えなくていいはずなんでもちろん機能によりますけどねみたいな感じで多分ね最小限にしていく必要はしていくと良いと思いますただ別にそれ合わせても誰も死なないんでそこはよっぽど最初合わせておいて実行重くねってなったら分けてもいいかもしれないですしそんな大変じゃない気がするな分けるのも

ちなみにモノリシックなアプリケーションでかつこれは意図的とかじゃなくて普通に巨大化してしまったパターンそんなことあり得るんですかねインフラが巨大化することってあるんですかねないかインフラ巨大化しないのか意味わかんないけどEC2インスタンス60台建てるみたいなことですよね例えばとんでもないロードバランシングして例えば機能増えていって

これウェブサーバーだけじゃ無理だってなって例えばSQS使うようになったとかそういう機能ありきでどんどんインフラが増えていって巨大化したパターンみたいなそんなにしないと思います多分SQS増やしたりもなかった結局でもひとまとめですもんね次はメールも必要になったSMS使おうみたいな感じでどんどんサービスが増えていってこれ裏でバッチしたいラムダ使っちゃえってラムダが増えていってみたいな

そのくらいだと一個でやりそうだけどなマイクロサービスちゃんと素結合になってるなら分けていいと思うんですよただ片方更新した瞬間絶対に動かないみたいなそういう密結合的になってるんだったら分けちゃダメですよねなるほどSQS使うとかだったら分けてもいいかも普通に素結合になるからチームに寄る気がしててそのコンポーネントパーツとして

名前を分けてるとかだったら分けてもいいかもと思いますね役割がそんなに違うとか見つけ都合してないとかだったら今僕がやってるプロジェクトもすっごいいっぱいあるんですけど登場人物がもちろん全員繋がってはいるんですけどちょこちょこ分けてて職人芸ですね分ける感どころはそうなんだ普通に考えたら分けるよねはあるかもしれないですけどね職人芸とはいえ

無理に分ける必要はないと思ってますあんまり多くないんだったら100とかいくんだったらね分けるのがいい気がするけどでも100とかもいくんでねシステムやって全然でもその辺とか問題起きたからでいいのかな分けるのは個人的にはそんなに大変じゃないと思いますよその1週間とかでできると思います一人で壊れてるの分かりやすいしね元通りにならなかったら壊れてるからねなるほどね

ちなみにさっきのベストプラクティスの分け方めっちゃ分かりやすいなと思ったんで逆にもう最初から分けてもそんなに弊害ないのかなと思ったんですけど小さいアプリケーションだと1個にまとめるみたいなのあったじゃないですか最初から分けてもいいんじゃないかぐらいの分かりやすさではあったような気がするAWSリソース使ってなおかつ3環境あるんだったら最初からやってもいいかもしれないですね他のクラウドサービスもそうかもしれないですけど例えばそれらでもないやつ監視ツール

監視ツールのリソース作るとか全然分かんないんでそういうのを作る時とかだったら最初1個に書いてもいいかもしれないですねなるほどねテラフォームか分かりやすい話だったと思う信じてます伝わってるといいなと思いながら他にも命名の話とかあるんですが僕先日Xで命名の話ポストしたんですよリソース名さっき言ってた

VPC作るやつあれってテラフォームが指定しているVPC作りますよみたいな宣言とあとそのVPC作ったやつにテラフォームの中で名前を付けるみたいなのがあってその名前について僕ポストしたんですけどこっちが良くてこっちがダメみたいなその○と×逆でしたわ

逆でポストしたまんま逆でポストしたあうんなるほどすごい申し訳ないでもねプレミアムユーザーじゃないからさ編集できないんだよねいやいやあそうなんだコメント連ねたりもしてないコメントはね指摘してくれましたあー本当に優しい人はい絵文字逆じゃねえってすまん

3ぐらいリポストもらってねまじで間違ってるからじゃなくて晒し上げみたいな気持ちはわかんないですけどすまんなと思いながら逆でしたすいませんっていうリプライだけついてますまあいいかと思ってまあいいよ

ぜひちょっと見てくださいこれはすごいサクッと読み上げるのでおすすめですリンクを載せておきますじゃあ終わりますねハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので本日の話に関する感想とか

うちではこうやってるみたいになったら知見になりますのでお願いしますあとはポッドキャストの説明欄からGoogleフォームで番組のお手入れ要望・感想・質問お待ちしてますお気軽にお願いしますあとは各種ポッドキャストブラッドフォームでフォロー・高評価もお待ちしてますのでお願いしますではまた次回あなたが落としたのはこの金のサーバーですかそれとも銀のサーバーですか

いいえ私が落としたのは普通のウェブサーバーですすみませんあなたは正直者ですね全部のサーバーをあげましょう正直者のエンジニアは不可分散ができるようになりましたそれを見ていた欲張りな男がサーバーを落としましたあなたが落としたのは金のサーバーですかへいその金のサーバーを落としましたどうやらあなたは嘘つきのようです

そう言って女神は帰っていきました欲張りな男は復旧できないサーバーの前でワンワン泣いていましたサーバーを落としたくないあなたへひまじんプログラマーの週末エンジニアリングレッスン