狠狠撸

狠狠撸Share a Scribd company logo

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

?Download as PPT, PDF?
?
K
kishimotosc

コネクト株式会社主催の 「SIerのためのCassandra実用セミナー　NoSQLリアルビジネス」（4月10日） での内容です。 （公開に際して一部削除しています。ご了承ください。） NoSQLをビジネスにするためのヒントになれば嬉しいです。 最近はCassandraをマイクロサービス/サービスメッシュ基盤へ応用しています。 https://b-rabbit.jp/

1 of 47
Downloaded 25 times
Cassandra(NoSQL) による システム提案と開発 株式会社エスキュービズム 岸本 康二
前提事项などのご説明
　 NoSQL のよくある誤解?正解 ■ 正解 ○ 負荷分散に優れている ○ 耐障害性が高い △ データ一貫性は弱い
　 NoSQL のよくある誤解?正解 ■ 誤解 × データ一貫性がない CAP 定理自体は正しい。 ただし、間違った解釈が異常に多い。 × トランザクション機能がない もう昔の話 × 業務系フロントシステムには向かない RDBMS を主役に据えた Not Only SQL … → なんて言ってるのはもう古い！
　 NoSQL と RDBMS との本当の関係 RDBMS での高速化（負荷分散） １）レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず
　 NoSQL と RDBMS との本当の関係 RDBMS での高速化（負荷分散） １）レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず ２）テーブル単位で複数サーバに分割 　　２ ' ）テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ
　 NoSQL と RDBMS との本当の関係 RDBMS での高速化（負荷分散） １）レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず ２）テーブル単位で複数サーバに分割 　　２ ' ）テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ ３）インデックスを張る → 発想は NoSQL 系と同じ
　 NoSQL と RDBMS との本当の関係 RDBMS での高速化（負荷分散） １）レプリケーションで読み込み負荷分散 → 書き込み負荷は分散できず ２）テーブル単位で複数サーバに分割 　　２ ' ）テーブルを複数サーバに分割 → 発想は NoSQL 系と同じ ３）インデックスを張る → 発想は 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 RDBMS WEB APP NoSQL WEB APP NoSQL WEB APP NoSQL WEB 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 はこれから大きく成長する領域です !

More Related Content

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

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