docker meetup #3

概要

• 日時 6月4日 @日経ホール 19−22時
• 参加者数 240名？ なんと2時間で枠がうまったという。。たまたまTwitterを見ていて気がついてよかった。
• NII 横山先生もいらしていた。
• コンテナ＋スタッカブルファイルシステムというどこかで聞いた技術。コンテナのレポジトリがあるというのがポイントなのか。

講演

通常発表

• 19:00 @philwhln - Orchestration Tools
  さまざまな周辺技術の紹介？
  焦点がよくわからなかった。
  stackato というPaaSを作っているのだが、独自のLXCレイヤを捨てて
  dockerに移行したとのこと。
• 19:30 @stanaka - Dockerでデプロイ&モニタリング(仮)
  はてなのCTO。
  • コンテナのなかからcpu usageとかをとると、基本的にホスト全体の値が取れてしまってコンテナの数値が取れない。なので、基本的には、ホストの方で、cgroup のお作法にしたがって、やればよい。/sys/fs/cgroup/xxxx/ を見ればいろいろな情報が取れる。
  • デプロイに関してはdocker hub を使って、自動ビルド。さらにwebhook とhubotで自動起動までできそう。
  • Mackerel という社内ツールの紹介。名前はサーバ→鯖から。ロールと言う単位でホスト群を一括管理。
  • 20:00 @mainyaa - Dive into Dockerネットワーク
    トップゲートの方。dockerでクラスタ的なものを作る際のネットワーク設定のオプションには次の３つぐらいがある。
  • -link
    ホスト内ネットワーク。IPを調べるのが面倒とのことだが、自動化すればいいので特に問題にならないだろうと思う。複数ノードに展開はできない。
  • host network
    いわゆるブリッジ。セキュリティ的にいかがなものか。isolation にならない。
  • open vswitch
    GREトンネルでホスト間にも使える。ある意味一番簡単。
  • 20:20 @deeeet - Flynn（仮）
    OSS のPaaSであるFlynnの紹介。HEROKUっぽい。EC2などの上に、独自のPaaSを展開することができる。コンテナを Docker Hubにあげておき、自動的にデプロイさせるとのこと。どんな言語でも対応できるというのが強みか。

  21:00 LT（1人5分）

• @mopemope - How to Impl lib swarm backend
• @peryaudo - Docker+CoreOS+GCEで自動スケール分散レイトレ
  タイトル通り。
• @kzys - Porting Docker to FreeBSD
  これも。まだできてない。Jailでやるとのこと。
• @nasunom - perfomance Evaluation of Docker
  横山先生と一緒にやっているというかた。外注か。AUFSのwrite が遅いので気をつけましょう。というのが結論か？
  • @y_matsuwitter
    gunosyの方。docker file がモノリシックなので、同じようなものをたくさん書かなければならなくて大変。ということで、複数のサブファイルをマージするツールを作成したとのこと。
    しかし、docker fileってそこまで頑張っちゃうものなんだろうか。shef をきどうするだけ、とかいう感じのほうが良かったりしないのか。本番環境もdockerにするというのなら別だが。。

調べること

• etcd
• consul
• mesos
• core OS
• libswarm
• hubot
• fleet
• surf ? serf?

​

MillWheel: Fault-Tolerant Stream Processing at Internet Scale

MillWheel: Fault-Tolerant Stream Processing at Internet Scale

SaTyler Akidau, Alex Balikov, Kaya Bekiroglu,Slava Chernyak, Josh Haberman, Reuven Lax,Sam McVeety, Daniel Mills, Paul Nordstrom, Sam Whittle

Proc. of Very Large Data Bases 2013, pages 734-746

Googleの イベントストリームプロセッサ。やっていることはよくあるもので、パイプラインと計算ノードを定義してやって、そこにイベントを流してやって処理するというものなのだが、自動負荷分散したり、永続ストレージを持っていたりと芸が細かい。

- exactly once セマンティクスをサポート。背後に持っているストレージに書き込むことで、2重に実行しないようにしている。さらっと書いてあるけど相当な難しいことである。さらに、それでもレイテンシが数十ミリ以内に収まっているのも驚き。。

- 論文のサンプルからはC++で書かれているように見える。

​

Flume Java

#FlumeJava: Easy, Efficient Data-Parallel Pipelines

Craig Chambers, Ashish Raniwala, Frances Perry, Stephen Adams, Robert R. Henry, Robert Bradshaw, Nathan Weizenbaum
Google, Inc

Proceeding of PLDI '10 Proceedings of the 2010 ACM SIGPLAN conference on Programming language design and implementation

Google論文。MapReduceを置き換えるものとして開発されたJavaのデータ並列ライブラリ。記述力としてMapReduceのスーパーセットであるという主張。複数ノードにまたがる（かもしれない）一連のデータに対して、データ並列でワークフローを書く。この形だとMapとReduceの区別が無く、ほぼフラットに書ける。GroupByという演算があり、これがMapReduceのシャッフルフェーズに相当する。

データ構造はimmutable で次々にデータ構造を作るようになっているが、実際には評価が遅延され、最後の結果を評価したところで、処理のツリーを最適化してから評価するという作り。最終的にはかなり複雑な評価式も一段のMapReduceに落として処理しているとのこと。

たしかに、MapReduceでグリグリ書いていくよりも、ずっと楽だろう。

２０１０年の論文という点を割り引いても、新規性があるとは思えないが、やはり超大規模環境でちゃんとやってるのが偉いっていうことなんだろう。

ページキャッシュ最適化手法におけるベイズ的アプローチの検討

OS-126
ページキャッシュ最適化手法におけるベイズ的アプローチの検討
高橋 一志, 佐々木 慎, 松宮 遼, 大山 恵弘

笹田さんのところにいた高橋さんが大山さんのところに行ってやってる仕事。 分散ファイルシステムを効率的に運用するためには、環境内の他ノードに存在する オンメモリのキャッシュを効率よく利用するが必須であるとし、 そのために、ベイズ統計の利用を提案している。

ちゃんと読めていないが、結局各ブロックデータにコンテントハッシュでIDを振り、 個々のブロックへのアクセスのトレースを取って、各ブロックへのアクセス頻度を 抽出。で、その頻度間の距離の遠近で最も近い所にキャッシュを探しに行く、ということか？ 特定のブロックのリードがサイコロと同じように相互に独立だ、という過程はかなり 無理があるように思うがどうなんだろうか。

実験結果を見てもまったく思ったとおりに動いていないようだが。。

動的適応可能な分散ファイルシステムの提案

OS-126
動的適応可能な分散ファイルシステムの提案
孫 静涛、 佐藤一郎

若干、と言うか相当、日本語がおかしい。と思ったけど、私の英語よりはずっとマシなことは間違いない。 日本語の論文誌を維持するには、この程度のおかしさは許容していくべきなんだろうなあ。。 国際化のひとつの方向性として。

内容的にはアイディアを表明しただけの論文で実装はまだない。 通常時は一つのサーバを複数のクライアントが共有するクライアント・サーバモデルで 運用するが、負荷が増大した際には全てのノードのクライアントとが 協調動作するP2P型ネットワークとなる分散ファイルシステムを提案している。 で、そのソフトウェア移送をエージェントでやると。

データはどこにある前提なんだろうか？ いずれにしろ、ぱっと見では、あまりメリットがあるようにも見えない。いいんだろうか。

システム状態の変化にロバストな異常タスク特定手法を 備えた MapReduce タスクスケジューラ

システム状態の変化にロバストな異常タスク特定手法を 備えた MapReduce タスクスケジューラ
浅原 理人, 藤森 偉恭, 成田 和世, 劉 健全

task の粒度が同一だと仮定できる場合、bag of task処理の終盤で、 処理が何らかの理由で滞っているとかんがえられる task を キャンセルし、他のノードで実行することがある。 しかし共用環境においては、正確に処理の遅延が判断できないため、 無駄にtaskをキャンセルしてしまう可能性がある。

この論文ではより正確な予測を行なうために、タイムウィンドウを用いて 参考にするタスクを絞り、ポアソン分布に従うと仮定して タスクの所用時刻を予測する。

キャンセルしないで、平行して実行すればどっちにしろ 無駄にはならないような。。

クラウド上の仮想マシンの安全なリモート監視機構

OS-126
クラウド上の仮想マシンの安全なリモート監視機構
重田一樹、光来健一

九工大のグループ。IaaSクラウド上でIDSを用いるはなし。 仮想計算機を使ってホスト側にIDSを動かすのはよくある話。 クラウドだと、ホスト側が必ずしも信頼出来ないので、 IDS本体はリモートの信頼できるサイトで稼働させる、というおはなし。 RemoteTransというのがシステム名？
技術的にはTransCallという、ゲスト内にシステムコールをフックして ホスト側に飛ばすライブラリをネットワーク経由で飛ばせるようにしているようだ。
IaaS事業者は信頼するが、管理VMから他のVMを管理している管理者は信頼しない、すなわち VMMは信頼できるが、他のVMは信頼出来ない、という脅威モデル。 かなりピンポイントというか、今ひとつリアリティのないモデルのような気がするが。。