エアロスパイクVS。 Redis、ケーススタディ
Aerospike Vs Redis Case Studies
エアロスパイクVS。 Redis、ケーススタディ
中国のRedis成熟したコミュニティであり、ほとんどがRedisを多かれ少なかれ使用していますが、KVデータベースがあれば、読み取りと書き込みの速度が速くなり、セキュリティの信頼性が向上し、セキュリティが低下するため、Redisには多くの要望があります。総所有コスト、Aerospikeを見てみませんか？
今日は私たちの顧客からの事例をあなたと共有したいと思います旅行の聴衆！
「トラベルオーディエンス」はデジタル広告プラットフォームであり、これは私たちが世界中の広告に多額の投資を続けることを意味します。この記事では、私たちのセクターの入札が直面しているいくつかの課題について説明したいと思います。
入札者はオークションに参加し、ページ広告スロットのリアルタイム環境に参加しました。入札リクエストについては毎秒60〜70kであり、各リクエストの処理時間は75ミリ秒未満である必要があります。システムの高負荷を処理するために、バックグラウンドでメモリ内のPostgres更新データを使用し、Redisでリアルタイムデータを使用しています。 （一般的に使用されるデータベーステクノロジー企業には、Postgres、MySQL、キャッシングソリューションなどのRDBMSが含まれます。）
SSP（Supply Side Platform）からの各リクエストは、複数のキャッシュされたクエリになります。スループット（1秒あたりのトランザクション数）と遅延（応答時間）は重要な指標であり、このキャッシュはRTBアプリケーションのニーズを満たす必要があります。
時間の経過とともに、ユーザー数を増やすキャンペーンの数も増加し、広告予算も増加しています。そのため、システムを拡張するためには、負荷に応じて柔軟性を維持する必要があります。
チャレンジ
異なるポートで複数のデータベース（5〜6）を実行するRedis Redisバッファー層では、各データベースにマスターノードとスレーブノードが約10個あります。最初から、Redisを使用するときに問題が増えることに気づきました。これは私たちが直面する問題のいくつかです：
・マスターデバイス、マスターノードによって実行されるサーバーのスループットを制限するための-'書き込み'からの複数のデバイス。
・Redisはシングルスレッドです。つまり、CPUに関して垂直方向のスケーラビリティはありません。
リアルタイムのマスタースレーブ同期の問題-プライマリノードでの多数の書き込み操作の結果として、すべての変更をノードと同期する必要があります。大量のデータは同期できないため、オフラインノードに起因するアプリケーションプログラムRTBからの読み取り要求に同時にデータを供給するため、同期する必要があります。
•同じデータベースにさまざまな種類のデータを保存する便利な方法はありません。さまざまなエンティティがさまざまなRedisインスタンス（インスタンス）に保存されているため、さまざまなポートで複数の接続を処理する必要があります。
解決
柔軟性と使いやすさを維持しながら、すべてのニーズを満たすソリューションを見つけようとしています。
徹底的な調査の結果、Aerospikeが私たちのニーズを本当に満たすことができることを深く理解しています。前の仕事でAerospikeを使用した経験があります。そこで、このプロジェクトでAerospikeの使用を開始しました。
Aerospikeの利点は次のとおりです。
・パーティション-デフォルトでは、クラスター内のすべてのノードに分散された4096のパーティションがあります。これは、スループットが大幅に向上した「書き込み」を行うためのものです。
・Aerospikeはマルチスレッドであり、リソースを最も効果的に使用できます。
・マスターコピーの同期ダウンタイムなし-「書き込み」ルール（ポリシー）を構成できます。「書き込み」要求を作成するために確認し、コピーで「完了」と見なされます。
・名前空間-すべての異なるタイプのデータは、同じクラスターの異なる名前空間に格納できます。この階層は、名前空間>セット>レコードです。
・SSDまたはメモリストレージ-Aerospikeには、SSDとメモリの2つのモードがあります。 Redisはメモリ内でのみ使用されるため、大幅な拡張は非常に高価になりますが、AerospikeはSSDストレージを使用してパフォーマンスの競争力を提供します。
ベンチマーク
私はRedisとAerospikeを比較してテストしました。まず、スループットは最も重要なパラメーターです。これは、入札者から1秒あたり数十万のリクエストがあるためです。
私は16vCPUと14.4GBのメモリを備えた仮想マシンを作成しました（ほとんどの旅行オーディエンスインフラストラクチャはGoogle Cloud Platformでホストされています）。そこで彼はRedisをセットアップし、AerospikeはGCEでDebian9を使用しました。
次のリンクに従って、Aerospikeとベンチマークを設定しました。
Debianにインストールする
このチュートリアルでは、DebianシステムへのAerospikeのインストールについて説明します。
https://www.aerospike.com/docs/operations/install/linux/debian/
ベンチマーク
Aerospike Goクライアントベンチマークツールを使用して、Aerospikeクラスターに負荷を生成し、パフォーマンスメトリックを計算します。
https://www.aerospike.com/docs/client/go/benchmarks.html
すべてのRTBアプリケーションはGoで記述されているため、Goベンチマークもダウンロードしました。
これは、Redisをインストールするためのリンクです。
Redisクイックスタート-Redis
Redisには動作する以外の依存関係がないため、Redisをインストールするための推奨される方法は、ソースからコンパイルすることです…
https://redis.io/topics/quickstart
次に、redis-serverを実行したところ、redis-benchmarkツールを使用できます。
参照をそれぞれ「書き込み」と「読み取り」で実行することにしました。ベンチマークの書き込み/読み取り1,000,000行、8バイトの書き込み値（Int64）、および50の同時クライアント接続。
「書き込み」ベンチマーク：
Redis：
redis-benchmark -t set -n 1000000 -d 8 -c 50
====== SET ======
1000000件のリクエストが7.66秒で完了しました
50の並列クライアント
8バイトのペイロード
生き続ける：1
99.92％<= 1 milliseconds
100.00％<= 2 milliseconds
100.00％<= 2 milliseconds
1秒あたり130497.20リクエスト
Aerospike：
./benchmark -w I -c 50
2018/01/17 14:05:33使用するCPU数の設定：16
2018/01/17 14:05:33ベンチマーク.go：181：ホスト：127.0.0.1
2018/01/17 14:05:33ベンチマーク.go：182：ポート：3000
2018/01/17 14:05:33ベンチマーク.go：183：名前空間：テスト
2018/01/17 14:05:33ベンチマーク.go：184：セット：テストセット
2018/01/17 14:05:33ベンチマーク.go：185：キー/レコード：1000000
2018/01/17 14:05:33ベンチマーク.go：186：オブジェクト仕様：I、サイズ：0
2018/01/17 14:05:33ベンチマーク.go：187：ランダムなビン値がfalse
2018/01/17 14:05:33ベンチマーク.go：188：ワークロード：レコードの100％を初期化します
2018/01/17 14:05:33ベンチマーク.go：189：同時実行性：50
2018/01/17 14:05:33ベンチマーク.go：190：最大スループット無制限
2018/01/17 14:05:33ベンチマーク.go：191：タイムアウト0ミリ秒
2018/01/17 14:05:33ベンチマーク.go：192：最大再試行回数2
2018/01/17 14:05:33ベンチマーク.go：193：デバッグ：false
2018/01/17 14:05:33ベンチマーク.go：194：レイテンシ：0：0
2018/01/17 14:05:33ベンチマーク.go：137：見つかったノード：[BB90512440A0142]
2018/01/17 14:05:34ベンチマーク.go：712：書き込み（tps = 436881タイムアウト= 0エラー= 0 totalCount = 436881）
2018/01/17 14:05:35ベンチマーク.go：712：書き込み（tps = 442889タイムアウト= 0エラー= 0 totalCount = 879770）
2018/01/17 14:05:36ベンチマーク.go：712：書き込み（tps = 120230タイムアウト= 0エラー= 0 totalCount = 1000000）
「読み取り」ベンチマーク：
Redis：
redis-benchmark -t get -n 1000000 -d 8 -c 50
====== GET ======
7.47秒で1000000件のリクエストが完了しました
50の並列クライアント
8バイトのペイロード
生き続ける：1
99.90％<= 1 milliseconds
100.00％<= 1 milliseconds
1秒あたり133850.89リクエスト
・Aerospike：
・./benchmark -w RU：100 -c 50
・2018/01/17 14:03:55使用するCPU数の設定：16
・2018/01/17 14:03:55ベンチマーク.go：181：ホスト：127.0.0.1
・2018/01/17 14:03:55ベンチマーク.go：182：ポート：3000
・2018/01/17 14:03:55ベンチマーク.go：183：名前空間：テスト
・2018/01/17 14:03:55ベンチマーク.go：184：セット：テストセット
・2018/01/17 14:03:55ベンチマーク.go：185：キー/レコード：1000000
・2018/01/17 14:03:55ベンチマーク.go：186：オブジェクト仕様：I、サイズ：0
・2018/01/17 14:03:55ベンチマーク.go：187：ランダムなビン値がfalse
・2018/01/17 14:03:55ベンチマーク.go：188：ワークロード：読み取り100％、書き込み0％
・2018/01/17 14:03:55ベンチマーク.go：189：同時実行性：50
・2018/01/17 14:03:55ベンチマーク.go：190：最大スループット無制限
・2018/01/17 14：03：55benchmark.go：191：タイムアウト0ミリ秒
・2018/01/17 14:03:55ベンチマーク.go：192：最大再試行回数2
・2018/01/17 14:03:55ベンチマーク.go：193：デバッグ：false
・2018/01/17 14:03:55ベンチマーク.go：194：レイテンシ：0：0
・2018/01/17 14:03:55ベンチマーク.go：137：見つかったノード：[BB90512440A0142]
・2018/01/17 14:03:57ベンチマーク.go：717：書き込み（tps = 0タイムアウト= 0エラー= 0）読み取り（tps = 446765タイムアウト= 0エラー= 0）合計（tps = 446765タイムアウト= 0エラー= 0、カウント= 446765）
・2018/01/17 14:03:58ベンチマーク.go：717：書き込み（tps = 0タイムアウト= 0エラー= 0）読み取り（tps = 503307タイムアウト= 0エラー= 0）合計（tps = 503307タイムアウト= 0エラー= 0、カウント= 950072）
・2018/01/17 14:03:59ベンチマーク.go：717：書き込み（tps = 0タイムアウト= 0エラー= 0）読み取り（tps = 487852タイムアウト= 0エラー= 0）合計（tps = 487852タイムアウト= 0エラー= 0、カウント= 1437924）
ベンチマークの読み取りと書き込みから、Redis TPS（1秒あたりのトランザクション数）とAerospikeTPSの間に大きなギャップがあることがわかります。
Aerospike 1秒あたり430,000の書き込み操作、および1秒あたり130,000の書き込み操作Redis
と
Aerospikeは1秒あたり480,000回、1秒あたり133,000回を読み取り、Redisを読み取りました。
クラスターのセットアップ
Aerospikeを引き続き使用することを決定し、GCEに3つのノードのクラスターをセットアップしました。レプリケーション係数は2で、最も一般的に使用されるリアルタイムデータの一部をRedisからAerospikeに切り替えました。
各名前空間は、パーティション化されていないSSDディスクを持つように構成されており、「data-in-memory」（メモリ内のデータ）パラメーターは「true」に設定されています。したがって、ノードが実質的に起動すると、ノードはすぐにすべてのデータをメモリにロードし、要求の処理を開始します。この配置により、より高速な開始ノードが可能になり、データが提供されます（Aerospikeメカニズムには、記録時に最初に取得するだけの独自のメモリ内データキャッシュメモリがありますが、記録はSSDからフェッチされ、その後の使用要求のためにメモリに常駐します）。
クラスターのステータスをよりよく理解できるように、PrometheusインジケーターとAerospike管理コンソールを使用しました。
ノード上のすべてのハードウェア/ソフトウェアのアップグレードは、次々にノードを切り替えることで簡単に完了できます。つまり、ノードをアップグレードまたは削除/追加するときに、データの移行を待つだけで、バランスをとることができます。他のすべての作業を担当するAerospikeクラスター。
欠点
Aerospikeによってもたらされる利点（Redisと比較して）に加えて、欠点についても言及する必要があります。
・行数を制限する-各名前空間の各ノードの行数は40億行に制限されているため、使用できるようになりました。制限の完全なリストについては、ここで見つけることができます：
Https://www.aerospike.com/docs/guide/limitations.html
・トランザクションをサポートしていません-特定の状況では、設計上の問題がさらに発生する可能性があります。GooglePubSubメッセージキューのエンティティを処理する必要があります（メッセージキューはメッセージシーケンスを保証するものではありません）。メッセージを処理して、Aerospikeのバージョンに保存する必要があります。したがって、各エンティティを保存するために、Aerospikeで何度も書き込みました。一般に、このような高性能データベースAerospikeの支払いにかかるコストを使用したACIDトランザクションのサポートの欠如（トランザクションデータベースはすぐにはありません）。言い換えれば、世代のエアロスパイクは良い妥協点です。 （注：Aerospikeは、強力な一貫性、一貫性、および強力なサポートをサポートするようになりました。ユーザーのシェアのさまざまな部分にクラスターを分散することで、Aerospikeを使用するメリットがさらに高まります。）
・不安定なクライアントライブラリに移動する-Aerospike Goクライアントは時々Goルーチンを2〜3倍生成しますが、これらのルーチンは停滞したままです。これは、彼らがより多くのメモリを消費し、決してそれを解放しないことを意味します。 （注：新しいバージョンのAerospikeも問題を解決しました）
結論として
Aerospikeを使用すると、データ管理が簡単になります。クラスターの3つのノードであるRedisAerospikeのデータベース5にデータを保存できます。
Goアプリケーションプロセスは、必要なすべてのデータをクエリするためのAerospike接続のみになりました。
平均持続時間320マイクロ秒を要求し、RTBバッファーの要件を完全に満たします（Redisと非常によく似ています）。
インフラストラクチャの拡張がより簡単になりました。まず、GCEで新しいノードを生成するテラフォームプロジェクトを使用します。次に、KubernetesがHelmChartsを使用するようにデプロイします。これで、1つのコマンドを使用して新しいクラスターを作成するのと同じくらい簡単にHelmChartsを実行できます。
読んでくれてありがとう！