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는 오프라인 서버를 자동으로 감지하고 다른 서버로 전환할 수 있음.