RedisとDragonflyは危機感を抱くべきだ!
マイクロソフトの新しいキャッシュストレージシステムGarnet
最近、マイクロソフトは公式にオープンソースキャッシュストレージシステムGarnetをオープンソース化した。マイクロソフトリサーチのデータベースグループのシニアプリンシパルリサーチャーであるBadrish Chandramouli氏によると、Garnetプロジェクトはゼロから構築され、パフォーマンス（特にスループットにおけるスレッドスケーラビリティと低レイテンシの割合の増加）を中心に構築された。
具体的には、Garnetには以下の利点がある。
- Garnetは一般的なRESP回線プロトコルを出発点として使用しているため、ほとんどのユーザーはほとんどのプログラミング言語で書かれたRedisクライアントから直接Garnetにアクセスできます。
- Garnetは、複数のクライアント接続と小ロット形式でスケーラビリティとスループットを向上させ、大規模なアプリケーションやサービスの運用コストを削減します。
- Garnetは99パーセンタイルと99.9パーセンタイルでクライアント側のレイテンシレベルが向上し、実世界のシナリオで重要な安定性パフォーマンスの割合が高くなりました。
- Garnetは最新の. NETテクノロジーに基づいており、クロスプラットフォーム、拡張性、モダンです。一般的なシナリオでパフォーマンスレベルを犠牲にすることなく、開発と調整が容易です。. NETの豊富なライブラリエコシステムを活用してAPIを拡張し、最適化の機会を開いています。. NETを徹底的に活用したGarnetは、LinuxとWindowsの両方で最高のパフォーマンスを発揮します。
マイクロソフトリサーチは2016年から最新のキーバリューデータベースアーキテクチャに取り組んでいます。2018年、マイクロソフトは組み込みキーバリューライブラリFASTERをオープンソース化し、シンプルなシングルノードプロセス内キーバリューモデルに焦点を当てながら、従来のシステムを数桁上回る性能を発揮しました。
2021年から、実際のユースケースのニーズに応じて、マイクロソフトは新しいリモートキャッシュストレージスキームの構築を開始します。既存のキャッシュストレージの実行可能な代替として機能するために必要なすべての機能が含まれます。当時のマイクロソフトにとっての課題は、より現実的な普遍的なネットワーク環境に適応する方法を検討しながら、以前の取り組みで達成したパフォーマンス優位性を維持/強化することでした。その結果がGarnetです。
Garnetの導入に適したシナリオについて尋ねられたChandramouli氏は、“キャッシュストレージソリューションとしてRedis、KeyDB、Dragonflyを使用する既存のアプリケーションはすべて適しています。Garnetは、より高いスループット、低レイテンシ、管理する必要のあるキャッシュストレージシャードを減らすことでコストを削減し、メモリサイズを超えるデータをキャッシュするためにローカルディスクやSSDにデータをオーバーフローすることができます。また、Garnetは、非常に高性能なキャッシュ層を利用してパフォーマンスを向上させ、バックエンドストレージサーバやデータベースのコストを削減したいと考えている新しいタイプのアプリケーションにも適しています。”
API機能に関しては、Garnetはプリミティブ文字列、解析、オブジェクト操作など幅広いAPIをサポートしています。また、シャーディング、レプリケーション、動的鍵移行などの機能のためのクラスタリングモードも提供します。ガートナーは、クライアント側のRESPトランザクションとC#で記述されたサーバ側のストアドプロシージャをサポートし、ユーザーは元の文字列と新しいオブジェクト型の両方にカスタムアクションを設定できます。これらはすべてC#で簡単に記述できるため、カスタム拡張機能の開発障壁は低くなります。
ネットワーク、ストレージ、クラスタリング機能に関しては、Garnetは高速でプラガブルなネットワーク層を使用し、カーネルバイパススタックなどの後続の拡張をサポートしています。TLS（Transport Layer Security）通信プロトコルと各種基本アクセス制御をサポートしています。OSS FASTERからフォークされたTsavoriteと呼ばれるGarnetのストレージ層は、スレッドスケーラビリティ、階層ストレージ（メモリ、SSD、クラウドストレージなど）のサポート、高速なノンブロッキングチェックポイント、リカバリ、永続的な運用ロギング、マルチキートランザクションのサポート、より良い内部管理と再利用などの強力なデータベース機能を提供します。さらに、Garnetはクラスタ動作モードをサポートしています。
単一ノード実行に加えて、Garnetはクラスタモードをサポートしており、ユーザーはシャードとレプリケーションデプロイメントを作成して管理できます。Garnetは効率的で動的なキー移行スキームをサポートし、シャードをリバランスします。ユーザーは標準のRedisクラスタコマンドを使用してGarnetクラスタを作成および管理でき、ノードはgossipを実行してクラスタ状態を共有および進化させます。全体として、Garnetのクラスタリングモードは巨大でまだ進化中の機能であり、マイクロソフトは詳細は今後の記事で共有すると述べています。
Chandramouli氏は、The Stackへの電子メールで、“他のさまざまな実世界のアプリケーションでGarnetのパフォーマンスについてフィードバックを得ることを楽しみにしています。さらに、C#ベースの強力なストアドプロシージャモデルがあり、ユーザーは関心のあるトランザクションをカスタマイズできます。最後に、Garnetは、ディスクIO、カーネルバイパスネットワーク、ベクトルデータベースなどのアプリケーションシナリオの最適化など、将来に向けた重要な革新的ツールと考えています。”
Garnetの特徴は？
クラウドとエッジコンピューティングの急速な成長により、アプリケーションやサービスのデータとリーチが大幅に向上しました。しかし、同時に、データアクセス、更新、変換のレベルで、より効率的で低遅延で低コストな実用的な要件も提示しています。これらのアプリケーションやサービスは、ストレージの相互作用に多額の運用コストを必要とすることが多く、今日最も高価で困難なプラットフォーム領域の1つです。個別のスケーラブルなリモートプロセスとして存在するキャッシュストレージソフトウェア層は、これらのコストを削減し、アプリケーションパフォーマンスを向上させます。これは、Redis、Memcached、KeyDB、Dragonflyなどの有名なオープンソースシステムを含むキャッシュストレージ業界の成長を後押ししています。
単純なフェッチ/セットインターフェイスのみをサポートする従来のリモートキャッシュストアとは異なり、最新のキャッシュは豊富なAPIと機能セットを提供する必要があります。生の文字列、Hyperloglogなどの解析データ構造、ソートセットやハッシュなどの複雑なデータ型をサポートしています。また、キャッシュのチェックポイントとリカバリ機能の設定、データシャードの作成、レプリカの維持、トランザクションとカスタム拡張のサポートも可能です。
しかし、既存のシステムでは、システム設計のシンプルさを維持しながら、最新のハードウェア機能（マルチコア、階層型ストレージ、高速ネットワークなど）を十分に活用できないなど、このような豊富な機能要件を満たすことが困難になることがよくあります。さらに、これらのシステムの多くは、アプリケーション開発者が簡単に拡張できること、異なるプラットフォーム/オペレーティングシステムでうまく動作することなどの現実的なニーズを考慮して設計されていません。
Garnetは、ネットワークからパケットを取得し、データベース操作を解析して処理し、ストレージ相互作用を実行するまで、キャッシュストレージスタック全体を設計から再考しました。
下の図はGarnetの全体的なアーキテクチャを示しており、Garnetのネットワーク層はShadowFaxの研究に触発されたマイクロソフトの共有メモリ設計を継承していることがわかる。TLS処理とストレージとの相互作用はIO完了スレッドで実行されるため、一般的なスレッド切り替えオーバーヘッドを回避できます。このアプローチは、サーバー上でデータを移動する必要がある従来のシャッフル設計ではなく、CPUキャッシュの一貫性を使用してネットワークにデータを転送します。
Garnetのストレージ設計は、統合されたオペレーションログにバインドされた2つのTsavoriteキー/バリューストアで構成されています。前者のストレージセットは“プライマリストレージ”と呼ばれ、生の文字列操作に最適化されており、ガベージコレクションを避けるためにメモリを管理します。2つ目のセットはオプションの“オブジェクトストレージ”で、ソートセット、セット、ハッシュ、リスト、地理空間などの一般的なデータ型をカバーする複雑なオブジェクトやカスタムデータ型に最適化されています。これらは（更新をより効率的にするために）メモリヒープに格納され、ディスクにシリアル化された形式で格納されます。マイクロソフトはまた、統一されたインデックスとログでGarnetのシステムメンテナンスを簡素化する方法を検討していきます。
Garnetの設計の特徴の1つは、TsavoriteストレージAPIの使用である。AIPは、読み取り、更新挿入、削除、アトミックな読み取り-変更-書き込みを実行できる、より大きく、よりリッチで、スケーラブルなRESP APIサーフェスを提供するために設計されており、すべてGarnetの非同期コールバックによって実装され、各操作中の複数のポイントにロジックを挿入します。ストレージAPIモデルにより、Garnetは問題解決とクエリ処理を、並行性、ストレージ階層化、チェックポイントなどの他のストレージ機能から完全に分離することができます。
さらに、Garnetは2段階ロックに基づくマルチキートランザクションのサポートを追加しました。ユーザーはRESPクライアント·トランザクション（MULTI-EXEC）を使用するか、C#のサーバ·トランザクション·ストアド·プロシージャを使用できます。
パフォーマンスパフォーマンスのパフォーマンス
マイクロソフトのリサーチチームは、ガートナーと他の主要なオープンソースキャッシュストレージソリューションの主要パフォーマンス指標を比較しました。
まず、Linuxシステム（Ubuntu 20.0 4）を実行するAzure Standard F 72 v 2仮想マシン2セット（仮想マシン72 あたりv CPUに144 GiBのメモリ）を事前設定し、高速TCPを有効にしました。仮想マシンの1セットはさまざまなキャッシュストレージサーバを実行し、もう1セットはパブリッシングワークロード専用です。ここでは、マイクロソフトは独自のベンチマークツールResp.benchmarkを使用してパフォーマンステスト結果を統一します。
マイクロソフトはGarnetをRedis（v 7.2）、KeyDB（v 6.3.4）、Dragonfly（v 6.2.1 1）の最新のオープンソースバージョンと比較した。実験では、マイクロソフトは一様にランダムに分散されたキーを使用した（Garnetの共有メモリ設計は非ランダムに分散されたキーに対してより良い性能最適化を提供した）。これらの実験では、データは各サーバにプリロードされ、メモリに埋め込まれました。
実験1：クライアントセッション数の異なるスループット比較
大きなフィンガー GET操作（バッチあたり4，096リクエスト）と低負荷（キーと値の8バイト）から始めて、ネットワークオーバーヘッドを最小限に抑え、クライアントセッション数を徐々に増やしてシステムパフォーマンスを比較します。下のグラフからわかるように、GarnetはRedisやKeyDBを上回るスケーラビリティを示しながら、3つのベースラインシステムすべてよりも高いスループット（y軸の対数）を達成しています。Dragonflyのスケーリング性能はGarnetと似ていますが、前者は純粋なインメモリシステムです。さらに、データベースサイズ（プリロードされたキーの数）がプロセッサのキャッシュサイズ（2億5600万キー）を大幅に上回っている場合、Garnetは他のシステムと比較して強力なスループットを維持しています。
データベースサイズが（a）1024キーおよび（b）2亿5600万キーのときの、异なる数のクライアントセッションに対応するスループット（対数）。
実験2：異なるバッチサイズのスループットの比較
次に、GET操作に固定数（64）のクライアントセッションを加えてバッチサイズを変更します。以前の実験と同様に、2つの異なるデータベースサイズを試してみてください。下図に示すように、バッチ処理を使用しなくてもGarnetの性能は向上し、バッチ処理を使用すると、バッチサイズが小さくてもGarnetの性能優位性が高まります。負荷サイズは実験1と同じで，Y軸も対数座標をとります。
データベースサイズが（a）1024キーおよび（b）2亿5600万キーのときの、异なるバッチサイズでのスループットの（対数をとる）。
実験3：意見セッション実施回数別の遅延比較
次にテストしたのは、さまざまなシステムのクライアントレイテンシです。下図に示すように、クライアントセッション数が増えるにつれて、Garnetは他のシステムに比べてすべてのパーセンタイル（マイクロ秒単位）で低遅延で安定しています。実験では，GET操作が80%，SET操作が20%の混合割合で操作を送信し，バッチ処理を行わなかった.
異なるクライアントセッション数の場合、（a）中央値、（b）99パーセンタイル、および（c）99.9パーセンタイルにおけるレイテンシレベル。
実験4：異なるバッチサイズの遅延の比較
Garnetのレイテンシレベルは、Adaptive Clientのバッチおよびクエリシステムに最適化されています。マイクロソフトはバッチサイズを1から64に増やし、128のアクティブなクライアント接続で異なるパーセンタイルのレイテンシレベルを以下の図にまとめました。下のグラフからわかるように、Gartnerのレイテンシーは全体的に低いです。これまでの実験と同様に，GET操作が80%，SET操作が20%の混合割合を採用した.
異なるバッチサイズでの遅延レベル（a）中央値、（b）99パーセンタイル、および（c）99.9パーセンタイルにおける。
開発者：Redisは大幅なパフォーマンス最適化が必要です!
ベンチマークのパフォーマンスグラフでは、GETコマンドのスループットはDragonflyの10倍以上になります。50パーセンタイルのレイテンシレベルはDragonflyよりもわずかに高いですが、99パーセンタイルのレイテンシレベルはDragonflyよりも低いです。GarnetとDragonflyはスループットとレイテンシでRedisよりもはるかに優れており、多くの開発者はRedisが大幅なパフォーマンス最適化を必要とする可能性を示唆している。
開発者のhipadev 23は、“Garnetは、低並列性と高並列性の両方でRedisを上回る最初の代替手段であり、驚くべき成果です。Redisは大幅なパフォーマンス最適化が必要かもしれません。
開発者のmtmkは、Garnetの出現は、Microsoft Windows Server上で直接Redis（または互換性）を実行する必要があるが、WSL 2に依存したくない人にとって朗報だと考えている。Redisポート（現在はアーカイブ状態）によって引き起こされていたメモリ使用の問題（主にメモリマップファイルAFAIKによる）はなくなります。
多くの開発者がRedisを選択します。Redisはいくつかの点で開発者フレンドリーで、実行時間が長く安定しています。Garnetでは、ライセンス契約、製品価格、アップデートとメンテナンスに関する懸念が一般的にあります。Throwawaway 38375は、“Redisはライセンス契約や製品価格に関してはるかに安定しているはずであり、結局のところ、何十億時間もの運用テストを経てきました。また、Redisのインストールと理解が容易です。”“このようなマイクロソフトリサーチのプロジェクトについて、私が最も心配しているのは、ライセンス契約や製品価格ではなく、アップデート（機能、メンテナンス、さらにはセキュリティアップデート）の欠如です。
理由：GarnetはC#で開発されました
コミュニティの議論では、GarnetプロジェクトがC#で開発されていることに驚いた開発者もいた。
开発者のwest nは、“最も惊いたのは、Garnetプロジェクトが実际にC#で开発されているのに対して、onflyはC++で开発されており、RedisはCで开発されているということだ”と述べている。開発者のwhimsicalismは“ガベージコレクション言語C#で書かれたGarnetがRedisやDragonflyを打ち負かしたのは驚くべきことだ”と述べた。
一部の開発者からのコメントは、“ガベージコレクション言語はガベージコレクション言語とは異なり、C#や. NETのような言語は実際にはC++と同等のパフォーマンスチューニングオプションをすべて提供している”と述べています。彼は皆がすべきことは真剣に学ぶことだと言いました全てのガベージコレクション言語を一つのカテゴリーにまとめてもう一度殺すのではなく[** ウェブマスター注：. NETはプラットフォームであり、C#は. NETの実装であり、C#は. NETとJavaとJDKのアナロジー ***]
さらに、より具体的には、MSILと. NETはC++をサポートするように設計されており、C#やF#などの言語はこれらの機能にアクセスする方法を持っています。言語構文レベルで公開されていない機能もありますが、開発者はC ++/CLIで生成されたMSILを直接使用できます。
これについてどう思いますか？コメント欄にあなたの意見を残してください。
参照リンク：
https://www.thestack.technology/microsoft-takes-on-redis-with-new-open-source-garnet-cache-store/