5장: 트래픽의 입구 — DNS, 로드 밸런서, 애플리케이션 게이트웨이

2부의 첫 장은 사용자 요청이 시스템에 들어오는 경로를 따라간다. 도메인 이름을 IP로 바꾸는 DNS, 그 IP로 도착한 트래픽을 여러 서버에 나누는 로드 밸런서, 그리고 그 앞에서 라우팅과 보안을 담당하는 애플리케이션 게이트웨이 순이다.

DNS의 구조

DNS(Domain Name System)는 사람이 이해하기 쉬운 도메인 이름을 기계가 사용하는 IP 주소로 변환하는 시스템이다. 중요한 전제가 하나 있다. DNS는 하나의 서버가 아니라 수많은 서버가 이루는 네트워크다.

사용자 쿼리에 응답하는 DNS 서버를 네임 서버(Name Server) 라 부르고, 매핑 정보는 리소스 레코드(RR, Resource Record) 라는 단위로 저장된다.

네임 서버는 계층적으로 구성된다. 이 계층 구조 덕에 DNS가 인터넷 규모의 쿼리 부하를 감당할 수 있다.

반복적 쿼리와 재귀적 쿼리

쿼리 방식은 두 가지다.

• 반복적 쿼리(Iterative Query) — 컴퓨터의 로컬 리졸버가 루트 서버, TLD 서버, 권한 있는 네임 서버와 각각 직접 통신하며 모든 과정을 스스로 처리한다.
• 재귀적 쿼리(Recursive Query) — 컴퓨터가 로컬 DNS 리졸버에 IP 주소만 요청하고, 리졸버가 상위 서버들을 대신 돌아 최종 IP를 찾아 반환한다.

우리가 일상적으로 쓰는 인터넷은 재귀적 쿼리 방식이다. ISP나 네트워크가 제공하는 로컬 리졸버에 IP 주소를 요청하고 결과만 받아 온다. 그리고 자주 접근하는 리소스 레코드는 DNS 캐싱으로 임시 저장해 두어 매번 계층을 타지 않는다.

DNS가 확보하는 확장성, 신뢰성, 일관성

DNS는 2장에서 본 세 축이 실제로 어떻게 구현되는지 보여주는 좋은 예다.

로드 밸런서

로드 밸런서는 트래픽을 여러 서버에 고르게 분산시키는 장치다. 주요 특징을 정리하면 이렇다.

• 트래픽을 고르게 분산시켜 과부하를 방지한다
• 장애나 응답 지연이 발생하면 다른 정상 서버로 재전송해 내구성을 높인다
• 일부 서버가 죽어도 나머지가 처리하도록 해 가용성을 유지한다
• 부하가 몰릴 때 응답 시간을 다소 지연시키면서라도 시스템을 정상 운영한다
• 서버 풀에 서버를 추가할 수 있게 해 수평 확장을 가능하게 한다

부수적으로 얻는 이점도 크다. 헬스 체크로 서버 상태를 관리해 접근할 수 없는 서버에 요청을 보내지 않고, TLS 연결을 종료해 암호화된 데이터를 미리 복호화한 뒤 전달함으로써 백엔드 서버가 본연의 작업에만 집중하게 만든다.

알고리즘

이 알고리즘들은 두 축으로 다시 분류된다.

• 정적 vs 동적 — 미리 설정된 정보만 보는지, 실시간으로 변하는 정보를 보는지
• 스테이트풀 vs 스테이트리스 — 클라이언트의 세션 정보를 유지하는지 여부

스테이트풀 로드 밸런서는 클라이언트 정보를 들고 어느 서버로 보낼지 결정하므로 가용성과 신뢰성을 높이는 방향이고, 스테이트리스 로드 밸런서는 단일 로드 밸런서 내부의 로컬 상태만으로 요청을 처리하므로 빠르고 확장성이 높으며 구현이 간단하다.

전역 로드 밸런싱과 DNS의 한계

전역 서버 로드 밸런싱(GSLB) 은 사용자 위치, 데이터 센터 상태, 서버 수 같은 요인을 기반으로 전역 트래픽을 적절한 데이터 센터로 보낸다. 로컬 로드 밸런싱은 자신이 관리하는 서버들의 상태와 용량 정보를 GSLB에 전달하는 역할을 한다.

그런데 DNS도 여러 IP를 번갈아 반환하는 방식으로 전역 로드 밸런싱 역할을 할 수 있다. 책은 이 방식의 한계를 네 가지로 짚는다.

1. 패킷 크기 제한 — DNS 패킷 크기는 512바이트로 작아 모든 서버 IP를 응답에 담을 수 없다
2. 선택 통제 불가 — 클라이언트가 반환받은 여러 IP 중 하나를 임의로 고르므로 과부하된 데이터 센터를 선택할 수 있고, DNS는 여기에 개입할 수 없다
3. 근접성 판단 불가 — DNS는 특정 클라이언트에 가장 가까운 서버를 결정하지 못한다. 지리적 위치 기반 연결이나 애니캐스트가 도움이 되지만 적용이 간단하지 않다
4. 느린 복구 — 장애가 발생해도 TTL 기반 캐싱 때문에 DNS를 통한 복구가 느리다

OSI 계층별 로드 밸런싱

OSI 모델은 시스템의 내부 구조나 특정 기술과 관계없이 네트워크 기능을 표준화하는 개념적 프레임워크다. 로드 밸런서는 주로 두 계층에서 동작한다.

그리고 실제 대규모 시스템에서는 이 계층들이 단계적으로 겹쳐 배치된다.

원칙은 간단하다. 하위 계층일수록 기본적인 트래픽 분배를 담당하고, 상위 계층일수록 더 많은 정보를 바탕으로 세밀하게 분산 처리한다.

구현 형태

애플리케이션 게이트웨이

애플리케이션 게이트웨이는 클라이언트와 백엔드 서비스 사이에서 트래픽을 가로채며 라우팅, 보안 강화, 성능 가속, 분석을 담당한다. 로드 밸런서와 역할이 겹치지만, 게이트웨이는 애플리케이션 관심사를 중앙으로 끌어올리는 것에 초점이 있다.

이 기능 목록이 의미 있는 이유는 마이크로서비스 아키텍처와 짝을 이루기 때문이다. 하나의 큰 시스템을 독립적이고 재사용 가능한 여러 서비스로 나누고, REST/HTTP 같은 가벼운 프로토콜로 통신하게 만들면, 인증이나 속도 제한 같은 공통 관심사를 각 서비스가 중복 구현하는 문제가 생긴다. 게이트웨이는 그 중복을 한곳으로 모은다.

클라우드와 온프레미스 선택지

정리

이 장은 분산 시스템의 세 가지 기본 구성 요소를 전반적으로 훑는다. 다만 각 주제의 깊이는 고르지 않았다.

DNS는 상대적으로 자세히 다뤄지지만, 계층 구조와 쿼리 방식 이상으로 파고들지는 않는다. 캐싱 동작이나 DNSSEC, 애니캐스트 같은 주제를 더 보고 싶은 지점에서 멈춘다. DNS를 단일 주제로 다루는 책을 따로 찾아 읽는 편이 나을 것 같다.

로드 밸런서는 기본 개념과 알고리즘 나열 위주다. 실무에 바로 참고하기에는 다소 추상적인데, 이 주제는 더 깊이 들어간다고 해서 결정적으로 달라지는 부분이 많지 않기도 하다. 오히려 소프트웨어 로드 밸런서를 실제로 다룰 기회에 개념을 적용해 보며 사례를 늘려 가는 편이 실질적이다.

애플리케이션 게이트웨이는 주로 클라우드 서비스 중심으로 소개된다. 관리형 서비스를 쓰지 않는 환경에서는 이 구조를 소프트웨어 단계에서 어떻게 재현할지, 즉 공통 모듈과 인증 레이어를 어떤 경계로 나눌지의 문제로 옮겨 생각해 볼 만하다.