狠狠撸

Copyright 2014 CYBIRD Co., Ltd. All Rights Reserved.
Couchbase Serverを用いた
大規模データ収集基盤
株式会社サイバードゲーム事業本部
小池大地 (Daichi KOIKE)
1
db tech showcase 東京 2014
2014年11月12日

自己紹介
小池大地 (Daichi KOIKE)?
? 2013年4月新卒入社（2年目）
? データ収集基盤開発?運用
? 社内唯一のCouchbaseエンジニア
? daichi.koike@gmail.com
2

会社紹介
3
各プラットフォームでモバイルビジネスを展開。

本日伝えたいこと
? 1年間のCouchbase Serverの稼働率100%を
達成
? Couchbase Serverは安定したパフォーマンスを
発揮した
? Couchbase Serverはシステムを停止させずにメ
ンテナンス可能
4

アジェンダ
? 導入の背景とビジネス上の課題
? Couchbase Serverの導入と運用事例
5

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

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

本システムの目的
アプリ横断的な集計?分析が
可能な基盤を作る
8

実現手段1 - 共通ID
アプリ間でユーザを紐付けられるよう、全社共通のIDを社
内SDKが発行。共通IDによりアプリ横断的にユーザを識別
可能。
9
ABCDEFGH-IJKL-MNOP-QRST-UVWXYZ123456

実現手段2 - トラッキング
アプリサイドで独自に情報を取得?送信する。アプリの終了
時にデータ送信を行うことで、Push通知からの起動時な
ど一斉にアプリが起動されるタイミングでの負荷を分散。
10
ユーザのデータ

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

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

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

14

Couchbase Serverとの出会い
15
CEDEC 2013の「Draw Something」というお絵かきアプ
リの講演
http://cedec.cesa.or.jp/2013/program/ENG/11253.html

Couchbase Serverの特長
? ドキュメント指向
? 高パフォーマンス
? 自動シャーディング
? 高スケーラビリティ
16

ドキュメント指向
17
? JSONやXMLで記述された「ドキュメント」でデータを管理
? スキーマレス
? ドキュメントに対してクエリが使用可能
? ドキュメントにはKeyを用いてアクセス
? Couchbase ServerはJSONを採用

Couchbase Server環境
18
? Couchbase Server 2.1.1 Community Edition 64bit
? Couchbase PHP SDK 1.2
スペック
最も重要なRAMが推奨スペック未満の環境で運用開始。
推奨当社必須
CPU 3GHz 4コア 2.5GHz 8コア 2GHz 2コア
RAM 16GB 7GB 4GB

サーバ構成
19

1年運用した結果
稼働率100%
20
2013年11月より運用開始

ストレージタイプ
21
Couchbase Type Memcached Type
アイテムサイズ 20MB 1MB
永続化 Yes No
レプリケーション Yes No
リバランス Yes No
Couchbase Typeを採用。

vBucket
22
ハッシュ値ノード
vb1 Node A
vb2 Node A
vb3 Node B
vb4 Node C
Couchbase Serverを支える強力な仕組み。Keyの接続
先サーバを管理し、データの分散配置を行う。すべてのノー
ドおよびクライアントが持つ。
Key
ハッシュ化

vBucketの特長
23
? vBucketがノードの物理的位置を抽象化するため、ク
ライアント-サーバ間にプロキシなどは不要
? クライアントはノードに直接通信するため、すべてのオ
ペレーションが1アクセス
? ノードの追加時にはリバランス中に動的にvBucketが
更新される
? 開発者はvBucketを意識することはない（そもそも
vBucketに直接アクセスできない）

書き込みのレベルを三段階に分けて指定可能で、今回は
1を採用。永続化とレプリケーションは非同期で行われる。
1. メモリ書き込み時（デフォルト）
2. ストレージ永続化時
3. レプリケーション完了時
SDKによるset
24
Memory
Storage
1
2
3
Node BNode A
SDK
クライアント

パフォーマンス
25
クライアントから見たパフォーマンスはノー
ドの数に関わらず一定。

レプリケーション
最大で3回のレプリケーションを設定可能で、今回は2回
に設定。マスターに書き込まれると非同期でレプリケーショ
ンが実施される。
26
Node A Node DNode B
Doc1
Master
Node C
Doc2
Replica
Doc2
Replica

フェイルオーバー
マスターが格納されているノードがダウンした際は即座に
切り離すことが可能。レプリカが格納されているノードのど
ちらかがマスターとなる。
27
Node DNode B Node C
どちらかがマスターに
Doc2
Replica
Doc2
Replica
Doc1
Master

フェイルオーバー
Couchbase Serverは永続化、レプリケーション前にノード
がダウンするとデータがロストする危険性がある。
?
運用中に2回ノードがダウンしたが、データのロストはな
かった。
28
Memory
Storage
1
2
3
Node BNode A
SDK
クライアント

Graceful Fail Over
Couchbase Server 3.0で「Graceful Fail Over」という
安全にフェイルオーバーを実施する機能が追加されたの
で、データがロストする可能性の低下が期待できる。
29

Node A
リバランス
ノード数が変わった際の既存データの再配置処理のこと。
リバランスはシステムを停止することなく実施可能で、ミド
ルウェアでシャーディングをしてくれるので非常に楽。
30
Doc
Doc
Doc
Node B
Doc
Doc
Doc
Node A
Doc
Doc
Node B Node C
Doc
Doc
Doc
Doc
new!!

リバランス時の性能劣化
ただしCouchbase Serverの性能は少々劣化してしまう。
ある日1台ノードを追加した際の例?
?
リバランス実施日は70万set/day程度で、Couchbase
Server内のドキュメント数（レコード数）は7,000万件ほど。
リバランスは10~11時に開始し、約8時間かかった。
31
setタイムアウト件数(1日)
通常 1~5
リバランス実施日 400

リバランス失敗
メモリ内のメタデータ占有率が50%超えのアラートが発
生したため、ノードを追加しリバランスを開始。
32
IPアドレス
IPアドレス
IPアドレス
IPアドレス

2~3回リバランスを実施するも途中で失敗する。?
考えられるリバランス失敗の原因
? そもそもメモリが推奨スペックを満たしていないため、?
これ以上ドキュメントを格納できなかった
? 不要なIndexが残されており、Index更新処理の負荷が
大きかった
33

実施した対応
? RDBに格納済みの使用しない古いドキュメントを消す
? 一時的にCompaction処理を無効化
? 不要なIndexを削除
?
再度リバランスを実施したところ無事成功。このときがドキュ
メント数のピークで、これ以降は古いドキュメントは消すよ
うに運用を変更した。
34

根本的な対応
総メタデータサイズ = ?
ドキュメント数 × (メタデータサイズ + Keyサイズ) × (ノード数)
メタデータサイズの詳細
Keyサイズ(ドキュメントにアクセスするKeyのサイズ)が極力?
小さくなるようKeyを設計し、総メタデータサイズを抑える。
35
バージョンメタデータサイズ
2.0 60Bytes
2.5 54Bytes

3.0からの新機能
36
Couchbase Server 3.0から以下ふたつの機能が追加
? メモリ内に保存するデータを管理できる?
「Tunable Memory」
? ドキュメント削除時にメタデータを一緒に削除できる?
オプション
メタデータ問題は概ね解消されていると思われる。

バックアップに関するトラブル
リバランスに失敗した時点でのフルバックアップを取得し
たが、一見正常にバックアップが終了しているにも関わら
ずリストアできないという謎の現象が発生。バグ？
もう一度フルバックアップをしたところ正常にリストアできる
ことを確認。
37

バックアップに関するトラブル
バックアップ作成時はリストアできるこ
とを確認すること。
38

凄い点
一連の試行錯誤の最中でも
Couchbase Serverは稼働しており、
システム全体には影響を与えない。
39

管理コンソール - 監視
優秀な管理コンソールが標準で使用可能で、何も設定し
なくてもクラスタの状態を監視してくれる。
40
IPアドレス

管理コンソール - アラート
41
アラートの設定も可能。
2.1.1 2.5 当社
監視レスポンス 30秒 120秒 150秒
Couchbase Server 2.1.1では監視レスポンス30秒と短
いため150秒に設定。

Couchbase Serverの特長
? ドキュメント指向
? 高パフォーマンス
? 自動シャーディング
? 高スケーラビリティ
42

今後の展望
Couchbase Mobileというモバイルソリューションを活用し
てゲームアプリのリソース管理ができないか検討中。
43

今後の展望
Couchbase Mobileを使用することの利点
? データの同期が簡単に可能なため、開発工数の減少が
期待できる
? オフライン（圏外）でもオンラインと同じ動作が可能
? サーバが特定の環境に依存しない
? アプリサイドの豊富なプラグイン
アプリ開発者にとって夢のようなソリューション
44

要望
? Couchbase ServerにSQLライクな文法で問い合わせ
ができるN1QL(ニッケル)という言語を早く使いたい
? リバランスの予想時間が表示されると嬉しい
? 管理コンソール上の監視で期間を指定?
してグラフを見たい
45

46
明日15:00 からもCouchbase Server?
「Couchbase Server 3.0で広がるNoSQL採用事例」

47
Couchbase MeetUP Tokyo - #11
- Couchbase モバイルハッカソンのアプリ発表会-
2014/11/19 （水） 19:30~21:30
会場: 株式会社サイバード
http://couchbasejpcommunity.doorkeeper.jp/
events/16749

48
極めて安定しており素晴らしいプロダクトです。

狠狠撸

db tech showcase 東京 2014 - Couchbase Serverを用いた大規模データ収集基盤

More Related Content

db tech showcase 東京 2014 - Couchbase Serverを用いた大規模データ収集基盤