去年は旦那が参加したので、今年は私が参加してきました。
ですが、開始前から残念なお知らせ。
アイスランド火山噴火の影響による欧州航空便の欠航に伴い、
以下2名によるセッションを変更いたしました。
4/19(月) 16:00-16:50 Erich Gamma 氏
4/20(火) 14:30-15:20 Jim Webber 氏
残念すぎます><
でも、参加者は200名弱はいた模様。女性は...平日のセッションの割には少なめだったかなぁー。
特に2日目は少なかった。1日目はFlex/Flashのセッションあったからか?!
会場の雰囲気としては、イマイチ盛り上がりに欠けてる感触。
盛り上げたいなら日本の有識者やコミュニティをもっと招待してみるとかしたらどうなんだろうか。
そうじゃないのであれば、twitterとかfacebookとかQConでしかきけないようなセッションをもっと時間をかけてやってみる方が私は嬉しいなぁー...とアンケートに書いてきた。
ま、聞きたかったセッションは面白かったですよ。
ピックアップしたセッションのみですが、内容報告。
Data Architecture at Twitter Scale
Nick Kallen
Twitterでのscaleのお話。最初からメインディッシュな感じです。
Twitterの初期は、MySQLのRDBで組んでた。項目は、[ID] [USER_ID] [TEXT] [CREATED_AT] ぐらい。
最初に発生した問題はディスクスペースだった。
それまで縦方向のスケールしていたのを、横方向へのスケールへ転換することになったが、どのようなパーティショニングするかの検討を行った。
(1) IDを、奇数と偶数の2つに分ける → ユーザについての全ての情報を取りたいときに不便
(2) USER_ID 毎にわける → (1)と逆の問題
(3) 時間軸でわける
Twitterの特性として、検索される大半のデータは新しいデータが多いため、(3)を採用。
cassandraに移行する予定があるが、cassandraが「魔法の杖」なんかじゃない。
Twitterだったら時間軸に特性があったように、アプリ毎の特性を判断して考える必要がある。
事前にフェッチしておくなども一つの手。
人のつながり情報関連(フォローしている、フォローされている)について、膨大な処理件数になってしまう。
そんなSocialGraphの処理の方が処理件数が多い (4:1)
フォローしている人/されている人 は重複してレコードを持っている(非正規な状態)
速度のために、データの近くで演算するようにする
有機的なユーザーインターフェイス実装における課題とアプローチ
隈元 章次 SiTE4D
アスクルのAdobeAIRガジェットを作られた会社の方です。
デザイナ、プログラマ、テスター 、IAが同じポジションで協力しながら開発していっている姿に感動。
特に、デザイナさんと企画段階からいろいろ相談して何かをつくってみたい..と思っている日々だったものでw
2ndオペレーション
右から出てきたウィンドウ、右にドラッグしたら実は消えるのでは? と想像して、できるとインパクトがあったりする。
でも、それを1ndオペレーションにすると、分かりにくい/使いにくい となるので、2ndでやる。
仕様/コンセプトは開発前にプレビズ(動画)を作成して固める。
最終的なゴールは、このプレビズのものとブレない。 (確かにブレてなくてビックリ!)
ブレさせないためにいろんな規格化(進むボタン系は黄色とか)をしている。
---> そのため、途中で客の担当者が変わって違うことを言い始めても修正できる。
---> そのため、作業の人展開もできるようになる。
α版アプリを毎日客に使ってもらう。
テストは全て動画で記録する。納品はその動画を入れたハードディスク毎行っている。
Scaling Memcache at Facebook
Marc Kwiatkowski
メインディッシュ2つ目です。
えと、内容のボリュームがでかいうえ、難しかったため、あまりついていけず。
なので間違っていたらごめんなさいベースでw
Facebookは友人の情報が密接につながっているため、膨大な処理量になる
PHPでシリアライズしているが、thriftを使うようになって、3倍の早さ/30%小さくなった
2つのデータセンターwest,east には memcache proxyを使って一貫性を保っている
データを更新すると、
(1) Databaseのupdate
(2) memcacheのdelete
(3) (複数の)クライアントからmemcacheへget
(3') 存在しないため(複数の)クライアントにfailが返る
(4) failを受け取ったら、databaseへadd (勝ったクライアント1つのみ反映される)
タイミングにより、違うバーションの2つのKEYが存在する状態が発生する可能性がある。
その解決として、Keyに、スキーマバージョンとオペレーションバージョンを含んでいる。
memcacheのdelete処理をより早くするために、
複数のKeyをまとめて送っている。
LocalでのDeleteなのか、GlobalでのDeleteなのか?を認識。
データが存在しなかった時には、PlaceHolderのオブジェクトを作り、情報を格納して処理を進める。
テストは、 python 、ctypesで書いていて、コマンドラインから実行できるようなものを作成している。
Programming the Cloud
Gregor Hohpe
急遽開催となったセッション。講演者はBest Software Writingにあった、"Starbucks Does Not Use Two-phase Commit"を書いたGoogleの方です。
Googleで提供している、GFS, BigTable, MapReduce, Sawzall(そーぞる)。SawzallはDSL。
(1) Uncertainty(不確実性) これはしょうがない。つきあっていくしかない。
(2) Asynchrony(非同期) 結果の順番が一緒になるとは限らない
(3) Interaction(相互作用) 不確実性をカバーするもの。でもfreeではない。
(4) Conversation(会話) 会話のパターンができるはず。講演者がまとめている最中らしい。本でるのかも?
(5) Back to Basics(基本に戻る) Bigtableはその例。必要なもののみシンプルに作成している。よく陥りがちなのが、不確実性をカバーし一貫性を保とうとするためいろんなレイヤーで処理を挟んで、システムを複雑にしてしまう事。トラブルが発生した時逆に原因追及しにくくなる。シンプルな方がいい。
(6) Empower the Run-time(ランタイムに合わせて) 決めすぎると分散しにくい。人間が頭で考える事と、その言語/環境に合ったものは違うこともある。
例として、int[4] の配列の値を全て足す処理を作成する場合。Loopを使ってしまいがちだが、int[0], int[1], int[2], int[3] の順番で足す必要はない。結構、ループ指向に陥りやすものだが、頭の切替が必要。
今まで(Before)と、これから(After) との比較
Before | After |
---|
Object-Oriented | Process-Oriented |
Rich Domain Model | Event based |
Method Calls | Channel based |
Prescriptive | Descriptive |
SingleThread | Parallelizable |
Easy to debug | Difficult to debug |
不確実性のため、会話が必要 という観点は実世界と同じ。
逆に、今までのオブジェクト指向は、思い描いていた理想の世界だったのかも?