Aerospikeを導入してみた話 ～ 他KVSとの違いアレコレ ～

1

株式会社インティメート・マージャー　松田和樹

自己紹介

松田 和樹

株式会社インティメート・マージャー（社員数９名）

開発本部

• パブリックDMP「AudienceSearch」の開発

• 主にインフラ周りを担当

2

アジェンダ

• IMでの使われ方（導入事例）

• 導入時に検討した他のKVS

• 導入して気づいたこと

3

IMでの使われ方

4

IMでの使われ方

• IDSyncサービス

• 自社IDと他社IDのマッピングテーブルのホスティング

• 属性データの加工

• 様々なデータソースからの更新とジョイン

5

IDSyncサービス

6

IDSyncサービス

IDSyncサービスとは

• 自社IDと他社IDのマッピングテーブルを生成、保持

• APIから更新、参照を行うことが可能

• 現在、50社以上のパートナーとID連携

7

IDSyncサービス

連携パートナー（一部）

8

例：アンケートで特定の回答をした人に広告配信

IDSyncサービス

IMIDアンケートパネルID DoubleClick ID

例：自社サイト（アプリ）に訪れた人にメール広告を配信

9

IMID1st Party Cookie （IDFA）

E-mail

IDSyncサービス

ELB

API

Aerospike

システム

• フロントは ELB + Nginx + uWSGI

• バックエンドにAerospikeを採用

• 平均応答速度は1ms

• ピーク時で1000req/s程度

10

IDSyncサービス

応答速度（ELB）

11

IDSyncサービス

• 主キーが自社ID、他社IDそれぞれのテーブルを生成

ELB

API

{A社: hoge}

A社 IM

hoge 1001

piyo 1002

IM A社

1001 hoge

1002 piyo

Aerospike

Set: A_to_IM Set: IM_to_A

※ Set: RDBMSのテーブルにあたる

12

属性データの加工

13

属性データの加工

14

Join Server

• 様々な属性情報を、異なるソースから取得 • IMで保持している属性情報を人が利用できる形に加工する基板にAerospikeを採用

• 加工したデータは検索エンジンから利用

属性データの加工

Cookie IDを主キーに様々な属性情報を保持

• 閲覧履歴に基づく「キーワード」

• 各メディアより提供される「セグメント」

• 「User Agent」

• アクセス元IPに基づく「住所」や「企業情報」

• etc…

15

属性データの加工

様々な属性情報を個別のSetで保持 それぞれ独立して更新を行うことが可能

ID セグメント

1001 234, 542

1002 2, 34, 112

ID アクセス元IP

1001 73.53.54.122

1002 59.3.66.32

ID ユーザーエージェント

1001 Mac Safari

1002 Win7 Chrome

IP 都道府県

73.53.54.122 東京都

59.3.66.32 北海道

IP 企業

73.53.54.122 IM

59.3.66.32 -

ID キーワード

1001 沖縄旅行

1002 引っ越し

Set: segmentSet: ua Set: keywords

Set: ip Set: address Set: company

16

属性データの加工

様々な属性情報を個別のSetで保持 それぞれ独立して更新を行うことが可能

ID アクセス元IP

1001 73.53.54.122

1002 59.3.66.32

ID ユーザーエージェント

1001 Mac Safari

1002 Win7 Chrome

Set: ua

Set: ip

17

アクセスログ

属性データの加工

様々な属性情報を個別のSetで保持 それぞれ独立して更新を行うことが可能

IP 都道府県

73.53.54.122 東京都

59.3.66.32 北海道

IP 企業

73.53.54.122 IM

59.3.66.32 -

Set: address Set: company

18

サイバーエリアリサーチ株式会社

属性データの加工

様々な属性情報を個別のSetで保持 それぞれ独立して更新を行うことが可能

ID キーワード

1001 沖縄旅行

1002 引っ越し

Set: keywords

19

提携メディア

属性データの加工

ジョインして検索エンジンに投入して活用

ID セグメント ユーザーエージェント キーワード 都道府県 企業

1001 234, 542 Mac Safari 沖縄旅行 東京都 IM

1002 2, 34, 112 Win7 Chrome 引っ越し 北海道 -

20

Join Server

導入時に検討した他のKVS

21

他のKVSとの比較検討

• DynamoDB (AWS)

• Redis

• Cloud Bigtable (Google) ※ 検討時、未リリース

22

DynamoDB (AWS)

• 費用が高い（非リザーブド）

• 10万read/sで、130万円/月

• 10万write/sで、650万円/月

• キャパシティを超えたリクエストはロストする

• 通常は手前でキューイングして対応するらしい

23

Redis (ElastiCache)

用途ごとにRedisを分けて、複数台並べることを想定

• 容量制限あり（最大で240GB）

• 到達した場合に代替手段がない

• 都度構築が必要になり、スケールしない

• 50社とID連携するのに50インスタンス必要

24

Cloud Bigtable (Google)

• 他のサーバもGoogle Cloud Platformに移さないと、ネットワークレイテンシが発生する

• 応答速度が対Aerospike比で約10倍（らしい）

• Aerospike: 1ms以下

• Cloud Bigtable: 5～10ms

25

導入して気づいたこと

26

Clientが高機能

• レコードがどのノードに配置されているか把握している

• 主キーのハッシュ値を利用

• コネクション確立時に、マッピングテーブルを取得する

• マッピングテーブルは、ノードの追加や削除時に再計算される

Client

27

Clientもパワーが必要

• Aerospikeのパフォーマンスを出し切るには、高多重度でリクエストを行うことが必要

• 1リクエスト1msで3.6億レコード取り出す場合

36万秒 = 6000分 = 100時間

• IMでは16～32coreのサーバを用い、数百多重で処理を回しています

28

意外とメモリの使用量が大きい

SSDのみの利用でも意外とメモリを使用する

• インデックスがメモリ展開される

• 1レコードにつき６４バイト

AWSではメモリとSSDの比率がほぼ固定なので、一部インメモリのNamespaceを使い、リソースの無駄を無くしました。

29

Namespaceは分割しにくい

• RDBMSでいうデータベース

• SSDを使用する場合、ブロックデバイス単位でしかNamespaceを分けることが出来ない

• インメモリの場合は自由に分割可能

30

Queryの制約

SQLライクな記述でレコードを参照することも可能

• 指定したサーバで処理が走る

（クライアント側ではない）

• 並列実行が出来ない

• 指定するサーバを変えあれば実行可

• バックアップもQuery扱い

31

Client

×

バックアップ

• mysqldumpの様なコマンドがある

• ほぼ平文なので、データ量が大きい

• 取得、復元に時間が掛かる

• Query扱いなので、実行ノードに注意（前述）

32

その他　雑感

• インメモリだと特に速い（比較してないけど）

• 設定項目がほぼ無いので、構築が楽

（逆にブラックボックスでもありますが。。）

• ドキュメントに無い機能がライブラリにある

（ソースコードを見ましょう！）

• リソースの見積が難しく、想定より高くなる。。

33

まとめ（これから始める方へ）

• 本当にAerospikeが必要なケースはあまり多くなさそう。 ＜マッチしそうなケース＞

• データ量の見積が難しい場合（事業のスケールなど） • 時間あたりのリクエスト数が膨大な場合

• Javascript経由で不特定多数からAPIをコールされる

• バッチ処理などで瞬間的に負荷をかける（億件単位のジョイン）

• サーバ、クライアント共に必要とされるリソースの見積が難しいので、クラウド環境で試してみることをオススメします。

• Queryをメインにサービスを設計してはいけない。

34

エンジニア募集

最新の技術に興味のある新メンバーを募集中です！

採用技術 開発基盤

35

ありがとうございました

36