2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
•
1 j'aime•9,469 vues
2018 builderscon 「airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう」用資料
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
Similaire à 2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう (20)
Plus de BrainPad Inc.
Plus de BrainPad Inc. (20)
2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
- 2. ● 渥美 達也 と申します ● ブレインパッドの自社サービス開発部署のVP of Engineering ● VPoEのかたわら、サービス開発もやってます。 ● Python, k8s, GCP, ボルダリングあたりが好きです。 自己紹介 最近話題のブレインパッドってデータサイエンスの堅い会社なの？ 本イベントに合わせて、builderscon運営さん に素敵なインタビュー記事を作っていただき ました！
- 3. アジェンダ 1. airflowの簡単な紹介 2. airflowを導入したプロダクトについて 3. airflow導入以前の課題 4. airflowの導入 5. 規模拡大への対処 6. 運用TIPS
- 5. airflowって？ “Airflow is a platform to programmatically author, schedule and monitor workflows.” 公式ドキュメントから抜粋 ざっくり言ってしまうと、 ワークフローを管理するためのソフトウェア。
- 6. ワークフローはタスクの依存関係 Task A Task B Task C Task D Task E airflowでは”DAG”（有向非巡回グ ラフ）とよばれます
- 7. airflowは、ワークフローを実行・管理する 例えばこんなことができます ● Pythonによるワークフローの実装 ● スケジュール実行 ● 実行履歴の可視化 ● 自動・手動リトライ ● 並列処理
- 10. 豊富なオペレータ ● BashOperator ○ Bashスクリプトを実行する ● PythonOperator ○ Pythonコードを実行する ● BranchPythonOperator ○ Pythonでの条件式に基づき、どのOperatorを次に実行するか判定する ● その他、 ○ DockerOperator, BigQueryOperator, SlackAPIOperatorのような外部との連携も ○ 既存のOperatorを継承した自前実装も結構簡単です。 ■ 私たちもBranchPythonOperatorを拡張した実装を一部使っています。
- 13. airflowの実行モードとスケーラビリティ airflowでは、Executorというクラスの実装を切り替えることで環境に応じた実行モードを 切り替えます。 ● SequentialExecutor ○ 一番単純な実行モード。タスクを直列にしか実行できない。 ○ お試し用という位置付け。 ● CeleryExecutor ○ RabbitMQなどのキューを利用した実行モードで、スケジューラとワーカーが分離される ○ ワーカーを並列実行でき、サーバー増設によるスケールも簡単になるため、本番環境での利用に 向いている。
- 16. 導入プロダクトについて
- 18. Rtoasterとは ● 「レコメンドエンジン搭載プライベートDMP」 ● ECサイトなどに導入することで、訪問ユーザーの行動ログをはじめとした、多様な データを蓄積します ● 蓄積した行動ログをもとに、様々なアクションが行えます ○ 訪問ユーザーの嗜好に応じたレコメンド（オススメ的な） ○ ユーザーのセグメンテーション（グループ分け） ○ などなどなど・・
- 19. Rtoasterのシステム的特徴 ● 100億件を超える大量のログデータ ● 単純な集計処理から、機械学習処理まで様々なタスク ● クライアントごとの独立性 ○ 契約クライアントごとに集計などのデータ処理は独立している ○ あるクライアントのトラブルが他のクライアントに影響を与えてはいけない このようなシステムではオンラインでのビッグデータ処理だけではなく、 オフライン（バッチ処理）で大量のワークフローが日夜実行される
- 21. airflow導入サブシステムの歴史 2014年 β版リリース（私はリリース後に入社） 2015年 GA版リリース 2016年 airflowを導入 2018年 Rtoasterへの正式統合に伴う規模の大幅な拡大
- 22. airflow導入以前の課題
- 23. β版リリース時のワークフロー ログロードタスク （クライアントA） データ転送タスク （クライアントA） cron ログロードタスク （クライアントB） データ転送タスク （クライアントB） ● タスク間の依存関係はなかった ● クライアントごとにタスク実行 ● cron設定行数は、2 * クライアント数となる ● クライアント追加ごとにcron設定が必要 ● 通知はメール ● 当時は処理も単純でクライアント数も非常に少な かったので特に問題なかった
- 24. GA版リリース時のワークフロー ログロードタスク （クライアントA） データ転送タスク （クライアントA） cron ログロードタスク （クライアントB） データ転送タスク （クライアントB） ● ログロードタスクと集計タスクの間には依存関係があ り、ログロードが終わらないと集計が実行できない ○ つまり、ワークフロー ● 上記のような問題にcron時間調整による職人芸で対 処していた ○ 例えば「ログロードがAM 4:00起動で10分くらい で終わるから、集計タスクはAM 4:20の起動」 ○ これをクライアントごとにやる・・！ ● GAと言いつつも積極展開していなかったので運用ダ メージは浅めだった 集計タスク （クライアントA） 集計タスク （クライアントB） 暗黙の関連 暗黙の関連
- 25. クラスタリング機能※ 追加後のワークフロー ログロードタスク （クライアントA） データ転送タスク （クライアントA） cron ログロードタスク （クライアントB） データ転送タスク （クライアントB） 集計タスク （クライアントA） 集計タスク （クライアントB） 暗黙の関連 RMFクラスタリング （クライアントA） カテゴリクラスタリング （クライアントA） SQS 暗黙の関連 RMFクラスタリング （クライアントB） カテゴリクラスタリング （クライアントB） SQS ● ワークフローが複雑化 ○ 二股に別れる ○ クライアントの状況に よってどれを実行する か動的に決まる ● SQSを導入して職人芸を回避 しつつスケーラビリティを確保 ● しかし、集計タスクの部分に 職人芸が残る ● cronはクライアントが増えるた びに肥大化を続ける ※クラスタリング機能＝行動ログからユーザーを自動的にグループわけする機能。 億超えのレコードに対して処理を行うため、Spark on EMRで稼働。
- 27. airflowの導入
- 29. ● 運用のしやすさ ○ GUIでの実行管理やリランの仕組み ○ エラー発生時・規定実行時間をオーバーしたときの通知 ○ 現状のチームで管理できる ● きめ細かい制御 ○ 複雑なワークフローの記述 ■ 並列実行, 条件分岐, タスク間での値の受け渡し、動的なワークフロー生成など ○ 細かい実行制御 ■ ワークフローごと・タスクごと・キューごとの同時実行数制限など ● 特定の種類のタスクや、特定のクライアントのタスクが他のタスクをブロックしてしまう のは極力避けたい ● スケーラビリティ 選定の観点
- 30. 比較 SWF Azkaban Airflow 運用のしやすさ 管理画面は必要最低限で、使い勝手もイマ イチ・・。 タスク間の関係を制御をするのは完全に実 装側の責任。 管理画面はワークフローの可視化や再実 行の仕組みなどあり使いやすそう。 様々な観点でのワークフロー可視化やリラ ンなど、管理画面が使いやすそう。 きめ細かい制御 制御するのは実装側なので、いかようにも 可能。 条件分岐や動的なワークフロー生成がな かった。 並列性の制御はexecutor（ワーカー）ごと のみ。 条件分岐など複雑なケースに対応。 並列性制御もワーカーごとだけでなく、Pool の仕組みを使ったきめ細かい制御が可能。 スケーラビリティ 問題なくスケールする。 複数ワーカーの実行をサポートしているの で大丈夫そう。バックエンドのDBが気にな るが・・。 複数ワーカーの実行をサポートしているので 大丈夫そう。バックエンドのDBが気になるが ・・。 所感 運用の経験から、やりたいことはだいたいで きるしスケールもするが、実装も運用も結構 ツラい。 シンプルなケースには最も向いていそうだ が、今回の要件には機能不足感は否めな い。 管理が簡単そうな他、複雑なケースにも対 処できそう。 ジョブ定義がPythonというのも良い。 airflowは我々の要件を満たしてくれそうと感じた！ ※2015〜2016年時点での比較であることにご注意ください。
- 32. ワーカーサーバー airflow導入後の構成 EC2（マネージャーサーバー） airflow scheduler （Pythonプロセス） airflow webserver （Pythonプロセス） EC2（ワーカーサーバー） airflow worker （Pythonプロセス） タスク （Pythonプロセス） RDS （airflow履歴管理） Rabbit MQ 自前のポーラー不要 スケールする ワークフローの管理が簡単になるな ど、airflowによるメリット RabbitMQやRDS、2種類のEC2に よるインフラの複雑化 システムの複雑化と引き換えに、 ワークフロー管理の簡単さを得たと いえる。 （今のGCPならCloud Composerがあるの で複雑化から逃れられそう。）※SQSでなくRabbitMQなのは、当時のCeleryではExperimentalだったから
- 35. airflowを導入してみて ● 自前でやっていた依存関係管理は全部airflowにお任せできた ● ビューも見やすいので何かあっても状況確認が超簡単になった ● インフラが複雑化した面は否めないが、それ以上のメリットがもたらされた ● 検証・導入当時はバグを踏むことも何度かあった ○ PR出せばすぐチェックしてマージしてくれた ● 思った以上に安定稼働した ● airflow特有のクセに慣れる必要もあった 全体的には、運用が楽になり導入してよかったと感じられた
- 36. 規模の拡大
- 38. どのくらい規模拡大したのか？ クライアント数 65 938 （x 14） ジョブ実行数（1日） 9,042 （x 8） 1,120
- 39. 乗り切るためにインフラ増強 airflow manager airflow worker t2.small x 1 c4.xlarge x 1 c4.large x 1 c4.2xlarge x 4 RDS t2.small x 1 t2.small x 1 ※アプリとairflowデータ共存 ※airflow専用インスタンスを新たに構築
- 40. 思ったより大丈夫だったという結論 ● インフラ増強＋同時実行数制限を大きくするといったパラメータチューニング程度で 乗り切れた！ ○ 同時実行数制限のお話は「運用TIPS」を参照（多分時間切れになっている） ● 特に事故らしい事故もなかった！ ● 仮にairflow導入前のアーキテクチャで規模拡大がやってきたら、地獄が待っていた に違いない（震え） ○ 大きなリスクには早めの対処を！
- 41. 運用のTIPSや困った点など
- 42. タスクの同時実行数制御について airflowには同時実行数を制御できる設定値がたくさんある。 ● タスクの同時実行数（dag_concurrency） ● ワークフロー種類ごとの同時実行数（max_active_runs_per_dag） ● airflow workerごとの同時実行数（celeryd_concurrency） ● Pool（後述） 他にもあったかも・・・
- 43. Poolについて Operator A pool=”p-1” priority=1 Operator B pool=”p-1” priority=2 Operator C pool=”p-2” priority=1 Pool: p-1 slot=1 Pool: p-2 slot=2 Operator A-1 Operator B-1 Operator C-1 オペレータ（タスク）ごとに、所属するプール名と優 先度を定義する スケジュールされるオペレータの数がPoolのスロットを超 える場合、同じプールに属するものは優先度順に実行さ れる。 この場合、Operator A-1、B-1がPool p-1に属しているが、 p-1のslotは1なので、優先度が劣るOperator A-1はB-1が 終わるまで待機となる。 Operator C-2 Pool: p-1 slot=1 Pool: p-2 slot=2 プールを定義する。slotは、そのプールの容量＝ 並列度
- 44. 同時実行数制御のポリシー ● Poolを使う ○ 特定のタスクのまとまりごとに同じプールを使うことで、特定のタスクがワーカーを占拠してしまうこ とによるタスク全体の目詰まりを防ぐ。 ○ 各クライアントの契約状況等に基づいて優先度を設定する ● それ以外の設定は、基本的にはサーバーインフラに応じて大きめに設定する ○ 極力シンプルにしておきたい ○ 基本的にはPoolで制御されてしまう
- 45. ワークフロー（DAG）の実装について ● オペレータはクライアントごとに個別かつ並列に実行したい。 ○ あるクライアントの処理が別のクライアントの処理をブロックしてほしくない ○ 一部のクライアントの処理だけ失敗した場合、そこだけに影響範囲を絞りつつ、リトライもしたい ○ クライアントが増えたり減ったりするたびに運用が発生して欲しくない => DAG定義ファイルの中で、DBからクライアントデータをロードして動的にDAGオブジェ クトを構築する
- 46. バックフィルの挙動が厄介 ● 例えばデイリーで動くワークフローがあったとして、そのワークフローを8/1〜8/3まで停止したとする （airflowの機能でスケジュールを停止できる） ● 8/4に再開すると、8/1, 8/2, 8/3の動かなかった分のワークフローが動き出す ● 再開するたびに動く必要のない過去分が全部動くのはかなり邪魔臭かったので、タスクを再度起動する 場合はstart_dateパラメータを昨日など直近に更新してから再起動する運用が必要。 ● 本番環境でタスクを停止することはほぼないので良いが、テスト環境ではよくあるので面倒だった。。 ● 1.8からcatchupパラメータが追加され、Falseにすればバックフィルを無効にできるようになった！
- 47. タスクのスケジュール日時がわかりにくい ● airflowでは、一つ前の日時のタスクをスケジューリングする。 ● 例えば毎日10時に起動されるタスクがあるとして、8/10の10時に起動されるタスク の日時は8/9の10時となる。 ○ {{ ds }}パラメータから取得できる値も”2018-08-09”となる・・！ ○ オペレータの実装では気をつける必要がある。
- 48. まとめ
- 49. まとめ：airflowに対する印象 ● 複雑なユースケースや実行制御なども可能で、やりたいことはだいたいできそう ● 設定が多いので、それなりのキャッチアップが必要 ● ツールとしてのクセがやはりあるので、慣れが必要 ● Python使いにはオススメ ● GCPがCloud Composerとしてマネージドairflowをサポートしだしたのはアツい ○ 自前で色々用意しなくても導入がとても簡単に ○ 開発が多分活発化する
- 51. ご静聴ありがとうございました。