▲

GN⁺: 라운드 로빈 DNS 이해하기

 (blog.hyperknot.com)
3P by neo 1달전 | favorite | 댓글 1개

라운드 로빈 DNS 이해하기

  • 라운드 로빈 DNS란 무엇인가?

    • 일반적으로 웹사이트를 VPS에서 제공할 때, DNS 제공자의 제어판에 단일 A 레코드를 추가함.
    • 라운드 로빈 DNS에서는 동일한 서브도메인에 여러 서버를 지정하여 부하를 여러 서버에 분산하고, 오프라인 서버를 자동으로 감지하여 온라인 서버를 선택할 수 있음.
    • 로드 밸런서를 사용하지 않고도 간단하고 우아한 솔루션을 제공하며, 비용이 들지 않음.

  • 이론적으로 어떻게 작동하는가?

    • RFC 8305 "Happy Eyeballs"에 따르면, 클라이언트는 연결 전에 주소를 정렬해야 함.
    • 서버가 온라인인지 오프라인인지 확인하고, 온라인 서버를 핑 시간에 따라 정렬함.

  • 실제로 어떻게 작동하는가?

    • 미국, 유럽, 싱가포르에 3개의 VPS를 생성하고, Cloudflare에 3개의 프록시 및 비프록시 A 레코드를 만듦.
    • 각 서버는 색상 이미지와 호스트 이름을 제공함.

클라이언트의 서버 선택 행동

  • Chrome

    • 모든 위치에서 무작위로 선택하지만, 선택 후에는 고정됨.
    • 몇 시간 후에 다시 평가함.

  • Firefox

    • Chrome과 유사하게 무작위로 선택하고 고정됨.

  • Safari

    • 항상 가장 가까운 서버를 올바르게 선택함.

  • curl

    • 처음에는 올바르지 않을 수 있지만, 두 번째 실행 시 가장 가까운 서버로 수정됨.

  • Cloudflare

    • 클라이언트 IP를 기반으로 무작위 위치를 선택하고 고정됨.

부분적으로 오프라인 서버가 있는 경우의 클라이언트 행동

  • 모든 클라이언트는 오프라인 서버를 감지하고 대체 서버를 선택함.
  • Cloudflare는 오프라인 서버를 감지하지 못하고, 선택된 서버가 오프라인이면 오프라인 상태로 제공됨.

Cloudflare 개선 사항

  1. 오프라인 서버를 감지해야 함.
  2. 가장 낮은 지연 시간을 가진 서버를 선택하는 기능이 필요함.

GN⁺의 정리

  • 라운드 로빈 DNS는 여러 서버에 부하를 분산시키고, 로드 밸런서를 사용하지 않고도 간단하게 구현할 수 있는 방법임.
  • 브라우저와 클라이언트의 서버 선택 방식은 다양하며, 특히 Safari는 가장 가까운 서버를 잘 선택함.
  • Cloudflare의 경우 오프라인 서버를 감지하지 못하는 문제점이 있으며, 이는 개선이 필요함.
  • 이 글은 라운드 로빈 DNS의 작동 방식을 이해하는 데 유용하며, 서버 선택 알고리듬의 차이를 탐구하는 데 흥미로울 수 있음.
▲
neo 1달전  [-]
Hacker News 의견

  • DNS 팀에게 현재 상황에 대한 설명을 요청했으며, 답변을 받으면 공유할 예정임. 코드가 자주 변경되어 현재 상황을 정확히 알기 어려움. 클라이언트 IP와 백엔드 서버 간의 연결 유지가 문제의 원인일 수 있음.

  • DNS 로드 밸런싱은 복잡한 문제를 야기할 수 있음. golang HTTP2 클라이언트가 RR DNS를 사용할 때 문제가 발생할 수 있음. 클라이언트가 새로운 서버를 발견하지 못하는 경우가 있음.

    • 모든 백엔드 서버가 다운되면 클라이언트는 첫 번째로 연결된 서버에 고정되어 다른 서버로 이동하지 않음.
    • grpc-go에서도 유사한 문제가 발생하며, 서버 측에서 MAX_CONNECTION_AGE를 설정하여 주기적으로 클라이언트를 연결 해제할 수 있음.

  • 서비스 발견을 위한 표준 솔루션이 부족함. 요청 기반 로드 밸런서를 구현하고 가상 IP를 사용하여 로드 밸런서가 상태 검사를 수행하도록 하는 것이 최선의 방법일 수 있음.

  • SRV DNS 레코드는 모든 서비스에 우선순위를 지정할 수 있는 초기 솔루션이었으나, 정치적 이유로 HTTP 클라이언트에서 사용되지 않음. 새로운 HTTPS 및 SVCB DNS 레코드가 로드 밸런싱을 위한 새로운 솔루션으로 제안됨.

  • 서버가 오프라인일 때 클라이언트는 연결이 거부되면 다음 IP로 이동함. 그러나 실제로는 서버가 응답하지 않거나 연결 후 침묵할 수 있음. 클라이언트 타임아웃에 의존하게 됨.

  • 클라이언트 측에서 신뢰성이 결정됨. 일부 시스템은 항상 가장 낮은 IP 주소를 반환하여 문제가 발생할 수 있음. DNS-RR은 로드 밸런서가 아니며, 로드 밸런서가 더 나은 솔루션임.

  • Perl로 디코더를 작성했으며, 모든 것이 Perl로 되어야 한다고 주장함.

  • RR-DNS는 로드 밸런싱에만 유용하며, 자동으로 서버 가용성을 감지하지 않음. 클라이언트에 스마트 기능을 추가해야 함.

  • 서버가 다운되면 전 세계적으로 분산된 IP 주소가 있어 사람들이 계속 접속할 수 있음.

  • 2000년대 Amazon에서는 온사이트 호스트에 대해 라운드 로빈 DNS를 사용했음. 당시에는 가장 빠른 로드 밸런싱 방법이었음. 그러나 와이파이가 가장 큰 병목 현상이었음.

  • Cloudflare Load Balancing에 대한 언급이 있지만, 실제 테스트는 하지 않음. Cloudflare는 오프라인 서버를 자동으로 감지하고 다른 서버로 전환할 수 있음.

답변달기