Dive Into Python

読書 python

Dive Into Python

Dive Into Python

上の"Dive Into Python"という本がなぜかここで無料で公開されているので、読んでみている。ちょっと前に、「みんなのPython」買ってちょいちょい読んではいたけど、こっちの方が面白いかも。
Python、確かにシンプルだし書きやすいなぁ。
あと、このDive Into PythonのChapter 4に"The Power Of Introspection"ってのがあって、Introspectionってなんだ？？日本語だと内観？？哲学関係か？？と思ってたら、オブジェクトの属性やメソッドを動的に見たり、書き換えたり出来ることを指しているらしい。これってリフレクションと違うの？？*1
というわけで、結構柔軟性高そうなんでいじってみるのも面白そうだ。

*1:この辺りは良く知りませんが

麻原彰晃の誕生

読書

麻原彰晃の誕生 (文春新書)

麻原彰晃の誕生 (文春新書)

読んだ．はじめの方は、松本智津夫の生い立ちについて結構細かく説明していて、興味深かったのだが、後半のヒヒイロカネに関する記述はやや冗長なように思えた。*1オウムや麻原彰晃の原点を考える上で、欠く事のできない事柄だったのかもしれないが、そこから麻原本人の話にあまり繋がってこなかったのが残念だ．
ただ、著者が「何度かオウムに対して共感したこともあった」といった感想を持っている事は、なかなか感心した。自分とは違う世界の話として捉えちゃうと、何も考えられなくなっちゃうもんね。

*1:amazonの書評にも同様の感想を書いている人がいた

The History of Haskell, Simon Peyton Jones, Paul Hudak, John Hughes, and Philip Wadler

Haskell 論文

最近久しくHaskellを触っていないわけですが、こんな論文(?)見つけました。まだまったく読んでないです。
どうやらHistory of Programming Languages Conference*1という集まりがあるらしく、本稿はその2007年に投稿したものみたいです。まだドラフトなのですが、著者陣が超豪華(Haskell界でだけど。。)なので、読んでみると面白いかもしれん。
しかし、Haskellの歴史を語るのに50ページもかかるとは。。

*1:2007年で三回目だと。存在を知らなかった。

The Design and Implementation of Zap: A System for Migrating Computing Environments(2)

論文 VM

昨日の続き。
昨日のエントリの最後で挙げたような点を解決したプロセスマイグレーションのシステムをこの論文では提案している。
そういったプロセスマイグレーションのシステムを作る上で、以下のようなことを考えないといけない。

  • プロセス情報の一貫性
    • プロセス情報とは、PID、ソケット番号など
    • 一度割り当てられたら、変更してはいけない
  • リソースの衝突の回避
    • ホスト内ではプロセスはユニーク(PIDがかぶってはいけない)
  • プロセスの独立性

三つ目の独立性について、もうちょっと説明する。例えば、あるプロセスを移行しようとしていたときに、そのプロセスが移行前のホストで他のプロセスとメモリを共有していたとする。そういったときに、何も考えずにプロセスを移行してしまうと、共有していたメモリの一貫性が失われてしまうため、どうにかしないといけない。例えばそのときに、移行前のホストにプロキシのようなプロセスを立ち上げて、移行後はそのプロキシを介して共有していたメモリを操作する、という解決策が考えられる。しかし、こういった解決策を取ると、移行前のホストがダウンしただけでそのプロセスは処理を続けることが出来なくなってしまう。こういった状況をホスト間の依存関係と読んでいるわけで、この依存関係が生じないように、システムを設計しないとまずいよね、というお話でした。
そこで、上で挙げたような用件を満たすプロセスマイグレーションシステムを本論文では、提案しているわけだが、これはプロセスを仮想化して実現している。
このシステムでは一つのホスト内は、以下のような構成になっている。(これは、私が勝手に書いた図)

この図の中で、podというのがキモで、いくつかのプロセスをグループにまとめて管理・仮想化するレイヤーである。このpodの基本的なアイデアは、依存関係のある(例えばメモリを共有しているとか)プロセスはまとめてしまい、外のリソースとのやり取りを管理しましょう、というもの。そして、マイグレーションは、このpod単位で行うことで、移行先の環境で名前空間が衝突したり、移行前の環境に依存することがなくなる。
それでは、podを使ってどういった仮想化を行っているかを説明しよう。
podでは、以下の四つを仮想化している。

これらについてここから一つずつ説明していく。

プロセスの状態

このpodは、プライベートな仮想名前空間を持っている。そうすることで

  • pod内では、プロセスの情報(PIDなど)がユニーク
  • podの外部のリソースを隠す

といったことが可能になる。
つまり、ホストとは独立なPIDをpod内で割り当ててあげて、podのレイヤーで実際のホストから割り当てられたPIDとの対応表を覚えておくのである。すると、マイグレーションをしたときに、その対応表を書き換えてあげるだけで、プロセスとしては常に一貫したPIDを使うことが可能となる。
そして、マイグレーションを行う際には、

  • プロセスとグループのID
  • CPUレジスタの内容
  • シグナルハンドラ
  • IPC(プロセス間通信)用のキーと状態
  • パイプ

を、保存する。

メモリ

メモリの仮想化は、OSの仮想メモリで実現されているので、それをそのまま利用するだけ。
そして、マイグレーション時には、

を保存する。

ファイルシステム

ファイルシステムは、/tmpや/localといったホストによって異なるディレクトリは、各pod用に個別のファイルシステムを用意するという方法で対処している。
より具体的には、どこかにストレージサーバを立てて、NFSで各pod用のファイルシステムをそのサーバに用意する。そうすることで、プロセスが移行してもそのサーバを見ればいいだけなので、解決される。

デバイス

/devもファイルシステムと同様にpodごとにマウント。
(ここよく読んでない。。)

ネットワーク

以下の三つの機能を提供している。

  • pod内のプロセスにリモートから通信可能
  • マイグレーションしても、アプリケーション層のインターフェースは変わらない
  • マイグレーションしても、オープンコネクションを保存できる

[ここは後で書く]

以下、所感。
全体的にうまくやっていると思った。ただ、いくつか気に入らないところもあった。
まず、一つ目として、ファイルシステムの仮想化、というかネットワーク越しに管理しているだけ、はどうかと思う。この論文の初めの方に、ホスト間の依存関係は良くない、とか言ってるけど、ファイルシステムの所ではストレージサーバに物凄く依存しているわけで。まあだからといって、他のいいアイデアが私にあるわけでもないのですが。。。
もう一つは、ネットワークの扱いのところ。最初、論文の概要を読んでいたときに、コネクション保持したままマイグレーションできるとか書いてあるから、すげーーと思ったけど、クライアント側でもアドレスを仮想化しないといけないのね。。
気になるのは、この二つかなぁ。
あと、どうでもいいけど、この論文すごく読みやすかった。まとめ方と例の使い方がうまい。いい。

追記
こちらのサイトに同じ論文のまとめがあった。元の論文に忠実な感じでいいです。

The Design and Implementation of Zap: A System for Migrating Computing Environments, Steven Osman, Dinesh Subhraveti, Gong Su, and Jason Nieh, OSDI 2002

論文 VM

プロセスマイグレーション（あるコンピュータ内のプロセスを、別のコンピュータに移す事）の研究。
プロセスマイグレーションが実現すれば、分散環境で以下のようなメリットを得る事ができると述べている。

  • ダウンしたホストからプロセスを移す事でサービスを維持できる
  • ユーザの近くにプロセスを持って行く事で、レスポンスが改善される
  • 負荷の高いホストから、負荷の低いホストにプロセスを移す事で負荷分散できる
  • あるホストのメンテナンス時には他のホストにプロセスを移す事でサービスを維持したままメンテナンスができる

結構色々うれしい事が多い。これまでも様々な手法が提案されたが、実用には難しいらしい。*1
プロセスマイグレーションを実用的に使うには、以下の四点が満たされているべきだ、と筆者らは述べている。

  • 既存のアプリケーションに対して修正を施す事なく使う事ができる
  • 既存のOSに対して修正を施す事なく使う事ができる
  • プロセスを移行する際に、移行前のホストと移行後のホストの間に依存関係を作らない（例えば、プロセスが移行した後も、移行前のホストに何かの処理を委託する、とかはだめ）
  • コストが現実的

[んー、眠い．．また明日]

*1:現在では、VMwareのVMotionが実用化されてるけどね

Using Time Travel to Diagnose Computer Problems, Andrew Whitaker, Richard S. Cox, and Steven D. Gribble

論文 VM

コンピュータの設定を変えて、システムの挙動がおかしくなる事はよくある。それを、システムの設定の変更（というか、ディスクの内容の変更）を保存しておく事で、きちんと動作していた状態に戻しましょう、という話。
これを聞いただけだと、Windowsのチェックポイントを選んでシステムの状態を戻すやつ（なんて言うんだっけ？システムの復元とかだっけか？）と変わらないように聞こえる。だが、本論文で提案する手法を使うと、

  • いつの時点に戻せばよいかを人間が知っている必要がない（この点は、複数のユーザが使うシステムや、デーモンが勝手に設定書き換える場合などにうれしい、と著者らは主張している。）
  • どの設定の変更がまずかったのかが、本論文で提案される手法だとわかる

というメリットがあるらしい。
んで、本論文で紹介されている手法は、Chronusというシステムで実装されている。
このChronusは、以下のものから構成される。

  • タイムトラベルディスク:ディスク変更のログを保存するところ
  • 仮想マシン
  • 解析エンジン:過去の変更を見て、どこでシステムがおかしくなったかを検出するためのエンジン
  • 検査コード:システムが正しいかどうかを判定するためのコード。これはユーザが書く。



なんで、仮想マシンが必要かというと、システムがおかしくなった場合、OSインスタンスを別に動かして、そこでタイムトラベルディスクから昔のディスクの状態をとってきて、検査コード走らせてどこでおかしくなったかを調べるため。タイムトラベルディスクでは、ディスクに対する変更のログが時間順に保存されているので、二分探索を使ってどの変更で検査コードにひっかかるかをみていく。
それで、どのバージョンでおかしくなったかがわかったら、現在のバージョンとのdiffを出力すれば、どこの設定変更でおかしくなったかがわかる、という仕組み。
以下、所感。
検査コードをユーザに書かせるの、いけてない。
どのくらいコストがかかるのか記述されてない。。VMMの上で動かしたりしてるから結構オーバーヘッドありそうだなぁ。しかも、一つのバージョンの設定を検査するのに対して、一つの仮想マシン動かしてるから、検査も時間かかりそーー。。
うーん、全体的に結構いまいち。