QCon Tokyo 2010 に行ってきました (二日目)

昨日に引き続き、二日目のレポート。


Scaling Memcache at Facebook

二日目、会場入り。ちょっと早く一番乗り。今日は朝から Facebook の memcache のお話。カサンドラは鬼の哭く街。 #QConTokyo

http://twitter.com/tksmd/status/12486857553

と、やる気満々な感じで一番乗りしつぶやいてみるも、カサンドラの話は一切なく。ま、それはそれでよかったのですが。。。

memcache が支えている、facebook の規模のお話から始まったのですが、トラフィックGoogle を越えた だけあって、秒間 4 億超の get や、2800 万超の set など、想像を絶する世界。その中でも memcache が果たしている役割は、その規模感からみても相当大きいようです。

まず、memcache の利用の前提条件は以下の通り。

  • 基本的な GET はまず memcache から
  • 更新時には DB 情報を変更し、memcache の値を invalidate
  • DB の行に対して memcache を対応づける

これらを元に様々な工夫をしたとのことで、興味深かった点を抜粋。

  • ネットワークトラフィックのオーバヘッドが大きく、(この辺りは昨日の Coherence にも通ずるのですが) 、TCP輻輳を避ける為 UDP に実装を変えた
  • オブジェクトのシリアライズを Thrift のフォーマットに変更したら、3 倍早くなり 30% ほどサイズが小さくなった
  • 複数データセンター間での memcache の同期の為に memcache proxy を利用している、また MySQLレプリケーションをした後、更新情報を同期する用途にも memcache proxy を利用している
  • HotKey に対応するために、Key 自体もレプリケーション (alias と言っておられました) し、負荷分散。また、他にもアプリケーションのアップデート時に、複数のアプリバージョンからのアクセスがある可能性もあるので、アプリケーションのバージョンを Key に入れるなど、Key 自体の値の持たせ方にも色々工夫をしている
  • 構成変更のテストは、python と ctypes を使ってやっている、一台のマシンでも複数の memcache インスタンスを立ち上げたり、構成を作るのが簡単だから、簡単なものなら、数十分で回帰テストを回せる

Twitter と同様、Facebook でも、トラフィックの増大にあわせて、色々とその形態を変えていっているとのこと、「ゲームのルールは刻々と変わる」という点も、Twitter の Nick さんの 「全ての対応は transient なものなんだ」と言っていた事に通ずるように思いました。

終わった後に、Twitter の Nick さんと話しているのを見かけたのですが、こういった形での交流を自然に出来るようになりたい。。。がんがれ > 自分

Javaにおけるモジュラリティ元年

id:kompiro さんによる、OSGi と Project Jigsaw を材料に、モジュラリティについて、その有用性を説いたお話でした。こちらで資料も公開。

現在、自動車で利用されているコード総数はなんと 1 億ステップもあるとのことで、また、全世界で保守されているソフトウェアのコード数も、7 年毎に倍になっていっているそう。その観点でいっても、モジュール分割し、適切な規模に問題領域を限定し、保守性を高めていくことは重要との話には、まったくもって同感でした。

Java では、そのモジュラリティを実現するために、既に Eclipse などで実績もある OSGi と、Java7 から搭載される Project Jigsaw が選択肢になるのですが、その各々について現在の立ち位置なども含めてお話されていました。

  • 「再利用」の考え方には「機能軸」と「時間軸」がある。時間軸というのは、あるモジュールを未来にも安全に使い続ける事が出来る、ということ。
  • 開発にかかるコストは三倍くらいかかるので、適用する規模の見極め重要
  • OSGi と Project Jigsaw は歩み寄ったらしい (OSGi Bundle が Jigsaw でも利用可能)
  • Linked in は OSGi でシステム構成を刷新 (資料発見)

規模にもよりますが、ウェブの場合だと、Control 層 - Service 層 - Dao 層といった形の層軸で、分割するケースが結構多いと思うのですが、OSGi の場合は機能軸でのアーキテクチャ分割をするようになるので、その点アーキテクチャ設計のイメージ変えていかないといけないですね。

私としては、モジュール分割もそうですが、何より OSGi はその動的構成の部分がすごく気になる所ではあります。ここが上手く動けば、稼働中のシステムの一部のみを、更新したりといった事がより柔軟に出来そうなので。メリットとデメリットよく把握した上で、使える所では使っていきたいな、と思いました。すごく勉強になりました。

「ビューティフルコード」とRubyの思想

Tuigwaa の時以来 (?!) の久しぶりのまつもとさんのお話。タイトルにもある通り、コードの美醜についてのまつもとさんの考えや、その視点からみたときの「Ruby の思想」といったお話。一番印象に残ったのは、Ruby には

  • プログラマに対する信頼 = 自分で作ったものは自分で責任をもつ
  • プログラマに対する自由 = その信頼のもとに、最大限の自由を与える

という思想がある、と。これだけで十分良い話が聞けたように思います。

「ビューティフルコード」は積み読み状態になっているので、今読んでいるガベージコレクションのアルゴリズムと実装を終えたらこれを読もう。

デザインパターンの "本当の" 使いこなし

デザインパターンを適用する意味や、その扱いについての注意事項、各パターン間の関係などといった、デザパタ全般に関わるお話でした。要約すると、デザパタの「解決」の部分を鵜呑みにして、そのままのモノで使うのではなく、そのトレードオフや考え方の根本を理解した上で、さらにその開発に置ける「フォース」に従い、採用のするしない、適用の仕方などを考えましょう、といった所。

で、お話の内容はまったくもって同意出来る話でしたが、デザパタを使ったり、試行錯誤した事ある人にとったら、ある意味当たり前の事が多かったように思いました。勿論それを整理し、抽象度 (デザパタから、別のデザパタへの参照数と被参照数の差) を利用して構造化してとらえたり、といった部分は面白かったのですが。。。

どうしても一般論に落ち着いてしまうのはしょうがないとは思うのですが、例えば典型的なソフトウェア (ウェブとか GUI とか、ミドルウェアとか、フレームワークとか、なんでもよいのですが) でよく使われるパターンであるとか、最近のアプリケーションアーキテクチャにおける新しいパターンであるとか、何がしか、そういった具象の話ももっと交えた形でお話聞きたかったなぁ、と思いました。

Failure Comes in Flavors

運用後のシステムのトラブルシューティングから、共通のアンチパターンを見いだし、開発時点で気をつけないといけない所を「やってはいけないこと」な視点からお話されていました。「障害は発生するもの」として、アーキテクチャや設計を考える、という基本スタンスは肝に命じておこうと思いました。

  • 結合点 (Integration Point と言っておられました、ネットワーク、DB、ファイアーウォールなど) は最も障害が発生する可能性が高いので、それらを利用する部分では、タイムアウト処理を入れ、「永遠に待つ」事だけはしないように。
  • CircuitBreaker (ブレーカ) のような仕組みを、結合点毎に入れておくと良い事もある。ブログ でも幾つか紹介してるよ、とのこと。
  • ある層 (ex. アプリケーションサーバ) を負荷分散している場合、あるノードが落ちた場合、相対的に他のノードの負荷が高まり、結局芋づる式に全ノードが落ちてしまう事がある。そういった場合には縮退したり、またその層のサービスが全部落ちたとしても、全体が止らないような作りにしておくこと
  • 本番環境との差異を認識しておくこと、特にスケールについて、2 台のテスト環境では起こらない事が起こる可能性がある。またテストを刷る際のデータは本番環境を不要な個人情報などをスクラブしたものを利用するのが良い

最後になったので、僕が息切れしていた感は否めず、少し聞き違えてる所もあるかもです。。。ともあれRelease It! 本番用ソフトウェア製品の設計とデプロイのために は読んでおこう、というのが感想。。。

余談

  • もう少しちゃんと英語を聞き取れるようになりたい。
  • 帰り道に相方とお茶した時に教えてもらったライブラリ、Apache Camel: Index は結構よさげ。
  • 参考 : http://qcon.jp/