Infrastructure-as-Code-is-very-tired

Transcript

1. Infrastructure as CodeʹർΕͨͷͰɺ ๻͕ͨͪຊདྷ΍Γ͔ͨͬͨ͜ͱΛ੔ཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner & Lead Infrastructure Engineer
2. ABEJA, Inc.  - Product Owner  - Lead Infrastructure Engineer Shogo Muranushi
3. • 2/26発売！ • Kindle、書泉ブックタワーで 先⾏販売中
4. • 会社紹介とプロダクト紹介 • 僕の遍歴と苦悩 • そもそも Infrastructure as Code で実現したかったこと • 代案を考える アジェンダ
6. トロント⼤学ヒントン教授が ディープラーニングによる画 像認識で１０％以上の精度改 善に成功（AlexNet） AlphaGOが囲碁のプロ棋⼠ イ・セドルを破る ディープラーニングによる画像認識で⼈間の精度を凌駕することに成功（ResNet） 10 12 5 ゲームに対する深層強化 学習の適⽤により⼈間の 知⾒を与えること無く有 効な戦略を⾃動的に獲得 することに成功（DQN） カリフォルニア⼤学バークレー校が深 層強化学習をロボット制御に応⽤する ことに成功（BRETT） 2 3 GANによりフォトリアリスティック (写真のよう)な画像の⽣成に成功 10 ؂मɿদݪਔʢ͸ͩͯ͜ະདྷେֶڭतɺגࣜձࣾABEJAٕज़ސ໰ʣ AI 驚くべき の進化の歴史 2012 2013 2014 2015 2016 2017
7. ABEJA創業 salesforceと 資本業務提携 インスパイア、個⼈投資家から最初 の資⾦調達を実施 ディープラーニングベー スシステムが三越伊勢丹 ホールディングスで採⽤ 世界で初めての⼩売業向けディープラー ニングベースSaaSをリリース ダイキン⼯業 と提携 NVIDIAと 資本業務提携 シンガポール 法⼈を設⽴ NTT、さくらインターネットなどから資⾦ 調達を実施 ABEJAの発展 9 9 7 12 6 5 2013 2014 2015 2016 2017 10 6 3 2012
9. データ 取得 データ 蓄積 データ 確認 教師データ 作成 モデル 設計 学習 評価 デプロイ 推論 再学習 データウェアハウス の準備と管理 データのバリデーション（正確性）の確認 0からのモデル設計 GPU環境の準備と ⾼度な分散化 データ、モデル、結果のバージョン管理 統計的に本番にデプロイした瞬間 から精度が下がることを担保 ⼤量データの取得に必要なAPIや負荷分散 の仕組みや準備、セキュリティ担保 教師データの作成に必要なツールと⼈材の準備 開発環境から本番環境への引き渡し 冗⻑性やGPUリソースの担保、 エッジ側との連携プロセス構築
10. データ 取得 データ 蓄積 データ 確認 教師データ 作成 モデル 設計 学習 評価 デプロイ 推論 再学習 データウェアハウス の準備と管理 データのバリデーション（正確性）の確認 0からのモデル設計 GPU環境の準備と ⾼度な分散化 データ、モデル、結果のバージョン管理 統計的に本番にデプロイした瞬間 から精度が下がることを担保 ⼤量データの取得に必要なAPIや負荷分散 の仕組みや準備、セキュリティ担保 教師データの作成に必要なツールと⼈材の準備 開発環境から本番環境への引き渡し 冗⻑性やGPUリソースの担保、 エッジ側との連携プロセス構築 AI活⽤までに数多くの課題が存在
11. 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システムを導⼊することは⽐較的⾼速で安価ですが、時間をかけて それを維持することは困難かつ⾼価である”
15. 今の僕の状態
16. 今の僕の状態 ύτϥογϡͷֆΛ ૝૾͍ͯͩ͘͠͞
17. 本セッションでの Infrastructure as Code は主にAWSを構成 するためのツール群を指します。 解を持っているわけではありません。 ベストな案も持っていないのでみんなで答えを出しましょ う。 注意事項
18. • Chef: 1年 • Ansible: 2年 • CloudFormation: 2年 • Terraform: 3年 僕の遍歴
20. • ディレクトリ設計 • Environment を分ける • tfstate は s3 backend に • Workspace の活⽤ • Map 関数フル活⽤ 詳解！Terraform Best Practices in 2017
21. • ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ෼͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔε͸moduleԽ͢Δ
22. • Environmentを分ける WorkspaceΛ׆༻͠ɺ؀ڥΛ෼͚Δ ݺͼग़࣌͢͸ ${terraform.workspace}
23. • Map 関数フル活⽤ ؀ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠੾ΓͰvariableΛఆٛ
24. • tfstate は s3 backend に
26. 詳解！Terraform Best Practices in 2017
27. • 社員のオンボーディングに時間がかかる • 数ヶ⽉後に⾃分で作る時に思い出すのに時間がかかる • ⼀定のスキルを持っている⼈がいる ベストプラクティスかもしれないけど複雑問題
28. • Applyに気を使う • Destroy/Createしないか慎重になる • 動作を理解していない⼈に安易に作業を任せられない • つまり、⼀定のスキルを持っている⼈がいる 変更の差分を維持するのに⼿間がかかる
29. • Terraform、CFnの対応を待てない場合は⼿でやる？ • ということは全部をコード化出来ない • 対応後に差分反映をしなきゃ。結構気を使うよね • つまり、⼀定のスキルを持っている⼈がいる 新しいサービス・機能に対応してない時がある
30. • スタートアップはそんなに⼈がいなかった • 居たとしてもValueある開発をしてほしい つまり、⼀定のスキルを持っている⼈がいる
31. イキリ期 申し訳ございません。複雑でした
32. • ロシア⼈「DynamoDBのTerraformのコードを作って欲 しい」 • 村主「オッケー」 とある⽇
33. 1. まずSampleをそのまま実⾏する 2. ディレクトリ設計 3. Environmentを分ける 1. s3 backend 4. Workspaceの活⽤ 1. Map関数フル活⽤ やること
34. 1. まずSampleをそのまま実⾏する
35. 2. ディレクトリ設計 ӨڹൣғΛݶఆ͢ΔͨΊ not_immutableͱimmutableΛ෼͚Δ ࠶ར༻ੑΛߴΊΔͨΊɺϦιʔε͸moduleԽ͢Δ
36. 3. Environmentを分ける WorkspaceΛ׆༻͠ɺ؀ڥΛ෼͚Δ ݺͼग़࣌͢͸ ${terraform.workspace}
37. 4. tfstate は s3 backend に
38. 5. tfstate は s3 backend に ؀ڥຖʹϦʔδϣϯΛม͑Δྫ υοτ۠੾ΓͰvariableΛఆٛ
41. • 1年ぶりにTerraformを調べる • for⽂はできない？！てことは・・ • ん？0.12ではfor⽂が使えるとな • 0.12をビルドするか？いや、まともに動かないのも⾯倒だな • ん？Terraform Module Registryというものがあるぞ。Githubに コードが上がってる • moduleの参考にさせてもらおう もっとキレイに書けないものか
42. Terraform Module Registry
43. Terraform Module Registry ⼼の声 「いや、俺こんな事してる場合じゃない」
44. 僕の役割 Πϯϑϥ ୲౰ऀ Πϯϑϥ ੹೚ऀ ϓϩμΫτ Φʔφʔ Time 責任
45. • 「それ作って消して作って消して、満⾜⾏くコードはどれくらい の時間で作れる？」 • 「誰が⾯倒⾒れる？」 • 「そもそもDynamoDBってそんな何回も作る？」 • 「DynamoDBの変更作業も少なくね？」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある？」 その時の⼼の声集
46. • 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かや り直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 • 「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある？」 その時の⼼の声集 その２
47. • 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かや り直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 • 「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある？」 その時の⼼の声集 その２ 「いや、無理」
48. Facebookで呟き、今に⾄る
49. Infrastructure as CodeʹർΕͨͷͰɺ ๻͕ͨͪຊདྷ΍Γ͔ͨͬͨ͜ͱΛ੔ཧ͢Δ Shogo Muranushi ABEJA, Inc. Product Owner & Lead Infrastructure Engineer
50. • Infrastructure as Codeとは • ⾃動化、バージョン管理、テスト、継続的インテグレーショ ン、継続的デプロイといった、ソフトウェア開発のプラクティ スをシステム管理に応⽤するための⽅法論 • ⼯数削減、作業履歴、テスト⾃動化、オペミス削減、レ ビュー・フローのメリット そもそも Infrastrucure as Codeで実現したかったこと
52. • ポチポチを数分で終わるはずが • コード化に時間がかかる • リファクタしたい病が発病する • 差分の整合を取るのに時間と気を使う • コードの拡張性を上げると、可読性が下がり複雑になる。敷居が上がる • コードのシンプルにすると、可読性は上がるが拡張性に⽋ける • moduleの再利⽤性の難しさ ただし、⾟いことがたくさんある
53. ߟ͑Δ΂͖ϙΠϯτ
54. • 体制 • 組織 • 事業フェーズ ⾃分が置かれている環境によって適⽤有無を考える େࣄ
55. • 「コード化は正義」廃⽌する • ROIを考えて⼿作業も視野に なんでもかんでもコード化するのは辞める • ref: https://image.slidesharecdn.com/20130801devsumidevops-130813042014- phpapp01/95/2013a1devops-35-638.jpg?cb=1376370976
56. • オペミスがある • 記録が残らない • 再現性がない • 使い回せない • レビューができない ⼿作業ではダメなのか。何がダメなのか
57. • オペミスがある • オペミスしてもOKなところ、NGなところ分けてる？ • 記録が残らない • 作業内容、履歴は（Excel）Githubで管理 • 逆に今の状態をExportしたい • 再現性がない • 本当に再現する必要ある？ 代案は？
58. • 使い回せない • 本当に使い回す？？ • 逆に今の状態をExport => Importしたい • レビューができない • 作業内容、変更するパラメータを事前にレビューする 代案は？
59. • CLIのコマンドを記録に残して、実⾏する • オペミス少ない • 記録は残る • 再現性はある • 使い回せる • レビューできる • 冪等ではない。宣⾔的ではない 代案は？
60. ͭ·Γ
61. εϥϜμϯΫઋಓ͞Μ ʮ·ͩ͋ΘͯΔΑ͏ͳ࣌ؒ͡Όͳ͍ʯ
62. • ⼿作業では何がダメなのか、ダメな理由をもう⼀度洗い出す • CLIや他の代案が出てくる • 状況を鑑みて要件を満たしつつ、コスト、スピード、リスクを評 価し、代案の⽅がコード化よりROIが⾼いなら、代案でOK • 例）DBとかCDNって何回も作らないよね・・？ • コスト、スピード、リスクの観点でコード化の⽅がROIが⾼いな ら、コード化でOK （⾃分に対して）冷静になりましょう
63. ROIΛߟ͑Δ
64. • コード化しない • DBとかCDNのような何回も作らないようなやつ（コスト効率悪い） • 意図しない動作を許容できないステート持つ系（リスクを許容できない） • インフラの⼈数が少ない（学習コストがかかり、スピード落ちる） コスト、スピード、リスクの評価例
65. • コード化する • ALB + EC2 + RDBのセットはバンバン作るんだよねー（コスト効率良い） • DR⽤にすぐに⽴ち上げる必要がある（スピードある） • 多リージョンにサービス展開する野望がある（スピードある） • リソース間を繋いでいる系（コスト効率⾼い） • オペミスを可能な限り排除したい（⾃動化によるリスクヘッジは可能） • だがしかし コスト、スピード、リスクの評価例
66. • 過度にキレイにし過ぎない • ⾜りない機能を補うために中⾝が複雑なコードにハードル上が る • 必要あらば本家にPR出そう • 割り切って⼿でも良いやん コード化する時の注意点
67. ྑ͍πʔϧͷ঺հ
68. • 誰かが作ったmoduleを再利⽤出来る • 誰が作ったかわからんものを信⽤するの難しいけど、Githubに コードが上がってるので何をしているかがちゃんと分かる • GithubなのでPRも出せる • そのうち、Variableだけ定義してmoduleを作成、変更すること はなくなる期待を込めている
71. • 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるの で、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気に していれば良い
72. • 0.12でfor⽂使えるのでだいぶスッキリするし可読性も上がるの で、誰が書いても近いコードになるかも • つまり、Terraform Module Registryを使えばVariableだけ気に していれば良い すいません。 結局凝りてません
73. 今の僕の状態 こうならないように ROI考えましょう
74. We are Hiring!!
82. Thank you.