|
著者について patpatbearはCtripのソフトウェア技術エキスパートであり、Ctripのキャッシュカーネルのメンテナンスを担当しています。オープンソースに情熱を注ぎ、高性能な分散NoSQLシステムの構築と応用に注力しています。 I. 背景Redisはメモリをストレージ媒体として使用し、優れたパフォーマンスと低レイテンシを実現します。しかし、メモリ容量がボトルネックとなることが多く、メモリ価格の高さがRedisの利用コスト増加につながります。 SSDディスク性能の継続的な向上により、NVMe SSDのランダム読み取り・書き込みレイテンシはわずか数十マイクロ秒となり、Redisの固有レイテンシ（100～200マイクロ秒）に匹敵します。SSDをストレージメディアとして使用することで、コストを抑えながら低レイテンシを実現できます。 そこで当社は、Redis カーネルを強化してホットとコールドのデータ交換をサポートし、ディスクを使用してキャッシュ容量を拡張し、コストを約 2/3 削減しながらパフォーマンスでほとんどのビジネス ニーズを満たすことができる ROR (Redis-On-Rocks) 製品を開発しました。 II. RORの紹介ROR の核となる考え方はシンプルです。Redis コードベースに基づいてコールドおよびホット スワップ機能を拡張し、Redis データのマルチレベルのコールドおよびホット ストレージを実現して、キャッシュの使用にかかる全体的なコストを削減します。 ROR はデータをホット部分とコールド部分に分割します。
ROR はホット データとコールド データの交換を担当します。
ROR は Redis のデータ構造とコマンド実装を継承し、コールドおよびホット データの交換のみを担当するため、ほぼすべての Redis コマンドと互換性があり、公式 Redis ドキュメントの新機能にすぐに対応できます。 III. RoFとの比較長期的な開発の観点から見ると、Redisは事実上のキャッシュ標準です。キャッシュカーネルはコミュニティソースのRedisをベースにしているため、Redisの進化に追従しやすくなっています。そのため、RORはRedisをベースにコールドスワップとホットスワップの機能を拡張することを選択しました。 RedisLabs の商用製品 Redis-on-Flash (RoF) は設計が ROR に似ていますが、調査の結果、RoF はコスト、汎用性、パフォーマンスの面でニーズを満たすことができないことがわかりました。 3.1 コスト RoF は、値をディスクに保存し、キーをメイン テーブルのメモリに保存します。これにより、dbsize、scan、randomkey などのコマンドを簡単にサポートできますが、使用するメモリの量は dbsize に比例して増加します。 コールドデータのキーはメモリ内のハッシュテーブルに格納されます。各キーの補助ポインタ（robjなど）は平均約50バイトを占有しますが、生成される文字列値の平均サイズは512バイトです。コストの観点から、キーがメモリの10%、値が90%を占有すると仮定すると…
したがって、ROR はコールド データのキーをメモリに保存するのではなく、RocksDB 内の別のメタ列ファミリに保存します。 メタ列ファミリは頻繁にアクセスされ、タイプや有効期限などの少量のメタデータのみを格納することを考慮すると、ほとんどのコールド キーは少量のメモリ (ブロック キャッシュ) でキャッシュできます。 256MBのブロックキャッシュを割り当て、コールドデータキーをRocksDBに保存しても、全体的なQPSは低下しないことが検証されていますが、IOスレッドのCPU消費量は増加します。RedisホストマシンのCPU使用率はわずか10%であるため、CPUをメモリと交換することは許容範囲内です。 3.2 普遍性 重複キャッシュを回避するため、RoFはRocksDB層のテーブルキャッシュとファイルシステム層のページキャッシュを無効化します。つまり、コールドキーへのアクセスにはI/O操作が必要となり、コールドキーとホットキーのアクセスレイテンシに大きな差が生じます。 汎用性を向上させるために、ROR は RocksDB 層のテーブル キャッシュとオペレーティング システム層のページ キャッシュを有効に活用し、未使用のメモリを最大限に活用して、コールド キーとホット キーへのアクセス間のレイテンシ ギャップを削減します。 現実には、DBAとビジネスユーザーの両方にとって、キャッシュクラスターが顕著なホット/コールド特性を示すかどうかを正確に予測することは困難です。リダイレクトレスポンス（ROR）は一般的なシナリオに適しており、通信コストを大幅に削減し、ビジネスユーザーのレイテンシに関する懸念を軽減します。 RedisをRORに移行する際、アプリケーションがホットかコールドかは考慮しません。ビジネスQPSがRedisの半分以下であり、P99レイテンシの影響をそれほど受けない限り、RORに移行できます。 3.3 パフォーマンス RoF はキー レベルでデータを保存し、各キーは RocksDB キーに対応します。一方、ROR はサブキー レベルでデータを保存し、各サブキーは RocksDB キーに対応します。 HSETやHGETなどの集約型コマンドの場合、RoFではキー全体のスワップインとスワップアウトが必要ですが、RORでは必要なサブキーのみの読み書きを行います。そのため、読み書きの増幅はRoFよりもはるかに低く、QPSとレイテンシもRoFよりも優れています。 以下は、RORとRoFにおける、高負荷時（100スレッド、QPS無制限）と通常負荷時（1000スレッド、10000QPS）の純粋なコールドデータの読み書きにおけるQPSとレイテンシです。以下のことがわかります。
テスト手順:
非常に大きな集約キーの場合、RoF はキー全体をメモリにロードするため、レイテンシの急上昇が顕著になります (第 2 レベルまで)。一方、ROR は必要なサブキーのみをメモリにスワップインするため、レイテンシの急上昇は顕著になりません。 Redis を使用するほとんどの企業はレイテンシに敏感であり、過度のレイテンシの急増を許容できません。
テスト手順:
IV. 実施計画4.1 熱交換 以下は、クライアントがコールドキーにアクセスした場合のRORの処理手順です。青色のモジュールはネイティブRedisのものと同じですが、オレンジ色のモジュールはRORによって追加されたコールドスワップとホットスワップの機能を表しています。 全体として、ROR は最初にホット コールド交換 (スワップ) を実行し、次にコマンド処理フローを実行します。 熱交換（スワップ）プロセスは、主に次の手順で構成されます。 1) 構文解析：クライアントコマンドに関係するキーとサブキーを解析します。例えば、MGET k1 k2 k3 は k1, k2, k3 に依存し、HMGET h1 f1 f2 f3 は h1.{ f1, f2, f3 } に依存することが解析できます。 2) ロック: 構文解析の結果に基づいて、コマンドが依存するキーをロックします。このロックはpthread_mutexのようなスレッドセーフなロックではなく、Ruby on the Rock (ROR) プロジェクトで実装されたシングルスレッドロックであることに注意してください。基本的には待機キューです。詳細については、後述の同時実行制御セクションを参照してください。 3) SWAP タスクの送信: ロックを取得した後、IO スレッド グループにスワップ タスクを送信して、RocksDB の読み取りおよび書き込み操作を実行します。 4) RocksDB の読み取りおよび書き込み操作を実行する: IO スレッド グループは RocksDB の読み取り操作を実行します。 5) データのマージ: RocksDB から読み取ったデータを Redis にマージします。 スワップ処理後、コールド データは Redis に転送され、その後実行されるコマンドはネイティブ Redis のコマンドと一致します。 4.2 同時実行制御 Redisはシングルスレッドアーキテクチャを採用していますが、RocksDBはブロッキングAPIを提供しています。RedisのメインスレッドからRocksDBを直接呼び出すと、Redisのパフォーマンスが大幅に低下します。I/Oスループットを向上させるため、RORはRocksDBの読み取りと書き込みを実行するために追加のI/Oスレッドグループを使用します。この追加のI/Oスレッドグループにより、同じキーに対する読み取りと書き込みはシングルスレッドではなくなり、適切な制御を行わないとデータが破損します。 同時実行性を制御するため、Ruby on Rails (ROR) はシングルスレッドの再入可能ロックを設計・実装しました。これにより、一度に 1 つのクライアントのみが同じキーに対して I/O 交換を実行できるようになります。このロックは `pthread_mutex` のようなシステムスレッドロックではなく、本質的には待機キューです。キーがロックされている場合、ロックを取得しようとするクライアントは、そのキーのロックを取得する前に、先行するクライアントがロックを解放するまで待機する必要があります。 下の図に示すように、3 つのクライアント C1、C2、C3 が MGET コマンドを順番に実行しました。ここで、Key1、Key2、Key3 はすべてコールド データです。 C1はKey1とKey2に依存しています。これら2つのキーはロックされておらずコールド状態であるため、C1はKey1とKey2のロックを取得し、Key1とKey2のスワップをトリガーします。 C2はKey2とKey3に依存しています。Key2はC1によってロックされているため、C2はKey2のロックを取得する前にC1の実行が完了するまで待機する必要があります。Key3はロックされておらず非アクティブであるため、C2はKey2のロックを取得し、Key3のスワップをトリガーします。 C3はKey1とKey3に依存しています。Key1とKey3はそれぞれC1とC2によってロックされているため、C3はC1とC2の実行が終了した後にのみKey1とKey3のロックを取得できます。 したがって、Key1、Key2、および Key3 がスワップインされた後、クライアントの実行順序は C1=>C2=>C3 になります。 上記は単純な例です。キー空間全体を扱うFLUSHDB/BGSAVEなどのコマンドの同時実行制御要件を満たすため、RORはKEY、DB、SVRの3つの粒度のロックを含む待機キューを使用します。粒度の大きいロックは、粒度の小さいロックが解放されるまで取得できません。さらに、MULTI/EXECトランザクションでデッドロックが発生しないように、同じトランザクションが同じキーを繰り返しロックすることを許可しています（つまり、再入可能性）。 下の図に示すように、クライアント C1 と C2 は 2 つのトランザクションを連続して開始します。 C1はKey1に（2回）依存しています。C1は同じトランザクション内でKey1に（2回）依存しており、コールドトランザクションであるため、C1はKey1のロックを取得し、スワップインをトリガーします。 C2はKey2（2回）、DB0、SVRロックに依存しています。C2は同じトランザクションでKey2（2回）に依存しており、コールド状態であるため、C2はKey2ロックを取得し、スワップインをトリガーします。C2はDB0ロックに依存しており、DB0ロックの範囲はKey1とKey2にほぼ等しいため、C1はKey1を解放した後にのみDB0ロックを取得できることに注意してください。 Key1 が Key2 の前にスワップインされると仮定すると、Key1 がスワップインされた後、トランザクション C1 が実行され、Key1 のロックが解除されます。 Key2 がスワップインされた後、C2 は DB0 ロックと SVR ロックを取得し (すべてのロックを取得)、C2 トランザクションが実行されます。 4.3 コールドデータストレージ 業界のほとんどのソリューションと同様に、ROR のコールド データ ストレージは RocksDB エンジンを使用し、その設計は kvrocks や pika などのプロジェクトを参照しており、次の 3 つの主要な機能を備えています。
RocksDBに保存されたキー メモリ消費量がデータベースサイズに依存しないようにするため、RocksDBはコールドキーをメモリに保存しません。キーの種類、有効期限、バージョンなどの情報は、RocksDBのmetaCFに保存されます。この設計は、各キーが約50バイトの追加メモリを必要とすることを主に考慮しており、これはデータベースサイズが1億の場合、約5GBの追加メモリに相当します。データベースサイズが大きく、値が小さいクラスターでは、追加のメモリ消費量が過大になり、コールドキーとホットキーの分離が非効率的になります。 そのため、RoFとは異なり、RORはコールドキーをメモリに保存しません。キー関連の少数のコマンド（scan、randomkey、dbsize）については、適応的な変更が行われます。 サブキーは、RocksDB のキーと値のペアに対応します。 RocksDBはキーバリュー（KV）データ型のみをサポートしており、Redisのハッシュ、セット、zsetなどの集約キー型に直接マッピングすることはできません。そのため、Redisの集約キー型とRocksDBのKV型の間にマッピング関係を構築する必要があります。 最も直接的な解決策は、Redisの集約型キーを単一のRocksDB KVに直接シリアル化することです。しかし、この解決策には非常に明らかな欠点があります。単一のサブキーのみに依存するHGETハッシュサブキーコマンドは、集約型キー全体をメモリにスワップする必要があり、深刻な読み取り/書き込み増幅を引き起こします。 そのため、ROR は集計タイプのサブキーを RocksDB KV として保存し、集計タイプ データのコールド キーを置き換えるときは、必要なサブキーのみを置き換える必要があります。 遅延削除集約型キー 集約キー型の場合、各サブキーはRocksDBのキーと値のペアに対応します。RORで集約キーを削除するには、すべてのサブキーを削除する必要があります。RocksDBから直接反復処理して削除すると、O(N)の計算量となり、レイテンシの急上昇を引き起こす可能性があります。 PikaとKVrocksの設計を参考に、各集約型キーにはバージョン番号が付与されます。RORが集約キーを削除する際、metaCFのメタデータのみが削除され、他のサブキーはRocksDBの圧縮フィルタによって段階的にフィルタリングされ、削除されます。 ハッシュ/セット/zsetエンコーディング ハッシュ/セット型のエンコード形式は次のとおりです。 各ハッシュ/セットには metaCF 内に 1 つの RocksDB キーと値のペアがあり、タイプ、タイムアウト、バージョン、サブキーの数を記録します。 各ハッシュ/セットは、defaultCFにN個のRocksDBキーと値のペアを持ち、各サブキーに1つずつ対応しています。各サブキーには対応するバージョンが記録されているため、集約キーを削除するには、metaCFのキーと値のペアを削除するだけで遅延削除が完了します。 zset タイプのエンコード形式も同様ですが、scoreCF レコードには zset のスコアのソートが記録されます。 リストエンコーディング 操作がhash/set/zsetとは大きく異なるため、リストデータモデルの設計も異なります。設計上、Redisのリストはメモリ上のRedisと同じデータ構造を使用し、サブキーの一部のみがメモリ上に配置される場合があります。 モデル上のリスト設計は次のとおりです。
RocksList はサブキー レベルで RocksDB にも保存されます。 4.4 カッコウフィルタはI/Oを削減する 前述の通り、メモリ使用量がデータベースサイズに依存しないようにするため、RocksDBはキーメタデータをメモリに保存しません。そのため、クライアントがアクセスするキーが頻繁にアクセスされないデータである場合、その存在を確認するためにRocksDBへのクエリを実行する必要があります。キーが存在する場合は、RocksDBから読み取り、アクセス頻度の低いデータに置き換える必要があります。一方、キーが存在しない場合は、RocksDBからの読み取りは不要です。これは、ビジネスキースペースのミス率が高い場合（存在しないキーを繰り返し読み取るなど）、特に問題となり、不要なI/O操作が大量に発生し、全体的なパフォーマンスが低下します。 キーの問題がないフィルタリングでは、ブルームフィルタはキーあたり8～10ビットのメモリで良好なフィルタリング結果を得ることができます。しかし、ブルームフィルタは削除をサポートしておらず、RORのキー空間は常に動的に変化するため、機能面では要件を満たすことができません。 調査の結果、Cuckooフィルタが私たちのニーズを非常によく満たすことがわかりました。Cuckooフィルタは削除をサポートし、RORフィルタリングの精度要件を満たすのに必要なキーあたり8ビットのみを必要とします。 キーの正確な数を予測することは不可能であるため、ROR はカッコウ フィルターを実装する際に、指数関数的に増加する容量を持つ複数のカッコウ フィルターで構成されたカスケード カッコウ フィルターを使用します。 私たちのテストでは、キースペース ミスのシナリオでは、Cuckoo フィルターによって ROR の QPS が 50,000 から約 60,000 に増加し、スループットが約 20% 増加することが明らかになりました。ただし、キースペース ヒットのシナリオには大きな影響はありません。 4.5 Redisレプリケーションとの互換性 RORのレプリケーションプロトコルは、Redisのネイティブレプリケーションと完全に互換性があります。フルレプリケーションではRDB形式を使用し、増分レプリケーションではRESPプロトコルを使用します。Redisのネイティブレプリケーションプロトコルとの完全な互換性により、RORはxpipeと直接インターフェースでき、DR（レプリケーションフロー）機能も備えています。 フルコピーをストリーミング RORとRedisの完全レプリケーションは、同じメインプロセスを共有しています。マスタープロセスが子プロセスをフォークし、子プロセスがRDBを作成します。ただし、RORはホットデータとコールドデータの両方を処理するため、生成されるRDBはネイティブRedisとは異なります。
コールドデータ（RocksDB部分）からRDBを生成する方法の一つとして、コールドキーを一時的にメモリにロードし、Redisのシリアル化メソッドを再利用してRDBを構築するというものがあります。しかし、この方法ではすべてのコールドキーをロードする際にCPUリソースを大量に消費します。Redisホストマシンがクラッシュして再起動すると、多数のRedis完全同期がCPUリソースを奪い合い、完全同期に非常に長い時間がかかります。 パフォーマンス上の理由から、RORはRDBの構築時にコールドキーをロードしません。代わりに、ストリーミング方式を採用しています。つまり、単一のIOスレッドがRocksDBデータセット全体を反復処理し、反復処理されたデータをストリーミング方式でRDBに追加します。このストリーミング方式は、同じ集約型のサブキーをRocksDB内の隣接する場所に格納するRORのストレージ設計に依存している点に留意してください。 実装レベルでは、ストリーミングRDB構築スキームは、キーをメモリにロードし、Redisレイヤーをスキップして再エンコードする手間を省きます。RockDBデータをRDBに直接ストリーミングすることで、フルコピー速度315MB/秒を実現しています。これはRedisのコピー性能（390MB/秒）の約80%に相当します。 同時増分レプリケーション Redisの増分レプリケーションでは、マスターは単一のレプリケーションクライアントを介してスレーブにレプリケーションストリームをプッシュします。レプリケーションクライアントは1つしかないため（コールドスワップとホットスワップの最大同時実行数は1）、RORスレーブがレプリケーションクライアントを使用して直接データを交換すると、スレーブのレプリケーションはマスターの書き込みに追いつかなくなります。 レプリケーションと交換のパフォーマンスを向上させるために、ROR はレプリケーション クライアントから受信したコマンドを複数のワーカー クライアントに分散し、交換を同時に実行します。 交換が完了した直後にワーカー クライアントがコマンドを呼び出すと、スレーブ上のコマンドの実行順序がマスター上のコマンドの実行順序と異なる場合があり、マスターとスレーブ間でデータの不整合が発生する可能性があります。 ROR方式では、ワーカークライアントは交換完了直後にコマンドを実行するのではなく、先行するすべてのコマンドの実行が完了するまで待機してからコマンドを実行します。スレーブは、マスターから伝播されたレプリケーションストリームと同じ順序で増分レプリケーションコマンドを実行するため、マスターとスレーブ間のデータ整合性が保証されます。 上図に示すように、①、②、④は同時にI/O操作を実行しています。②と④は①より先にデータ交換を完了する場合もありますが、必ず①のI/O操作が完了するまで待機してからコマンドを実行します。 ROR 増分レプリケーション同時実行性の変更後、スレーブのレプリケーション コマンドの処理速度は数千 QPS からマスターの最大書き込み速度 (ホット データとコールド データの比率に応じて約 50,000 ～ 100,000 QPS) を超えるまでに向上しました。 V. 制作実務経験上、多くのRedisクラスターはQPSが低いにもかかわらずメモリ使用量が高いという問題があります。Redisホストマシンは通常、メモリ上限に達したもののCPUリソースが比較的アイドル状態にあるため、拡張をトリガーします。例えば、CtripのRedisホストマシンの平均CPU使用率は約15%ですが、平均メモリ使用率は50%に達します。 RORはディスクを使用してキャッシュ容量を増やし、より多くのデータを保持できます。ただし、RocksDBエンジンの圧縮とコンパクションはCPUリソースを多く消費します。そのため、RORはアイドル状態のCPUをメモリと交換する費用対効果の高いソリューションと言えます。 コストの面では、経験的データによれば、1 つの ROR インスタンスは 3 つの Redis インスタンスのデータに対応できるため、Redis を ROR に移行するとコストを 2/3 削減できます。 現在、数万台のRORインスタンスが本番環境に導入されています。海外のパブリッククラウドはメモリ単価が高いため、ほぼすべての導入にRORが採用されており、年間数千万元のコスト削減につながっています。 パフォーマンスの面では、スループットを考慮すると、Ctrip の内部 Redis クラスター内の高 QPS の割合は比較的低く、ROR の QPS 制限をはるかに下回っています (上記のパフォーマンス データを参照)。 レイテンシの観点から見ると、RORはキャッシュを有効に活用し、サブキーレベルでデータを保存するように設計されています。さらに、NVMe SSDのレイテンシはわずか数十マイクロ秒であるため、Redisと比べてレイテンシが大幅に高くなることはありません。 以下は、ROR への移行後の典型的な Redis クラスターのレイテンシ比較です。80% がコールドデータ、20% がホットデータです。移行前後のクライアントアクセスレイテンシは 200 マイクロ秒から約 220 マイクロ秒に増加しました。 VI. オープンソースプロジェクトと今後の計画6.1 プロジェクトはオープンソースです ROR (Redis-On-Rocks) は現在オープンソースであり、Redis と同じ BSD ライセンスを使用しています。 6.2 今後の計画 1) 単一インスタンスのQPSの向上 一部のビジネスシナリオ（ビッグデータ関連ビジネスなど）では、データ量が多いだけでなく、QPSも比較的高くなります。これらのクラスターでは、RORのメインスレッド使用率が100%になる場合があります。こうしたシナリオに対処するため、ソフトウェアレベルとハードウェアレベルの両方で最適化を検討しています。ソフトウェアレベルでは、コールドスワップとホットスワップの損失を削減し、パイプラインを自動化することでネットワークCPUの消費量を削減します。ハードウェアレベルでは、クロック速度の高いCPUを使用することで、上限値を高めています。 2) データ構造のサポートを改善する あまり使用頻度の高くないデータ構造の中には、最適化が必要なものがあります。例えば、ビットマップは現在文字列として扱われているため、読み書きの負荷が著しく増大し、パフォーマンスの最適化が必要です。ストリームは現在サポートされておらず、メモリストレージを使用するため、将来的にサポートされる予定です。 3) 完全な同期を減らす 国内外の帯域幅は比較的限られているため、完全同期を行うと海外のサービスに長期間の中断が生じる可能性があります。海外展開が拡大するにつれて、この問題の影響は徐々に大きくなります。今後、RORは、軽微なデータ不整合があっても増分同期を可能にする、可用性と整合性を確保するオプションの提供を検討していきます。 | |||||||||||||||||||||||||||
