DragonflyDBとKeyDBの比較: Redis互換性およびKubernetes親和性

1. Redis互換性

Redisコマンドのサポート範囲

DragonflyDB: RedisおよびMemcachedのAPIに対応しており、既存アプリケーションのコード変更なしに置き換え可能と謳っています (Documentation | Dragonfly)。実際、主要なRedisコマンドの大部分（2024年9月時点で250以上のコマンド）を実装済みで、一般的な利用シナリオはほぼカバーしています (After migration from Redis to Dragonfly issues - Discourse)。Luaスクリプト機能（RedisのEVALコマンド等）にも対応しており、Redis 5系のAPIに近い互換性を持つとされています (After migration from Redis to Dragonfly issues - Discourse) (What Is Dragonfly?)。一方で、Redisモジュール機能（外部プラグインライブラリ）には現時点では対応していないようです。また、一部特殊なコマンド（Redis Cluster用の管理コマンド等）は限定的なサポートに留まります。

KeyDB: Redis 5をベースに開発されたマルチスレッド対応のフォークであり、RedisのAPIおよびプロトコルと完全な互換性を保つことを目標としています (Compatibility | KeyDB - The Faster Redis Alternative)。そのため、Redisで使用できる全てのコマンドがKeyDBでも同様に使えます。KeyDBはRedisの最新バージョンのコマンドにも追随しており（例：Redis Streams等のデータ型や機能）、クライアントライブラリもそのまま利用できます (Compatibility | KeyDB - The Faster Redis Alternative)。さらに、KeyDBはRedisモジュールやLuaスクリプトにも対応しており、これらも含めてRedisと同等に動作するよう実装されています (databases/keydb: High performance fork of Redis - FreshPorts)。トランザクション（MULTI/EXECの原子性）やLuaのスクリプト実行の原子性もRedisと同じ保証が提供されています (databases/keydb: High performance fork of Redis - FreshPorts)。

クラスター構成の対応

DragonflyDB: Redisのクラスターモード（データをシャーディングして複数ノードに分散するモード）に対しては、単一ノードでのエミュレーションによる部分的な互換を提供しています。現時点でDragonflyDB自体はRedisのようなネイティブな分散クラスターモードを実装しておらず、CLUSTER系コマンドのフルサポートはありません (Does the dragonfly support the redis cluster mode ? #445 - GitHub)。代わりに「エミュレーテッド・クラスターモード」として、一つのDragonflyインスタンスがRedisクラスタと同様の振る舞いをする機能があります (Install Dragonfly as a Multi Node Cluster using k8s operator)。このモードでは単一のDragonflyが論理的に複数スロットを持ち、Redis Cluster対応のクライアントからのCLUSTER SLOTS等の問い合わせに応答できるため、Redis Cluster環境からシングルノードDragonflyへの移行が容易になるよう配慮されています (Install Dragonfly as a Multi Node Cluster using k8s operator) (Migrating from a Redis Cluster to Dragonfly on a single node)。ただし実際のデータ分散は行われず、スケールアウトは単一マシン内での垂直スケールに依存します（Dragonflyはマルチスレッドで1ノードあたり高い性能と大容量を実現する設計です）。将来的なマルチノード対応クラスターモードの計画については言及されていますが（実験的なプレビューなど）、2025年初現在では正式なマルチノードクラスタ機能は未提供と考えられます。

KeyDB: KeyDBはRedisクラスターと同様の分散クラスターモードをサポートしています。KeyDBクラスターモードでは、データが自動的に複数のノード間でシャーディングされ、各ノードがハッシュスロットを分担します (In Depth Cluster Tutorial | KeyDB - The Faster Redis Alternative)。このため、Redis Cluster対応のクライアントやツールを用いてKeyDBクラスタに接続し、シームレスにデータ分散を活用できます。KeyDBクラスタは稼働中にノードの追加・削除にも対応しており、リシャーディングをオンラインで行う機能も備えます (Cluster Specification | KeyDB - The Faster Redis Alternative)。加えて、KeyDB独自の特徴としてマルチマスター（アクティブ-アクティブ）構成を選択することも可能です。後述するように、複数のノードをすべてマスター（書き込み可能）として動作させ、内部で非同期にデータを複製・マージする「Active Replica」モードがあり、これにより単一クラスタ内での可用性向上やマルチサイト展開が可能です (Is KeyDB 5x Faster than Redis? We Tested! - InfraCloud)。総じて、KeyDBはRedis Cluster相当のシャーディングとマルチマスターによる拡張の両方をサポートし、高いスケーラビリティと柔軟性を提供します。

レプリケーションおよび永続性のサポート

DragonflyDB（レプリケーション）： DragonflyはRedisと同様のマスター-レプリカ非同期レプリケーションをサポートしています。RedisでおなじみのREPLICAOFコマンドやROLEコマンドによってレプリカを設定・管理でき、レプリケーション管理APIはRedisと互換性があります (Replication | Dragonfly)。1つのプライマリ（マスター）インスタンスに対し複数のセカンダリ（レプリカ）を配置し、マスターのデータをリアルタイムで複製することで高可用性(HA)を実現できます。フェイルオーバー（マスター障害時の自動昇格）に関しては、RedisのSentinelのような専用仕組みは提供されていませんが、後述のKubernetesオペレーター等でカバーされています。Dragonflyはマルチマスター構成をサポートしておらず、あくまで一方向の非同期レプリケーション（マスター→レプリカ）のみとなります。

DragonflyDB（永続性）： インメモリデータストアではありますが、スナップショットによる永続化(RDB方式)をサポートしています。Redisと同様に、手動または自動の間隔指定によりメモリ上のデータをRDBファイルとしてディスクに書き出すことが可能です (Saving Backups - Dragonfly)。Dragonflyのスナップショット機構はフォークレスで高速に動作するよう工夫されており、大容量データでも短時間でバックアップを取得できます (dragonfly/docs/rdbsave.md at main - GitHub)。一方、Append Only File (AOF) 方式の永続化（更新ごとにログ追記する方式）については現時点でサポートされていません (Append Only File (AOF) - Dragonfly)。公式によればコミュニティからの高優先度の要望が少ないため未実装とのことです (Append Only File (AOF) - Dragonfly)。そのため、Dragonflyで高いデータ耐久性が必要な場合は短間隔のスナップショットを併用するか、他の手段で対処する必要があります。

KeyDB（レプリケーション）： KeyDBはRedisと同様のマスター-レプリカ型レプリケーションを備えており、基本的な挙動（非同期レプリケーション、再接続時の自動完全同期など）はRedisと同一です (KeyDb Redis support - ServiceStack Customer Forums)。さらに特徴的なのは、Active-Active方式のマルチマスター・レプリケーションをサポートする点です (KeyDB active-active replication in a multi-site kubernetes environment)。KeyDBの「Active Replica」機能を有効化すると、複数のノードがすべてマスターとして振る舞い、各ノードへの書き込みが他のマスターにも非同期複製されます (Is KeyDB 5x Faster than Redis? We Tested! - InfraCloud)。競合した更新に対しては**「最後に書き込まれた内容を優先（Last-write-wins）」**というポリシーで自動マージされるため、強整合ではありませんが最終的整合性(Eventual Consistency)でデータの一貫性を保ちます (some clarifications regarding replication · Issue #40 · Snapchat/KeyDB) (Is KeyDB 5x Faster than Redis? We Tested! - InfraCloud)。このマルチマスター機能により、リージョン分散や高可用性をよりシンプルに実現でき、フォールトトレランスを高めることが可能です。ただし、完全な強整合が要求されるケースではシングルマスター運用が推奨されます。

KeyDB（永続性）： KeyDBはRedisと同じ永続化方式（RDBスナップショットとAOF）をサポートしています (Redis Alternative — KeyDB. Introduction | by Fabricio Pedroso Jorge)。デフォルト設定や動作もRedisに準じており、RDBによる一定間隔スナップショットやAOFによる逐次書き込みログの保持が可能です (Redis Alternative — KeyDB. Introduction | by Fabricio Pedroso Jorge)。たとえば、あるMedium記事では「KeyDBはRedisと同様にRDBとAOFの両方の永続化手段を提供している」と紹介されています (Redis Alternative — KeyDB. Introduction | by Fabricio Pedroso Jorge)。そのため、KeyDBを使用する際はRedis同様にappendonly yes等の設定でAOFを有効化でき、AOF+RDB併用による冗長な永続化も構成できます。特筆すべき違いとして、Bitnami提供の公式DockerイメージではAOFがデフォルト有効となっている例もあります (bitnami/keydb - Docker Image)（これは起動時にデータを確実に復元するための設定）。総じてKeyDBは永続化に関してRedis互換であり、運用上の知見もそのまま活かせます。

Redis互換性の比較表

項目	DragonflyDB	KeyDB
コマンド互換性	Redisの主要コマンドを網羅（約250+コマンドをサポート） (After migration from Redis to Dragonfly issues - Discourse)。モジュールは未対応。	Redisの全APIに対応するドロップイン代替 ([Compatibility
クラスターモード	マルチノードのRedis Clusterプロトコルは未実装。単一インスタンスでクラスタをエミュレートし、Clusterクライアント互換を提供 (Install Dragonfly as a Multi Node Cluster using k8s operator)。	Redis Cluster同等のシャーディング対応クラスターモードを実装 ([In Depth Cluster Tutorial
レプリケーション	マスター-レプリカ方式（非同期）に対応 ([Replication	Dragonfly](https://www.dragonflydb.io/docs/managing-dragonfly/replication#:~:text=The%20Dragonfly%20replication%20management%20API,If%20you%27re))。複数レプリカでHA構成可。マルチマスター不可。
永続化	RDBスナップショットによる永続化をサポート（自動・手動） (Saving Backups - Dragonfly)。AOFは非対応 (Append Only File (AOF) - Dragonfly)。	RDBスナップショットとAOFログ双方をサポート ([Redis Alternative — KeyDB. Introduction

2. Kubernetesとの親和性

Kubernetes環境でのデプロイ容易性

DragonflyDB: Dragonfly公式がKubernetes向けのデプロイ手順を用意しており、Helmチャートによる簡単なデプロイをサポートしています (Install on Kubernetes with Helm Chart - Dragonfly)。公式Dockerイメージも提供されているため、Kubernetes上でStatefulSet等を用いて直接デプロイすることも可能です。公式Helmチャートを使うことで、必要なConfigMapやServiceなども自動作成され、最小限の設定でクラスタ内にDragonflyインスタンスを起動できます。加えて、後述のように公式のKubernetes Operatorも公開されており、これを利用すればカスタムリソース定義(CRD)を通じてDragonflyをデプロイ・管理できます。例えば公式ガイドには、Helmチャートを用いてhelm upgrade --installコマンド一発でDragonflyをクラスタにインストールする手順が示されています (Install on Kubernetes with Helm Chart - Dragonfly)。以上より、DragonflyはKubernetes上でのセットアップが比較的容易であり、公式サポートが手厚いと言えます。

KeyDB: KeyDBも公式イメージがDocker Hubに公開されており、Kubernetes上に導入可能です。Helmチャートについては、コミュニティやベンダー提供のものが複数存在します。代表的なものとしてBitnamiによるKeyDB Helmチャートがあり、シングルマスター＋レプリカ構成（高可用性構成）を簡単にデプロイできます (keydb 0.3.2 · bitnami/bitnami - Artifact Hub)。このチャートではarchitecture=replication等の値を指定することで、マスター用StatefulSetとレプリカ用StatefulSetが自動的に展開され、マスターのServiceとレプリカのServiceも構成されます (keydb 0.3.2 · bitnami/bitnami - Artifact Hub)。一方、KeyDBの特徴であるマルチマスター(Active-Active)構成に対応したHelmチャートもコミュニティから提供されています (keydb 0.48.0 · helm/enapter - Artifact Hub)。例えばArtifact Hub上のEnapter社提供のチャートは、複数Pod全てをマスターとするStatefulSetを起動し、各ノード間でActive-Activeレプリケーションを有効化することで高可用性を実現します (keydb 0.48.0 · helm/enapter - Artifact Hub)。このように、KeyDBは用途に応じて複数のHelmチャートから選択でき、Helmを用いたデプロイも比較的容易です。ただし、公式として一本化されたHelmチャートがDragonflyほど明示されていないため、利用するチャートのメンテナンス状況や機能対応状況を確認することが推奨されます。

Helmチャートの有無

• DragonflyDB: 公式のHelmチャートが用意されています。DragonflyDB公式サイトのドキュメントにHelmによるインストール手順が記載されており (Install on Kubernetes with Helm Chart - Dragonfly)、Helmリポジトリからチャートを取得可能です。また、HelmチャートはDragonflyDB Operatorの内部でも利用されており、設定項目が充実しています。デフォルトでシングルインスタンス（必要に応じてレプリカ付き）構成がデプロイされ、PrometheusのServiceMonitorやGrafanaダッシュボードの設定オプションも含まれるなど、運用しやすい作りになっています（※公式ブログなどでHelm値の例が紹介されています）。

• KeyDB: 公式が直接管理するHelmチャートはありませんが、Bitnamiやコミュニティ提供のチャートが存在します。Bitnami版はRedisチャートに準じた構成で、シンプルなマスター-スレーブ(レプリカ)構成をすぐデプロイ可能です。Active-Activeモード用にはEnapter社のチャート（Artifact Hubで公開）や、Snap社コミュニティによるKeyDB Operator付属のチャートなどが利用できます (keydb 0.48.0 · helm/enapter - Artifact Hub)。公式ドキュメントでも「KeyDB Multimaster Helm Chart」という名称でマルチマスター設定用のチャートに言及があり、Kubernetes上でのActive-Active構成を簡便化しています (Download Options for KeyDB | KeyDB - The Faster Redis Alternative)。したがって、KeyDBもHelmチャートによるデプロイ手段が複数存在し、用途に応じて選択できます。

オートスケーリングおよびオペレーター対応状況

DragonflyDB: Dragonflyは公式のKubernetes Operatorが提供されています (A Kubernetes operator to install and manage Dragonfly instances.)。このOperatorは、CustomResourceDefinitions (CRD) を通じてDragonflyインスタンスを管理し、自動フェイルオーバーやスケーリングをサポートします (A Kubernetes operator to install and manage Dragonfly instances.)。具体的には、Operator経由でDragonflyクラスターオブジェクトを作成すると、内部でStatefulSetやServiceが生成され、プライマリ／レプリカ構成が自動的にセットアップされます。マスター障害時にはOperatorが自動でレプリカを昇格し、サービス切り替えを行う自動フェイルオーバー機能があります (A Kubernetes operator to install and manage Dragonfly instances.)。スケーリングに関しては、Dragonfly自体が前述のように垂直スケール志向（1ノード内での性能向上）ですが、Operatorではレプリカ数の増減（水平スケール）も設定可能になっています (A Kubernetes operator to install and manage Dragonfly instances.)。例えばCRDのスペックでreplicasを増やせば複数のレプリカPodが起動し、読み取り負荷を分散できます（書き込みは単一マスターに集中）。ただし、Redis Clusterのようなシャーディングによる水平スケールではなく、あくまでリードレプリカの増減によるスケールアウトです。そのため、CPUやメモリ利用率に応じた自動的なHorizontal Pod Autoscaler (HPA) 連携は現状ありませんが、Operatorを介して手動もしくはカスタムメトリクス連携でスケール調整することは可能です。総じてDragonfly OperatorによりKubernetes上での運用自動化が図られており、特にフェイルオーバーの自動化は大きな利点です (A Kubernetes operator to install and manage Dragonfly instances.)。

KeyDB: KeyDB向けにはコミュニティ主導のKeyDB Operator（Krestomatio社などによるAnsibleベース実装）が存在します (keydb-operator 0.3.13 - Artifact Hub)。このOperatorを使用すると、KeyDBのデプロイ・管理が容易になり、例えばCRDでマルチマスター構成のKeyDBクラスタを定義すると、自動的に各Pod間でActive-Activeレプリケーション設定が施されます。また、Operatorは構成に応じてServiceやConfigMapを生成し、シークレット管理やモニタリング設定もサポートします。BitnamiのHelmチャート自体にはOperatorは含まれませんが、Helmでデプロイしたマスター/レプリカ構成でもKubernetesの機能（例えばStatefulSetのreplicas変更やkubectl rollout restartによる再起動）により手動でスケーリングやフェイルオーバー対応は可能です。オートスケーリングについては、KeyDBクラスターモードを利用すればノード追加によるスケールアウトが技術的には可能です (Cluster Specification | KeyDB - The Faster Redis Alternative)。しかし、自動でHPAがPodを追加してクラスタに参加させる仕組みは標準では提供されていません。必要に応じて運用者がCLUSTER MEETコマンドやOperatorの機能でノードを追加し、再シャーディングを行う形になります。Active-Activeモードの場合、読み書きトラフィックが各マスターに分散されるため、負荷分散を用いたスケーリング効果が得られます (KeyDB server on Fly - GitHub)。例えば複数のKeyDBマスターPodの上にServiceを配置し、Round-robinでリクエストを分散すれば、自動ではないもののHPA的なスケールアウトと同等の効果が期待できます。まとめると、KeyDBはシャーディングとマルチマスターの組み合わせによって水平スケーラビリティを確保できますが、その管理を自動化する仕組みは利用するOperatorやツールに依存します。

クラウドネイティブ機能（Service Discovery、HPAなど）

Service Discovery（サービスディスカバリ）: 両者ともStatefulSet上にデプロイされるケースが多く、各Podに固定のホスト名が割り当てられます。加えて、Serviceリソースを通じた接続が基本となります。DragonflyDBの場合、HelmチャートまたはOperatorがデプロイ時に自動生成するService（ClusterIPもしくはHeadless Service）があり、クライアントはそのService経由でDragonflyに接続します (Connect to Dragonfly on Kubernetes - Discourse)。単一インスタンス構成ではServiceはそのままマスターPodを指し、レプリカを伴うHA構成の場合、OperatorがプライマリPodに選択的に流すServiceと、各レプリカに接続可能なServiceを用意することが想定されます。フェイルオーバー時にはOperatorがプライマリのService先を新マスターに切り替えることで、クライアントからは透過的に新マスターへ接続されます。このようにOperator＋Serviceによる役割の分離により、アプリケーション側は常に一定のエンドポイント（例：dragonfly-primary.default.svc.cluster.local）を参照するだけで済み、クラスタ内のPod変更を意識する必要がありません。

KeyDBでは、クラスターモード時はRedis Clusterと同様にクライアントがクラスタ内ノード情報を把握して接続します。初期接続先としてService（全Podを選択するHeadless Serviceなど）を指定すれば、クライアントはCLUSTER SLOTSコマンドで各ノードのアドレスを取得し、以降は直接各Podに通信する形になります。したがって、Redis Cluster対応クライアントライブラリを使えばサービスディスカバリは自動で行われます。一方、Active-Activeマルチマスター構成では、各ノードが常に全データを保持するため任意のノードにアクセスしても結果は同じになります。そのため、Kubernetes上では全マスターPodをセレクターに含むServiceを一つ用意し、ロードバランシングでリクエストを分散するというシンプルな構成が可能です。この場合クライアントは単一のServiceエンドポイントに接続するだけで、高可用かつスケーラブルなKeyDBクラスタを利用できます。例えばあるユーザ事例では、複数リージョンに配置したKeyDB間でActive-Active同期を行い、各リージョンのアプリケーションはローカルのKeyDB Serviceに書き込みつつグローバルにデータ整合性を保つ、といった使い方も報告されています (Our experience with using KeyDB as Multi-Master and Active Replica)。

Horizontal Pod Autoscaling (HPA): HPAによる自動スケールはステートフルなデータストアでは注意が必要です。DragonflyもKeyDBも、CPU使用率などでPod数を機械的に増減させても、自動でデータが分散されたりレプリカが調整されたりしないため、標準のHPA機能をそのまま適用することは推奨されません (Issue #3114 · dragonflydb/dragonfly - Horizontal Scaling - GitHub)。代替として、例えばKeyDBクラスタでは運用者が手動でクラスタノードを追加し、必要に応じてKubernetesノード自体のオートスケール（Cluster Autoscaler）と組み合わせてリソースプールを拡張する、といった形になります。Dragonflyの場合、前述のとおり基本は垂直スケーリング（CPUコア数やメモリ増強）で対応し、性能限界時に追加インスタンスを立てて分割運用する選択となります。Dragonfly Operatorは水平方向のスケール手段も提供していますが (A Kubernetes operator to install and manage Dragonfly instances.)、これもレプリカ増設によるスケールアウトであり、アプリケーションから書き込み負荷そのものを分散するにはKeyDBのマルチマスター構成のほうが適しています。

以上をまとめると、DragonflyDBは公式HelmチャートとOperatorによってKubernetes環境への統合が進んでおり、主にシングルインスタンス性能とレプリカによるHAにフォーカスしています。一方KeyDBは複数のチャートやOperatorを活用してクラスタ構成やマルチマスター構成を柔軟にデプロイでき、水平スケーリングやマルチサイト展開まで見据えた機能を持っています。それぞれアプローチは異なりますが、どちらもクラウドネイティブ環境で動作させるための基本的なコンポーネント（コンテナイメージ、Helm/Opertor、サービスディスカバリ機構）は揃っていると言えるでしょう。

Kubernetes親和性の比較表

項目	DragonflyDB	KeyDB
デプロイ容易性	公式Dockerイメージ提供。公式Helmチャートにより迅速にデプロイ可能 (Install on Kubernetes with Helm Chart - Dragonfly)。Operator経由の管理も対応。	公式イメージ提供。Bitnami製など複数のHelmチャートあり、用途に応じマスター＋レプリカやマルチマスター構成を簡単に展開可能 (keydb 0.48.0 · helm/enapter - Artifact Hub)。
Helmチャート	公式Helmチャートあり（単一インスタンス＋オプションでレプリカ構成）。モニタリング統合など設定項目も豊富。	公式チャートは無いがBitnami他コミュニティ製チャートが利用可。マルチマスター用のHelmチャートも提供されている (keydb 0.48.0 · helm/enapter - Artifact Hub)。
Operatorによる管理	公式Operatorあり (A Kubernetes operator to install and manage Dragonfly instances.)。CRDを介しデプロイ管理、自動フェイルオーバーやスケール調整を実装 (A Kubernetes operator to install and manage Dragonfly instances.)。	コミュニティOperatorあり (keydb-operator 0.3.13 - Artifact Hub)（Ansible製）。CRDでKeyDBクラスタを管理、Active-Active同期設定等を自動化。
水平スケーリング	垂直スケール中心。水平スケールはレプリカ追加による読み取りスケールに限定（シャーディング不可）。Operatorでレプリカ数管理。	クラスターモードでシャーディング対応 ([In Depth Cluster Tutorial
サービスディスカバリ	Operator/HelmがServiceを生成。プライマリ用Service経由で接続し、フェイルオーバー時は内部で切替 (Connect to Dragonfly on Kubernetes - Discourse)。	クラスターモードではクライアントがクラスタ情報を取得して各ノードに接続。マルチマスター時は全Podを束ねるServiceで一括接続可能。
HPA対応	標準HPAの直接適用は非推奨（ステートフルのため）。必要に応じOperator＋カスタムメトリクスで手動的にスケール。	標準HPA適用は非推奨。クラスタノード追加でスケールアウト可能だが自動化には工夫が必要。マルチマスター＋Serviceで負荷分散しスケール効果。

参考文献:

【0】DragonflyDB Docs – Replication (公式ドキュメント) (Replication | Dragonfly); 【1】DragonflyDB Docs – Overview (Documentation | Dragonfly); 【3】DragonflyDB Discourse – 「RedisからDragonflyへの移行」 Q&A (After migration from Redis to Dragonfly issues - Discourse); 【12】KeyDB Docs – Cluster Specification (In Depth Cluster Tutorial | KeyDB - The Faster Redis Alternative) (Cluster Specification | KeyDB - The Faster Redis Alternative); 【17】KeyDB Docs – Compatibility (Compatibility | KeyDB - The Faster Redis Alternative); 【18】KeyDB GitHub README (databases/keydb: High performance fork of Redis - FreshPorts); 【22】DragonflyDB Discourse – クラスターモードに関するコメント (Install Dragonfly as a Multi Node Cluster using k8s operator); 【25】DragonflyDB Docs – Append Only File (AOF) 未対応について (Append Only File (AOF) - Dragonfly); 【26】DragonflyDB Docs – Snapshotとバックアップ (Saving Backups - Dragonfly); 【27】InfraCloud – 「Is KeyDB 5x Faster than Redis?」記事 (Is KeyDB 5x Faster than Redis? We Tested! - InfraCloud); 【23】Artifact Hub – KeyDB Helm Chart (enapter) (keydb 0.48.0 · helm/enapter - Artifact Hub) (keydb 0.3.2 · bitnami/bitnami - Artifact Hub); 【5】Artifact Hub – KeyDB Operator (Krestomatio) (keydb-operator 0.3.13 - Artifact Hub); 【29】DragonflyDB Operator GitHub – 機能一覧 (A Kubernetes operator to install and manage Dragonfly instances.); 【6】DragonflyDB Docs/Discourse – Kubernetes接続に関する記述 (Connect to Dragonfly on Kubernetes - Discourse); 【30】Medium – 「Redis Alternative — KeyDB」記事 (Redis Alternative — KeyDB. Introduction | by Fabricio Pedroso Jorge).