Recruit Technologies Open Lab #03 Infrastructure as Code に参加してきた

スピーカーが興味深い方ばかりだったので、参加してきました。

多くの方が Infra as Code の本質はインフラがコード化することで、ソフトウェア領域での知見が適用できるようになって来たと言っていたのが印象的でした。

今まさにterraformやansibleでサーバ構成をコード化しているところなので、負債化しないように意識していきたいですね。

以下勉強会中にとったメモ書き

Infra as code は単なる自動化では無かった。。。!
- Software で使われてるプラクティスをインフラにも適用する
naoyaさんにが思うinfra as code
- infraのモデリング..! (DDD的な)
- 負債を無くす、減らす
- そもそもDockerとかで小さく分割して管理するコード減らす方向性...?

Infra as Code
- インフラもソフトウェアを構成するコンポーネントの一部になる
- コンウェイの法則が働く
pattern 1: インフラとアプリが別組織
- インフラサービスが均質化して個別に対応できなくなってくる
pattern 2: インフラとアプリが同プロダクト所属(仮想チーム的な)
- コミュのオーバーヘッドは減るが、インフラエンジニア個人の資質に依存しがち
- 個別最適化はし易い
pattern 3: インフラとアプリが同組織(サービス)
- 一番変化に強い
- 技術マトリクス的なものを作って、SPOFを減らす
- 他のチームを意識しないので、一貫性がなくなりがち
  - 例) AWSのコンソール
- pattern 3-1: QAとかセキュリティ的なところだけ別部署
  - スピードと安全性のバランスが取れている
ryuzeeさんの本をもらった
Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
- 作者: 荒木靖宏,大谷晋平,小林正人,酒徳知明,高田智己,瀧澤与一,山本教仁,吉羽龍太郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/06/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る

O'reilly の infrastructure as code の4本柱
- Dynamic Infrastructure Platforms
- Infra Definition Tools
- Server Configuration Tools
- Infrastructure Services
Infra as Code に影響を与えそうなもの
- Container
- MicroServices
- Server Configuration Tools は重要性↓
Infrastructure Services
- 設定を外部化するだけではなく内部で調整可能にする
  - 学術的なプローチ
    - グラフ理論、形式手法、ディープラーニング
  - Nginxでluaやmrubyで自律的に動かすとか
- Consumer-Driven Contract testing パターン
  - http://techlife.cookpad.com/entry/2016/01/04/094705
モニタリング is dead
- https://speakerdeck.com/grepory/monitoring-is-dead
- 数字じゃなくて振る舞いをモニタリング(テスト)する的な

メトリックを返すエンドポイントがあるとよろし
監視 as Code
- じつは既に、監視は結構コード化, Plugin化されてる
  - muninとかもそうだった記憶が
- なのでどんどん書いていこう
- webhookには夢がある

Makeはベターshell scriptである 2012
- http://tech.voyagegroup.com/archives/6286346.html
Immutable Infrastructureを実際にやってみた 2014
- https://atnd.org/events/47786 (これ？)
Makeは補完が効く
エラー処理: non-zeroだったら落ちる
宣言的適用と差分
- サーバは状態をもつので、冪等性の維持がむずい
手続き型への回帰: 提言
- サーバの単純化
- コンテナなどで、破棄可能な感じに(状態が無くなってきた)
- サーバレス

かまたま日記3