Infrastructure-as-Code-is-very-tired

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. View Slide

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

   View Slide

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

   View Slide

8. View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. View Slide

13. View Slide

14. View Slide

15. 今の僕の状態
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. • tfstate は s3 backend に
    

    View Slide

25. View Slide

26. 詳解！Terraform Best Practices in 2017
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

37. 4. tfstate は s3 backend に
    

    View Slide

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

    View Slide

39. View Slide

40. View Slide

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

    View Slide

42. Terraform Module Registry
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

48. Facebookで呟き、今に⾄る
    

    View Slide

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

    View Slide

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

    View Slide

51. View Slide

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

    View Slide

53. ߟ͑Δ΂͖ϙΠϯτ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

60. ͭ·Γ
    

    View Slide

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

    View Slide

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

    View Slide

63. ROIΛߟ͑Δ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

67. ྑ͍πʔϧͷ঺հ
    

    View Slide

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

    View Slide

69. View Slide

70. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

74. We are Hiring!!
    

    View Slide

75. View Slide

76. View Slide

77. View Slide

78. View Slide

79. View Slide

80. View Slide

81. View Slide

82. Thank you.
    

    View Slide