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

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

yukinagae
September 30, 2019

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

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

yukinagae

September 30, 2019
Tweet

More Decks by yukinagae

Other Decks in Technology

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