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

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エンジニア

• [email protected]

2

mailto:[email protected]


会社紹介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

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を採用。


vBucket22

ハッシュ値ノード

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によるset24

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

http://couchbasejpcommunity.doorkeeper.jp/events/16749


48

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

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

Technology