どどどど? Couchbase Server どどど どどどどどどど Kazumi HIROSE
Jan 15, 2015
どう使う?Couchbase Server 運用とパ
フォーマンスKazumi HIROSE
自己紹介廣瀬 一海 ( ひろせかずみ )http://www.facebook.com/kazumi.hirose株式会社アイレット クラウドパック事業部 研究開発チーム
インフラエンジニア、最近はクラウドを使って、インフラを構成しています。好きなクラウドは Microsoft Azure現在のお仕事は、パブリッククラウドを始めとした様々なクラウドを比較検討しながら、研究開発を日々行っています。
Microsoft MVP – Microsoft Azure (Windows Azure)Japan Azure Users Group (JAZUG) コアメンバ
クラウドを多くの人に使ってもらう為の、次のステージに参加してくれる仲間も絶賛募集中です。
今回のミッション
• 出来る限りダウンタイムを低減• 急増、急減するトラフィックに柔
軟に対応• 高可用性を維持
構成俯瞰
Windows Azure Load Balancer
Virtual Machine (IaaS)
Couchbase Server Cluster
Azure Storage BLOB
Azure Storage Table
Azure Storage Queue
Virtual network ( 仮想 L2)
Cloud Services (PaaS)Web Roles IIS PHP
Cloud Services (PaaS)Worker Roles
Virtual Machine (IaaS)
Mariadb Cluster
Couchbase をつかった利用シーン
• モデル、セッション、レンダリングなどのキャッシュストレージとして
• ユーザーデータの永続化保存領域として
Couchbase について
memcached Buckets Couchbase Buckets
最大アイテムサイズ 1MByte 20Mbyte
アイテムデータの永続化 No Yes
レプリケーション No Yes
リバランス No Yes
クライアント memcahed (libketama) Consistent hashing / couchbase SDK
Memcached と Couchbase2 つのストレージを扱う事ができます。
node1 node2 node3 node4
vBuckets
vBuckets couchbase port 11211
vBuckets memcache port 11212
vBuckets memcache port 11213
vBuckets memcache port 11214
vBuckets
永続化やレプリケーション機能を持った Couchbase で保存X 用 /Y 用 /G 用と Memcache と管理するサーバクラスタやデーモンの起動を増やさないで済むので管理が楽だった
Node1
Node2
Node3Node4
Node5
Replication
vBuckets couchbase port 11211
クラスタ内に指定した数のレプリカデータを保持し、ノード障害時のデーター損失を回避
Key1(Org)
Key1(Rep)
Key1(Rep)
Replication
ノードのスケールアウト時にデータの分散再配置を自動化できるのは、管理が楽だった
Cross Datacenter Replication (XDCR)
Node1
Node2
Node3Node4
Node5
Node1
Node2
Node3
Node4
Node5
vBuckets couchbase port
11211
Key1(Org)
Key1(Rep)
Key1(Rep)vBuckets
couchbase port 11211
Key1(Org)
Key1(Rep)
Key1(Rep)
Replication
Region1 Region2
Virtual network ( 仮想 L2)
Cross Datacenter Replication (XDCR)
DC (リージョン)をまたいで事業継続用のバックアップを確保など便利にできそうな(見込みがあった)開発開始当時は速度面に難があり( 2.5 で改善された)
Rebalance
vBuckets couchbase port 11211
Node1
Node2
Node3
Node4
Node5
NewNode
6 クラスタに新規サーバの追加する再など、クラスタの構成変更に合わせ「リバランス」を行い、既存のデータの分散再配置を行う
Rebalance
ノードのスケールアウト時にデータの分散再配置を自動化できるのは、管理が楽だった
Failover
vBuckets couchbase port 11211
Node1
Node2
Node3Node4
Node5
Node が死亡した場合にでも性能は劣化するがレプリカ数を Keep
マニュアルでの Node の新規追加、もしくは復帰により戻ってきた場合には再リバランスにより、縮退運転から継続したレプリケーションを再開
Key1(Org)
Key1(Rep)
Key1(Dead)
Key1(Keep)
Failover
クラウドだったので、新規ノード追加で、縮退から速やかに復帰でき、運用管理が楽だった
Failover
CPU 高負荷時に監視レスポンスが 30秒超えたケースなどが、フェイルオーバー 30 秒ではちょっと短い( 2.5 では 120 秒になったそうです)
開発における戦略
ユーザーの ID が既に決まっている事が多い(既に API 経由でのログインで ID が取得できている)ユーザーのデーターを以下のように名前空間管理01204444440120444444/Item0120444444/UserProfile….01205115110120511511/Item0120511511/UserProfile….
開発における戦略
JSON の「 serialize/deserialize 」のコスト名前空間管理で分割する事で Key / Value そのものを出来る限り小さく
最終的には igbinary(PHP) にシリアライザを変更
Node1
Node2
Node3Node4
Node5
Performance 戦略
vBuckets couchbase port 11211
台数が増えると、一台あたりの IO はかなり下がる。
• 大きなスペックのインスタンス?を数台?
• 小さなスペックのインスタンス?を大量?
Key1(Org)
Key1(Rep)
Key1(Rep)
Node1Node2
Node3
Node4
Node5
Node6
Node7
Node8Node9
Node10
Node11
Node12
Node13
Node14
Node15
Node16
Performance 戦略
vBuckets couchbase port 11211
• 小さなスペックのインスタンスを並べる戦略
• ダウン時の影響度が下がり、リバランスのコストが下がる
• ダウン時の影響度が下がりリバランスのコストが減る(フェイルオーバー時のダウンタイムを短縮)
Performance 戦略
Couchbase Server 2.0 クラスタ サイジング入門 Part 1: 何台のノードが必要か ?
http://bit.ly/1lClLkW
セッティング(クラウドの場合)• Linux の場合
• Swap を切る、 vm.swappiness = 0; (/etc/sysctl.conf)
• データーディスクは既に多重化されている為、信用し Ext4 の IOバリアを解除
• Couchbase の multi write を有効化• 複数のデーターディスクを束ねてストライプでの対応な
ど• 展開は Chef で自動化 / ansible (最近)
Couchbase 楽だった
次のセッションも Couchbase !席はそのまま!
27Couchbase, Inc. Confidential
お問合せ:Couchbase Japan 株式会社〒 231-0062神奈川県横浜市中区桜木町 1-1-7TOC みなとみらい 10階TEL: 045-228-5574Email: [email protected]: http://www.couchbase.com/jp