Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Infrastructure-as-Code-is-very-tired
shogomuranushi
February 24, 2019
58
46k
Infrastructure-as-Code-is-very-tired
shogomuranushi
February 24, 2019
Tweet
Share
More Decks by shogomuranushi
See All by shogomuranushi
FPが教える iDeCo のすごさ
shogomuranushi
0
35
AWS Control Tower導入してハッピーになりました
shogomuranushi
0
50
EKS を使ってる人から見た App Runner
shogomuranushi
7
2k
Suggested Topicの質問に可能な限り答えてみた
shogomuranushi
0
940
顧客のアプリケーションコードが動くマルチテナント環境における課題とEKSにたどり着くまで
shogomuranushi
0
1.2k
ちょいテク100本ノック。できるまで帰しません 。今から使えるちょいテク集
shogomuranushi
1
1.6k
after of Infrastructure-as-Code-is-very-tired
shogomuranushi
16
3.2k
what is Cloud Run?
shogomuranushi
2
83
登壇資料_JAWS-UG_初心者支部_20190417.pdf
shogomuranushi
0
490
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
253
12k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
173
8.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
107
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
239
11k
Practical Orchestrator
shlominoach
178
8.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
5
2.5k
Done Done
chrislema
174
14k
The Straight Up "How To Draw Better" Workshop
denniskardys
225
120k
How To Stay Up To Date on Web Technology
chriscoyier
780
250k
How to name files
jennybc
40
63k
Code Reviewing Like a Champion
maltzj
506
37k
Fantastic passwords and where to find them - at NoRuKo
philnash
27
1.6k
Transcript
Infrastructure as CodeʹർΕͨͷͰɺ ͕ͨͪຊདྷΓ͔ͨͬͨ͜ͱΛཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner &
Lead Infrastructure Engineer
ABEJA, Inc. - Product Owner - Lead Infrastructure Engineer Shogo
Muranushi
• 2/26発売! • Kindle、書泉ブックタワーで 先⾏販売中
• 会社紹介とプロダクト紹介 • 僕の遍歴と苦悩 • そもそも Infrastructure as Code で実現したかったこと
• 代案を考える アジェンダ
None
トロント⼤学ヒントン教授が ディープラーニングによる画 像認識で10%以上の精度改 善に成功(AlexNet) AlphaGOが囲碁のプロ棋⼠ イ・セドルを破る ディープラーニングによる画像認識で⼈間の精度を凌駕することに成功(ResNet) 10 12 5
ゲームに対する深層強化 学習の適⽤により⼈間の 知⾒を与えること無く有 効な戦略を⾃動的に獲得 することに成功(DQN) カリフォルニア⼤学バークレー校が深 層強化学習をロボット制御に応⽤する ことに成功(BRETT) 2 3 GANによりフォトリアリスティック (写真のよう)な画像の⽣成に成功 10 मɿদݪਔʢͩͯ͜ະདྷେֶڭतɺגࣜձࣾABEJAٕज़ސʣ AI 驚くべき の進化の歴史 2012 2013 2014 2015 2016 2017
ABEJA創業 salesforceと 資本業務提携 インスパイア、個⼈投資家から最初 の資⾦調達を実施 ディープラーニングベー スシステムが三越伊勢丹 ホールディングスで採⽤ 世界で初めての⼩売業向けディープラー ニングベースSaaSをリリース
ダイキン⼯業 と提携 NVIDIAと 資本業務提携 シンガポール 法⼈を設⽴ NTT、さくらインターネットなどから資⾦ 調達を実施 ABEJAの発展 9 9 7 12 6 5 2013 2014 2015 2016 2017 10 6 3 2012
None
データ 取得 データ 蓄積 データ 確認 教師データ 作成 モデル 設計
学習 評価 デプロイ 推論 再学習 データウェアハウス の準備と管理 データのバリデーション(正確性)の確認 0からのモデル設計 GPU環境の準備と ⾼度な分散化 データ、モデル、結果のバージョン管理 統計的に本番にデプロイした瞬間 から精度が下がることを担保 ⼤量データの取得に必要なAPIや負荷分散 の仕組みや準備、セキュリティ担保 教師データの作成に必要なツールと⼈材の準備 開発環境から本番環境への引き渡し 冗⻑性やGPUリソースの担保、 エッジ側との連携プロセス構築
データ 取得 データ 蓄積 データ 確認 教師データ 作成 モデル 設計
学習 評価 デプロイ 推論 再学習 データウェアハウス の準備と管理 データのバリデーション(正確性)の確認 0からのモデル設計 GPU環境の準備と ⾼度な分散化 データ、モデル、結果のバージョン管理 統計的に本番にデプロイした瞬間 から精度が下がることを担保 ⼤量データの取得に必要なAPIや負荷分散 の仕組みや準備、セキュリティ担保 教師データの作成に必要なツールと⼈材の準備 開発環境から本番環境への引き渡し 冗⻑性やGPUリソースの担保、 エッジ側との連携プロセス構築 AI活⽤までに数多くの課題が存在
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システムを導⼊することは⽐較的⾼速で安価ですが、時間をかけて それを維持することは困難かつ⾼価である”
None
None
None
今の僕の状態
今の僕の状態 ύτϥογϡͷֆΛ ૾͍ͯͩ͘͠͞
本セッションでの Infrastructure as Code は主にAWSを構成 するためのツール群を指します。 解を持っているわけではありません。 ベストな案も持っていないのでみんなで答えを出しましょ う。 注意事項
• Chef: 1年 • Ansible: 2年 • CloudFormation: 2年 •
Terraform: 3年 僕の遍歴
None
• ディレクトリ設計 • Environment を分ける • tfstate は s3 backend
に • Workspace の活⽤ • Map 関数フル活⽤ 詳解!Terraform Best Practices in 2017
• ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔεmoduleԽ͢Δ
• Environmentを分ける WorkspaceΛ׆༻͠ɺڥΛ͚Δ ݺͼग़࣌͢ ${terraform.workspace}
• Map 関数フル活⽤ ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠ΓͰvariableΛఆٛ
• tfstate は s3 backend に
None
詳解!Terraform Best Practices in 2017
• 社員のオンボーディングに時間がかかる • 数ヶ⽉後に⾃分で作る時に思い出すのに時間がかかる • ⼀定のスキルを持っている⼈がいる ベストプラクティスかもしれないけど複雑問題
• Applyに気を使う • Destroy/Createしないか慎重になる • 動作を理解していない⼈に安易に作業を任せられない • つまり、⼀定のスキルを持っている⼈がいる 変更の差分を維持するのに⼿間がかかる
• Terraform、CFnの対応を待てない場合は⼿でやる? • ということは全部をコード化出来ない • 対応後に差分反映をしなきゃ。結構気を使うよね • つまり、⼀定のスキルを持っている⼈がいる 新しいサービス・機能に対応してない時がある
• スタートアップはそんなに⼈がいなかった • 居たとしてもValueある開発をしてほしい つまり、⼀定のスキルを持っている⼈がいる
イキリ期 申し訳ございません。複雑でした
• ロシア⼈「DynamoDBのTerraformのコードを作って欲 しい」 • 村主「オッケー」 とある⽇
1. まずSampleをそのまま実⾏する 2. ディレクトリ設計 3. Environmentを分ける 1. s3 backend 4.
Workspaceの活⽤ 1. Map関数フル活⽤ やること
1. まずSampleをそのまま実⾏する
2. ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔεmoduleԽ͢Δ
3. Environmentを分ける WorkspaceΛ׆༻͠ɺڥΛ͚Δ ݺͼग़࣌͢ ${terraform.workspace}
4. tfstate は s3 backend に
5. tfstate は s3 backend に ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠ΓͰvariableΛఆٛ
None
None
• 1年ぶりにTerraformを調べる • for⽂はできない?!てことは・・ • ん?0.12ではfor⽂が使えるとな • 0.12をビルドするか?いや、まともに動かないのも⾯倒だな • ん?Terraform
Module Registryというものがあるぞ。Githubに コードが上がってる • moduleの参考にさせてもらおう もっとキレイに書けないものか
Terraform Module Registry
Terraform Module Registry ⼼の声 「いや、俺こんな事してる場合じゃない」
僕の役割 Πϯϑϥ ୲ऀ Πϯϑϥ ऀ ϓϩμΫτ Φʔφʔ Time 責任
• 「それ作って消して作って消して、満⾜⾏くコードはどれくらい の時間で作れる?」 • 「誰が⾯倒⾒れる?」 • 「そもそもDynamoDBってそんな何回も作る?」 • 「DynamoDBの変更作業も少なくね?」 •
「差分気にしながら、コードのリファクタ考えながら使うメリッ トある?」 その時の⼼の声集
• 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かや り直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 •
「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある?」 その時の⼼の声集 その2
• 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かや り直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 •
「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある?」 その時の⼼の声集 その2 「いや、無理」
Facebookで呟き、今に⾄る
Infrastructure as CodeʹർΕͨͷͰɺ ͕ͨͪຊདྷΓ͔ͨͬͨ͜ͱΛཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner &
Lead Infrastructure Engineer
• Infrastructure as Codeとは • ⾃動化、バージョン管理、テスト、継続的インテグレーショ ン、継続的デプロイといった、ソフトウェア開発のプラクティ スをシステム管理に応⽤するための⽅法論 • ⼯数削減、作業履歴、テスト⾃動化、オペミス削減、レ
ビュー・フローのメリット そもそも Infrastrucure as Codeで実現したかったこと
None
• ポチポチを数分で終わるはずが • コード化に時間がかかる • リファクタしたい病が発病する • 差分の整合を取るのに時間と気を使う • コードの拡張性を上げると、可読性が下がり複雑になる。敷居が上がる
• コードのシンプルにすると、可読性は上がるが拡張性に⽋ける • moduleの再利⽤性の難しさ ただし、⾟いことがたくさんある
ߟ͑Δ͖ϙΠϯτ
• 体制 • 組織 • 事業フェーズ ⾃分が置かれている環境によって適⽤有無を考える େࣄ
• 「コード化は正義」廃⽌する • ROIを考えて⼿作業も視野に なんでもかんでもコード化するのは辞める • ref: https://image.slidesharecdn.com/20130801devsumidevops-130813042014- phpapp01/95/2013a1devops-35-638.jpg?cb=1376370976
• オペミスがある • 記録が残らない • 再現性がない • 使い回せない • レビューができない
⼿作業ではダメなのか。何がダメなのか
• オペミスがある • オペミスしてもOKなところ、NGなところ分けてる? • 記録が残らない • 作業内容、履歴は(Excel)Githubで管理 • 逆に今の状態をExportしたい
• 再現性がない • 本当に再現する必要ある? 代案は?
• 使い回せない • 本当に使い回す?? • 逆に今の状態をExport => Importしたい • レビューができない
• 作業内容、変更するパラメータを事前にレビューする 代案は?
• CLIのコマンドを記録に残して、実⾏する • オペミス少ない • 記録は残る • 再現性はある • 使い回せる
• レビューできる • 冪等ではない。宣⾔的ではない 代案は?
ͭ·Γ
εϥϜμϯΫઋಓ͞Μ ʮ·ͩ͋ΘͯΔΑ͏ͳ࣌ؒ͡Όͳ͍ʯ
• ⼿作業では何がダメなのか、ダメな理由をもう⼀度洗い出す • CLIや他の代案が出てくる • 状況を鑑みて要件を満たしつつ、コスト、スピード、リスクを評 価し、代案の⽅がコード化よりROIが⾼いなら、代案でOK • 例)DBとかCDNって何回も作らないよね・・? •
コスト、スピード、リスクの観点でコード化の⽅がROIが⾼いな ら、コード化でOK (⾃分に対して)冷静になりましょう
ROIΛߟ͑Δ
• コード化しない • DBとかCDNのような何回も作らないようなやつ(コスト効率悪い) • 意図しない動作を許容できないステート持つ系(リスクを許容できない) • インフラの⼈数が少ない(学習コストがかかり、スピード落ちる) コスト、スピード、リスクの評価例
• コード化する • ALB + EC2 + RDBのセットはバンバン作るんだよねー(コスト効率良い) • DR⽤にすぐに⽴ち上げる必要がある(スピードある)
• 多リージョンにサービス展開する野望がある(スピードある) • リソース間を繋いでいる系(コスト効率⾼い) • オペミスを可能な限り排除したい(⾃動化によるリスクヘッジは可能) • だがしかし コスト、スピード、リスクの評価例
• 過度にキレイにし過ぎない • ⾜りない機能を補うために中⾝が複雑なコードにハードル上が る • 必要あらば本家にPR出そう • 割り切って⼿でも良いやん コード化する時の注意点
ྑ͍πʔϧͷհ
• 誰かが作ったmoduleを再利⽤出来る • 誰が作ったかわからんものを信⽤するの難しいけど、Githubに コードが上がってるので何をしているかがちゃんと分かる • GithubなのでPRも出せる • そのうち、Variableだけ定義してmoduleを作成、変更すること はなくなる期待を込めている
None
None
• 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるの で、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気に していれば良い
• 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるの で、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気に していれば良い すいません。 結局凝りてません
今の僕の状態 こうならないように ROI考えましょう
We are Hiring!!
None
None
None
None
None
None
None
Thank you.