2016.07.22 - Infrastructure as Code Casual 札幌 2016夏

2. Masashi Terui @ marcy_terui
I’m a Developer and Cloud Architect.
I’m a full-time employee at JIG-SAW Inc. But, I’m a part-time freelancer.
I’m a member of GCPUG and JAWS-UG and MyNA←New!!
I’m around 30 years old. I’m a father of my son and daughter.
https://willy.works/
2

3. 3

4. 4

5. IaC is 何
5
これを見てから (Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code)
→ https://www.youtube.com/watch?v=RFTdM8SUmf4
これを聞けばおｋ (のぼりーさんのクラウドインフラPodcast Track 5、ついでにTrack2←俺回)
→ https://cloudinfra.audio/track005-f5122e3d98df#.6oin2si36

6. 6

7. IaCで
得たもの
7
最初の欲求は自動化だったがそれに留まらない
アプリケーション開発のプラクティスをインフラに持ち込む
コードレビュー
テスト駆動
CI
Reproducible Build(再現可能なビルド)
インフラのモデリング（ここまで議論が発展しない。。。）

8. 明らかに
なった課題
8
理解度や成熟度が人によってマチマチで議論が成熟しない傾向
技術面よりも組織面の課題が浮き彫りになるケースが多い
コンウェイの法則
まず、開発でCIとかのプラクティスを実践してる？って話も

9. 広がる対象と
その分類
9
Dynamic Infrastructure Platforms
Infrastructure Definication Tools
Server Configuration Tools
Infrastructure Services

10. これから
どうなる？
10
Cloud, Container, Micro Services等のさらなる拡大と発展
今までと重きが変わってくる
モニタリング等の運用部分のコード化
動的な振る舞いを如何にコードに落としこむか
より複雑化するので、如何にシンプルに保つかが大切

11. 11

12. 感想的な
12
なんとなく感じていたものが次々言語化されてて良かった
これから向かうべき方向性の示唆に富んでて良かった
今日、この話をしようって思ったのもこのイベントの影響だったり
これから始める人は大変そうに感じるかもね。。。

13. 13

14. 14

15. 15

16. でぶおっぷす
16
完全にバズワード化
世にあふれるDevOps製品
元々は開発(Dev)と運用(Ops)のコラボレーションを推進し、
事業スピードを上げようという提言的なもの
Infrastructure as Codeはその手段の一つ
が、そういったツールを使うことや自動化＝DevOps的風潮

17. 17

18. DevOps
18
アプリケーションの要求が変わった時に
自分でインフラ構成やミドルウェアの設定を変えられるDev
パフォーマンス低下した時にSlow Log見て、原因のSQLに当たりをつける
…だけじゃなくてそれが発行される箇所を特定して直せちゃうOps
そのアプリケーションに最適なインフラ構成からミドルウェア選定まで
協力して設計・構築するDev,Ops
およびそういったことが上手く回るフローや環境の構築、組織・文化の醸成

19. 19

20. 20

21. Devな人
21
The Twelve-Factor App
インフラまで全て含めて一つのアプリケーションであると認識しよう
アプリケーションに合わせたインフラが簡単に作れる世界になった
誰かが作ったインフラに縛られて、そのまま使うだけでは勿体無い
インフラをアプリケーションの武器とする

22. Opsな人
22
The Twelve-Factor App
アプリケーションのコードに触れるようになろう
技術的にも組織的にも
インフラの問題解決のためにアプリやツールを作るという発想を持つ

23. 23

24. クロスすると
24
異なるロールの人同士で領域がクロスするとオーバヘッドが生まれる
共通言語が必要になる
それを解決するのがInfrastructure as Code
共通の判断基準を持とう
数値化・可視化・モニタリングの重要性
「DevOpsのためのモニタリングツール」とか間違ってないんだけど、この辺の前提抜け落ちてるから胡散臭くな（ｒｙ

25. 25

26. 共通言語
26
ただコマンドや手順を羅列するだけのものは共通言語になりえない
自動化したいだけならそれでも良い
それで十分な場面も多くあるということは否定するつもりはない
全員が全てを知るのは難しいし、全てを知っている必要もない
オブジェクト指向的発想
「インフラのモデリング」にはこういう意味もあると思ってる

27. オブジェクト
指向
27
複雑さを隠蔽して分かりやすいインターフェースを提供する
抽象化とかそういうアレ
抽象度が低いとインフラについて求められる知識が多くなる
ただし、逆もしかり
過度な共通化などによって複雑化する事態は避ける
シンプルに小さく保つ
取り回しの良い部品を沢山作って組み合わせる
オブジェクト指向開発で失敗しないためのプラクティスと一緒っぽい

28. 28

29. 29

30. 目的と手段
30
事業スピードを上げたい
分業によるオーバヘッドが問題
対応が早くて変化に対して柔軟なら分業していても問題ないのでは？
いわゆる、攻めの運用
それを実現するためのInfrastructure as Code
SREっぽい？

31. あるいは
31
「管理しない」領域を増やすというアプローチ
コンテナ化
PaaSの利用（GAEはいいぞ）
Serverless Architecture
個人的にもそれで済むなら越したことはないと思う
長い目で見ると廃業の危機ｗ

32. 32

33. 33

34. IaCまとめ
34
領域を広げてさらに進化し続けてて一言では言い表せなくなってきた
とにかく便利な世の中になってるけど、反面複雑化してる
複雑さに協力して立ち向かうために共通言語を持とう
「自分達で管理しない」領域を増やすことで負担を減らすアプローチもある

35. 35

36. DevOps
まとめ
36
インフラまで全て含めて一つのアプリケーションである
そもそも何が目的なのか考える
目的を見失わずに領域を広げていくことで辿り着く場所
ツールの話をする前にやることは一杯ある