Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

NoSQL勉強会資料(2015/03/12@ヒカラボ )

7 825 vues

Publié le

Redis/LevelDB/MariaDBを使ったWebアプリケーション構築事例

Publié dans : Technologie
  • Soyez le premier à commenter

NoSQL勉強会資料(2015/03/12@ヒカラボ )

  1. 1. Redis/LevelDB/MariaDBを使った Webアプリケーション構築事例 2015年3月16日@ヒカラボ 株式会社インテリジェンス 大谷 祐司 1
  2. 2. 2 ・山口県下関出身の34歳 ・インテリジェンスの新規事業チームの開発責任者。 ・趣味は車とプログラミングです。 ・最近はGo言語にはまっています。 自己紹介
  3. 3. 3 ・新規事業で人材関連のWebサービスを立ち上げ中。 ・現在は一部機能をテスト運用中。 ・2015年からプロジェクトスタート、エンジニアは4名。 ・新くて優れた技術を積極的に採用していく方針。 何をやっているのか
  4. 4. 4 現在テスト運用中の新規サービスについて Redis/LevelDB/MariaDBを使って構築しました。 検証や構築の中で分かった各データベースの特徴や 活用事例を共有したいと思います。 今日お話する内容
  5. 5. 5 ・OS :Linux(CentOS6) ・サーバサイド :hack(PHPを拡張した言語) ・バッチ :Go言語 ・DB :MariaDB(Galera Cluster) ・NoSQL :Redis(Redis Cluster) / LavelDB 採用している技術
  6. 6. 6 Redisを使った事があるかた。 はじめに質問
  7. 7. 7 LavelDBを使った事があるかた。 はじめに質問
  8. 8. 新規サービスにおける DB/NoSQLの活用事例 8
  9. 9. サービスでは、データを3タイプに分けて扱う。 9 ①更新のほとんどないマスタ系データ。 ②再作成が可能で、永続性が必須でないデータ。 ③更新頻度が高く、永続性が必須なデータ。
  10. 10. 10 想定データ サイズ(合計) 更新頻度 参照頻度 更新のほとんどないマスタ系 50MB 少ない 多い 再作成が可能で、永続性が必須でない 1G以下 中くらい 中くらい 更新頻度が高く、永続性が必須 20G以上 高い 多い サービスでは、データを3タイプに分けて扱う。
  11. 11. 11 ・合計データサイズ :少ない(50MB程度) ・更新頻度 :少ない(1ヶ月に数回程度) ・参照頻度 :多い(多くの場面で呼ばれる) ・データ増加 :少ない(制御可能) ①更新のほとんどないマスタ系データ 都道府県、大学、職種、資格など。
  12. 12. 12 ・Webサーバに置いたLevelDBで保持する。 ・MariaDBからバッチで定期的にロードする。 ①更新のほとんどないマスタ系データ シンプルで高速に値を取得したい!
  13. 13. 13 ・合計データサイズ:少ない(1G程度) ・更新頻度 :中くらい(1時間に1回程度) ・参照頻度 :中くらい(特定の場面で呼ばれる) ・データ増加 :中くらい(予測可能) ②再作成が可能で、永続性が必須でないデータ 集計したランキング、基幹システムからの連携データなど
  14. 14. 14 ・Redisで保持する。 ・クラスタリング構成にしてメモリ容量を分散する。 ・Master-Slave構成を利用してデータの消失を防ぐ。 ・MariaDB/基幹システムからバッチで定期的にロードする。 ②再作成が可能で、永続性が必須でないデータ 柔軟にデータ参照できて、冗長性も持たせたい。
  15. 15. 15 ・合計データサイズ:多い(20GB以上) ・更新頻度 :多い(常に更新が実行される) ・参照頻度 :多い(あらゆる場面で呼ばれる) ・データ増加 :多い(予測不可能) ユーザの会員情報、メッセージのやり取りなど。 ③更新頻度が高く、永続性が必須のデータ
  16. 16. 16 ・RDB(MariaDB)で保持する。 ・ユーザの会員情報、メッセージのやり取りなど。 ・クラスタリング構成にしてデータの消失を防ぐ。 ・プロキシサーバを使ってクエリを分散させる。 ③更新頻度が高く、永続性が必須のデータ 冗長性を持たせて安全にデータを保持したい。
  17. 17. 各DBの概要/活用方法について 17
  18. 18. サーバ構成(GMOクラウド) 18 Internet LB proxy Web DB BatchBackup
  19. 19. LevelDBの活用 19
  20. 20. 20 ・Googleが開発をして、2011年に公開。 ・C++で書かれたオープンソース(BSDライセンス)。 ・ChromeのIndexedDB(ローカルKVS)として利用されている。 LevelDBの概要
  21. 21. 21 ・Key-Value型の軽量なデータストア。 ・動作がとても速く、機能はとてもシンプル。 ・データはキーでソートされ「レベル」単位で階層化。 ・単一サーバ前提で、単体での冗長化は考慮されていない。 (ポートも認証も必要なく、ディレクトリの指定ですぐに使える) LevelDBの概要
  22. 22. 22 ・Put/Get/Deleteのシンプルな操作。 ・保持できるは文字列のみで、型などは持たない。 ・データはファイルシステムに圧縮して保存される。 LevelDBの概要
  23. 23. 23 ・アプリケーションへの組み込みやOSへの移植が簡単。 ・riak/FoundationDB/InfuluxDBなどがバックエンドに採用。 ・Facebookが公開したRocksDBもバックエンドはLevelDB。 LevelDBの概要
  24. 24. 24 サービスでの活用方法 バッチ Web マスタデータ バッチ Web バッチ Web InternetLB
  25. 25. 25 ・定期的にマスタデータをDBからバッチでコピーして、 各WebサーバのLevelDBに保存する。 ・Webアクセス時にはLevelDBからデータを取得。 ・DBやファイルから読み込むよりも高速に取得できる。 活用方法
  26. 26. 26 ・シンプルなKVS。 ・データを読み込むスピードがとても速い。 ・複数サーバからのアクセスや冗長化は単体では不可能。 ・RDBなどで持っているデータのキャッシュとして最適。 LevelDBまとめ
  27. 27. Redisの活用 27
  28. 28. Redisの概要 28 ・ネットワーク経由で利用可能なNoSQL。 ・単純なKVSではなく、データをセットで持てる。 ・5つの型が存在し、活用の幅が広い。 (string, list, hash, set, sorted set) ・データをメモリに保持するので、十分なメモリが必要。 ・Master-Slave構成での冗長化が可能。
  29. 29. 29 サービスでの活用方法 nginx Internet 基幹システム 集計済データ LB nginx nginx クラスタリング バッチ 連携データ
  30. 30. 30 Redis Clusterについて
  31. 31. 31 ・クラスタリングとは。 ・Redis Clusterの特徴は? ・実際に使ってみてどうだったか? Redis Clusterについて
  32. 32. 32 ・複数台の「アクティブな」サーバでDBを構成する。 ・データの冗長性や処理の負荷分散を実現できる。 ・サーバの台数を増やしてシステムの拡張を行う事ができる。 ・逆にサーバの台数を減らす事も可能。 クラスタリングとは?
  33. 33. 33 ・複数台で分散してデータを持つ(シャーディング) ・同じデータは複数台で持たない。 ・ノード毎にMaster-Slave構成が可能 (障害時はSlaveがMasterに自動で昇格) ・ノードを追加/削除した際にリシャーディンングが可能。 Redis Clusterの特徴
  34. 34. 34 Redis Clusterの構成例 Internet LB ①命令をルールで 均等に分散 ②命令を実行する ③Slaveにデータを バックアップ (1サーバに3つの Redisが起動) nginx nginx nginx
  35. 35. 35 ・ノードに0-16384の数字(slot)を割り振る。 ・リクエストのキーを計算して、対象のサーバを判別する。 [HASH_SLOT = CRC16(key) mod 16384] クラスタリングの概要 [slot 0-5460] [slot 5461-10922] [slot 10923-16383] ①サーバを選んで命令 ②対象のサーバを判別して命令を転送 node1 node2 node3③命令を実行して結果を返す
  36. 36. 36 ・耐障害性やバックアップ性が高くなる。 ・状況に応じたスケールアウトが可能。 ・冗長化にはMaster-Slave構成が必要。 ・今まで以上にRedisの活用方法が広がりそうです。 ※3/12現在RC-4で、間もなくStableになる見込みです。 http://redis.io/download Redis Clusterまとめ
  37. 37. MariaDBの活用 37
  38. 38. 38 MariaDBの概要 ・MySQLの派生で、オリジナルコードの作者が開発。 ・現在の最新版は10.0系。 ・MySQLの機能に加えていくつかの独自機能を実装。 (並列レプリケーション, ストレージエンジン, Show Explain文, etc…)
  39. 39. 39 MariaDBの概要 ・プログラムからMySQLとほとんど同じように利用できる。 ・スレッドプールを実装(MySQLは有償版のみ) ・クラスタリングの仕組みを提供している。 (Galara Cluster)
  40. 40. 40 Galera Clusterについて
  41. 41. 41 ・MariaDBを複数台でクラスタリングできる仕組み、 ・複数台構成なので、耐障害性が高い。 ・障害発生時にデータの不整合が起きにくい。 Galera Clusterの概要
  42. 42. 42 ・3台から構築でき、柔軟にスケールアウトできる。 ・アプリからMySQLベースの技術がそのまま利用できる。 ・アプリから接続先の管理が必要ない。 Galera Clusterの概要
  43. 43. 43 ・MySQL Clusterに比べて構築が簡単(社内で実績あり) ・ストレージエンジンはInnoDBとExtraDBをサポート ・auto incrementの増加が1づつではなくなる(要注意!)。 Galera Clusterの特徴
  44. 44. 44 ・全ノードが、全データを保持している(ユーザ含めて)。 ・ノードを追加したタイミングで、全データを同期する。 ・ノードの障害発生時には、クラスタから切り離される。 Galera Clusterの特徴
  45. 45. 45 Galera Clusterの構成例 Internet Web MaxScale
  46. 46. 46 MaxScaleの概要 ・データベースとアプリケーションを中継するプロキシ。 ・MariaDB/MySQLの監視、ロードバランシングが可能。 ・SQLを解析してmaster/slaveの振り分けが可能。 ・Galera Clusterを監視する仕組みが実装されている。
  47. 47. 47 ・複数台のサーバで冗長化を実現できる。 (全データを持ち合う) ・簡単に構築できて、どのサーバにもRead/Write可能。 ・オンラインでサーバの追加/削減が簡単に行える。 ・監視にはMaxScaleが便利。 MariaDB(Galera Cluster)まとめ
  48. 48. まとめ 48
  49. 49. ・DB/NoSQLを適材適所で使い分ける事が重要。 ・データの性質から考えると、どれが最適か判断しやすい。 ・DBをクラスタリングすることで柔軟な運用が可能になる。 ・新規開発こそ、新しい技術に挑戦するチャンス。 49 まとめ
  50. 50. さいごに 50
  51. 51. 新規事業部門では、エンジニアを募集しています。 興味がある方は、気軽にお声がけください。 51
  52. 52. ご清聴ありがとうございました。 52

×