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
59
48k
Infrastructure-as-Code-is-very-tired
shogomuranushi
February 24, 2019
Tweet
Share
More Decks by shogomuranushi
See All by shogomuranushi
FPが教える iDeCo のすごさ
shogomuranushi
0
58
AWS Control Tower導入してハッピーになりました
shogomuranushi
0
90
EKS を使ってる人から見た App Runner
shogomuranushi
7
2.1k
Suggested Topicの質問に可能な限り答えてみた
shogomuranushi
0
960
顧客のアプリケーションコードが動くマルチテナント環境における課題とEKSにたどり着くまで
shogomuranushi
0
1.3k
ちょいテク100本ノック。できるまで帰しません 。今から使えるちょいテク集
shogomuranushi
1
1.9k
after of Infrastructure-as-Code-is-very-tired
shogomuranushi
16
3.2k
what is Cloud Run?
shogomuranushi
2
89
登壇資料_JAWS-UG_初心者支部_20190417.pdf
shogomuranushi
0
520
Featured
See All Featured
Writing Fast Ruby
sferik
613
58k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
32
6.7k
Documentation Writing (for coders)
carmenintech
51
2.9k
GraphQLの誤解/rethinking-graphql
sonatard
39
7.8k
Designing for Performance
lara
600
65k
Designing on Purpose - Digital PM Summit 2013
jponch
108
5.9k
Mobile First: as difficult as doing things right
swwweet
213
7.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
109
16k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
351
21k
Code Review Best Practice
trishagee
50
11k
Rails Girls Zürich Keynote
gr2m
87
12k
Teambox: Starting and Learning
jrom
124
7.9k
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.