Cassandra(no sql)によるシステム提案と開発
Upcoming SlideShare
Loading in...5
×
 

Cassandra(no sql)によるシステム提案と開発

on

  • 1,125 views

コネクト株式会社主催の ...

コネクト株式会社主催の
「SIerのためのCassandra実用セミナー NoSQLリアルビジネス」(4月10日)
での内容です。
(公開に際して一部削除しています。ご了承ください。)

NoSQLをビジネスにするためのヒントになれば嬉しいです。

Statistics

Views

Total Views
1,125
Views on SlideShare
1,125
Embed Views
0

Actions

Likes
1
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cassandra(no sql)によるシステム提案と開発 Cassandra(no sql)によるシステム提案と開発 Presentation Transcript

  • Cassandra(NoSQL) による システム提案と開発 株式会社エスキュービズム 岸本 康二
  • 前提事項などのご説明
  •   NoSQL のよくある誤解・正解 ■ 正解 ○ 負荷分散に優れている ○ 耐障害性が高い △ データ一貫性は弱い
  •   NoSQL のよくある誤解・正解 ■ 誤解 × データ一貫性がない CAP 定理自体は正しい。 ただし、間違った解釈が異常に多い。 × トランザクション機能がない もう昔の話 × 業務系フロントシステムには向かない RDBMS を主役に据えた Not Only SQL … → なんて言ってるのはもう古い!
  •   NoSQL と RDBMS との本当の関係RDBMS での高速化(負荷分散) 1)レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず
  •   NoSQL と RDBMS との本当の関係RDBMS での高速化(負荷分散) 1)レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず 2)テーブル単位で複数サーバに分割   2 )テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ
  •   NoSQL と RDBMS との本当の関係RDBMS での高速化(負荷分散) 1)レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず 2)テーブル単位で複数サーバに分割   2 )テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ 3)インデックスを張る → 発想は NoSQL 系と同じ
  •   NoSQL と RDBMS との本当の関係RDBMS での高速化(負荷分散) 1)レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず 2)テーブル単位で複数サーバに分割   2 )テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ 3)インデックスを張る → 発想は NoSQL 系と同じ 番外) SQL の解析を飛ばして直接ストレージ API の操作 → もはや SQL では…
  •   NoSQL と RDBMS との本当の関係 RDBMS でも NoSQL でも設計を深く突き詰めると同じ そもそも CPU の処理量は DB に関係なく一定 ↓ CPU 処理量の配分の最適化が大切 ↓ NoSQL :フロント (オンライン) RDBMS :バックヤード (オフライン) ログ解析など(← SQL が活きる!) ↑ 「 Not Only SQL 」風の構成とは真逆が正解
  •   NoSQL と RDBMS との本当の関係 WEB APP ● 従来型 →DB に負荷集中 WEB APP RDBMS WEB APP RDBMS WEB APP WEB APP
  •   NoSQL と RDBMS との本当の関係 WEB APP NoSQL NoSQL WEB APP RDBMS WEB APP RDBMS WEB APP ● 負荷を軽減しようと・・・ →NoSQL でキャッシュ WEB APP →DB の書き込み負荷は減らない   これが今の「 Not Only SQL 」の構成
  •   NoSQL と RDBMS との本当の関係 ここを売るのは先が細い WEB APP NoSQL NoSQL WEB APP RDBMS WEB APP RDBMS WEB APP ● 負荷を軽減しようと・・・ →NoSQL でキャッシュ WEB APP →DB の書き込み負荷は減らない   現在の「 Not Only SQL 」の構成
  •   NoSQL と RDBMS との本当の関係 WEB APP NoSQL NoSQL WEB APP RDBMS WEB APP RDBMS WEB APP ● ボトルネック部分を削ってみる WEB APP
  •   NoSQL と RDBMS との本当の関係 WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL
  •   NoSQL と RDBMS との本当の関係 WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL
  •   NoSQL と RDBMS との本当の関係 WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL ● 自然と NoSQL クラスタに行き着く
  •   NoSQL と RDBMS との本当の関係WEB APP NoSQL RDBMSWEB APP NoSQLWEB APP NoSQLWEB APP NoSQLWEB APP NoSQL ● 最適なシステム構成 →NoSQL はフロント   → RDBMS はバックヤード
  •   NoSQL と RDBMS との本当の関係 ■NoSQL ・書き込み負荷も容易に分散(スケールアウト) ・障害・アクシデントに強い ・データ分散自体がバックアップも兼ねるので効率的・経済的 → フロントシステム向き ■RDBMS ・ SQL が便利。思いつきの解析もすぐに実行できる ・検索、ソートが効率的 → バックヤードでの分析・統計向き → 処理を定型に落として Hadoop を提案、が定石
  • では、数ある NoSQL の中で 何を選ぶべきなのか?
  • ■ Apache Cassandra を選ぶ理由 Cassandra MongoDB Redis ボトルネックな ボトルネッ ボトルネッ し! ク ク 独立協調型 管理型 マスタ - スレーブ型
  • ■ Apache Cassandra を選ぶ理由 「人」の単一障害点 → 開発コミュニティの層が厚いことが重要 Cassandra は Apache ソフトウェア財団の 「トップレベルプロジェクト」
  • 実案件での例
  • ■  実案件での NoSQL (公開に際して削除しました)
  • NoSQL はお金になるのか?
  • ■   NoSQL で動くお金 (公開に際して削除しました)
  • ■   NoSQL で動くお金 ■ 金額の差の理由 ・ NoSQL を意識する案件は比較的規模が大きめ ・システム全体を受けていること (↔ 「 Not Only SQL 」では一部のみ) ・ NoSQL はそもそもノードを増やす発想 RDBMS はせいぜいマスタ - スレーブの 2 台構成+ WEB 数台
  • お金になるのは判った。でも案件見込数は?
  • ■   NoSQL でのターゲット ・「 Not Only SQL 」型提案では、  既存に+ α するという型にはまってしまっていた。 → 提案先も限られ、受託規模も小さい。 ・従来 RDBMS で提案していた(大きめ)案件が  実は全て NoSQL でも提案ターゲットにできる。 → なぜなら「トランザクション」が可能だから ・ RDBMS では難しいさらに大きな規模もターゲットにできる ・結果、実は大きな市場が眠っている! → しかも、そのほとんどが手付かずの状態。
  • NoSQL で提案するメリット
  •   NoSQL 提案のメリット ・目立つ。 ・決裁者は結局システムは動けば OK →  スケーラビリティ、耐障害性の優位をアピール →  実績もちゃんとある ・クラウドを利用するべき「合理的な理由がある」 →  担当者に納得感が生まれる →  選考が進む ・クラウド利用率が上がる →  インフラとセットにした商品開発にもなる
  • コンペでの提案ポイント
  • ■  コンペでの提案ポイント (公開に際して削除しました)
  • 想定問答
  • ■  想定問答 ~コンペ編~ ・「 RDBMS? NoSQL ??」な顔 → スーパーマンの例え話 ・実績あるの? → 【ご説明済み】 ・有償サポートはある?運用一式任せられる? → 問題なし。本日のセミナーの内容通りです。 ・クライアントにも説明したい。 → ご協力致します。
  • ■  想定問答 ~職場編~ ・社長 : 「 NoSQL って何 ? 」 → 「あ、さすがですね ! これから伸びるクラウド時代の技術です」 ・事業部長:「儲かるの?」 → 【すでに説明済み】 ・エンジニア:「よく分からん」 → 「ちょうど良かった」と新人に振る。 → 変に SQL にこだわりが無い人の方が伸びる → 実は 40 代以降の方には意外と抵抗感がない → エンジニア向けのレクチャーメニューもございます
  • NoSQL での設計パターン ~ M2M 編 ~
  • (公開に際して削除しました)
  • コンパクトなネットワーク構成も可能
  • 機能に応じてクラスタを分離可能 → ハードウェアレベルでチューニング可能 → マルチデータセンターも可能
  •  開発ツール: パフォーマンスの可視化、チューニング Compuware 社 「 dynaTrace」 との連携による分散環境の性能分析・可 視化
  •  開発ツール: パフォーマンスの可視化、チューニング Compuware 社 「 dynaTrace」 との連携による分散環境の性能分析・可 視化
  •  開発ツール: パフォーマンスの可視化、チューニング Compuware 社 「 dynaTrace」 との連携による分散環境の性能分析・可 視化
  • ■   NanaHoshi の今後 クラウドコンポーネントではじめるビジネス拡張 「 BlueRabbit 」 クラウドコンポーネントではじめるビジネス拡張 「 BlueRabbit 」 RS MS RC NH RF 監視と電話 高速・安定な EC サイト 業務向け サイト横断 の融合 M2M 基盤 POS &倉庫連携 NoSQL O2O 分析 WC MM DT RR RT 完全従量制 完全従量制 パフォーマンス 訪問時間枠 リアルタイム CDN Map 情報 チューニング 予約サービス 貨物追跡
  • ■   NanaHoshi の今後 ■PaaS として組み合わせて土台にする ■SaaS としてパッケージを利用する
  • 全て Ready  → 案件の提案に使って頂けます 営業 ・パッケージ(簡単・安定・規模) → 「 NanaHoshi 」 →   SIer 様向けメニューあり ・実績 ・差別化 ・金額 ・利益率 開発 ・パッケージ ・現場を経験したツール群 ・デバッグ、チューニング用ツール ・カスタマイズ / 連携を容易にする API 群 ・納品用マニュアル類 運用 ・有償サポート ・監視(クラウド環境向けノウハウあり)
  • ■   NoSQL が熱い領域 ・ M2M 領域(広い意味で) → センサーデータ → 家電データも相当 → 業界大手はまだ Hadoop による可視化を売っているのみ → まだまだ巨大なニーズが残っている ・ PaaS 領域 → パッケージの機能一式をクラウドで提供 ・既存領域でもシステムリニューアルは熱い → 決裁者は DB で選ばない → より良いシステムをより合理的なコストで
  • ■ データベースの変遷1970 年頃 RDB の誕生 20 年 RDB 黎明期1990 年頃 SQL の標準化 20 年 RDB 黄金期2010 年頃 NoSQL の誕生 ← RDB の処理限界 ・ネット人口の増加 ・デバイスの増加 ・ WEB サービスの増加 NoSQL 黎明期 NoSQL はこれから大きく成長する領域です !