Data Pipeline Casual Talk Vol.4 https://dpct.connpass.com/event/139163/
ある機械学習システムをAWSからGCP/GKEに移行した話Data Pipeline Casual Talk Vol.4 - 2019/09/30@yukinagae
View Slide
TL;DRAWSで動いている機械学習システムをGCP/GKE化した(まずAPI部分のみ)GCP/GKE化の理由リリースサイクルの高速化インフラコスト削減 (リソース共有)既存システムも徐々に移行していく予定新システムは最初からGCP/GKEで構築2
自己紹介永江悠紀 @yukinagaeエムスリー株式会社 ソフトウェアエンジニアデータエンジニア寄り。最近はレコメンド改善などもやる元々Java/Scalaでサーバサイドの開発をやっていた最近はGo + Pythonを触ることが多いクラウドはGCP担当(※AWSわからないだけ)3
システム移行の背景エムスリーでは多くのシステムをオンプレもしくはAWSで構築しているAIチームではすでに複数の機械学習システムを開発・リリース済み(AWS)※詳しくは以下のスライドが詳しいです:エムスリーにおける機械学習活用事例と開発の効率化https://speakerdeck.com/nishiba/emusuriniokeru-ji-jie-xue-xi-huo-yong-shi-li-tokai-fa-falsexiao-lu-hua4
多数のマイクロサービス2年間で20をこえる機械学習システムをリリース現在も増加中すごいね!(´∀`)5
ポイント1.システム数が多い6
今回の移行対象のシステムCantor記事などのコンテンツの関連度(類似度)を計算するシステム※おまけ:システム名はドイツの数学者のGeorg Cantorが由来7
既存システム構成(図)8
既存システムの課題①現状のシステム構成だと、GCP/BigQuery → AWSというクラウドをまたいだ構成になってしまっている9
ポイント2. BigQueryとAWSの混在10
既存システムの課題②Cantorというシステム構成特有の課題:Lambdaでもろもろ問題があった15分に一度バックエンドのECSが停止されてしまう(確率的にタイムアウトが発生)11
既存システムの課題③(※改善点)簡単・頻繁にリリースしたいすぐリリースしたい(※カナリアリリース etc)バグなどの際すぐ以前のバージョンに戻したいマイクロサービスの粒度のシステムが増えているので各環境を用意するのは大変運用や管理が面倒インフラコストがかさむ12
ポイント3.どんどんリリースしたい4.運用・管理を楽にしたい5.インフラコスト削減したい13
新システム構成の選択肢AWSならEC2ECSEKSGCPならCloud RunGAE( ex)GCEGKE 14
技術選定のポイントいろいろインフラコスト運用の手間クラウドベンダーのサービスの成熟度やマイルストーンワークロードの特性必要なリソース要件チーム体制(例:人数 /スキル /学習コスト)15
ポイントを振り返る1.サービス数(API)が多い2. BigQueryとAWSの混在3.どんどんリリースしたい4.運用・管理を楽にしたい5.インフラコスト削減したい16
GKEでいい感じに作れるのでは?(`・ω・´)17
想定するメリットコスト削減複数サービスをGKEで構築しリソース最適化メンテナンスコストも削減(されるはず)リリースの高速化オーダーメイドから量産体制へterraformk8s可用性も向上全部GCPにできてBigQueryもにっこり(´∀`) 18
移行方針:どうやって移行するか?1.まずはAPI部分(システムの一部)からの移行2.段階的にすべてを移行していくまずはAPI部分からの移行を実施影響範囲を小さくしたいAPIだけなら最悪どうにでもなるもともとのAWSヘの切り戻しも容易機械学習部分をいきなり移行してデグレったら嫌だよね(/・ω・)/汗19
移行後の構成(API部分のみ)20
GKEからCloud SQLに接続Cloud SQL Proxyで別GCPプロジェクトのDBに接続する構成(マイクロサービス的な構成)原理的にPrivate IPで直で接続するより当然遅いCloud SQL Proxyにした場合にどれくらい遅くなるかは簡易的に検証(※当然実環境とは異なるが)medium記事: https://medium.com/google-cloud-jp/eb1fbd049d56github: https://github.com/yukinagae/latency-comparison-of-cloud-sql-connection21
移行後の理想(全部GCP/GKE化)22
今後の移行方針既存サービスのGCP/GKE化まずは今回のプロジェクトで導入実績を作り、運用経験を積む他サービスも徐々に移行していく(※移行すればするほど、インフラ・運用コストを削減できる)新規サービスは最初からGCP/GKEで構築次に発表する katio2さんがそのサービスの話をしてくれると思います(`・ω・´)23
ありがとうございました!(´∀`)24
(おまけ)GKE移行の辛みk8s/GKE周りのノウハウや経験がないので手探りそもそもk8s自体の学習コストが高いk8sの公式ドキュメントそのままだと動かないGKEはだいたいβ版25
(おまけ)GCPでの運用・監視datadogはちょっと辛い既存のAWSシステムではdatadogをdashboardで使ってたが、GCPで使うのは辛いPubSub経由でdatadogにpushする仕組みを毎回作らないといけないGCPプロジェクト毎に認証をしないといけないの大変datadog APMの導入はめちゃくちゃ楽しかし、もちろんcontainer周りの指標しか取得できない26
(おまけ)現状の運用・監視方法Stackdriver Monitoring使う理由datadog用に追加のintegration作業が不要複数プロジェクトを一つのworkspaceにまとめれば、GKEやCloud SQLのプロジェクトが別でも1つのdashboardで監視できるalert policyやヘルスチェックもそのまま作れる(※現状はterraform使わず、あえてGUIで手動作成している。理由としては、監視しながらちょこちょこ値を調整したいから)27
(おまけ)現状の運用・監視方法結論GCPの場合にはStackdriverのみ使うことにしたStackdriver monitoringでの監視alert policyの作成 + slack通知dashboardの作成Stackdriver Traceでのパフォーマンスチェックopencensus入れたStackdriver for pythonはα版。。。(`・ω・´)汗28
おわり29