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

builderscon2018 airflowを用いて、 複雑大規模なジョブフロー管理 に...

Tatsuya Atsumi
September 07, 2018

builderscon2018 airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう

builderscon2018で発表した資料。

Tatsuya Atsumi

September 07, 2018
Tweet

More Decks by Tatsuya Atsumi

Other Decks in Technology

Transcript

  1. • 渥美 達也 と申します • ブレインパッドの自社サービス開発部署のVP of Engineering • VPoEのかたわら、サービス開発もやってます。 •

    Python, k8s, GCP, ボルダリングあたりが好きです。 自己紹介 最近話題のブレインパッドってデータサイエンスの堅い会社なの? 本イベントに合わせて、builderscon運営さん に素敵なインタビュー記事を作っていただき ました!
  2. airflowって? “Airflow is a platform to programmatically author, schedule and

    monitor workflows.” 公式ドキュメントから抜粋 ざっくり言ってしまうと、 ワークフローを管理するためのソフトウェア。
  3. ワークフローはタスクの依存関係 Task A Task B Task C Task D Task

    E airflowでは”DAG”(有向非巡回グ ラフ)とよばれます
  4. 豊富なオペレータ • BashOperator ◦ Bashスクリプトを実行する • PythonOperator ◦ Pythonコードを実行する •

    BranchPythonOperator ◦ Pythonでの条件式に基づき、どのOperatorを次に実行するか判定する • その他、 ◦ DockerOperator, BigQueryOperator, SlackAPIOperatorのような外部との連携も ◦ 既存のOperatorを継承した自前実装も結構簡単です。 ▪ 私たちもBranchPythonOperatorを拡張した実装を一部使っています。
  5. airflowの実行モードとスケーラビリティ airflowでは、Executorというクラスの実装を切り替えることで環境に応じた実行モードを 切り替えます。 • SequentialExecutor ◦ 一番単純な実行モード。タスクを直列にしか実行できない。 ◦ お試し用という位置付け。 •

    CeleryExecutor ◦ RabbitMQなどのキューを利用した実行モードで、スケジューラとワーカーが分離される ◦ ワーカーを並列実行でき、サーバー増設によるスケールも簡単になるため、本番環境での利用に 向いている。
  6. Rtoasterのシステム的特徴 • 100億件を超える大量のログデータ • 単純な集計処理から、機械学習処理まで様々なタスク • クライアントごとの独立性 ◦ 契約クライアントごとに集計などのデータ処理は独立している ◦

    あるクライアントのトラブルが他のクライアントに影響を与えてはいけない このようなシステムではオンラインでのビッグデータ処理だけではなく、 オフライン(バッチ処理)で大量のワークフローが日夜実行される
  7. β版リリース時のワークフロー ログロードタスク (クライアントA) データ転送タスク (クライアントA) cron ログロードタスク (クライアントB) データ転送タスク (クライアントB)

    • タスク間の依存関係はなかった • クライアントごとにタスク実行 • cron設定行数は、2 * クライアント数となる • クライアント追加ごとにcron設定が必要 • 通知はメール • 当時は処理も単純でクライアント数も非常に少な かったので特に問題なかった
  8. GA版リリース時のワークフロー ログロードタスク (クライアントA) データ転送タスク (クライアントA) cron ログロードタスク (クライアントB) データ転送タスク (クライアントB)

    • ログロードタスクと集計タスクの間には依存関係があ り、ログロードが終わらないと集計が実行できない ◦ つまり、ワークフロー • 上記のような問題にcron時間調整による職人芸で対 処していた ◦ 例えば「ログロードがAM 4:00起動で10分くらい で終わるから、集計タスクはAM 4:20の起動」 ◦ これをクライアントごとにやる・・! • GAと言いつつも積極展開していなかったので運用ダ メージは浅めだった 集計タスク (クライアントA) 集計タスク (クライアントB) 暗黙の関連 暗黙の関連
  9. クラスタリング機能※ 追加後のワークフロー ログロードタスク (クライアントA) データ転送タスク (クライアントA) cron ログロードタスク (クライアントB) データ転送タスク

    (クライアントB) 集計タスク (クライアントA) 集計タスク (クライアントB) 暗黙の関連 RMFクラスタリング (クライアントA) カテゴリクラスタリング (クライアントA) SQS 暗黙の関連 RMFクラスタリング (クライアントB) カテゴリクラスタリング (クライアントB) SQS • ワークフローが複雑化 ◦ 二股に別れる ◦ クライアントの状況に よってどれを実行する か動的に決まる • SQSを導入して職人芸を回避 しつつスケーラビリティを確保 • しかし、集計タスクの部分に 職人芸が残る • cronはクライアントが増えるた びに肥大化を続ける ※クラスタリング機能=行動ログからユーザーを自動的にグループわけする機能。 億超えのレコードに対して処理を行うため、Spark on EMRで稼働。
  10. • 運用のしやすさ ◦ GUIでの実行管理やリランの仕組み ◦ エラー発生時・規定実行時間をオーバーしたときの通知 ◦ 現状のチームで管理できる • きめ細かい制御

    ◦ 複雑なワークフローの記述 ▪ 並列実行, 条件分岐, タスク間での値の受け渡し、動的なワークフロー生成など ◦ 細かい実行制御 ▪ ワークフローごと・タスクごと・キューごとの同時実行数制限など • 特定の種類のタスクや、特定のクライアントのタスクが他のタスクをブロックしてしまう のは極力避けたい • スケーラビリティ 選定の観点
  11. 比較 SWF Azkaban Airflow 運用のしやすさ 管理画面は必要最低限で、使い勝手もイマ イチ・・。 タスク間の関係を制御をするのは完全に実 装側の責任。 管理画面はワークフローの可視化や再実

    行の仕組みなどあり使いやすそう。 様々な観点でのワークフロー可視化やリラ ンなど、管理画面が使いやすそう。 きめ細かい制御 制御するのは実装側なので、いかようにも 可能。 条件分岐や動的なワークフロー生成がな かった。 並列性の制御はexecutor(ワーカー)ごと のみ。 条件分岐など複雑なケースに対応。 並列性制御もワーカーごとだけでなく、Pool の仕組みを使ったきめ細かい制御が可能。 スケーラビリティ 問題なくスケールする。 複数ワーカーの実行をサポートしているの で大丈夫そう。バックエンドのDBが気にな るが・・。 複数ワーカーの実行をサポートしているので 大丈夫そう。バックエンドのDBが気になるが ・・。 所感 運用の経験から、やりたいことはだいたいで きるしスケールもするが、実装も運用も結構 ツラい。 シンプルなケースには最も向いていそうだ が、今回の要件には機能不足感は否めな い。 管理が簡単そうな他、複雑なケースにも対 処できそう。 ジョブ定義がPythonというのも良い。 airflowは我々の要件を満たしてくれそうと感じた! ※2015〜2016年時点での比較であることにご注意ください。
  12. airflow導入前の構成 EC2(バッチサーバー) crond タスクA (Pythonプロセス) SQS タスクB (Pythonプロセス) SQSポーラー (Pythonプロセス)

    push pull fork ※インフラはAWS シンプルな構成 スケールする タスク間の関連がタスクの実装に密結合 ワークフロー全体の状態を管理するのが大 変 特定のタスクの再実行(もちろんパラメータ も引き継いだ上で)が大変 エラー時の自動リトライの実装など、自前で 作り込む必要性
  13. ワーカーサーバー 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だったから
  14. 乗り切るためにインフラ増強 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専用インスタンスを新たに構築
  15. 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は、そのプールの容量= 並列度
  16. バックフィルの挙動が厄介 • 例えばデイリーで動くワークフローがあったとして、そのワークフローを8/1〜8/3まで停止したとする (airflowの機能でスケジュールを停止できる) • 8/4に再開すると、8/1, 8/2, 8/3の動かなかった分のワークフローが動き出す • 再開するたびに動く必要のない過去分が全部動くのはかなり邪魔臭かったので、タスクを再度起動する

    場合はstart_dateパラメータを昨日など直近に更新してから再起動する運用が必要。 • 本番環境でタスクを停止することはほぼないので良いが、テスト環境ではよくあるので面倒だった。。 • 1.8からcatchupパラメータが追加され、Falseにすればバックフィルを無効にできるようになった!