UZOUにおけるAerospike

2023.6.7 Aerospike セミナーにおける登壇資料

Transcript

1. UZOUにおけるAerospike
2. 自己紹介 Toyohito Murooka 室岡 豊人 株式会社SpeeeにてUZOUという広告配信システムの開発に従事 https://twitter.com/muroon01 https://github.com/muroon
3. UZOUとは • メディアに関連する記事や広告を配信するネイティブアド配信プラットフォーム • 2016年からサービスを開始しており7年目のプロダクト(Aerospikeの使用は2017年〜)
4. UZOの全体構成図
5. 配信サーバーからのアクセス • 事前にデータ更新しておいてランタイム処 理のリソースアクセスはオンメモリと KVSへ のReadのみ ◦ オンメモリ(DBから定期的に取得) ◦ KVS(都度KVSから取得可能) • Write処理は非同期で実施
6. Aerospikeに保存している主な内容 • コンバージョン情報 • 広告・記事などの配信候補の情報 • 広告に関する情報(予算・CPCなど) • 配信制御部分 なぜオンメモリではないのか？ • 上記の情報は更新後にすぐに取得できるように配信サーバーから都度取得する必要があるためKVSを使用 • オンメモリデータは一定時間間隔でDBから取得することになる(数百万TPS環境下では差分が大きい)
7. 必要な性能と役割 性能 • read, writeともに数百万TPS以上 UZOUにおけるAerospikeの役割 • クラスタ型KVS • Data型としてはSetsのみ
8. なぜAerospike? リリース当初はDynamoDBを使用していたが、下記の問題点が発生 • DynamoDBを使用していて、Write性能、Read性能が低いことにより、UZOUのデータ量だとコスト（金銭的、処理的）が高く なってしまう • 局所的にスループット出したい場面で辛くなってきている ◦ DynamoDB Accelerator (DAX)によりスループットの上では改善することも可能 ◦ ただしコストパフォーマンスに難あり • UZOUのデータ構造を扱うにはクエリの柔軟性が低い ◦ キーベースで取り出すのが厳しい ◦ UZOUのアプリデータのつくり上ではupdateしづらい ◦ 集計がない ◦ 10GBの隠れパーティション ▪ パーティションサイズを10GB以内にしなければならない • キーに対してアプリケーション側で手を加える必要がある • VPCの外にあるので、ネットワークレイテンシーの影響を受けやすい • プロトコルがhttp(もしくはhttps)のためコストが高い ※注意) • あくまでUZOUのデータ構造を扱う上での見解です • 2017年当時の見解ですので変わっている可能性があります
9. 別のKVSを検討 AerospikeかRedis Clusterを検討 Aerospike Redis Cluster スケーリング 自動フェイルオーバー、自動データバランシングなどの機能を 持っており、ホリゾンタルスケーリングが容易。また、 Aerospikeは データをメモリとSSDの両方に保存できるため、大容量のデータ を扱うことが可能。 ホリゾンタルスケーリングが可能で、データは複数のノード間で自 動的に分散される。ただし、データは主にメモリに保存されるた め、大容量のデータを扱う際にはメモリコストが高くなる。 レイテンシ メモリとSSDの両方でデータを保存でき、 SSDを使用した場合で も非常に高速な読み書き性能を発揮する。また、強力なインデッ クス機能を持っており、高速な検索が可能。 基本的にメモリ上でデータを扱うため、非常に低いレイテンシで高 速な読み書きが可能。ただし、データがメモリに収まらない場合、 パフォーマンスが低下することがある。 コストパフォーマンス メモリとSSDの両方でデータを保存できるため、データ量に応じて コストを抑えることが可能。 データがメモリに収まらない場合、コストが高くなることがある。
10. 別のKVSを検討 最終的にはAerospikeを選択 • メモリとSSDの両方を使用するところが、Redisに比べてメモリ効率が良く、結果コストパフォーマンスが良い • オートシェーディング対応がされている
11. パフォーマンス • CPU ◦ 45% • メモリ ◦ 50% • Read ◦ 47000 TPS • Write ◦ 42000 TPS • レイテンシ ◦ Read: 1ms以下 ◦ Write: 1ms以下
12. インフラ構成詳細 • EC2上にインストールしている • rolling updateではなく新インスタンス追加&旧インスタンス破棄方式 • 独自のUser-Defined Functionsの利用 • 予めconfigファイルも含みAMIを作成しておき、インスタンス作成時に利用 ◦ ノードの追加時も作成済みのAMIを使用する • service_threadsは5×CPUコア数
13. User-Defined Functions (UDFs) • データローカリティ ◦ UDFsはサーバー側で実行されるため、ネットワークを介さずに処理が可能。データ処理が高速化され、ネットワークト ラフィックが軽減される。 • 原子性 ◦ UDFsはレコードレベルでトランザクションを保証し、データの一貫性を確保する。つまり、UDFは全ての操作が成功す るか、または全く操作が行われないかのいずれか。 • 柔軟性 ◦ UDFsはカスタムビジネスロジックを適用でき、通常のデータベース操作では実現できない複雑な操作を可能にする。 UZOUでは広告グループ内の予算データをインクリメントするのにレコードUDFsを使用している
14. モニタリング項目とアラート発生時の対応 • メモリ使用量が80%を超える場合はノードを追加する、逆に60%を下回るようならノードを削除する • ディスクやCPUなどのアラートを仕掛けているが、基本的に鳴ったことはない（メモリの使用量を起因としてスケールアウトし ているから） ◦ アラート鳴るレベルで負荷が増えてるのならノードを追加する対応を行う
15. 実績 • 導入からAerospike起因の障害もなく運用できている
16. 今後の展望 • バージョンアップ • マルチAZ対応 • Arm対応 • Graviton2と合わせた使用の検討 a. コストパフォーマンス向上との報告がある b. https://aerospike.com/news/press-release/database-6-on-aws-graviton2/