スケーラブルな
 ワークフロー実行環境を目指して
 株式会社ZOZOテクノロジーズ
 ZOZO研究所　福岡
 平田　拓也 Copyright © ZOZO Technologies, Inc.

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ 
 ZOZO研究所　福岡
 平田　拓也 @TrsNium
 2018年中途入社。ML-SREで機械学習を用いた推論基盤の 構築やバッチシステムの構築や実装を担当。今はZOZO研 究所 福岡で、アプリケーションの実装や学習基盤のサポー トもやっている。
 2

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

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

© ZOZO Technologies, Inc. 5 これまでのワークフローエンジンの問題点 ● Cloud Composerを使用 ○ Airflowのマネージドサービス メリット ● PythonによるDAG定義 ● 必要なインフラを自動で構築 (GKE, MySQL, GAE, ...etc.) デメリット ● 開発効率が悪い ● Workerのレプリカが固定 ● 不安定な挙動が所々ある

© ZOZO Technologies, Inc. 6 開発効率が悪い ● ローカルで実行環境を整えるのが面倒 ● Cloud Composer上で動作確認をするのに時間がかかる ○ タスクの切れ間に30秒程度の空白ができる ■ スケジューラーがWorkerにタスクを割り当てているため ● タスクがAirflow側の問題で失敗してリトライが走り時間がかかる

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

© ZOZO Technologies, Inc. 8 Workerのレプリカが固定 アイドル時 worker1 worker2 worker3 Task Queue 問題点 ● アイドル時でも複数のWorker(Cloud Composerでは最低3台は必 要)なため、その分のインスタンス料金がかかってしまう。

© ZOZO Technologies, Inc. 9 不安定な挙動が所々ある ● タスクのログが表示されない ● MySQLのデッドロックエラーが表示される(airflow v0.10.8でfix) ● タスクの実行ステートが成功になっているが、実行されていない ● タスクが成功/失敗したら任意の関数をhookされるようになっているが、hookさ れていないことがある などなど (´·ω·`)

© ZOZO Technologies, Inc. 10 ワークフローエンジンの理想系 ● 高い開発効率 ● スケーラビリティがある ● 安定している Task1 worker1 Task4 worker4 Task4 Task3 Task2 Task1 自動スケール Task Queue

© ZOZO Technologies, Inc. 11 Digdagでワークフローエンジンの 　　理想系を考える ● 高い開発効率 → ローカルで開発する仕組みが既にあったりパフォーマンス等も良い ● スケーラビリティがある→ Kubernetes上で運用すればできそう ● 安定している → 社内での運用実績と最悪パッチを投げれば良い

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

© ZOZO Technologies, Inc. 13 DigdagをKubernetes(GKE)上で スケーラブルに動かす やること ● Digdagサーバーを機能ごとに分けて動かす ● スケールするインフラ構成を組む ● Kubernetesの水平スケーラー(HPA)の問題と解決

© 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

© ZOZO Technologies, Inc. 15 Digdagサーバーを機能ごとに分けて動かす目的 ● 機能ごとの責務を分けるため ○ 障害の切り分けのしやすさ ● コンピュートリソースの最適化 ● 機能ごとに水平スケールするためのパラメータが違うため ○ WebはLBのリクエストカウント/CPU・Memoryの使用率 ○ WorkerはPostgreSQLのTask Queueベース

© 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

© 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

© ZOZO Technologies, Inc. 18 Kubernetesの水平スケーラー(HPA)の問題 ● workerのスケールインをWorkerがタスクを実行しているかを加味して行ってくれない ○ 他のWorkerでリトライが走り、そのタスクを始めからやり直してしまう ● 1workerに割り当てられるタスク数(max_task_threads)を考慮することができない ○ 過剰なスケールアウトでWorkerがタスクを処理せずに遊んでいる ○ スケールアウトして実行したいタスクが余っている 独自の水平スケーラー(カスタムコントローラ)を作ることに

© ZOZO Technologies, Inc. 19 Kubernetesのカスタムリソース/コントローラ カスタムリソース ● Kubernetes APIやKubernetesクラスタを拡張できる 例) VirtualService, Gateway(istio) ● CRD(CustomResourceDefinition)を使ってカスタムリソースオブジェクトの構造を定 義できる カスタムコントローラー ● ユーザーが作成したカスタムリソースオブジェクトを元に、それをあるべき状態とし維 持管理に務める

© 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: port: value: "5432" database: value: digdag user: value: hpa password: valueFromSecretKeyRef: name: postgres namespace: default key: password

© 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: port: value: "5432" database: value: digdag user: value: hpa password: valueFromSecretKeyRef: name: postgres namespace: default key: password Taskを実行していないWorkerを即座にkillすれば良いのでは?

© ZOZO Technologies, Inc. 22 独自の水平スケーラーで解決できなかったこと ● タスクキューが空にならない限りスケールインすることができない ○ タスクを実行せずに遊んでいるWorkerが発生する可能性がある → DeploymentのReplicaControllerでは特定のPod(タスクを実行していない) のみをスケールインする仕組みを作れない 解決策: ● Custom Deploymentのようなものを作り、タスク実行していないPodのみを狙い 撃ちでスケールインする仕組みを作るしかない

© 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

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

© ZOZO Technologies, Inc. 25 「KubernetesCommandExecutor」とは ● v0.10で追加される予定の新しいCommandExecutor ○ 対応するオペレータは、ShOperator, RbOperator, PyOperator ● Kubernetes上でPodとしてTaskを実行する ○ 既にあるSimpleCommandExecutorやDockerCommandExecutorと違い、 Workerでタスクを実行しない worker Task Task Kubernetes

© 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で )タ ス ク の 実 行 結 果 の ア ー カ イ ブ を 作 成 /ア ップ ロ ー ド

© ZOZO Technologies, Inc. 27 ● KubernetesCommandExecutorで実行するタスクの処理負荷をWorkerが気 にしなくてよくなる ○ WorkerはPodを監視しているだけなのでタスクの処理負荷の大小に関係な くWorkerの負荷は一定になる ■ タスクの処理負荷によるWorkerインスタンスの調整をしなくてよくなる ○ タスクの処理負荷(resources request/limit)によるノードの割り当ては Kubernetesが全部やってくれる 「KubernetesCommandExecutor」で期待でき ること

© 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のインフラへの変更なしで様々な負 荷のタスクを実行できる

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

© ZOZO Technologies, Inc. 30 GKE上で「KuberentesCommandExecutorなど」 を動かすためにやったこと ● GCPで動かすために必要なものは何か洗い出しPRにする ○ Storage typeにGCSがない... ● 「KubernetesCommandExecutor」はコードを頼りに仕様を把握する ○ v0.10に関するドキュメントが殆どないため ● 「KubernetesCommandExecutor」周りで欲しい機能を探しPRにする ○ Resources request/limitnの指定, NodeAffinityなど

© 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

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

© ZOZO Technologies, Inc. 33 まとめ ✅ 高い開発効率 ✅ スケーラビリティーがある ✅ 安定している

© ZOZO Technologies, Inc. 34 ✅高い開発効率 もともとDigdagはよくできていた（意訳: 特に何もしていない） ● digdag run によるローカル環境での動作確認 ● タスク実行のパフォーマンスが高い

© ZOZO Technologies, Inc. 35 ✅スケーラビリティがある GKE上でホストしてあげることで、スケーラビリティを確保 ● 独自の水平スケーラを作ることでWorkerを安全にスケールアウト/インできるよう に ○ ワークフローが終わらないとスケールインできないため改善の余地あり ● 「KubernetesCommandExecutor」とGKEの自動プロビジョニングでインフラの 面倒を見る手間を省くことができる

© ZOZO Technologies, Inc. 36 ✅安定している 2020年3月あたりから運用し始めて特に何も問題なく稼働している ● 始めはエラーなどで出て安定していなかったが、パッチを送って安定させた ○ 即座にパッチを適用できるのがOSSをセルフホストする強みだと改めて感じた

No content