Terraform meetup tokyo#2 参加レポート兼感想のようなもの #terraformjp
だいぶ遅くなりましたが10/2に行われたTerraform meetup tokyo#2に参加してきたので、その参加レポートです。
当日はTwitterが不調で、実況がままならない時間帯もありましたが面白かったです。当日の様子がトゥギャられてるので、こちらもどうぞ。
個々のアプリのリポジトリでTerraformを管理している話
アプリケーションごとにTerraformのコードを分散管理するお話でした。
- 普通？のTerraform管理方法
- Speee（Uzou）さんでのTerraform管理
- アプリケーションコードと一緒に管理している
- 歴史的にフルスタックエンジニアが多い
- 今の組織状態であればメリットが大きい
- 影響範囲のわかりやすさや、Planの早さは嬉しいポイント
- 一方で、書き方にムラが出るなどの課題もある
所感
アプリケーションも書けてTerraformも書けるエンジニアはどちらかというとレアキャラですが、開発スピードを最高速度に保つためには必須だと思うので、この方針で運用できているのは素晴らしいです。筆者の所属企業では事実上、SREチームがいじっている状態なので素直に憧れます。一方でセキュリティやガバナンスは全体としてクオリティの担保が必要なので、どのように運用しているのか気になりました。
APIがある外部サービスはTerraformで管理できますよ
Providerの存在しないサービスをTerraform管理するお話でした。
- Terraformで管理できるのはAWSやGCPなどのパブリッククラウドだけじゃない
- Datadogとかfastlyなどの有名なSaaSもProviderが存在
- Providerがないなら自分で作ってみましょう
- わりとやるべきことがシンプルなのでチャレンジしよう
所感
自分でもできそう！という気持ちになれるため、はてブでもかなり話題になっていました。Terraform Provider実装 入門が参考になったとのことで、気になる人はこちらを読むと良さそうです。そもそも筆者を含めて、Providerを自作しようと考える人のほうが少ないと思うので、そういった人たちに選択肢を広げる意味はとても大きいと思いました。
発表者が自作されたProviderは下記のようです。
Terraformerのおはなし
Terraformerに機能追加するのは実は簡単ですというお話でした。
- Terraformerのアーキテクチャはざっくり三段階
- 「前処理」「Providerとの通信」「取得結果のParse」
- 機能追加は「前処理」の部分だけ追加すればOK
所感
直前のProvider同様、自分でもできそう！という気持ちになれる発表でした。発表者のプルリクエストを見ると、依存の追加で一見変更ファイルが多いですが、実装部分は本当にシンプルです。
余談ですがTerraformerは最近、Terraform 0.12に対応するプルリクエストがマージされています。対応リソースもモリモリ増えています。GCPのリポジトリで一見難易度が高そうに見えますが、驚くほどサクッとマージされるので、結構オススメのプロジェクトだったりします。
FOLIOのterraform運用tips
FOLIOさんで実践しているさまざまな運用Tipsのお話でした。
- 運用するうえで大事なのは、後から入社した人でも分かるようにすること
- できる限りコメントを書いて、安心感を与える
- Terraformは様々なコンポーネントを細かくコミットするため全体像が見えづらい
- ステージングでまず動かすことを意識して、全体設計レビューはステージング完成後に注力
所感
FOLIOさんではいかに安心して運用できるかを強く意識しているようで感動しました。Terraformに限らず、ただ動くコードを書くのはそれほど難易度が高くないですが、変更可能な状態を維持するのは大変です。特に実装者以外が理解できるようにするにはホスピタリティが必要で、おざなりにされることも多いですが丁寧にケアされているようで、改めてきちんとやらねばという気にさせられました。
Terraform Workspace機能を活用してきたノウハウを一挙公開
Terraform界隈では事例共有が異様に少ないWorkspaceのお話でした。
- TerraformはThe Twelve-Factor Appとの親和性が高い
- 特に「開発と本番が一致する」はWorkspaceで実現できる
- countを利用してリソースが不要な環境では立ち上げない工夫
- ツライこと
- 情報量が少なかったり、やめましたみたいな記事で悲しくなったり
- でもそんなにツラかったことなかった
所感
Meilyさんでは創業当初からインフラのコード化を徹底されていたとのことで、Workspaceとの親和性が高いカルチャーだという印象を受けました。何年もTerraformを運用してコードベースが大きくなったあとで、切り替えるのはかなり心理的負荷が高く、実戦投入できてない会社も多いと思うので、こうやって知見が共有されるのは素直に嬉しいです。
ちなみに運営による事前アンケートではWorkspace利用者が3割いる（ホントに！？）ということで、着実に利用者は増えているようです。そろそろ巨大なコードベースをWorkspaceに移行した事例とか聞いてみたいですねｗ
TerraformとAzure Pipelinesを用いたプロビジョニングの自動化
数少ないAzureにTerraformを導入したお話でした。
- Azure PipelinesとTerraformを組み合わた場合の情報が希少すぎる
- フィードバックほしい
- いくつか完全なプロビジョニング自動化を諦めた
- SQL Serverのセキュリティ構成やEvent Hubsのイベントサブスクリプションの構成
所感
筆者は普段AWSしか触っておらず、キーワードも初見で推測するしかなかったですが、Azureでも基本的なことは一通りTerraformで作れそうな印象です。一部Terraform化を断念したところもあるようですが、今後事例が増えてくれば解決に向かいそうです。ちなみに運営による事前アンケートではAzureユーザは、参加者の10%ほどだそうです。Azureのシェアを考えるともう少し高くても良さそうですが、AzureユーザはTerraform以外のソリューションを採用してるのでしょうか。
terraform-provider-aws のコントリビュータになろう
Terraformユーザでもっとも利用者数が多いと思われる、terraform-provider-awsにコントリビュートするお話でした。
- コードを書かないコントリビュートもある
- ドキュメント修正やIssueをたてるだけでも立派なコントリビュート
- 難易度が高いのはコントリビュートする題材を見つけること
- refactorやtechnical-debtで検索しよう
- 難しいと感じたらSource Code Readingに参加しよう！
所感
OSSへのコントリビュートはなんとなく敷居の高さを感じてしまうものですが、小さく始める方法が凝縮されていました。Issueをたてるだけでもコントリビュートになる、というメッセージは意義深いものがあります。ある意味、こういう勉強で発表することやブログで記事を書くこともコントリビュートの一種でしょう。また題材探しの方法は、意外と形式知化されていないので面白いですね。
宣伝『実践Terraform』
懇親会LTの最後に、拙著『実践Terraform』の宣伝もさせていただきました。
実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)
- 作者: 野村友規
- 出版社/メーカー: インプレスR&D
- 発売日: 2019/09/20
- メディア: Kindle版
- この商品を含むブログを見る
同人誌「Pragmatic Terraform on AWS」をベースに100ページ近く新規に書き下ろしているので、よかったらどうぞ。同人誌と違って電子でも紙でもAmazonで買えるので、読書スタイルにあわせて選択いただけます！
World Cafe
Terraform meetupではWorld Cafeという、数人のグループを作って参加者同士でディスカッションする企画が実施されています。どのような議論がされたのか全貌を知るすべはないですが、筆者が参加したグループで話した内容を中心に軽くシェアします。なお、事前に行われたアンケート結果の共有も行われたので、あわせてスライドを貼っておきます。
- リポジトリの単位はどうしてる？
- みんなadmin権限でやってる？
- パスワードなどのシークレット管理どうしてる？
- 複数人開発で気をつけることは？
- グループでアンケートを取ったらお一人様運用が6人中4人（意外と一人で運用してる人多い）
- モジュールは人によって設計思想が大きく変わるのできちんと認識を揃える（デフォルト値とか）
- applyは気をつけないといけない
- モジュールのリファクタリングがツライんですが、いい方法ないですか？
- ない
- ひたすらmoveで頑張る
- VPCピアリングどっちから貼る？
- いつもどちらを主にするか迷う
- ライフサイクルが長いヤツを主にする
- 別に他の判断軸でも良いが、雰囲気でやらずに明確にしたほうがいい
- 別tfstateファイルの参照どうする？
- 多くのケースではリモートステートかデータソースになる
- データソースならplan時にエラー検出できるから、変更に強い（気がする）
- もちろん一長一短はあるので、使い分けよう
他のグループでは下記のような話題も出た模様です。
- 中国AWS環境、機能制限があったりSSH接続が遅かったりでツライ話
- AWSアカウント単位にリポジトリ作ってtfファイルを管理しているときに、アカウントを跨いで共通なリソース（sg）の定義を管理する時に楽な方法は？
- すでに複数台のサーバが動いてる環境で導入するにはどうしたらいい？
- 運用はどのようにして回してる？(大枠だけ作って後は手作業してる人から)
World Cafeは聞きたいことを持っていったほうが絶対に得なので、次回参加予定の人はぜひ議論テーマを持っていきましょうｗ
感想的なよもやま話
LTについては概ね二種類の話題となっていました。Terraformのエコシステム（プロバイダや周辺ツール）の話と、運用にまつわる話です。エコシステム周りでは、Terraformのプラグイン機構の強力さを実感できる内容になっていました。また各発表者に共通していたのは、チャレンジしてみよう！という聞き手を後押しする姿勢です。あまり日本語では情報がありませんが、出発点として必要な情報がかなり網羅されていたように感じます。もう少し掘り下げて形式知化すれば本にできるので、発表者の皆さんあぜひ検討してみてくださいｗ
個人的にもっとも注目していたのは運用にまつわる話です。運用はコンテキスト依存が強く汎用化しづらいですが、それぞれの事情に即した知恵が凝縮されておりとても面白いです。特にSpeeeさんとFOLIOさんの事例は興味深いです。
コードの統一管理と組織戦略
Speeeさんのアプリケーションコードとインフラのコードを同じリポジトリで管理するというアイデア自体は、わりとよく聞く方法論でInfrastructure as Codeの9章1にも登場します。この本では、アプリケーションコードとインフラコードを分離するのはよくないものとしています。技術的にも組織的にも余計なオーバーヘッドがかかるためです。特にアプリケーションとインフラのオーナーがふたつのチームに分割されている場合、調整するための時間と作業が必要になってしまうと指摘しています。
これはとても理にかなっている考え方で、筆者も理想的な姿だと思いますが、意外と実践できている組織は少ないです。なぜなら、アプリケーションとインフラは必要とされるスキルセットが大きく異なるためです。世の中的にはTerraformなどでインフラ構築ができて、アプリケーションコードも書ける人は少ないです。アプリケーションもインフラもただ動かすだけであればハードルは大幅に下がっていますが、本番運用に耐えられるクオリティにするにはまだまだ一定以上の専門性が必要で、一朝一夕で身につくスキルとはいえません。またアプリケーションエンジニアに比べると、インフラの専門知識を持っているエンジニアの絶対数が少ないことも問題になります。高い専門性が必要なうえに数が少ないため、多くの組織ではインフラを専門的にみるチームが作られることになります。（各チームに配置する余裕はない！
この状況を打破しようとすると、フルスタックなエンジニアを採用するなり育成するなりしないといけません。Speeeさんの発表では歴史的経緯の一言で片付けられていましたが、戦略的にやっていたとしたら相当スゴいことをやってのけています。個人的にはTerraformの管理単位をどうするかよりも、どういうスキルセットを備えたエンジニアを採用して組織を作ってきたかのプロセスのほうが気になります。このあたり一度詳しく聞いてみたいトコロです。
運用するということ
FOLIOさんの「運用するということ」のスライドはたった一枚ですが、とても感銘を受けました。実はTerraformのコードの保守性を維持する、というのは難しいテーマです。現在どのように設定されているかはコードを読めば分かりますが、設定した意図はコードだけでは分かりません。意図を残すためには、プルリクエストやIssueで設計の過程を残す・コミットメッセージに書く・Qiita:Teamやコンフルなどのドキュメンテーションシステムにまとめるなどの方法があります。しかし、一番読まれる可能性が高いのはコードのコメントです。そのコメントを適切に書くというのは、運用するうえではとても大切です。
ところがTerraformのようなDSLやミドルウェアの設定ファイルでは、アプリケーションコード以上にコメントが軽視されます。適切にコメントがないコードは認知的負荷が高いです。「A Philosophy of Software Design2」ではソフトウェアの複雑性の原因を3つ挙げていますが、そのうちのひとつが認知的負荷です。「なぜこの設定にしているのだろう？」「なぜこのオプションが有効になっているのだろう？」と読んだ人に思われたなら、そのコードは認知的負荷が高い状態です。認知的負荷が高いコードは安心感とは真逆の気持ちをエンジニアに与えます。
コメントは安心感を与えるための手段のひとつでしかありませんが、その重要性を認識し、あとから携わる人のことを考えてしっかりレビューしているというのは本当に素晴らしい取り組みです。こういう取り組みは、短期的に役に立つことが少ないためなかなか評価されませんが、個人的にはこういうスタンスの人と一緒に働きたいと思っています。
あとがき
ドラクエ11Sで勇者として世界を救うのに忙しかったうえに、書いてるうちにどんどん書きたいことが増えてきて収拾がつかなくなってきてリアルにお蔵入りしかけましたが、なんとかアウトプットできてよかったです。実際お蔵入りした内容もあるんですが、それはまた別の機会ということで。
あと『実践Terraform』を何卒よろしくおねがいします（唐突
実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)
- 作者: 野村友規
- 出版社/メーカー: インプレスR&D
- 発売日: 2019/09/20
- メディア: Kindle版
- この商品を含むブログを見る
ちなみに他の参加者のレポートも存在するので、あわせてそちらもご覧ください。