View a markdown version of this page

클러스터 엔드포인트의 DNS 확인 관리 - Amazon Timestream
DNS 캐싱 이해솔루션 1: JVM DNS TTL 구성(Java 애플리케이션)솔루션 2: 신뢰할 수 있는 네임서버를 통한 직접 해결노드 IP 변경 사항 처리모범 사례

Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. 여기에서 자세히 알아보세요.

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

클러스터 엔드포인트의 DNS 확인 관리

InfluxDB 3용 Timestream 다중 노드 클러스터는 DNS 기반 트래픽 분산을 사용하여 노드 간 연결의 균형을 맞춥니다. 장애 조치가 발생하거나 노드가 교체되면 DNS 레코드가 사용 가능한 인스턴스를 가리키도록 자동으로 업데이트됩니다. 애플리케이션이 이러한 변경 사항을 발견하고 최적의 트래픽 분산을 유지할 수 있도록 하려면 적절한 DNS 확인 구성이 필요합니다.

DNS 캐싱 이해

많은 프로그래밍 환경이 DNS 조회를 캐싱하여 성능을 개선합니다. 그러나이 캐싱은 장애 조치 후 애플리케이션이 업데이트된 IP 주소를 검색하거나 여러 클러스터 노드에 연결을 배포하지 못하게 할 수 있습니다. 영향은 언어 및 런타임에 따라 다릅니다.

  • Java/JVM 기반 애플리케이션 - JVM은 구성 가능한 TTL(time-to-live)에 대한 DNS 조회를 캐시합니다. 일부 구성은 JVM이 다시 시작될 때까지 무기한 캐시됩니다.

  • 다른 언어 - Python, Go, Node.js 및 기타 런타임은 일반적으로 운영 체제 DNS 확인에 의존하며 동일한 캐싱 동작을 나타내지 않을 수 있습니다.

솔루션 1: JVM DNS TTL 구성(Java 애플리케이션)

Timestream for InfluxDB for InfluxDB 3 클러스터 엔드포인트에 연결하는 Java 애플리케이션의 경우 JVM DNS 캐시 TTL을 0으로 설정합니다. 이렇게 하면 각 연결이 새로운 DNS 조회를 트리거하여 적절한 트래픽 분산과 즉각적인 장애 조치 감지를 가능하게 합니다.

현재 TTL 설정을 확인합니다.

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");

다음 방법 중 하나를 사용하여 TTL을 구성합니다.

  • 글로벌 구성 - networkaddress.cache.ttl에서 설정$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • 애플리케이션별 구성 - 네트워크 연결을 설정하기 전에 애플리케이션 초기화 코드에서 속성을 설정합니다.

    java.security.Security.setProperty("networkaddress.cache.ttl", "0");

  • JVM 인수 - 애플리케이션을 시작할 때를 시스템 속성으로 전달합니다.

    java -Dsun.net.inetaddr.ttl=0 -jar your-application.jar
참고

클러스터가 아닌 엔드포인트 또는 일반 AWS 리소스의 경우 일반적으로 60초의 TTL이면 충분합니다. 제로 TTL 권장 사항은 트래픽 분산 및 신속한 장애 조치 감지가 중요한 InfluxDB 3 클러스터 엔드포인트에만 적용됩니다.

솔루션 2: 신뢰할 수 있는 네임서버를 통한 직접 해결

예를 들어 중간 OS 수준 캐싱으로 인해 TTL 구성이 충분하지 않거나 프로그래밍 언어에 DNS 캐싱 문제가 없는 경우 신뢰할 수 있는 네임서버를 직접 쿼리하여 새로운 DNS 확인을 강제할 수 있습니다. 이 접근 방식은 표준 TTL 구성으로 문제가 해결되지 않는 경우에만 사용합니다.

직접 해결 워크플로

  1. 클러스터 엔드포인트에 대한 신뢰할 수 있는 네임서버를 식별합니다.

    dig <cluster-endpoint> NS

    출력AUTHORITY SECTION의에서 뒤에 나열된 nameserver를 기록해 둡니다IN SOA. 예를 들어 ns-1458.awsdns-54.org입니다.

  2. 신뢰할 수 있는 nameserver를 직접 쿼리하여 캐시를 우회합니다.

    dig @ns-1458.awsdns-54.org <cluster-endpoint>

    그러면 실제 DNS 기반 트래픽 배포를 반영하는 엔드포인트의 현재 IP 주소가 반환됩니다.

  3. 애플리케이션 연결에 확인된 IP 주소(들)를 사용합니다. 이 확인을 주기적으로 반복하거나 연결 오류가 발생하여 주소를 새로 고칩니다.

예:

# Find authoritative nameserver
dig my-cluster.timestream-influxdb.us-east-1.amazonaws.com NS

# Resolve using authoritative nameserver
dig @ns-1458.awsdns-54.org my-cluster.timestream-influxdb.us-east-1.amazonaws.com

# Use returned IP addresses in your application

노드 IP 변경 사항 처리

중요

노드 IP 주소는 정적이지 않습니다. 장애 조치, 노드 재시작, 유지 관리 작업 및 클러스터 조정 중에 변경됩니다. 확인된 IP 주소를 무한정 캐싱하지 마세요.

IP 변경을 처리하기 위해 다음 사례를 구현합니다.

  • 주기적 재해상 - 백그라운드 작업을 사용하여 30~60초마다 엔드포인트를 재해상합니다. 새 IP 주소를 캐시된 값과 비교하고 그에 따라 연결 풀을 업데이트합니다.

  • 오류 기반 재해결 - 연결이 실패하면(제한 시간, 연결 거부, 재설정) 엔드포인트를 즉시 재해결하고 업데이트된 IP 주소로 재시도합니다.

  • 정상적인 연결 드레이닝 - IP 주소가 더 이상 DNS 레코드 세트에 없으면 진행 중인 요청이 완료되도록 허용하되 해당 IP에 대한 새 연결 생성은 중지합니다.

  • 새 연결 생성 - 다시 해결한 후 업데이트된 IP 주소를 사용하여 새 연결을 생성합니다. 기존 IPs은 재분해능의 이점을 얻지 못합니다.

모범 사례

  • TTL 구성으로 시작 - Java 애플리케이션의 경우 항상 networkaddress.cache.ttl=0 먼저 설정을 시도합니다. 가장 간단하고 효과적인 솔루션입니다.

  • 직접 해상도를 거의 사용하지 않음 - TTL 구성이 충분하지 않거나 영구 중간 캐싱을 처리할 때만 신뢰할 수 있는 네임서버 쿼리를 사용합니다.

  • 네임서버 검색 자동화 - 네임서버 주소를 하드코딩하지 마세요. 네임서버 할당이 변경될 수 있으므로 동적으로 검색합니다.

  • 클러스터 엔드포인트에만 적용 - 이러한 기법은 DNS 기반 배포를 사용하는 클러스터 수준 엔드포인트(쓰기 및 읽기)에 적용됩니다. 개별 노드를 직접 대상으로 하는 노드별 엔드포인트에는이 구성이 필요하지 않습니다.

  • 구현 테스트 - 애플리케이션이 여러 노드에 연결을 올바르게 분산하고 시뮬레이션된 노드 장애로부터 복구하는지 확인합니다.