昨日行ってきました。 内容に単純に興味があったのと、著名な方々が来ていて今まで一回も生でお目にかかったことがないなぁと思ったので参加してみました。 Twitterで見つけてすぐに応募しましたが、すでに200人越えてて補欠枠だったのですが、前日に繰り上がりになって良かったです。
https://atnd.org/events/78581 動画 が上がっています。僕も週末見てみます。
"Infrastructure as Code" から数年、結果どうなったか
伊藤 直也 (一休.com CTO)
https://speakerdeck.com/naoya/infrastructure-as-code
Infrastructure as Code が世の中に出てきて
元はCFEngineが1993年に出てきてからPuppet, Chef, Ansibleが出てきた 2011年にAWS東京リージョンが来た。 2013年「入門Chef Solo」が出版された。
クラウドになってきてから Infrastructure as Code が広まっていった。
当時に期待値は秘伝のタレをソース化 => コードにしてみたらGitでバージョン管理、GitHubでPRなどインフラもコードを書く => テスト(Serverspec)、CIもできる => GitHubでマージボタンを押せば自動的に適用される
本当の目的は自動化やコード化を達成したいからではなかった。 Configuration as Code
サーバ以外にも応用できないか？
- Route53の設定を宣言的に定義&適用する
- DNS設定をGitHubで管理、masterにマージするとDNSが反映される => 変更反映をGitHubのマージボタンに集約される => 権限管理が課題
ビルドの再現可能性が重要
- 何回やっても同じ結果(冪等性) => Configuration as Code
- Terraform
- Docker Compose
ソフトウェア開発のプラクティスをインフラにも適用する。
インフラストラクチャをモデリング
- モデリングすることで複雑性を取り払い本質を捉える
- 業務をそのままシステムに落とすのではなく、モデリングすることで業務に活かすことができる(DDD)
自動化やCI/CDをやる前にモデリングをやるべきなのではないか
Ansible vs Chef
- どちらがより、現システムのモデリング要求基準に適しているか => これは他のツールにも言えるのではないか
モデリングは今後広まっていくか
- 今のところ期待値はあまり高くなさそう
[感想] Chefを導入するときに「入門Chef Solo」には大変になった。その頃から Infrastructure as Code という単語をよく耳にするようになって本当の目的を見ていたわけでもなく、ただサーバ構築を自動化したい、(当時最先端だった)Chefを使ってみたいという欲求でしかなった。 話していた内容で印象的にだったのが「Cookbookとか作ったとしても数年後にそれが技術的負債になるかもしれない」で、確かに構築するサーバはどんどん増えていくし、変更箇所も増えていったり変わっていったりあっという間にソフトウェア以上に負債を抱え込んでしまう可能性があって、自動化がゴールにするのではなくてその先(モデリング)にまで目を向けて考えなければならないなと思った。DDDは挫折したから再挑戦しようかな。
Infrastructure as Code と企業文化
吉羽 龍太郎 (ryuzee.com) http://slide.meguro.ryuzee.com/slides/75よくある文化的な問題
- ソフトウェア開発のベストプラクティスが導入できない
Infrastructure as Code
- サーバ内だけにとどまらず、サービスを動かすインフラ全体が対象になる
- DNS, Network etc
- インフラとアプリとの境界がなくなっていく
コンウェイの法則
- 企業文化・体質がシステム・ソフトウェアに体現される法則
- 逆に言えばシステム・ソフトウェアの品質を上げたい場合は組織構造を変える必要がある
組織構造
(1)インフラ部(部署・サービス部門と、インフラ部)
- 全社横断型インフラ部
- インフラ部がボトルネックになる。インフラ部で定めたSLAになってしまう
- 均質化がすすむのでアプリ側の要件を満たせない
- Cookbookなどを作って標準化を図ろうとしても部署ごとに要件が異なるので結局破綻する
責任分界点問題
- AWSなどクラウド上だとインフラとアプリ側の境界が難しくなる
- 例) Auto Scalingの設定、AMI作成はどっち側なのか
- 急な変更が必要なときにどうするのか
境界は曖昧。つなぎ方がアーキテクチャ
(2)部門ごとにインフラチームがいる
- インフラが複数プロジェクトを兼任したばあい、インフラチームではなく個人に負荷が偏ってしまう
- インフラ部門での情報やベストプラクティスの共有が必要になる
- 変化に対応し続けられる
(3)製品単位でチームを作り、その中にインフラエンジニアを含める
- サービスをゴールにできるので集中しやすい
- 一番変化に強くなる
- インフラ専任とは限らない。アプリ開発者のなかでインフラもできるエンジニアが担当することもある
- スキルをまとめたマトリックスを利用する
- 他の製品チームを意識しない => 全製品をまたいだ一貫性は担保されない
- 認証・セキュリティ等の要求基準を合わせるコントロールが必要
(3-1) (3)に加え、チームを跨いだセキュリティ/標準化チームを設ける
- セキュリティ設定済のイメージ、Terraformスクリプト、各種ガイドラインなど標準化がすすむ
- チームの自立性+外部からの最低限守るべきルールの提供
- Amazon, Netflixなどがこの形をとっている
責任範囲マトリクス
- 各レイヤー、タスクについてアプリエンジニア、インフラエンジニアなどどこに責任があるのかを見える化する
文化面でのチャレンジ
- やりたいことに沿った組織構造が必要
- 上の人に言う覚悟
- いきなりやろうとすると抵抗を受ける
- 最初は小さくやって事例をつくる
- 最初に失敗すると二回目以降やるのが難しくなる
- 人間系が泥臭い
[感想] 組織構造がソフトウェアの品質に現れるコンウェイの法則は初めて知った。インフラだけをやる人はよりよいソフトウェアを作る上で要らない存在になっていくようで危機感を抱く。
Infrastructure as Code のこれまでとこれから
宮下 剛輔 (Recruit Technologies ATL 技術顧問) 合同会社Serverspec Operations代表 https://speakerdeck.com/mizzy/infrastructure-as-codeInfrastructure as Code の三本柱
- 自動化
- バージョン管理
- テスト
最近の Infrastructure as Code 事情
オライリー「Infrastructure as Code」Dynamic Infrastructure Platforms
- IaaS etc
Infrastructure Definition Tools
- Terraform, CloudFormation etc
Server Configuration Tools
- Chef, Puppet, Ansible etc
Infrastructure Services
- オーケストレーション部分
- モニタリング etc
Infrastructure as Code のこれから
- 対象領域が広がり、より複雑化していく
- 出来る限りシンプルに実現していく必要がある
- 学術系的アプローチ
- テスト分野はまだ未成熟(改善の余地が十分ある)
- モニタリングとの融合
- 本番デプロイ後
Dynamic Infrastructure Platforms
- マルチクラウド対応、ベンダーロックイン回避
Container
- Infrastructure Definition Tools, Infrastructure Services の重要性が増大
- Server Configuration Tools の重要性が低下
- Serverspec でテストすれば良い
- サーバ管理というよりプロセス管理
Microservices
Infrastructure Services
- Infrastructure as Code の恩恵が不十分
- 動的な振舞いを記述する
- Server Configuration Tools は静的な状態を記述していた
- 自律制御も重要になってくる
- 動的平衡
- ソフトウェア開発との境界が薄くなってきている(曖昧になってきている)
- あまり縁がなかった手法の応用
- 形式手法の設計
- Consumer-Driven Contract Testing
- あまり縁がなかった手法の応用
運用・監視もコード化する。開発者が監視まで考える方法論
松木 雅幸(id:Songmu) (株式会社はてな) http://songmu.github.io/slides/recruit-technologies-open-lab-3/#0モニタリングの重要性向上
何を監視すれば良いのかを考える
- メトリックを取得可能にする
- 監視ための内部的APIを作る
コード化する
- 監視プラグインは単なるコマンド実行
- チェック監視
- OK/NG
- メトリック監視
- 数値データを可視化
- mackerel-plugin-gostat
- Go製監視プラグイン
監視設計
- 何を監視するかを考える
- 監視できるようにする
閾値設定をコード化する
アラートに対するアクション
- Mackerel のアラート通知はWebhookで受け取ることができる
- fluent-plugin-webhook-mackerel
- fluentdでwebhookを受け取れる
サーバ管理
- Mackerel は当初サーバ管理的な思想が強かった
- はてなではアプリケーションサーバ一覧をMackerelから取り出してデプロイしている
[感想] 前半は監視全般、後半はmackerelのお話。MackerelでMacの熱の温度をモニタリングをしているのは少し面白かった。これから社内でmackerelを導入していくけど、ただモニタリング・監視するだけではなくてもっと色々なことができそう。
プロビジョニングツールはMakeで決まりだろ
大谷 和紀 (VOYAGE GROUP) https://speakerdeck.com/katzchang/purobiziyoninguturuhamakedejue-maridaro- 途中で失敗(0以外を返す)とmakeが失敗する(安全に倒す)
プロビジョニングツール
- 冪等性なんてなかった
- パッケージインストール適用後、記述を消すとその前に適用したパッケージが残ったままになる
- 宣言的記述なんてできるのか
- 冪等性なんてなかった
- 昔は共有サーバ(複雑なサーバ)をどう管理するか
- 今は単機能なサーバをどう組み合わせるか
- クラウド/コンテナ => 破棄可能なインフラ
- 状態管理からの脱出
- サーバレスアーキテクチャになってきた
- cli, shell scriptとの親和性が良い
[感想] Makefileを作ったことが無い自分にとって別次元な話だった。
