タグ: Developers Summit

Developers [Social Enterprise] Summit 2012

日時:2012/07/27
場所:東京コンファレンスセンター品川
URLDevelopers [Social Enterprise] Summit 2012

B-3 社内ソーシャルメディア開発トライ&エラー おれたちの4tate(株式会社インターネットイニシアティブ 原島 法子 氏 / 岩永 義弘 氏)

開発の契機

会社を合併し、人員増加
→使っているツールなどが合わず水と油のように

そこで、社内コミュニケーションツールの開発指令が下る

プロジェクトゴール

  • 組織を横断
  • スタッフがコラボレーションできる
  • 社内コミュニケーション基盤で
  • イノベーションを起こす

しかし、いままでコミュニケーションツールは流行らなかった。

  • システム自体の問題
  • 心理の問題

そこで、システムを提供すると同時に実例・実績も提供することにした。
→開発チームがコラボしてイノベーションを起こすことにした

開発チーム

4人チーム(2人+各人の上司)
生きた事例となるように

やるからには効率良く

  1. ファシリテーション
  2. アジャイル
  3. UX

1.ファシリテーション

仕様を詰めたいが時間が足りない

ミーティングでファシリテーションを採用

課題の共有
ふせんを書いた 1時間
課題の分類
みんなで話し、付箋を分類 1時間
課題から機能を抽出
課題を解決する機能をイメージしてもらい、詰めた 2時間
機能の優先度をつける
縦軸に重要度を3段階・横軸に難易度を3段階の9分割して仕分け 2時間

実質6時間であっさり決まった。この過程はまさにプロジェクトのゴールでやろうとしたこと

「これをシステム化したらいいのでは」

2.アジャイル

しかし問題発生

チームは2人

  • 経験がまるで違う
  • スキルは未知数

⇒少し進めては調整してみよう

お試し期間で3週間。実質38時間でどれくらいできるか測った

その後3ヶ月かけて本格開発

本格開発ではお試し期間のふりかえりから以下を実践

  • 開発する際には一緒に作業
  • とにかく連絡しあう
  • やるやらないをきっちり分ける

リミットから60日を残して、必須機能が実装できた。

でもチーム2人での開発はお勧めできない。(多数決がとれないから)

3.UX

50人でアルファリリース
→最終的に使い続けた人は1人

期間中にもらったフィードバックを取り入れるとアクティブユーザは増えるのか
→ユーザ数は増えない

そもそもどうしてこうなった?

  • ふせん方式は馴染みのないコンセプトだった
  • 機能の見せ方(あったら便利だが邪魔。作った機能が使われない)

つまりUX視点が欠けていた

そこで、UXのプロの力を借りて、UX強化

フロー
a.いつ、どのように使われるかを調査
コミュニケーションの手段と内容・人数
そのコミュニケーションがどうなったら嬉しいか

b.ペーパープロトタイプテスト

c.実システムで使用感テスト

結果、UX改善でアクティブが30人に

このプロジェクトで得られたもの

  • これらの実績が注目された(勉強会で聞く方から話す方へ)
  • 同じ志の仲間に出会えた
  • システムを面白いと言ってもらえた

B-4 グリーを支えるソーシャルコーディングのすべて(グリー株式会社 大場 光一郎 氏)

greeの開発の課題

  • 急激な増員
    • 2010年から毎月50人増えた計算
    • 1人あたりskypeのチャットルームが200個とか、1チャットルームの最大人数を上回るように
  • 業種の増加
  • 国際化
    • 世界に9拠点

周辺の動向

バージョン管理がSubversionからgitへ

GitHubの登場。forkとpull request。
これらにより従来はコミッターしかコードを修正できなかったが、誰もがプロジェクトをforkでき、変更を還元できる

greeの開発

Subversion→Gitosis

gitは分散repoによって複数人開発をより良くしたが、プロジェクトを超えて開発するための機能が足りない。

Gitosis->GitHub

github導入の目的
  • OSS開発で良いソされている手動の導入
  • プロジェクト間のコラボレーション
  • 埋もれているプログラムの発掘
  • 国際化対応
導入効果
  • Gitosisは管理者が必要でリポジトリ作成の申請が必要だったが、GitHubは各人が好きなようにリポジトリ作成可能になった
  • 誰が何を開発しているのか(メンテナやチームメンバーがわかる)
  • 手元で書き捨てるようなコードも共有できる(Gist
  • メンテされないプログラムも使いたい人が修正して使い続けられる
    →プログラムの寿命が伸びる
現在の課題

業種を超えてのGitHubの使い方

GigHub導入の壁

ソースコードを外に置くということ

GitHub Enterprise – Install GitHub on Your Servers

githubのオンプレミス版
自分たちで運用する

Q&A

pull requestの使用頻度は

プロジェクトによるが、ワークフローで取り入れているところもある

pull requestのマージ方法は

メンテナは置かずチームでレビューする

ツールを作っているところもある

Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers’ Blog

GitHub Enterpriseでの成果物はgithub.comので公開することは?

greeというOrganization名でunityプラグインなどを公開中 → gree · GitHub

yumdownloader

広告

Developers Summit 2011 1日目

URL:http://codezine.jp/devsumi/2011

場所:目黒雅叙園

【17-A-3】ソーシャルアプリを支えるインフラの現場

モバイル向けソーシャルアプリの特徴

  • Proxy型の画面遷移
  • FlashLiteを使用した画面構成
  • mixiが仕様化(OpneSocial WAP Extension)

パネラーの方が扱うサーバ台数

  • KLab 1500
  • ドリコム 100(Xen 400 instance)
  • ライブドア 約8000 (40名くらいで管理)
  • DeNA 2500〜 (モバゲーのみ)

クラウドについて

  • Klab
    利用していない

    • 責任点があいまいになるので、すべて自社で行っている
    • 性能が安定しない
    • アクセス増の時、DBサーバがネックになりやすい
    • WEBは仮想、DBは実サーバという構成で検証しているが、評価できておらず利用していない
  • ドリコム
    海外をやめ国内にした

    • 移行したのはソーシャルアプリの5秒ルールがネックなため
    • ハズレインスタンスにあたることが多い(パケットロスなど)
    • 国内のクラウドサービスが増えており、スペックの開示や、コストダウンも進んでいる
  • ライブドア
    利用していない

    • 現在は、利用していないが、今後、可用性、性能が向上したら利用することを検討する
    • クラウド技術を自社サービスに取り入れたい
  • DeNA
    ほぼ使っていない

    • 海外展開時に検討したが、現在は万が一の選択肢として最低限の環境をキープしているのみ
    • 不安定な印象、原因の切り分けが難しい

自社でクラウドを展開することはるのか

  • Klab
    クラウド技術は仮想だけではない。将来的に提供できたらいいな
  • ライブドア
    マネージドIaaS
  • DeNA
    社内や協業会社に使ってもらうプライベートクラウドは検討

→クラウドは今後に期待

RDBMS

パネラー全員MySQLを使用

構成について

  • Klab
    Master:1 + Slave:2(うち1台はバックアップとして)を1セット
  • ドリコム
    Master:1 + Slave:2(Backup)
  • ライブドア
    Master + Slave
  • DeNA
    Master:1 + Backup兼いざというときのMaster用Slave:1 + Slave:5
    SlaveにSSDを使用

SQLチューニング

  • Klab
    • スロークエリログの蓄積
    • explainでSQL分析
    • indexの追加
  • ドリコム
    Railsを使用しているので、プラグインを活用してクエリをチェック
    スロークエリの量はcactiでチェック
  • ライブドア
    インフラ提供側として事前テストをお願いします
  • DeNA
    DBIに手を入れて、クエリ情報を出力。それを分析する

NoSQL

  • Klab
    • memcached
    • Tokyo Tyrant(TT)
    • APC

    PHPを使用しているのでAPCならオブジェクトを保存できる
    TTは便利なのだが、RDBMSで簡単にできることができにくいので、あまり使われなくなっている

  • ドリコム
    • memcached
    • TT

    用途に応じて使い分けている
    memcachedは100KB超のデータを入れ続けると不具合が出た
    TTはカウントアップするデータを入れている

  • ライブドア
    • memcached
  • DeNA
    • memcached
    • Handler Socket

    memcachedは基本的な使われ方で使用
    Handler Socketは限られたところでしかいまは使われていない

ソーシャルアプリ

FlashLiteの動的生成

  • Klab
    • FlamixierというPHP拡張モジュールを開発
  • ドリコム
    • swfmill
    • swfruby
  • ライブドア
    サービスを提供中だが、顧客は自身で生成システムを用意していることが多い
  • DeNA
    なるべく外部のCDNサービスを使用して、なるべく外においている
    3Dアバターメーカーは自社開発

スケールアウトとスケールアップ

  • Klab
    両者は仲の良い物。1台の性能向上の結果、全体も向上する
    ディスクアクセスの低減を目指している
    なるべくメモリへ
    Flash合成はリクエストごとにやっている。合成後はすべてメモリ上に乗らないが、素材は載るので全部載せている
  • ドリコム
    クラウド利用のため、スケールアップは限界があるので、スケールアウトを考えている
    サーバ台数が多くなると、コストがかかるので、DBは自社サーバにする、あとは転送量次第
  • DeNA
    両方必要
    ハードウェアはいいものを使用する

現場での体験談

初期のソーシャルアプリリリースの際、いろいろな問題が発生した。
→マルチキャストでファイル転送していたが、帯域制御していなかったため、フルに使ってしまい、全サービスが落ちた

今後の展開

  • わからない
  • スマートフォンに対応しつつ、随時アンテナを伸ばしておく
  • 国内クラウド
  • オートスケールする仕組みづくり

【17-A-4】大規模Webサービスのためのデータベース技術の現在・未来

MySQLが目指したサービス

大規模WEBサービスを動かすのにふさわしいDB
高性能、高可用性

DeNAの現在

  • 1日あたり20数億PV
  • 500台のDBサーバとそれ以上のWEBサーバ
  • データセンター3拠点
  • 数百のアプリケーション

課題

DB1台ですべてのトラフィックを捌けない

ユーザIDを主キーに持つテーブル
→レコード数は限定(数百から数千万)→1000万レコードで100B/Recordとしても1GB
→捌けなくはない

ユーザID+αで主キーとなるテーブル
→1億〜10億レコードなんてざら
→分割しなければならない

分割手法

Sharding(水平分割)

  • 分割ルールは様々(剰余方式、マッピングテーブル方式【DeNAはこちらを採用】)
  • 一度基盤を作れば、あとは使い回しが可能
  • アプリケーション側の作り込みが手間
  • サーバ追加で新しいShardが追加できるので簡単
    • 台数の増加とスループット
      →すべてのShardにクエリを投げて結果を取らないといけないパターンが多いと、台数増加でもスループットがあがりにくい

サーバ台数の多さからのコスト高

1台のサーバの性能向上を目指す

いまは64ビット、大容量メモリ時代

  • ヒット率の向上
  • 台数の集約が可能に
  • バッテリーバックアップ付きライトキャッシュが標準搭載されることによりコミットのコストが改善された
    →InnoDBが利用されるようになった

高性能化がもたらす副作用

  • 1大あたりのユーザ数増加
  • マスターはマルチスレッドで処理できるが、スレーブはシングルスレッドのため、レプリケーション遅延が起こるようになった
    →シングルスレッドで高いアクセス性能をだすには?
    →SSDの採用
    書き込み時もデータを読み込む必要があるので、結果としてアクセス性能が向上した
    マスターへの導入は勇気が必要
    マスターよりはスレーブに導入するほうがコストパフォーマンスが高い

→MySQLの大きな残課題は、レプリケーションの並列化

今後

SSD

  • マスターでのSSD使用
  • スレーブでPCI-ExpressのSSD
    →マスターがHDDの場合、性能を持て余すほど早い
    →複数のスレーブを1台にまとめることができる
    →しかし仮想環境上では性能面で苦しい
    →PCI-ExpressのSSDのマスターでの使用はいつかはやってくる
    →またスレーブ側がボトルネックになるかも

PCI-Express SSDの台頭の影響

  • ストレージからCPU,ネットワークへボトルネックが移動する
    • ネットワーク
      レイテンシが問題になりやすくなる
      100Mはすぐ使いきってしまう
      1Gは10万qps出せる。100接続で25万pqs出せる
      10Gのレイテンシは良くない
      ネットワークに関するチューニングが必要になる
    • CPU
      CPU利用効率が悪い処理が問題に(文字列処理など)
      →NoSQLが選択肢に
      MySQLをNoSQLとして利用する(Hander Socket)

データベースへの接続

現在は、都度接続・切断が主流

課題は、TCP SYNの3秒待ち
→ボトルネックがネットワークに移ると無視できない問題に

ソリューション

  • パーシステントコネクション
    接続を張りっぱなしにしておく
    1台のWEBサーバの接続数×台数が最大接続数に
    →10000接続くらいになる
  • Proxy型コネクションプール
    Proxyサーバを置いてそれが、DBサーバと常時接続
    Proxyサーバが大量のネットワーク送受信を捌けないといけない
  • DBでスレッドプール
    DB内部の機能としてコネクションをプールする

運用

運用メンバーはサーバほどスケールしない
→サーバが100倍になったところでメンバーが100倍にならない

1人あたりのサーバ台数が飛躍的に増加する

担当サーバを減らす努力

  • ハードウェア故障率を減らす
  • 手動フェイルオーバーをなくす
  • 1台あたりの作業時間を少なく

【17-E-5】Cassandraで見るNoSQL

NoSQLとは

KVSとNoSQLの違い
→KVSはNoSQLの一種

RDBMSとNoSQLの違い
→RDBMSはパフォーマンス向上のためスケールアップを行う
NoSQLはスケールアウトで対応
→RDBMSはSQLで操作
NoSQLはほとんどの場合API

NoSQL登場の背景
→Web2.0の登場→データ量の増加

NoSQLの特徴
→DDLが不要
→スキーマレスなので仕様変更が即座に対応可能

Cassandra

  • BigTable+Dynamoの特徴を合わせた物
  • FacebookやTwitterで使用されている
  • 下位バージョン互換性を犠牲にして機能追加を行っているので、まだ発展途上中
  • スケールでき、レイテンシが低い
  • 無停止でのスケールアウトができる
  • SPOFが存在しない
  • 一貫性の制御はアプリ側で行う
  • Hadoop、MapReduce対応
  • Thriftを使用しているので、言語サポートが広い

Developers Summit 2011 2日目

URL:http://codezine.jp/devsumi/2011

場所:目黒雅叙園

【18-A-3】スマートフォン向けソーシャルアプリケーション開発の現在

スマートフォンのトレンド

出荷台数

スマートフォン:1億台 > 9000万台:PC

3G回線普及率

USA、インドネシア、中国、ブラジルが躍進

2013年に契約台数6000万になることを予想(実際はもっと多くなる予想)
→周りを見渡すとほとんどスマートフォンを持っている人がいる時代へ

Androidの急速なシェア拡大(50%を超える)

スマートフォンの普及の効果

3年ぶりにモバイル出荷台数がプラスに転じる

データによるAPRU(1ユーザあたりの売上高)が上昇
→代わりに音声APRUが減少
→減少分を補う形に

スマートフォンユーザのアクティビティの実際

メール・WEB・電話 50%

ソーシャルアプリ、スマートフォンアプリ、ソーシャルメディアで50%

据え置き型ゲーム市場の現状

全世界的に減少傾向

一方オンラインゲーム市場は上昇

アプリ内課金の登場

売上手段の50%がアプリ内課金に

あるアプリが有料ダウンロードからアプリ内課金に変更したところ、急激に売上を伸ばした

予想:
アプリ市場は2015年に$25BILLION
アプリ内課金は$11BILLION

スマートフォン技術トレンド

NFC(Near Field Communication)
Android 2.3に搭載
iPhone5, iPad2にも搭載予定

2010ゲームトレンド

シンプル&直感的

例:AngryBirds / Cut the rope / Fruit Ninja / Enigmo

ゲーミングプラットフォーム

  • Open Feint
  • Pankia
  • Crystal
  • Apple Game Center

2010ソーシャルアプリのトレンド

単機能+ソーシャル

例:Instgram

単機能な分、デザインやUIがよく出来ている

FacebookやTwitterと連携するUI・機能がどれでも入っている

GREEのスマートフォン対応

Android、iPhoneともにWebkitベースブラウザで新技術を積極採用
→CSS3, HTML5, AJAX

HTMLだけでできないことをアプリで補う⇒ハイブリッドアーキテクチャ

  • プッシュ通知
  • 電話帳連携
  • カメラ・アルバム

さまざまなアーキテクチャ

  • HTML5
  • ネイティブアプリ
  • JavaScriptミドルウェア
  • ハイブリッド

今後の注目技術

クロスモバイルプラットフォーム

JavaScriptミドルウェア
→Titanium
MogSnap

ハイブリッドアプリ開発フレームワーク
→PhoneGap

HTML5 WEBアプリフレームワーク
→JQuery Mobile

ゲームエンジン

  • Unreal Engine
    →Android対応はこれから
  • Corona SDK
    →Luaで2D開発、ActionScriptライクに開発
  • Airplay SDK
    →C/C++ ライトワンスでコンソールゲーム機もサポート
  • Unity
    →JavaScript, C#, Luaで3D開発、ActionScriptライクに開発

【18-A-4】ウェブアプリケーション関連技術5年間の変遷とこれからのはなし

  • 思ったより、大きな変化はない
  • 10倍,100倍,1000倍を見据えたシステムづくりを

【18-A-5】前例のないソフトウェアを作る! コミPo!開発秘話

減色エンジンツールの提供を主としていた

着想から開発まで

きっかけ

ソーシャルアプリや、モバイルのスマートフォン化によって減色のニーズが減っていった
→新規事業への挑戦

  • 所有する技術
  • 時代のニーズ(UGC・CGM)
  • 漫画表現の優位性(モノを伝える手段としては有効)

基本構想

もとはゲーム会社に所属していた頃に考えた企画

2Dデータだとパターンを複数持つ必要があるが、3Dデータにすれば少なく済む

しかし何をいくつ用意すればいいのか?
→漫画で使用するいろいろなパターンを用意するとデータ量は膨大に
→自身が漫画家という観点から1ジャンルに絞ることで必要なデータが限定される(学園モノ)

開発の見通しがたった

しかし前例のないソフトのため、趣旨を説明するためにもプロトタイプを作成した

プロトタイプは現在提供している基本機能を網羅した

社内リリースを経て本格開発へ

開発からリリースへ

試行錯誤の連続

  • ターゲットが定まらない
  • 使われ方が定まらない
  • UIが決まらない

1年以上の試行錯誤を経て仕様が決定

  • 絵を書くのが不得意な人。でも漫画が書きたい人
  • WEB・メールを使う程度のPCスキル
  • マニュアルなしでも簡単に作れる

→これまでの既存のノウハウを活かす

すぐに使えるUIを作るには?

  • 誰でも使ったことのあるソフトを手本に
  • カーソルにしゃべらせる
    →場所によって形を変える⇒なにかあることを知らせる
  • 左クリックと、左ドラッグ
    →ライトユーザはこの2つしか操作しないので、重要機能はそれでできるように
  • コンテキストメニューの活用
    →ユーザは困ったら右クリックする
  • 配置を考える
    →目線を考える、グループ化する
  • アクセラレータキーへの対応
    →中上級者向けとして。お約束のショートカットやよく使う機能は押さえておく
    マニュアルを見なくてもいいように、キーの組み合わせはメニューに書いておく
  • 高度な機能は小さく
    →よくよく操作すると高度な機能がある

リリースから現在

発売後に分かるニーズ
→萌えキャラ好きユーザを想定していたが、会社のプレゼン資料やHPなどビジネス用途にもニーズが