OSv—Optimizing the Operating System for Virtual Machines

ここからダウンロード。

うわさの OSv。このペーパーを読んで何が驚いたかって、”v”が下付きではなく上付きだったこと。えー、そうなの？？スライドとかでも、上付きになってるの見たこと無いけど。。

• 単一アプリをラッピングしてIaaS上で動かす軽量OS。JavaVMが最初のターゲットだったが、今は色々動く。
• C++でスクラッチから書かれている。
• プロセスは一個だけしか動かないが、スレッド的に複数のアプリを動かすことが実は可能。ただしメモリは共有される。
• それどころか、アプリとカーネルの間でもメモリ空間は共有。というか、基本的にカーネルとユーザランドの区別が無い。アプリにOS機能を直接リンクするイメージに近い。
• 1秒で起動するとのこと。
• 用途はアプライアンスだろうか。
• 直接の対抗馬はコンテナ技術か。コンテナよりはきっちりアイソレーションできそう。マイグレーションとの相性も良さそう。コンテナもマイグレーションできるそうだが、プロセスマイグレーションの経験から行くと、VMマイグレーションとは比較にならないほど面倒なので。

​

DBToaster: Higher-order Delta Processing for Dynamic, Frequently Fresh Views

DBToaster: Higher-order Delta Processing for Dynamic, Frequently Fresh Views

Yanif Ahmad, Oliver Kennedy, Christoph Koch, Milos Nikolic,

Peoc. of VLDB 2012 pp.968-979, 2012

• DBアクセスを高速化する方法としてview を構築しておく方法がある。
• しかし、頻繁に書き換えられるDBではviewの書き換えが多発する。
• これをIncremental にやることで解決する。
• 具体的には差分を意味するΔview も持っておき、データ入力でこのΔを変更する。
  そしてΔを使って元のviewを変更する、というように再帰的にやるらしい。
• ストリームシステムSPYよりも圧倒的に速いという結果。というかこのSPYは
  妙に遅い？？

​

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauley, Michael J. Franklin, Scott Shenker, Ion Stoica
Proc. of NSDI’12, 2012

• UCBのチーム
• Resilient Distributed Datasets というものを提唱。これはFlume JavaのPCollectionとほぼ等価に見える。
• lineage (家系）という概念を導入。要するにどのようにしてそのデータセットが計算されたかの履歴。いつでも再計算できるようにしてFTを実現。これだとiteration があると大変なことになるので、適宜スナップショットを併用する。
• Spark 上に実装。
• Iterative なジョブでHadoopと比較している。

​

Presto SQL Engine

Hadoop Conference Japan 2014 のTD古橋さんによるPrestoのお話

参加するつもりだったのだけど、変な会議のせいで参加できなかったhadoop conferenceでの講演資料がアップされていた。ありがとうございます

• SQLエンジン。HDFSに対して処理を行うだけでなく他のSQL的にアクセスできる
  DBに対するラッパとしても機能する。
• アーキテクチャとしては、複数のWorkerをCoordinator が束ねる。CoordinatorはリクエストのSQLを解析してプランニングを行い、個々のWorkerに行なうべき動作を指示する。Workerはコネクタプラグインを介して、バックエンドのDBにアクセスする。
• workerでの処理はオンメモリ。メモリに乗らないものは扱えない。
• プラグイン
  • Javaでかく
  • Hive,Cassandra, JDBCがすでに用意されている。
  • SchemeとRow を提供する機能があればよい。
• Prestogres
  • PrestoのフロントエンドはSQLになっているのだが、ここにアクセスさせる
    アダプタを書くのが面倒
  • Postgresqlをフロントエンドに持つことで、アダプタ実装を回避。
  • 枯れたPostgresql用のアダプタでアクセスできる。

Presto - Hadoop Conference Japan 2014 from Sadayuki Furuhashi

​

apache S4

論文

• S4: Distributed Stream Computing Platform
  Leonardo Neumeyer, Bruce Robbins, Anish Nair, Anand Kesari
  Proceedings of the 2010 IEEE International Conference on Data Mining Workshops, Pages 170-177, 2010
• Performance Evaluation of Yahoo! S4: A First Look
  Chauhan, J; Chowdhury, S.A. ; Makaroff, D.
  Proc of .P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), 2012 Seventh International Conference on
  pp. 58-65, 2012

所感

• 2010年にYahooが発表したフレームワーク。その後apacheに移管されたが、あまり話を聞かない。
• ストリーム処理を連続したイベントの処理として考え、イベントをノードが投げ合う。イベントを受け取ったノードはイベントを作成して送出する。
• KVペアをベースにキーで分散先を指定して投げつけるというつくり。キーが同一であれば一つのノードに行くはずなので、そこで集計処理ができる。つまりシャッフル相当のことがこれで実現できている。なので基本的にはMapReduce ができる。
• ただし一つのキーに対するreduce 的処理を分散して実行する事はできない。これはHadoopでも一緒だが。
• そもそも、統計的に処理をすることを前提としているので、イベントを落とすことをなんとも思っていない。負荷が上がるとどんどん落とすつくり。まあ、それでいい場合も多かろう。
• 2010年に論文を読んだ時の印象としては、かなりプリミティブで負荷分散とかうまくいかないだろうなあ、というかんじだった。性能もなかなかくるしそう。FTについてもあまリ考えていないのかなと。
• 2つめの論文は評価論文。でも台数も少ないし、ワークロードもスタティックでデータのロスレートを見るというぐらいであまリ参考にならない。

​

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は信頼出来ない、という脅威モデル。 かなりピンポイントというか、今ひとつリアリティのないモデルのような気がするが。。