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

Embulk & Digdag Meetup 2020

Trs
July 09, 2020

Embulk & Digdag Meetup 2020

This is a story about running digdag on Kuberentes to create a scalable workflow execution environment

Trs

July 09, 2020
Tweet

More Decks by Trs

Other Decks in Technology

Transcript

  1. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ 
 ZOZO研究所 福岡
 平田 拓也 @TrsNium
 2018年中途入社。ML-SREで機械学習を用いた推論基盤の

    構築やバッチシステムの構築や実装を担当。今はZOZO研 究所 福岡で、アプリケーションの実装や学習基盤のサポー トもやっている。
 2
  2. © ZOZO Technologies, Inc. 3 本日のアジェンダ • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす

    • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ
  3. © ZOZO Technologies, Inc. 4 本日のアジェンダ • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす

    • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ
  4. © ZOZO Technologies, Inc. 5 これまでのワークフローエンジンの問題点 • Cloud Composerを使用 ◦

    Airflowのマネージドサービス メリット • PythonによるDAG定義 • 必要なインフラを自動で構築 (GKE, MySQL, GAE, ...etc.) デメリット • 開発効率が悪い • Workerのレプリカが固定 • 不安定な挙動が所々ある
  5. © ZOZO Technologies, Inc. 6 開発効率が悪い • ローカルで実行環境を整えるのが面倒 • Cloud

    Composer上で動作確認をするのに時間がかかる ◦ タスクの切れ間に30秒程度の空白ができる ▪ スケジューラーがWorkerにタスクを割り当てているため • タスクがAirflow側の問題で失敗してリトライが走り時間がかかる
  6. © ZOZO Technologies, Inc. 7 Workerのレプリカが固定 タスク実行時 Task1 worker1 worker2

    Task2 Task3 worker3 Task7 Task6 Task5 Task4 Task Queue アイドル時 worker1 worker2 worker3 Task Queue
  7. © ZOZO Technologies, Inc. 8 Workerのレプリカが固定 アイドル時 worker1 worker2 worker3

    Task Queue 問題点 • アイドル時でも複数のWorker(Cloud Composerでは最低3台は必 要)なため、その分のインスタンス料金がかかってしまう。
  8. © ZOZO Technologies, Inc. 9 不安定な挙動が所々ある • タスクのログが表示されない • MySQLのデッドロックエラーが表示される(airflow

    v0.10.8でfix) • タスクの実行ステートが成功になっているが、実行されていない • タスクが成功/失敗したら任意の関数をhookされるようになっているが、hookさ れていないことがある などなど (´·ω·`)
  9. © ZOZO Technologies, Inc. 10 ワークフローエンジンの理想系 • 高い開発効率 • スケーラビリティがある

    • 安定している Task1 worker1 Task4 worker4 Task4 Task3 Task2 Task1 自動スケール Task Queue
  10. © ZOZO Technologies, Inc. 11 Digdagでワークフローエンジンの   理想系を考える • 高い開発効率 →

    ローカルで開発する仕組みが既にあったりパフォーマンス等も良い • スケーラビリティがある→ Kubernetes上で運用すればできそう • 安定している → 社内での運用実績と最悪パッチを投げれば良い
  11. © ZOZO Technologies, Inc. 12 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす •

    Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
  12. © ZOZO Technologies, Inc. 13 DigdagをKubernetes(GKE)上で スケーラブルに動かす やること • Digdagサーバーを機能ごとに分けて動かす

    • スケールするインフラ構成を組む • Kubernetesの水平スケーラー(HPA)の問題と解決
  13. © ZOZO Technologies, Inc. 14 Digdagサーバーを機能ごとに分けて動かす • Web‥WebUIの提供/Digdagクライアントからのリクエスト処理 --disable-local-agent, --disable-scheduler,

    --disable-executor-loop • Scheduler‥‥タスクの定期スケジューリングのみをするだけ --disable-local-agent, --disable-executor-loop • Worker‥‥タスクの実行をするだけ --disable-scheduler
  14. © ZOZO Technologies, Inc. 15 Digdagサーバーを機能ごとに分けて動かす目的 • 機能ごとの責務を分けるため ◦ 障害の切り分けのしやすさ

    • コンピュートリソースの最適化 • 機能ごとに水平スケールするためのパラメータが違うため ◦ WebはLBのリクエストカウント/CPU・Memoryの使用率 ◦ WorkerはPostgreSQLのTask Queueベース
  15. © ZOZO Technologies, Inc. 16 インフラ構成 Virtual Private Cloud Identity-Aware

    Proxy Cloud Load Balancing Cloud SQL(PostgreSQL) Kubernetes Engine Container Registry Digdag Worker Pool Digdag Scheduler Pool Digdag Web Pool Kube-System Pool HTTPS HTTPS HTTP
  16. © ZOZO Technologies, Inc. Virtual Private Cloud 17 Kubernetesの構成 Digdag

    Worker Pod0 Digdag Scheduler Pod0 Digdag Scheduler Pod1 Digdag web Pod0 Digdag web Pod1 Digdag Worker Pod1 ReplicationController/Deployment HorizontalPodAutoscaler ReplicationController/Deployment HorizontalPodAutoscaler ReplicationController/Deployment HorizontalPodAutoscaler Service Ingress
  17. © ZOZO Technologies, Inc. 18 Kubernetesの水平スケーラー(HPA)の問題 • workerのスケールインをWorkerがタスクを実行しているかを加味して行ってくれない ◦ 他のWorkerでリトライが走り、そのタスクを始めからやり直してしまう

    • 1workerに割り当てられるタスク数(max_task_threads)を考慮することができない ◦ 過剰なスケールアウトでWorkerがタスクを処理せずに遊んでいる ◦ スケールアウトして実行したいタスクが余っている 独自の水平スケーラー(カスタムコントローラ)を作ることに
  18. © ZOZO Technologies, Inc. 19 Kubernetesのカスタムリソース/コントローラ カスタムリソース • Kubernetes APIやKubernetesクラスタを拡張できる

    例) VirtualService, Gateway(istio) • CRD(CustomResourceDefinition)を使ってカスタムリソースオブジェクトの構造を定 義できる カスタムコントローラー • ユーザーが作成したカスタムリソースオブジェクトを元に、それをあるべき状態とし維 持管理に務める
  19. © ZOZO Technologies, Inc. 20 独自の水平スケーラーを作り問題を解決する • 1Workerに割り当てられるタスク数 (max_task_threads)とタスクキューを 考慮しスケールアウトできるようになっ

    た • タスクキューが空になったらスケール インをするようにし、タスクが途中で失 敗することを防いだ GitHub(https://github.com/TrsNium/digdag-worke r-crd)に公開しています apiVersion: horizontalpodautoscalers.autoscaling.digdag-worker-crd/v1 kind: HorizontalDigdagWorkerAutoscaler metadata: name: horizontaldigdagworkerautoscaler spec: deployment: name: digdag-worker namespace: default maxTaskThreads: 6 postgresql: host: value: <YOUR_POSTGRESQL_HOST> port: value: "5432" database: value: digdag user: value: hpa password: valueFromSecretKeyRef: name: postgres namespace: default key: password
  20. © ZOZO Technologies, Inc. 21 独自の水平スケーラーを作り問題を解決する • 1Workerに割り当てられるタスク数 (max_task_threads)とタスクキューを 考慮しスケールアウトできるようになっ

    た • タスクキューが空になったらスケール インをするようにし、タスクが途中で失 敗することを防いだ GitHub(https://github.com/TrsNium/digdag-worke r-crd)に公開しています apiVersion: horizontalpodautoscalers.autoscaling.digdag-worker-crd/v1 kind: HorizontalDigdagWorkerAutoscaler metadata: name: horizontaldigdagworkerautoscaler spec: deployment: name: digdag-worker namespace: default maxTaskThreads: 6 postgresql: host: value: <YOUR_POSTGRESQL_HOST> port: value: "5432" database: value: digdag user: value: hpa password: valueFromSecretKeyRef: name: postgres namespace: default key: password Taskを実行していないWorkerを即座にkillすれば良いのでは?
  21. © ZOZO Technologies, Inc. 22 独自の水平スケーラーで解決できなかったこと • タスクキューが空にならない限りスケールインすることができない ◦ タスクを実行せずに遊んでいるWorkerが発生する可能性がある

    → DeploymentのReplicaControllerでは特定のPod(タスクを実行していない) のみをスケールインする仕組みを作れない 解決策: • Custom Deploymentのようなものを作り、タスク実行していないPodのみを狙い 撃ちでスケールインする仕組みを作るしかない
  22. © ZOZO Technologies, Inc. 23 修正後のKubernetesの構成 Virtual Private Cloud Digdag

    Worker Pod0 Digdag Scheduler Pod0 Digdag Scheduler Pod1 Digdag web Pod0 Digdag web Pod1 Digdag Worker Pod1 ReplicationController/Deployment HorizontalPodAutoscaler ReplicationController/Deployment DigdagWorkerHorizontalPodAutoscaler (Controller) ReplicationController/Deployment HorizontalPodAutoscaler Service Ingress CustomResourceDefinition
  23. © ZOZO Technologies, Inc. 24 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす •

    Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
  24. © ZOZO Technologies, Inc. 25 「KubernetesCommandExecutor」とは • v0.10で追加される予定の新しいCommandExecutor ◦ 対応するオペレータは、ShOperator,

    RbOperator, PyOperator • Kubernetes上でPodとしてTaskを実行する ◦ 既にあるSimpleCommandExecutorやDockerCommandExecutorと違い、 Workerでタスクを実行しない worker Task Task Kubernetes
  25. © ZOZO Technologies, Inc. 26 「KubernetesCommandExecutor」の仕組み ───────┬──────────── │ File: test.dig

    ───────┼──────────── 1 │ _export: 2 │ docker: 3 │ image: ubuntu:latest 4 │ 5 │ +echo: 6 │ sh>: echo hello world ───────┴──────────── Storage Image: ubuntu:latest commands: [/bin/bash] args: - mkdir -p /tmp/digdag-tempdir6427047 971659898370/workspace/1 _scoring_16_890_902452901 2354517251; cd /tmp/digdag-tempdir6427047 971659898370/workspace/1 _scoring_16_890_902452901 2354517251; ….(略 ⑴ ア ー カ イ ブ の 作 成 /ア ップ ロ ー ド (署 名 付 き URLを 取 得 ) ⑵podの作成 ⑶ (署 名 つ き URLで ) ア ー カ イ ブ の ダ ウ ン ロ ー ド ⑷podのstatusを監視 ⑹ (署 名 つ き URLで )タス ク の 実 行 結 果 の ア ー カ イ ブ を ダ ウ ン ロ ー ド ⑸ (署 名 つ き URLで )タ ス ク の 実 行 結 果 の ア ー カ イ ブ を 作 成 /ア ップ ロ ー ド
  26. © ZOZO Technologies, Inc. 27 • KubernetesCommandExecutorで実行するタスクの処理負荷をWorkerが気 にしなくてよくなる ◦ WorkerはPodを監視しているだけなのでタスクの処理負荷の大小に関係な

    くWorkerの負荷は一定になる ▪ タスクの処理負荷によるWorkerインスタンスの調整をしなくてよくなる ◦ タスクの処理負荷(resources request/limit)によるノードの割り当ては Kubernetesが全部やってくれる 「KubernetesCommandExecutor」で期待でき ること
  27. © ZOZO Technologies, Inc. 28 「KubernetesCommandExecutor」と GKEの自動プロビジョニングで柔軟に Cloud SQL Virtual

    Private Cloud Kubernetes Engine Auto Provisioning Pool 1 (n1-standard-1) Auto Provisioning Pool 2 (n1-standard-2) Auto Provisioning Pool N (リソース要件にあったインスタンス) Node Auto Provisioning • Podにresources request/limitを設定すると、 それを検知して自動でノードプールがプロビ ジョニングされるGKEの機能 KubernetesCommandExecutorでPod発行時に resources request/litmitを指定してあげれば、 Kuberentesのインフラへの変更なしで様々な負 荷のタスクを実行できる
  28. © ZOZO Technologies, Inc. 29 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす •

    Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
  29. © ZOZO Technologies, Inc. 30 GKE上で「KuberentesCommandExecutorなど」 を動かすためにやったこと • GCPで動かすために必要なものは何か洗い出しPRにする ◦

    Storage typeにGCSがない... • 「KubernetesCommandExecutor」はコードを頼りに仕様を把握する ◦ v0.10に関するドキュメントが殆どないため • 「KubernetesCommandExecutor」周りで欲しい機能を探しPRにする ◦ Resources request/limitnの指定, NodeAffinityなど
  30. © ZOZO Technologies, Inc. 31 送ったPR • StorageにGCSをサポート • KubeConfigからもk8sの認証情報を読み込めるように

    • RequestConfigからもk8sの設定を読めるように(ZOZO研究所 福岡 shikajiroさ ん) ◦ get k8s config from requestConfig. and added test. #1279 • k8sのresources request/limitなどのpodの設定, pv, pvcリソースのサポート ◦ Support new kubernetes podspec resource and pv pvc resource type #1265 • KubernetesCommandExecutorのバグ修正 ◦ Fix KubernetesCommandExecutor's bash arguments #1340 ◦ Fix KubernetesCommandEexecutor part of wait for starting container. #1348 ◦ Fix KubernetesCommandExecutor for throw an exception if pod exceeds expire of TemporalConfigStorage. #1359
  31. © ZOZO Technologies, Inc. 32 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす •

    Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutor」を動かすためにやったこと • まとめ 本日のアジェンダ
  32. © ZOZO Technologies, Inc. 34 ✅高い開発効率 もともとDigdagはよくできていた(意訳: 特に何もしていない) • digdag

    run によるローカル環境での動作確認 • タスク実行のパフォーマンスが高い
  33. © ZOZO Technologies, Inc. 35 ✅スケーラビリティがある GKE上でホストしてあげることで、スケーラビリティを確保 • 独自の水平スケーラを作ることでWorkerを安全にスケールアウト/インできるよう に

    ◦ ワークフローが終わらないとスケールインできないため改善の余地あり • 「KubernetesCommandExecutor」とGKEの自動プロビジョニングでインフラの 面倒を見る手間を省くことができる