Slide 1

Slide 1 text

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:[email protected] Tel: 03-6712-0636 Fax: 03-6712-0664 Visit https://goo.gl/YfGUp7 for online slides

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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 •コンパイラ

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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も) – 障害時の⾃動再実⾏

Slide 8

Slide 8 text

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/

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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で管理

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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 – まだ試していない

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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を叩く前にローカルの状態を更新しておく

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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 のログを⾒る

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Copyright © 2017Nautilus Technologies, Inc. All rights reserved. NAUTILUS 27 Roadmap (必要に応じて) ■⾼可⽤性、耐障害性 ■Fair scheduling ■DCOSパッケージ化