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

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

構築事例

株式会社コスモルートクラウドR&D グループ

terurou

Cassandra Conference in Tokyo（2011/10/05）

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

今から話すこと

• 自己紹介＋会社紹介

• 事例紹介

– 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 －時空を超えろ－

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


ログの送信 • GPS • Message • Photo • …

データの閲覧

連携

ログの蓄積・解析

GeQuuクラウド

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を流用（何でもよかった）

• とりあえず作ってみて問題点を洗い出す。


APサーバ Windows Mobile 6.5

Viewer

Oracle

初期プロトタイプの問題点

• 精細な移動経路を表示させたい！

– 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が発売された時期だった。


APサーバ Android

Viewer

Cassandra

プロトタイプ#2の評価

• Cassandraは十分使い物になる。

– ノードのAdd/Removeが簡単で運用が楽そう。

• MySQLで同じ事をするとなると…。

– 設計ノウハウの習得には苦労した。

• SQLって本当に凄いものですね！

• データストアはスケールするようになったが、APサーバの方が負荷に耐えられない。

– 瞬間的な負荷増大でシステムが停止してしまう。



• 書き込み処理を分散MessageQueue化。

• できるだけAndroid側でログの加工を行い、サービス側の負荷を軽減する。


分散MQ

APサーバ Android

Viewer

Cassandra 送信前にログ加工

分散MessageQueue

• 「瞬間的な負荷増大」対策の常套手段。

– 負荷が高くても書き込み要求は受け付ける。

• 負荷状況に応じてスケールアウト可能に。


・・・

待ち行列で過剰な書き込み要求をバッファリング

負荷に応じてサーバ追加


• システム全体の書き込み性能は改善。

– 負荷が増加しても分散MQのマシン追加で対応可。

• しかし閲覧処理のパフォーマンスに難あり。

– 書き込みに対してデータ構造を最適化したため、参照には問題があった。

• Cassandraでは書き込み負荷を分散するために、データを複数キーに分散させなくてはならない。

• だが、参照時には経路情報のような連続データは単一キーに格納されている方が良い。



• 参照用データの統合・アーカイブ

• 並列検索＋HTTP Streaming


分散MQ

APサーバ

Android

Viewer

送信前にログ加工

並列検索

HTTP Streaming

Cassandra

参照用データの統合・アーカイブ

• 移動経路を表示するために何千もレコードを読み込むのは非効率なので1つに統合する。

– ログ開始～終了の全レコードを1つに統合すると、長時間ログの途中からのシークに支障がある。

– 一定時間ごとにブロック化する。

• 参照頻度の低いログは圧縮して退避・削除。

– キーの絶対数を減らしてしまう。

– ディスク使用量を大きく削減する狙いも。


並列検索＋HTTP Streaming

• 1ノードで検索処理すると時間がかかる。

• 検索処理を並列分散して、タスク毎に結果を逐次送信する。

– レスポンス・レイテンシが大きく改善。


APサーバ


• 検索パフォーマンスも実用レベルに到達。

– アーキテクチャとしてのベースラインは完成。

• あとは公開に向けて機能追加・安定化。


現在のシステム構成

• Cassandraでは実現が難しい検索のために、独自のIn-Memory KVSを実装。


分散MQ

APサーバ Cassandra

Android

Viewer

送信前にログ加工

並列検索

HTTP Streaming

独自KVS

まとめ


Cassandraを1年以上使ってきた雑感

• Cassandraの得意領域を見極める。

– ログのようなシーケンシャルなデータは得意。

– お金を管理するようなシステムには使わない。

• CassandraはRDBでは実現困難な問題を解決する選択肢の一つ。

– RDBで問題がなければ、別に使う理由はない。

– Hadoopや他のKVSでも同じことが言える。


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


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

Technology