Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
UZOUにおけるAerospike
Search
muroon
June 08, 2023
Technology
0
230
UZOUにおけるAerospike
2023.6.7 Aerospike セミナーにおける登壇資料
muroon
June 08, 2023
Tweet
Share
More Decks by muroon
See All by muroon
GCにおけるパフォーマンス改善
muroon
0
760
go-athenaの大量データ取得を速くした方法
muroon
1
360
Goの静的解析を使用してAPI Doc Linterをつくる
muroon
0
65
Cloude Spannerの主キーの設計
muroon
0
47
Other Decks in Technology
See All in Technology
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
420
おやつは300円まで!の最適化を模索してみた
techtekt
PRO
0
250
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
4
990
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
340
現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある / Team-oriented Organization Design 20250827
mtx2s
7
69k
DuckDB-Wasmを使って ブラウザ上でRDBMSを動かす
hacusk
1
140
Nstockの一人目エンジニアが 3年間かけて向き合ってきた セキュリティのこととこれから〜あれから半年〜
yo41sawada
0
110
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
970
『FailNet~やらかし共有SNS~』エレベーターピッチ
yokomachi
1
190
シークレット管理だけじゃない!HashiCorp Vault でデータ暗号化をしよう / Beyond Secret Management! Let's Encrypt Data with HashiCorp Vault
nnstt1
2
130
Webアクセシビリティ入門
recruitengineers
PRO
3
1.4k
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
430
Featured
See All Featured
For a Future-Friendly Web
brad_frost
179
9.9k
KATA
mclloyd
32
14k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Automating Front-end Workflow
addyosmani
1370
200k
Agile that works and the tools we love
rasmusluckow
330
21k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Designing for humans not robots
tammielis
253
25k
Side Projects
sachag
455
43k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Transcript
UZOUにおけるAerospike
自己紹介 Toyohito Murooka 室岡 豊人 株式会社SpeeeにてUZOUという広告配信システムの開発に従事 https://twitter.com/muroon01 https://github.com/muroon
UZOUとは • メディアに関連する記事や広告を配信するネイティブアド配信プラットフォーム • 2016年からサービスを開始しており7年目のプロダクト(Aerospikeの使用は2017年〜)
UZOの全体構成図
配信サーバーからのアクセス • 事前にデータ更新しておいてランタイム処 理のリソースアクセスはオンメモリと KVSへ のReadのみ ◦ オンメモリ(DBから定期的に取得) ◦ KVS(都度KVSから取得可能)
• Write処理は非同期で実施
Aerospikeに保存している主な内容 • コンバージョン情報 • 広告・記事などの配信候補の情報 • 広告に関する情報(予算・CPCなど) • 配信制御部分 なぜオンメモリではないのか?
• 上記の情報は更新後にすぐに取得できるように配信サーバーから都度取得する必要があるためKVSを使用 • オンメモリデータは一定時間間隔でDBから取得することになる(数百万TPS環境下では差分が大きい)
必要な性能と役割 性能 • read, writeともに数百万TPS以上 UZOUにおけるAerospikeの役割 • クラスタ型KVS • Data型としてはSetsのみ
なぜAerospike? リリース当初はDynamoDBを使用していたが、下記の問題点が発生 • DynamoDBを使用していて、Write性能、Read性能が低いことにより、UZOUのデータ量だとコスト(金銭的、処理的)が高く なってしまう • 局所的にスループット出したい場面で辛くなってきている ◦ DynamoDB Accelerator
(DAX)によりスループットの上では改善することも可能 ◦ ただしコストパフォーマンスに難あり • UZOUのデータ構造を扱うにはクエリの柔軟性が低い ◦ キーベースで取り出すのが厳しい ◦ UZOUのアプリデータのつくり上ではupdateしづらい ◦ 集計がない ◦ 10GBの隠れパーティション ▪ パーティションサイズを10GB以内にしなければならない • キーに対してアプリケーション側で手を加える必要がある • VPCの外にあるので、ネットワークレイテンシーの影響を受けやすい • プロトコルがhttp(もしくはhttps)のためコストが高い ※注意) • あくまでUZOUのデータ構造を扱う上での見解です • 2017年当時の見解ですので変わっている可能性があります
別のKVSを検討 AerospikeかRedis Clusterを検討 Aerospike Redis Cluster スケーリング 自動フェイルオーバー、自動データバランシングなどの機能を 持っており、ホリゾンタルスケーリングが容易。また、 Aerospikeは
データをメモリとSSDの両方に保存できるため、大容量のデータ を扱うことが可能。 ホリゾンタルスケーリングが可能で、データは複数のノード間で自 動的に分散される。ただし、データは主にメモリに保存されるた め、大容量のデータを扱う際にはメモリコストが高くなる。 レイテンシ メモリとSSDの両方でデータを保存でき、 SSDを使用した場合で も非常に高速な読み書き性能を発揮する。また、強力なインデッ クス機能を持っており、高速な検索が可能。 基本的にメモリ上でデータを扱うため、非常に低いレイテンシで高 速な読み書きが可能。ただし、データがメモリに収まらない場合、 パフォーマンスが低下することがある。 コストパフォーマンス メモリとSSDの両方でデータを保存できるため、データ量に応じて コストを抑えることが可能。 データがメモリに収まらない場合、コストが高くなることがある。
別のKVSを検討 最終的にはAerospikeを選択 • メモリとSSDの両方を使用するところが、Redisに比べてメモリ効率が良く、結果コストパフォーマンスが良い • オートシェーディング対応がされている
パフォーマンス • CPU ◦ 45% • メモリ ◦ 50% •
Read ◦ 47000 TPS • Write ◦ 42000 TPS • レイテンシ ◦ Read: 1ms以下 ◦ Write: 1ms以下
インフラ構成詳細 • EC2上にインストールしている • rolling updateではなく新インスタンス追加&旧インスタンス破棄方式 • 独自のUser-Defined Functionsの利用 •
予めconfigファイルも含みAMIを作成しておき、インスタンス作成時に利用 ◦ ノードの追加時も作成済みのAMIを使用する • service_threadsは5×CPUコア数
User-Defined Functions (UDFs) • データローカリティ ◦ UDFsはサーバー側で実行されるため、ネットワークを介さずに処理が可能。データ処理が高速化され、ネットワークト ラフィックが軽減される。 • 原子性
◦ UDFsはレコードレベルでトランザクションを保証し、データの一貫性を確保する。つまり、UDFは全ての操作が成功す るか、または全く操作が行われないかのいずれか。 • 柔軟性 ◦ UDFsはカスタムビジネスロジックを適用でき、通常のデータベース操作では実現できない複雑な操作を可能にする。 UZOUでは広告グループ内の予算データをインクリメントするのにレコードUDFsを使用している
モニタリング項目とアラート発生時の対応 • メモリ使用量が80%を超える場合はノードを追加する、逆に60%を下回るようならノードを削除する • ディスクやCPUなどのアラートを仕掛けているが、基本的に鳴ったことはない(メモリの使用量を起因としてスケールアウトし ているから) ◦ アラート鳴るレベルで負荷が増えてるのならノードを追加する対応を行う
実績 • 導入からAerospike起因の障害もなく運用できている
今後の展望 • バージョンアップ • マルチAZ対応 • Arm対応 • Graviton2と合わせた使用の検討 a.
コストパフォーマンス向上との報告がある b. https://aerospike.com/news/press-release/database-6-on-aws-graviton2/