Couchbase 101 ja
•Download as PPTX, PDF•
1 like•1,082 views
2015年8月31日に開催された、Couchbase Live TokyoでCouchbase Serverの入門編として、アーキテクチャなどを説明した際の資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Couchbase 101 ja
Similar to Couchbase 101 ja (20)
Recently uploaded
Recently uploaded (8)
Couchbase 101 ja
- 1. Couchbase 101 河村康爾 – Solutions Engineer
- 2. コアテクノロジ 製品概要
- 3. Memcachedからの進化 ©2015 Couchbase, Inc. 3 • 創業者はmemcachedのキーコントリビュータ • 分散”永続”Key-Valueストア、Membaseへと進化 • Couchbaseドキュメントストアへと進化、 JSONサポートとMap-Reduceインデックス、 Elasticsearch連携、クロスデータセンタレプリケーションに対応
- 4. Couchbase Server 4 様々な用途 伸縮自在の スケーラビリティ 一貫した高性能 常に利用可能 柔軟、グローバルな デプロイメント エンタープライズレベルの 管理機能 リアルタイム ビッグデータ モバイル データ もっとも完成された、スケーラブル & 高性能 NoSQLデータベース 開発者に フォーカス ©2015 Couchbase, Inc.
- 5. Couchbase Server Couchbaseは全範囲の データ管理ソリューションを提供 高可用性 キャッシュ Key Value ドキュメント モバイル デバイス SSN: 400 658 9993 Pass: ****** 5©2015 Couchbase, Inc.
- 6. 主な特徴 6 • 開発者にフォーカス JSONをサポート インデックス/クエリ インクリメンタル Map-Reduce • 伸縮自在のスケーラビリティ シングルノードタイプによる、 シェアードナッシングアーキ テクチャ クロスデータセンタ レプリケーション (XDCR) ボタンを押すだけでスケール アウト • 一貫した高性能 オブジェクトレベル キャッシュを統合 細粒度のロック ハッシュパーティション • 常に利用可能 ダウンタイムなしの運用管理と アップグレード ストリーミング、ラック認識の レプリケーション 包括的なクラスタ全体の モニタリング ©2015 Couchbase, Inc.
- 7. キーコンセプト
- 8. Key Value 8 • CouchbaseはKey-Valueドキュメントストアとして動作 • KeyはUTF-8の文字列、 250 Bytesまで • Valueは: - シンプルなデータ型: strings, numbers, datetime, boolean, バイナリデータを保存可能 -- Base64エンコード文字列として保存 - 複雑なデータ型: ディクショナリ/連想配列、配列/リスト、JSONフォーマットで保存 (単純なリストは文字列と区切り文字でも表現可能) - JSONは特別なstring型、シンプルあるいは複雑なデータ構造をエンコードする特定の フォーマット • スキーマは不要で暗黙的、スキーマの変更はプログラマティックにオンラインで、ドキュメ ント毎に異なるスキーマを持つことができる ©2015 Couchbase, Inc.
- 9. Couchbase は KVS にも ドキュメントストア にも Key-Valueストア ドキュメントストア 2014-06-23-10:15am : 75F 2014-06-23-11:30am : 77F 2014-06-23-02:00pm : 82F 0001: {firstname: “Dipti”, lastname: “Borkar”, language: “English”, time_zone: “PST”, zip: 94403 } Key – UTF-8文字列、250 bytes まで Value - 0 bytes ~ 20 MB (ベストプラクティス < 1 MB) 9©2015 Couchbase, Inc.
- 10. 複雑なオブジェクト、データ構造を表現可能 非常に単純な符号化、軽量、コンパクト、可読性 最も一般的なシステム連携APIの結果データ型 Facebook, Twitter, をはじめ、多くのAPIはJSONを返す Javascriptネイティブ (利用しやすい) Couchbaseにそのまま格納できる (より迅速な開発) シリアライズ、デシリアライズが非常に速い JSONの利点 10©2015 Couchbase, Inc.
- 11. ドキュメントの保存と取得 11 Couchbaseクラスタ サーバノード ユーザ/アプリケーションデータ サーバ上に存在 データバケット ドキュメント 参照 / 更新 クラスタに所属 クライアント サーバ 動的にスケール可能 ハッシュパーティション ©2015 Couchbase, Inc.
- 12. ユーザオブジェクト string uid string firstname string lastname int age array favorite_colors string email u::john@couchbase.com { “uid”: 123456, “firstname”: “John”, “lastname”: “Smith”, “age”: 22, “favorite_colors”: [“blue”, “black”], “email”: “john@couchbase.com” } ユーザオブジェクト string uid string firstname string lastname int age array favorite_colors string email u::john@couchbase.com { “uid”: 123456, “firstname”: “John”, “lastname”: “Smith”, “age”: 22, “favorite_colors”: [“blue”, “black”], “email”: “john@couchbase.com” } add() get() オブジェクト、JSON間のシリアライズ/デシリアライズ 12©2015 Couchbase, Inc.
- 14. 個々のサーバは – シングルノードタイプ 14 Heartbeat Processmonitor Globalsingletonsupervisor Configurationmanager on each node Rebalanceorchestrator Nodehealthmonitor one per clusa vBucketstateandreplicationmanager http RESTmanagementAPI/WebUI HTTP 8091 Erlang port mapper 4369 Distributed Erlang 21100 - 21199 Erlang/OTP storage interface Couchbase EP Engine 11210 Memcapable 2.0 Moxi 11211 Memcapable 1.0 Memcached Persistence Layer 8092 クエリAPI QueryEngine データマネージャ クラスタマネージャ ©2015 Couchbase, Inc.
- 15. 単一ノードのオペレーション – 更新 15 33 2 マネージドキャッシュ ディスクキュー ディスク レプリケー ションキュー App サーバ 他ノードへのレプリケー ションは、メモリ to メ モリ Doc DocDoc ©2015 Couchbase, Inc.
- 16. Managed Cache ディスク 単一ノードのオペレーション – 参照 16 マネージドキャッシュ Doc 1 Get Doc 1 Doc 1Doc 1 App サーバ ディスクキュー レプリケー ションキュー 他ノードへのレプリケー ションは、メモリ to メ モリ ©2015 Couchbase, Inc.
- 17. ディスク マネージドキャッシュ 単一ノードのオペレーション – キャッシュの除去 17 Doc 1 Doc 1 Doc 2Doc 3Doc 4Doc 5Doc 6 Doc 2Doc 3Doc 4Doc 5Doc 6 App サーバ ディスクキュー レプリケー ションキュー 他ノードへのレプリケー ションは、メモリ to メ モリ ©2015 Couchbase, Inc.
- 18. 単一ノードのオペレーション – キャッシュミス 18 33 2 ディスクキュー ディスク レプリケー ションキュー App サーバ 他ノードへのレプリケー ションは、メモリ to メ モリ Doc 1 Doc 2Doc 3Doc 4Doc 5Doc 6 Doc 2Doc 3Doc 4Doc 5Doc 6 Doc 1 Doc 1Doc 1 マネージドキャッシュ Get Doc 1 ©2015 Couchbase, Inc.
- 19. クラスタのオペレーション
- 20. 各バケットはアクティブとレプリカのデータセットを保持 各データセットは 1024 の仮想バケット (vBucket)を持つ ドキュメントは論理的にvBucketにマッピングされる 同一のドキュメントIDは常に同じ仮想バケットにハッシュされる 仮想バケットの物理的なサーバのロケーションは固定されていない 仮想バケットと、物理サーバのマッピングを クラスタマップ と呼ぶ 各仮想バケットは、全データセットの 1/1024 の部分的データを保 持 自動シャーディング – バケットとvBucket vB データバケット vB 1 ….. 1024 仮想バケット 20©2015 Couchbase, Inc.
- 21. クラスタマップ ハッシュ関数 (キー) vB1 vB2 vB3 vB4 vB5 vB6 物理 サーバ A B C さらにスケールが必要な 場合、ノードを追加 論理パー ティション クラスタマップ 新しいクラスタマップ 21©2015 Couchbase, Inc.
- 22. 参照/挿入/更新 アクティブ サーバ 1 アクティブ サーバ 2 アクティブ サーバ 3 APP サーバ 1 COUCHBASE クライアントライブラリ クラスタマップ COUCHBASE クライアントライブラリ クラスタマップ APP サーバ 2 Shard 5 Shard 2 Shard 9 Shard Shard Shard Shard 4 Shard 7 Shard 8 Shard Shard Shard Shard 1 Shard 3 Shard 6 Shard Shard Shard レプリカ レプリカ レプリカ Shard 4 Shard 1 Shard 8 Shard Shard Shard Shard 6 Shard 3 Shard 2 Shard Shard Shard Shard 7 Shard 9 Shard 5 Shard Shard Shard 複数ノードのオペレーション • ドキュメントは均等に各サーバへ分散 • 各サーバはアクティブ、レプリカの 両ドキュメントを保持 - アクティブなドキュメントを保持するサーバ は1台のみ • クライアントライブラリはデータベース へのシンプルなインタフェースをアプリ に提供 • クラスタマップがドキュメントとサーバ とのマッピングを提供 - アプリは知る必要がない • アプリからドキュメントを参照、挿入、 更新 • 複数のAppサーバから同一の ドキュメントを同時にアクセスできる 22©2015 Couchbase, Inc.
- 23. サーバ 4 サーバ 5 レプリカ アクティブ レプリカ アクティブ 参照/挿入/更新 APP サーバ 1 COUCHBASE クライアントライブラリ クラスタマップ COUCHBASE クライアントライブラリ クラスタマップ APP サーバ 2 アクティブ サーバ 1 Shard 9 Shard レプリカ Shard 4 Shard 1 Shard 8 Shard Shard Shard アクティブ サーバ 2 Shard 8 Shard レプリカ Shard 6 Shard 3 Shard 2 Shard Shard Shard アクティブ サーバ 3 Shard 6 Shard レプリカ Shard 7 Shard 9 Shard 5 Shard Shard Shard 参照/挿入/更新 Shard 5 Shard 2 Shard Shard Shard 4 Shard 7 Shard Shard Shard 1 Shard 3 Shard Shard ノードの追加 • 複数のサーバを1クリックの操作で 追加可能 • ドキュメントは自動的にクラスタ 全体で再配置される - 均等にドキュメントを分散 - ドキュメントの移動は最小に • クラスタマップが更新される • アプリからのデータベースリクエ ストはより多くのサーバに分散さ れる 23©2015 Couchbase, Inc.
- 24. フェイルオーバ サーバ 4 サーバ 5 レプリカ アクティブ レプリカ アクティブ App サーバ 1 COUCHBASE クライアントライブラリ クラスタマップ COUCHBASE クライアントライブラリ クラスタマップ Appサーバ 2 アクティブ サーバ 1 Shard 5 Shard 2 Shard 9Shard Shard Shard レプリカ Shard 4 Shard 1 Shard 8Shard Shard Shard アクティブ サーバ 2 Shard 4 Shard 7 Shard 8 Shard Shard Shard レプリカ Shard 6 Shard 3 Shard 2 Shard Shard Shard アクティブ サーバ 3 Shard 1 Shard 3 Shard 6Shard Shard Shard レプリカ Shard 7 Shard 9 Shard 5Shard Shard Shard • Appサーバがシャードにア クセス • サーバ 3 へのリクエストが 失敗 • クラスタはサーバ障害を検 知 o レプリカのシャードをアク ティブに昇格させる o クラスタマップを更新 • ドキュメントへのアクセス は正しいサーバへ • 通常は、この後リバランス を行う Shard 1 Shard 3 Shard 24©2015 Couchbase, Inc.
- 25. クロスデータセンタレプリケーション (XDCR) 25 • 継続的に ソースクラスタ から リモートクラスタ へとデータをレプリケート • 単一方向と、双方向のレプリケーションをサポート • アプリケーションはどちらのクラスタからも読み書きできる (アクティブ – アクティブ レプリケーション) • レプリケーションのスループットはリニアにスケール • 運用管理をコンソール、REST、CLIでシンプルに ©2015 Couchbase, Inc.
- 26. クロスデータセンタレプリケーション (XDCR) 26 単一方向レプリケーション • ホットスペア / ディザスタリカバリ • デプロイ / テスト用コピー • インデックス作成用クラスタ • コネクタとの連携、例) Elasticsearch • カスタムコンシューマとの連携も可能 ©2015 Couchbase, Inc.
- 27. クロスデータセンタレプリケーション (XDCR) 27 双方向レプリケーション • 複数のアクティブなマスタ群 • データローカリティ • ディザスタリカバリ ©2015 Couchbase, Inc.
- 28. 33 2 データ更新とXDCR 2 マネージドキャッシュ ディスクキュー ディスク レプリケー ションキュー App サーバ Couchbase Server ノード Doc 1 Doc 1 XDCR キュー Doc 1Doc 1 (New in 3.0) リモートクラスタへの レプリケーションも、 メモリ to メモリ 他ノードへの レプリケーションは、 メモリ to メモリ 28©2015 Couchbase, Inc.
- 29. メタデータ除去ポリシーによるメモリ利用の最適化 巨大なデータベースに対するより良いメモリ最適化 頻繁にアクセスしないデータセットの効率的な管理を実現 ワーキングセットのキーとデータのみをキャッシュ & 過去データはメモリから除去 チューナブルメモリ – 巨大なデータセットに対する最適化 ©2015 Couchbase, Inc.
- 30. チューナブルメモリ – 巨大なデータセットに対する最適化 3.0は2.5と比べ、メタデータのメモリ利用を数100分の1に削減可能 注: 上記グラフはデータ追加中の様子、ドキュメントサイズは~0.5KB、~5,000万のドキュメント v.3.0 – ホットなワーキングセットを持つ巨大なDB メタデータだけで 3 GB のRAMを消費 2.5.1 以前 – リアルタイムレイテンシ メタデータのRAM利用はわずか 80 MB ©2015 Couchbase, Inc.
- 31. Thank you.
Editor's Notes
- # 開発者にフォーカス JSON: 多くのAPIで利用されるデータフォーマットのスタンダード DBAの作業よりも、開発者が必要なオブジェクトモデリングを行う # 一貫した高性能 Memcachedが内部で稼働している # スケーラビリティ マスタ、スレーブなどの親子関係、階層関係はなし # 常に利用可能 Linuxカーネルのアップデート、ハードウェアのメンテナンスを運用中にダウンタイムなしに実施可能 Rack awarenessはクラスタ内サーバのグルーピングを任意に設定可能、AWSのAZ、ラック、スイッチ、ハイパーバイザなど リッチなモニタリング
- さまざまなデータタイプをシンプルに保存できる JSONを利用すると、View IndexやSQL for documentが利用できる スキーマはオンデマンドで定義、Create tableやAlter tableを事前に実行する必要はない
- JSON: Java Script Object Notation オブジェクトを手軽にシリアライズでき、表現できるフォーマット Couchbase Serverに保存する情報、ドキュメントはすべてキーを持っている。 キーはドキュメントの一意な識別子、バリューはJSONドキュメント、あるいはバイトストリーム、シリアライズしたオブジェクトなど、任意のデータを保存できる。 バリューはJSON、あるいは整数、Stringなどのバイナリオブジェクト。 キーはまた、ドキュメントIDとも呼ばれ、SQLのプライマリキーと同様の機能。Couchbase Serverのキーは任意の文字列、区切り文字と識別子を組み合わせて ‘person_93679’なども設定できる。ユニーク。 Couchbase ServerにJSONドキュメントを保存すると、そのデータにインデックスを作成し、クエリできるようになる。Couchbase ServerはJavascriptベースのクエリエンジンを提供し、フィールドの値によるクエリが可能。 一般的には、RAMから高速にオブジェクトを参照するキャッシュとしての用途では、バリューは < 1MBを推奨している、がアプリケーション次第。
- 動的にスケール可能 クラスタ内のすべてのサーバに自動的かつ均等にデータを分散 同時に負荷も均一に分割する
- クライアントSDK 2.0系はJSONのシリアライザをデフォルトで組み込んでいるのでより手軽に利用できるようになった。 このようなユーザオブジェクトがあるとする、 SDKには、オブジェクトをJSONにシリアライズするAPIがある 同様にget()したJSONをPOJOにデシリアライズすることができる。 Java界隈ではPOJOというが、他の言語でも同様
- それでは、「シングルノードタイプ」は何を意味するのか、より詳細にみてみましょう。 実際にどのように動作するのか、後ほどデモもお見せします。 すでにインストールされている方はもうご存知かもしれませんね
- すべてのノードで同じコンポーネントがインストールされ、同じプロセスが稼働している ノードごとに個別の設定は不要、コーディネイターやマスタノードは存在しない Redhatベース、DebianベースのLinuxディストリビューション用パッケージインストーラ Windowsインストーラ MaxOS用インストーラは開発用 インストーラをダウンロードして、インストールしてサービスを起動、新規のクラスタとして始めるか、既存のクラスタに参加 起動すると、いくつかのプロセスが稼働、これらのプロセスは二つのグループに分かれている データリクエストに関するもの、クラスタ管理に関するもの それぞれの用途に最適な開発言語を利用している データマネージャ側では、C, C++, これらは最も高性能な言語であるため クラスタマネージメントではErlangを利用、クラスタ内のノード管理に優れている データマネージャ: Couchbaseからデータを取得する方法は2つ 郵便番号でユーザのリストを取得する = View、Viewはディスクに保存されており、良いパフォーマンス、I/O負荷を避けるためにOSディスクキャッシュを利用 特定のユーザをIDで取得する = KeyValue Couchbaseクラスタ内の各ノードではMemcachedが稼働し、11210ポートでリスン ポート11211にはMoxyと呼ばれるプロセス、Moxyは主にMemcached用に開発したアプリケーションをスムースに移行するために存在。アプリケーションをそのままCouchbaseに向けることができる CouchbaseはMemcachedといくつかの点で異なる、Memcachedを利用する場合、単一ノードか、Ketamaによるハッシュを利用して複数のMemcachedノードに分散する Couchbaseでは、Memcachedクライアントにはない、異なるハッシュアルゴリズムを利用、そのため、Moxiがプロキシとなり、MemcachedクライアントとCouchbaseクラスタの仲介を行う これらと連携して、EPエンジンがある。これがMemcachedをより強力にするエンジン。 Memcachedは標準的なキャッシュエンジンで、インメモリのハッシュマップ、非常に良い製品だが、RAMオンリーでディスクの永続化はせず、分散もクライアント側で行う仕組み EPエンジンの仕事は、メモリ上のHashmapで起こった変更を、クラスタ内の他のノードにレプリケートし、同時にデータを守るためディスクに永続化する ディスク上のフォーマットは追記型。 おそらく約半数のお客様はEC2にデプロイしている。 EC2のI/O性能はいろいろ選択可能である、最高性能のI/Oを利用しなかったとしても、ランダムI/Oルックアップに比べて、追記型のシーケンシャルなデータ読み書きは有利??? クラスタマネージャ: それ以外のほぼすべてを担う。Erlangは分散コミュニケーションに向いている言語。 各Couchbaseノードは小さなWebサーバも起動している。これはいくつかの異なる用途に利用 多くの管理用RESTエンドポイントを実装、Couchbaseのさまざまな管理操作を実行可能 Web管理コンソールも提供、コンソールから実行した操作は前述のRESTを呼び出す 統計情報の取得や、ノードの追加、リバランスはREST APIを呼び出すだけ CLIツールもRESTリクエストを送信している、すべてがこのREST APIに紐付いている 管理コンソールでできて、REST API、CLIにできない機能はありません 管理コンソール主体の運用管理だけでなく、ChefやPuppetなどの構成管理ツールと組み合わせたCouchbaseの自動化も可能 BabySitterは基本的にあるプロセスで何か発生した場合にプロセスを停止するかどうかをモニタリングするのが役割 クラスタ内のノード間でメッシュ状にハートビートを送信し合っている。 ConfigurationManagerはクラスタ内に設定情報を分配 その他のいくつかはデモでも紹介します Couchbaseクラスタ内の各ノード上ではこれらのプロセスが稼働している、多くある質問は次の二つ: 参照・更新リクエストを実行したとき、各ノード上では一体何が起こっているのか? 分散システムにおいて、データはどこに保存されるのか? 次のセクションで詳細を見てみましょう。
- Couchbaseクラスタがあるとします、ここでは説明を簡単にするために一つのノードのみ表しています。 また、Couchbase SDKを利用したアプリケーションサーバがあります。 Couchbase SDKはどのデータをどのノードに書き込めば良いのかを知っている。 書き込まれたデータはマネージドキャッシュに保存される、これはMemcached、デフォルトではこの時点でアプリケーションにAckが返却され、アプリケーションは書き込み後の処理を継続することができる Memcachedにデータが保存されると、EPエンジンがこれを検知し、キューに登録する レプリケーション用とディスク書き込み用のキューがある。 レプリケーションでは、メモリからメモリへとネットワーク経由でデータが送られる データがレプリケートされるのに必要な時間はネットワークレイテンシ、スループットはオブジェクトサイズにも影響される 一般的にGigEでは、数ミリ秒、とても高速です。 大抵の場合はディスク書き込みよりも高速です。Fusion-IOなどを利用するとこれらのレイテンシは近いものになるが、通常、多くのお客さまの環境では、データの永続化に8msから20msかかっている。 この方法により、データがディスクに永続化されるのを待たずに、他のノード上にレプリケートされることを保証できます。 前に述べたように、これはデフォルトの動作で、書き込みリクエストごとに変更可能です。 これをDurability Constraintsとよんでいる、日本語だと、永続性の制約?とか サーバに、他のNノードでレプリケーションが完了したら通知を送るように指示すること、もしくはNノードのディスクに書き込みが完了したら データがサーバ3台に永続化されることを保証するのはあまり効率的ではありませんが、非常にクリティカルなデータでは、すべてのノードに複製され永続化されることを確実にしたい場合もあるでしょう。これをオペレーション単位という非常に細かい粒度で指定できるオプションを提供しています。
- 参照のリクエストでも、動きは同様です。ただし、キューは関与しません。 サーバに参照リクエストが送信されると、サーバはメモリ上のハッシュマップを参照してドキュメントを返します この処理速度を示す統計情報があり、どの程度高速にデータを返却できたのかを確認することができる。 通常ハッシュマップの参照は1マイクロ秒で完了します。 参照操作の処理時間の大部分はネットワーク転送で、10GigEの場合大体200マイクロ秒、GigEでは数ミリが一般的です。
- よく誤解されがちなのが、CouchbaseではすべてのデータをRAMに格納しなければならないということ 実際は、ワーキングセットがRAMに収まるよう、プロダクション環境に移行するまえに適切にサイジングを行うことが重要 RAM上のデータは非常に高速に扱える デイリーアクセスユーザ数が全体の10%程度だとすると、10%から15%がRAMに収まるように。 それ以上のデータがある場合、CouchbaseはRAMからアイテムを除去する。
- メモリ上に存在しないデータを参照した場合、ディスクフェッチ処理がリクエストされる。 高性能が求められるアプリケーションでは、キャッシュミスが発生しないようにクラスタの総RAMサイズを正しく見積もることが大事。 足りない場合はノードの追加で拡張可能。
- 例えば4ノードのクラスタの場合、各ノードは256のvBucketを持つ レプリカを1つ設定していた場合、各ノードは512のvBucketを持つ、256アクティブ、256レプリカ ドキュメントIDはCRC32によりハッシュ化、同じキーは必ず同じvBucketにマッピング、データの位置はそのvBucketがどのサーバに存在するのかで決まる vBucketは安全性と効率化のために、専用のマッピング情報で管理されている 安全性とは、同じvBucketが複数のサーバに存在しないこと 効率化としては、大量のデータをサーバ間でシャッフルしないということ 一つのノードが数百GBのデータを保持する環境では、これをノード間で転送するのは非効率ですね このため、各vBucketは1/1024のデータを部分的に保持するようになっています。デモでも紹介します。
- この図が処理の流れを示しています。 この図には6つのvBucketが登場し、クラスタマップによって、vB1と2がサーバA, … となっています。 キーをハッシュし、そのvBucketを保持するサーバに対して直接リクエストを送信できます。 vBucketがどのサーバでアクティブで、どのサーバでレプリカを保持しているのかをクラスタマップが管理しています。 クライアントの初期処理で、このクラスタマップを取得し、リクエストを送信するために利用します。 このため、Couchbase SDKが非常に重要な役目を担います。クラスタのトポロジを理解し、リバランス中のvBucketの移動に追従するためです。
- これまで、vBucket、バケット、サーバ、クラスタについて説明してきました。 この図では3ノードのクラスタがあり、データが均等に分散されています。 分散の単位はvBucketでしたね? そして特定のドキュメントは特定のvBucketに所属しています。 そしてまた、レプリカという概念もあります。サーバ1が持つvBucketのレプリカはサーバ2または3に存在します。 アプリケーションを接続してみましょう。Couchbase SDKは数多くのクライアント言語に対応していて、SDKがクラスタマップを取得します。 そしてvBucketがどのサーバに存在するのかを知っています。 vBucketを持つサーバに対して直接リクエストを送信します。 RDBMSと異なり、参照と更新のリクエストは、アクティブなvBucketに対してのみ行います。 このため、更新されたデータは即座に参照リクエストで取得することができる。 必要があればリクエスト単位で、レプリカからデータを取得することができますが、他のテクノロジーではこれを参照リクエストのスケーリングに利用します。 このアプローチは参照リクエストがここのサーバのディスクI/Oに依存する場合効果がありますが、Couchbase ServerはMemcachedを利用しているため 参照、更新共にアクティブデータを利用するだけで高性能を提供することができるのです。 レプリカはデータの安全性を確保する目的でのみ利用します。
- 常にオンラインで利用でき、クラスタを自由に伸縮させるには、ノードを追加し、リバランスを行います。 これはvBucketとハッシュがより意味をなす操作です。 もしクラスタのデータが急激に増加した場合、ノードの追加で対応することができます。 さらなるディスクI/O、CPU、RAMを追加できます。 二つのサーバを追加してみましょう。 その後、リバランスと呼ばれる操作を実行します。リバランスはクラスタマップを再計算し、新しいノードにアトミックにvBucketを割り当てる操作です。 vBucketを移動するたびに、クラスタマップを更新します。 このため、アプリケーションからは、リバランスによりvBucket移動中であっても正しいノードにリクエストを送信することができます。 リバランスが完了すると、アプリケーションからのリクエストはより多くのサーバによって分散されます。 サーバ台数が増えると、各サーバでの負荷は減少します。 サービスを停止してより高性能なサーバに移行するのに比べ、ダウンタイムなしにサーバの追加が可能で、クラスタのリソースを拡張できることは非常に便利です。 サーバの追加によりクラスタをリニアにスケールすることができます。
- この例ではシンプルにより一つのノードがダウンした様子を示しています。 ノードのダウンは、ハードウェア障害や、カーネルパニックなどで発生、サーバ3が利用不可となりました。 サーバ3はハートビートを返すことができず、オートフェイルオーバが発動します。 クラスタ内の各ノードはお互いにハートビートを送信し合い、ノードが利用不可となると、オートフェイルオーバを有効にしていた場合、 レプリカを自動的にアクティブへと昇格させます。そしてクラスタマップも更新します。 これにより、すべてのデータを継続してサービスすることができます。 フェイルオーバ後はレプリカを部分的に失った状態となるので、通常このあとにリバランスを実行し、レプリカを修復します。 リバランス時にノードを追加して障害前のクラスタサイズに戻すことも可能です。 ラックゾーンアウェアネスは、さらに耐障害性を高めます。 例えば6つのノードがあった場合、ノードを異なる障害ポイントにグルーピングできます。 異なるスイッチ、EC2のAZなど これによりレプリカ数以上のノードに障害が発生しても復旧が可能となります。
- XDCRはプッシュ型のレプリケーション。 ソースクラスタとリモートクラスタがある。 マスタマスタ、マスタスレーブ、デイジーチェイン、それらの組み合わせなどを構成できる どれだけ複雑な構成ができるかは、利用可能なリソースに依存 複数のクラスタに読み書きが可能。アクティブアクティブレプリケーション。 注意しなければならないのはレプリケーションのレイテンシ。 書き込みが競合した場合、最も更新された方が勝つ。 時期バージョンの4.0では、最後に更新したものが勝つ。 異なるクラスタで同一のデータを更新する場合、これに注意してください。 設定は非常に簡単、クライアントからの接続と同様にvBucketとクラスタのコンセプトを利用。 日本とアメリカのクラスタでXDCRを設定した後に、アメリカのクラスタノード数を二倍にしたとしても、 日本のクラスタ側では特に設定を変更するひつようはない、接続にクラスタマップを利用しているため。
- さまざまな用途がある、 継続的なバックアップ、3.0から差分バックアップが可能となったが、定期的に実行する必要がある。 XDCRを使うと継続的に異なるロケーションのクラスタに更新されたデータのバックアップが可能。 XDCRの利点は二つのクラスタのサイズは同じでなくても良いということ。 本番運用には高スペックのサーバを多数利用し高性能を提供、バックアップ側には大容量のディスクを持つ3台のクラスタとするなど。 ホットスタンバイ、DR、同スペックのクラスタにレプリケーションして、万が一の事態に備える。 プロダクションデータを利用したQAプロセス、プロダクションに負荷をかけずにテストを行うなど。 また、他製品との連携にも利用、Solr、Elasticsearchなど
- データローカリティ 中東、ヨーロッパ、アジア、アメリカなどの各地域で最高のレイテンシを提供
- 3.0から、XDCRの動作が変わっています。 Couchbaseではメモリからメモリへの転送が基本的です。 XDCRもRAMからRAMへクラスタ間でレプリケーション。 クラスタ内部のレプリケーションキューと、クラスタ間でのレプリケーションキューがある 外部ネットワークのレイテンシは数100ms 以前のバージョンではディスク書き込み後にレプリケーションしていたが、高速になりました。 This slide has an click-by-click animation 1. (click) A set request comes in from the application . 2. Couchbase Server responses back that they key is written 3. (click)Couchbase Server then Replicates the data out to memory in the other nodes At the same time it is put the data into a write queue to be persisted to disk (click)Once it is on disk, the item is processed by the view engine and sent out any configured XDCR link to one or more clusters
- 3.0からの新機能 メモリ上のハッシュマップに対する操作は非常に高速。なぜなら、キー空間とアイテムのメタデータをRAM上に保持しているから。 キー名に30バイト、メタデータに56バイト、レプリカを一つ作成すると、1アイテムあたり160バイト。 数百や数千のアイテムでは問題になりませんが、数億のアイテムでは問題となってきます。 以前のバージョンではこれらのデータをRAM上にかならず保持する必要があり、制約となってしまうケースがありました。 3.0ではチューナブルメモリという名の機能を追加し、データをRAMから除去する際にそのキーとメタデータも同時に除去できるようになりました。 アーカイブデータを保存するようなユースケースで、過去データのキーやメタデータをRAMに保持したくない場合に有効です。 - Improve the animation for data handling – refresh existing sales deck and deep dives.
- 5千万のドキュメントを保存した場合のメタデータによるRAM消費量を示しています。 ----- Meeting Notes (9/25/14 17:22) ----- from 2.x to 3.0 use key and metadata instead of metadata