デブサミ２日目の午後

勉強 技術

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

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

↓

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


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

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

アマゾンにおける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 桑野さん、根本さん

18 a-6 ameba pigg backend practice 20110217

    • アメーバピグ
      • 開始から丁度二年。ユーザ数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
      • アクセス数 -> 約３億〜４億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との比較デモが印象的だったのと、年末には圧倒的な性能のスマートフォンが出荷予定ということで、先の藤本さんのセッションで、５年後を考えてみようというような話があったけど、それってもの凄く難しいことだなーとしみじみ思った。
何となく、ゲーム機の進化を見ていると、ハードの進化が速すぎてソフトがついてこれなかったり、ソフト開発の予算がふくれあがってしまったりした中で、DSが大ブレイクしたという歴史があるけど、スマートフォンもそういう流れになっていくのかな〜と思ったりした。