このトピックでは、オープンソースのRedisクラスターおよびRedis open-source Editionクラスターインスタンスで使用できるスケーリングソリューションの欠点を一覧表示し、Tair (Enterprise Edition) クラスターインスタンスで使用できる知覚できないスケーリングソリューションについて説明します。
オープンソースのRedisクラスターでは、データノードの柔軟なスケーリングとシャード間でのデータの移行に関する要件がよくあります。 ただし、これらの一般的なスケーリングソリューションには、キーベースの移行が遅い、複数のキーを含むコマンドのサポートがない、Luaスクリプトを移行できない、大きなキーの移行によって引き起こされる潜在的な待ち時間または高可用性の切り替え、移行の失敗とロールバックの処理の複雑さなどの問題があります。
これらの問題に対応して、Tairチームは、スロットレプリケーションに基づく新しいアーキテクチャを開発し、知覚できないデータ移行を保証しました。 このアーキテクチャは、インスタンス内のスレッドスケジューリングアルゴリズムを最適化して、インスタンスを効率的かつ正確に管理できるようにします。 これは知覚できないスケーリングの原理です。 次のセクションでは、オープンソースのRedisクラスターおよびApsaraDB for Redisクラスターインスタンスで使用できるスケーリングソリューションの欠点について説明し、Tairクラスターインスタンスで使用できる知覚できないスケーリングソリューションについて紹介します。
オープンソースRedisクラスターの一般的なスケーリングソリューションとその欠点
オープンソースRedisクラスターの弾性スケーリング
オープンソースのRedisクラスターは、ゴシッププロトコルを使用してデータを転送します。 データ転送中、スロット内のキーをトラバースして移行することにより、スロットが最小データセットとして移行されます。 このスケーリングソリューションには、次の問題があります。
低い安定性
データがキーによって移行されているため、同じスロットに複数のキーが含まれるコマンドが実行されない場合があります。
データの移行時にLuaスクリプトを同時にレプリケートすることはできません。 その結果、データ移行が完了するとLuaスクリプトが失われる可能性があります。
データがレプリケートされると、大きなキーの移行により、高可用性の切り替えを引き起こす可能性のある待ち時間やエラーが発生する可能性があります。
高いO&M難易度
データ移行中にエラーが発生した場合は、データベースデータを手動で復元する必要があります。 このプロセスは困難であり、時間がかかり、エラーを起こしやすい。
キーによるデータの移行には時間がかかるため、クラスターのスケーリングに時間がかかります。 これにより、企業はオフピーク時にスケーリングアクティビティを実行することを余儀なくされ、通常のビジネス運用に影響を与える可能性があります。
データ同期および移行コンポーネントに基づくスケーリング
このソリューションは、オープンソースのRedisクラスターではなくミドルウェアコンポーネントに依存してデータを移行します。 たとえば、スケーリング操作を実行するには、クラスターを作成し、ミドルウェアコンポーネントを使用してデータをクラスターに移行し、ロードバランサーコンポーネントを使用してアクセスパスを切り替えます。 このスケーリングソリューションには、次の問題があります。
完全なデータを同期するには長い時間がかかります。
スケーリング操作を実行するには2つのリソースセットを作成する必要があるため、コストが高くなります。
ロードバランサコンポーネントが切り替えを実行すると、クライアントは切断されます。 切り替えが有効になるまでに時間がかかり、サービスが最大10秒間使用できない場合があります。
ApsaraDB for Redisクラスターインスタンスの知覚不可能なスケーリングソリューションとその欠点
ApsaraDB for Redisクラスターインスタンスで使用できる知覚できないスケーリングソリューションは、オープンソースのRedisクラスターの前述の問題に対処できます。 ただし、このソリューションには次の問題もあります。
スケーリング操作中に実行されるデータ移行はインスタンスに影響し、インスタンスは数秒間読み取り専用になることがあります。
説明スケーリング操作を実行すると、データ移行のニーズが発生する場合があります。 データ移行中に、同期される増分データの合計量に対する同期された増分データの割合がしきい値未満の場合、インスタンスは読み取り専用になります。 残りの増分データが同期された後、クライアントは新しいエンドポイントを使用してインスタンスに再接続できます。 インスタンスが読み取り専用状態のときに更新リクエストがインスタンスに送信された場合、リクエストは拒否され、読み取り専用エラーが返されます。 読み取り専用エラーはスムーズに処理できず、ビジネスに影響を与える可能性があります。
スケーリング操作中に実行されるデータ移行は、通常の操作とリソースを競合します。 これにより、企業はオフピーク時にスケーリングアクティビティを実行せざるを得なくなり、スケーリング操作の柔軟性に影響を与える可能性があります。
Tairクラスターインスタンスの知覚できないスケーリングソリューション
Tairクラスターインスタンスは、集中制御コンポーネントを使用してクラスターの操作を効率的に処理する新しいアーキテクチャに基づいて構築された、知覚できないスケーリングソリューションを提供します。
このソリューションは、DRAMベースのインスタンスや永続メモリ最適化インスタンスなど、Tairクラウドディスクベースのインスタンスで使用できます。 ApsaraDB for Redis Community Editionクラウドディスクベースのインスタンスも、デフォルトでこのソリューションを使用します。
このソリューションには次の利点があります。
知覚不可能なスケーリング
Tairクラスターインスタンスがスケーリングされている間、クライアントは影響を受けず、ビジネスは中断されず、インスタンスは読み取り専用状態のままではありません。 Tairクラスターインスタンスはいつでもスケールできます。
知覚できないスケーリングの鍵は、データ移行中のインスタンスの読み取り専用期間を短縮することです。 Tairクラスターインスタンスは、残りの増分データの移行に必要な時間を動的に推定し、読み取り専用の期間をミリ秒以内に維持します。 この読み取り専用期間は、数百ミリ秒で測定されるTCP再送信時間よりもはるかに短いため、これは理論的にはインスタンスが読み取り専用状態に入るのを防ぎます。 インスタンスが読み取り専用状態のままである場合、移行されるキーに対して行われた書き込み要求は、書き込まれるのではなくインスタンスにキャッシュされます。 データ移行が完了すると、クライアントはリダイレクションメッセージを受信します。 同時に、管理システムとデータベースエンジンは連携して、データ移行が完了するとすぐにインスタンス情報を更新します。 このプロセスにより、スケーリング操作がクライアントに認識されないようになります。
スムーズなスケーリング
Tairは、クラスターインスタンス内のスレッドスケジューリングアルゴリズムを最適化して、データ移行タスクの詳細な管理を実装します。 これにより、スレッドの実行効率が10% から最大80% に向上します。 この範囲内でカスタム効率値を指定できます。 これにより、ビジネスに影響を与えることなく、データ移行速度が最大化されます。 さらに、Tairクラスターインスタンスは、応答時間 (RT) を増加させることなく、きめ細かいスケーリングをサポートし、ネットワークジッタによる高可用性の切り替えを防止します。 これにより、高いデータ信頼性が保証される。
効率的で簡単なO&M
Tairクラスターインスタンスは、次の方法を使用して、オープンソースのRedisクラスターのスケーリングの問題に対処できます。
バックグラウンドでの事前バックアップ: バックグラウンドでの事前バックアップは、Tairインスタンスに実装できます。 この方法では、移行が完了するまで、ソースインスタンスが完全に機能し続け、完全なデータセットを保持します。 これにより、大きなキーの移行によるレイテンシが防止されます。
数回のクリックによるロールバック: スケーリング中に例外が発生した場合、数回のクリックでインスタンスをロールバックできます。
スロットによるデータ移行: スロット単位でデータを移行できます。 これにより、同じスロット内の複数のキーを含むコマンドを期待どおりに実行できます。
Luaスクリプトのレプリケーション: データ移行中、LuaスクリプトをレプリケートしてLuaスクリプトの損失を防ぐことができます。
水平スケーリング: 1つのインスタンスに最大256個のシャードを追加または削除できます。
コスト効率
ミドルウェアコンポーネントを必要とするソリューションと比較して、このソリューションは2つのリソースセットを作成する必要がないため、コストを削減します。