翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# オンラインクラスターのサイズ変更
<a name="best-practices-online-resharding"></a>

*リシャーディング*には、クラスターへのシャードまたはノードの追加と削除、およびキースペースの再分散が含まれます。したがって、クラスターの負荷、メモリ使用率、データ全体のサイズなど、シャーディングオペレーションには複数のものが影響します。最適なエクスペリエンスを得るには、均一なワークロードパターンディストリビューションのクラスターベストプラクティス全体に従うことをお勧めします。さらに、次のステップを実行することをお勧めします。

リシャーディングを開始する前に、次のことをお勧めします:
+ **アプリケーションをテストする** – 可能であれば、ステージング環境でリシャーディング中にアプリケーションの動作をテストします。
+ **スケーリング問題の早期通知の取得** – リシャーディングは計算処理能力を集中的に使用するオペレーションです。このため、リシャーディング中は CPU 使用率をマルチコアインスタンスで 80% 未満、シングルコアインスタンスで 50% 未満にすることをお勧めします。ElastiCache for Redis OSS メトリックスをモニタリングして、アプリケーションでスケーリングの問題が発生する前にリシャーディングを開始します。追跡すると有用なメトリックスは、`CPUUtilization`、`NetworkBytesIn`、`NetworkBytesOut`、`CurrConnections`、`NewConnections`、`FreeableMemory`、`SwapUsage`、`BytesUsedForCacheItems` です。
+ **スケーリングする前に、空きメモリが十分に確保されていることを確認する** – スケーリングする場合、保持するシャードの空きメモリが、削除するシャードに使用されているメモリの 1.5 倍以上であることを確認します。
+ **オフピーク時にリシャーディングを開始する** – このプラクティスは、リシャーディングオペレーションがクライアントのレイテンシーとスループットに与える影響を軽減するのに役立ちます。また、スロット再分散に多くのリソースを使用できるため、リシャーディングをより迅速に完了できます。
+ **クライアントのタイムアウト動作を確認する** – オンラインクラスターのサイズ変更中に、一部のクライアントでレイテンシーが長くなる場合があります。より大きなタイムアウトでクライアントライブラリを設定すると、サーバーがより高い負荷条件でもシステムが接続する時間を与えることができます。場合によっては、サーバーへの接続を多数開く必要があります。この場合、エクスポネンシャルバックオフを追加してロジックを再接続することを検討してください。こうすると、サーバーに対して大量の新しい接続が同時に行われるのを防ぐことができます。
+ **すべてのシャードに関数を読み込む** – クラスターをスケールアウトすると、ElastiCache は (ランダムに選択された) 既存のノードのいずれかにロードされた関数を新しいノードに自動的にレプリケートします。クラスターに Valkey 7.2 以上または Redis OSS 7.0 以上があり、アプリケーションで[関数](https://valkey.io/topics/functions-intro/)を使用している場合は、スケールアウトする前に、クラスターがシャードにより異なる関数定義にならないように、すべての関数をすべてのシャードに読み込むことをお勧めします。

リシャーディング後は、以下の点に注意してください:
+ ターゲットのシャードで十分なメモリが利用できない場合、スケールインが部分的に成功している可能性があります。そのような結果が生じた場合、必要に応じて使用可能なメモリを確認し、オペレーションを再試行してください。ターゲットのシャードのデータは削除されません。
+ `FLUSHALL` および `FLUSHDB` コマンドは、リシャーディング操作中の Lua スクリプト内ではサポートされません。Redis OSS 6 より前では、移行中のスロットで動作する `BRPOPLPUSH` コマンドはサポートされていません。