기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
ElastiCache 모범 사례 및 캐싱 전략
다음은 Amazon ElastiCache에 대한 모범 사례입니다. 다음 모범 사례를 준수하면 클러스터의 성능과 신뢰성을 향상시킬 수 있습니다.
주제
TLS 활성화 듀얼 스택 ElastiCache 클러스터
ElastiCache 클러스터에 TLS가 활성화된 경우, 클러스터 검색 함수 (Redis용 cluster slots
, cluster shards
및 cluster nodes
) 또는 Memcached용 config get cluster
는 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 연결을 만들지 않습니다. Valkey 또는 Redis OSS의 경우 여기에는 다른 비-Valkey 및 비-Redis OSS 애플리케이션에 대한 애플리케이션이 포함됩니다.
호스트 수준 기본 설정
일반적으로 클라이언트 또는 클라이언트 런타임에 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
에 대한 자세한 내용은 Linux 맨 페이지에서gai.conf
확인할 수 있습니다.
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