Redis をしばらく使用していて、ワークロードの増大に伴う問題に遭遇し始めているのは、あなただけではありません。当社お客様の多くは Redis から Aerospikeに移行しており、その数は増え続けています。
弊社のお客様は、初めて Redis を導入したときに、使いやすいと言ってくれました。
しかし、データ量とワークロードが増加し続けると、状況は急速に変化します。これが起こると、新しいアプリケーションをより迅速に提供すること、5 テラバイトを超えるデータに機械学習などの分析テクノロジーを適用すること、信頼性が高く魅力的なユーザー エクスペリエンスを提供すること、またはデジタル変革プロジェクトを展開することなど、より大きな課題に直面することになります。
これは、私たちが取引している多くの企業にとって一般的な状況です。
彼らは、Redis による高い所有コスト、大規模なパフォーマンスの低下、運用の複雑さの増加が想像していたよりも悪いことに気づきました。
IT 予算の超過、サービス レベル アグリーメント (SLA) 違反、アプリケーションのロールアウトの遅延に直面した彼らは、代替手段を探すことになります。
ここで Aerospikeが役立ちます。
Aerospikeは、読み取り/書き込みワークロードの超高速ランタイム パフォーマンス、高可用性、ほぼ線形のスケーラビリティ、強力なデータ一貫性をすべて他の代替手段の数分の一のコストで提供する NoSQLキーバリューデータベースです。
また、世界で最も革新的で業界をリードする企業のハイパースケール データ プラットフォームを強化しており、多くの場合、 確実に拡張できないRedis やその他の従来の NoSQL データベースを置き換えています。
Redis なしでデータベースを拡張できる時代が来ました
それでは、ユーザーがRedisを使いこなせていない兆候は何でしょうか？
Redis に関する問題を抱えたユーザーから学んだことは次のとおりです。
総所有コスト (TCO) の懸念
データ量の急増と競争圧力により、企業は新しいアプリケーションをより迅速に提供し、大規模なデータセットをリアルタイムで処理する必要に迫られています。
このような要求は Redisクラスターにストレスを与える可能性があり、より多くのノード、メモリ、人員を導入する必要が生じるため、総所有コスト が増加します。
データベースのスケーラビリティと柔軟性の必要性
Redis はインメモリ処理用に設計されたシングルスレッド システムであるため、企業は拡張するためにノードと DRAM を追加することがよくあります。
しかし、DRAM は高価であり、ますます大規模になるクラスターを管理するのは簡単ではありません。
Redis on Flash (ROF) は、メタデータとインデックスをメモリ内に保持し、パフォーマンスのために「ホット」データをキャッシュし、バックグラウンドでメモリを大量に消費する RocksDB プロセスに依存するため、これらの問題を解決しません。
Redis 構成要件も柔軟性を阻害します。
企業はクラスターを現在のシャード数の倍数でスケールアウトすることしかできず、一度作成されたクラスターからシャードを削除することはできません。
そのため、ピーク期の前にスケールアップしたり、ピーク後にスケールダウンしたりすると、手間と費用がかかる可能性があります。
高いパフォーマンスを維持するための持続性
Redis は、完全なDRAMインスタンスを使用し、ユーザーデータのコピーを一つだけ使用するベンチマークを公開しています。
これは、企業が実稼働環境で必要とするものとは大きく異なり、ハイパーセールのユースケースを扱う際に見られるユーザー環境とも一致しません。
多くの人が気づいているように、スナップショットや追加専用ファイルを介して Redis に永続化すると、パフォーマンスが低下し、さらにはデータ損失につながる可能性があります。
強力なデータ一貫性の必要性
企業がデータの一貫性が必須となるミッションクリティカルなアプリケーションを構築している場合、Redis は正しい選択ではない可能性があります。
Redis は、強力な一貫性に関する Jepsen テストに合格していません (一方、 Aerospikeは合格しています)。
Redis は結果整合性をサポートしています。これにより、特定の状況下では読み取りが失われ、さらにはデータ損失が発生する可能性があります。
Redis は、一貫性と最も密接に関連する WAIT コマンドをリリースしましたが、Redisのドキュメントでは 、WAIT によって Redis が強整合性ストアになるわけではないことが認められています。
支払いが関係する金融サービス会社や電子商取引会社の場合、WAIT コマンドによって実装される結果整合性アプローチは適切ではありません。
大規模な管理性と運用の容易さの必要性
Redis のスケーリングには大量のメモリが必要であり、大規模なクラスターが必要になります。
これは、より複雑でノード障害がより頻繁に発生することを意味します。
データへのアクセスを高速化するために永続 SQL または NoSQL データ ストアのメモリ内キャッシュとして Redis を使用していたお客様は、アプリケーションが古いデータにアクセスしたり、キャッシュが原因でパフォーマンスが低下したりしないように、両方の環境の管理と同期に懸命に取り組んでいました。
2 つのシステムを拡張するための運用コストをカバーすることは、特にデータ量とワークロードが増大するにつれて、困難になる可能性があります。
この種の環境の管理に必要なスタッフ リソースは、既存のアプリケーションの保守ではなく、新しいアプリケーションの構築または展開に費やされる可能性があります。
これらの兆候が 1 つ以上発生したことがある場合は、Redis データベースが適切に機能していない可能性があります。
このブログは2021年8月5日「Redis vs. Aerospike: The differences between NoSQL databases」の翻訳です。
