pandazx's blog

データ分析など雑多な技術ブログ

楽天テクノロジーカンファレンス2011に行ってきた

まとめ

f:id:pandazx:20111119135829j:image

楽天テクノロジーカンファレンス2011に行ってきたのでメモと感想。


テーマはGlobalization、Agile、BIG Dataだが、
ランチセッションには参加できず、本会場にだけいたので、
ほとんどビッグデータしか見てない。

基調講演ではおそらく200名ほど参加者がいた。


以下はプレゼン中に取ったメモ。（けっこうスルーしてる部分もあります）
一部、私見と捕捉リンクを入れてます。


ビッグデータ革命　クラウドがコモデティ化する「奇跡」（45分）
中田敦 様（日経BP社日経コンピュータ 記者）

MongoDB と Cassandra : 入門から最新情報まで（45分）
doryokujin（井上 敬浩）様（MongoDBJP 代表）
冨田和孝 様（株式会社INTHEFOREST 代表取締役）


このテーマはMongoDB, Cassandraに分けて講演が行われた。


mongoDB

  • プレゼン資料：MongoDB: Intro & Application for Big Data
  • 2012年1月第3週あたりに「MongoDB Conference in Japan #2 開催予定
  • 主な機能
    • ドキュメント型DB
    • フルインデックスサポート
    • 自動シャーディング（ただし、高負荷、大規模では不安定）
    • MYSQLとほぼ同等のクエリを発行可能。入れ子構造も可能。
    • インデックスはどの属性にも付与できる
    • プライマリ、セカンダリがあり、プライマリが死んだら自動フェイルオーバー
    • mapreduceサポート
  • クライアントのアクセスはmongosに対して行う
    • ここはspofにならんのか？と思ったが、Sharding - Docs-Japanese - 10gen ConfluenceにSPoFはないとかいてある
    • ただ、1000ノード以上でのスケールアウトが可能とあるが、そんな大規模では運用が回らないっぽい
  • デメリット
    • 同一データ量でもmogoDBは2-3倍ディスク容量が必要になる。インデックス用にメモリも必要
    • シャーディングが不安定
    • 一貫性の問題もある。double counting
  • mongoDBを使う場合はマスタデータを別に持つ必要がある
  • mogoDBには一次集計後のデータをいれて分析するのがよい
  • logのストリーム処理としてfluentがある
    • mongoDBがビッグデータを扱うのは難しいので、入れる前にアグリゲーションしてmongoDBに入れることで、データサイズを落とす


cassandra

  • プレゼン資料：
  • 今週水曜日に19回目の勉強会を開催した
  • 同時書き込みや削除が重なると消したはずのデータが復活することがあるので注意
  • 一貫性が低いと書き込み先の負荷が高いと書き込みをあきらめるので、本当にレプリカ数分のノードにデータが書き込まれているかどうかは別途、確認が必要。
  • netflixテクノロジーブログでスケールのベンチマーク結果がある。288ノードでベンチマーク
  • 10台くらいから本領発揮するかなという感覚
  • コンパクションの問題があるので、1台あたりのデータ量は多くて20-100GBに抑えて、ノード数で増やすと安定動作しやすい
  • ディザスタリカバリ
    • データ量によるが切り替えに2-3時間
    • 死んだDCのデータがもう一方にすべて寄るため、データ量が2-3倍に膨れ上がるので注意


以下、Q&A

  • 質問がないので、ネタでmongoとCassandraの各ポジションからのディスり合い
    • cassandraはアグリゲーションが弱いので後から考えて対応することができないのが厳しいところ。反対にmogoDBは得意
    • mongoDBはスペックの高いノードを10台以下の構成を推奨。反対にcssandraは低スペックを10台以上推奨。
    • mongoDBのシャーディング問題。大量データインサート中にシャーディングが発生すると、メタデータに変更が必要になり、全体にロックがかかってしまう。さらにインサート後にノード数が12あるはずが2つしか認識してくれないとかもある
    • 競合ソフトウェアじゃないので仲良くやろう。mongoDBに疲れたらCassandraやってるかもとのこと（doryokujin）


Is technology making the real world better?
Inside disaster response of sinsai.info, Crisis Mapping and Hack For Japan.（45分）
関治之 様（sinsai.info 総責任者）

  • プレゼン資料：Is Technology Making World Better?
  • 震災でITはどう役に立ったのか
  • YahooはwebのNHK的ポジション（確かに）
  • 震災で開発されたサービス
    • person finder
    • 助け合いジャパン
    • 計画停電MAP。大学生2人で開発
    • safecast。世界中の放射線データ共有MAP
    • ボランティアMAP
    • crisis mapping
      • オープンストリートマップを利用。500以上のユーザーが50万回書き込みを行った
  • 震災.info
  • Hack for Japanで生まれたサービス
    • 風@福島原発。放射線の拡散状況を地図で表現力。
    • フォトサルベージの輪。Photoshopが得意な人が汚れた写真を復元
    • ボランティアニーズ受付管理
    • 復興時計→復興の窓
  • 震災.com, Hack for Japanで学んだこと
    • スピードとフィードバックが重要。クラウドソースはすごい結果を生み出すことがある。オープンコラボレーションはプロジェクトを強化する
    • まつもとゆきひろさんの言葉：ほとんどの人は適切な大きさと複雑な問題を探している
    • 震災では、このレベルの問題が多かったのが良かった
    • Hack for Japanは12月17-18日に経産省の協力で、30人で石巻市にバスで行って、現地の人と会話することで、必要なサービスを考えることを予定している
    • そんなアイディアソン、ハッカソンをやっている

Technology can make the world better to live.
（テクノロジーは世界をより良くすることができる。）
You make the world better to live.
（つまり、あなたも世界をより良くすることができる）


ちなみに、今年の楽天テクノロジーアワード金賞を受賞されていた（ぱちぱち）


グローバル・パネルディスカッション（45分）
James Chen（楽天株式会社 執行役員・副DU長・楽天市場サービス開発部 部長）
Terje Marthinussen（楽天株式会社 執行役員・副DU長・次世代サーチ チーフアーキテクト）
よしおかひろたか（楽天株式会社 技術理事）

  • 英語のカンファレンスに参加できるようになろうということで基本、英語で行われた
  • 雰囲気しか内容はわからなかったのでメモはありません
  • 一言で言うなら、楽天はAgileにGlobalに多国籍で開発して、Big Dataしてるよっていう話をしていた


特別講演（30分）
三木谷浩史（楽天株式会社 代表取締役会長兼社長）

  • 社内公用語が英語であるだけあり、英語でプレゼン
  • 冒頭に電子書籍リーダーKoboのプレゼン動画
  • 英語がわからないので、どこに向かって話が進んでいるのかよくわからなかったが、楽天は世界標準のやり方でグローバルにビジネスを行っていく、エンジニアにもビジネススキルや英語が必要ということだったと思う


このメモに間違いなどあればご指摘ください。


カンファレンス関連記事