Infrastructure-as-Code-is-very-tired

Slide 1

Slide 1 text

Infrastructure as CodeʹർΕͨͷͰɺ ๻͕ͨͪຊདྷ΍Γ͔ͨͬͨ͜ͱΛ੔ཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner & Lead Infrastructure Engineer

Slide 2

Slide 2 text

ABEJA, Inc. - Product Owner - Lead Infrastructure Engineer Shogo Muranushi

Slide 3

Slide 3 text

• 2/26発売！ • Kindle、書泉ブックタワーで先⾏販売中

Slide 4

Slide 4 text

• 会社紹介とプロダクト紹介 • 僕の遍歴と苦悩 • そもそも Infrastructure as Code で実現したかったこと • 代案を考えるアジェンダ

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

トロント⼤学ヒントン教授がディープラーニングによる画像認識で１０％以上の精度改善に成功（AlexNet） AlphaGOが囲碁のプロ棋⼠イ・セドルを破るディープラーニングによる画像認識で⼈間の精度を凌駕することに成功（ResNet） 10 12 5 ゲームに対する深層強化学習の適⽤により⼈間の知⾒を与えること無く有効な戦略を⾃動的に獲得することに成功（DQN）カリフォルニア⼤学バークレー校が深層強化学習をロボット制御に応⽤することに成功（BRETT） 2 3 GANによりフォトリアリスティック (写真のよう)な画像の⽣成に成功 10 ؂मɿদݪਔʢ͸ͩͯ͜ະདྷେֶڭतɺגࣜձࣾABEJAٕज़ސ໰ʣ AI 驚くべきの進化の歴史 2012 2013 2014 2015 2016 2017

Slide 7

Slide 7 text

ABEJA創業 salesforceと資本業務提携インスパイア、個⼈投資家から最初の資⾦調達を実施ディープラーニングベースシステムが三越伊勢丹ホールディングスで採⽤世界で初めての⼩売業向けディープラーニングベースSaaSをリリースダイキン⼯業と提携 NVIDIAと資本業務提携シンガポール法⼈を設⽴ NTT、さくらインターネットなどから資⾦調達を実施 ABEJAの発展 9 9 7 12 6 5 2013 2014 2015 2016 2017 10 6 3 2012

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

データ取得データ蓄積データ確認教師データ作成モデル設計学習評価デプロイ推論再学習データウェアハウスの準備と管理データのバリデーション（正確性）の確認 0からのモデル設計 GPU環境の準備と⾼度な分散化データ、モデル、結果のバージョン管理統計的に本番にデプロイした瞬間から精度が下がることを担保⼤量データの取得に必要なAPIや負荷分散の仕組みや準備、セキュリティ担保教師データの作成に必要なツールと⼈材の準備開発環境から本番環境への引き渡し冗⻑性やGPUリソースの担保、エッジ側との連携プロセス構築

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Ref: https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf “ As the machine learning (ML) community continues to accumulate years of experience with live systems ” “ 開発およびMLシステムを導⼊することは⽐較的⾼速で安価ですが、時間をかけてそれを維持することは困難かつ⾼価である”

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

今の僕の状態

Slide 16

Slide 16 text

今の僕の状態 ύτϥογϡͷֆΛ ૝૾͍ͯͩ͘͠͞

Slide 17

Slide 17 text

本セッションでの Infrastructure as Code は主にAWSを構成するためのツール群を指します。解を持っているわけではありません。ベストな案も持っていないのでみんなで答えを出しましょう。注意事項

Slide 18

Slide 18 text

• Chef: 1年 • Ansible: 2年 • CloudFormation: 2年 • Terraform: 3年僕の遍歴

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

• ディレクトリ設計 • Environment を分ける • tfstate は s3 backend に • Workspace の活⽤ • Map 関数フル活⽤詳解！Terraform Best Practices in 2017

Slide 21

Slide 21 text

• ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ෼͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔε͸moduleԽ͢Δ

Slide 22

Slide 22 text

• Environmentを分ける WorkspaceΛ׆༻͠ɺ؀ڥΛ෼͚Δ ݺͼग़࣌͢͸ ${terraform.workspace}

Slide 23

Slide 23 text

• Map 関数フル活⽤ ؀ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠੾ΓͰvariableΛఆٛ

Slide 24

Slide 24 text

• tfstate は s3 backend に

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

詳解！Terraform Best Practices in 2017

Slide 27

Slide 27 text

• 社員のオンボーディングに時間がかかる • 数ヶ⽉後に⾃分で作る時に思い出すのに時間がかかる • ⼀定のスキルを持っている⼈がいるベストプラクティスかもしれないけど複雑問題

Slide 28

Slide 28 text

• Applyに気を使う • Destroy/Createしないか慎重になる • 動作を理解していない⼈に安易に作業を任せられない • つまり、⼀定のスキルを持っている⼈がいる変更の差分を維持するのに⼿間がかかる

Slide 29

Slide 29 text

• Terraform、CFnの対応を待てない場合は⼿でやる？ • ということは全部をコード化出来ない • 対応後に差分反映をしなきゃ。結構気を使うよね • つまり、⼀定のスキルを持っている⼈がいる新しいサービス・機能に対応してない時がある

Slide 30

Slide 30 text

• スタートアップはそんなに⼈がいなかった • 居たとしてもValueある開発をしてほしいつまり、⼀定のスキルを持っている⼈がいる

Slide 31

Slide 31 text

イキリ期申し訳ございません。複雑でした

Slide 32

Slide 32 text

• ロシア⼈「DynamoDBのTerraformのコードを作って欲しい」 • 村主「オッケー」とある⽇

Slide 33

Slide 33 text

1. まずSampleをそのまま実⾏する 2. ディレクトリ設計 3. Environmentを分ける 1. s3 backend 4. Workspaceの活⽤ 1. Map関数フル活⽤やること

Slide 34

Slide 34 text

1. まずSampleをそのまま実⾏する

Slide 35

Slide 35 text

2. ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ෼͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔε͸moduleԽ͢Δ

Slide 36

Slide 36 text

3. Environmentを分ける WorkspaceΛ׆༻͠ɺ؀ڥΛ෼͚Δ ݺͼग़࣌͢͸ ${terraform.workspace}

Slide 37

Slide 37 text

4. tfstate は s3 backend に

Slide 38

Slide 38 text

5. tfstate は s3 backend に ؀ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠੾ΓͰvariableΛఆٛ

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

• 1年ぶりにTerraformを調べる • for⽂はできない？！てことは・・ • ん？0.12ではfor⽂が使えるとな • 0.12をビルドするか？いや、まともに動かないのも⾯倒だな • ん？Terraform Module Registryというものがあるぞ。Githubにコードが上がってる • moduleの参考にさせてもらおうもっとキレイに書けないものか

Slide 42

Slide 42 text

Terraform Module Registry

Slide 43

Slide 43 text

Terraform Module Registry ⼼の声「いや、俺こんな事してる場合じゃない」

Slide 44

Slide 44 text

僕の役割 Πϯϑϥ ୲౰ऀ Πϯϑϥ ੹೚ऀ ϓϩμΫτ Φʔφʔ Time 責任

Slide 45

Slide 45 text

• 「それ作って消して作って消して、満⾜⾏くコードはどれくらいの時間で作れる？」 • 「誰が⾯倒⾒れる？」 • 「そもそもDynamoDBってそんな何回も作る？」 • 「DynamoDBの変更作業も少なくね？」 • 「差分気にしながら、コードのリファクタ考えながら使うメリットある？」その時の⼼の声集

Slide 46

Slide 46 text

• 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かやり直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 • 「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリットある？」その時の⼼の声集その２

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Facebookで呟き、今に⾄る

Slide 49

Slide 49 text

Infrastructure as CodeʹർΕͨͷͰɺ ๻͕ͨͪຊདྷ΍Γ͔ͨͬͨ͜ͱΛ੔ཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner & Lead Infrastructure Engineer

Slide 50

Slide 50 text

• Infrastructure as Codeとは • ⾃動化、バージョン管理、テスト、継続的インテグレーション、継続的デプロイといった、ソフトウェア開発のプラクティスをシステム管理に応⽤するための⽅法論 • ⼯数削減、作業履歴、テスト⾃動化、オペミス削減、レビュー・フローのメリットそもそも Infrastrucure as Codeで実現したかったこと

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

• ポチポチを数分で終わるはずが • コード化に時間がかかる • リファクタしたい病が発病する • 差分の整合を取るのに時間と気を使う • コードの拡張性を上げると、可読性が下がり複雑になる。敷居が上がる • コードのシンプルにすると、可読性は上がるが拡張性に⽋ける • moduleの再利⽤性の難しさただし、⾟いことがたくさんある

Slide 53

Slide 53 text

ߟ͑Δ΂͖ϙΠϯτ

Slide 54

Slide 54 text

• 体制 • 組織 • 事業フェーズ⾃分が置かれている環境によって適⽤有無を考える େࣄ

Slide 55

Slide 55 text

• 「コード化は正義」廃⽌する • ROIを考えて⼿作業も視野になんでもかんでもコード化するのは辞める • ref: https://image.slidesharecdn.com/20130801devsumidevops-130813042014- phpapp01/95/2013a1devops-35-638.jpg?cb=1376370976

Slide 56

Slide 56 text

• オペミスがある • 記録が残らない • 再現性がない • 使い回せない • レビューができない⼿作業ではダメなのか。何がダメなのか

Slide 57

Slide 57 text

• オペミスがある • オペミスしてもOKなところ、NGなところ分けてる？ • 記録が残らない • 作業内容、履歴は（Excel）Githubで管理 • 逆に今の状態をExportしたい • 再現性がない • 本当に再現する必要ある？代案は？

Slide 58

Slide 58 text

• 使い回せない • 本当に使い回す？？ • 逆に今の状態をExport => Importしたい • レビューができない • 作業内容、変更するパラメータを事前にレビューする代案は？

Slide 59

Slide 59 text

• CLIのコマンドを記録に残して、実⾏する • オペミス少ない • 記録は残る • 再現性はある • 使い回せる • レビューできる • 冪等ではない。宣⾔的ではない代案は？

Slide 60

Slide 60 text

ͭ·Γ

Slide 61

Slide 61 text

εϥϜμϯΫઋಓ͞Μ ʮ·ͩ͋ΘͯΔΑ͏ͳ࣌ؒ͡Όͳ͍ʯ

Slide 62

Slide 62 text

• ⼿作業では何がダメなのか、ダメな理由をもう⼀度洗い出す • CLIや他の代案が出てくる • 状況を鑑みて要件を満たしつつ、コスト、スピード、リスクを評価し、代案の⽅がコード化よりROIが⾼いなら、代案でOK • 例）DBとかCDNって何回も作らないよね・・？ • コスト、スピード、リスクの観点でコード化の⽅がROIが⾼いなら、コード化でOK （⾃分に対して）冷静になりましょう

Slide 63

Slide 63 text

ROIΛߟ͑Δ

Slide 64

Slide 64 text

• コード化しない • DBとかCDNのような何回も作らないようなやつ（コスト効率悪い） • 意図しない動作を許容できないステート持つ系（リスクを許容できない） • インフラの⼈数が少ない（学習コストがかかり、スピード落ちる）コスト、スピード、リスクの評価例

Slide 65

Slide 65 text

• コード化する • ALB + EC2 + RDBのセットはバンバン作るんだよねー（コスト効率良い） • DR⽤にすぐに⽴ち上げる必要がある（スピードある） • 多リージョンにサービス展開する野望がある（スピードある） • リソース間を繋いでいる系（コスト効率⾼い） • オペミスを可能な限り排除したい（⾃動化によるリスクヘッジは可能） • だがしかしコスト、スピード、リスクの評価例

Slide 66

Slide 66 text

• 過度にキレイにし過ぎない • ⾜りない機能を補うために中⾝が複雑なコードにハードル上がる • 必要あらば本家にPR出そう • 割り切って⼿でも良いやんコード化する時の注意点

Slide 67

Slide 67 text

ྑ͍πʔϧͷ঺հ

Slide 68

Slide 68 text

• 誰かが作ったmoduleを再利⽤出来る • 誰が作ったかわからんものを信⽤するの難しいけど、Githubにコードが上がってるので何をしているかがちゃんと分かる • GithubなのでPRも出せる • そのうち、Variableだけ定義してmoduleを作成、変更することはなくなる期待を込めている

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

• 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるので、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気にしていれば良い

Slide 72

Slide 72 text

• 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるので、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気にしていれば良いすいません。結局凝りてません