ある機械学習システムをAWSからGCP/GKEに移行した話 / Machine Learning System Migration from AWS to GKE

Data Pipeline Casual Talk Vol.4
https://dpct.connpass.com/event/139163/

Transcript

1. ある機械学習システムを
   AWS
   からGCP/GKE
   に移行した話
   Data Pipeline Casual Talk Vol.4 - 2019/09/30
   @yukinagae
   

   View Slide

2. TL;DR
   AWS
   で動いている機械学習システムをGCP/GKE
   化
   した（まずAPI
   部分のみ）
   GCP/GKE
   化の理由
   リリースサイクルの高速化
   インフラコスト削減 (
   リソース共有)
   既存システムも徐々に移行していく予定
   新システムは最初からGCP/GKE
   で構築
   2
   

   View Slide

3. 自己紹介
   永江悠紀 @yukinagae
   エムスリー株式会社 ソフトウェアエンジニア
   データエンジニア寄り。最近はレコメンド改善
   などもやる
   元々Java/Scala
   でサーバサイドの開発をやっていた
   最近はGo + Python
   を触ることが多い
   クラウドはGCP
   担当（※AWS
   わからないだけ）
   3
   

   View Slide

4. システム移行の背景
   エムスリーでは多くのシステムをオンプレもしく
   はAWS
   で構築している
   AI
   チームではすでに複数の機械学習システムを開
   発・リリース済み（AWS
   ）
   ※詳しくは以下のスライドが詳しいです:
   エムスリーにおける機械学習活用事例と開発の効率化
   https://speakerdeck.com/nishiba/emusuriniokeru-ji-
   jie-xue-xi-huo-yong-shi-li-tokai-fa-falsexiao-lu-hua
   4
   

   View Slide

5. 多数のマイクロサービス
   2
   年間で20
   をこえる機械学習システムをリリース
   現在も増加中
   すごいね！(´∀｀)
   5
   

   View Slide

6. ポイント
   1.
   システム数が多い
   6
   

   View Slide

7. 今回の移行対象のシステム
   Cantor
   記事などのコンテンツの関連度（類似度）を計
   算するシステム
   ※おまけ:
   システム名はドイツの数学者のGeorg Cantor
   が由来
   7
   

   View Slide

8. 既存システム構成（図）
   8
   

   View Slide

9. 既存システムの課題①
   現状のシステム構成だと、GCP/BigQuery → AWS
   と
   いうクラウドをまたいだ構成になってしまっている
   9
   

   View Slide

10. ポイント
    2. BigQuery
    とAWS
    の混在
    10
    

    View Slide

11. 既存システムの課題②
    Cantor
    というシステム構成特有の課題:
    Lambda
    でもろもろ問題があった
    15
    分に一度バックエンドのECS
    が停止されてし
    まう（確率的にタイムアウトが発生）
    11
    

    View Slide

12. 既存システムの課題③（※改善点）
    簡単・頻繁にリリースしたい
    すぐリリースしたい（※カナリアリリース etc
    ）
    バグなどの際すぐ以前のバージョンに戻したい
    マイクロサービスの粒度のシステムが増えている
    ので各環境を用意するのは大変
    運用や管理が面倒
    インフラコストがかさむ
    12
    

    View Slide

13. ポイント
    3.
    どんどんリリースしたい
    4.
    運用・管理を楽にしたい
    5.
    インフラコスト削減したい
    13
    

    View Slide

14. 新システム構成の選択肢
    AWS
    なら
    EC2
    ECS
    EKS
    GCP
    なら
    Cloud Run
    GAE
    （ ex
    ）
    GCE
    GKE 14
    

    View Slide

15. 技術選定のポイントいろいろ
    インフラコスト
    運用の手間
    クラウドベンダーのサービスの成熟度やマイルス
    トーン
    ワークロードの特性
    必要なリソース要件
    チーム体制（例:
    人数 /
    スキル /
    学習コスト）
    15
    

    View Slide

16. ポイントを振り返る
    1.
    サービス数（API
    ）が多い
    2. BigQuery
    とAWS
    の混在
    3.
    どんどんリリースしたい
    4.
    運用・管理を楽にしたい
    5.
    インフラコスト削減したい
    16
    

    View Slide

17. GKE
    でいい感じに作れるのでは？
    (
    ｀・ω
    ・´)
    17
    

    View Slide

18. 想定するメリット
    コスト削減
    複数サービスをGKE
    で構築しリソース最適化
    メンテナンスコストも削減（されるはず）
    リリースの高速化
    オーダーメイドから量産体制へ
    terraform
    k8s
    可用性も向上
    全部GCP
    にできてBigQuery
    もにっこり(´∀｀) 18
    

    View Slide

19. 移行方針:
    どうやって移行するか？
    1.
    まずはAPI
    部分（システムの一部）からの移行
    2.
    段階的にすべてを移行していく
    まずはAPI
    部分からの移行を実施
    影響範囲を小さくしたい
    API
    だけなら最悪どうにでもなる
    もともとのAWS
    ヘの切り戻しも容易
    機械学習部分をいきなり移行してデグレったら
    嫌だよね(/
    ･ω
    ･)/
    汗
    19
    

    View Slide

20. 移行後の構成（API
    部分のみ）
    20
    

    View Slide

21. GKE
    からCloud SQL
    に接続
    Cloud SQL Proxy
    で別GCP
    プロジェクトのDB
    に接
    続する構成（マイクロサービス的な構成）
    原理的にPrivate IP
    で直で接続するより当然遅い
    Cloud SQL Proxy
    にした場合にどれくらい遅くなる
    かは簡易的に検証（※当然実環境とは異なるが）
    medium
    記事: https://medium.com/google-cloud-
    jp/eb1fbd049d56
    github: https://github.com/yukinagae/latency-
    comparison-of-cloud-sql-connection
    21
    

    View Slide

22. 移行後の理想（全部GCP/GKE
    化）
    22
    

    View Slide

23. 今後の移行方針
    既存サービスのGCP/GKE
    化
    まずは今回のプロジェクトで導入実績を作り、
    運用経験を積む
    他サービスも徐々に移行していく（※移行すれ
    ばするほど、インフラ・運用コストを削減でき
    る）
    新規サービスは最初からGCP/GKE
    で構築
    次に発表する katio2
    さんがそのサービスの話を
    してくれると思います(
    ｀・ω
    ・´)
    23
    

    View Slide

24. ありがとうございました！
    (´∀｀)
    24
    

    View Slide

25. （おまけ）GKE
    移行の辛み
    k8s/GKE
    周りのノウハウや経験がないので手探り
    そもそもk8s
    自体の学習コストが高い
    k8s
    の公式ドキュメントそのままだと動かない
    GKE
    はだいたいβ
    版
    25
    

    View Slide

26. （おまけ）GCP
    での運用・監視
    datadog
    はちょっと辛い
    既存のAWS
    システムではdatadog
    をdashboard
    で使
    ってたが、GCP
    で使うのは辛い
    PubSub
    経由でdatadog
    にpush
    する仕組みを毎回
    作らないといけない
    GCP
    プロジェクト毎に認証をしないといけない
    の大変
    datadog APM
    の導入はめちゃくちゃ楽
    しかし、もちろんcontainer
    周りの指標しか取得
    できない
    26
    

    View Slide

27. （おまけ）現状の運用・監視方法
    Stackdriver Monitoring
    使う理由
    datadog
    用に追加のintegration
    作業が不要
    複数プロジェクトを一つのworkspace
    にまとめれ
    ば、GKE
    やCloud SQL
    のプロジェクトが別でも1
    つ
    のdashboard
    で監視できる
    alert policy
    やヘルスチェックもそのまま作れる
    （※現状はterraform
    使わず、あえてGUI
    で手動
    作成している。理由としては、監視しながらち
    ょこちょこ値を調整したいから）
    27
    

    View Slide

28. （おまけ）現状の運用・監視方法
    結論
    GCP
    の場合にはStackdriver
    のみ使うことにした
    Stackdriver monitoring
    での監視
    alert policy
    の作成 + slack
    通知
    dashboard
    の作成
    Stackdriver Trace
    でのパフォーマンスチェック
    opencensus
    入れた
    Stackdriver for python
    はα
    版。。。(
    ｀・ω
    ・´)
    汗
    28
    

    View Slide

29. おわり
    29
    

    View Slide