IPv6 클라이언트 예시
다음은 일반적으로 사용되는 오픈 소스 클라이언트 라이브러리로 IPv6 활성화 ElastiCache 리소스와 상호 작용하는 모범 사례입니다. ElastiCache 리소스에 적합한 클라이언트 구성 권장 사항은 ElastiCache와의 상호 작용 관련 기존 모범 사례
검증된 클라이언트
ElastiCache는 오픈 소스 Redis와 호환됩니다. 즉, IPv6 연결을 지원하는 오픈 소스 Redis 클라이언트는 IPv6 활성화 ElastiCache for Redis 클러스터에 반드시 연결 가능합니다. 또한 가장 널리 사용되는 Python 및 Java 클라이언트 몇 종도 특별한 테스트를 거쳐 지원되는 모든 네트워크 유형 구성(IPv4 전용, IPv6 전용, 듀얼 스택)에서 동작한다고 검증되었습니다.
검증된 클라이언트:
듀얼 스택 클러스터에 선호되는 프로토콜 구성
클러스터 모드가 활성화된 Redis 클러스터의 경우, 클라이언트가 클러스터 내 노드에 연결하는 데 사용할 프로토콜을 IP Discovery 파라미터로 제어할 수 있습니다. IP Discovery 파라미터는 IPv4 또는 IPv6로 설정할 수 있습니다.
Redis 클러스터의 경우, IP Discovery 파라미터가 cluster slots ()
IP Discovery를 변경해도 연결된 클라이언트는 가동 중지되지 않습니다. 하지만 변경 사항이 전파되려면 다소 시간이 소요됩니다. Redis 클러스터에 변경 사항이 완전히 전파된 시점을 확인하려면 cluster slots의 출력을 모니터링하면 됩니다. 클러스터 슬롯 명령에서 반환된 모든 노드가 새 프로토콜이 있는 IP를 보고하면, 변경 사항이 완전히 전파된 것입니다.
Redis-Py 사용 예제:
cluster = RedisCluster(host="xxxx", port=6379) target_type = IPv6Address # Or IPv4Address if changing to IPv4 nodes = set() while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes): nodes = set() # This refreshes the cluster topology and will discovery any node updates. # Under the hood it calls cluster slots cluster.nodes_manager.initialize() for node in cluster.get_nodes(): nodes.add(node.host) self.logger.info(nodes) time.sleep(1)
Lettuce 사용 예제:
RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379)); Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4 Set<String> nodes; do { // Check for any changes in the cluster topology. // Under the hood this calls cluster slots clusterClient.refreshPartitions(); Set<String> nodes = new HashSet<>(); for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) { nodes.add(node.getUri().getHost()); } Thread.sleep(1000); } while (!nodes.stream().allMatch(node -> { try { return finalTargetProtocolType.isInstance(InetAddress.getByName(node)); } catch (UnknownHostException ignored) {} return false; }));
TLS 활성화 듀얼 스택 ElastiCache 클러스터
ElastiCache 클러스터에 TLS가 활성화된 경우, 클러스터 검색 함수 (cluster slots, cluster shards, 및 cluster nodes) 는 IP 대신 호스트 이름을 반환합니다. IP 대신 호스트 이름을 사용하여 ElastiCache 클러스터에 연결하고 TLS 핸드셰이크를 수행합니다. 따라서, 클라이언트가 IP Discovery 파라미터의 영향을 받지 않습니다. TLS 활성화 클러스터의 경우, IP Discovery 파라미터는 선호 IP 프로토콜에 영향을 끼치지 않습니다. 대신 클라이언트가 DNS 호스트 이름을 확인할 때 어떤 IP 프로토콜을 선호하는지에 따라, 사용되는 IP 프로토콜이 결정됩니다.
Java 클라이언트
IPv4와 IPv6를 모두 지원하는 Java 환경에서 연결할 때, Java는 기본적으로 이전 버전과의 호환성을 위해 IPv6보다 IPv4를 선호합니다. 하지만 JVM 인수를 통해 IP 프로토콜 기본 설정을 구성할 수 있습니다. IPv4를 선호하려면 JVM에 -Djava.net.preferIPv4Stack=true를, IPv6를 선호하려면 -Djava.net.preferIPv6Stack=true를 설정합니다. -Djava.net.preferIPv4Stack=true를 설정하면 JVM이 더 이상 IPv6 연결을 만들지 않습니다. 비Redis 애플리케이션도 마찬가지입니다.
호스트 수준 기본 설정
일반적으로 클라이언트 또는 클라이언트 런타임에 IP 프로토콜 기본 설정을 위한 구성 옵션이 제공되지 않으면, DNS 확인을 수행할 때 IP 프로토콜이 호스트의 구성에 의존합니다. 기본적으로, 대부분의 호스트는 IPv4보다 IPv6를 선호하지만 이 기본 설정은 호스트 수준에서 구성할 수 있습니다. 이는 ElastiCache 클러스터에 대한 요청뿐만 아니라 해당 호스트로부터의 모든 DNS 요청에 영향을 끼칩니다.
Linux 호스트
Linux의 경우, gai.conf 파일을 수정하여 IP 프로토콜 기본 설정을 구성할 수 있습니다. gai.conf 파일은 /etc/gai.conf에서 찾을 수 있습니다. 지정된 gai.conf가 없으면 예제를 /usr/share/doc/glibc-common-x.xx/gai.conf에서 찾을 수 있는데, 이를 /etc/gai.conf에 복사하면 기본 구성의 주석을 제거할 수 있습니다. ElastiCache 클러스터에 연결할 때 IPv4를 선호하도록 구성을 업데이트하려면 해당 클러스터 IP를 포괄한 CIDR 범위의 우선 순위를 업데이트하여 기본 IPv6 연결의 우선 순위보다 높게 설정하면 됩니다. IPv6 연결의 우선 순위는 기본적으로 40입니다. 예를 들어, 클러스터가 CIDR이 172.31.0.0:0/16인 서브넷에 위치할 때는 아래 구성으로 인해 클라이언트는 해당 클러스터에 IPv4 연결을 선호하게 됩니다.
label ::1/128 0 label ::/0 1 label 2002::/16 2 label ::/96 3 label ::ffff:0:0/96 4 label fec0::/10 5 label fc00::/7 6 label 2001:0::/32 7 label ::ffff:172.31.0.0/112 8 # # This default differs from the tables given in RFC 3484 by handling # (now obsolete) site-local IPv6 addresses and Unique Local Addresses. # The reason for this difference is that these addresses are never # NATed while IPv4 site-local addresses most probably are. Given # the precedence of IPv6 over IPv4 (see below) on machines having only # site-local IPv4 and IPv6 addresses a lookup for a global address would # see the IPv6 be preferred. The result is a long delay because the # site-local IPv6 addresses cannot be used while the IPv4 address is # (at least for the foreseeable future) NATed. We also treat Teredo # tunnels special. # # precedence <mask> <value> # Add another rule to the RFC 3484 precedence table. See section 2.1 # and 10.3 in RFC 3484. The default is: # precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 30 precedence ::/96 20 precedence ::ffff:0:0/96 10 precedence ::ffff:172.31.0.0/112 100
gai.conf에 대한 자세한 내용은 Linux 기본 페이지
Windows 호스트
Windows 호스트의 프로세스도 비슷합니다. Windows 호스트의 경우, netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL을 실행할 수 있습니다. 이는 Linux 호스트에서 gai.conf 파일을 수정할 때와 효과가 동일합니다.
이렇게 하면, 지정된 CIDR 범위에 IPv6 연결보다 IPv4 연결을 선호하도록 기본 설정 정책이 업데이트됩니다. 예를 들어, 클러스터가 CIDR이 172.31.0.0:0/16인 서브넷에 위치할 때 netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15를 실행하면 다음 우선 순위 테이블로 인해 클라이언트는 해당 클러스터에 IPv4 연결을 선호하게 됩니다.
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies Querying active state... Precedence Label Prefix ---------- ----- -------------------------------- 100 15 ::ffff:172.31.0.0:0/112 20 4 ::ffff:0:0/96 50 0 ::1/128 40 1 ::/0 30 2 2002::/16 5 5 2001::/32 3 13 fc00::/7 1 11 fec0::/10 1 12 3ffe::/16 1 3 ::/96
