Terraformjp #04 行ってきた

Terraform meetup tokyo#4 - connpass に参加させて頂きました。

「ワールドカフェ」という形式

ツールやプラットホームに対する習熟度や抱えている課題ががいい具合にバラついて、いい具合に揃っていたことが大きかったと思います。

自分が抱えていた課題感としては「CI/CDみんなはどうしてんだろう」「ステート単位どうしよう」という点でした

ざっくり感想を言うと、

• ワールドカフェ形式おもしろい
  • 抱えている課題や規模感などがいい感じにバラついて、いい感じに似たような境遇の人と話せた
  • うまく回るかどうかは形式自体よりもファシリテーションや参加者同士の相性もありそうで運営は難しそう?
    • 今回は全体の人数が少なく、最終ラウンドでは一度話した方と再度同じグループになったりしましたがその分深い話ができた
• 自分が「この方法が筋良さそう」と思っている範囲は思いの外狭かった、もっとAlternativeを知るべきだった
  • ある設計の選択を「しなかった」ことの説明ができるまで考え抜けると強そう
• 「今の自分の組織の状態」「次に目指したい状態」「将来的に目指したい状態」の順番で考えなければいけないなぁというのは、SRENextに参加させてもらったときと本質的に同じ(当たり前かも)
• Terraformソースコードリーディング会に参加してなかったことに非常に損した気分、次がもしあれば絶対行きたい

CI/CDみんなはどうしてんだろう

これには二つの観点があって、(1) 何を記録として残したいか (2) 実際にインフラを触る人が何人いるか によって色々な意見を聞くことができました。

自分が考えるときに最初に参考にさせて頂いたのはこちらです。

インフラCICDの勘所 from Toru Makabe

www.slideshare.net

(1) 何を記録として残したいか

Infrastructure as Codeの動機の一つは構成管理の記録を残すことだと思います。

その動機に対して、操作する人が自分だけまたは十分に少ないのであれば手元でapplyしても良いのではとも思いましたが、それだけでは「いつ、誰が、何の変更を適用したか」という操作記録は抜け落ちてしまいます。

terraformであろうとCloudFormationであろうと、(CI/CDに限らず)統一されたワークフローがなければ「コード上はこうなってるけどこれいつ反映されたの(あるいはまだされてないの？」という不確かさが残ってしまいます。

CloudTrailなどで頑張って追いかけることも不可能ではないと思いますが、「せっかくGit管理されていてアプリケーションのCI/CDで使っているツールあるのだからそれに乗っかってしまえばよい」と。

(2) 実際にインフラに触る人が何人いるか

これは、「今インフラに触るのは何人？」という問いと「今後インフラに触る人を何人にしたい？」という問いに分解できそうです。

今回お話させて頂いた参加者さんの中にも「立ち上げ期の数人のチームで自分がまるっと面倒みるし、ワークフロー構築よりもポチポチつくったほうが早い」というケースと「少人数だからこそ最初からインフラも含めたCI/CDをカッチリ作り込んでいる」というケースの両方がありました。

そこから思ったこと

人数が少ない(究極は一人の)場合だと、ブランチが増えたりHEAD≠現在の状態になることも少ないし、正直CI/CDカッチリしなくてもSlackで「今からXXスケールアップしまーす」で済んじゃうこともあるかと思います。

でも触れる人数が増えればいつかは限界がくるし、アプリケーションでは当然のようにやってるなら、シンプルかつ確実に解決する方法としてインフラでもより広めていっても良さそうかも、と考えました。

「自分で作るアプリケーションは自分で動かす」状態を維持したまま、デプロイのスピードを上げるにはどうすれば良いか、今後新たなメンバーを迎えたり、既存メンバーでも担当領域を変えた場合にも「どうすれば最速でデプロイを回せるか」は自分でやっていかないと...

ステート単位どうしよう

モジュールやコンポーネントの単位についても色々な意見を聞けて収穫が多かったです。

ライフサイクルの長さ(Mutable v. Immutable、Dynamic v. Static)は重要というのはある程度皆共通認識で、それらをどうリンクしていくかという話。

「remote stateよりもdata resourceを使うケースがある」というのは自分が参加するまで持っていなかった視点で、自分はremote stateはどんどん使うものだと思っていたのですが、「state間で依存関係を持ってしまうのが気持ち悪い」という考え方もあることを知りました。さらにすすめて、module化もせずにフラットなresourceに書いていく流派もあると聞きました。

せっかくterraform管理下にあるのにremote stateではなくdata sourcesなどを通じて参照するのは「インターフェイスで明示的に宣言されていない属性やメソッドにアクセスする」ような忌避感を自分は持っていました。しかし、「依存先で想定外の変更があった場合、依存元がコケるので気付ける。DynamicなリソースたちとStaticなリソースたちを上手くコンポーネント切り分けておけばいい」という考え方を聞いて納得しました。

「こうするのがよい」「かくあるべき」っていう一つの考えに凝り固まりがちなので気をつけないとなぁと思うなど。

まとめ

• 上手く回れば参加者の課題や規模などが近いと直接活かしやすい知見を共有できるし、異なる場合は違った確度からの話が聞けて良い
  • 逆に参加者同士がいい感じに協調しないと不発になっちゃうかもしれない、そこは参加者の責任かなぁと
  • 全員が等しく話すチャンスがあることも大事だけど、ある種共犯関係というか、雰囲気で合意があれば「そこもっと詳しく！」が続いてしまうのはアリかも？
    • 初回ラウンドで一人目の自己紹介からすぐに本題に入って話が盛り上がってしまった
    • 結果的に話が深堀りできて面白かったんだけどワールドカフェのガイドラインには則れなかった感
• 強制的にグループ作って話し始めるのはコミュ障にはありがたい
• 次は是非ソースコードリーディング会のブログを書きたいなっ