マイクロソフトが年収数億ドルのRedis市場に参入?オープンソースの高速Garnetを発表:Redisクライアントをそのまま接続可能

マイクロソフトが年収数億ドルのRedis市場に参入?オープンソースの高速Garnetを発表:Redisクライアントをそのまま接続可能

先日、マイクロソフトはキャッシュストレージシステム「Garnet」をオープンソース化しました。マイクロソフトリサーチのデータベースグループ上級主席研究員Badrish Chandramouli氏によると、Garnetプロジェクトはゼロから構築され、パフォーマンス(特にスループットのスレッドスケーラビリティと高い低レイテンシ比率)を中心に設計されています。

最終更新 2024/03/21 0:26
凌敏,核子可乐
読了目安 7 分
カテゴリ
.NET
タグ
.NET C# オープンソース Redis Garnet

マイクロソフト、年商1億ドル超のRedisのシェアを奪取?オープンソースでパフォーマンスで圧倒的に優れたGarnet:修正不要で、Redisクライアントがそのまま接続可能

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 は、高性能キャッシュ層を活用してパフォーマンスを向上させ、バックエンドストレージサーバーやデータベースのコストを削減したい新しいアプリケーションにも適しています。」

img

API 機能としては、Garnet は幅広い API をサポートしており、生文字列、分析、オブジェクト操作などを含みます。また、シャーディング、レプリケーション、動的キー移行などの機能を備えたクラスターモードも提供します。Garnet は、クライアントの RESP トランザクションと C# で書かれたサーバーサイドストアドプロシージャをサポートし、ユーザーが生文字列や新しいオブジェクト型の上にカスタム操作を設定することも可能です。これらはすべて C# で簡単に記述できるため、カスタム拡張の開発ハードルは低くなります。

ネットワーク、ストレージ、クラスタリング機能に関して、Garnet は高速でプラグ可能なネットワーク層を使用しており、カーネルバイパススタックなどの将来の拡張もサポートしています。トランスポート層セキュリティ(TLS)通信プロトコルと様々な基本アクセス制御をサポートします。Garnet のストレージ層は Tsavorite と呼ばれ、OSS FASTER からフォークされたもので、スレッドスケーラビリティ、階層ストレージサポート(メモリ、SSD、クラウドストレージなど)、高速な非ブロッキングチェックポイント、リカバリ、永続操作ログ記録、マルチキートランザクションサポート、および優れた内部管理と再利用機能など、一連の強力なデータベース機能を提供します。さらに、Garnet はクラスター運用モードもサポートしています。

単一ノード実行に加えて、Garnet はクラスターモードをサポートしており、ユーザーはシャードとレプリカのデプロイメントを作成および管理できます。Garnet はまた、効率的で動的なキー移行スキームをサポートしており、これにより各シャードを再分散できます。ユーザーは標準の Redis クラスターコマンドを使用して Garnet クラスターを作成および管理でき、各ノードはゴシップを実行してクラスター状態を共有および進化させます。全体として、Garnet のクラスターモードは大規模で発展中の機能であり、マイクロソフトは詳細を後続の記事で共有する予定です。

Chandramouli 氏は The Stack へのメール返信で、「Garnet を他のさまざまな現実のアプリケーションで使用したフィードバックもお待ちしています。さらに、C# ベースの強力なストアドプロシージャモデルも備えており、ユーザーは関心のあるトランザクションをカスタマイズできます。最後に、Garnet を将来に向けた重要なイノベーションツールと位置付けており、ディスク IO の最適化、カーネルバイパスネットワーク、ベクトルデータベースなどのアプリケーションシナリオも視野に入れています。」

Garnet の特長は?

クラウドとエッジコンピューティングの急速な成長により、関連するアプリケーションやサービスはデータとカバレッジの両面で大幅に向上しています。しかし同時に、データアクセス、更新、変換の面で、より高い効率、低レイテンシ、低コストという実際の要求が生じています。これらのアプリケーションやサービスは、ストレージとのやり取りに多額の運用支出を必要とすることが多く、今日の最もコストがかかり困難なプラットフォーム領域の一つとなっています。個別にスケーラブルなリモートプロセスとして存在するキャッシュストレージソフトウェア層は、これらのコストを効果的に削減し、アプリケーションのパフォーマンスを向上させることができます。これにより、キャッシュストレージ業界が発展し、Redis、Memcached、KeyDB、Dragonfly など、多くの有名なオープンソースシステムが登場しています。

単純な get/set インターフェースのみをサポートする従来のリモートキャッシュストレージとは異なり、最新のキャッシュストレージは豊富な API と機能セットを提供する必要があります。生文字列、HyperLogLog などの分析データ構造、ソートセットやハッシュなどの複雑なデータ型をサポートします。また、ユーザーがキャッシュにチェックポイントとリカバリ機能を設定したり、データシャードを作成したり、レプリカを維持したり、トランザクションやカスタム拡張をサポートしたりすることも可能でなければなりません。

しかし、既存のシステムはシステム設計のシンプルさを維持しながら、これほど豊富な機能要件を満たすのが難しいことが多く、マルチコア、階層ストレージ、高速ネットワークなどの最新のハードウェア機能を十分に活用できない原因となっています。さらに、これらのシステムの多くは、アプリケーション開発者が簡単に拡張したり、異なるプラットフォームやオペレーティングシステムで良好に動作したりすることを当初から考慮していませんでした。

説明によると、Garnet は設計上、キャッシュストレージスタック全体を再検討しています。ネットワークからパケットを取得し、データベース操作を解析・処理し、ストレージとの対話を実行するまでをカバーしています。

下図は Garnet の全体アーキテクチャです。Garnet のネットワーク層は、ShadowFax の研究に触発された共有メモリ設計を継承しています。TLS 処理とストレージとの対話は IO 完了スレッドで実行され、一般的なスレッド切り替えのオーバーヘッドを回避します。この方法により、CPU キャッシュの一貫性を利用してデータをネットワークに転送できます。これは、サーバー上でデータを移動する必要がある従来のシャッフル設計とは異なります。

Garnetプロジェクト全体アーキテクチャ

Garnet のストレージ設計は、統合された操作ログにバインドされた 2 つの Tsavorite キー・バリュー・ストアで構成されています。最初のストアは「プライマリストレージ」と呼ばれ、生文字列操作に最適化されており、ガベージコレクションを回避するためにメモリを管理します。2 つ目はオプションの「オブジェクトストレージ」で、主に複雑なオブジェクトやカスタムデータ型に最適化されており、ソートセット、セット、ハッシュ、リスト、地理空間などの一般的なデータ型を含みます。これらはメモリヒープ上に格納され(更新の効率化のため)、ディスク上にはシリアル化された形式で格納されます。将来的には、統合されたインデックスとログを使用して Garnet のシステムメンテナンスを簡素化する方法を研究する予定です。

Garnet 設計の顕著な特徴の 1 つは、Tsavorite ストレージ API の採用です。この API は、より大きく、より豊富で拡張可能な RESP API サーフェスを提供し、読み取り、更新挿入、削除、アトミックな読み取り・変更・書き込みなどの操作を実行でき、これらはすべて Garnet の非同期コールバックを介して実装され、各操作中の複数のポイントにロジックを挿入できます。ストレージ API モデルは、Garnet が問題の解析とクエリ処理を、並行性、ストレージ階層化、チェックポイントなどの他のストレージ機能から完全に分離することを保証します。

さらに、Garnet は 2 相ロックに基づくマルチキートランザクションのサポートも追加しています。ユーザーは RESP クライアントトランザクション(MULTI-EXEC)または C# を使用したサーバーサイドトランザクションストアドプロシージャを使用できます。

パフォーマンス

マイクロソフトの研究チームは、Garnet と他の主要なオープンソースキャッシュストレージソリューションとの間の主要なパフォーマンス指標を比較して示しています。

まず、チームは Linux システム(Ubuntu 20.04)を実行する 2 つの Azure 標準 F72s v2 仮想マシン(各仮想マシン 72 vCPU、144 GiB メモリ)を事前構成し、加速 TCP を有効にしました。1 つの仮想マシンはさまざまなキャッシュストレージサーバーを実行し、もう 1 つはワークロードを専用に発行します。マイクロソフトは独自のベンチマークツール Resp.benchmark を使用し、これによってパフォーマンステスト結果を統一しました。

マイクロソフトは Garnet を、最新のオープンソースバージョンの Redis(v7.2)、KeyDB(v6.3.4)、Dragonfly(v6.2.11)と比較しました。実験では、均一にランダムに分布したキー(Garnet の共有メモリ設計は、ランダムでない分布のキーに対してより良いパフォーマンス最適化効果を持っています)を使用しました。これらの実験では、データは各サーバーに事前にロードされ、メモリに組み込まれました。

実験 1:異なるクライアントセッション数でのスループット比較

大量の GET 操作(バッチあたり 4096 リクエスト)と低負荷(8 バイトキーと値)から始めて、ネットワークオーバーヘッドを最小限に抑え、クライアントセッション数を徐々に増やしてシステムパフォーマンスを比較しました。下図からわかるように、Garnet は Redis と KeyDB よりも優れたスケーラビリティを示し、3 つのベースラインシステムすべてよりも高いスループットを達成しました(y 軸は対数スケール)。Dragonfly の拡張性能は Garnet と似ていますが、Dragonfly は純粋なインメモリシステムであることに注意してください。さらに、データベースサイズ(つまり、事前ロードされたキーの数)がプロセッサのキャッシュサイズ(2 億 5600 万キー)を大幅に超えた場合でも、Garnet は他のシステムと比較して強力なスループットを維持しました。

img

データベースサイズが (a) 1024 キーおよび (b) 2 億 5600 万キーの場合の、異なるクライアントセッション数におけるスループット(対数スケール)。

実験 2:異なるバッチサイズでのスループット比較

次に、GET 操作と固定数(64)のクライアントセッションを使用して、バッチサイズを変更しました。前の実験と同様に、2 つの異なるデータベースサイズを試しました。下図に示すように、バッチ処理を行わない場合でも Garnet のパフォーマンスは優れており、バッチ処理を行った場合、たとえバッチサイズが小さくても、Garnet のパフォーマンス上の利点は増大します。負荷サイズは実験 1 と同じで、y 軸も対数スケールです。

img

データベースサイズが (a) 1024 キーおよび (b) 2 億 5600 万キーの場合の、異なるバッチサイズでのスループット比較(対数スケール)。

実験 3:異なるクライアントセッション数でのレイテンシ比較

次に、各システムのクライアントレイテンシをテストしました。下図に示すように、クライアントセッション数が増加するにつれて、Garnet は他のシステムと比較して、各パーセンタイルでのレイテンシ(マイクロ秒単位)が低く、より安定しています。実験では、GET 操作 80%、SET 操作 20% の混合比率で操作を送信し、バッチ処理は行いませんでした。

img

異なるクライアントセッション数での、(a) 中央値、(b) 99 パーセンタイル、(c) 99.9 パーセンタイルにおけるレイテンシ。

実験 4:異なるバッチサイズでのレイテンシ比較

Garnet のレイテンシは、適応型クライアントのバッチ処理とクエリシステム向けに最適化されています。マイクロソフトはバッチサイズを 1 から 64 に増やし、128 のアクティブなクライアント接続がある場合の各パーセンタイルでのレイテンシを下図にまとめました。下図からわかるように、Garnet のレイテンシは全体的に低くなっています。前の実験と同様に、GET 操作 80%、SET 操作 20% の混合比率を使用しました。

img

異なるバッチサイズでの、(a) 中央値、(b) 99 パーセンタイル、(c) 99.9 パーセンタイルにおけるレイテンシ。

開発者:Redis は大幅なパフォーマンス最適化が必要!

ベンチマークパフォーマンスグラフから、GET コマンドのスループットは Dragonfly の 10 倍以上でした。50 パーセンタイルのレイテンシは Dragonfly よりわずかに高いものの、99 パーセンタイルのレイテンシは Dragonfly より低くなっています。Garnet と Dragonfly のスループットとレイテンシは Redis をはるかに上回っており、多くの開発者は、これは Redis が大幅なパフォーマンス最適化を必要としている可能性を示していると考えています。

開発者 hipadev23 氏は、「Garnet は確かに、低同時実行と高同時実行の両方で Redis を上回る最初の代替案であり、これは素晴らしい成果です。」「Redis は大幅なパフォーマンス最適化が必要かもしれません。」と述べています。

開発者 mtmk 氏は、WSL2 に依存せずに Windows サーバー上で直接 Redis(または互換品)を実行する必要がある人にとって、Garnet の登場は確かに朗報だと述べています。これまで Redis ポート(現在はアーカイブ状態)が引き起こしていたメモリ使用問題(主にメモリマップドファイル AFAIK による)は解消されます。

一方、多くの開発者は依然として Redis を固く支持しています。Redis は特定の面で開発者にとってより親しみやすく、より長く安定して動作しています。Garnet については、ライセンス、製品価格、アップデートとメンテナンスなどに対する懸念が一般的です。throwaway38375 氏は、「Redis はライセンスや製品価格に関してより安定しているはずで、何十億時間もの本番稼働テストを経ています。Redis の方がインストールも理解も容易です。」と述べています。Someone 氏は、「このような Microsoft Research のプロジェクトについて私が最も懸念しているのは、ライセンスや製品価格ではなく、アップデート(機能、メンテナンス、さらにはセキュリティアップデート)の欠如です。」と述べています。

ちなみに:Garnet は C# で開発されています

コミュニティの議論では、Garnet プロジェクトが C# で開発されていることに多くの開発者が驚いています。

開発者 west0n 氏は、「最も驚いたのは、Garnet プロジェクトが C# で開発されていることです。Dragonfly は C++、Redis は C で開発されています。」と述べています。開発者 whimsicalism 氏は、「まったくの予想外で、ガベージコレクション言語である C# で書かれた Garnet が Redis や Dragonfly を打ち負かすとは。」と述べています。

また、より中立的な評価を与える開発者もおり、pjmlp 氏は「ガベージコレクション言語にも違いがあります。C# や .NET などの言語は、C++ と同等のすべてのパフォーマンスチューニングオプションを提供しています。」と述べています。彼は、すべてのガベージコレクション言語をひとくくりにして否定するのではなく、しっかり学ぶべきだと言います。【管理者注:.NET はプラットフォームであり、C# は .NET の実装の一つです。C# と .NET の関係は、Java と JDK の関係に似ています。

さらに、より具体的には、MSIL と .NET は設計上 C++ もサポートしており、C# や F# などの言語でもこれらの機能にアクセスする方法があります。一部の機能が言語構文レベルで公開されていなくても、開発者は C++/CLI で生成された MSIL を直接使用できます。

これについて、あなたはどう思いますか?コメントであなたの意見をお聞かせください。

参考リンク:

https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/

https://www.thestack.technology/microsoft-takes-on-redis-with-new-open-source-garnet-cache-store/

https://news.ycombinator.com/item?id=39752504

さらに探索

関連読書

その他の記事
同じカテゴリ / 同じタグ 2026/04/22

各OSバージョンの.NETサポート状況(250707更新)

仮想マシンとテストマシンを使用して、各OSバージョンの.NETサポート状況を確認します。OSインストール後、対応するランタイムをインストールし、Stardustエージェントを実行できることを確認します(合格条件)。

続きを読む