参加できなかった Recruit Technologies Open Lab #03 の動画が YouTube に上がっていたのでさっそく見てみた．発表者のラインナップが豪華だし，刺激的な話が聞けたし，オススメ！こうやって配信してもらえると，参加できなかった勉強会をキャッチアップできるし，繰り返し見ることもできるし，良いなと感じた．ライブ配信だからだと思うけど，ゾロゾロと参加者が集まって席が埋まっていくところまで録画されてて超シュールだったwww 数人知ってる人も映ってた！
Infrastructure as Code / @naoya_ito
- アプリケーション開発で培ってきたプラクティスをインフラ構築/運用に適用するプロセス
- GitHub - codenize-tools/roadworker: Roadworker is a tool to manage Route53. It defines the state of Route53 using DSL, and updates Route53 according to DSL.
- 本質を見失うな
- 複雑になってしまったシステムをモデリングしてシンプルにすることで本質が見えてくるのでは
"課題の本質を考えるべき" という話は凄く考えさせられた．僕も Chef vs Ansible という例題に関しては同感で，ミドルウェアの選択も，言語の選択も，表面上の議論だけなら意味はなく，実践したいことを突き詰めた結果から意思決定をするべきと考えている．何となく浅い議論で良し悪しを言う傾向の人って，自分では試したことはなくて，流れてきた情報をザッと見て偏見を持ってしまっていることもあるよなーと思うことがあって，だからこそ本質を考えるためには日々学ぶ必要があるのではないかなーなんて．まぁ言うは易し行うは難しで，常にそういう意思決定ができるわけじゃないし，組織として技術顧問を向かい入れることの価値としては，正しく本質を見極めるためと言えるのではないか．
Infrastructure as Code と企業文化 / @ryuzee
- 組織構造を分類すると
- 組織構造 1 - 開発部門とインフラ部門が独立している
- 組織構造 2 - 開発部門とインフラ部門が独立している（ただしプロダクトごとに縦割りにする）
- 組織構造 3 - プロダクトごとにインフラエンジニアを含める（アプリケーション兼任もある）
- 組織構造 3 の良し悪し
- プロダクトのミッションが明確になる
- チームの自律性を尊重できる
- 全体的な統一感は失われる可能性がある
- 組織文化を変える必要がある
- 技術力より人間力が問われる
僕は今までに組織構造 1/2/3 全てを経験していて，さらに 1/2/3 の順番で経験していることもあって，自分が所属してきた組織のことを考えながら話を聞くことができた．比較表にあった通り，一概に良し悪しは言えないと思ってて，ビジネスモデルだったり，組織構造だったりに依存する．ただ前職の SI で大規模案件（組織構造 1）を担当してたときのコミュニケーションコストは本当に高くて，インフラ部門と飲みに行って話したら，そこで大枠のビジョンを共有できたという経験もあったから改善の余地があると思う．ドキュメントが不要とまでは言わないけど，過剰と感じられるなら不要だという感じ．
全体的に表現の難しいと思われる話をここまで完璧に言語化されていたという点が素晴らしかった．組織文化を変えるには根気強く取り組む必要があるのはその通りなんだけど，同時に "誰が言うか" が特に重要だと個人的には思っている．やはり過去に実績を出した人だったり，成功した事例を持っている人が言うと，シンプルに納得感があって組織文化が変わっていく速度が上がるのではないかなと．
Infrastructure as Code のこれまでとこれから / @gosukenator
- Infrastructure as Code 本
- 学術的アプローチも事例が出てきている
- 形式手法 (Alloy) / グラフ理論 / DeepLearning
- CPU 使用率などのメトリクスを監視するだけではなくサービスの "振る舞い" を監視する考え方もある
- インフラ系 Podcast : cloudinfra-audio
Serverspec の恩恵は計り知れないなと思う．実際に担当してるプロダクトでは Chef + Serverspec の組み合わせでテストをしていて，状態をテストできることの良さを実感している．メンテナンスしてる人じゃないと Cookbook を読むのが難しいという話もありそうだけど，基本的には Serverspec のテストコードを読めば，ロールごとに満たすべき構成が把握できるから，それで十分かなと．
"Infrastructure Definition Tools" と呼ばれている領域に関しては現在まだ手動で運用していて，自動化を検討しているところ．確かに今までだとその辺りを "Orchestration" と呼んでいたと思う．Infrastructure as Code 本のことを知らなくて，今の積読が落ち着いたら読みたいなと思う．
Infrastructure as Code: Managing Servers in the Cloud
- 作者: Kief Morris
- 出版社/メーカー: O'Reilly Media
- 発売日: 2016/06/27
- メディア: ペーパーバック
- この商品を含むブログを見る
運用・監視もコード化する。開発者が監視まで考える方法論 / @songmu
- 1ロールで2554台も稼働してる例がある（グラフヤバイ！w）
- 監視に対する抵抗感
- 難しそう
- 適当にやってる
- 監視とは高速な健康診断である
- 体重などのように意味のわかるメトリクスを監視する
- メトリクスがあり過ぎると途端に難しくなる
- 監視に対する敷居を下げる
- Mackerel の監視設定をコード化
直近の数ヶ月で，今まであまり活用できてなく，アラートも無視し続けていた Zabbix の健全化というタスクがあって，監視の本質を考えながら作業をしていたから，凄く刺さる発表だった．健全化はできていて，メトリクスを可視化したことで発見できた問題も多くあるし，パフォーマンスに関する議論やリファクタリングの効果検証などにも使うようになっているので，監視という継続的な概念が開発プロセスに乗るようにはなっている．
ただ "敷居を下げる" というところは全然できてないなと思った．権威的になってる気はないけど，もっとアプリケーション側のメンバーにも気軽にグラフを見てもらいたいし，活用してもらえれば嬉しい．監視に対する僕のスタンスを社内勉強会で話そうと決めた．
プロビジョニングツールは Make で決まりだろ / @katzchang
- Make as a better shell script
- 冪等性なんて無かった
比較的真面目な雰囲気の中，突然の LT でタイトルもアレで最高だった！
"冪等性なんて無かった" の話は実際に悩んでいたところで，最近 Chef をメンテナンスしている関係で，不要なレシピを削除しまくっているんだけど，新規にプロビジョニングする場合は良くて，既存のホストには残ってしまうという問題がある．現状どうしているかと言うと，対象サーバを洗い出して，手動で削除を適用して，同じ状態になるようにしている．ただ全然 Immutable じゃないし，冪等じゃないし，だからと言って Chef に削除用のレシピを書くのも過剰だし，という感じ．ポンポンとインスタンスを立ち上げて，既存を捨てられるアーキテクチャになってるなら良いんだけど，そうもなってなく．
関連記事
今まで書いてきた記事と重なる話も多かった気がした．引き続きバーンとやっていこ！
