Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

JapanContainerDays v18.04

Avatar for Shouta Yoshikai

Shouta Yoshikai

April 19, 2018
Tweet

More Decks by Shouta Yoshikai

Other Decks in Technology

Transcript

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

    (開発と運用) ❏ Python, Go, Kubernetes, GCP ❏ コミュニティ活動 ❏ Kubernetes Meetup Tokyo, GCPUG Tokyo ❏ Web連載 ❏ CodeZine Kubernetesによるスケーラブルな Webアプリ環境の構築 ❏ 趣味 ❏ クソアプリ開発, IoT(ロボ作ったり、雨になったら開く紙の傘を作ったり 3
  2. KubernetesのJob • 一度限りの処理を実行させるためコンテナ ◦ 処理が終わるとコンテナが終了する • Kubernetesの標準の機能 • リトライ機能(コンテナ再実行) ◦

    ゼロ以外の終了コード ◦ デフォルトのリトライ上限は6回 ▪ リトライのディレイは10秒, 20秒, 40秒と大きくなる • 上限は6分 標準機能なので使うのが容易だが単純な仕組みしか用意されていない ので、自前で色々と準備する必要があり 11
  3. Jobのみを使う構成ついて • メリット ◦ 構成するコンポーネントの数が少ない。シンプル超いいね ◦ 機能が単純なので理解しやすい • デメリット ◦

    Jobの数が増えると管理するのが大変 ▪ ラベルをつけて管理出来るが数が多いと辛い ◦ 一度に大量のJobを作ると ▪ リソースの上限に達してしまう ▪ Kubernetes apiserver, controller, or schedulerに負荷が かかる 13
  4. 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
  5. メッセージキューイングと組み合わせる メリット • Jobのみ構成の問題解決 ◦ 管理の大変さ、リソース上限、K8SのAPIserverに対する負荷 の軽減 • 並列にタスクを処理できる •

    Podを使える ◦ キャッシュをPodにもたせて処理時間の短縮 ◦ レスポンス性がいい ▪ コンテナ起動時の処理がはいらないので ◦ マシンリソースはJobより使うことに 16
  6. まとめ バッチ処理のパターンを検討する上で • 構成をシンプルに ◦ Jobで要件をみたすか ◦ 構成するコンポーネント数を少なく • 導入コスト、運用コスト

    ◦ クラウドを使うのかミドルウェアをブチ込むのか Jobでのバッチ処理を検討して難しいようであれば、メッセージキューイ ングを使った仕組みを検討する 25
  7. 現構成 29 Client K8S CPU Pod (Worker) HTTP AppEngine &

    TaskQueue HTTP K8S GPU Pod (Worker) Pod (Worker) LB 非同期 同期
  8. 課題点 31 K8S CPU Pod (Worker) HTTP AppEngine & TaskQueue

    K8S GPU Pod (Worker) Pod (Worker) LB 処理終わるまで 繋ぎっぱ タスク処理中とか 知らんがな
  9. 検討したもの • Cloud Pub/Sub ◦ ACK(確認応答)の期限が最大10分 • Cloud Tasks ◦

    アルファーなので本番使うのは無謀 • Redis ◦ シンプルで速いけど必要な機能が足りない • RabbitMQ ◦ 多機能。要件は満たしそう ◦ うさぎ可愛い 35
  10. 新構成 using RabbitMQ 38 Client K8S CPU Pod (Worker) amqp

    Rabbit MQ HTTP K8S GPU Pod (Worker) Pod (Worker) AppEngine (API互換のため)
  11. まとめ • バッチ処理のパターンには大きく2通り ◦ Job ◦ メッセージキューイング • バッチ処理の構成は ◦

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