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を使用しているので、言語サポートが広い

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中