Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. [여기](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)에서 자세히 알아보세요.

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

# 클러스터 엔드포인트의 DNS 확인 관리
<a name="timestream-for-influx-managing-dns"></a>

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

## DNS 캐싱 이해
<a name="timestream-for-influx-dns-caching-issue"></a>

많은 프로그래밍 환경이 DNS 조회를 캐싱하여 성능을 개선합니다. 그러나이 캐싱은 장애 조치 후 애플리케이션이 업데이트된 IP 주소를 검색하거나 여러 클러스터 노드에 연결을 배포하지 못하게 할 수 있습니다. 영향은 언어 및 런타임에 따라 다릅니다.
+ **Java/JVM 기반 애플리케이션 -** JVM은 구성 가능한 TTL(time-to-live)에 대한 DNS 조회를 캐시합니다. 일부 구성은 JVM이 다시 시작될 때까지 무기한 캐시됩니다.
+ **다른 언어** - Python, Go, Node.js 및 기타 런타임은 일반적으로 운영 체제 DNS 확인에 의존하며 동일한 캐싱 동작을 나타내지 않을 수 있습니다.

## 솔루션 1: JVM DNS TTL 구성(Java 애플리케이션)
<a name="timestream-for-influx-jvm-ttl"></a>

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: 신뢰할 수 있는 네임서버를 통한 직접 해결
<a name="timestream-for-influx-direct-resolution"></a>

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

**직접 해결 워크플로**

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

   ```
   dig <cluster-endpoint> NS
   ```

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

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

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

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

1. 애플리케이션 연결에 확인된 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 변경 사항 처리
<a name="timestream-for-influx-handling-ip-changes"></a>

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

IP 변경을 처리하기 위해 다음 사례를 구현합니다.
+ **주기적 재해상** - 백그라운드 작업을 사용하여 30\~60초마다 엔드포인트를 재해상합니다. 새 IP 주소를 캐시된 값과 비교하고 그에 따라 연결 풀을 업데이트합니다.
+ **오류 기반 재해결 -** 연결이 실패하면(제한 시간, 연결 거부, 재설정) 엔드포인트를 즉시 재해결하고 업데이트된 IP 주소로 재시도합니다.
+ **정상적인 연결 드레이닝** - IP 주소가 더 이상 DNS 레코드 세트에 없으면 진행 중인 요청이 완료되도록 허용하되 해당 IP에 대한 새 연결 생성은 중지합니다.
+ **새 연결 생성** - 다시 해결한 후 업데이트된 IP 주소를 사용하여 새 연결을 생성합니다. 기존 IPs은 재분해능의 이점을 얻지 못합니다.

## 모범 사례
<a name="timestream-for-influx-dns-best-practices"></a>
+ **TTL 구성으로 시작** - Java 애플리케이션의 경우 항상 `networkaddress.cache.ttl=0` 먼저 설정을 시도합니다. 가장 간단하고 효과적인 솔루션입니다.
+ **직접 해상도를 거의 사용하지** 않음 - TTL 구성이 충분하지 않거나 영구 중간 캐싱을 처리할 때만 신뢰할 수 있는 네임서버 쿼리를 사용합니다.
+ **네임서버 검색 자동화** - 네임서버 주소를 하드코딩하지 마세요. 네임서버 할당이 변경될 수 있으므로 동적으로 검색합니다.
+ **클러스터 엔드포인트에만 적용** - 이러한 기법은 DNS 기반 배포를 사용하는 클러스터 수준 엔드포인트(쓰기 및 읽기)에 적용됩니다. 개별 노드를 직접 대상으로 하는 노드별 엔드포인트에는이 구성이 필요하지 않습니다.
+ **구현 테스트** - 애플리케이션이 여러 노드에 연결을 올바르게 분산하고 시뮬레이션된 노드 장애로부터 복구하는지 확인합니다.