クラウドで Redis を使用していますか?知っておくべき10のこと

ステートフル分散システムは大規模に運用するのが難しく、Redis も例外ではありません。マネージド データベースは、面倒な作業のほとんどを自動化することで、作業の負担を軽減します。ただし、健全なアーキテクチャが必要であり、サーバー (Redis) とクライアント (アプリケーション) の両方にベスト プラクティスを適用する必要があります。

この記事では、クラスターのスケーラビリティ、クライアント構成、統合、メトリックなど、Redis 関連のさまざまなベスト プラクティス、ヒント、コツについて説明します。 Amazon MemoryDB と ElastiCache for Redis については時々言及しますが、そのほとんどは (すべてではないにしても) Redis Cluster 全般に当てはまります。

これは決して網羅的なリストではありません。 10 を選んだのは、それが素敵で健全な数字だからです。

Redis クラスターをスケーリングするためのオプションを詳しく見てみましょう。

1. スケーラビリティオプション

拡大または縮小できます:

スケーリング（垂直） - たとえば、Amazon EC2 db.r6g.xlarge タイプから db.r6g.2xlarge にアップグレードするなど、単一のノード/インスタンスの容量を増やすことができます。
スケールアウト (水平) − クラスターにさらにノードを追加できます。スケールアウトの必要性は、いくつかの理由によって生じます。

読み取り負荷の高いワークロードを処理する必要がある場合は、レプリカ ノードを追加することもできます。これは、Redis クラスター設定 (MemoryDB など) またはクラスター モードが無効になっている ElastiCache の場合などの非クラスター化マスター レプリカ モードに適用されます。

書き込み容量を増やしたい場合は、マスターレプリカ モデルによって制限されるため、Redis クラスター ベースのセットアップを選択する必要があります。クラスター内のシャードの数を増やすことができます。これは、マスター ノードのみが書き込みを受け入れることができ、シャードごとにマスター ノードが 1 つしか存在できないためです。

これには、全体的な高可用性が向上するという追加の利点もあります。

図 1: Redis (クラスター モードが無効) と Redis (クラスター モードが有効) クラスター – ElastiCache for Redis ドキュメント

2. クラスターを拡張した後は、これらのレプリカを使用するのが最適です。

ほとんどの Redis Cluster クライアント (redis-cli を含む) のデフォルトの動作は、すべての読み取りをプライマリ ノードにリダイレクトすることです。読み取りトラフィックをスケールアウトするために読み取りレプリカを追加した場合、それらはアイドル状態になります。

レプリカが受動的な参加者だけでなくすべての読み取り要求を処理するようにするには、READONLY モードに切り替える必要があります。 Redis クライアントが正しく構成されていることを確認してください。これはクライアントとプログラミング言語によって異なります。

たとえば、Go Redis クライアントでは、ReadOnly を true に設定できます。

 クライアント: = redis 。 新しいクラスタクライアント(
 & レディス。 クラスターオプション{
 アドレス: [] 文字列{ clusterEndpoint },
 読み取り専用: true 、
 //..その他のオプション
})

さらに最適化するには、RouteByLatency または RouteRandomly を使用することもできます。どちらも ReadOnly モードを自動的にオンにします。

Lettuce などの Java クライアントがどのように動作するかを参照できます。

3. 読み取り専用レプリカを使用する場合は一貫性の特性に注意する

アプリケーションがレプリカから古いデータを読み取る可能性があります。これが最終的な一貫性です。マスター レプリカ ノードのレプリケーションは非同期であるため、マスター ノードに送信したライターがまだ読み取りレプリカに反映されていない可能性があります。この状況は、特に複数のアベイラビリティーゾーンにわたって多数の読み取りレプリカがある場合に発生する可能性があります。

これがユースケースで受け入れられない場合は、読み取りにもマスターノードを使用する必要があります。

MemoryDB または ElastiCache for Redis の ReplicationLag メトリックを使用すると、レプリカがプライマリからの変更を適用するのにどれだけ遅れているか (秒単位) を確認できます。

強い一貫性についてはどうでしょうか?

MemoryDB の場合、プライマリ ノードからの読み取りは強力に一貫性があります。これは、クライアント アプリケーションが、書き込み (プライマリ ノードへの) が永続的なマルチ AZ トランザクション ログに書き込まれた後にのみ、書き込み成功の確認を受信するためです。

4. Redisクラスタ内でキーがどのように分散されるかに影響を与えることができることを覚えておいてください

Redis は、他の多くの分散データベースのように一貫性のあるハッシュを使用する代わりに、ハッシュ スロットの概念を使用します。合計で 16384 個のスロットがあり、クラスター内の各マスター ノードにはハッシュ スロットの範囲が割り当てられ、各キーは特定のハッシュ スロットに属します (したがって、特定のノードに割り当てられます)。キーが異なるハッシュ スロットに属している場合、Redis クラスターで実行される複数キー操作は機能しません。

ただし、クラスターに完全に左右されるわけではありません。ハッシュタグを使用すると、キーの位置に影響を与えることができます。したがって、特定のキーが同じハッシュ スロットを持つことを確認できます。たとえば、顧客 ID 42 の注文を customer:42:orders というハッシュに保存し、顧客プロファイル情報を customer:42:profile に保存する場合、中括弧 {} を使用してハッシュされる特定の部分文字列を定義できます。この場合、キーは {customer:42}:orders と {customer:42}:profile です。{customer:42} がハッシュ スロットの配置を決定します。これで、両方のキーが同じハッシュ スロット (つまり同じノード) にあることが確実になりました。

5. 規模を縮小することを検討したことがありますか?

あなたのアプリは成功しており、多くのユーザーとトラフィックを獲得しています。クラスターをスケールアップし、物事は順調に進み続けました。すばらしい！しかし、規模を縮小する必要がある場合はどうすればよいでしょうか?これを実行する前に、いくつか注意すべき点があります。

• 各ノードに十分なメモリがありますか?
• オフピーク時にこれを行うことはできますか?
• クライアント アプリケーションにどのような影響がありますか?
• このフェーズではどのような指標を監視できますか? (例: CPUUtilization、CurrConnections など)

スケーリングをより適切に計画するためのベスト プラクティスについては、MemoryDb for Redis のドキュメントを参照してください。

6. 物事がうまくいかないとき…

正直に言えば、失敗はうらやましいものです。重要なのは、それらに対する準備ができているかどうかです。 Redis クラスターについては、考慮すべき点がいくつかあります。

• 障害が発生した場合にアプリケーション/サービスがどのように動作するかをテストしましたか?そうでない場合は、ぜひやってください！ MemoryDBとElastiCache for Redisを使用
• フェイルオーバー API を活用してプライマリ ノードの障害をシミュレートし、フェイルオーバーをトリガーできます。
• レプリカノードはありますか?マスター ノードが 1 つしかないシャードが 1 つしかない場合、そのノードに障害が発生するとダウンタイムが確実に発生します。
• 複数のシャードがありますか?シャードが 1 つ (プライマリとレプリカ) しかない場合、そのシャードのプライマリ ノードに障害が発生すると、クラスターは書き込みを一切受け入れることができなくなります。
• シャードは複数のアベイラビリティーゾーンにまたがっていますか?複数の AZ にまたがるシャードがある場合は、AZ 障害に対してより適切に備えることができます。

いずれの場合も、MemoryDBはノードの交換やフェイルオーバー中にデータが失われないことを保証します。

7. Redis に接続できません。助けてください!

Tl;DR: おそらくネットワーク/セキュリティ構成の問題です。これは常に人々を悩ませる問題です。 MemoryDB と ElastiCache を使用すると、Redis ノードは VPC 内に配置されます。 AWS Lambda、EKS、ECS、App Runner などのコンピューティング サービスにクライアント アプリケーションをデプロイする場合は、特に VPC とセキュリティ グループに関して、正しい構成になっていることを確認する必要があります。

これは、使用しているコンピューティング プラットフォームによって異なる場合があります。たとえば、VPC 内のリソースにアクセスするために Lambda 関数を設定する方法は、App Runner (VPC コネクタ経由) や EKS (概念的には同じですが) での設定方法とは少し異なります。

8. Redis 6 にはアクセス制御リストが組み込まれています。ぜひご利用ください。

Redis クラスターに認証 (ユーザー名/パスワード) と承認 (ACL ベースの権限) を適用しない理由はありません。 MemoryDB は Redis 6 に準拠しており、ACL をサポートしています。ただし、古いバージョンの Redis に準拠するために、各アカウントはデフォルトのユーザー (ユーザー名は default) と open-access と呼ばれる不変の ACL で構成されます。 MemoryDB クラスターを作成し、この ACL に関連付けると、次のようになります。

• クライアントは認証なしで接続できる
• クライアントは任意のキーで任意のコマンドを実行できます（権限や承認も不要）

ベストプラクティスとして:

明示的な ACL を定義してユーザー (およびパスワード) を追加し、セキュリティ要件に基づいてアクセス文字列を構成します。認証の失敗を監視する必要があります。たとえば、MemoryDB の AuthenticationFailures メトリックでは、失敗した認証試行の合計数がわかります。これにアラートを設定して、不正なアクセス試行を検出します。

境界セキュリティを忘れないでください。サーバー上で TLS が設定されている場合は、クライアントでもそれを使用することを忘れないでください。たとえば、Go Redis を使用する場合:

 クライアント: = redis 。 新しいクラスタクライアント(
 & レディス。 クラスターオプション{
 アドレス: [] 文字列{ clusterEndpoint },
 TLSConfig : & tls 。 設定{ MaxVersion : tls . バージョンTLS12 },
 //..その他のオプション
})

これを使用しないと、十分に明らかではないエラー (一般的な I/O タイムアウトなど) が発生し、デバッグが困難になる可能性があります。この点には注意が必要です。

9. できないこともある

マネージド データベース サービスとして、MemoryDB または ElastiCache は特定の Redis コマンドへのアクセスを制限します。たとえば、クラスター管理 (スケーリング、シャーディングなど) はサービス自体によって実行されるため、CLUSTER 関連のコマンドのサブセットは使用できません。

ただし、場合によっては代替手段が見つかるかもしれません。実行速度が遅いクエリの監視を例に挙げてみましょう。 CONFIG SET を使用してlatency-monitor-threshold を設定することはできませんが、パラメータ グループで slowlog-log-slower-than 設定を設定し、slowlog get を使用して比較することができます。

10. 接続プールを使用する

Redis サーバー ノード (強力なものであっても) のリソースは限られています。その 1 つは、一定数の同時接続をサポートする機能です。ほとんどの Redis クライアントは、Redis サーバーへの接続を効率的に管理する方法として接続プールを提供します。接続を再利用すると、Redis サーバーにメリットがもたらされるだけでなく、オーバーヘッドが削減されるためクライアントのパフォーマンスも向上します。これは、大量のシナリオでは非常に重要です。

ElastiCache では、追跡できるメトリクスがいくつか提供されます。

• CurrConnections: クライアント接続数（読み取りレプリカを除く）
• NewConnections: 特定の期間内にサーバーが受け入れた接続の合計数。

11. (ボーナス) 適切な接続モードを使用する

これは明らかなことのように思えるかもしれませんが、私が見た限りでは、人々が犯す最も一般的な「始める」間違いの 1 つなので、あえて言います。

クライアント アプリケーションで使用する接続モードは、スタンドアロンの Redis セットアップを使用しているか、Redis クラスターを使用しているか (ほとんどの場合) によって異なります。ほとんどの Redis クライアントはそれらを明確に区別します。たとえば、クラスター モードが有効になっている Go Redis クライアント (MemoryDB) を使用している場合、Elasticache は NewClient ではなく NewClusterClient を使用する必要があります。

 レディス。 NewClusterClient ( & redis . ClusterOptions { //....})

興味深いことに、より柔軟な UniversalClient オプション (執筆時点では Go Redis v9) があり、正しい接続モードを使用しないとエラーが発生します。しかし、場合によっては、根本的な原因が一般的なエラー メッセージの背後に隠れていることもあるため、注意が必要です。

結論は

最終的に行うアーキテクチャの選択は、特定のニーズによって決まります。