Introducing Retz and how to develop practical frameworks

Introducing Retz and how to develop practical frameworks

Slides for my talk at Mesos Meetup Tokyo #2

E1923013dacab39eb231a2fffbf7b33c?s=128

UENISHI Kota

July 25, 2017
Tweet

Transcript

  1. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved. NAUTILUS

    Introducing Retz And Developing Practical Mesos Framework 2017/7/25 Mesos Meetup Tokyo #2 @ IIJ 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Visit https://goo.gl/YfGUp7 for online slides
  2. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 2

    Summary ▪Asakusa Framework as enterprise batch system development environment with source open – One source code, runs on many backend engines e.g. Hadoop MapReduce, Spark, M3BP – Thereʼs distributed schedulers for MapReduce and Spark, but nothing for M3BP ▪Retz as a full featured job scheduler on top of Apache Mesos for scheduling M3BP batch jobs – But supports any other CUI programs in containers ▪Real world usage and actual software stack ▪Lessons learned on developing and operating full featured Mesos framework
  3. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 3

    ㈱ノーチラス・テクノロジーズ ▪Asakusa Frameworkという業務バッチ向けのDSLコンパイラを OSSで開発・提供しています ▪他にもいろいろ開発・提供しようとしています ▪コンパイラに詳しい⼈、データベースに詳しい⼈、分散システムに 詳しい⼈、業務に詳しい⼈、Javaに詳しい⼈などがいます
  4. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 4

    Spark YARN ▪基幹業務システム向けのモデリング⾔語、DSLとコンパイラなどの 開発環境 ▪基幹バッチ処理に必要なテスト・実⾏環境・運⽤環境 ▪各種データベース、データ形式のドライバも同梱 ▪各種分散処理システム、DAGエンジンに(順次)対応 n MapReduce, Spark 向けコードをAsakusaのコンパイラが⾃動⽣成・最適化 •データモデル定義 •外部システム連携 •Asakusa DSL •Operator DSL •自動テスト •バッチ実行ツール •Flow DSL •Batch DSL • MapReduce •コンパイラ •DMDL •DMDL •コンパイラ •TestDriver •ThunderGate •WindGate •Direct I/O •YAESS •EXCEL •テンプレート •実行エンジン •スモールジョブ 実行エンジン Apache Hadoop CDH MapR HDP Amazon EMR M3BP コンパイラ 基幹業務向けバッチ開発フレームワーク Asakusa •Spark •コンパイラ
  5. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 5

    コードを変更せずにエンジンをを切り替える クラウド 分散環境 分散処理フレームワーク 商用ディストリビューション シングルノード 並列環境 並列処理 フレームワーク &実行基盤 M3BP クラウドサービス Amazon EMR Azure HDInsight データフロー DSL / コンパイラ インフラ ストラクチャ 並列・分散処理 ミドルウェア 開発 フレームワーク リファレンス実装 オンプレミス ユースケースに合わせて必要な性能特性を持ったエンジンを利用する
  6. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 6

    スケジューラがない! ▪リソーススケジューラ(ジョブスケジューラ)がないとリソース利 ⽤率が上がらない≒常に余剰リソースを抱えることになる ▪Jenkins – 柔軟性が⾼くプラグインも豊富 – ジョブキューとしては不⼗分 ▪YARN (Apache Hadoop) – よくも悪くもHadoop系プロダクトがプライマリターゲット ▪Apache Mesos – 完成度が⾼い、⾃由度も⾼い – エコシステムも発達 – ⾃分でスケジューラ作らないといけない
  7. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 7

    Retz ( github.com/retz ) ▪いわゆる「ジョブキュー」 ▪ジョブを渡す→リソースが空い たら順番に実⾏してくれる ▪Mesos を使いやすくする – ⾮同期なScheduler APIを独⾃の同期APIに変換 – Mesos API と UI の完全隠蔽を⽬指す – 業務⽤ジョブスケジューラのための実⽤性 ▪機能 – ジョブの登録、削除、⼀覧 – マルチユーザー対応(Mesosのユーザー追加は⼤げさ…) – ジョブ優先制御、カスタムスケジューリング実装のプラグイン – GPUリソース、カスタム attributes 指定 – Dockerコンテナ上での実⾏(Docker Volumesも) – 障害時の⾃動再実⾏
  8. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 8

    Retz@さくらインターネット (1/2) ▪データセンターの原価計算システム [1] – ⽣データ 500GB / day – ⽇次で数百ジョブ、⽉次で数百ジョブ ▪ Asakusa on Spark から Asakusa on M3BP に移⾏ – 全てのジョブがインメモリで処理できる程度にコンピュータの性能が向 上してきた – YARNのようなスケジューラーがないのでMesos – いざというときもMesos上でSparkを⾛らせることができる – Sparkだと数⼗分かかるジョブもあった •MapR FS •YARN (Apache Hadoop) •Asakusa on Spark •Jenkins •MapR FS •Retz / Apache Mesos •Asakusa on M3BP •Digdag [1] http://knowledge.sakura.ad.jp/event/3766/
  9. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 9

    Retz@さくらインターネット (2/2) ▪サーバー台数 – 20台以上 => 5台以下 ▪⼀⽇のジョブ数 – 1000~2000程度 ▪ジョブの実⾏待ち時間 – 多くが10~20分程度、中央値約8.3分 ▪ジョブの実⾏時間 – ほとんどが2分以内、中央値17.0秒
  10. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 10

    Retz & Mesos @ Preferred Networks ▪社内⽤の実験環境 ▪ハードウェア環境とソフトウェア・パッケージの組み合わせを指定 したDockerの中で実験⽤プログラムを実⾏ ▪Mesos の複雑なAPIを隠蔽してシンプルなジョブスケジューリング をしてくれる ▪耐障害性も担保されていて、タスクが失敗しても、ノードが故障し ても⾃動的にRetzが再実⾏してくれる ▪⾃分たちの環境に合わせた独⾃のPlannerを作ってプラグインして いる ▪Retzに多くのコントリビューションをしていくれています
  11. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 11

    MESOS FRAMEWORK の 作り⽅(発展編) 前提知識 Mesos Framework の作り⽅: https://goo.gl/zGpBdt
  12. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 12

    Retz & Mesosのプロセス構成 Master Agent Executor Executor Executor Executor Agent Executor Executor Executor Executor Agent Executor Executor Executor Executor •…....... Framework Scheduler (Marathon) Retz ZooKeeper ZooKeeper ZooKeeper
  13. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 13

    タスク起動の仕組み Master Agent Executor Agent Executor Framework Scheduler 1. Resource Offer 2. Accept Offer 3. Launch Task 4. Fork & Exec 4. Fork & Exec 5. Status Update 5. Status Update •Executorは daemon でもOK •Executorは ただのコマンドでもOK •Executorは Docker イメージでもOK •Framework SchedulerはMarathonで管理
  14. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 14

    復習: Mesos Framework API の基本的な使い⽅ ▪Scheduler Interface でMesosからの通知を受け取る – Offerが来た – タスクが始まった / 終わった / 失敗した – Mesosと切れた – Agentが死んだ ▪Scheduler Driver でMesosにリクエストを送る – Offerを Accept / Decline する – Mesosとの接続を切る Framework Scheduler Driver Scheduler Interface callback
  15. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 15

    Hello Mesos !の次の⼀歩: 結果の取得 ▪ statusUpdate では TASK_FAILED / TASK_KILLED でしかプロ グラムの実⾏結果が分からない(リターンコードすら分からない) ▪プログラムの実⾏結果をどうやって取得する? ▪外部ストレージ(HDFS, S3, NFS…)にファイルを書く – Docker Volume Driver経由でアタッチ – ネットワーク経由で直接書き出す ▪Scheduler#frameworkMessage() – ⾃分でExecutorを作る必要がある ▪Sandboxを覗く – stdout / stderr というファイルが作成されるので、これをOperator API 経由でファイルを取得する – 2週間経つとAgent内で消される(→ディスクフルに注意) ▪Container Attach / Detach – MESOS-6460 – まだ試していない
  16. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 16

    Hello Mesos !の次の⼀歩: 準正常系、異常系 ▪複数のサーバーが協調して⼀貫した動作をする=分散システム ▪タスクの失敗 ▪ノードの故障 ▪スケジューラの故障、再起動 ▪その他 – いつまで経ってもOfferが来ない – いつまで経ってもMesosに(再)接続できない
  17. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 17

    タスクの失敗 ▪失敗する原因 – アプリが⾮0を返す (TASK_FAILED) – OOM Killer (TASK_KILLED) – ネットワーク分断 (TASK_LOST etc.) – etc… ▪いずれもMesosは再実⾏してくれないので、Framework側でハン ドリング – フレームワークとアプリケーションの要件に応じて ▪ 再実⾏ ▪ 上位に通知 – ネットワーク分断の可能性があるので、タイミングをみて reconcile す ると帰ってくる(こともある) – 細かいことは mesos.proto を⾒ましょう Scheduler Master Agent Executor App
  18. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 18

    タスクの扱い ▪Mesos側が何かおかしい(Master / Agentが落ちた)とき – 再接続などはクライアントライブラリが⾃動的に対応 – reconcile すると updateStatus が来るので、情報を確認 – 適切に対応する ▪スケジューラ側がおかしくなったとき – failover_timeout の間はMesosが待ってくれる – 再起動やフェイルオーバーしても、同じFramework IDで接続すれば状 態を維持できる ▪ Framework IDとタスクの状態を⾼可⽤な何某かに保存しておく ▪タスクの情報をスケジューラ側で管理するコツ – Mesos上の状態と、スケジューラ内の状態は必ずずれる – ⼀貫制を保つ努⼒をする(ずれていたら直す) ▪ 状態がずれたときの解決⽅法の状態遷移図を全て定義しておく ▪ Retzであれば JobStatem.java – Driver APIを叩く前にローカルの状態を更新しておく
  19. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 19

    ノード故障 ▪どのノードもいつでも故障しうる ▪どのノードにあるデータも任意のタイミングでなくなる ▪基本⽅針 – 冪等に設計してリトライする – データを複製して冗⻑化する – ZooKeeperを信⽤して複製間の排他制御に利⽤する Scheduler Master Agent Executor App ZooKeeper
  20. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 20

    スケジューラのHA化 (パターン1) ▪冪等に設計してリトライする – 失敗したら確認 (reconcile) して再実⾏ ▪データを信頼できるストレージに保存する – HDFS, S3, MySQL/PostgreSQL, NoSQL, etc.. – Persistent Storage はダメ – 少量ならReplicated Log / ZooKeeper ▪Marathon / Aurora に起動制御をさせる – インスタンスが落ちたら(規定数に⾜りなかったら上げてくれる) Scheduler Frameworkとして登録 起動管理 Framework
  21. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 21

    スケジューラのHA化 (パターン2) ▪冪等に設計してリトライする – 失敗したら確認 (reconcile) して再実⾏ ▪データを複製して冗⻑化する – ⼤きな量のレプリケーションは⾃前で – ⼩さな量はReplicated Logで ▪ZooKeeperを信⽤して複製間の排他制御に利⽤する – 複数台⽴ち上げてZooKeeperで協調させる – ただし負荷をかけてはいけない Scheduler Master Agent Executor App ZooKeeper Scheduler Master Agent Executor App Scheduler Master Agent Executor App ZooKeeper ZooKeeper
  22. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 22

    その他ハマりどころ ▪いつまで経ってもOfferが来ない – Mesos masterとの接続が切れている – GPU_RESOURCESがオンになっている – 他のFrameworkがOfferを確保している ▪いつまで経ってもMesosに(再)接続できない – Masterの IPアドレスに直接アクセスしていないか? – 1台でもZooKeeperを使う ▪ドキュメントに詳細な仕様がない – mesos.proto のコメントを全部読む ▪Operator API にまともなクライアントがない ▪タスクが失敗した原因がわからない – コンテナの起動に失敗すると Sandbox は空になる – Master / Agent のログを⾒る
  23. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 23

    最後にひとつ: Retz Digdag Plugin ▪DigdagのワークフローをRetz経由でMesos上で実⾏する – RetzのJavaクライアントでプログラミングしなくてよい – RetzのCLIを覚える必要がない – 結局ワークフローにして運⽤するので ▪こんな感じでワークフローに組み込める +simple_app: retz_run>: /opt/app/simple-app.sh +heavy_batch: retz_run>: /opt/app/heavy-batch.sh ${session_date} cpu: 8 mem: 16g priority: 1 timeout: 30 https://github.com/retz/retz-digdag-plugin
  24. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 24

    まとめ ▪Retzを紹介 ▪Framework APIの細かい動作と扱いについて解説 ▪⾃作スケジューラを作るときのパターン ▪困ったら mesos.proto を⾒ましょう 【宣伝】ノーチラス・テクノロジーズでは • バッチ処理およびHadoopやSparkなど周辺システムのコンサルティ ング、受託開発、運用 • Asakusa Frameworkの開発と運用の商用サポート • RetzおよびApache Mesosの商用サポート などを行っています。お気軽にお問い合わせ下さい
  25. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 25

    QUESTIONS?
  26. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 26

    APPENDIX
  27. Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 27

    Roadmap (必要に応じて) ▪⾼可⽤性、耐障害性 ▪Fair scheduling ▪DCOSパッケージ化