スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例

スマートフォン×Cassandraによる
ハイパフォーマンスサービス基盤の
構築事例

株式会社コスモルート
クラウドR&D グループ
terurou
Cassandra Conference in Tokyo（2011/10/05）

1 All Rights Reserved,Copyright © 株式会社コスモルート 2011

今から話すこと
• 自己紹介＋会社紹介
• 事例紹介
– GeQuuとは
– リリースに至るまでのサービス基盤の変遷
• どのように技術的な難題を解決してきたか？
• まとめ


自己紹介＋会社紹介


terurou（YAGI.Teruo）
• Twitter: @terurou

• Blog: DenkiYagi（はてなDiary）
– http://d.hatena.ne.jp/terurou/


株式会社コスモルート
• 名古屋本社、東京支社
– 1989年設立、社員約60名
• 業務系のソフトハウス
– ソフトウェア開発
• 製造業、生産管理、ERP向けが中心
• アーキテクトやインフラも守備範囲
– ソフト以外にも機械設計、電子設計
– 研究開発
• Cassandraは2010年3月頃から使っています。


「terurouは何エンジニア？」『RIAかなぁ』
• 「クライアントからいかにして大量データを
操作するか？」を考えることが多い
– UX、ストレスフリーなUI設計
– データ構造、プロトコルレベルの設計
– Caching機構の設計（Frontend、Backend）
– etc...
• Silverlight, JavaScript, Android, ...
– Microsoft Tech Fielders Member
• PHP逆引きレシピ共著


主催コミュニティ
• DSTokai
– 東海地方のメタコミュニティ
• コミュニティ間の連絡窓口・イベント告知
• クロスコミュニティイベントの企画
– NGK：名古屋合同懇親会（花見、忘年会...）
• 大規模分散技術勉強会 in 名古屋
– 通称：大名古屋
– Hadoop本読書会（全10回、完）
– 「Hadoop MapReduce デザインパターン」とか
「オンラインゲームを支える技術」も読みたい


事例紹介
GeQuuとは


GeQuu －時空を超えろ－
時間と空間を自由に移動できる
ソーシャルなロギングサービス基盤

GeQuuクラウド
ログの送信ログの蓄積・解析
• GPS
• Message データの閲覧
• Photo
•… 連携


GeQuu －時空を超えろ－
• http://gequu.net/
• GeQuuの読み方は「じくー」です。
– よく「げくー」と間違えられますが…。
– Geolocation/GeomediaのGeです。
– 読み方を元に、空いているTwitterアカウントを
探してたらこのスペルになりました。
• 今年８月から公開ベータを開始しました！
– Androidクライアント公開中。
– iPhoneクライアントは現在開発中。


GeQuuの目指すところ
• 現在、過去、未来(!?)のその瞬間の出来事を
シームレスに表示・共有
• 位置情報を主とした様々なログの保存・解析
– 各種センサーデバイス
• GPS、地磁気、加速度…。脳波もおもしろそう。
– Tweet 、Message
– Photo、Movie
• リアルタイムコミュニケーション


デモ

「時間と空間を自由に移動できる」って
言われても意味が判らないですよねー。


事例紹介
リリースに至るまでの
サービス基盤の変遷


GeQuu開発のきっかけ
• 社員が趣味でスマートフォン・GPSを使った
イマココサービスを構築した。
– 現在の位置情報をGoogleMapsに表示するだけの
シンプルなサービス
• 「現在位置」だけではなく「移動経路」も
リアルタイムに表示できないか？
– 意外にもこのようなサービスがなかった。
– B2Bサービスとして展開できそう。


初期プロトタイプ
• シンプルなServlet/JSP + Oracle
– 社内の開発用Oracleを流用（何でもよかった）
• とりあえず作ってみて問題点を洗い出す。

Windows
Mobile 6.5 APサーバ Oracle

Viewer


初期プロトタイプの問題点
• 精細な移動経路を表示させたい！
– GPSデータを１秒単位で取得する必要がある。
– 1万ユーザ × 毎日1時間ロギング × 1年間運用
＝13,140,000,000（≒130億）レコード！
• ほぼリアルタイムに現在位置を表示したい！
– 10秒間隔でデータを送る必要がある。
• それ以上長いとリアルタイム性が損なわれる。
– 超高負荷な書き込みトラフィックが発生！！


RDB vs 超大量データ＋超高負荷更新
• RDBを用いた大規模システムのノウハウを
適用しづらい。
– Master-Slaveレプリケーションは参照負荷を
分散させるもので、要件に合わない。
– パーティショニング＋マルチマスタはシステムが
複雑化し、環境構築や運用が難しくなる。
• データの冗長化はどうする？
• サーバ台数が爆発しないか？


Cassandraの採用を検討
• 書き込みに強い分散DB：Cassandra？
– MySQLを大規模化するよりもスマートらしい。
• しかし、いくつか懸念事項があった。
– データモデルがRDBとは大きく異なる。
– SQLがサポートされていない。
– Transactionがサポートされていない。
– 技術的に枯れていない。
• 検討開始したのは、ver0.5がリリースされた頃。


データモデルがRDBとは大きく異なる
• RDBは行指向DB、Cassandraは列指向DB
– Hadoop（HBase）も列指向DBらしい。
– 後々のデータマイニングのことを考えると、
むしろ都合が良さそう。
• Hadoop MapReduce Integrationの存在も。
• INDEXがなかった（注：現在はある）
– 転置INDEXを自分で作ればよい。
– 仮にINDEXがあったとしても、書き込みでは
ボトルネック要因なので積極的には使えない。


SQLがサポートされていない
• SQLではなくThrift API
– SQLの構文解析処理がボトルネックという話題が
出てきたこともあり、逆に好意的に捉えた。
• RDBも大規模化するとJOINができなくなり、
SQLを使うメリットは弱くなる。
• パフォーマンスを考慮するとリアルタイムで
実行されるクエリは軽量化する必要がある。
– PK検索、検索結果のキャッシュ、正規化崩し


Transactionがサポートされていない
• 業務アプリ脳「ないとアプリ作れないだろ」
– でも本当にTransactionは必要なの？
– 基幹システムを作るわけではない。
• blogやSNSではTransactionはまず使わない。
• 仮に書き込みエラーが発生しても、スマート
フォンからのログ再送＋リトライができる。
– Eventual Consistencyの考え方そのもの。
• Update/Deleteを避けてInsert主体にすれば
Transactionがなくてもなんとかなる。


技術的に枯れていない
• 確かにver0.5の頃は不安定だったが…。
– 開発が活発なので、次第に安定していくはず。
– 多少の不具合よりもメリットの方が大きい。
– 研究開発プロダクトなので自由だった。
• 他社に先んじる
– 名古屋では同じような事をやっている会社は皆無。
– BigDataの時代に備えたノウハウの蓄積。


御託は抜きにしてですね

というか、最初に
「Cassandra使おうぜ！」って
言い出したのが社長だった。

※初期の開発チームは社長と私の2名体制。
※サーバサイドは主に社長が担当。


プロトタイプ#2
• Cassandra採用、クライアントはAndroid化
– ちょうどXperiaが発売された時期だった。

Android
APサーバ Cassandra

Viewer


プロトタイプ#2の評価
• Cassandraは十分使い物になる。
– ノードのAdd/Removeが簡単で運用が楽そう。
• MySQLで同じ事をするとなると…。
– 設計ノウハウの習得には苦労した。
• SQLって本当に凄いものですね！
• データストアはスケールするようになったが、
APサーバの方が負荷に耐えられない。
– 瞬間的な負荷増大でシステムが停止してしまう。


• 書き込み処理を分散MessageQueue化。
• できるだけAndroid側でログの加工を行い、
サービス側の負荷を軽減する。

分散MQ

Android 送信前に
APサーバ Cassandra
ログ加工

Viewer


分散MessageQueue
• 「瞬間的な負荷増大」対策の常套手段。
– 負荷が高くても書き込み要求は受け付ける。
• 負荷状況に応じてスケールアウト可能に。
待ち行列で過剰な
書き込み要求を
バッファリング

・
・
負荷に応じて・
サーバ追加


• システム全体の書き込み性能は改善。
– 負荷が増加しても分散MQのマシン追加で対応可。
• しかし閲覧処理のパフォーマンスに難あり。
– 書き込みに対してデータ構造を最適化したため、
参照には問題があった。
• Cassandraでは書き込み負荷を分散するために、
データを複数キーに分散させなくてはならない。
• だが、参照時には経路情報のような連続データは
単一キーに格納されている方が良い。


• 参照用データの統合・アーカイブ
• 並列検索＋HTTP Streaming

分散MQ
Android
送信前に
ログ加工 APサーバ
Cassandra

並列検索

Viewer HTTP
Streaming


参照用データの統合・アーカイブ
• 移動経路を表示するために何千もレコードを
読み込むのは非効率なので1つに統合する。
– ログ開始～終了の全レコードを1つに統合すると、
長時間ログの途中からのシークに支障がある。
– 一定時間ごとにブロック化する。
• 参照頻度の低いログは圧縮して退避・削除。
– キーの絶対数を減らしてしまう。
– ディスク使用量を大きく削減する狙いも。


並列検索＋HTTP Streaming
• 1ノードで検索処理すると時間がかかる。
• 検索処理を並列分散して、タスク毎に結果を
逐次送信する。
– レスポンス・レイテンシが大きく改善。

APサーバ


• 検索パフォーマンスも実用レベルに到達。
– アーキテクチャとしてのベースラインは完成。
• あとは公開に向けて機能追加・安定化。


現在のシステム構成
• Cassandraでは実現が難しい検索のために、
独自のIn-Memory KVSを実装。

分散MQ

Android 送信前に APサーバ
ログ加工独自KVS Cassandra

並列検索

Viewer HTTP
Streaming


まとめ


Cassandraを1年以上使ってきた雑感
• Cassandraの得意領域を見極める。
– ログのようなシーケンシャルなデータは得意。
– お金を管理するようなシステムには使わない。
• CassandraはRDBでは実現困難な問題を
解決する選択肢の一つ。
– RDBで問題がなければ、別に使う理由はない。
– Hadoopや他のKVSでも同じことが言える。


ご清聴ありがとうございました


スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例

More Related Content

スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例