Redisは、マイクロサービスアーキテクチャで広く使用されている高性能のキーバリューストレージシステムです。Redisクラスターモードで提供される高度な機能を使用する場合は、クライアントコードを変更する必要があります。これにより、アプリケーションのアップグレードとメンテナンスが困難になります。IstioとEnvoyを使用すると、クライアントコードを変更せずに、クライアントに対応しないRedis Clusterデータシャーディングを実装し、読み取り/書き込み分離やトラフィックミラーリングなどの高度なトラフィック管理機能を提供できます。
Redisクラスター
Redisの一般的な用途は、データキャッシュとしてです。アプリケーションサーバーとデータベースサーバーの間にRedisキャッシュレイヤーを追加することにより、アプリケーションサーバーによるデータベースでの多数の読み取り操作を減らすことができ、応答が遅くなるリスクや、高圧下でのデータベースサーバーのダウンタイムさえも回避でき、システム全体の堅牢性を大幅に向上させることができます。データキャッシュとしてのRedisの原理を次の図に示します。
小規模なシステムでは、上の図に示されている単一のRedisは、キャッシュ層の機能を適切に実装できます。システムにキャッシュする必要のあるデータの量が多い場合、1つのRedisサーバーがすべてのアプリケーションサーバーのキャッシュ要件を満たすことができません。同時に、単一のRedisインスタンスに障害が発生すると、多数の読み取り要求がバックエンドデータベースサーバーに直接送信され、一時的なデータベースサーバーになります。過度の圧力はシステムの安定性に影響を与えます。Redis Clusterを使用して、キャッシュされたデータをシャーディングし、さまざまなデータをさまざまなRedisシャードに配置して、Redisキャッシュレイヤーの容量を向上させることができます。各Redisシャードでは、複数のレプリカノードを使用して、キャッシュされた読み取り要求の負荷を共有し、Redisの高い可用性を実現することもできます。RedisClusterを使用するシステムを以下に示します。
図からわかるように、Redisクラスターモードでは、クライアントはクラスターのフラグメンテーションルールに従って、クラスター内のさまざまなRedisノードにさまざまなキーの読み取りおよび書き込み操作を送信する必要があるため、クライアントはRedisクラスターのトポロジを理解する必要があります。これにより、Redis独立ノードモードを使用するアプリケーションを、クライアントを変更せずにRedisクラスターにスムーズに移行することができなくなります。さらに、クライアントはRedis Clusterの内部トポロジを理解する必要があるため、クライアントコードとRedis Clusterの運用および保守の結合にもつながります。たとえば、読み取りと書き込みの分離またはトラフィックミラーリングを実現するには、各クライアントのコードを変更して再デプロイする必要があります。 。
このシナリオでは、アプリケーションサーバーとRedisクラスターの間にEnvoyプロキシサーバーを配置できます。Envoyは、アプリケーションによって発行されたキャッシュの読み取りおよび書き込み要求を正しいRedisノードにルーティングする役割を果たします。マイクロサービスシステムでは、キャッシュサーバーにアクセスする必要のあるアプリケーションプロセスが多数あります。単一の障害ポイントとパフォーマンスのボトルネックを回避するために、アプリケーションプロセスごとにSidecarの形式でEnvoyプロキシを展開します。同時に、これらのプロキシの管理を簡素化するために、次の図に示すように、Istioをコントロールプレーンとして使用して、すべてのEnvoyプロキシを均一に構成できます。
この記事の次のパートでは、IstioとEnvoyを使用してRedis Clusterを管理し、クライアントに依存しないデータパーティショニングを実現する方法と、読み取り/書き込み分離やトラフィックミラーリングなどの高度なルーティング戦略を紹介します。
Istioをデプロイする
RedisプロトコルはPilotですでにサポートされていますが、その機能は弱いです。Redisプロキシのデフォルトルートのみを構成でき、Redisクラスターモードはサポートしていません。Redisフィルターデータの断片化、読み取り/書き込み分離、トラフィックミラーリング、およびその他の高度なトラフィック管理を実装することはできません。特徴。IstioがRedisCluster関連の構成をEnvoySidecarに配信できるようにするために、EnvoyFilterの「REPLCAE」操作をサポートするようにEnvoyFilter構成関連のコードを変更しました。EnvoyFilterパッチの改訂されたPR実装REPLACE操作は、Istioコミュニティに送信され、メインブランチにマージされ、Istioの後続のバージョンでリリースされる予定です。
この記事を書いている時点では、最新のIstioリリースバージョン1.7.3にはまだこのPRが組み込まれていません。そこで、EnvoyFilterの「REPLACE」操作を有効にするパイロットイメージを作成しました。Istioをインストールするときは、次のコマンドラインに示すように、istioctlコマンドでパイロットイメージを指定する必要があります。
$ cd istio-1.7.3/bin
$ ./istioctl install --set components.pilot.hub=zhaohuabing --set components.pilot.tag=1.7.3-enable-ef-replace注：Istioバージョンが1.7.3より新しく、PRが組み込まれている場合は、Istioバージョンでデフォルトのパイロットミラーリングを直接使用できます。
Redisクラスターを展開する
次の例で使用されている関連コードをhttps://github.com/zhaohuabing/istio-redis-culsterからダウンロードしてください。
$ git clone https://github.com/zhaohuabing/istio-redis-culster.git
$ cd istio-redis-culsterこの例では、Redisクラスターをデプロイするための「redis」名前名を作成します。
$ kubectl create ns redis
namespace/redis createdRedisサーバーのStatefulsetとConfigmapをデプロイします。
$ kubectl apply -f k8s/redis-cluster.yaml -n redis
configmap/redis-cluster created
statefulset.apps/redis-cluster created
service/redis-cluster createdRedisの展開を確認する
Redisノードが正常に稼働していることを確認します。
$ kubectl get pod -n redis
NAME READY STATUS RESTARTS AGE
redis-cluster-0 2/2 Running 0 4m25s
redis-cluster-1 2/2 Running 0 3m56s
redis-cluster-2 2/2 Running 0 3m28s
redis-cluster-3 2/2 Running 0 2m58s
redis-cluster-4 2/2 Running 0 2m27s
redis-cluster-5 2/2 Running 0 117sRedisクラスターを作成する
上記の手順では、Statefulsetを使用して6つのRedisノードを展開しましたが、現在、これらの6つのノードは互いに独立しており、クラスターを形成していません。ここでは、Rediscluster createコマンドを使用してこれらのノードをRedisクラスターにします。
$ kubectl exec -it redis-cluster-0 -n redis -- redis-cli --cluster create --cluster-replicas 1 $(kubectl get pods -l app=redis-cluster -o jsonpath='{range.items[*]}{.status.podIP}:6379 ' -n redis)
Defaulting container name to redis.
Use 'kubectl describe pod/redis-cluster-0 -n redis' to see all of the containers in this pod.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 172.16.0.72:6379 to 172.16.0.138:6379
Adding replica 172.16.0.201:6379 to 172.16.1.52:6379
Adding replica 172.16.0.139:6379 to 172.16.1.53:6379
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
slots:[0-5460] (5461 slots) master
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
slots:[5461-10922] (5462 slots) master
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
slots:[10923-16383] (5461 slots) master
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 172.16.0.138:6379)
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
slots: (0 slots) slave
replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
slots: (0 slots) slave
replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
slots: (0 slots) slave
replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.Redisクラスターを確認する
このcluster infoコマンドを使用して、クラスターが正常に作成されたことを確認するために、構成情報とRedisクラスタークラスターメンバーノードを表示できます。
$ kubectl exec -it redis-cluster-0 -c redis -n redis -- redis-cli cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:206
cluster_stats_messages_pong_sent:210
cluster_stats_messages_sent:416
cluster_stats_messages_ping_received:205
cluster_stats_messages_pong_received:206
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:416テストクライアントを展開します
テストコマンドを送信するクライアントを展開します。
$ kubectl apply -f k8s/redis-client.yaml -n redis
deployment.apps/redis-client createdIstioを介してRedisクラスターに関連するEnvoy構成を配布します
次の手順では、RedisCluster関連の構成をIstioを介してEnvoySidecarに送信し、データの断片化、読み取り/書き込みの分離、トラフィックミラーリングなど、クライアントを変更せずにRedisClusterの高度な機能を有効にします。
EnvoyRedisクラスターを作成する
Envoyは、バックエンドRedisクラスターに接続するためのタイプ「envoy.clusters.redis」のEnvoyクラスターを提供します。Envoyは、クラスターを介してバックエンドRedisクラスターのトポロジを取得します。これには、シャードの数が含まれ、各シャードが責任を負います。クライアントからの要求を正しいRedisノードに分散するためにシャードに含まれるスロットとノード。
EnvoyFilterを使用して、必要なEnvoyRedisクラスターを作成します。
$ kubectl apply -f istio/envoyfilter-custom-redis-cluster.yaml
envoyfilter.networking.istio.io/custom-redis-cluster createdEnvoyRedisプロキシを作成する
IstioのデフォルトのLDSはTCPプロキシフィルターで構成されているため、Redisプロキシフィルターに置き換える必要があります。
EnvoyFilterの「REPLACE」操作は1.7.3ではまだサポートされていないため、EnvoyFilterを作成する前に、まずEnvoyFilterのCRD定義を更新する必要があります。
$ kubectl apply -f istio/envoyfilter-crd.yaml
customresourcedefinition.apiextensions.k8s.io/envoyfilters.networking.istio.io configuredEnvoyFilterを使用してTCPプロキシフィルターをRedisプロキシフィルターに置き換え、EnvoyがクライアントからのRedis操作要求をプロキシできるようにします。
$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy.yaml
envoyfilter.networking.istio.io/add-redis-proxy createdRedisクラスター機能を確認する
すべての準備ができたので、Redisクラスターのさまざまな機能を確認しましょう。
Redisデータシャーディング
EnvoyFilterで定義された構成をIstioを介してEnvoyに送信すると、EnvoyはバックエンドRedisクラスターのトポロジを自動的に検出し、クライアント要求のキーに従ってRedisクラスター内の正しいノードに要求を自動的に配布できます。
Redisクラスターを作成する前のステップのコマンドライン出力によると、Redisクラスターのトポロジを確認できます。クラスターには3つのシャードがあり、各シャードにはマスターノードとスレーブ（レプリカ）ノードがあります。次の図に示すように、クライアントは、同じポッドに配置されたEnvoyProxyを介してRedisクラスターにアクセスします。
Redisクラスター内の各シャードのマスターノードアドレスとスレーブノードアドレス：
Shard[0] Master[0] redis-cluster-0 172.16.0.138:6379 replica redis-cluster-4 172.16.0.72:6379 -> Slots 0 - 5460
Shard[1] Master[1] redis-cluster-1 172.16.1.52:6379 replica redis-cluster-5 172.16.0.201:6379 -> Slots 5461 - 10922
Shard[2] Master[2] redis-cluster-2 172.16.1.53:6379 replica redis-cluster-3 172.16.0.139:6379 -> Slots 10923 - 16383注：この例を独自のK8sクラスターにデプロイする場合、Redisクラスターの各ノードのIPアドレスとトポロジーはわずかに異なる可能性がありますが、基本的な構造は類似している必要があります。
クライアントのset要求からRdeisクラスターにいくつかの異なるキーを送信しようとします。
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> set a a
OK
redis-cluster:6379> set b b
OK
redis-cluster:6379> set c c
OK
redis-cluster:6379> set d d
OK
redis-cluster:6379> set e e
OK
redis-cluster:6379> set f f
OK
redis-cluster:6379> set g g
OK
redis-cluster:6379> set h h
OKクライアントの観点からは、すべての要求が成功します。scanコマンドを使用して、サーバー側の各ノードのデータを表示できます。
shard [0]でデータを表示します。マスターノードはredis-cluster-0で、スレーブノードはredis-cluster-4です。
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli --scan
b
f
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli --scan
f
bシャード[1]のデータを表示します。マスターノードはredis-cluster-1で、スレーブノードはredis-cluster-5です。
$ kubectl exec redis-cluster-1 -c redis -n redis -- redis-cli --scan
c
g
$ kubectl exec redis-cluster-5 -c redis -n redis -- redis-cli --scan
g
cシャード[2]のデータを確認します。マスターノードはredis-cluster-2で、スレーブノードはredis-cluster-3です。
$ kubectl exec redis-cluster-2 -c redis -n redis -- redis-cli --scan
a
e
d
h
$ kubectl exec redis-cluster-3 -c redis -n redis -- redis-cli --scan
h
e
d
a上記の検証結果からわかるように、クライアントによって設定されたデータは、Redisクラスター内の3つのシャードに配布されます。データ配布プロセスは、Envoy Redis Proxyによって自動的に実装されます。クライアントは、バックエンドのRedisクラスターを認識しません。クライアントの場合、Redisクラスターとの対話は、単一のRedisノードとの対話と同じです。
この方法を使用すると、アプリケーションビジネスの規模が徐々に拡大し、単一のRedisノードへのプレッシャーが高すぎる場合に、システム内のRedisを単一ノードからクラスターモードにシームレスに移行できます。クラスターモードでは、さまざまなキーのデータがさまざまなデータシャードにキャッシュされます。シャード内のレプリカノードの数を増やしてシャードを拡張したり、シャードの数を増やしてクラスター全体を拡張したりできます。 、事業拡大によるデータプレッシャーの増大に対応するため。EnvoyはRedisClusterクラスタートポロジを認識でき、データ配布はEnvoyによって完了するため、移行および拡張プロセス全体にクライアントは必要なく、オンラインビジネスの通常の運用に影響を与えることはありません。
Redisの読み取りと書き込みの分離
Redisシャードには、通常、1つのマスターノードと1つ以上のスレーブ（レプリカ）ノードがあります。マスターノードは、操作の書き込みとデータ変更のスレーブノードへの同期を担当します。アプリケーションからの読み取り操作の圧力が高い場合は、シャードにレプリカを追加して、読み取り操作の負荷を分担することができます。Envoy Redis Rroxyは、さまざまな読み取り戦略の設定をサポートしています。
- マスター：マスターノードからのみデータを読み取ります。このモードは、クライアントが強力なデータ整合性を必要とする場合に必要です。このモードはマスターに大きなプレッシャーをかけ、複数のノードを使用して同じシャードで読み取り操作をロードシェアすることはできません。
- PREFER_MASTER：最初にマスターノードからデータを読み取ります。マスターノードが使用できない場合は、レプリカノードからデータを読み取ります。
- REPLICA：レプリカノードからのデータの読み取りのみ。マスターからレプリカへのデータ複製プロセスは非同期で実行されるため、この方法で期限切れのデータを読み取ることができ、クライアントが高いデータ整合性を必要としないシナリオに適しています。このモードでは、複数のレプリカノードを使用してクライアントからの読み取り負荷を共有できます。
- PREFER_REPLICA：最初にレプリカノードからデータを読み取り、レプリカノードが使用できない場合はマスターノードから読み取ります。
- ANY：任意のノードからデータを読み取ります。
以前に発行されたEnvoyFilterでは、Envoy Redis Proxyの読み取り戦略を「REPLICA」に設定しているため、クライアントの読み取り操作はレプリカノードにのみ送信する必要があります。次のコマンドを使用して、読み取りと書き込みの分離戦略を確認しましょう。
一連の主要なクライアントを開始することによりget、setアクションは「b」になります。
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379> 以前のRedisクラスタートポロジでは、キー「b」がShard [0]シャードに属していることを学びました。redis-cli monitor受信したコマンドスライスマスターおよびレプリカノードを表示するようにコマンドを実行できます。
マスターノード：
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorスレーブノード：
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitor図からわかるように、すべてのget要求はレプリカエンボイノードに送信されます。
Redisトラフィックミラーリング
Envoy Redis Proxyは、トラフィックミラーリングをサポートしています。つまり、クライアントから送信された要求は、ミラーリングされたRedisサーバー/クラスターに同時に送信されます。トラフィックミラーリングは非常に便利な機能です。トラフィックミラーリングを使用して、オンラインデータを本番環境からテスト環境にインポートし、オンラインデータを使用して、回線に影響を与えることなく、アプリケーションを可能な限り現実的にシミュレートできます。インターネット上のユーザーによる通常の使用。
ミラーサーバーとして使用する単一ノードのRedisノードを作成します。
$ kubectl apply -f k8s/redis-mirror.yaml -n redis
deployment.apps/redis-mirror created
service/redis-mirror createdEnvoFilterを使用して、ミラーリング戦略を有効にします。
$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy-with-mirror.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy-with-mirror.yaml
envoyfilter.networking.istio.io/add-redis-proxy configured一連の主要なクライアントを開始することによりget、setアクションは「b」になります。
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379> set b bbb
OK
redis-cluster:6379> get b
"bbb"
redis-cluster:6379> get b
"bbb"コマンドredis-cli monitorビューによって、コマンドマスター、レプリカ、およびミラーリングされたノードがそれぞれ受信されます。
マスターノード：
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorスレーブノード：
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitorミラーノード：
$ kubectl exec -it `kubectl get pod -l app=redis-mirror -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-mirror -n redis -- redis-cli monitor図からわかるように、すべてのset要求はEnvoyにミラーノードに送信されます。
実施原則
上記の手順では、Istioで2つのEnvoyFilter構成オブジェクトを作成しました。これらの2つのEnvoyFilterは、Envoyプロキシの構成を変更します。これには、主に、Redisプロキシネットワークフィルター構成とRedisクラスター構成の2つの部分が含まれます。
以下のEnvoyFilterは、Pilot for Redis Serviceによって作成されたリスナーのTCPプロキシネットワークフィルターを置き換え、「type.googleapis.com /envoy.config.filter.network.redis_proxy.v2.RedisProxy」タイプのネットワークフィルターに置き換えます。このRedisプロキシのデフォルトルートは「custom-redis-cluster」を指し、読み取り/書き込み分離戦略とトラフィックミラーリング戦略が構成されています。
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: add-redis-proxy
namespace: istio-system
spec:
configPatches:
- applyTo: NETWORK_FILTER
match:
listener:
name: ${REDIS_VIP}_6379 # Replace REDIS_VIP with the cluster IP of "redis-cluster service
filterChain:
filter:
name: "envoy.filters.network.tcp_proxy"
patch:
operation: REPLACE
value:
name: envoy.redis_proxy
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy
stat_prefix: redis_stats
prefix_routes:
catch_all_route:
request_mirror_policy: # Send requests to the mirror cluster
- cluster: outbound|6379||redis-mirror.redis.svc.cluster.local
exclude_read_commands: True # Mirror write commands only:
cluster: custom-redis-cluster
settings:
op_timeout: 5s
enable_redirection: true
enable_command_stats: true
read_policy: REPLICA # Send read requests to replica次のEnvoyFilterは、パイロットによって発行されたCDSに「envoy.clusters.redis」タイプのクラスターを作成します。「custom-redis-cluster」、クラスターはCLUSTER SLOTSコマンドを使用して、Redisクラスター内のランダムノードにクラスターを照会します。トポロジー構造とトポロジー構造をローカルに保存して、クライアントからクラスター内の正しいRedisノードに要求を分散します。
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: custom-redis-cluster
namespace: istio-system
spec:
configPatches:
- applyTo: CLUSTER
patch:
operation: INSERT_FIRST
value:
name: "custom-redis-cluster"
connect_timeout: 0.5s
lb_policy: CLUSTER_PROVIDED
load_assignment:
cluster_name: custom-redis-cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: redis-cluster-0.redis-cluster.redis.svc.cluster.local
port_value: 6379
- endpoint:
address:
socket_address:
address: redis-cluster-1.redis-cluster.redis.svc.cluster.local
port_value: 6379
- endpoint:
address:
socket_address:
address: redis-cluster-2.redis-cluster.redis.svc.cluster.local
port_value: 6379
- endpoint:
address:
socket_address:
address: redis-cluster-3.redis-cluster.redis.svc.cluster.local
port_value: 6379
- endpoint:
address:
socket_address:
address: redis-cluster-4.redis-cluster.redis.svc.cluster.local
port_value: 6379
- endpoint:
address:
socket_address:
address: redis-cluster-5.redis-cluster.redis.svc.cluster.local
port_value: 6379
cluster_type:
name: envoy.clusters.redis
typed_config:
"@type": type.googleapis.com/google.protobuf.Struct
value:
cluster_refresh_rate: 5s
cluster_refresh_timeout: 3s
redirect_refresh_interval: 5s
redirect_refresh_threshold: 5概要
この記事では、Envoyを使用してマイクロサービスアプリケーションにクライアントに対応しないRedisデータシャーディングを提供する方法と、Istioを使用してシステム内の複数のEnvoyエージェントのRedisクラスター構成を均一に管理する方法について説明します。IstioとEnvoyを使用すると、Redis Clusterを使用してクライアントのコーディングと構成を大幅に簡素化でき、Redis Clusterの運用と保守の戦略をオンラインで変更して、読み取り/書き込み分離やトラフィックミラーリングなどの高度なトラフィック管理を実現できることがわかります。もちろん、IstioとEnvoyの導入により、システム全体の複雑さが軽減されることはありませんでしたが、Redisクラスターのメンテナンスが分散したアプリケーションコードからサービスグリッドインフラストラクチャレイヤーに集中しました。大多数のアプリケーション開発者に対応して、そのビジネス価値は主にアプリケーションコードからもたらされ、そのようなインフラストラクチャに多くのエネルギーを投資することは費用効果が高くありません。Tencent CloudでクラウドネイティブのServiceMeshサービスTCM（Tencent Cloud Mesh）を直接採用して、Service Meshインフラストラクチャ自体のインストール、保守、およびアップグレードに注意を払うことなく、マイクロサービスアプリケーション用のServiceMeshのトラフィック管理およびサービスガバナンス機能をすばやく導入することをお勧めします。そして他の問題。