RubyWorld Conference 2011
RubyWorld Conference 2011に行ってきました。
会場には、無線LANのアクセスポイントも用意されてたみたいです。（詳細は、公式の告知ページをご確認ください。）
あと、WiMAXも使えてました。電源も休憩ポイントに用意されてましたね。
以下、聞いたセッションのまとめを、いくつか書いておきます。
また、間違いなどありましたら、ご指摘いただければと。
目次
「日本のRuby PaaS」立ち上げまでの道のり」
Webの記事：http://www.atmarkit.co.jp/news/201109/05/mogok.html
概要については、上記記事を参照してください。
ここでは、もう少し技術詳細に関してメモしておきたいと思います。
まず、Engine Yard社 (EY社)の「herokuのようなマルチテナントはクラウドに向いていない」という話に触れ、クラウドのあり方について論じておられました。
IaaSだってマルチテナントには変わりない、ということで、「大事なのはどのレイヤでどんな技術を使い、サーバを論理分割するか、を検討することだ」という方針を述べられていました。
以下、MOGOKで採用された方式について、各レイヤーごとにまとめます。
OSレイヤー
HV方式(Xen, KVMなど)や、Linuxコンテナ方式（OpenVZ, lxc）、chroot 方式を比較して、
リソース消費量が一番少ない、chroot方式を選択。
カーネルのインスタンスを共有するため、リソース消費量が少ない。
※ （個人的感想）けど、プロセスごとにリソース消費量を監視したり、作り込みが大変そう。あと、アプリのセキュリティとか、他プロセスを保護する機構とか。
その辺って、Linux でがんばってるのかな。
あと、スケールアウトってどうするんだろう。
Git を使ってデプロイ
詳しくは聞き取れてないので、省略します。
AP サーバには、Thinを採用。
Thinは、Ruby番の軽量サーバのこと。
Nginx + Passenger などもあるが、MOGOK では、以下の理由によりThinを使う。
OSレイヤーでchroot 方式をとっている。
なので、サーバリソースを制御するために、監視プロセスとWebプロセスを1:1で対応させるというアーキテクチャをとっている。
Nginx では、この方式が使えない。
Ruby on RailsのPaaS「RCloud」ができるまで
Ruby + CentOS or Solaris のバッドノウハウの発表ですね。
導入として、（意訳すると）Rails は、RADツールとして優秀で、ECサイトのアプリがJavaより作りやすかった。
あくまで基盤を運用してるときに直面した課題と、それをどう乗り越えたのかの発表。
503 エラーが頻発
原因は、mongrel のプロセス（？）が、200 プロセスも立ち上がっていて、スワップが大量に発生していたから。
サーバのメモリには、4GB 積んでた。
CentOS + REE 186 から、Solaris +Sun のサーバに乗り換えた。
mongrel のプロセス数の上限を 7にした。
そのほか
- アプリはメモリーリークが起こることを前提に運用せよ。
- ソフトウェア若化は、運用では大事。プロセスを定期的に再起動するとか。
- アプリを監視する方式も、HTTP HEADではだめで、ちゃんとGETで取って、レスポンスタイムも監視する。
- レスポンスタイムを、SLAの一つとして定義しておくって話ですね。
- Radiant CMS は、extention ごとに、dbのmigrate, update が必要。だから、管理が大変。
- Rails アプリを作る際のバットノウハウになりそう
1.9.3 リリース、そしてRubyのエンタープライズ分野への適用の可能性について
- better GC
Lazy Sweep GCが実装されたそうです。
詳細は、以下の記事を参照してください。
http://www.infoq.com/jp/news/2011/08/ruby193-gc
- better GVL (Gloval VM Lock)
fairness issue の問題。
最近の、メニーコアなCPUでは、ruby マルチスレッドの実行の際に、CPU時間の配分が不平等になることがある。
原因は、GVL の仕組みと、最近のIntel CPUの相性が悪いからだそうです。
詳細は、以下のスライドで説明されてます。
http://www.slideshare.net/kosaki55tea/ruby-gvlimprovement-8617719
- Power Efficiency
昨今のデータセンターや、HPCでは、省電力が重要。なので、短いsleep, timer発火させてるアプリは、敬遠される。
Rubyではマルチスレッド用に、タイマースレッドがある（コンテクストスイッチをやるため、だったと思う）。
それが、PowerTOP に邪悪なアプリ認定をされてしまうので、それを改善したそうです。
そのほか、いろいろ細かい不具合が修正されているそうです。タイミング依存のバグとか、レビューでしか見つけられないバグが多い。
また、Rubyのコミッターは、Linux コミッターと違い、Rubyのコードの広い範囲に対して、知見を持っているんだとか。
最後に、Rubyのtrunkを試してくれる人柱の人が増えると、コミュニティ的にいろいろありがたいそうです。
Rubyコミュニティは慢性的な人不足だそうで。
いっぽう、Rubyのコミュニティってすごい人がおおいから、コミュニティに参加するのもハードル高そうですよねぇ。と勝手に思ってしまうのです。
Advancing Net::HTTP
Rubyで nonblocikng io api がほしいという話です。
あと、Net2::HTTP という、ノンブロッキングなHTTPライブラリが欲しいとも。
リアクターパターンの説明をされてたんですが、すみません、あんまり聞き取れませんでした。
イベント駆動なプログラミングモデルって理解でいいのかな。
node.js って単語も出てたし。
Cloud Foundry: Why Ruby, and will it last?
資料は以下を参照。
発表資料： http://j.mp/rubyworld2011
CloudFoundry には、ローカル環境用のMicro Cloud Foundryというものもあり、ロードバランサなどの機能がないけれど、基本的に同じ構成なんだとか。
試してみたい人は、がんばってダウンロードしてみてください。
会場では、Micro Cloud Foundry入りの、Original USB Memory が数個ほど配布されてたみたいです。
Cloud Foundryは、Rubyを使って実装されてるみたいで、EventMachineやFiber などを使ったら、パフォーマンスも十分なものが作れたって話だったと思います。
それに、Chefとか優れたデプロイメントツールもそろってる。
あと、SPoFの回避・ステートレスってのが、スケールアウトには大事だよねぇと、分散システムの基本もおっしゃってます。
そんな中、ACIDトランザクションをやるなら、どうしたらいい？ っていう質問が出てました。（というか、しました。ちょっと場違いだったですね。結果整合性って単語が出てたので、そこんとこ、ちょっと気になりました。）
まず、Cloud Foundryでは、MySQLとかが使えるので、それを使う必要がある。
また、ACIDトランザクションが必要であるとともに、パフォーマンスが求められるなら、それはソフトウェアで解決するべき問題ではない。
やっぱり良いハードウェアを買う必要があって、Fusion IO社のソリューションだったり、SSDだったりを使うほうがいいんじゃない、っていうことをおっしゃってたと思う。
Heroku – 多言語化するアプリケーションの為のプラットフォームの紹介
- 「適切な道具を選べ」
- プログラマにアジリティ・生産性を与えてくれる
昔は、道具（プログラミング言語、フレームワーク、ツール）の使い方を学ぶのに時間がかかった。
でも、今は、screencast など各種チュートリアルや学習環境が整備されているので、学習にかかる時間が短縮された。
その結果、Polyglot Platform が現実的になってきた。
また、「適切な道具を選べ」という話は、言語だけでなく、PaaSにもいえる話だそうです。
ECサイトは、heroku、トランザクションが必要な処理は、Salesforce と組み合わせて使う事例も紹介されていました。
関連記事：http://blog.heroku.com/archives/2011/8/3/polyglot_platform/
併せて、私がheroku (Rails) に触ったときの記事も読んでもらえたら嬉しいです。
- id:nshibazaki:20110723 - 環境のインストール。
- id:nshibazaki:20110724 - MessageBoard アプリのデプロイ。
- id:nshibazaki:20110730 - PostgreSQL(共有プラン) を少し触ってみる。
