Google Kubernetes Engine におけるバッチ処理のパターン

Transcript

1. Google Kubernetes Engine における バッチ処理のパターン 株式会社 カブク 吉海 将太

2. 自己紹介 2

3. 自己紹介 吉海 将太 / @yoshikai_ ❏ 株式会社 カブク ❏ サーバーサイドエンドエンジニア

   (開発と運用) ❏ Python, Go, Kubernetes, GCP ❏ コミュニティ活動 ❏ Kubernetes Meetup Tokyo, GCPUG Tokyo ❏ Web連載 ❏ CodeZine Kubernetesによるスケーラブルな Webアプリ環境の構築 ❏ 趣味 ❏ クソアプリ開発, IoT（ロボ作ったり、雨になったら開く紙の傘を作ったり 3

4. 今日のゴール 4

5. 今日のゴール Google Kubernetes Engineにおけるバッチ処理には • どの様なパターンがあるか ◦ K8S Job, メッセージキューイング

   • どの様な構成例があるか ◦ 弊社の構成例をご紹介します 5

6. アジェンダ • バッチ処理の定義 • バッチ処理のパターン紹介 • 弊社の構築例を紹介 6

7. バッチ処理の定義 7

8. バッチ処理の定義 1. 数秒から数時間以上かかる処理 2. 非同期（今回は非同期のバッチ処理を想定しています） 弊社では、時間がかかる3D解析処理をバッチ処理にしています 本講演では、タスクという単語がよく出てきます。 タスクはバッチ処理のことを指します。 8

9. バッチ処理のパターン 9

10. バッチ処理のパターン 大きく分けて2通り • KubernetesのJob • メッセージキューイングの組み合わせる ◦ クラウドのメッセージキューイングサービス ▪ Cloud

    Pub/Sub ◦ ミドルウェア ▪ RabbitMQ 10

11. KubernetesのJob • 一度限りの処理を実行させるためコンテナ ◦ 処理が終わるとコンテナが終了する • Kubernetesの標準の機能 • リトライ機能（コンテナ再実行） ◦

    ゼロ以外の終了コード ◦ デフォルトのリトライ上限は6回 ▪ リトライのディレイは10秒, 20秒, 40秒と大きくなる • 上限は6分 標準機能なので使うのが容易だが単純な仕組みしか用意されていない ので、自前で色々と準備する必要があり 11

12. KubernetesのJobの構成例 12 Client K8S Job K8S API API Server &

    Controller

13. Jobのみを使う構成ついて • メリット ◦ 構成するコンポーネントの数が少ない。シンプル超いいね ◦ 機能が単純なので理解しやすい • デメリット ◦

    Jobの数が増えると管理するのが大変 ▪ ラベルをつけて管理出来るが数が多いと辛い ◦ 一度に大量のJobを作ると ▪ リソースの上限に達してしまう ▪ Kubernetes apiserver, controller, or schedulerに負荷が かかる 13

14. Jobのみを使う構成の問題 公式で紹介されている解決案 https://kubernetes.io/docs/tasks/job/parallel-processing-expansion/ • Parallel Processing using Expansions • Coarse

    Parallel Processing Using a Work Queue ◦ RabbitMQと組み合わせる • Fine Parallel Processing Using a Work Queue ◦ Redisと組み合わせる 14

15. メッセージキューイングと組み 合わせる 15

16. メッセージキューイングと組み合わせる メリット • Jobのみ構成の問題解決 ◦ 管理の大変さ、リソース上限、K8SのAPIserverに対する負荷 の軽減 • 並列にタスクを処理できる •

    Podを使える ◦ キャッシュをPodにもたせて処理時間の短縮 ◦ レスポンス性がいい ▪ コンテナ起動時の処理がはいらないので ◦ マシンリソースはJobより使うことに 16

17. メッセージキューイングの組み合わせる デメリット • 検討すべき点が増える ◦ どのメッセージキューイング使うか ◦ Push式するか、Pull式するか ◦ ネットワーク構成どうする

    • コンポーネントが増える ◦ 運用コストなどが増える ◦ 構成を理解するのに時間がかかる 17

18. クラウドの メッセージキューイング 18

19. クラウドのメッセージキューイング Google Cloud Platform • Cloud Pub/Sub フルマネージドなので、導入コストが低い 負荷の問題も金で解決できる 通信経路が、K8Sのネットワーク外

    19

20. クラウドのメッセージキューイングサービスを使った構 成図 Job 20 Client K8S Job (Worker) K8S API

    Cloud Message Queue Cloud API API Server & Controller

21. クラウドのメッセージキューイングサービスを使った構 成図 Pod Push方式 21 Client K8S Pod (Worker) Cloud

    API Cloud Message Queue Cloud API

22. ミドルウェアの メッセージキューイング 22

23. ミドルウェアの メッセージキューイング K8Sにミドルウェアを動作させる形 • RabbitMQなど 特徴 • 導入、運用コストが高い • 要件にあったミドルウェアを使える

    23

24. Middlewareのメッセージキューイングサービスを 使った構成図 Pod Push方式 24 Client K8S Pod (Worker) Middleware

    API Middleware Message Queue Middleware API

25. まとめ バッチ処理のパターンを検討する上で • 構成をシンプルに ◦ Jobで要件をみたすか ◦ 構成するコンポーネント数を少なく • 導入コスト、運用コスト

    ◦ クラウドを使うのかミドルウェアをブチ込むのか Jobでのバッチ処理を検討して難しいようであれば、メッセージキューイ ングを使った仕組みを検討する 25

26. 弊社の構築例の紹介 26

27. 弊社の構築例の紹介 要件 • タスクのリトライ機能 • 3D解析処理 ◦ 数秒から1時間を超える処理 • GPUとCPUのヘテロ構成

    ◦ GPU ▪ レンダリング ◦ CPU ▪ ポリゴンリダクション 27

28. 注意！！ これから紹介する構成例は 良くない例です 歴史的背景がなー 色々となー 28

29. 現構成 29 Client K8S CPU Pod (Worker) HTTP AppEngine &

    TaskQueue HTTP K8S GPU Pod (Worker) Pod (Worker) LB 非同期 同期

30. 課題 • 長時間のタスクをHTTPで動的に投げているゆえの制約 ◦ 1タスクの最大処理時間が1時間の上限がある ▪ AppEngineのネットワーク制約 ▪ 3D解析処理によっては1時間超えることがある ◦

    処理中のPodにもタスクが振られてしまう場合がある ▪ LoadBalancerで3D解析処理APIにリクエストを飛ばして いるため 30

31. 課題点 31 K8S CPU Pod (Worker) HTTP AppEngine & TaskQueue

    K8S GPU Pod (Worker) Pod (Worker) LB 処理終わるまで 繋ぎっぱ タスク処理中とか 知らんがな

32. そうだ、新しい構成に移行し よう 32

33. 新要件 • HTTPを辞める ◦ 1時間を超えるタスクの処理が出来るように ◦ 空いているPodにタスクを振り分けるように 33

34. いくつか新しい構成を検討し ていくことに 34

35. 検討したもの • Cloud Pub/Sub ◦ ACK(確認応答)の期限が最大10分 • Cloud Tasks ◦

    アルファーなので本番使うのは無謀 • Redis ◦ シンプルで速いけど必要な機能が足りない • RabbitMQ ◦ 多機能。要件は満たしそう ◦ うさぎ可愛い 35

36. あ、RabbitMQだ！ かわいい！！ 36 君に決めた！

37. RabbitMQを使った構成 37

38. 新構成 using RabbitMQ 38 Client K8S CPU Pod (Worker) amqp

    Rabbit MQ HTTP K8S GPU Pod (Worker) Pod (Worker) AppEngine (API互換のため)

39. 新構成 using RabbitMQ • タスクの処理時間の上限の問題の解決 ◦ AMQP • 処理中のPodにもタスクが振られてしまう問題の解決 ◦

    コンシューマーのプリフェッチカウントを1 39

40. まとめ 40

41. まとめ • バッチ処理のパターンには大きく２通り ◦ Job ◦ メッセージキューイング • バッチ処理の構成は ◦

    なるべくシンプルに ◦ コストを考える • 悪い構成は良くしていこうな ◦ なかなか難しい... 41

42. おまけ 42

43. エンジニアを募集してます！！！！ • フロントエンドエンジニア • サーバーサイドエンジニア • 機械学習エンジニア 3名のGoogle Developers Expertsが在籍！！

    3Dプリンター使い放題！！ 43

44. 4月22日の技術書典にサークル参加します！！！ 44