オンラインクラスターのサイズ変更

リシャーディングを開始する前に、次のことをお勧めします:

• アプリケーションをテストする – 可能であれば、ステージング環境でリシャーディング中にアプリケーションの動作をテストします。

• スケーリング問題の早期通知の取得 – リシャーディングは計算処理能力を集中的に使用するオペレーションです。このため、再シャーディング中は、マルチコアインスタンスでは CPU 80% 未満、単一コアインスタンスでは 50% 未満の使用を維持することをお勧めします。アプリケーションがスケーリングの問題を監視する前に、メトリクスをモニタリング ElastiCache (Redis OSS) し、再シャーディングを開始します。追跡すると有用なメトリックスは、CPUUtilization、NetworkBytesIn、NetworkBytesOut、CurrConnections、NewConnections、FreeableMemory、SwapUsage、BytesUsedForCacheItems です。

• スケーリングする前に、空きメモリが十分に確保されていることを確認する – スケーリングする場合、保持するシャードの空きメモリが、削除するシャードに使用されているメモリの 1.5 倍以上であることを確認します。

• オフピーク時にリシャーディングを開始する – このプラクティスは、リシャーディングオペレーションがクライアントのレイテンシーとスループットに与える影響を軽減するのに役立ちます。また、スロット再分散に多くのリソースを使用できるため、リシャーディングをより迅速に完了できます。

• クライアントのタイムアウト動作を確認する – オンラインクラスターのサイズ変更中に、一部のクライアントでレイテンシーが長くなる場合があります。より大きなタイムアウトでクライアントライブラリを設定すると、サーバーがより高い負荷条件でもシステムが接続する時間を与えることができます。場合によっては、サーバーへの接続を多数開く必要があります。この場合、エクスポネンシャルバックオフを追加してロジックを再接続することを検討してください。こうすると、サーバーに対して大量の新しい接続が同時に行われるのを防ぐことができます。

• 関数をすべてのシャードにロードする – クラスターをスケールアウトすると、 ElastiCache は既存のノード (ランダムに選択) の 1 つにロードされた関数を自動的に新しいノード (複数可) にレプリケートします。クラスターに Valkey 7.2 以降、または Redis OSS7.0 以降があり、アプリケーションが Functions を使用している場合は、クラスターが異なるシャード上の異なる関数を消費しないように、スケールアウトする前にすべての関数をすべてのシャードにロードすることをお勧めします。

リシャーディング後は、以下の点に注意してください:

• ターゲットのシャードで十分なメモリが利用できない場合、スケールインが部分的に成功している可能性があります。そのような結果が生じた場合、必要に応じて使用可能なメモリーを確認し、オペレーションを再試行してください。ターゲットのシャードのデータは削除されません。

• 大きなアイテムのスロットは移行されません。特に、シリアル化後に 256 MB を超えるアイテムを持つスロットは移行されません。

• FLUSHALL および FLUSHDB コマンドは、リシャーディング操作中の Lua スクリプト内ではサポートされません。Redis OSS 6 より前のBRPOPLPUSHコマンドは、移行するスロットで動作する場合はサポートされていません。