ソーシャルメディア、ソーシャルアプリが育てたNoSQL技術に参加してきました

震災の影響で２カ月程延期されていた ソーシャルメディア、ソーシャルアプリが育てたNoSQL技術 に参加してきました。
参加者がそのままスライドした影響か、ATND上では定員を大きく上回る参加あったが、実際の参加者が少なく結構席も空いていました。

MongoDBで作るソーシャルデータ新解析基盤 [twitter:@doryokujin]

  • 旧解析基盤(MongoDBとHadoopを活用)の処理フロー
  1. Data Gathering
    1. 分散するサーバから各種ログをローカルに収集
    2. 課金・登録情報の該当データをMySQLから取得
    3. ユーザゲームセーブデータをCassandraから取得
  2. Data Pre-processing(Hadoop)
    1. ログ整形
    2. フィルタリング
  3. Data Analysis(Hadoop)
    1. ユーザIDをキーにした各指標値を集計
    2. アクセスログの集計
    3. イベントの効果測定
  4. Result Data Strage(MongoDB)
  5. Data Mining
  6. Data Sharding
    • MongoDBは解析結果格納サーバとしてのみ利用
    • 集計自体はHadoopで行う
    • 大容量のログをHadoopでReductionして、MongoDBに格納
  • 新解析基盤(MongoDB、Redis、Scribeを活用)の処理フロー
  1. Data Gathering(Scribe)
    • 1時間毎にサーバからログファイルを転送
  2. Data Pre-processing
  3. Raw Data Strage(MongoDB)
    • Shard Keyにhourを指定し、Shard0 - Shard23に１つずつ割り当てるマニュアルSharding
      • Shardingの各種問題対策にもなるし、データが追加されているshardについても把握できる
    • 自動Balancerも停止
    • mongod１つに対し、1CPUしか使えないため、複数Shardを１台の物理サーバに同居
    • 解析結果格納用のShardはSSDを使い高速にする
  4. Data Analysis(MongoDB + Redis)
    • smallデータの場合
      • 24Shardを利用して、Mongo Master MR
      • デフォルトのMongo MRはMasterしか使えない
      • Map/Reduce実行中でもDBロックしないがパフォーマンスが低下するため、長時間やりたくない
    • middleデータの場合
      • insert中のShardを除く全Shard全Primary/Secondaryのmongodに直接接続
      • mapreduce/distinct/findなど実行。findの場合は別途集計処理
      • 各mongodの実行結果（key,value）を同host内のRedisに集約
    • bigデータの場合
  5. Result Data Strage(MongoDB)
  6. Data Mining
  7. Data Sharding
本番で使うための"Cassandra"ガイド [twitter:@_shimada]

  • 強み、弱み、落とし穴
    • 勝手にシャーディング
      • スケールアウトが容易
      • キーの設計を間違うと、１か所にデータが集中
    • 勝手にレプリケーション
      • 反映に掛る時間はベストエフォート
      • スレーブが反映前のデータを返すことも
    • 勝手にフェイルオーバー
      • 落ちたノードへの書き込みは自動的に他のノードが受け取り一時保管
      • ノードが復帰したらデータが書き戻される
    • スケールアウトと負荷分散
      • ノードを追加すると、データが一番多いノードからデータを半分引き取る
    • データの整合性
    • 読み書きのパフォーマンス
      • 読み出しよりも書き込みの方が早い
      • コミットログ書き出し：
      • 読み込み：書き込みの速度比、書き込みが８倍程早い
  • まとめ
    • 大量のデータを大量のサーバで捌く
    • 一部で障害が起きても全体の整合性
    • 書き込み速度重視
    • データの整合性を犠牲にして、速度を上げることができる
  • フィットするパターン
    • 大量のデータが一斉に飛んでくる
    • 大量のデータを統計処理に使いたい
      • ごく一部のデータが欠損しても全体には影響がない
    • Webサービスのログ
    • リアルタイムな統計的な処理
分散KVS “okuyama” のご紹介と、実際に利用した事例のご紹介 [twitter:@okuyamaoo]

  • 最近追加した機能
    • パーティション機能
      • 容量は可変（初期設定は不要）
      • 数の限度なし
    • ストレージ機能の強化
    • 全文検索機能
      • N-Gramと辞書方式のMIX
      • N-GramのNの部分はIndex作成、検索時に指定可能
      • 作成Indexのグルーピングが可能
  • 利用事例
    • 共有キャッシュサーバ
    • データ集約ストレージ
"memcached"とトラブルとソーシャルアプリ [twitter:@goodoo]

  • 「星空バータウン」の規模
    • ユーザ数約200万人
    • 約10億PV/月
    • 月間アクティブユーザ75万
    • ピーク時のトラフィック200Mbps
    • サーバ台数 約50台
    • PHPのセッション共有にmemcachedを使用
  • memcachedのトラブルの教訓
    • memcachedを運用する場合には-cによる接続数の制限は大きくとる(きちんと監視されていること前提)
    • Networkまわりのパラメータチューニング
      • iptablesを使用する場合は、ip_conntrack_maxの制限
    • 特定のサーバにアクセスが集中するのはリスク
  • キャッシュの考え方まとめ
    • NoSQLとDBの棲み分け
    • NoSQLの出番は？
      • 最悪データがロストしてもいいところ(セッションデータなど)
      • あくまでキャッシュとして割り切ってつかう
      • ロールバックできなくてもユーザが不利益を被らない処理に利用
"HandlerSocket": MySQLの非SQLインタフェース

  • 狙い
    • 単純なCRUD処理を高速に実行したい
      • SQL処理を省略
      • 単純な処理に適用可能な最適化
    • しかも同じデータをMySQLでも処理できるようにしたい
      • 単純かつ速度が必要な部分だけを非SQLに置き換えたい
      • SQLから少しずつ移行したい
  • mobageへの導入
    • 2010/08 本格利用開始
      • サービスを停止せずに移行
    • 導入以降トラブルは一度もなし
    • 一度HandlerSocketのプラグインを更新
  • 最初の適用箇所
    • MySQL + memcachedで構成
    • クエリは単純だが、数が膨大
    • 既存構成の問題
      • 同時接続数の問題で、mysqlの持続接続の利用が難しい
      • memcachedとのデータ同期のための仕組みが複雑で運用に負荷がかかっていた
      • ネットワークトラフィックが必要以上にでてしまっていた
  • 導入効果
  • 利点（libmysqlと比較して）
    • CPUを食わない
      • サーバ側、クライアント側のいずれも効果あり
      • 特に単純なクエリで差が大きい
    • ネットワークトラフィックが減らせる
      • 特に単純なクエリでおおきい
    • 同時接続数がほぼ無制限
      • すくなくとも65000本までは可能
      • 同時接続数を増やしても性能劣化がほとんどない
  • HandlerSocketに向いているケース
    • データサイズが小さく十分小さくメモりに乗る
    • 単純なクエリ、サーバのCPUがネック
    • 単純なクエリ、トラフィックがネック
    • 同時接続数が多すぎて、維持接続がつかえない
  • HandlerSocketに不向きなケース
    • クエリが複雑でHandlerSOcketで実現困難
    • クエリ１回あたりのCPU負荷が大きい
    • データサイズが大きくDisk IOがネック
  • 機能（参照系）
    • PKやUKを使った行取得
    • 範囲取得
    • SQLのINのような複数行取得
  • 機能（更新系）
  • libmysqlとの性能比較
    • 単純な参照クエリで数倍〜１０倍
    • 取得する列数が多くなる場合に特に有効
  • なぜ早くなるか
    • SQLパース処理をしていない
      • CPU消費がすくない
    • リクエストを集約実行
      • CPU消費やディスクI/Oが少ない
    • 独自プロトコル
      • libmysqlでは、レスポンスにDB名、テーブル名、カラム名などが含まれているため、ネットワーク負荷が大きい
  • 課題
    • ビルドが面倒
    • mysqlバイナリ互換性問題
      • mysqlのバージョンやビルドオプションを代えるたびに、handlersocektをビルドする必要があうr。
  • 今後の予定
    • 不可分なread-modify-write操作のサポート
    • InnoDB以外のエンジンでの検証
      • クライアントライブラリの整備
      • スクリプトエンジンorJVMを埋め込む
まとめ＆所感

doryokujinさんのMongoDBをごりっと使ったデータ解析基盤は素晴らしい。Mongo愛を感じる。
詳細は次回MongoDB勉強会でも聞けるみたいなので、ぜひ皆さま参加ください。
HandlerSocketは万能ではないが、特定用途向けには超強力な印象。InnoDBを使うので
普通にSQLでもクエリを投げれるところに安心感がある。