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 full-size slide

  2. TL;DR
    AWS
    で動いている機械学習システムをGCP/GKE

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. 既存システム構成(図)
    8

    View full-size slide

  9. 既存システムの課題①
    現状のシステム構成だと、GCP/BigQuery → AWS

    いうクラウドをまたいだ構成になってしまっている
    9

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  12. 既存システムの課題③(※改善点)
    簡単・頻繁にリリースしたい
    すぐリリースしたい(※カナリアリリース etc

    バグなどの際すぐ以前のバージョンに戻したい
    マイクロサービスの粒度のシステムが増えている
    ので各環境を用意するのは大変
    運用や管理が面倒
    インフラコストがかさむ
    12

    View full-size slide

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

    View full-size slide

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

    GCE
    GKE 14

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    19

    View full-size slide

  20. 移行後の構成(API
    部分のみ)
    20

    View full-size 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 full-size slide

  22. 移行後の理想(全部GCP/GKE
    化)
    22

    View full-size slide

  23. 今後の移行方針
    既存サービスのGCP/GKE

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

    View full-size slide

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

    View full-size slide

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

    25

    View full-size slide

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

    View full-size slide

  27. (おまけ)現状の運用・監視方法
    Stackdriver Monitoring
    使う理由
    datadog
    用に追加のintegration
    作業が不要
    複数プロジェクトを一つのworkspace
    にまとめれ
    ば、GKE
    やCloud SQL
    のプロジェクトが別でも1

    のdashboard
    で監視できる
    alert policy
    やヘルスチェックもそのまま作れる
    (※現状はterraform
    使わず、あえてGUI
    で手動
    作成している。理由としては、監視しながらち
    ょこちょこ値を調整したいから)
    27

    View full-size slide

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

    28

    View full-size slide