第8回ジオメディアサミットに行った

第8回ジオメディアサミットに行ったので、そのメモ。
今回のテーマはO2O(Online to Offline)でした。
↓にユーストのアーカイブとtoggeterへのリンクもあり。
http://geomediasummit.jp/post/16383948134/8

40000店舗、3850万会員基盤によるDBマーケティング

CCC 藤澤幸生様

  • TSUTAYA 1414店舗。
    • 実は日本一、本を売っている店舗である。
    • 渋谷店が最大の売り上げ
  • T-Pointカード
    • 3854万会員。(名寄せ + 一年以内に使ったユーザに絞っているので、いわゆるアクティブに使ってる人数!)
    • 80社、40000店舗。
      • TSUTAYA、ファミマ、ドトール、牛角 etc..
      • 流通からメーカーへ。ブルボン、アイシティ、woo
    • 幅広い業態に出すことでいろんな属性の人に使ってもらえる。
  • 会員と販促基盤の共有。
    • 誰に何が売れているかが分かる。
    • ロイヤルカスタマー優遇システムを作れたり。
  • リコメンドサービス
    • 誰にどんな広告をうつか? データが豊富なため、マスではなく1to1に近いターゲティングが可能。
    • アライアンス企業に対して、会員の個人情報や履歴の提供は一切していません!!
  • 商圏マップ
    • 元がチェーン店舗なのでこの辺は元から得意。
    • アライアンスに入ることで利用者だけでなく、未利用者の分布まで分かる。
  • 属性×購買行動×接点(店舗の位置情報)
    • 行動商圏特定セグメント。
    • これまでの購買履歴からその人の行動半径が分かる。エリア特化型マーケティング。
    • 自販機連携。今日から?サービス開始。
    • T-POINTクーポンアプリ。
  • 代官山プロジェクト
    • お金、時間のあるかっこいい大人を狙った店舗。
    • 最新ITの導入。

自分がT-Pointカードを使っていないこともあり、今まであんまり存在を意識したことはなかったけど、今流行りのBig dataにどんぴしゃで、住んでる場所、行動エリア、購買履歴と、どっから手をつけていいものかと迷ってしまいそうなデータ量なんだろうな〜と。
一開発者として見ると凄いデータ量でチャレンジングなことが色々出来そうだな〜と思うし、きっと事業寄りの人から見ても魅力的なデータなんだろうとは思うけど、講演の中ではこんな広告が打てますみたいな話が多く、一エンドユーザとして考えた時には正直、T-Pointは入らないでおこうと思ってしまったので、、エンドユーザ的にはポイント貯まる以外にも、こんなメリットがあるんだ!みたいのが聞けるといいな〜と思いました。

ニコトコを中心とした二子玉川でのジオサービス 東急電鉄 福島様

  • about 東急電鉄
    • 元はまちづくりの会社。そのインフラとして鉄道を引いた。
    • 東急沿線沿は245万世帯、501万人。
  • 課題
    • 基礎消費の縮小、情報伝達の変化、所有の質の変化。
      • 鉄道、不動産、小売/リテール どれも厳しい。
      • 外出減、回遊性の低下、購買行動がオンラインへ。
    • 街づくりもついていかないと、若い人が集まらず、○○ニュータウンのようなゴーストタウンへ。。
    • ハード(箱物)からソフトへ、コミュニティ作り。
  • ぷらっとPlat (この辺からあんまりちゃんと聞いてなかったので、やや怪しい)
    • ピナクリ
      • iPhone使ってる人が以外と少なかったり、サービスがイマイチ回らなかったり。。
      • 渋谷という町の特性もこの事業でやる方向性とはちょっと違うなという印象
    • ニコトコ
      • ガラケーでも使えるサービスにした & 対象とする町の変更。

NFC活用によるビジネスの可能性 リクルート 鵜飼様

パネルディスカッション

  • 参加者
    • 株式会社マイネット・ジャパン 代表取締役社長 上原仁
    • 株式会社サンゼロミニッツ 代表取締役社長 谷郷 元昭
    • 株式会社FrogApps 代表取締役社長 中村仁
    • 株式会社nomad 代表取締役社長 小笠原 治
    • 有限会社らしく 代表取締役社長 佐藤 純也
    • 株式会社ゆめみ ソーシャルアプリ事業部 副事業部長 君塚 賢一
  • 詳細はユースト or togetter見るべし!
  • メモ
    • サンゼロミニッツはついに黒字化!
      • メルマガ集約、静的ページ集約、自治体発信情報集約、店舗発信×ユーザ発信
    • 豚組のtwitter
      • 現在は約5〜10%のお客がtwitter経由で予約。少ないと思われるかもしれないが、この集客が黒字との分岐点になったりすることもあるので超重要。
      • "ごちそうさまでした"という言葉がもらえる!
      • トップダウンで始めた。最初は店の人は嫌がっていたけど、今はノリノリ。
    • ファミマのT-pointに関する店員へのオペレーションの徹底はある意味すごい。
    • awabar
      • ソーシャルのみで集客
      • 今は坪当たり20万円の売り上げ。(飲食店としてはかなりいい数字)
    • アプリの名前に自分の知ってる地名が入ることの価値。(株式会社らしく)
    • Miilに関して(FrogApps)
      • 店舗経験がある人がオンラインの場で何かすることに価値があるのでは無いのかと思うようになり、今はアプリを作る仕事をしている。
      • チェックインは皆がする行為ではない。写真アップロードのほうが皆がしてくれるはず
    • オフライン(店舗)側からオンライン側への歩み寄りは徐々に始まっている。次はオンライン側がオフラインに歩みよるべし。

GPSによるシームレス測位技術 IMES(= Indoor MEssaging Service)について

  • 屋内技術
    • 三次元(高さ)が必要
    • かなりの精度が求められる
    • 人が対象
    • 地図はどうする?
  • IMESの概要
    • 位置情報をメッセージで送り、GPS受信機で取得。
    • プロトコルあり。 緯度軽度 + Floor を送ったり。
    • 特許だよ!!
    • 電波の強さを変えることでメッセージの伝播範囲を調整することができる。
    • LSIというかなりちっちゃい発信機ができた。
      • これにより、普及の足がかりはできた
      • 電灯にさしてそこから電力を得るようにできる。
    • IMESサービス開発キャンペーン

LT (一部抜粋)

”僕の来た道” - 移動ログを全部とっておくとできること
  • ジオメディアは危機に瀕している!!
    • 無断での位置情報取得等
  • 位置情報を提供することによる価値をエンドユーザに届ける必要がある。そのためにこのアプリを作った。
  • もうすぐアプリ公開予定
    • 位置情報は全てローカル保存。
Daily portal Z ちょっと見てきて

個人的には今回の一番の収穫じゃないかくらい、面白いコンテンツだな〜と思った。何気ないよくある風景や写真でも、誰かの想いや思い出が乗ることで、スペシャルなものに変わってほんと面白い。今の雰囲気を保ちつつ、もっとメジャーになっていくといいなと思います。依頼の内容的にも、ふわっとした感じ的にも、何となく探偵ナイトスクープを思い出した。

位置情報×プライバシーでSoLoMoの未来を変える! @sa2da
  • SoLoMo (=Social, Local, Mobile.)
  • 位置情報の公開に懸念を持ってるユーザが多い。
    • 位置情報を公開してアプリを使っているユーザは7%くらい
  • ON/OFF の二者択一では拾えないニーズがあるのでは?
  • そのニーズを拾うのがZONE
  • 開発者登録受付中
GPS屋内測位技術「IMES」による空間エンタテインメント
  • RokePoP
    • IMESを使った超狭い範囲Push広告
NFCを活用したリアル・チェックインサービス「たっちなう」
  • 海外ではどれにタッチすればいいか分からん!!
  • NFCタグを発行し、それに触るだけでいい感じに。
  • 駅出口とかに作ることで何か情報だしたり
鳥取大学が創る新しい地域公共交通案内サービス @niyalist
  • バス路線、利用者は減り続けている。利用者減 -> 路線廃止 -> 利用者減、、の悪循環。
  • バスの利用を促すものを作れないか。
  • バスネット

感想

googleの検索もFacebookも、使う人が多くなっても、中々、利益を上げられずに苦しんでいた(というか、興味がなかった?)らしい。でも、作っている人たちはその価値を信じて邁進していた。ちょっと前に見たはてなの近藤さんの講演でも、ダイヤリーを作った時には売り上げとか考えずに絶対あると便利だからという理由で受託の売り上げをサーバに突っ込んでいたという話をされていた(そして、超格好いいな〜と痺れた)。
ジオメディアもどうしてもマネタイズの話になりはするけれど、これだけの人たちが面白おかしく色んなものを作っている(ちょこちょこ色んな勉強会に行くけど、LTが振るいにかけられるほど集まり、5分とは思えない密度の濃い内容が展開される場は中々ないと思う。)んだから、引き続きお互い切磋琢磨して面白いものを作って、エンドユーザを増やしていければ、いつか誰かがgoogleばりに(はてなばりに?)ドカーンと行くに違いない!と、勝手な楽観論を抱いてしまいました。
とりあえず、ちょっと見てきての書籍が出たら買います(笑)。
NFC、IMESといった今後のジオメディアの土台となっていくかもしれない技術、パネルディスカッションで聞けたO2Oの取り組みの実例、LTで語られていたプライバシー問題などなど、今回も色んな収穫のあった会でした。主催者の方々、ありがとうございました!!

グーグル ネット覇者の真実 追われる立場から追う立場へ

グーグル ネット覇者の真実 追われる立場から追う立場へ


フェイスブック 若き天才の野望 (5億人をつなぐソーシャルネットワークはこう生まれた)

フェイスブック 若き天才の野望 (5億人をつなぐソーシャルネットワークはこう生まれた)

ウェブ時代5つの定理を再読した。

無事にベータ版に登録できたので、初エントリー。

何をネタにしようかな〜と考えていたけど、ちょっと前に梅田望夫さんの「ウェブ時代の5つの定理」を読み直していたので、はてなつながり?ということで、丁度いいかなと。

昔の自分のブログでも書いたことがあるけど、 

http://d.hatena.ne.jp/seikoudoku2000/20080305

http://d.hatena.ne.jp/seikoudoku2000/20080317

 

望夫さん曰く、

--

 この本は手元に置いて、何年かに一度でもぜひ開いてほしい。そのときどきのベスト10を選んでみてください。まったく違った言葉を選んでいる新しい自分を発見するはずです。

-- 

ということなので、3年半以上が経過した今回はどんな言葉が引っかかったかをメモ。

 

  • The internet is helping to statisfy our most fundamental human needs - our desire for knownledge, communication and a senseof belonging.   by Eric Schmit

 前に読んだ時は全然記憶に残ってなかったけど、ほんとその通りだよな〜と深く感銘を受けた。インターネットって何が面白んだろう??って考えても、中々上手く言葉にしきれなくてもどかしいけど、この言葉をベースに、自分なりにぴったりする言葉を見つけることができるといいなと思った。

 

  • The top-level team must be "do"-oriented rather than "management"-oriented.  by Gordon Bell
  • Google's emphasis on innovation and commitment to cost containment means each employee is a hands-on contributor. There's little in the way of corporate hierarchy and everyone wears several hats.    The Google Culture

  これも全く記憶に残っていなかったww。所謂アジャイル開発(最近、色々と勉強中。)の話につながると感じた。とにかく行動重視。それしか生き残る術はないんだなと再認識。

 

  • You know, every technology dislocation has winners and losers. And the winers are the companies that can adopt these technologies more quickly and the losers are the ones that are stuck, unable to make the transition, unable to take advantage of new technologies.   by Eric Schmit

 技術革新による企業の入れ替わりとかは2008年時点でも話としては聞いたことはあったものの、本の中だけの話な感じがしてピンときていなかったけど、今はスマフォの登場による変化が起こり、企業の淘汰が現在進行形で進んでいるのを見ていて、こういうことなんだな〜と。何か新しい物が出てくると、しばらく様子見だの枯れた技術でないことによるリスクだのとなりがちだけど、逆に流れに乗らないことのリスクってのも半端ない。そして2008年くらいのことを思い出してみると、今のスマフォの普及っぷりは半端ないし、いつのまにかちゃっかりとAndroidを開発していたGoogleも半端ない。

 

  • Don't public, use data.  by Marrisa Mayer
  • You have to work with people you like.  by Roger Mcnamee  

この2つは前も選んでて、今回も引っかかった。ここがぶれてしまうと、エンジニアとしての仕事がつまらなくなってしまいそうなので、引き続き意識したいな〜と思う。

 

ということで、ほんとに結構変わるもんだな〜。また、やろう。

 

MA7に応募したはてぶマップについて(詳細編)

前回に続いてはてぶマップの話。

今回は内部の作りの説明と作ってみての感想です。
ソースは公開準備中です。

データ作成バッチ (javaで実装)

データ作成の手順は以下の通り。

  • 対象のページ + 対象ワードの抽出(手動。。)

最初ははてぶのホットエントリーとか新着エントリーを全部回せばいいかくらいに思っていたのですが、後に出てくるyahooのローカル検索APIの所で、都道府県コードやジャンルコードを付与してやらないと、一般名詞でもけっこうスポットが引っかかってしまったりで、データがかなりいまいちになってしまったので、ここは手動でやりました。。
はてぶで"東京"、"京都"で検索 -> ページをざっと見て、解析する価値がありそうかを判断 -> 都道府県コードとカテゴリコードを決定 というアナログな手法でページの選定と検索条件を設定しました。
「ページのURL \t 都道府県コード \t ジャンルコード」という形式のCSVを手でポチポチと作成します。
データを増やしていくにあたっては、完全にボトルネックになってしまうので、何か仕組みを検討していきたい所ですが、技術的なハードルはかなり高そうだなと感じてます。(まずは誰でも設定できるような仕組みの提供とか?)

↑が手動なため、そのタイミングで一緒に設定すればいいので、必要は無いっちゃないんですが、将来的に自動化予定!?なので、API経由でブクマ情報を取得しています (& はてなの協賛企業賞も狙っていますww)。

  • 各ページのbodyのテキスト文字列を抽出

ROMEというパッケージを利用しました。
(ファイルが見つからず苦労したので、ここにまとめました。)
次の特徴語抽出APIが文章内での相対的なスコアリングを行っているようだったので、ある程度の長さ毎に一行(=クエリの単位)にして文字列を抽出し、特徴的な単語が見つかりやすくなるようにしました。
今は単純に文字列を抜いてるだけなので、タグ構造を加味する等、ここも色々と改善の余地がある部分です。

元のテキストを形態素解析とかだけして、次のローカルサーチを実行することも可能ですが、速攻でAPIの上限に引っかかりそうな気がしたので、キーフレーズ抽出を挟みました。
(文章の少ないまとめ系のエントリーなどでは、引き当てたいキーワードが浮かび上がってこなかったり、ある1スポットを紹介したエントリーになると、もやはこの仕組みでは太刀打ちがいかなかったので、一部エントリーに関してはここも手動で作業しました。。)

最初にセットした都道府県コードとジャンルコード + ↑で抽出されたキーフレーズで順に検索を実行し、ページの中に登場したと思われるスポットを抽出。地名(ex.新宿)や一般名詞(ex.ラーメン)等が入ってしまうことがあり、そういう時は関係ないスポットが大量に入ってしまうので、該当件数が多い場合は弾いています。

描画と検索で利用するために、GeoHexのコードを付与。詳細は後述。


描画部分

やりたかったこととして、

    • スケールが広くても、画面をピンだらけにしないで操作性を維持するとともに、。
    • 地図全体で表示件数を絞ってしまうと一部エリアに偏る可能性があり、そうなると結局↑も満たさないので、地図全体に万遍なくピンを降らせる。

という2点がありました。
そこで、GeoHexの座標系を用い、各Hex内毎にピンをブクマ数の上位5件までとするという制御を入れることで、↑を実現しました。
現在、最新版はv3ですが、今回の利用方法としては、mapの縮尺とhexのlevel(=大きさ)を対応づけやすいv2のほうが適しているように感じたので、v2のコード体型でデータを保持しています。
結果、渋谷周辺で見てみると、、
f:id:seikoudoku2000:20111107031030p:image:w640
f:id:seikoudoku2000:20111107031031p:image:w640
f:id:seikoudoku2000:20111107031032p:image:w640
f:id:seikoudoku2000:20111107031033p:image:w640

こんな感じになり、無事にやりたかったことを実現できました。
また、ジオ系のデータを扱うスキーマとしては、PostGISや最近ではMongoDB辺りがでてきているような気がしますが、普段使い慣れているものではなく、最初の敷居が高くなってしまいがちですが、GeoHexの座標系を用いると、RDBMSにデータを突っ込み、x座標とy座標の範囲指定という単純なwhere文でデータを引っ張ってこれるというのも、かなり魅力的だなと思ったりしました。

感想

バッチ作成に関しては、"HTMLからスポットに紐づく単語のみを抜き出す"という課題の敷居の高さが思ったよりはるかに高く、全くいけてる仕組みにできませんでした。。(人間のコンテキストを読みとる力ってのはほんとに凄いんだな〜と思ったり。。)
こういう問題に実際にガツンとぶつかったことで、これまで漫然と学習していたテキストマイニング機械学習といった所に対して、目的を持って取り組むことができそうなので、それはそれで良かったはずと自分を励ましつつ、精進を進め、新たな打開策を考えていきたいと思います。
とりあえず、同僚に勧められていながら価格の高さからスルーしていた、↓を購入してみるなどしてみました。

情報検索と言語処理 (言語と計算)

情報検索と言語処理 (言語と計算)


描画部分に関しては作り出す時に頭にあったものにイメージに近い物ができました。(デザインは全くのせられていませんが、、)
ただ、ピンやポリゴンにaddEventListernする所で結構はまり、クロージャ的な話が全く理解できていないことが判明したり、グローバル変数をがんがん使ったりと、コード書きながらちょっと悲しい気分になったので、こちらも勉強し直さねばならないなと痛感したのでありました。まずは蝶々本を読み直す所からかな〜。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス


最後に、、はてなは今の仕事をするにあたってかなり影響を受けた会社(自分の初期の頃のエントリーにちょこちょこと出てくる)で、中でもはてぶはwebの面白さを教えて続けてくれる大好きなサービスであり、また、GeoHexは初めて見た時から凄いな〜と感じ、端で見ている間にあれよあれよという間にwhere2.0にまで登場してしまう存在に駆け上がり、GeoHexというプロダクトと共に、3年以内にwhere2.0で登壇するという目標をたて、それを果たしてしまった、@sa2daさんの行動力自体にもめちゃめちゃ刺激を受けました。
すんごい微力ですが、このリスペクトする2つのプロダクトを結びつけるというのは、とても楽しい作業で、何ともいえない充実感も感じることができたと同時に、改めて自分の力が及ばない部分を痛感することができたので、これを糧にまた次のステップを考えていきたいな〜と思います。


Mashup Awardという場を提供してくださるとともに、Mashup campの名の下で2度にわたり、電源と無線LAN完備の快適な開発環境+飲み物やらお菓子やらを提供してくださった、リクルート メディアテクノロジーラボの関係各位の皆様には本当に感謝感謝です。(Mashup campなかったら、きっと応募できてませんでした。。)ありがとうございました!!

MA7に応募したはてぶマップについて(問題解決編)

MA7に応募したはてぶマップという作品の紹介になります。
http://seikoudoku2000.com/hatebumap/
https://ma7.mashupaward.jp/works/278?locale=ja

ちょっと前になりますが、はてぶ上で↓の記事が話題になっていて、なるほどな〜と思ったので、この記事で上げられている重要な5つの点に沿って項目に沿って作品を紹介したいと思います。
シリコンバレーで起業した日本人が語るスタートアップガイド――受け入れられる投資家へのプレゼンとは


1.どういった問題を解決しようとしているのか
はてぶの人気エントリーには、日々たくさんの面白い記事があがってきていて、多くの人は「最新の人気エントリー」(=時間軸的にホットなもの)を読んで楽しんでいます。
その「最新の人気エントリー」には時々、↓のような記事が挙がってきて、いつか行ってみたいな〜とか、今度近くに行くことがあったら、、と思いながらも、ほとんど実際の行動につなげられていないことをもったいなく思っていました。きっと、これらの記事をブクマしたほとんどのユーザも同様ではないかと思います。
京都で美味しいラーメン屋ってどこ?一乗寺、新福菜館、第一旭、天一?
【決定版】一度は食べてみたい東京のハンバーガーショップ10店舗
こういった記事を、現在地や今度遊びに行く場所(=場所軸的にホットなもの)に紐づけて閲覧できるようになることで、上記の問題を解決し、日々の生活が楽しくなるのではないかという思いを元に、今回のサービスを作ってみました。


2.どういった解決策(サービス)なのか
はてぶの人気エントリーの記事の中から、店舗名等、緯度経度を特定できる単語を抽出し、記事と緯度経度を紐づけることで、地図ベースのUI上で人気エントリーを読むことができる。
これにより、現在地の近くに関するエントリーや、今度旅行に行く先に関する話題になった記事を容易に見つけることができる。


3.現時点でどの程度ユーザーがいるのか(増加率はどの程度か)

↓の資料によると、2009年時点で300000ユーザ、400万セッション/月。
http://www.slideshare.net/naoya1977/ss-1983437
まずはそのうちの1% + 地図ベースにすることによる新規ユーザを狙う。


4.創業チームは誰なのか
私、はてなのAPI、YahooのAPIGoogle Map


5.今後どのような計画か

  • スマフォ対応
  • 新着エントリ対応 (今はブックマーク数だけで表示対象を決定している。)
  • 対象記事、対象ワードの自動抽出
    • 細かい処理の話は後続予定のエントリー*1に譲りますが、最初の対象記事の抽出の所が自動化されておらず、かなりの部分を人力でやっています。。
    • 今は特徴語抽出→ローカル検索 で引っかかったものという2段階フィルターにより該当単語の抽出を行っていますが、ローカル検索の裏側で利用されているDB(+ゆらぎを組み込んだ辞書)をベースに、ページを解析したり、文章の係り受けを考慮したり、HTML構造を加味することで、もっと精度が上げられるのではないかと考えています。
  • データ表示可能範囲を広げる。(↑ができれば、自然解決の予定。。)

審査員の皆様、まずはテーマ賞あたりでの検討をお願いします!協力企業賞でも凄く嬉しいです!!

*1:[http://d.hatena.ne.jp/seikoudoku2000/20111107:title=11/7追記:書きました]

Hadoop Conference Japan 2011 Fallに行ってきた

Hadoop Conference Japan 2011 Fallに行ってきた。

リクルートのMIT作成のQAやら講演資料のサイト (現状、一部の資料がアップされているのみ。)

http://mit.recruit.co.jp/hadoop/conference2011fall/info/archive.html


午前中のセッションに関しては、ITProのニュースになってたり、他のブログでも書かれていたり、技術的にはこれといった話が無かったりだったので略。
午後はずっとCommyunity Trackのセッションを聞いていたので、そのまとめ。

Elastic MapReduce: Amazon Web Serviceが提供するhadoopサービス  @shot6

  • アマゾンの三つのビジネス
    • Eコマース
    • マーケットプレイス
    • AWS
      • AWSは2006年から始まっている。
      • 低レベルな階層のインフラから、高い階層のツールまでをレゴのように組み立てながら作っていく。
  • AWSが提供するElastic map-reduce とは
    • 大規模データ分析をあらゆる開発者に。
    • インフラでAWSを利用することで、解析業務に集中できる。
    • 高い堅牢生を誇るS3の利用。
      • これまでにデータロストしたことや、アタック等でデータが流出したことはない。
    • Big dataはほんとにビジネスとして成立するのか?
      • 成立することが分かったらすさまじいスピードでの拡張、成立しないなら素早い撤退が必要となる。
      • リアルサーバであれば、初期投資が難しいし、大きく拡張していくことも難しい。
      • AWSでこの柔軟性を実現できる!!
  • Elastic map-reduce 概要
    • EC2、S3、Simple DB がEMRを支えている。
    • Job実行中の動的なノードの追加が可能。
    • 時間帯に応じてノード数を調整することも可能。
    • Spotインスタンスという課金方法。
      • 入札によって空いてるリソースを利用できる。
      • 動的な追加部分をSpotインスタンスで補えれば、時間、料金ともにコスト削減が可能に!!
      • 入札価格より高値での落札者が現れた場合、自分のインスタンスは停止されてしまう。
    • ブートストラップアクション
      • hadoopの実行起動引数を指定。
  • 導入事例
    • Razorfish
      • 広告の費用対効果が500%改善された。
    • Sonet
    • 一日10GBのアクセスログ解析
    • 普通に構築すると初期費用だけで数千万かかりそうなところを、年間600万で運用できている。
  • hadoopと比較して
    • 物理ハードウェア vs 仮想マシン
      • 確かに仮想マシンによる実行ではオーバーヘッドが存在し、物理マシンで実行するほうが速い。
      • でも、EMRのもたらす拡張性、柔軟性はそれに勝る魅力であると考える。
      • 何事もトレードオフ
    • 価格に関しては、hadoopは1ラックを超えると高くなる傾向がある。
      • ネットワーク機器等の費用が増える & 結構な値段がする。
      • AWSではインスタンス単位での課金なので、リニアにスケールすることができる。
  • クラウド上のデータの安全性?
    • S3がデータをロストしたことは無い。アタック等による流出もない。
  • QA
    • 他のユーザのジョブにより、ネットワーク負荷があがり、自分が影響を受けることはあるのか?
      • ありえるが、テナント単位での帯域の上限は決まっている。また、M1 X-Large以上のインスタンスであれば、インバウンドの回線は専有となるので、ちょっとお高いがこれを利用すれば確実。

基本、他のセッションはbig dataにチャンスが眠っているというスタンスでしたが、このセッションはほんとにbig dataはビジネスにつながるのか??という問いかけがある所が新鮮でした。(だから、初期費用もかからず、すぐに撤退できるEMRを使いましょうというセールストークな面もありますが。)
最近はTech ChrunchとかでもBig dataの解析をする会社が投資を受けたとかでニュースになっていたり、何となくbig data系がバブルになっている気がしますが、Data Ware House的なものはもっと前から存在するわけで、hadoopの登場によって参入障壁が下がった分、そこで差別化を測るのがどんどん難しくなっていったり、Map-Reduceのデザパタ本では、高度な解析よりもデータ量を集めることに注力するほうが良い結果を産み出す可能性が高いと書いてあり、そうなると、今リードしている会社が有利な戦いになってしまうので、果たして今後big dataを巡る争いはどうなっていくんだろうか??と思いを馳せ巡らせたりしました。

LT

Hadoop and subsystems in livedoor    @tagomoris

  • livedoorのシステム概要
    • 2800 server
    • 3200 host
    • 今は15Gbpsくらい。
      • ↓が出たのが、2009/8なので、2年ちょいで3倍以上。

4Gbpsを超えるWebサービス構築術

Lightweight wrapper for Hive on Amazon EMR    @stanaka

  • はてなでのhadoop利用
    • Amazon EMRとHiveを使っている。
    • 自前のクラスターを使っていたが、ジョブが溢れた。
    • 生のmap-reduceを使うと、実装者が偏ってしまい、ノウハウも偏る。
  • EMRの利用へ
    • データをS3に置かないといけない。
    • 一連(インスタンス起動-データのプット-処理の実行-実行結果のゲット-インスタンス停止)の動作を自動でやるのが大変。
  • 自動化した!
    • log2ec2.pl
      • ログを吐き出す部分と回収する部分は別の仕組みにすべし。
      • 昔、回収部分用の設定をapacheに入れたところ、それが原因で動作がおかしくなったことがあった。
      • でもやっぱりS3にデータを置くのはちょっと大変。
    • Hive実行用のpl
      • クラスタの停止を失敗すると課金が発生し続けるので、要注意。
HBaseでグラフ構造を扱う(開発中)    Ameba 鈴木さん


今はMySQLを使っているが、SPOFがあったり、シャーディング管理が面倒だったりで、HBaseへの移行を実装中。

Large-scale Graph processing    @doryokujin

  • Map-reduce デザパタ本の五章にも載ってるよ!
  • Map-reduce
    • Graph構造も一緒にreduceに送る必要があるため、shuffleがえらいことになる。
    • そもそも本来のgraphの仕組みとmap-reduceでは相性が悪い。
  • Googleのpregelモデル
    • シンプルなアルゴリズム。
    • ネットワーク通信はメッセージのみ。
  • Pregelにインスパイアされたプロジェクトたち
    • Hama
    • GoldenOrb
    • Giraph
      • hadoopのインフラ上で動く
  • データの増大とともに計算方法の選択が求められる時代

大規模分散処理でもGraphの扱いが問題になり、最近のトレンドである所謂ソーシャルな分野でもGraph構造が取りざたされ、DB界でも@doryokujin さん主催で勉強会が開催される Graph DBが出てきて、webは元々Graphだしということで、IT業界はどこを見てもGraphに到達するんだな〜と思いました(笑)。ただ、全然キャッチアップできておらず、このLTの話もチンプンカンプンだったので、しっかりキャッチアップせねばww。

リクルート式hadoopの使い方   石川さん

  • リクルート自体は部門(ゼクシィ、じゃらん、carセンサー etc..)ごとに別会社な存在だが、MITは全社横断な組織。
  • 解決したかった課題。
    • バッチが終わらない。。
    • hadoop使いたかっただけな面もあり。
  • 導入への障壁
    • 現行システムに影響は与えたくない。開発工数をかけたくない。
    • エコシステムを上手く活用すべし。
  • エコシステムの活用
    • web Hiveというツールを作成した。
      • リクルートのシステム自体がSQLを駆使しており、Hiveとの親和性が高かった。
    • ツール群:https://github.com/recruitcojp/
  • 効果
    • 飲食ぐるメール
      • Hot pepperのメールマガジンのおすすめ店舗。CTR、CVRが1.6倍に!
      • 集計期間、配信人数ともに増やすことができた。
  • Mahoutの利用
    • Parallel freauent pattern mining. アソシエーション分析
      • カーセンサの同時に参照されることの多い車種表示。
    • Non distributed recommenders. あなたにおすすめの、、、
    • 分析専門の人もいるが、簡単なマイニングはMahoutをそのまま利用している。
  • hadoopの構成に関して
    • 現在は全部で118台。
    • Azkabanという監視ツール
      • USのYahooの人におすすめされて、勝手に導入したww。
      • Jobフローを図で確認。
      • 失敗時のメール送信、リトライなどの設定が可能。
  • MapRの検証も本格的にやる予定
    • スナップショット機能
    • ボリューム機能を利用したアクセス管理
      • リクルートのようなマルチテナントの会社には良さそう。

今回のイベントのメインスポンサーのリクルートさんの発表。前回のconferenceの発表では、まだ実用には至っていなさそうな感じ?でしたが、今回は実例がバンバン出てきて、ちょっとびっくりしました。現状、そんなにびっくりするようなサービスは無いですが、結婚やらグルメやら就職・転職やら習い事やら中古車購入やらマイホーム購入まで、人生の一大イベントからちょっとしたことまで、各サービス間で個人を結びつけられれば、データの量は半端ないと思うので、日本で一番データの掘りがいのある会社なのかもしれないな〜とセッションを聞きながら思いました。エンジニアで年収○○万の人におすすめの結婚式場とか!?
あと、Azkabanは聞いたこともなかったので、けっこう気になった。

Hadoop and Event collection    Terjeさん

  • Flume
    • ログ転送用のミドルウェア
    • Master, agent, collector が存在する。
    • Decoratorを使って、実際に保存するデータのFilterなどが行える。
    • plugingが使える。
    • 多機能すぎて使いづらい時がある。
    • セキュリティの問題。
  • パッチを作っている
    • Master lessのAck 機能
    • OSSにコミット済み or コミット待ち。
    • どんどんOSSに貢献していくよ!
  • QA
    • なぜHBaseではなく、cassandraをチョイスしたのか?
      • HBaseは初期導入コストが高い。hadoopのインフラにコストをかけられない場合は、cassandraで作ってしまうという方法もありだと思う。

Flume知らない上に、英語だったので、あまり理解できず。。。

マーケティング向け大規模ログ解析事例紹介 NTT コミュニケーションズ 原さん

  • Hadoopワールドで発表予定の内容
  • BizストレージとBizマーケティングというクラウドサービスを展開中。
  • Bizマーケティング
    • アクセスログの解析
    • 口コミ情報の抽出
    • リッチインデクシング技術を使って口コミを解析
      • NTT研究所が開発した技術
      • ワード抽出、関連語抽出、ポジネガ抽出、位置情報抽出
  • Map-reduceの高速化
    • Map multi reduce, local reduce
    • PJoin
      • ともにNTT研究所が作成。

ミクシィにおけるhadoopの利用  @takahi_i

  • mixiにおけるhadoopの利用
    • 複数クラスタがあるが、いずれもデータノードの数は4-5程度。
    • ログデータ、DBコンテンツをHDFSに投入している。
  • 推薦機能
    • ニュース、チェック、レビュー等に推薦機能を導入したいと思っている。
    • Googleニュースのレコメンドタブ的な。(この機能はUSロケール限定)
    • 類似インスタンスを集めることで実現可能。
    • 文書の場合 -> 同一単語を多く含む
    • ユーザの場合 -> 同一の商品を購買した、同一のニュースを参照したetc..
    • 総当たりでの類似オブジェクトを検索しようとすると、オブジェクト数の二乗の計算量になり、効率が悪い。
  • LSH
    • 効率はいいが、精度に問題があると言われている。
    • Google ニュースで導入されているらしい。
    • インスタンス毎にベクトルを生成する。
    • ECサイトであれば、商品IDを次元とした多次元ベクトル。
    • これに関数(後述)を適用し、ユーザ毎の値を決定。
    • 関数が肝となる!
  • 実験
    • mixiニュースで推薦記事の作成を試験した
      • ニュース記事は閲覧頻度がベキ分布になってしまっているが、あまり見られていないものも見られるようにしたい。
      • 移り変わりが激しいので、高速に動作することが重要。
    • 結果
      • ニュースでは参照するニュースがカテゴリを横断してしまい、あまりいい結果がえられず。。
      • カテゴリを適用してみたら、結果がよくなった。
  • その他、作ったツール

WEB+DB PRESSで大規模データ分析が取り上げられた時の伊藤さんの記事がかなり分かり易く、likelikeを触ったり、コードを見たりしながら、知識を膨らますことができたので、今回、一番期待していたセッションでしたが、意外にもlikelikeはほとんど進化していませんでしたww。(他のツールを作ったりされていたようです。)
WEB+DB PRESS Vol.59
map-reduceのデザパタ本もhadoopを始めた人の次の一歩的な位置づけとありましたが、統計とか機械学習とかの素人な状態な自分にとって、ベタのMap-Reduce×統計処理とかデータ抽出とかっていうのは、かなり参考になる有り難いプロジェクトなので、今後、発展していくといいな〜と思う分野でした。また、likelikeのように○○のためのプロジェクトとはっきり用途が限定されていると分かり易くて良いなと思います。
(Mahoutも出てきていますが、やはり、そもそもの知識がないとMahout使っても、、、という所があったり、色々できすぎてソースコードを元にあれこれ勉強するのには不向きだったりするのかなと思ったり。)

  • 収穫物

会場で↓が先行値引き販売していて\2500円でゲット。玉川さんのLTを聞きながら、これは売れるに違いないと思い、途中離脱して買いに走りました。(LT後はやはり大行列)
おまけでビックリマンサイズの象さんのキラキラシールもGET。

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理


まだ、2章までしか読んでいませんが、かなりの良書の予感。(ちなみに、@okachimachizさんのブログによると、3章が最も大事な模様。)
そして、比較的薄い本なので、気合いを入れなくても何回も読みなおす気になりそうな所も好印象です(笑)。
mixiの人やリクルートの人の発表の中でもデータの導出についての解説がありましたが、mahoutが国内でホットになっていったり、機械学習のサイトに大量にブクマがついたりと、そういう分野とhadoopとの架け橋的な存在を多くの人が求めているような気がするので、スマッシュヒットな一冊になるんじゃないかな〜と勝手に思ったりしました。

[[Hatena10th]] はてな10周年おめでとうございます

Hatena10th
はてな10周年。おめでとうございます!

わざわざブログを書こうと思ったのは、勿論Tシャツ狙いというのと、
「へんな会社」の作り方 との出会いが、自分にとって結構な分岐点となった気がするから。
文系上がりでろくに開発もできない状態なまま、「上流行程」やら「コンサル」やらという言葉に、言葉尻と給料良さそうという2点から漠然と憧れていて、でも何か違うな〜と思っていた状態から、この本を読んで、こういう考え方や流れで物事が進んでいく、web上に何か作る仕事ってのが凄く面白そうだな〜と思いはじめ、上流行程には上れないまま(笑)、web系の開発の仕事を志向して今に至りました。
勿論、色々と思い通りにいかないことがいっぱいあったり、自分の力不足が歯がゆかったりはしますが、何だかんだと性に合ってるんじゃないかな〜と思うので、良い出会いだったと思います。


そして、10周年という一つの節目だしと思い、最初のエントリーを見返してみると、この本に影響を受けてはてなを使い出していましたww。
そう考えると、この時に初めてはてなを知ったということで、web系のことをやり出してまだ4年なんだな〜。この経験年数で、残念ながら個人的には先日30歳を迎えてしまいましたが、逆にまだまだ伸びれるに違いないと思って、日々、精進していきたいと思います。。
http://d.hatena.ne.jp/seikoudoku2000/20070710#1196611886

他にも、はてなハイクが始まった時とか、(サービス開始後、しばらくの間、星をもらうために大喜利みたいなお題に頑張って投稿続けてたりしてました。。)
http://d.hatena.ne.jp/seikoudoku2000/20071217#1197907031

はてなワールドの仮想大賞の時とか、
http://d.hatena.ne.jp/seikoudoku2000/20080125#1201310988

新しいサービスに関する記事も書いてて、色々面白い経験をさせてもらった中で自分も成長してきたんだな〜とか、その中に書いてある自分の感想は、今読んでもそんなに的外れでもないな〜と思ったり(笑)。

芋づる式に、他の色んな過去エントリーも読み直してしまい、昔のほうが言葉に切れがあるな〜とか、当時からそんなことを考えていたんだな〜とか、こんな風に勉強しながら今に至ったんだな〜と、部屋の大掃除をしている時ばりに思い出に浸ってしまいました。

こうやって色んなことを経験したり、記録したりしているのも、はてなとの出会いがあったからなんだな〜としみじみしました。
webの面白さを教えてくれてありがとうございます!!
改めまして、10周年おめでとうございます!!

もうすぐ、10周年記念ユースト!!

「へんな会社」のつくり方 (NT2X)

「へんな会社」のつくり方 (NT2X)

Hatena10th Hatena10th

デブサミ2日目の午後

引き続き、デブサミのまとめ。

スマートフォン向けソーシャルアプリの開発 GREE 伊藤さん

    • コンピューター = スマートフォンの時代が来つつある。
      • imodeの普及曲線を圧倒的に超えるスピード。
      • 日本は既に3Gがかなり完備されているが、世界的に見ると、まだまだ成長中。中国、ブラジル。
      • スマートフォン需要により、日本でも三年ぶりに携帯の出荷台数が増えた。
      • キャリアから見ると、音声ARPUの減少をデータARPUの上昇が補ってくれるというメリットがある。
    • ゲーム市場動向
      • 据え置き型のゲーム市場は縮退中、アプリ、オンラインゲームが急上昇中。
      • ミニゲーム -> angry birds 4200万ダウンロード + 有料が1200万。
      • ソーシャル ⇨ facebookはモバイルのアクセスがPCの倍。twitterはユーザの46%
      • アプリ内課金の成長。ゲームの場合、50%くらいがin-appでの収益になっている。定額課金も始まるのでさらに期待。
    • NFCの搭載。 near field communication.
      • taglet。mixiが作ったアプリ。
    • ゲームトレンド
      • シンプルand直感的。Angry birds , fruits ninja
      • ソーシャルゲーム。 restaurant story
    • ゲーミングプラットフォーム
      • Open feint, pankia, apple game center. etc..
      • まだ、デフォルトはなくて競争中。
    • ソーシャル + 単機能
      • Instagram レトロ写真の共有。 ##PC版のサービスは無い。
      • Path. 同じく写真共有。
      • シンプル and こだわったUI。
      • Facebook, twitterとの連携。
    • GREEのゲーム作成
      • Android, iOSともにwebkitベースのブラウザなので、新技術を積極的に投入。
      • ネイティブアプリもあるが、web viewをベースに作っている。-> 頻繁な更新、クロスプラットフォームな所に対応するため。
      • HTMLだけでできないことをネイティブで補う。
      • ただし、速度とUIではネイティブと比べて不利な点がある。
      • 環境的にいくつか厳しい面もあり。 ex. アニメーションGIFを再生できない -> JavaScriptで再生するということをやった。ブログに詳細あり。 http://labs.gree.jp/blog/2011/02/2800/ (多分これ。)
    • クロスプラットフォーム対応
      • Titanium Mobile が伊藤さんのお気に入り。
      • MogSnapもこれで作られた。
      • Phone gapは web + ネイティブのハイブリッドアプリを作れる。
      • ネイティブアプリにこだわらなければ、javascriptライブラリも整いつつある。jquery mobileとか。
    • マルチプロットフォームのゲーム系のエンジンも続々
      • Unreal Engine
      • Corona SDK
      • Airplay SDK
      • Unity ##本命と言われている。しかもライセンスが安いandソースもある程度公開されている。GREE iOS SDKとの連携機能を作成中。
      • 個人的には開発効率等を考えるとHTML5のほうへ流れていくのではないかと考えている。ただし、短期的にはまだまだネイティブも重要。

前に参加したイベント(http://d.hatena.ne.jp/seikoudoku2000/20110120)の内容と結構似ていたかなという印象。こういった業界の概要みたいのは伊藤さんじゃなくても説明できるから、次ははてな時代のブログに時々あったような、技術的にいかつい内容のセッションを聞いてみたい。

webの変遷 GREE 藤本さん

    • 五年前の振り返り。(## 五年前にもここで喋ったから。)
      • 会場にスーツ系が多かった。アウェー感。
      • GREEのDBも5、6台だったり、SPOFがあったり。
      • 200万PV, 30万ユーザ
      • ミドルウェア系は意外と揃っている。
      • jqueryは既にあった。
      • AndroidiPhoneはまだいけど、googleはその頃に会社を買収し、準備を始めていた。 -> この辺のものは作り上げたり、浸透するのに時間がかかることが分かる。
      • 五年前の三月にtwitterの最初のpostがあった。
    • なぜ振り返りが大事か?
      • 五年前の状態とその時、自分が考えていたこと、今、どうなっているかをつき合わせて考えることで、自分のものの見方に足りなかったものが見えてくる。
      • GREEでみると
        • ユーザ数100倍。
        • PV 1000倍。
        • エンジニア 10倍。
      • 当時、想定していなかった問題として、、
        • スケーラビリティの確保が大変。
        • オープンソースソフトウェアが動かなくなり、自作に挑戦。
        • 集中管理(svn)がきつくなってきた。
      • 常に10倍、100倍になった時に大丈夫かを考えたアーキテクチャが大事。少なくてもこうすれば、、みたいなオプションの準備が必要。
    • これからの話 (五年後を考えてみる。)
      • インターネット人口の増加。
      • ハードウェア性能、回線数の増加。 (ムーアの法則)
      • Connectivity増加。
      • これらが全て10倍、100倍。といった状況を考えてみる。

      • モバイルデバイスへのサービスの集約
      • プログラミング言語のinter-operability. 互換性。
      • サービスのinter-operability
      • データ容量の増加。
      • Runtimeでアクセスするデータ量の増加。
      • ユーザがポストするデータ量の増加。
      • レコメンデーション的な解析がより重要に。
      • モバイルデバイスの常時接続性
      • Smart phoneでMMORPG
      • サーバ側アーキテクチャの多様化
      • アプリケーションが複雑化しちゃう?PS3化。。 DS的なものの登場?


内容的には少し論点が見えづらかったな〜という印象。5年間の時の流れの中で、ハードや流行サービスの変化に比べ、ミドルウェアや言語に関してはそこまで変わっていないことはけっこう意外だった。
あと、目先のニュースを追っていると、どうしても五年後のことなんて考えられなくなってしまうので、期間を切ってそういうことを考えるのも思考として必要なんだと思う。

アマゾンにおけるAWSを用いた社内システム移行事例


##世界に六人のエバンジェリストのうちの2人が集結!!

    • Amazon自体もAWSの利用者である。
      • 社是に倹約 frugalityが入っているくらい厳しいコスト意識。
      • インフラは大事だけど、そこにエンジニアが注力することは理想的では無い。
      • グループであることを除いて、AWSというのは信頼できるパートナーである。
      • また、ハードウェアの導入の敷居が下がることで、様々な障害が無くなり、新しいものをつくることへのモチベーションが高まる。
      • トライandエラーも簡単。もし、大ヒットしたら容易にスケールアウトできる。従来だと、ハードウェア買ってDCに置くのに半年とか??AWSだと数分。
      • この違いはサービスの進歩の量的な部分でなく、質を変えてしまう。
      • VPCを使うことで、社内システムも移行可能。
    • 3rdベンダーとの協業。
      • クラウド関係用のライセンスモデルを提供してもらっている。(Oracle, Microsoft など)
    • Broadcast.amazon.com
      • 研修用の動画を見たりする、社内アプリケーション
      • 旧 -> 手作業でエンコード、その後、公開作業。
      • 現 -> 誰でもアップロード and 自動公開。
      • 2人にエンジニアが三週間で作った。
      • エンコードサーバはクラウドに置く ⇨ オンデマンド、スケーラブル。
      • ビデオストレージもクラウドに。
    • BMC (ユーザサポートとかで使われる一般的なシステムの名前らしい)
      • 三つのデータセンターに負荷分散させていて、その中の一つにEC2を使っている。既存の資産はそのままに、拡張分に適用してみるこたことで、上手く移行できた。
    • 学んだこと
      • 早い段階からセキュリティに取り組む -> 安心感の向上
      • 使いやすくするようにしていくが大事
    • Amazonという世界最大のECサイトを運営しているお客様の要求に応えることで、AWSも成長している。


先日のROOのセッションと同様、せっかくUSAからJeffさんが来てて、しかも玉川さんまでいるのに、翻訳という形をとることで、内容が減ってしまう & かなり台本に沿ったとおりの内容なってしまうのが凄くもったいないと思った。
あと、社内システムの移行ということで現実的な話は聞けたけれども、ECサイト側でのAmazonならではのスループットやデータ量の話をしてもらってて、もう少しびびらしてもらいたかった。
AWSを導入することで、開発の量ではなく、質が代わるというのは確かにあるだろうな〜と思う(環境準備してもらったり、ちょっとポート開けるのも依頼ベースだったり、、面倒になってしまう)ので、ちょっとしたプロととかを作る時とかには、意識して使ってみようかなと思う。


アメーバピグ バックエンド Cyber Agent 桑野さん、根本さん

    • アメーバピグ
      • 開始から丁度二年。ユーザ数600万人。
      • 月に六億円の売り上げ。
    • システムの特徴
      • Adobe flashを利用したリアルタイム処理
      • Flashで独自プロトコルを使ってsocketサーバと呼ばれているサーバとやりとりしている。
    • 大きく変わった点
      • サービス開始当初は自作KVSとMySQLのハイブリッド。現在はMySQLオンリー。

      • バックエンドに依存しないモデル
      • オープン当初は自作KVS(NDI)に大きなメリットがあった。
      • スケールアウトの仕組み、キーがソートされているのでレンジ取得が可能。
      • データが増大してきて、DBとの連携に時間がかかるようになった。 -> 廃止!!
      • アプリの設計としてデータ取得部分を抽象化して、pluggableにしておいたので、比較的スムーズに移行できた。これは実装しておいて良かったと思っている。
    • 負荷テスト
      • 本番の操作ログを取得し、同様の負荷をかけてみて、動作に問題が無いかを確認。
    • 差分テスト
      • 両方のバージョンで動かしてデータに差異が無いかをスクリプトで確認。
    • 現在の構成
      • MySQL + Fusion IO の組み合わせ。
      • コストとしては当初よりは掛かるようになってしまった。
      • Fusion IOは無くてもいけたと思うが、DBの台数が膨れ上がり、運用コストとして跳ね返ってくることが想定されたので導入した。
      • Cassandra等の分散KVSという選択肢もあったが、実現性を重視した。また、運用ノウハウの面でも不安があったので、将来的なコストとして考えると、どうなの??という思いもあり。
      • 構成の決定にあたっては実現性を重視した。こういった新しい技術は部分的に導入して行きたいと考えている。
    • 画像ストレージの運用、構築編
      • ブログのユーザ画像のストレージで多く使われている。
      • リリース当初、、、
        • 物凄く不安定。
        • データロストもあり。(リアルタイバックアップでは無かったため。)
        • 気づいた時点で70%のストレージ容量を占めており、二ヶ月の期間しかなかったので、出来るだけの検証をしてリリースしてした感じ。
      • 現在のTraffic ->3GPS
      • 投稿容量 -> 120GB/day
      • アクセス数 -> 約3億〜4億PV
    • ストレージ構築のプラクティス
      • その1 HDDを構成するコンポーネントを全て列挙する。そして、順に調べていく。
        • Server - RAID間の通信 サーバ改善、RAID改善 etc...
        • RAIDコントーラの適性温度。
      • その2、その3 怪しい部品は交換、思い切る!
        • 突然HDDを認識しなくなることがある。。 結局原因がわからず、144台の全交換。-> 現象は

再現しなくなった。

        • もちろん対策をうっても効果がなかったものも多数あり。
        • どの組み合わせがベストかの検証が難しい。
      • その4として、複数の対策を並行して調べていき、効果の無かったものを外していくことで、スピードアップ。

自分が聞いた中では一番技術的に突っ込んだ内容で、聞きごたえがった。内容的にはスマートではない、比較的泥臭い仕事の紹介だったように思うけど、そういう実サービスの展開にあたって得られたノウハウはかけがえないだろうし、あと、梅田望夫さんの本でgoogleも最高のエンジニアが最も泥臭い仕事を嬉々としてやる会社であるというような説明をしていた覚えがあって、そのことを思いだした。

GPGPUを使った開発 馬路さん

    • GPU(Graphic processor unit)の進化
      • 実写のようにリアルな三次元グラフィックをリアルタイム描画。
      • それまでは処理を行う箇所が固定化されていたが、8シリーズ以降から、unified designで各---プロセッサで柔軟に色んなタスクを並列で処理できる様になった。
      • CPUと比較して、飛躍的に性能が向上していってる。
      • CPUと協調して、GPUの圧倒的なパワーを利用すべし。
    • コーディング方法
      • C with CUDA Extension を開発。
      • Appleが開発したopen CL などもあり。
      • プログラムが比較的用意で、圧倒的なパフォーマンス。
      • 今、世界一のコンピュータはGPUを7000個使っている。
    • ビデオデモ
      • 全てのドット毎に、ニュートン力学とかを適用しているので、リアルな動きが再現される。
      • さらに性能アップした4CPUのデモを今日からやっている。
      • Kal-El -> ベンチマークintelに勝ったよ!
      • 4コアを載せたスマートフォンが今年の年末には出てくる!!
    • Window + officeも脱インテルの流れ!?
    • 今後の課題としては使用電力量の改善。

ぶっちゃけ、GPUという言葉だけしか知らない状態で参加したので、内容的にはいまいちついていけなかったけど、galaxyとの比較デモが印象的だったのと、年末には圧倒的な性能のスマートフォンが出荷予定ということで、先の藤本さんのセッションで、5年後を考えてみようというような話があったけど、それってもの凄く難しいことだなーとしみじみ思った。
何となく、ゲーム機の進化を見ていると、ハードの進化が速すぎてソフトがついてこれなかったり、ソフト開発の予算がふくれあがってしまったりした中で、DSが大ブレイクしたという歴史があるけど、スマートフォンもそういう流れになっていくのかな〜と思ったりした。