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

6,201 views

Published on

Cassandra Conference Tokyo 2011での発表資料

Published in: Technology
  • Be the first to comment

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

  1. 1. スマートフォン×Cassandraによるハイパフォーマンスサービス基盤の 構築事例 株式会社コスモルート クラウドR&D グループ terurou Cassandra Conference in Tokyo(2011/10/05) 1 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  2. 2. 今から話すこと• 自己紹介+会社紹介• 事例紹介– GeQuuとは– リリースに至るまでのサービス基盤の変遷 • どのように技術的な難題を解決してきたか?• まとめ 2 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  3. 3. 自己紹介+会社紹介 3 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  4. 4. terurou(YAGI.Teruo)• Twitter: @terurou• Blog: DenkiYagi(はてなDiary) – http://d.hatena.ne.jp/terurou/ 4 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  5. 5. 株式会社コスモルート• 名古屋本社、東京支社– 1989年設立、社員 約60名• 業務系のソフトハウス– ソフトウェア開発 • 製造業、生産管理、ERP向けが中心 • アーキテクトやインフラも守備範囲– ソフト以外にも機械設計、電子設計– 研究開発 • Cassandraは2010年3月頃から使っています。 5 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  6. 6. 「terurouは何エンジニア?」『RIAかなぁ』• 「クライアントからいかにして大量データを 操作するか?」を考えることが多い – UX、ストレスフリーなUI設計 – データ構造、プロトコルレベルの設計 – Caching機構の設計(Frontend、Backend) – etc...• Silverlight, JavaScript, Android, ... – Microsoft Tech Fielders Member• PHP逆引きレシピ共著 6 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  7. 7. 主催コミュニティ• DSTokai – 東海地方のメタコミュニティ • コミュニティ間の連絡窓口・イベント告知 • クロスコミュニティイベントの企画 – NGK:名古屋 合同 懇親会(花見、忘年会...)• 大規模分散技術勉強会 in 名古屋 – 通称:大名古屋 – Hadoop本読書会(全10回、完) – 「Hadoop MapReduce デザインパターン」とか 「オンラインゲームを支える技術」も読みたい 7 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  8. 8. 事例紹介 GeQuuとは8 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  9. 9. GeQuu -時空を超えろ-時間と空間を自由に移動できるソーシャルなロギングサービス基盤 GeQuuクラウド ログの送信 ログの蓄積・解析 • GPS • Message データの閲覧 • Photo •… 連携 9 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  10. 10. GeQuu -時空を超えろ-• http://gequu.net/• GeQuuの読み方は「じくー」です。– よく「げくー」と間違えられますが…。– Geolocation/GeomediaのGeです。– 読み方を元に、空いているTwitterアカウントを 探してたらこのスペルになりました。• 今年8月から公開ベータを開始しました!– Androidクライアント公開中。– iPhoneクライアントは現在開発中。 10 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  11. 11. GeQuuの目指すところ• 現在、過去、未来(!?)のその瞬間の出来事を シームレスに表示・共有• 位置情報を主とした様々なログの保存・解析– 各種センサーデバイス • GPS、地磁気、加速度…。脳波もおもしろそう。– Tweet 、Message– Photo、Movie• リアルタイムコミュニケーション 11 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  12. 12. デモ 「時間と空間を自由に移動できる」って 言われても意味が判らないですよねー。 12 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  13. 13. 事例紹介リリースに至るまでのサービス基盤の変遷 13 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  14. 14. GeQuu開発のきっかけ• 社員が趣味でスマートフォン・GPSを使った イマココサービスを構築した。– 現在の位置情報をGoogleMapsに表示するだけの シンプルなサービス• 「現在位置」だけではなく「移動経路」も リアルタイムに表示できないか?– 意外にもこのようなサービスがなかった。– B2Bサービスとして展開できそう。 14 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  15. 15. 初期プロトタイプ• シンプルなServlet/JSP + Oracle – 社内の開発用Oracleを流用(何でもよかった)• とりあえず作ってみて問題点を洗い出す。 Windows Mobile 6.5 APサーバ Oracle Viewer 15 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  16. 16. 初期プロトタイプの問題点• 精細な移動経路を表示させたい!– GPSデータを1秒単位で取得する必要がある。– 1万ユーザ × 毎日1時間ロギング × 1年間運用 =13,140,000,000(≒130億)レコード!• ほぼリアルタイムに現在位置を表示したい!– 10秒間隔でデータを送る必要がある。 • それ以上長いとリアルタイム性が損なわれる。– 超高負荷な書き込みトラフィックが発生!! 16 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  17. 17. RDB vs 超大量データ+超高負荷更新• RDBを用いた大規模システムのノウハウを 適用しづらい。– Master-Slaveレプリケーションは参照負荷を 分散させるもので、要件に合わない。– パーティショニング+マルチマスタはシステムが 複雑化し、環境構築や運用が難しくなる。 • データの冗長化はどうする? • サーバ台数が爆発しないか? 17 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  18. 18. Cassandraの採用を検討• 書き込みに強い分散DB:Cassandra?– MySQLを大規模化するよりもスマートらしい。• しかし、いくつか懸念事項があった。– データモデルがRDBとは大きく異なる。– SQLがサポートされていない。– Transactionがサポートされていない。– 技術的に枯れていない。 • 検討開始したのは、ver0.5がリリースされた頃。 18 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  19. 19. データモデルがRDBとは大きく異なる• RDBは行指向DB、Cassandraは列指向DB– Hadoop(HBase)も列指向DBらしい。– 後々のデータマイニングのことを考えると、 むしろ都合が良さそう。 • Hadoop MapReduce Integrationの存在も。• INDEXがなかった(注:現在はある)– 転置INDEXを自分で作ればよい。– 仮にINDEXがあったとしても、書き込みでは ボトルネック要因なので積極的には使えない。 19 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  20. 20. SQLがサポートされていない• SQLではなくThrift API – SQLの構文解析処理がボトルネックという話題が 出てきたこともあり、逆に好意的に捉えた。• RDBも大規模化するとJOINができなくなり、 SQLを使うメリットは弱くなる。• パフォーマンスを考慮するとリアルタイムで 実行されるクエリは軽量化する必要がある。 – PK検索、検索結果のキャッシュ、正規化崩し 20 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  21. 21. Transactionがサポートされていない• 業務アプリ脳「ないとアプリ作れないだろ」 – でも本当にTransactionは必要なの? – 基幹システムを作るわけではない。 • blogやSNSではTransactionはまず使わない。• 仮に書き込みエラーが発生しても、スマート フォンからのログ再送+リトライができる。 – Eventual Consistencyの考え方そのもの。• Update/Deleteを避けてInsert主体にすれば Transactionがなくてもなんとかなる。 21 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  22. 22. 技術的に枯れていない• 確かにver0.5の頃は不安定だったが…。– 開発が活発なので、次第に安定していくはず。– 多少の不具合よりもメリットの方が大きい。– 研究開発プロダクトなので自由だった。• 他社に先んじる– 名古屋では同じような事をやっている会社は皆無。– BigDataの時代に備えたノウハウの蓄積。 22 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  23. 23. 御託は抜きにしてですねというか、最初に「Cassandra使おうぜ!」って言い出したのが社長だった。※初期の開発チームは社長と私の2名体制。※サーバサイドは主に社長が担当。 23 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  24. 24. プロトタイプ#2• Cassandra採用、クライアントはAndroid化– ちょうどXperiaが発売された時期だった。 Android APサーバ Cassandra Viewer 24 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  25. 25. プロトタイプ#2の評価• Cassandraは十分使い物になる。– ノードのAdd/Removeが簡単で運用が楽そう。 • MySQLで同じ事をするとなると…。– 設計ノウハウの習得には苦労した。 • SQLって本当に凄いものですね!• データストアはスケールするようになったが、 APサーバの方が負荷に耐えられない。– 瞬間的な負荷増大でシステムが停止してしまう。 25 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  26. 26. プロトタイプ#3• 書き込み処理を分散MessageQueue化。• できるだけAndroid側でログの加工を行い、 サービス側の負荷を軽減する。 分散MQ Android 送信前に APサーバ Cassandra ログ加工 Viewer 26 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  27. 27. 分散MessageQueue• 「瞬間的な負荷増大」対策の常套手段。 – 負荷が高くても書き込み要求は受け付ける。• 負荷状況に応じてスケールアウト可能に。 待ち行列で過剰な 書き込み要求を バッファリング ・ ・ 負荷に応じて ・ サーバ追加 27 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  28. 28. プロトタイプ#3の評価• システム全体の書き込み性能は改善。– 負荷が増加しても分散MQのマシン追加で対応可。• しかし閲覧処理のパフォーマンスに難あり。– 書き込みに対してデータ構造を最適化したため、 参照には問題があった。 • Cassandraでは書き込み負荷を分散するために、 データを複数キーに分散させなくてはならない。 • だが、参照時には経路情報のような連続データは 単一キーに格納されている方が良い。 28 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  29. 29. プロトタイプ#4• 参照用データの統合・アーカイブ• 並列検索+HTTP Streaming 分散MQ Android 送信前に ログ加工 APサーバ Cassandra 並列検索 Viewer HTTP Streaming 29 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  30. 30. 参照用データの統合・アーカイブ• 移動経路を表示するために何千もレコードを 読み込むのは非効率なので1つに統合する。– ログ開始~終了の全レコードを1つに統合すると、 長時間ログの途中からのシークに支障がある。– 一定時間ごとにブロック化する。• 参照頻度の低いログは圧縮して退避・削除。– キーの絶対数を減らしてしまう。– ディスク使用量を大きく削減する狙いも。 30 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  31. 31. 並列検索+HTTP Streaming• 1ノードで検索処理すると時間がかかる。• 検索処理を並列分散して、タスク毎に結果を 逐次送信する。– レスポンス・レイテンシが大きく改善。 APサーバ 31 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  32. 32. プロトタイプ#4の評価• 検索パフォーマンスも実用レベルに到達。– アーキテクチャとしてのベースラインは完成。• あとは公開に向けて機能追加・安定化。 32 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  33. 33. 現在のシステム構成• Cassandraでは実現が難しい検索のために、 独自のIn-Memory KVSを実装。 分散MQAndroid 送信前に APサーバ ログ加工 独自KVS Cassandra 並列検索Viewer HTTP Streaming 33 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  34. 34. まとめ34 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  35. 35. Cassandraを1年以上使ってきた雑感• Cassandraの得意領域を見極める。– ログのようなシーケンシャルなデータは得意。– お金を管理するようなシステムには使わない。• CassandraはRDBでは実現困難な問題を 解決する選択肢の一つ。– RDBで問題がなければ、別に使う理由はない。– Hadoopや他のKVSでも同じことが言える。 35 All Rights Reserved,Copyright © 株式会社コスモルート 2011
  36. 36. ご清聴ありがとうございました 36 All Rights Reserved,Copyright © 株式会社コスモルート 2011

×