mesos
2017年11月02日12:16いってきた: Mesos Meetup Tokyo #3
- https://mesos.connpass.com/event/67877/
- 日時: 2017-11-01 19:00〜21:00
- 会場: IIJ飯田橋
[2017-11-01 19:01]
オープミング
- #MUGT
- もくもく会みたいなのもやりたいなぁ。
- Mesos User Groups は25都市が登録。
- さいしょはデータ解析でつかわれて、コンテナでつかわれるようになった、まだtensorflowなどでつかわれるように。
- Kubernetes
- distributed tensorflow support
Mesosを使用した分析サービス「e19(千京;せんけい)」の紹介と開発の話 / 木内満歳(きうち みつとし)
- e19: 自然対数のe。10^19の意味だったが。データサイエンティストのためのサービス。 https://e19.io
- 開発のなりゆき
- SI企業のなやみ: 案件ごとにエンジニアをわりあてるが、エンジニアの数で売上がきまってしまう。案件ごとに難易度がちがう。エンジニアごとにスキルもちがう。
- プロダクトをつくって売ればエンジニアもお客もハッピーなのでは?
- 世の中にはデータ分析サービスはくさるほどあるが、過去の成功と遺産にとわられているのでは? Hadoopの膨大なスタックにはまってる。ちょっとパラメータをいじっただけでバランスがくずれてつかいにくという苦情。
- 技術とニーズがずれはじめてるかも?
- Hadoop スタックから Spark ひとつでシンプルに。BIはapache drillつかったりするけど。
- なぜmesos?
- Sparkでつかえるクラスタ管理ソフト(Mesos,YARN,Standaalone)のひとつだったから。YARNはむつかしい、standaloneは簡単だけどマルチユーザに対応してない、他のサービスを同一フレームワークであつかえない。
- Agentは複数だが、1ZK 1Master の構成。
- e19ではクラスタを単一ホストっぽく見せる(シングルビュー)ようにしている。データサイエンティストの方々はクラスタに詳しくないため(sshシラネ、クラサバしらね)。バッチスケジューラ(Retz, Aurora)も入れてない。
- Q: DC/OSじゃないの?
- A: つかいたかったけどまだOSSになってなかった。
- データサイエンティストは分析用ライブラリにはこだわりがある。(xgboost,statsmodels,causalimpact,Bokeh,NLTK)。pip でインストールできるようにしたい。
- 開発体制・使用ツール (オフレコ)
- ぶっちゃけ2名
- UI=bootstrap
- アプリフレームワーク=Meteor。javascript。python:jangoをリッチにしたかんじ。
- インフラ=Ansible。難しいことをやるには面倒。chefにしたい。
- DB=MoboDB。Meteor指定。
- 開発方針: 無駄にがんばらない (兼業なので)
- syslogない。systemdでstdoutをジャーナルに書く。
- 環境: Fedora,Mac,CentOSでもうごいている。
- 管理はJIRA, Confluenseで。
- どうなった?
- ジレンマは解決されなかったが、
- 自分達で売るものができたのはよかった。
- 使いたい人よりも売りたい人のほうが多かった。なぜかわからんが。
- チャンネル登録よろ
- 今後の予定
- 売りたい人のためにマイクロサービス・可搬性向上(プラットフォーム非依存)させようとしている。
- http://www.creationline.com
[2017-11-01 19:45]
crashacademy で過去の動画がみられるらしい。今回も録画しているのでそのうちみえるようになるはず。
[2017-11-01 19:46]
たいそうりっぱになったねえ。 DC/OS 1.10 / @jyoshise
- https://hackmd.io/p/SyHr9e1CZ
- 9月に出た
- 事前アンケートではMesos,DC/OSにさわったことがない人が多いのでデモ
- DC/OS Universe Packageのしくみ
- 設定用のjsonファイルをかくだけ
- https://dcos.io, https://github.com/dcos https://dcos.io/docs
- Mesosのディストリビューション的なもの エンタプライズ版もある
- Spartan: MesosのDNS。.localだけじゃなくドメインをつかえるようになった。
- CNI(cloud native interface)対応
- Universal Container Runtime (UCR) つかうように。dockerはずし現象?
- kubernetesをDC/OSでうごかすメリット: かんたんにデプロイできる。DC/OS上のデータサービスとの接続が簡単。共通リソースの管理。
- Marathonじゃないのは? 長いものには巻かれろ?
- 鉄板データサービズ(M7): Mesosphereがpackageメンテナンス。production ready。
- nodeの数やgpuの数を指定するだけでてきとうにわりふってくれる。
- DC/OSはVagrantで1ノードでうごくが、いろいろやるなら最低5ノード。
- DC/OSのコミュニティはMesosよりも活発。
- CNCFへのあゆみより。パーシステンスストレージとか。
[2017-11-01 20:11]
休憩
[2017-11-01 20:22]
Serverless w/Mesos / @kojiha_
- デモしようとしたらバージョン不整合でうごかないのでトラブルシューティング中...
- Mesosでつかえるserverlessツール: Gestalt, Fancatron, iron.io
- iron.io: フロントエンドだけクラウドに置いて実行はオンプレミスで、ということもできる。
[2017-11-01 20:36]
[2017-11-01 20:39]
すべてのWaitingを生まれる前に消し去りたい / @kotatsu360
- https://speakerdeck.com/kotatsu360/goodby-waiting-status-forever
- VASILY: DC/OSはつかわず。Marathonでdockerコンテナをうごかしている。
- Marathonの"Wating"を解消したい
- リソースがいつまでたっても確保できない問題
- いったいなんのリソースが不足しているのか分からない。
- 1: リソース不足
- 2: タスクの制約(Constraints. GPU必要とか1ノード1タスク(hostname:UNIQUE制約)とか)
- 3: リソースの利用許可がない (ポート80をつかいたい(requirePorts)がagentにresourcesオプションを追加してなかった、など)
- upgradeStrategyでminimumHealthCapacityとmaximumOverCapacityを0にすると(新規タスクのデプロイ前に既存タスクをkill) 瞬断が許される場合につかえる
[2017-11-01 20:58]
@kotatsu360さんにリソース不足になったのを自動的に検出する方法はあるかきいてみたところ
- Web UIからはわからない
- marathonとmasterのAPIから必要リソースと手持ちリソースがわかるのでAWSならLambdaで監視できる
とのこと。
2016年12月16日12:56Mesosソースコードリーディング第1回
- 2016-12-15 18:00~21:00 PFN会議室 (大手町ビル;C7出口)
- https://mesos-scr-jp.connpass.com/event/45785/
- http://togetter.com/li/1059854
- ハッシュタグ: #mesosjp
- Q: Subcommand::dispatch()の引数どうなってるの?
- A: マクロで1引数から11引数までのバリエーションを生成しているっぽい。C++のvariadic templateでできそうだけど。
- 3rdparty/stout/include/stout/subcommand.hpp
[2016-12-15 18:24]
- 現在14人 (参加予定19人になってた)
[2016-12-15 18:25]
スタート
containerizerに興味があるひと?
containerizerがdockerコマンドをつかってないって知っている人?
[2016-12-15 18:32]
containerizer / @suma90h
- 機械学習チョットデキル
- さいきん星の写真をとっている
- 資料: https://github.com/kuenishi/mesos_scr_jp/blob/master/01/mesos-scr-01_containerizer.md
- エディタはvim
- Listing docsを読んだひと → 会場1名
- "Unified Container": mesos用語ではないっぽい。
- mesos.protoはv1の方をみる。
- composing containerizer: テストでつかうっぽい。複数のコンテナを結合。dockerの機能をつかいつつresource isolationできるので使いたいひとがいるかも。
- docker containerizer: dockerべったり。
- mesos containerizer: ソースをよむとifdef LINUXがでてきてゲンナリ。
- ソースをよむまえにcontainerizer-internals.mdをよむとよい。
- /v1はだれもいじってないので見ないで include/mesos/mesos.protoのほうを参照
- TaskInfo
- ContainerInfo
- executor: (A)mesos agent in docker or (B)not in dockerの2パターンある
- containerizer state: FETCHING: fetcherはサンドボックスにURIからダウンロードしてくるコンポーネント。
- 迷子にならないよう簡単なところから。 abstract classをみてみる。
- src/slave/containerizer/containerizer.hpp
- class Resourcesはどこからきてる? protobufから? それとも resources.hppのか?
- create()がファクトリー
- launch()
- src/slave/containerizer/containerizer.cpp
- Containerizer::create()
- つぎはdocker containerizerをよむ。
- containerizer/docker.hpp
- NvidiaComponentsってGPUかな。
- コードすかすか。実装はDockerContainerizerProcessにある。
- ____destroy(): アンダーバーで始まる名前は処理系予約だから使わない方がよいのでは。。。
- containerizer/docker.cpp
- DOCKER_NAME_PREFIX = "mesos-"
- DockerContainerizer::create()
- docker/docker.cppもある
- C++では定義(.cpp)のメソッド定義にはstaticはあらわれないので宣言(.hpp)をみる。
- もろdockerコマンドをたたいてる。APIつかってない。
- version >= 1.9.0.を期待しているっぽい。コマンドたたいて結果パースしている。
- ここまでで30分くらいと予想していたが45分経過。 [2016-12-15 19:17]
- 引数のescape処理してない。
- foreach: stout/foreach.hppか。独自マクロ多すぎ。予約語じゃないのでハイライトされてない。。
- Docker::run()でcmdがescapeなしに雑にjoinされているが、メッセージ表示につかっているだけなのでだいじょうぶか?
- subprocess探索のつづきはご自宅でどぞー
[2016-12-15 19:29]
- 現在 会場19人
- Q: javaっぽい書き方だけどメモリリークだいじょうぶ?
- A: OwndとかあるしlibprocessはGCスレッドがいるし。
[2016-12-15 19:37]
libprocess / @ashigeru
- 資料: https://github.com/kuenishi/mesos_scr_jp/blob/master/01/libprocess.md
- エディタはsublime
- 3rdparty/libprocessのした
- actor model (erlangにインスパイヤ)
- process = actor (unixのプロセスではない)
- local messaginとremote httpの両方がある。今回はlocalのみ。
- libprocess/README.md : githubで読むとサンプルコードがコメントアウトされていてみえないのでソースコードを直接見るべし!
- erlang styleとは? 気持ちはわかる。
- メッセージごとにスレッドをわりあてるのではなく、キューを用意して処理するモデル?
- futureとpromiseは今回無視する方向で。
- プロセスごとにスレッドは割り当てないので軽量。CPUの数+1くらいのスレッドプールをつくってイベントドリブンになっている。
- Process::dispatch()はメンバ関数と引数を渡すと実行される。
- ProcessBase: Processのいっこ上。プロセス実行環境みたいなもん?
- HttpProcess: とばします
- PID: unixのpidそのものではない。ProcessオブジェクトをつかうんじゃなくてPIDをつかう。PIDのリファレンスみたいなもん。
- process::initialize(): 機構の初期化。あちこちで呼ばれている。
- **/3rdparty/**, **/test/** はノイズ
- initialize()は何度呼んでもok.
- stout スタウト? エスティーアウト? mesosをつくっていた人がもともとつかっていたもの.
- 3rdpartyというorgnizaiton(github)がある。おもいっきりmesosの人。
- header only library
- Ownedはprocess版のとそうじゃないのと両方あってややこしい
- mesos-3rdpartyにtar.gzがごろごろ
- process.hpp
- ProcessBaseはEventVisiorを継承している。
- EventVisitorはvisitorパターンの実装。Event::visit().ダブルディスパッチパターンになっている。
- ProcessBase::serve()をよぶと自分のvisit()がコールバックでよばれる。
- MessageHandlerは関数で引数はUPIDとstring.
- あんまりピュアじゃない。HTTPのメッセージをルーティングする機能がある。たぶんMesosの前にやってた。
- process::diapatch()はprocess::internal::dispatch()のラッパー.
- 3rdparty/libprocess/src/process.cpp
- たいていclass ProcessManagerの中でいろいろやってる。init_threadが肝。
- process::initialize()
- initialize_startはatomic boolean
- 定番のSIGPIPEをSIG_IGN
- EventLoop::initialize()はあとでrun()する
- process_manager->init_threads()
- ProcessManager::init_threads()
- プロセス数が最低でも8なのは(コメントによれば)テストを通すためだけっぽい。。。
- workerはoperator()を定義していて
- process_manager->dequeue()はプロセスのキューになっている。
- worker_threadを登録する。
- ProcessManager::spawn()
- プロセスつくったらキューの末尾につける。
- __process__はthread local storageになってるっぽ。
- ProcessManager::resume()
- event->visit()
- ProcessManager::wait()
- process::wait(const UPID& pid, const Duration& duration)から
- WaitWaiterっていうのがいる
- Gateは待ち合わせ機構。approach()/arrive()はバリア同期?。
- wait()はyield()みたいなこともする。
- きほん non priemptive
- ゆうせんどもある?
- internal::dispatch()
- - プロセスマネジャにDispatchEventを送って
[2016-12-15 20:36]
2016年11月22日15:15Mesosソースコードリーディング第0回
- 2016-11-21 19:20〜21:40
- さくらインターネット 西新宿 セミナールーム
- イベント告知: https://mesos-scr-jp.connpass.com/event/43819/
- レポジトリ: https://github.com/kuenishi/mesos_scr_jp
- #mesosjp: http://togetter.com/li/1051421
雨はほぼ止んで新宿駅から徒歩15分で到着。循環バスもあるようだったが(途中写真撮ってふらふらしてたので)時間ぎりぎりで待ってるあいだに歩いた方が早いと判断。早足で歩いたので体があったまってしまった。暑い。
6Fに到着しても、どのドアも開かず。まるで会員制クラブのよう。。
[2016-11-21 19:21]
自己紹介
最初に軽く上西さんが会の主旨を説明したあと自己紹介(名前・所属・バックグラウンド・目的・興味があること・運営に関する質問)タイム。全23名。
[2016-11-21 20:04]
10000ft overview / kuenishi
- 10000ft overview
- ネットワークのdata plane control planeが分かれるように分散スケジューラも分かれた。大規模になると必然。
- ソースコードの統計: https://github.com/kuenishi/mesos_scr_jp/tree/master/00/mesos-gitstat
- だれがメイン開発者なのかなど
[2016-11-21 20:30]
Sorterについて / oza_x86
- https://github.com/kuenishi/mesos_scr_jp/blob/master/00/ozawa.md
- ソースコードを見ながら語るスタイルで。
- slaveはZKはservice-discoveryにつかっているだけ。slaveの耐故障性にはZKは関与してない。
- mesos/src/master/allocatorは短かい。
- sorterはallocatorになぜ必要か? 優先度の管理が必要だから。
- clientはframeworkだったりuserだったり。
- Sorter::sort()の実装はdrfの下にある。
- DRFComparatorはstd::setのソート関数でDRFSorterができてる。
- client.shareとallcationstとnameで比較している。
- DRF(Dominant Resource Fairness)とは?
- fairnessをCPU/MEM/GPUなど多次元で割合を計算する。
- DRFのいいところ:声が大きな人が勝たないように証明されている。
- frameworkの自己申告でリソース配分の割合をかえられる。role
- calculateShare()が計算しているところ
- 論文
- mesos.protoはコメントたっぷり(これは外向け)
- src/messages
- cpu 0%は上のレイヤでvalidatorではじいてるはず
- DiskInfoはユニーク。(YARNにないHDFSにまるなげ)
- hashmapは3rdpirtyのstout(includeするだけでつかえるべんりなやつ)
- DRFはfairになってる? ナッシュ均衡になってる? 最適ではなさそう。
- スケジューラはドメイン知識を入れると効率があがる。
- offerはofferを出すとoffered状態になってmasterは関与できなくなる。
- frameworkから要求量はしめせる?
[2016-11-21 21:39]