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 で実現したかったこと

   • 代案を考える アジェンダ
5. None

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
8. None

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システムを導⼊することは⽐較的⾼速で安価ですが、時間をかけて それを維持することは困難かつ⾼価である”
12. None
13. None
14. None

15. 今の僕の状態

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

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

18. • Chef: 1年 • Ansible: 2年 • CloudFormation: 2年 •

    Terraform: 3年 僕の遍歴
19. None

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 に

25. None

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Λఆٛ

39. None
40. None

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で実現したかったこと
51. None

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を作成、変更すること はなくなる期待を込めている

69. None
70. None

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

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

73. 今の僕の状態 こうならないように ROI考えましょう

74. We are Hiring!!

75. None
76. None
77. None
78. None
79. None
80. None
81. None

82. Thank you.