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

タイトル通り、昨日、一昨日の二日間、東京はミッドタウンで開催された QCon Tokyo 2010 に行ってきました。

久々の東京である事と、場所が東京みったーんという超オシャレゾーンでアウェー感満載でした。また、火山の影響で Erich Gamma が来れなくなる、という残念なニュースもありましたが、充実した二日を過ごす事が出来ました。200名の参加者だったようです。(場所とスピーカからすると、この値段でもペイしないのでは、とか思ったり) お小遣い以外の予算で行く事を許してくれた奥様に感謝。まずは一日目の内容を。

Data Architecture at Twitter Scale

Twitter がいわゆる「リアルタイム」( < 100ms や low latency という事を何度も言っていました) を如何に実現しているかについて、主な四つの機能の観点から、その取り組みを話していました。内容については、「秒間120万つぶやきを処理、Twitterシステムの“今” − @IT」のレポートが素晴らしいので略。。。資料も こちら に。

まず興味深かったのが、Twitter が初期は RDBMS (+ RoR) といったいわゆる「通常の」構成でサービスは開始され、ユーザの増加、トラフィックの増加に伴ってそれにコツコツ対応し、今の高トラフィック、低レイテンシを支えるインフラやソフトウェアアーキテクチャに育てたという「過程」。常に正しくあり続ける回答は無いし、逆に「見えない未来の事を心配しすぎない、今ある問題に正しくアプローチする」という事も改めて大事な事だと思った次第。

もう一つ、Timeline のデータを作るための Fanout の話で、こういった「先払い」型の設計というのは、話で聞くと簡単そうに思うけれど、中々出来ない所。というのも、どちらかというと、RDBMS では「one fact in one place」的な考え方に従って正規化し、データの入力は一つで、見る時に種々の加工 (ex. 集約やジョイン) をするという「後払い」的なアプリケーション設計にする事が多いので、「慣れ」という側面でもなかなかとりにくい。その観点で、Twitter の規模で、この Fanout 的なアプローチが上手くいっているという事は参考になるなー、と。(と、思っていたら naoya さんのこんなつぶやき も)

振り返るとこの二日間で、一番面白いお話でした。きけてよかった。

The JSON Saga

JSON の生みの親 (ご本人曰く「発明したのではなく、自然にあるものを見つけた」と) Douglas Crockford さんのお話。

曰く、「私は、JSON の為に 1) サイトをたて 2) ドキュメント (簡単な BNF/鉄道ダイアグラム/説明) をかき、3) JavaJSON Parser の参照実装を書いた、以上」と。それ以外は特に何もせず広がっていったとのこと。

広まった要因は、その「シンプルさ」。各プログラミング言語がもっているデータ構造の和集合ではなく、共通部分に仕様を「絞った」おかげで、沢山の言語実装もあり、沢山の人がそのデータフォーマットの恩恵を受けれるようになったそうです。また、偶然にも、JavaScript だけでなく、Python や NewtonScript にも同様の考え方のフォーマットがあり、他にも (一部仕様を削除する事によって) JSONYAML のサブセットになった、といった事実からも、ある意味「必然的」なデータフォーマットではないのか、という所は印象的でした。

id:agt さんに教えて頂き JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス を読んだのですが、この本から受ける印象と同じく、ハッカー的「変わり者」な語り口でした。(この本は面白かったです。勉強になりましたし、JS 書きたくなる一冊だと思います。)

Connected Clouds: A Platform for Globally Distributed Service - サービス基盤としての分散KVS、そのグローバルへの広がり -

タイトルはやや「釣り」気味で、実際の内容は、ヨドバシ などで使われている Coherence の worldwide での事例紹介。

  • cache は置かれたタイミングで自動的にパーティショニング及びレプリケーションされる
  • worldwide のシステムでも、キャッシュクラスタは拠点内で設計する。拠点間の遅延 (ex, uk <-> au で < 300ms) が無視出来なくなる
  • レプリケーション (自動) において、ネットワークスループットは超重要。仮想環境でも動かせるが、最悪 1G Ether でも仮想ドライバ経由で 5MB/s くらいしか出ない時もあるので、物理 H/W に構築しておく方が今はよい
  • Push Replication というアプローチで、複数クラスタの同期を取る。最終的にデータを受け取った後に、conflict があれば、それを解決する。eventually consistent な考え方
  • JVM 1 インスタンス辺り 1GB くらいが大体上限。(Java6 でもう少しいける) これを数百台くらい並べる

もっとまっすぐ「Coherence」のテクニカルな話を聞きたかったなー、というのが正直なところでした。後、物理 H/W を推奨する辺りに Sun を買収した影響か ?! みたいな邪推をしてみたり。(笑)

有機的なユーザーインターフェイス実装における課題とアプローチ

Site4D さんでこの10年で取り組まれた事例紹介を下敷きにしながら、そこで培った、チームの構成、プロセス、仕様のポイントと仕様書、といったまさに現場のノウハウてんこ盛り、な内容でした。

まず、チーム構成が「UIデザイナ」「開発者」そして「テストエンジニア」の中心に「IA」を置き、皆がプロジェクト開始からほぼ同時に動き出す、という所がプロセスの中で興味をひいた点。実際に、こうした方が結果的にはコストは下がるんです、と言い切っておられました。私もチームの中でテスト仕様を作ってもらった人からのフィードバックで、随分仕様の抜け・漏れを指摘し助けてもらった事があり、「テストの事を考えるのは仕様の事を考える事に近い」といった事を話していたので、それを実際にうまく回されているのだなぁ、と感じました。

また、UI の考え方で、

  • 例えば「右からスライドしてウィンドウが入ってくる」という操作に対しては、「ひょっとして、つまんで右に払ったら、画面から消えるのでは」といった、「やってくれるかもしれない、出来るかもしれない」というラインを作り込んでおくと、非常に印象が良い
  • ただし、それをメインのオペレーションにするのではなく、メインはボタンなどのあくまで正統派なものにしておき、セカンドオペレーションとして、そういった作り込みをしておくと良い

といった当りは、よく考えられているなぁ、と。

一番感銘を受けたのは、開発前の段階で、プレビズ (pre-visualization、参考) といって、最終的なアプリイメージを動画として作りこんで、そこでお客さんとも、また開発チームとも最終イメージをぐっと共有してから、実際に作り出す、というプロセス。これを作るために、「そのソフトウェアの UI = 世界観」を徹底的に作り込むそうです。この「世界観」というのは UI に限らず大事な所ですよね。

Real Javascript

Erich Gamma さんの代わりの講演で、Douglas Crockford さんが再度登壇。JavaScript の未来の話。

  • ブロックスコープの問題は、let/const で解決するかも
  • number 型の問題は解決するかも
  • Thread はやらないでしょう (thread は必要悪で、アプリケーション言語には入れない方がよい)
  • compile 対象としての JavaScript
  • 末尾再帰の最適化

などなどが、検討されたりするでしょう、とのこと。ただし、それより何より大きな関心事はセキュリティで、曰く「The Web is important to fix」。折に触れて、(MS スポンサーのイベントで)

  • IE6 Must Die

と (三回くらい) いってみたり、

  • HTML5 は間違った方向に進んでるから、一からやり直したほうがよい

とか、ずけずけ言ってしまう当りにも現れてました。 (笑。

ちなみに、HTML5 については、良い仕様も沢山あるのだけれども、各仕様が複雑になりすぎていて、その複雑さは必ずセキュリティ問題を引き起こす、というのが大きな理由とのことです。それよりは、ひとまず今のブラウザと JS のモデルのもつセキュリティの問題にしっかりと対応するために、ES5/Strict を推し進めていきたい、とのこと。