ElastiCache 모범 사례 및 캐싱 전략 - Amazon ElastiCache

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

ElastiCache 모범 사례 및 캐싱 전략

아래에서 Amazon 에 대한 권장 모범 사례를 찾을 수 있습니다 ElastiCache. 다음 모범 사례를 준수하면 클러스터의 성능과 신뢰성을 향상시킬 수 있습니다.

TLS 활성화된 듀얼 스택 ElastiCache 클러스터

ElastiCache 클러스터에 대해 TLS 가 활성화되면 클러스터 검색 함수(cluster slotsRedis의 cluster nodes 경우 , cluster shards, )가 활성화되고 config get cluster Memcached의 경우 대신 호스트 이름을 반환합니다IPs. 그런 다음 ElastiCache 클러스터IPs에 연결하고 TLS 핸드셰이크를 수행하는 대신 호스트 이름이 사용됩니다. 따라서 클라이언트가 IP Discovery 파라미터의 영향을 받지 않습니다. TLS 활성화된 클러스터의 경우 IP 검색 파라미터는 기본 IP 프로토콜에 영향을 주지 않습니다. 대신 사용되는 IP 프로토콜은 클라이언트가 DNS 호스트 이름을 확인할 때 선호하는 IP 프로토콜에 따라 결정됩니다.

Java 클라이언트

IPv4 및 를 모두 지원하는 Java 환경에서 연결할 때 IPv6Java는 기본적으로 이전 버전과의 호환성IPv4IPv6을 선호합니다. 그러나 JVM 인수를 통해 IP 프로토콜 기본 설정을 구성할 수 있습니다. IPv4를 선호하려면 가 -Djava.net.preferIPv4Stack=true 및 를 JVM 수락하고 IPv6 를 선호합니다-Djava.net.preferIPv6Stack=true. 설정-Djava.net.preferIPv4Stack=true하면 JVM가 더 이상 IPv6 연결하지 않습니다. Valkey 또는 Redis 의 경우 OSS여기에는 다른 비-Valkey 및 비-Redis OSS 애플리케이션에 대한 애플리케이션이 포함됩니다.

호스트 수준 기본 설정

일반적으로 클라이언트 또는 클라이언트 런타임이 IP 프로토콜 기본 설정을 위한 구성 옵션을 제공하지 않는 경우 DNS 해결을 수행할 때 IP 프로토콜은 호스트의 구성에 따라 달라집니다. 기본적으로 대부분의 호스트는 IPv6 우선하지만 IPv4 이 기본 설정은 호스트 수준에서 구성할 수 있습니다. 이는 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 때 선호하도록 구성을 업데이트하려면 클러스터를 포함하는 CIDR 범위의 우선 순위를 기본 IPv6 연결의 우선 순위보다 높IPs게 업데이트합니다. 기본적으로 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 범위의 IPv4 연결보다 IPv6 연결을 선호하도록 기본 설정 정책이 업데이트됩니다. 예를 들어 클러스터가 172.31.0.0:0/16이 CIDR 실행 중인 서브넷에 있다고 가정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