DNS 라운드 로빈: IP 간 트래픽 분산

DNS 라운드 로빈은 DNS가 한 이름에 여러 주소 레코드를 게시하고 응답마다 순서를 돌려 가며 반환할 수 있는 단순한 기법입니다. 그러면 클라이언트와 리졸버는 고정된 IP 하나가 아니라 여러 후보 목적지를 보게 됩니다. 서버 간에 연결을 분산하거나 기본적인 이중화를 제공하는 데 자주 쓰입니다. 하지만 DNS는 각 서버가 개별 클라이언트마다 정상인지 관찰하지 않으며, 캐싱 때문에 리졸버는 TTL 동안 응답을 계속 사용할 수 있습니다. 따라서 라운드 로빈은 가벼운 분산 방식일 뿐, 장애 조치가 보장되는 상태 인식형 로드 밸런싱 시스템은 아닙니다.

클라이언트에게 보이는 것

DNS 응답에는 A 또는 AAAA 레코드가 둘 이상 포함될 수 있습니다. 재귀 리졸버는 이 집합을 캐시할 수 있고, 운영 체제나 애플리케이션이 반환된 주소를 어떤 순서로 시도할지 결정합니다. 첫 번째 주소를 쓰는 시스템도 있고, 순서를 바꾸거나 여러 연결을 시도하는 시스템도 있으며, 최신 브라우저 스택은 자체 연결 전략에 따라 주소 체계끼리 경쟁시키기도 합니다. DNS 응답 순서만으로는 어느 서버가 결국 사용자의 요청을 처리했는지 증명할 수 없습니다. 조회를 반복하면 서로 다른 순서나 부분 집합이 나타날 수 있지만, 이러한 동작은 권한 제공업체와 리졸버에 따라 달라집니다.

중요한 결과 하나는 장애가 난 서버가 해당 TTL이 만료되거나 리졸버가 데이터를 갱신할 때까지 캐시된 응답에 남아 있을 수 있다는 점입니다. 계획된 마이그레이션에 앞서 TTL을 낮추면 예상 캐시 기간을 줄일 수 있지만, 이전 TTL로 이미 캐시된 응답은 지워지지 않습니다. 클라이언트도 자체 캐시나 연결 재사용 동작을 가질 수 있습니다. 이러한 이유로 서비스에 빠르고 신뢰할 수 있는 상태 기반 장애 조치가 필요하다면, DNS 라운드 로빈을 서버 장애에 대한 유일한 보호 수단으로 삼아서는 안 됩니다.

로드 밸런서와의 비교

전용 로드 밸런서는 연결 또는 애플리케이션 계층에서 결정을 내리고, 상태 점검을 실행하며, 설정된 기준을 충족하는 엔드포인트로만 트래픽을 보낼 수 있습니다. DNS 제공업체도 상태 점검과 동적 응답을 제공할 수 있지만, 이러한 기능은 제공업체마다 다르며 여전히 재귀 캐시의 영향을 받습니다. 기본적인 라운드 로빈 레코드 집합은 선택지를 제공할 뿐이며 내재된 피드백 루프가 없습니다. 이 설계들은 조합할 수 있습니다. 예를 들어 DNS가 사용자를 지역별 로드 밸런서로 안내하고, 그 로드 밸런서가 정상적인 백엔드를 선택하는 방식입니다. 처리해야 할 장애 유형을 관찰할 수 있는 계층을 선택하세요.

• 라운드 로빈 집합의 모든 주소가 해당 호스트 이름을 제공할 수 있는 상태를 유지하세요.
• 각 엔드포인트를 독립적으로 모니터링하세요. DNS 순환은 상태 점검이 아닙니다.
• 컷오버나 장애 조치를 계획하기 전에 TTL과 클라이언트 캐싱을 이해하세요.
• 엔드포인트를 빠르게 제외해야 한다면 상태 인식형 로드 밸런서를 사용하세요.
• 이름이 알려진 리졸버들의 반복된 응답을 비교하고 각 질의 시간을 기록하세요.

여러 응답 문제 해결하기

도메인이 여러 IP 주소로 확인된다면 먼저 그것이 의도된 것인지 확인하세요. 권한 존이나 제공업체 대시보드에서 전체 레코드 집합을 확인한 뒤 재귀 응답과 비교합니다. 역방향 조회에만 의존하지 말고 제공업체 문서를 통해 해당 주소가 예상되는 호스팅, CDN 또는 로드 밸런서 인프라에 속하는지 확인하세요. 직접 관리하는 환경이라면 의도한 호스트 이름과 TLS 구성을 통해 각 엔드포인트를 테스트하세요. 가상 호스팅은 호스트 이름에 따라 달라지므로 IP로 직접 요청하면 다른 결과가 나올 수 있습니다. 따라서 IP만으로 하는 테스트를 일반 트래픽의 완벽한 대용으로 취급해서는 안 됩니다.

DNS 라운드 로빈은 설정하기 쉽지만, 운영상의 단순함 때문에 캐시 유지 시간과 엔드포인트 상태에 대한 중요한 가정이 가려질 수 있습니다. 더 넓은 맥락은 도메인에 IP가 여러 개인 이유와 CDN이 DNS를 사용하는 방식을 참고하세요. 도메인 IP 조회로 현재의 공개 응답 집합을 확인할 수 있습니다. 이 관찰 결과를 모니터링 및 서비스별 점검과 함께 활용해 분산이 의도대로 동작하는지 파악하세요.

모든 대상에서 풀을 일관되게 유지하기

라운드 로빈 집합에 여러 주소를 추가하기 전에, 각 엔드포인트가 동일한 호스트 이름과 애플리케이션 버전을 안전하게 제공할 수 있는지 확인하세요. 인증서 적용 범위, 상태, 데이터 일관성, 세션 상태에 관한 가정을 점검합니다. 사용자가 어느 주소로든 도달할 수 있다면, 콘텐츠가 불완전하거나 로그인 구성이 다른 서버는 무작위로 보이는 간헐적 장애를 일으킬 수 있습니다. 올바른 호스트 헤더와 TLS 이름으로 각 주소를 모니터링하고, ping에만 의존하지 말고 애플리케이션 오류를 비교하세요. 고장 난 대상을 제거할 때는 캐시된 DNS 응답과 이미 열려 있는 연결을 고려해야 합니다. DNS는 새로운 조회에 해당 주소를 더 이상 알리지 않을 수는 있지만, 모든 클라이언트의 기존 세션이나 캐시된 연결을 즉시 끊을 수는 없습니다.