GKE上でのMLバッチ運用のコツ エムスリー 株式会社 北川亮(@kitagry) #kyototechtalk

自己紹介 Vim, Go, k8sが好き 新卒4年目で現在AI・機械学習チームのチーム リーダー 今年の４月から京都オフィス所属になりました。エ ンジニア所属２人なので仲間が欲しい！！

現在のチームの特徴 ● チームで管理しているほぼすべてのバッチ・APIがGKE上で動いている ● チームで定期実行しているバッチは300個ほど ● バッチには数分で終わる小規模なものから数日かかる大規模なものまである

GKEで出てくる単語をおさらい ● Pod ○ コンテナのグループを表す 
 ○ docker-composeくらいの認識で良いと思う 
 ● Node
 ○ VMまたは物理マシンを表す 
 ○ GCPならGCE・AWSならEC2・お家なら Raspberry Pi
 ● Node Pool
 ○ Nodeのグループ
 ○ 利用状況に応じてスケールイン・スケールア ウトを行う


Node Poolのありがたさ ● Nodeのリソースが余っていると適切に 分配してNode数を減らしてくれる ● Node課金の場合切り詰めて使ってく れると節約になってありがたい ● ありがとうKubernetes kubernetes/autoscalerのコードにはNodeの料金を計算してやすいものを 選択してくれるソースがあります https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscal er/cloudprovider/gce/gce_price_model.go

この機能MLバッチでは致命的 半日かけて学習した内容がEvictionととも に破壊されてしまう。。。

この機能MLバッチでは致命的 半日かけて学習した内容がEvictionととも に破壊されてしまう。。。 MLバッチはある意味ではステートフル

safe-to-evictionという機能 ● evictionを制限するための機能 リソースにアノテーションをつけるだけで簡 単に設定可

safe-to-evictionという機能 ● evictionを制限するための機能 リソースにアノテーションをつけるだけで簡 単に設定可 やったか！？

safe-to-evictionの落とし穴 巨大なPodが動いているNodeに小さなPod が迷い込んできます。 Node Pool 巨大Node 巨大Pod 小さいPodが 迷い込む

safe-to-evictionの落とし穴 巨大なPodが正常に終了します。 このNode消して小さいNodeに移動してほ しいですよね？ Node Pool 巨大Node

safe-to-evictionの落とし穴 小さなPodはsafe-to-evicitionのため、どい てくれません。 Node Pool 巨大Node Node だが断る 無事にクラウド破産 ＼(^o^)／

Podごとに使って良いNodeを決めることに。。 ● 大きなPodは大きいNodeへ ● 小さなPodは小さなNodeへ エンジニア側がある程度メモリどれくらい使 うかは与えないといけない。。 えーあいってやつでなんとかしたい。。。

この先の話はブログで！(10分短い) https://www.m3tech.blog/entry/ai-gke-ml-batch

まとめ ● MLバッチは実はステートフル ● ステートフルなシステムの運用は本質的に難しい ● Kubernetesの特殊な使い方を出来る環境はとても楽しい