Introducing Retz and how to develop practical frameworks

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 8
[email protected]さくらインターネット (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/

View Slide

NAUTILUS 9
[email protected]さくらインターネット (2/2)
■サーバー台数
– 20台以上 => 5台以下
■⼀⽇のジョブ数
– 1000~2000程度
■ジョブの実⾏待ち時間
– 多くが10~20分程度、中央値約8.3分
■ジョブの実⾏時間
– ほとんどが2分以内、中央値17.0秒

View Slide

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

View Slide

NAUTILUS 11
MESOS FRAMEWORK の
作り⽅（発展編）
前提知識
Mesos Framework の作り⽅: https://goo.gl/zGpBdt

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 19
ノード故障
■どのノードもいつでも故障しうる
■どのノードにあるデータも任意のタイミングでなくなる
■基本⽅針
– 冪等に設計してリトライする
– データを複製して冗⻑化する
– ZooKeeperを信⽤して複製間の排他制御に利⽤する
ZooKeeper

View Slide

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

View Slide

NAUTILUS 21
スケジューラのHA化（パターン2）
■冪等に設計してリトライする
– 失敗したら確認 (reconcile) して再実⾏
■データを複製して冗⻑化する
– ⼤きな量のレプリケーションは⾃前で
– ⼩さな量はReplicated Logで
■ZooKeeperを信⽤して複製間の排他制御に利⽤する
– 複数台⽴ち上げてZooKeeperで協調させる
– ただし負荷をかけてはいけない
ZooKeeper
ZooKeeper
ZooKeeper

View Slide

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 25
QUESTIONS?

View Slide

NAUTILUS 26
APPENDIX

View Slide

NAUTILUS 27
Roadmap （必要に応じて）
■⾼可⽤性、耐障害性
■Fair scheduling
■DCOSパッケージ化

View Slide

Introducing Retz and how to develop practical frameworks

Introducing Retz and how to develop practical frameworks

UENISHI Kota

More Decks by UENISHI Kota

Other Decks in Technology

Featured

Transcript