Aerospikeを導入してみた話 ~ 他KVSとの違いアレコレ ~
1
株式会社インティメート・マージャー 松田和樹
自己紹介
松田 和樹
株式会社インティメート・マージャー(社員数9名)
開発本部
• パブリック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)
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レコードにつき64バイト
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