Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Infrastructure-as-Code-is-very-tired

shogomuranushi
February 24, 2019
53k

 Infrastructure-as-Code-is-very-tired

shogomuranushi

February 24, 2019
Tweet

More Decks by shogomuranushi

Transcript

  1. トロント⼤学ヒントン教授が ディープラーニングによる画 像認識で10%以上の精度改 善に成功(AlexNet) AlphaGOが囲碁のプロ棋⼠ イ・セドルを破る ディープラーニングによる画像認識で⼈間の精度を凌駕することに成功(ResNet) 10 12 5

    ゲームに対する深層強化 学習の適⽤により⼈間の 知⾒を与えること無く有 効な戦略を⾃動的に獲得 することに成功(DQN) カリフォルニア⼤学バークレー校が深 層強化学習をロボット制御に応⽤する ことに成功(BRETT) 2 3 GANによりフォトリアリスティック (写真のよう)な画像の⽣成に成功 10 ؂मɿদݪਔʢ͸ͩͯ͜ະདྷେֶڭतɺגࣜձࣾABEJAٕज़ސ໰ʣ AI 驚くべき の進化の歴史 2012 2013 2014 2015 2016 2017
  2. ABEJA創業 salesforceと 資本業務提携 インスパイア、個⼈投資家から最初 の資⾦調達を実施 ディープラーニングベー スシステムが三越伊勢丹 ホールディングスで採⽤ 世界で初めての⼩売業向けディープラー ニングベースSaaSをリリース

    ダイキン⼯業 と提携 NVIDIAと 資本業務提携 シンガポール 法⼈を設⽴ NTT、さくらインターネットなどから資⾦ 調達を実施 ABEJAの発展 9 9 7 12 6 5 2013 2014 2015 2016 2017 10 6 3 2012
  3. データ 取得 データ 蓄積 データ 確認 教師データ 作成 モデル 設計

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

    学習 評価 デプロイ 推論 再学習 データウェアハウス の準備と管理 データのバリデーション(正確性)の確認 0からのモデル設計 GPU環境の準備と ⾼度な分散化 データ、モデル、結果のバージョン管理 統計的に本番にデプロイした瞬間 から精度が下がることを担保 ⼤量データの取得に必要なAPIや負荷分散 の仕組みや準備、セキュリティ担保 教師データの作成に必要なツールと⼈材の準備 開発環境から本番環境への引き渡し 冗⻑性やGPUリソースの担保、 エッジ側との連携プロセス構築 AI活⽤までに数多くの課題が存在
  5. 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システムを導⼊することは⽐較的⾼速で安価ですが、時間をかけて それを維持することは困難かつ⾼価である”
  6. • ディレクトリ設計 • Environment を分ける • tfstate は s3 backend

    に • Workspace の活⽤ • Map 関数フル活⽤ 詳解!Terraform Best Practices in 2017
  7. • 1年ぶりにTerraformを調べる • for⽂はできない?!てことは・・ • ん?0.12ではfor⽂が使えるとな • 0.12をビルドするか?いや、まともに動かないのも⾯倒だな • ん?Terraform

    Module Registryというものがあるぞ。Githubに コードが上がってる • moduleの参考にさせてもらおう もっとキレイに書けないものか
  8. • 「そういえば、Redshiftの時も思った」 • 「Sample試して、module化して、キレイなコードにして…」 • 「で、Redshiftのデプロイが⼀回20-30分かかるから、何回かや り直して…」 • 「それ何時間かかるねん。ボタンポチポチで数分で出来るやん」 •

    「dev、stg、prod作っても作業時間は10分程度やん」 • 「差分気にしながら、コードのリファクタ考えながら使うメリッ トある?」 その時の⼼の声集 その2 「いや、無理」
  9. • 使い回せない • 本当に使い回す?? • 逆に今の状態をExport => Importしたい • レビューができない

    • 作業内容、変更するパラメータを事前にレビューする 代案は?
  10. • コード化する • ALB + EC2 + RDBのセットはバンバン作るんだよねー(コスト効率良い) • DR⽤にすぐに⽴ち上げる必要がある(スピードある)

    • 多リージョンにサービス展開する野望がある(スピードある) • リソース間を繋いでいる系(コスト効率⾼い) • オペミスを可能な限り排除したい(⾃動化によるリスクヘッジは可能) • だがしかし コスト、スピード、リスクの評価例