Embulk & Digdag Meetup 2020

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

Transcript

1. スケーラブルな
 ワークフロー実行環境を目指して
 株式会社ZOZOテクノロジーズ
 ZOZO研究所　福岡
 平田　拓也 Copyright © ZOZO Technologies, Inc.
2. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ 
 ZOZO研究所　福岡
 平田　拓也 @TrsNium
 2018年中途入社。ML-SREで機械学習を用いた推論基盤の 構築やバッチシステムの構築や実装を担当。今はZOZO研 究所 福岡で、アプリケーションの実装や学習基盤のサポー トもやっている。
 2
3. © ZOZO Technologies, Inc. 3 本日のアジェンダ • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ
4. © ZOZO Technologies, Inc. 4 本日のアジェンダ • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ
5. © ZOZO Technologies, Inc. 5 これまでのワークフローエンジンの問題点 • Cloud Composerを使用 ◦ Airflowのマネージドサービス メリット • PythonによるDAG定義 • 必要なインフラを自動で構築 (GKE, MySQL, GAE, ...etc.) デメリット • 開発効率が悪い • Workerのレプリカが固定 • 不安定な挙動が所々ある
6. © ZOZO Technologies, Inc. 6 開発効率が悪い • ローカルで実行環境を整えるのが面倒 • Cloud Composer上で動作確認をするのに時間がかかる ◦ タスクの切れ間に30秒程度の空白ができる ▪ スケジューラーがWorkerにタスクを割り当てているため • タスクがAirflow側の問題で失敗してリトライが走り時間がかかる
7. © ZOZO Technologies, Inc. 7 Workerのレプリカが固定 タスク実行時 Task1 worker1 worker2 Task2 Task3 worker3 Task7 Task6 Task5 Task4 Task Queue アイドル時 worker1 worker2 worker3 Task Queue
8. © ZOZO Technologies, Inc. 8 Workerのレプリカが固定 アイドル時 worker1 worker2 worker3 Task Queue 問題点 • アイドル時でも複数のWorker(Cloud Composerでは最低3台は必 要)なため、その分のインスタンス料金がかかってしまう。
9. © ZOZO Technologies, Inc. 9 不安定な挙動が所々ある • タスクのログが表示されない • MySQLのデッドロックエラーが表示される(airflow v0.10.8でfix) • タスクの実行ステートが成功になっているが、実行されていない • タスクが成功/失敗したら任意の関数をhookされるようになっているが、hookさ れていないことがある などなど (´·ω·`)
10. © ZOZO Technologies, Inc. 10 ワークフローエンジンの理想系 • 高い開発効率 • スケーラビリティがある • 安定している Task1 worker1 Task4 worker4 Task4 Task3 Task2 Task1 自動スケール Task Queue
11. © ZOZO Technologies, Inc. 11 Digdagでワークフローエンジンの 　　理想系を考える • 高い開発効率 → ローカルで開発する仕組みが既にあったりパフォーマンス等も良い • スケーラビリティがある→ Kubernetes上で運用すればできそう • 安定している → 社内での運用実績と最悪パッチを投げれば良い
12. © ZOZO Technologies, Inc. 12 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
13. © ZOZO Technologies, Inc. 13 DigdagをKubernetes(GKE)上で スケーラブルに動かす やること • Digdagサーバーを機能ごとに分けて動かす • スケールするインフラ構成を組む • Kubernetesの水平スケーラー(HPA)の問題と解決
14. © 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
15. © ZOZO Technologies, Inc. 15 Digdagサーバーを機能ごとに分けて動かす目的 • 機能ごとの責務を分けるため ◦ 障害の切り分けのしやすさ • コンピュートリソースの最適化 • 機能ごとに水平スケールするためのパラメータが違うため ◦ WebはLBのリクエストカウント/CPU・Memoryの使用率 ◦ WorkerはPostgreSQLのTask Queueベース
16. © 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
17. © 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
18. © ZOZO Technologies, Inc. 18 Kubernetesの水平スケーラー(HPA)の問題 • workerのスケールインをWorkerがタスクを実行しているかを加味して行ってくれない ◦ 他のWorkerでリトライが走り、そのタスクを始めからやり直してしまう • 1workerに割り当てられるタスク数(max_task_threads)を考慮することができない ◦ 過剰なスケールアウトでWorkerがタスクを処理せずに遊んでいる ◦ スケールアウトして実行したいタスクが余っている 独自の水平スケーラー(カスタムコントローラ)を作ることに
19. © ZOZO Technologies, Inc. 19 Kubernetesのカスタムリソース/コントローラ カスタムリソース • Kubernetes APIやKubernetesクラスタを拡張できる 例) VirtualService, Gateway(istio) • CRD(CustomResourceDefinition)を使ってカスタムリソースオブジェクトの構造を定 義できる カスタムコントローラー • ユーザーが作成したカスタムリソースオブジェクトを元に、それをあるべき状態とし維 持管理に務める
20. © 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
21. © 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すれば良いのでは?
22. © ZOZO Technologies, Inc. 22 独自の水平スケーラーで解決できなかったこと • タスクキューが空にならない限りスケールインすることができない ◦ タスクを実行せずに遊んでいるWorkerが発生する可能性がある → DeploymentのReplicaControllerでは特定のPod(タスクを実行していない) のみをスケールインする仕組みを作れない 解決策: • Custom Deploymentのようなものを作り、タスク実行していないPodのみを狙い 撃ちでスケールインする仕組みを作るしかない
23. © 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
24. © ZOZO Technologies, Inc. 24 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
25. © ZOZO Technologies, Inc. 25 「KubernetesCommandExecutor」とは • v0.10で追加される予定の新しいCommandExecutor ◦ 対応するオペレータは、ShOperator, RbOperator, PyOperator • Kubernetes上でPodとしてTaskを実行する ◦ 既にあるSimpleCommandExecutorやDockerCommandExecutorと違い、 Workerでタスクを実行しない worker Task Task Kubernetes
26. © 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で )タ ス ク の 実 行 結 果 の ア ー カ イ ブ を 作 成 /ア ップ ロ ー ド
27. © ZOZO Technologies, Inc. 27 • KubernetesCommandExecutorで実行するタスクの処理負荷をWorkerが気 にしなくてよくなる ◦ WorkerはPodを監視しているだけなのでタスクの処理負荷の大小に関係な くWorkerの負荷は一定になる ▪ タスクの処理負荷によるWorkerインスタンスの調整をしなくてよくなる ◦ タスクの処理負荷(resources request/limit)によるノードの割り当ては Kubernetesが全部やってくれる 「KubernetesCommandExecutor」で期待でき ること
28. © 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のインフラへの変更なしで様々な負 荷のタスクを実行できる
29. © ZOZO Technologies, Inc. 29 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutorなど」を動かすためにやったこと • まとめ 本日のアジェンダ
30. © ZOZO Technologies, Inc. 30 GKE上で「KuberentesCommandExecutorなど」 を動かすためにやったこと • GCPで動かすために必要なものは何か洗い出しPRにする ◦ Storage typeにGCSがない... • 「KubernetesCommandExecutor」はコードを頼りに仕様を把握する ◦ v0.10に関するドキュメントが殆どないため • 「KubernetesCommandExecutor」周りで欲しい機能を探しPRにする ◦ Resources request/limitnの指定, NodeAffinityなど
31. © 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
32. © ZOZO Technologies, Inc. 32 • これまでのワークフローエンジンの問題点 • DigdagをKubernetes(GKE)上でスケーラブルに動かす • Digdag v0.10の機能「KubernetesCommandExecutor」でより柔軟に • 「KubernetesCommandExecutor」を動かすためにやったこと • まとめ 本日のアジェンダ
33. © ZOZO Technologies, Inc. 33 まとめ ✅ 高い開発効率 ✅ スケーラビリティーがある ✅ 安定している
34. © ZOZO Technologies, Inc. 34 ✅高い開発効率 もともとDigdagはよくできていた（意訳: 特に何もしていない） • digdag run によるローカル環境での動作確認 • タスク実行のパフォーマンスが高い
35. © ZOZO Technologies, Inc. 35 ✅スケーラビリティがある GKE上でホストしてあげることで、スケーラビリティを確保 • 独自の水平スケーラを作ることでWorkerを安全にスケールアウト/インできるよう に ◦ ワークフローが終わらないとスケールインできないため改善の余地あり • 「KubernetesCommandExecutor」とGKEの自動プロビジョニングでインフラの 面倒を見る手間を省くことができる
36. © ZOZO Technologies, Inc. 36 ✅安定している 2020年3月あたりから運用し始めて特に何も問題なく稼働している • 始めはエラーなどで出て安定していなかったが、パッチを送って安定させた ◦ 即座にパッチを適用できるのがOSSをセルフホストする強みだと改めて感じた