Couchbase Serverの社内勉強会資料

1. Couchbase Serverを
半年使ってみた
(株)ゆめみ 仲川樽八

2. 本スライドの目的
本スライドは(株)ゆめみ社内でCouchbaseServerに興味を持ってもらうための勉強会で使用し
た資料の公開版となります。
社内で、システムのメンテナーを増やすことで自分が楽をしたいという個人的な狙いが主目的と
なりますが、こういった形で情報共有することにより、国内での利用がもっと盛り上がってもらえ
ればそれに越したことはありません。

3. What is Couchbase
Server

4. Couchbase Serverの特徴
（その1）

5. Couchabe 3.x系
• NoSQL
• 他のNoSQL製品と比べても速いよ
• ノード追加でどこまでもスケールするよ
• データ量
• CPU資源・メモリー資源
• データ冗長度を高く設定できるよ。(AZ間で持てるのでZone障害でデータロストしない)
• XDCRという機能があって、リージョン感で双方向レプリケーションできるよ。(海外に待機系シス
テムを構築すれば東京リージョン全滅でも大丈夫)
• elasticsearch連携すれば横断検索も出来る
• SDKの完成度が高くて信頼性があるよ。
• WebConsoleの出来が異様にいいよ。

7. Couchbase 4.x系
2015年10月頃に正式リリース
• NoSQLなのに、N1QLというSQLが使える!!
まさにNot Only SQL
NoSQLなのに、ドキュメントを横断検索した結果でUpdateなんてことも出来る。
いろいろ妄想が広がる
• Couchbase3.x系→4.x系のバージョンアップもXDCR機能などを使えばダウンタイムゼロで可
能!!

8. 良いことだらけじゃないか!!

9. Why Japanese Peopleは
もっとCouchbase Server使わない
の？

10. と切れる前に、

11. それ、RDBで出来ない？

12. ソリューション選定の鉄則

13. 候補ソリューションの
メリットに目を奪われてははならない。

14. 必須要件の中に出来ないことが一つでもあるのであれ
ば、そのソリューションは選んではならない。
それを忘れたものは地獄の業火に焼かれるであろう。
Taruhachi (1975~)

15. Couchbase Serverの特徴
（その2）

16. 特徴（地雷）
• 大事なデータを扱おうとするとライセンス版がほぼ必須。
• 冗長化すると最小構成でもかなりリッチな構成になる。
• Couchbase社、日本法人撤退しちゃった。
• トランザクションレス（多くの場合致命的）
• データの中身の検索が弱い。Unique 制約等が貼れない。
• elasticsearch連携できるが、、、。
• N1QLでSQLが使えるが、、、。
• データの外部連携が面倒。

17. 結論から先に言うと、
どうしてもNoSQLでないといけない案件の時には積極的に検討したい。
ただし、RDBが使えるのであれば、悪いことは言わないので使っておこ
う。

18. それでも茨の道を歩みたい人、
歩まなければならない運命を持った人
は続きのスライドをどうぞ。

19. 各地雷は
・アプリケーションの実装で踏み抜く
・運用でカバーする
のいずれかで対応する必要があります

20. 大事なデータを扱おうとすると
ライセンス版がほぼ必須。
特徴（地雷）

21. 以下の機能はノード単位でライセンス費用が必要となる。
※ Oracleよりはかなり安いですが、、、small startな案件には厳しいかも。
• XDCR機能
複数のCouchbaseCluster間でデータのレプリケーションを行う機能
リージョンをまたいで双方向のレプリケーションも可能
ダウンタイム無しでのバージョンアップや、CouchbaseClusterの切り替えなどにも便利
• クラスタ中のノードのグループ化する機能
ノードをグループ化することにより、該当ノードのデータの複製先を必ず別のグループのノードに割り当てる
という指定が可能。AZ(データセンターに相当)を指定することでAZ障害においてもデータが欠損しなくなる。

22. 冗長化すると最小構成でも
かなりリッチな構成になる
特徴（地雷）

23. 各AZに2台のノードを配置、それを複数AZに展開することで初めて十分な冗長化とオートフェールオーバー
機能が利用できる。
※Split Brain状態を防ぐため、オートフェールオーバーが機能するのは最初の1台のダウンだけ。
Availability Zone Availability Zone
最小構成で4ノード、4ライセンス
※ただし、バケット数の制限はないので複数の
案件でクラスタを共有することは可能

24. Couchbase社日本法人撤退しちゃった
特徴（地雷）

25. 日本における先行きは不透明な感じ。
特にCommunity版の将来は日本語ドキュメント量にかかってきそう。
ただし、英語ドキュメントならそれなりにあるので頑張れば日本でのコ
ミュニティーも存続できるかも！！

26. トランザクションレス
特徴（地雷）
Foundation DB という、
NoSQL but ACIDを標榜していた製品があったのですが、、、。

27. トランザクションレス
• (NoSQL製品では当たり前ですが、)トランザクション使えません。
• 複数のデータオブジェクト間のデータ整合性は取れません。
※CASは使える、AtomicCounterも使える
• お客様にもいろいろ諦めて頂く必要がある。
• 何を諦めて頂く必要があるかは具体的に全て洗い出して、個別で了承をとって頂く。
• 、、、こうすればNoSQLでもデータ整合性を担保できる系の記事は全部眉に唾つけて読んでいます。
• 全ての更新をキューに入れて、成功するまで更新操作を繰り返すという実装は不採用。
※この方法でも新たに別の問題が発生するのでその問題を踏み抜くメリットとの相談。

28. トランザクションレス
データの更新順序などを厳密に定義して、それぞれの不整合状態を洗い出し、不整合発生後も自動的に修復を図れ
るようにアプリケーション側で全て実装する。
※これを全てのデータ操作に関して定義、確認した上で実装も正しくされていることを担保する必要がある。
Doc
A
Doc
B
Doc
C
Doc
D
Doc
A
更新中ステータスにする 更新 新規追加 削除 更新完了状態にする
この間で発生したデータ不整合は
失敗とみなし、アプリケーションには失敗ステータスを返す
この間で発生したデータ不整合は
成功とみなし、アプリケーションには成功ステータスを返す
次回のアクセスで自動修復する
例

29. トランザクションレス
構築されたシステム内のデータの整合性を基本的に信用出来ない。
• 外部システム側で発生したエラーも全て内部のデータ調査が必要となるが、KVSなので都度調査ス
クリプトを作成する必要がある。
• 身の潔白を証明する責任が非常に大きい。（だいたい緊急調査）
• 最後のデータの突き合わせ調査が終わるまでは自分自身が疑心暗鬼。
• 実際に不整合データが発生していたら、場合によっては完全に終わる。
→データ不整合修正プログラムを作って頑張る。

30. データの中身の検索が弱い。
Unique 制約等が貼れない。
特徴（地雷）

31. • データはJSONドキュメントとして保存しますが、JSONドキュメント中の特定のvalueを利用して
の検索ができません。（Viewという機能はあるけど非同期であり使いどころが難しい）
• また、Valueに対するユニークキーなども貼れないため、ユニークであることを担保するために
は別に逆引きのIndexドキュメントを作成しなければなりません。（テーブル間のリレーション毎
に逆引きのためのカラムを別途設ける）
• 上記の理由により、本来同一で良いドキュメントが複数に分割されますので、更新しなければ
ならないドキュメント数は増えるのですが、ここで先程述べたトランザクションレスの呪いが降り
かかります。

32. elasticsearchとの連携ができるが、、、
特徴（地雷）

33. XDCR機能で、Couchbaseの更新を
全てelasticsearchにレプリケーションする事が可能だが、
実データ
Index
data
XDCRデータ更新
横断検索なんて出来ねぇよ！！ 横断検索は任された！！

34. XDCR該当ドキュメントの更新さえすれば良い 該当ドキュメントを展開して各
valueをNgramでインデックス
化
古いインデックスも全て整理
Couchbaseの仕事量 << elasticserachの仕事量
検索要件を絞り込んでおかないと、全てにIndexを張る
必要が出てくるため、、、

35. • Couchbaseの高い更新能力にelasticsearchのIndex更新能力が全くついてこれない。
• 当然大きなレプリケーション遅延が発生する。
• ElasticSearch側のIndexとCouchbase上の実データの乖離が大きくなりすぎるのをアプリケー
ションで担保しなければならなくなる。
→使えねぇ！！！！！ということで使いませんでした。
→じゃぁ、どうやって検索要件を満たしたかは後述

36. N1QLでクエリが使えるが、、、
特徴（地雷）

37. • N1QLを使うなら、1テーブル = 1バケットの考え方で実装しておきたい。
• JOINが面倒、コストが高い（JOIN先は必ず別のドキュメントのキーである必要がある）
• 検索要件に合わせてIndexを増やすと、物理メモリを大量に消費するので高コストとなる。
• Selectされる結果セットが数万件以上になると異様に遅くなり実用に耐えない。
• すぐにタイムアウトする
• Index更新が非同期でSelect条件と得られる結果がズレたりする
• 大量データのExportには向かない。
（巨大なJSONドキュメントとして結果が得られる。落ちる、ページングしてる間にデータが更新される。）
• N1QLのご利用は計画的に

38. データの外部連携が面倒
特徴（地雷）

39. VIEW機能も使いにくいし、
N1QL使っても大量データ出力には向かない。
→RDB(MySQL)にデータ連携しちゃえ

40. RDBなら
• トランザクションが使える!!
• 比較的安価
• 柔軟なSQLがあとからいくらでも書ける
• 大量データ出力に強い(行フェッチが可能)
• 開発者多い
• N1QLとは比較にならないくらい高速
• レプリケーションも楽
• 調査が楽
• データの断面が取れる
• ぶっちゃけ何やるにも楽

41. Couchbaseのデータを
RDBにレプリケーションしよう

42. RDBへのデータ連携が出来ると後が楽
外部システム A
外部システム B
S3
Embulk等
Semi Realtime
Replication
Couchbase利用システ
ム
横断検索
Search API
FTP
MySQL Replication
データ外部連携システム
外部システム C
※このAPIも外出しは可能
※更新差分データ提供

43. 問題はここの部分だけ
Semi Realtime
Replication
Couchbase利用システ
ム

44. 基本的な考え方
1. Couchbase上のドキュメントを更新する際にレプリケーション対象としたいドキュメント（※）には全て
_microtimeという更新時刻を残すようにアプリケーションを構築する。
※逆引き用Indexなどはレプリケーション対象とする必要がないので不要。
2. 既にRDBに存在する最新の_microtimeより新しい更新時刻を持つドキュメントを、_microtimeのより古い方
からN件取得する。（N1QLを利用する）
3. 上記のドキュメントをRDB上の対応するテーブルに同一トランザクション内でReplaceをかける。
※失敗時にはロールバックさせて次のプロセスの処理対象とする。
→ 2. へ戻る

45. レプリケーションをもう少し詳しく言うと、
N1QLで更新差分データのみをN件抽出
例:1000件毎
Data Service
Index Service
非同期でIndex更新
同一トランザクションでN件全部Replace
Couchbase利用システ
ム
Query Service

46. ところが、
N1QLで更新差分データのみをN件抽出
Data Service
Index Service
非同期でIndex更新
同一トランザクションでN件全部Replace
Index更新遅
延
Couchbase利用システ
ム
Query Service
川

47. レプリケーションされないデータが出てきた。
Couchbase上の更新はN1QLのIndex更新キューに積まれ、その後実際にIndexが更新されるが、
アプリケーション側から入れた_microtimeは実際にキューに入った順番とは異なる可能性がある。
※アプリケーションサーバが複数台あるため
この時、既にレプリケーションされたデータより古いデータが後から届くことがあるが、それは次回の検
索対象とはならない。
Index更新の最終行付近のデータが信用出来ないので、N1QLのIndex更新が実際にはどこまで終
わっているかを正確に知る必要がある。
→ 更新チェック用のドキュメントを作成、それをバッチで毎秒更新した上でN1QLのIndex上の時刻
を調査することで対応。した。

48. N1QL Index上のデータ参照方法
USE INDEXを利用したクエリを発行し、SELECTの中身にINDEX中で指定したカラムのみを指定することで、実
データへのアクセスをせずに、Index上のデータを取得することが可能。（Explainで確かめる）
Explain SELECT max(_microtime)
FROM `【バケット名】` USE INDEX (`idx_doctype_microtime`)
WHERE doctype='N1QL_INDEX_CHECKER’;
→ “expr”: “cover((`accountpf-ph1`.`_microtime`))”となっている場合は、Index上のデータをそのまま利
用している。
そうなっていない場合は実データへのアクセスが発生している。

49. それでも、やっぱりRDBへの投入って遅れるよね
N1QLで更新差分データのみをN件抽出
Data Service
Index Service
非同期でIndex更新
同一トランザクションでN件全部Replace
データ更新遅延
高負荷時においても
5分以内に更新完了
Couchbase利用システ
ム
Query Service

50. リソース使用状況
（RDSレプリケーション用WRITEスループット）
予めcouchbaseバケットに対して各テーブル
1000万件程度のデータを投入していた状態
のレプリケーション状況。
RDS for MySQLを利用した場合、レプリケー
ション開始から暫くの間は数千records/sec
でのレプリケーションがされるが、途中から
Write Operationに上限が観測され、
300records/sec程度でのレプリケーション
しか行えなくなっている。
これをインスタンスタイプをスケールダウンし、
1000PIOPSを確保すると、スループットの向
上が見受けられ、2000req/sec程度のレプ
リケーションが可能となった。
MySQL r3.2xlarge MySQL m4.xlarge
1000PIOPS
Write operationに上限が観測され
る
暫くは速い
安いインスタンスのほうが速い

51. RDS for MySQLは高負荷状態が続くと
WriteOperation速度に制限がかかってしまう。
※短期間の場合はOKであることに注意
→インスタンスタイプを下げてでもPIOPSを購入することでこの状態の
解消が可能だが、この状態ではまだ遅い。

52. ついでにRDS for Auroraも試してやれ

53. リソース使用状況
（RDSレプリケーション用ネットワークスループット）
予めCouchbaseバケットに対して各
テーブル1000万件程度のデータを投
入していた状態のレプリケーション状況。
※Auroraの方が安いインスタンス
全体的にAuroraの方がスループットが
高く、先にレプリケーションが完了してい
ることがわかる。
Aurora5時間、 MySQL 9時間
Aurora
r3.xlarge
MySQL
m4.xlarge
レプリケーション完了

54. リソース使用状況
（レプリケーション用RDS空きメモリ）
Auroraの方が空きメモ
リに余裕がある状態で
あるため、検索用index
がオンメモリとなることが
多い。
※どちらもメモリから落ち
た時は検索にかなりの
時間が必要となる。
Aurora
r3.xlarge
MySQL
m4.xlarge

55. Auroraなら安いインスタンスでもレプリ
ケーション遅延がほとんど発生しない!!
※フロントのAPIに対して数万req/sec
の負荷試験を行っている状態。(更新は数千req/sec)

56. ベストソリューションの選定は
やってみないとわからないので
簡単なものならまずやってみよう。
※試験段階なら、RDS for MySQL と AURORAの変更はすぐ

57. ただし
更新データの検知をレプリケーションするというこの方法では、物理削
除されたデータがレプリケーション対象とならないことに注意する。
→どうせCouchbase上でリレーションデータは相互に握っているので
そちらもレプリケーションさせて後から突き合わせる等の対策が必要。

58. 結論
重要なデータをNoSQLに格納するという使い方は、必要に迫
られないかぎり敢えて手を出さないのが無難。
でも、どうしても使いたい場合にCouchbaseServerは非常
に良い選択肢となりうる。
なぜならば、Couchbase→MySQLへのレプリケーションをす
るというソリューションを手に入れたから。

59. 素材は
http://www.irasutoya.com/
さんのものを利用させて頂きました。