Couchbase Serverのサーバ移管と2.1から3.0.1へのバージョンアップ

Copyright 2015 CYBIRD Co., Ltd. All Rights Reserved.
Couchbase Serverのサーバ移管と
2.1から3.0.1へのバージョンアップ
株式会社サイバードビジネス戦略統括本部
小池大地 (Daichi KOIKE)
2015年7月22日
1
Couchbase MeetUP Tokyo - #14

自己紹介
小池大地 (Daichi KOIKE) 
• 2013年4月新卒入社
• iOS共通システム開発
• ときどきサーバ
• daichi.koike@gmail.com
2

本日伝えたいこと
• AWSにサーバ移管しました
• 平行して2.1から3.0.1にバージョンアップしました
• XDCRを使わず、バックアップ&リストアの方法で
データを移行しました
3

4
システムの概要

ビジネス上の課題1
従来のWebアプリからネイティブアプリへの移行が進み、
サーバ内に自動的に残るログが減少しているため、意図
的にデータを収集する必要がある。
5

ビジネス上の課題2
Google Analyticsなどの外部解析ツールはユーザに着
目した分析が困難なので、社内に複数アプリにまたがって
ユーザを分析する環境が欲しい。
6

本システムの目的
アプリ横断的な集計・分析が
可能な基盤を作ること 
(2013年11月)
7

サーバの課題1 - 可用性
複数アプリから常にアクセスされるため、システムダウンは
許されない。障害時においてもシステムを完全に停止させ
るのではなく、縮退運転をさせる必要がある。
8

サーバの課題2 - 拡張性
トラフィックが急激に増加するゲームアプリのイベントにも
耐えられなければならない。即座にスケールアウトできる
ことが重要。
9
イベント
発生

サーバの課題3 - データ構造
アプリごとに取得データが異なるため、柔軟なデータ構造
が求められる。
10

サーバ構成
11
Webサーバ
MariaDB
データ集計
Couchbase Server
データ蓄積
バッチ処理・
データ可視化サーバ

サーバ構成
12
Webサーバ
MariaDB
データ集計
Couchbase Server
データ蓄積
バッチ処理・
データ可視化サーバ
表側
裏側

13
移管について

14
1月にAWSに移管しました

移管の要件
• 常時アクセスされる共通システムのため、オンラインで
移管しなければならない
• リアルタイム処理は行っていないため、バッチ処理が走
る深夜時間までに移管が完了していればよい
15

ついでに
メモリ内のメタデータ占有率が50%超えのアラートがよく
発生していた。
16
IPアドレス
IPアドレス
IPアドレス
IPアドレス

ついでに
3系からドキュメント削除時にメモリ内のKeyとメタデータ
も完全に削除するオプションが追加されているので、2系
から3系にバージョンアップしたい(2系ではValueが削除
されるのみ)。
17

移管案1
自社環境クラスタとAWSクラスタで、XDCRによるクラス
タ間の双方向レプリケーションを使う。
18
自社クラスタ AWSクラスタ

移管案1
19
自社クラスタ
事前にレプリケーションを設定
AWSクラスタ

移管案1
20
DNS切り替え

移管案1
21
DNS切り替え
こちらにアクセスが来ても
XDCRで同期される

移管案1の良い点
• レプリケートができていれば、当日はDNS切り替えだけ
でむので圧倒的に楽
• 移管に失敗した際に元の環境に切り戻すのも楽
22

• レプリケートができていれば、当日はDNS切り替えだけ
でむので圧倒的に楽
• 移管に失敗した際に元の環境に切り戻すのも楽
23
当日作業が楽！！

移管案1の悪い点
• XDCRではデータは平文で転送されるので、VPN接続
をするなどの対応が必要(※3系では暗号化可能)
• クcが一致していないといけない
24

• クラスタ間でCouchbase Serverのバージョンが一致し
ていないといけない
クラスタ内でバージョンの違うノードが混在できるので、 
バージョンがばらばらでも可能だと思っていた…。
25

26
不採用

27
不採用
追記
クラスタ間のCouchbase Serverのバージョンが
バラバラでもXDCRは使えるとのことです。

移管案2
自社環境クラスタのフルバックアップを取得し、AWSクラ
スタでリストアするというXDCRを使わない手法。
28
AWSクラスタ

移管案2
29
事前にクラスタの
フルバックアップをリストア

移管案2
30
DNS切り替え

移管案2
31
DNS切り替え
自前でAWS側に送る

• 2系のバックアップを3系にリストアできるため、バージョ
ンアップも同時にできる
• 事前準備が楽
32

• 移管に失敗した際に元の環境に切り戻すのに手間がか
かる
• DNS切り替え後に自社環境にアクセスされたデータを
自前でAWS側に送る仕組みが必要
33

• 移管に失敗した際に元の環境に切り戻すのに手間がか
かる
• DNS切り替え後に自社環境にアクセスされたデータを
自前でAWS側に送る仕組みが必要
34
ちょっとしんどい。

35
バージョンアップもしたいので
移管案2を採用

2.1→3.0.1へ
当初3.0にしようとしたが、ノードの追加、削除時のリバラ
ンスが止まるなど不安定だったため3.0.1に変更した。
3.0.1では問題なく動作することを確認。
クライアントは2013年10月リリースのPHP SDK 1.2だが
問題なく動作したのでアプリケーション側は変更なし。
4.0 Beta 1でも使えた。
36
IPアドレス

前日作業
1. フルバックアップの取得処理
$ cbbackup http://[HOST]:8091  
/my/path/couchbase_backup  
-u [USERNAME] -p [PASSWORD] -b [BUCKET]
2. リストア処理。大体3~4時間ほどで完了
$ cbrestore /my/path/couchbase_backup  
http://[HOST]:8091  
-u [USERNAME] -p [PASSWORD] -b [BUCKET]
37

当日作業
3. リストア処理の確認
4. 前日のバックアップ取得以降のデータをAWS側に書き
込み
5. 最終動作確認
6. DNS切り替え
38

作業の流れ
39
前日データ当日データ

作業の流れ
40
フルバックアップ
↓
リストア

作業の流れ
41
↓
リストア
手動で 
書き込み

作業の流れ
42
これ以降バッチ
↓
リストア
手動で 
書き込み

3.0.1にした結果
• Viewがかなり高速になった。複雑なクエリを投げても 
1秒かからない
• リバランスが速くなった。検証では従来の2倍ほどの 
速度に
43

メモリ内もすっきりした(ゴミが消えたのもあるでしょうが)。
44
31.4GB
19GB

クラスタに名前が付けられるようになった。
45

46
トラブルもなく移管完了

随所に染み渡る思想
「開発者がリラックスして、カウチソファに座ってい
るようにデータベースの設計・構築・運用ができる
ように」
47

告知
8/31(月)のCouchbase Live Tokyoで、 
「N1QLのDeveloper Preview 4を社内ツールに入れて
みたよ」という話をします。
48
IPアドレス

告知
Couchbase Mobile ワークショップ
日程: 9/1(火) 10:00 ~ 17:00 
場所: Theatre CYBIRD 
ご飯も出るらしいですよ。
49

最後に
エンジニア募集中です！
50

Couchbase Serverのサーバ移管と2.1から3.0.1へのバージョンアップ

More Related Content

What's hot

Similar to Couchbase Serverのサーバ移管と2.1から3.0.1へのバージョンアップ

Recently uploaded

Couchbase Serverのサーバ移管と2.1から3.0.1へのバージョンアップ