ElastiCache for Redis がスケーリングしているときに、ダウンタイムを最小限に抑えるにはどうすればよいですか?

所要時間1分
0

Amazon ElastiCache for Redis がスケーリングされている間、ダウンタイムを最小限に抑えたい。これを行うにはどうすればよいですか?

解決方法

ダウンタイムを最小限に抑えるには、次の点を考慮してください。

  • 同期の影響を最小限に抑えるには、高いワークロードの下でのスケーリングを避けてください。クラスターのワークロードが高く、スケーリングに時間がかかる場合は、同期の失敗を防ぐために Redis への受信リクエストを減らします。スケーリングプロセス中に、同期 (バックグラウンド保存、フォーク、またはフォークレス) がトリガーされることがあります。同期は計算負荷の高い操作であり、余分なメモリを消費します。Amazon CloudWatch の SaveInProgress メトリクスをチェックして、同期がいつ行われたかを確認します。このメトリクスは毎分データを収集することに注意してください。このため、メトリクスは 1 分未満で完了した同期をキャプチャしない場合があります。ワークロードのモニタリングの詳細については、「Amazon CloudWatch を使用した Amazon ElastiCache for Redis によるベストプラクティスのモニタリング」を参照してください。
  • スケーリングタイプによっては、新しいノードが参加したり、ノードがクラスターから削除されたり、スケーリング中にノードの IP が変更されたりすることがあります。Amazon ElastiCache for Redis には、クラスターに接続するためのさまざまなタイプの接続エンドポイントが用意されています。接続エンドポイントのタイプの選択は、アプリケーションの要件によって異なります。ベストプラクティスとして、非本番環境でスケーリングをテストして、Redis クラスターの接続中にクライアント側での構成ミスが原因で発生する予期しない問題を特定します。
  • クライアントが同期中の新しいレプリカに接続すると、「LOADING**: Redis はデータセットをメモリにロードしています**」というエラーが表示されます。別のレプリカでクエリを再試行するか、クエリをプライマリノードに送信するように Redis クライアントまたはアプリケーションコードを設定します。データセットのロードにかかる時間は、データサイズとノードのパフォーマンスによって異なります。テスト環境でテストして、これが問題になるかどうかを判断します。
  • 手動でスケーリングする代わりに、自動的にスケーリングするようにクラスターを設定できます。自動スケーリングは、受信するワークロードの急激な増加によって引き起こされるパフォーマンスの問題を防ぎます。詳細については、「ElastiCache for Redis クラスターの自動スケーリング」を参照してください。

スケーリングアクションのダウンタイムの概要

次の 4 つのスケーリングアクションがあります。

  • スケールインする。
  • スケールアウトする。
  • ノードタイプを変更する。
  • ノードグループの数を変更する。これは Redis (クラスターモード無効) クラスターでのみサポートされます。

詳細については、「ElastiCache for Redis クラスターのスケーリング」を参照してください。

通常、スケーリングアクションとクラスター構成によっては、スケーリングのダウンタイムは最大で数秒かかる場合があります。以下は、各クラスタータイプとスケーリングアクションのダウンタイムの説明です。

Redis (クラスターモード無効) クラスター

スケールイン: スケールインすると、クラスターからレプリカノードが削除されます。これは、コストを削減するために行う場合があります。スケールインするとデータの耐久性も低下することに留意してください。アプリケーションがプライマリエンドポイントのみを使用してクラスターに接続する場合、レプリカノードを削除してもダウンタイムは発生しません。これは、プライマリエンドポイントがプライマリノードを指しているためです。

ただし、アプリケーションがリーダーエンドポイントまたは個別のエンドポイントを使用してそのレプリカノードに接続する場合、削除されたレプリカノードへの元の接続が切断され、アプリケーションは他のレプリカノードへの新しい TCP 接続を確立する必要があります。また、削除したレプリカノードに接続しないように、アプリケーションは DNS ルックアップを再度実行する必要があります。クライアントがリーダーエンドポイントを使用している場合、リーダーエンドポイントの DNS 伝播によって数秒間のダウンタイムが発生する可能性があります。

スケールアウト: スケールアウトすると、既存のクラスターにレプリカノードが追加されます。プライマリノードは新しいノードと同期します。同期中のダウンタイムを避けるため、ワークロードが最小の時間帯にスケールアウトすることを検討してください。

ノードタイプの変更: ノードタイプを変更すると、指定したタイプの新しいノードが作成されます。古いプライマリノードは新しいプライマリノードと同期し、新しいプライマリノードは新しいレプリカノードと同期します。このスケーリングプロセスでは、次のことを確認してください。

  • ワークロードがそれほど高くないため、同期は失敗します。
  • 新しいノードの IP は、古いノードと同じではない場合があります。アプリケーションでは、プライマリエンドポイントまたはリーダーエンドポイントで DNS ルックアップを再度実行し、新しいノードへの新しい接続を確立する必要がある場合があります。DNS の伝播には数秒かかるため、クライアントが新しいノードに到達するまでにサービスが中断される可能性があります。
    Redis バージョン 5.0.5 以上では、中断が最小限に抑えられます。 Redis クライアントは、古いノードの終了によりリクエストが失敗した場合、新しいノードへのリクエストを再試行します。ElastiCache サービスの最適化の恩恵を受けるには、新しい Redis バージョンにアップグレードするのがベストプラクティスです。

Redis (クラスターモードが有効) クラスター

スケールイン: スケールインとは、クラスターからシャードを削除することを意味します。シャードが削除される前に、そのシャード内のデータが他のノードに移行されます。このプロセスは、「リシャーディング」と呼ばれます。リシャーディングを行うと、クラスターに余分なワークロードが発生し、クライアントは Redis クラスターをサポートしている必要があります。スケールイン中のダウンタイムを最小限に抑えるための情報については、「ベストプラクティス: オンラインクラスターのサイズ変更」を参照してください。

過度のスケールインによるパフォーマンスの問題を最小限に抑えるには、徐々にスケーリングすることを検討してください。たとえば、ターゲットが 12 個のシャードから 6 個のシャードにスケールインする場合、最初に 12 個のシャードから 9 個のシャードにスケールインします。最初のスケールイン後、ピーク時のクラスターのパフォーマンスを確認し、さらにスケールインします。

スケールアウト: スケールアウトすると、クラスターにシャードが追加されます。他のシャードのデータは新しいシャードに移行されます。このプロセスは、「リシャーディング」と呼ばれます。リシャーディングによってクラスターに余分なワークロードが発生し、クライアントは Redis クラスターをサポートしている必要があります。スケールアウト中のダウンタイムを最小限に抑える方法については、「ベストプラクティス: オンラインクラスターのサイズ変更」を参照してください。

ノードタイプの変更:「ノードタイプの変更」中、シャードごとに、古いプライマリノードが新しいプライマリノードと同期します。次に、新しいプライマリノードが新しいレプリカノードと同期します。このスケーリングプロセスでは、次のことを確認してください。

  • ワークロードがそれほど高くないため、同期は失敗します。
  • 新しいノードの IP は、古いノードと同じではない場合があります。IP アドレスを特定するために、アプリケーションはクラスターノードまたはクラスタースロットコマンドを使用して、クラスターから更新されたトポロジ情報を取得します。Redis クラスターをサポートするほとんどの Redis クライアントは、クラスターのトポロジを更新できます。ただし、これを実行するには Redis クライアントを設定する必要がある場合があります。Redis クライアントの設定方法の情報については、特定のクライアントタイプのドキュメントを参照してください。

ノードグループ数の変更: ノードグループの数を変更すると、各シャードのレプリカノードの数が変わります。レプリカノードの数が増えると、新しいレプリカノードがクラスターに参加し、プライマリノードが新しいノードと同期します。そのため、レプリカノードを追加する前に、プライマリノードのパフォーマンスを確認してください。レプリカノードの数が減り、削除されたレプリカノードからクライアントを読み取る必要がある場合は、新しいレプリカノードのいずれかにリクエストを送信する必要があります。また、クライアントはクラスターのトポロジを更新して、削除されたノードにさらなる要求が送信されないようにする必要があります。


関連情報

レプリケーション: Redis (クラスターモード無効) とRedis (クラスターモード有効)

ステップ 4: クラスターのノードに接続する - ノードのエンドポイントを見つける

ElastiCache for Redis クラスターのスケーリング

Redis スナップショットを作成するのに十分なメモリがあることを確認する

AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ