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

by Shouta Yoshikai

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

自己紹介吉海将太 / @yoshikai_ ❏ 株式会社カブク ❏ サーバーサイドエンドエンジニア (開発と運用) ❏ Python, Go, Kubernetes, GCP ❏ コミュニティ活動 ❏ Kubernetes Meetup Tokyo, GCPUG Tokyo ❏ Web連載 ❏ CodeZine Kubernetesによるスケーラブルな Webアプリ環境の構築 ❏ 趣味 ❏ クソアプリ開発, IoT（ロボ作ったり、雨になったら開く紙の傘を作ったり 3

Slide 4

Slide 4 text

今日のゴール 4

Slide 5

Slide 5 text

今日のゴール Google Kubernetes Engineにおけるバッチ処理には ● どの様なパターンがあるか ○ K8S Job, メッセージキューイング ● どの様な構成例があるか ○ 弊社の構成例をご紹介します 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

バッチ処理の定義 7

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

バッチ処理のパターン 9

Slide 10

Slide 10 text

バッチ処理のパターン大きく分けて2通り ● KubernetesのJob ● メッセージキューイングの組み合わせる ○ クラウドのメッセージキューイングサービス ■ Cloud Pub/Sub ○ ミドルウェア ■ RabbitMQ 10

Slide 11

Slide 11 text

KubernetesのJob ● 一度限りの処理を実行させるためコンテナ ○ 処理が終わるとコンテナが終了する ● Kubernetesの標準の機能 ● リトライ機能（コンテナ再実行） ○ ゼロ以外の終了コード ○ デフォルトのリトライ上限は6回 ■ リトライのディレイは10秒, 20秒, 40秒と大きくなる ● 上限は6分標準機能なので使うのが容易だが単純な仕組みしか用意されていないので、自前で色々と準備する必要があり 11

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Jobのみを使う構成ついて ● メリット ○ 構成するコンポーネントの数が少ない。シンプル超いいね ○ 機能が単純なので理解しやすい ● デメリット ○ Jobの数が増えると管理するのが大変 ■ ラベルをつけて管理出来るが数が多いと辛い ○ 一度に大量のJobを作ると ■ リソースの上限に達してしまう ■ Kubernetes apiserver, controller, or schedulerに負荷がかかる 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

メッセージキューイングと組み合わせるメリット ● Jobのみ構成の問題解決 ○ 管理の大変さ、リソース上限、K8SのAPIserverに対する負荷の軽減 ● 並列にタスクを処理できる ● Podを使える ○ キャッシュをPodにもたせて処理時間の短縮 ○ レスポンス性がいい ■ コンテナ起動時の処理がはいらないので ○ マシンリソースはJobより使うことに 16

Slide 17

Slide 17 text

メッセージキューイングの組み合わせるデメリット ● 検討すべき点が増える ○ どのメッセージキューイング使うか ○ Push式するか、Pull式するか ○ ネットワーク構成どうする ● コンポーネントが増える ○ 運用コストなどが増える ○ 構成を理解するのに時間がかかる 17

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

まとめバッチ処理のパターンを検討する上で ● 構成をシンプルに ○ Jobで要件をみたすか ○ 構成するコンポーネント数を少なく ● 導入コスト、運用コスト ○ クラウドを使うのかミドルウェアをブチ込むのか Jobでのバッチ処理を検討して難しいようであれば、メッセージキューイングを使った仕組みを検討する 25

Slide 26

Slide 26 text

弊社の構築例の紹介 26

Slide 27

Slide 27 text

弊社の構築例の紹介要件 ● タスクのリトライ機能 ● 3D解析処理 ○ 数秒から1時間を超える処理 ● GPUとCPUのヘテロ構成 ○ GPU ■ レンダリング ○ CPU ■ ポリゴンリダクション 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

現構成 29 Client K8S CPU Pod (Worker) HTTP AppEngine & TaskQueue HTTP K8S GPU Pod (Worker) Pod (Worker) LB 非同期同期

Slide 30

Slide 30 text

課題 ● 長時間のタスクをHTTPで動的に投げているゆえの制約 ○ 1タスクの最大処理時間が1時間の上限がある ■ AppEngineのネットワーク制約 ■ 3D解析処理によっては1時間超えることがある ○ 処理中のPodにもタスクが振られてしまう場合がある ■ LoadBalancerで3D解析処理APIにリクエストを飛ばしているため 30

Slide 31

Slide 31 text

課題点 31 K8S CPU Pod (Worker) HTTP AppEngine & TaskQueue K8S GPU Pod (Worker) Pod (Worker) LB 処理終わるまで繋ぎっぱタスク処理中とか知らんがな

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

検討したもの ● Cloud Pub/Sub ○ ACK(確認応答)の期限が最大10分 ● Cloud Tasks ○ アルファーなので本番使うのは無謀 ● Redis ○ シンプルで速いけど必要な機能が足りない ● RabbitMQ ○ 多機能。要件は満たしそう ○ うさぎ可愛い 35

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

RabbitMQを使った構成 37

Slide 38

Slide 38 text

新構成 using RabbitMQ 38 Client K8S CPU Pod (Worker) amqp Rabbit MQ HTTP K8S GPU Pod (Worker) Pod (Worker) AppEngine (API互換のため)

Slide 39

Slide 39 text

新構成 using RabbitMQ ● タスクの処理時間の上限の問題の解決 ○ AMQP ● 処理中のPodにもタスクが振られてしまう問題の解決 ○ コンシューマーのプリフェッチカウントを1 39

Slide 40

Slide 40 text

まとめ 40

Slide 41

Slide 41 text

まとめ ● バッチ処理のパターンには大きく２通り ○ Job ○ メッセージキューイング ● バッチ処理の構成は ○ なるべくシンプルに ○ コストを考える ● 悪い構成は良くしていこうな ○ なかなか難しい... 41

Slide 42

Slide 42 text

おまけ 42

Slide 43

Slide 43 text

エンジニアを募集してます！！！！ ● フロントエンドエンジニア ● サーバーサイドエンジニア ● 機械学習エンジニア 3名のGoogle Developers Expertsが在籍！！ 3Dプリンター使い放題！！ 43

Slide 44

Slide 44 text

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