4장 분산 시스템의 기본 요소: DNS, 로드 밸런서, 애플리케이션 게이트웨이

[jongfeel]

4.1 DNS 이해

도메인 네임 서버(Domain Name Server, DNS), 약어인 DNS로 많이 칭하는 이것은 사람이 이해하기 쉬운 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환하는 시스템입니다.

Figure 4.1: Basic architecture of DNS

• 네임 서버
• 리소스 레코드
  • A 레코드: 호스트 이름을 IP 주소에 매핑합니다.
  • NS 레코드: 도메인의 DNS 요청을 처리할 수 있는 권한 있는 네임 서버를 매핑합니다.
  • CNAME 레코드: 하나의 도메인 이름에 별칭을 부여하여 별칭 도메인 이름을 실제(정식) 도메인 이름으로 연결합니다.
  • MX 레코드: 도메인을 메일 서버에 매핑합니다.
• 캐싱
• 계층 구조: DNS의 네임 서버는 계층적으로 구성되어 있어 DNS가 거대한 규모와 쿼리 부하를 감당할 수 있게 합니다.

그림 4-2에서 볼 수 있듯이, DNS 네임 서버에는 여러 유형이 있습니다. 각기 다른 계층에 위치한 네임 서버는 DNS 인프라에서 중요한 요소입니다.

Figure 4.2: DNS name server hierarchy

• 루트 서버: 로컬 리졸버에서 쿼리를 받아 .com, .edu, .us 같은 최상위 도메인의 네임 서버 정보를 관리합니다.
• 최상위 도메인 서버(TLD): 해당 도메인의 권한 있는 네임 서버 IP 주소를 보유하고 있습니다.
• 권한 있는 네임 서버: 특정 조직이나 도메인의 최종 DNS 서버로, 웹 및 애플리케이션 서버의 IP 주소 정보를 제공합니다.

권한 있는 네임 서버는 최종적으로 도메인 이름을 IP 주소로 변환하는 역할을 하는 DNS 서버로, 가장 정확한 도메인 정보를 가지고 있는 서버입니다.

4.1.1 DNS 쿼리

반복적 쿼리

반복적 쿼리에서는 컴퓨터가 로컬 DNS 리졸버로 모든 과정을 직접 처리합니다.

Figure 4.3: Iterative DNS queries

DNS 재귀적 쿼리

컴퓨터가 로컬 DNS 리졸버에 원하는 웹 사이트의 IP 주소를 요청하면 로컬 리졸버가 이후 모든 과정을 처리합니다.

Figure 4.3: Iterative DNS queries

DNS 캐싱

캐싱을 사용하면 다음 이점을 챙길 수 있습니다.

• DNS 계층 구조로 쿼리하지 않고 로컬에서 답을 제공함으로써 사용자 응답 시간을 단축합니다.
• 불필요한 쿼리를 줄여 네트워크 트래픽을 감소시킵니다.

4.2 DNS의 확장성, 신뢰성, 일관성

4.2.1 확장성

DNS는 루트 서버, 최상위 도메인 서버, 권한 있는 네임 서버로 구성된 계층적 구조로 높은 확장성을 지닙니다.

DNS의 분산 구조는 시스템 확장성을 높이는 데 큰 역할을 합니다.
전 세계 여러 곳에 중복된 DNS 서버가 배치되어 있어 사용자 요청에 빠르게 응답하며 지연 시간을 줄일 수 있습니다.

4.2.2 신뢰성

여러 단계에서 캐싱을 사용하므로 일부 DNS 서버가 일시적으로 응답하지 못하더라도 사용자에게 필요한 정보를 빠르게 전달할 수 있습니다.

또 전 세계에 분산된 중복 DNS 서버가 사용자 요청에 신속히 응답하여 시스템 안정성을 높입니다.

4.2.3 일관성

DNS는 강한 일관성을 유지하는 대신 높은 성능을 목표로 설계되었습니다.
캐싱된 레코드의 유효 기간(TTL) 설정과 점진적으로 업데이트를 반영하여 시간이 지나면 모든 서버가 일관된 데이터를 가지는 최종 일관성을 적용했습니다.

4.3 로드 밸런서

로드 밸런싱은 여러 서버, CPU, 하드 드라이브, 네트워크 연결에 작업을 고르게 분배하여 자원을 효율적으로 사용하고, 처리 속도를 높이고, 응답 시간을 줄이고, 시스템이 과부하에 걸리지 않도록 합니다.

Figure 4.5: Load balancer

로드 밸런싱의 주요 특징은 다음과 같습니다.

• 트래픽을 여러 서버에 고르게 분산시켜 특정 서버에 과부하가 걸리는 것을 방지합니다.
• 장애가 발생하거나 속도가 느려진 서버의 요청을 다른 정상 서버로 재전송하여 시스템 내구성을 높입니다.
• 일부 서버가 작동하지 않더라도 나머지 서버가 요청을 처리할 수 있어 서비스 가용성이 유지됩니다.
• 높은 트래픽 상황에서도 시스템이 완전히 멈추지 않고 성능이 점진적으로 저하되도록 합니다. 부하가 늘어나면 응답 시간이 길어질 수 있지만 시스템은 계속 운영됩니다.
• 서버 풀에 서버를 추가함으로써 더 많은 트래픽을 처리할 수 있는 수평 확장이 가능합니다.

4.3.1 로드 밸런서 위치

로드 밸런서는 클라이언트와 프런트엔드 서버 사이, 다층 시스템의 각 계층 사이, 여러 인스턴스가 있는 서비스 간에 배치하여 효율적으로 트래픽을 분산시킬 수 있습니다.

Figure 4.6: Placing load balancers

4.3.2 로드 밸런서의 장점

• 로드 밸런서는 백엔드 서버의 상태를 확인하는 헬스 체크를 이용하여 서버가 정상 작동 중인지 파악할 수 있습니다.
• 로드 밸런서는 TLS(전송 계층 보안) 연결을 종료하여 백엔드 서버의 안정성을 높일 수 있습니다. 이것으로 공격자가 TLS 연결을 이용하여 백엔드 서버에 과부하를 주는 것을 방지할 수 있습니다. 로드 밸런서가 TLS 연결을 종료할 때, 들어오는 트래픽에 대한 보안 게이트웨이 역할을 합니다.
• 로드 밸런서는 트래픽 패턴을 분석하고 효율적인 요청 분배 알고리즘을 이용하여 서버 리소스 활용을 극대화합니다.

4.3.3 전역 로드 밸런싱과 로컬 로드 밸런싱

전역 서버 로드 밸런싱(GSLB)은 다양한 지역에 있는 데이터 센터 간에 트래픽을 분산시키는 역할을 하고,
로컬 로드 밸런싱은 개별 데이터 센터 내에서 자원 활용도를 높이는 데 중점을 둡니다.

Figure 4.7: Global and local load balancing

4.3.4 DNS와 전역 로드 밸런서

DNS도 전역 서버 로드 밸런싱 역할을 어느 정도 수행할 수 있습니다.

DNS 로드 밸런싱은 전역 트래픽을 어느 정도 분산할 수 있지만 한계가 있어 각 데이터 센터 내부에 로컬 로드 밸런서가 필요하다는 한계점을 지닙니다.

• DNS 패킷 크기가 512바이트로 작아 모든 서버 IP 주소를 응답에 포함할 수 없습니다. 이 때문에 로드 밸런싱 기능이 제한됩니다.
• 클라이언트가 DNS가 반환한 여러 IP 주소 중 하나를 임의로 선택하기에 과부하가 걸린 데이터 센터로 연결될 수도 있습니다. 이 경우 DNS는 클라이언트가 어떤 IP 주소를 선택해야 할지 간섭할 수 없습니다.
• DNS는 특정 클라이언트와 가장 가까운 서버를 결정하지 못하지만, 지리적 위치 기반 연결(geolocation)이나 애니캐스팅(anycasting) 같은 기술을 활용하면 도움이 될 수 있습니다. 하지만 이런 기술은 적용이 간단하지 않습니다.
• 장애가 발생했을 때, 특히 TTL 값이 길 때 캐싱으로 DNS를 이용한 복구가 느릴 수 있습니다.

이 문제점은 각 데이터 센터 내부에 로컬 로드 밸런서를 두어야 막을 수 있습니다.

4.3.5 로드 밸런서가 사용하는 알고리즘

• 라운드 로빈 스케줄링
• 가중치 기반 라운드 로빈: 서버 용량에 따라 가중치를 부여하고, 가중치가 높은 서버가 더 많은 요청을 받도록 설정합니다.
• 최소 연결 알고리즘: 현재 연결된 요청 수가 가장 적은 서버에 새로운 요청을 할당하는 방식입니다.
• 최소 응답 시간 알고리즘: 응답 시간이 가장 짧은 서버에 요청을 할당하여 성능이 중요한 서비스에서 효율을 극대화합니다.
• 해시, URL 해시, 일관성 해시 알고리즘: 각각 클라이언트의 IP 주소나 요청 URL을 기반으로 요청을 특정 서버에 할당하는 방식입니다.

정적 알고리즘 vs 동적 알고리즘

정적 알고리즘은 서버 상태를 실시간으로 반영하지 않고, 미리 설정된 서버 구성에 따라 요청을 분배합니다.

동적 알고리즘은 서버의 현재 상태나 최근 상태(부하 수준이나 서버 상태)를 고려하여 요청을 분배합니다.
이런 알고리즘은 서버와 통신하여 상태 정보를 유지해야 하므로 통신 비용이 증가하고 시스템이 다소 복잡하다는 단점이 있습니다.

실제로는 동적 알고리즘을 더 많이 사용합니다.
좀 더 복잡하더라도 부하 분산 효과가 뛰어나기 때문입니다.

스테이트풀 vs 스테이트리스

스테이트풀 로드 밸런서는 클라이언트와 백엔드 서버 간에 연결 상태 정보를 저장합니다. 이 상태 정보를 로드 분배 알고리즘에 반영하여 요청을 어느 서버로 보낼지 결정합니다.

스테이트리스 로드 밸런서는 클라이언트의 세션 상태를 따로 저장하지 않는 대신, 일관된 해싱 알고리즘을 사용하여 요청을 서버에 매핑합니다.
이 방식은 성능과 확장성 면에서 유리하지만, 인프라가 변경될 때 안정성이 상대적으로 낮을 수 있습니다.

4.3.6 OSI 모델의 각 계층에서 로드 밸런싱

전송 계층(4계층) 로드 밸런서는 TCP와 UDP 프로토콜을 기준으로 부하를 분산합니다.
이 로드 밸런서는 TCP/UDP 연결을 유지하면서 클라이언트 요청을 백엔드의 동일한 서버로 전달하여 연결 지향 프로토콜에 안정성을 제공합니다.

응용 계층(7계층) 로드 밸런서는 HTTP 등 응용 계층 데이터를 기반으로 부하를 분산합니다.
HTTP 헤더, URL, 쿠키, 사용자 ID 등 애플리케이션 정보를 활용하여 더 정교한 요청 분배가 가능합니다.

전송 계층 로드 밸런서는 TCP 기반 애플리케이션에 기본적인 부하 분산과 안정성을 제공하고, 응용 계층 로드 밸런서는 요청의 URL, HTTP 헤더, 쿠키 등 애플리케이션 세부 정보를 바탕으로 더 정교하고 상황에 맞춘 부하 분산을 구현할 수 있습니다.

4.3.7 로드 밸런서의 배치

• 0단계: DNS 시스템을 이용하여 특정 웹 사이트나 서비스에 대해 여러 IP 주소를 선택적으로 제공해서 트래픽을 분산합니다.
• 1단계: 특수 라우터를 사용하여 라운드 로빈 같은 규칙이나 IP 주소를 기준으로 인터넷 트래픽을 분배합니다.
• 2단계: 전송 계층(4계층) 로드 밸런서를 사용하여 동일한 사용자 세션이나 연관된 데이터 요청이 한 로드 밸런서로 일관되게 전달되도록 합니다. 이를 위해 일관된 해싱과 네트워크 설정 변경 사항 추적 같은 기술을 활용합니다.
• 3단계: 응용 계층(7계층) 로드 밸런서를 주요 서버와 직접 연결합니다. 이 단계의 로드 밸런서는 서버 상태를 모니터링하고 정상 작동 중인 서버 간에 트래픽을 분산합니다. 또 서버 효율성을 높이는 일부 작업도 수행합니다.

4.3.8 로드 밸런서의 구현

• 하드웨어 로드 밸런서는 1990년대에 처음 도입된 로드 밸런서 유형으로, 독립된 장치로 작동하며 많은 동시 사용자를 처리할 만큼 성능이 뛰어납니다. 하지만 가격이 비싸고 몇 가지 단점도 있습니다.
• 소프트웨어 로드 밸런서는 유연하게 프로그래밍할 수 있는 기능 덕분에 다양한 트래픽 분배 방식을 상황에 맞추어서 적용할 수 있습니다.
• 클라우드 로드 밸런서, 즉 LBaaS(Load Balancer as a Service)는 클라우드 제공 업체에서 공급하는 서비스입니다. 사용자는 사용량이나 서비스 수준 계약(SLA)에 따라 비용을 지불하며, 로컬 부하 분산뿐만 아니라 클라우드 지역 간 글로벌 트래픽 관리 기능도 수행할 수 있습니다.

4.4 애플리케이션 게이트웨이

애플리케이션 게이트웨이는 클라이언트와 백엔드 서비스 사이에서 트래픽을 가로채며 라우팅, 보안 강화, 성능 가속, 분석, 유연성 등을 지원합니다.
특히 여러 독립적인 서비스를 하나의 통합 API로 묶어야 하는 마이크로서비스 기반 아키텍처에서 큰 장점을 발휘합니다.

Figure 4.8: A typical API gateway

4.4.1 애플리케이션 게이트웨이의 기능과 역할

• 고급 요청 라우팅: 애플리케이션 게이트웨이는 호스트 이름, 경로, 헤더, 요청을 보낸 IP 주소 등 다양한 조건에 따라 적합한 백엔드 서비스로 요청을 전달합니다.
• 보안: 게이트웨이는 공통 보안 기능을 중앙에서 관리하여 모든 백엔드 애플리케이션과 서비스를 보호합니다. 여기에는 인증, 접근 제어, TLS 종료, DDoS(분산 서비스 거부) 방어가 포함되며, 웹 애플리케이션 방화벽(WAF)을 통합하여 보안을 강화할 수 있습니다.
• 가속화와 오프로딩: 애플리케이션 게이트웨이는 성능을 향상시키기 위해 캐싱, 압축, TCP 연결 관리, TLS 오프로딩 같은 기능을 수행합니다.
• 모니터링 기능: 게이트웨이는 중앙에서 로그, 메트릭, 트레이스를 통합 수집하여 애플리케이션 상태를 종합적으로 파악할 수 있게 합니다.
• 적응성: 요청과 응답을 조정하여 백엔드 서비스의 변화하는 기능을 유연하게 처리할 수 있게 합니다.

4.5 마이크로서비스 아키텍처

마이크로서비스에서 애플리케이션 게이트웨이는 어떤 의미를 지닐까요?

• 여러 마이크로서비스를 하나의 논리적 API로 묶어 클라이언트에 제공합니다. 이렇게 하면 클라이언트가 변화하는 백엔드 구현에 직접 의존하지 않아도 됩니다.
• 서비스 디스커버리와 동적 요청 라우팅을 통해 백엔드 서비스로 효율적으로 연결하고, 인스턴스 간 로드 밸런싱을 지원합니다.
• 보안, 모니터링, 안정성 같은 횡단 관심사를 중앙에서 처리하여 각 서비스마다 중복 코드를 작성할 필요를 없앱니다.
• 백엔드 서비스와 상관없이 게이트웨이의 새 버전을 독립적으로 배포할 수 있습니다.
• 서비스를 독립적으로 개발하고 확장할 수 있어 개발 속도를 높입니다.

4.6 클라우드 네이티브 애플리케이션 게이트웨이 서비스 개요

• AWS: 아마존의 API 게이트웨이는 API 생성, 배포, 관리 및 보안을 담당하며, 애플리케이션 로드 밸런서는 AWS 서비스와 컨테이너로 들어오는 트래픽의 라우팅을 처리합니다.
• 마이크로소프트 Azure: 응용 계층의 로드 밸런싱 기능을 제공합니다. 웹 애플리케이션 방화벽, SSL 오프로딩, 종단 간 TLS 암호화, 자동 확장 기능을 갖추고 있습니다.
• 구글 클라우드 플랫폼: Cloud Armor는 DDoS 공격을 방어하고 구글 네트워크 인프라와 연동되는 방화벽 기능을 갖추고 있습니다. Cloud 콘텐츠 전송 네트워크는 캐싱과 성능을 높여 빠른 콘텐츠 전송을 가능하게 합니다.
• 쿠버네티스 환경: Istio, Kong, Traefik, Ambassador 같은 인그레스 컨트롤러는 쿠버네티스 클러스터에서 API 게이트웨이 역할을 하며 HTTP/HTTPS 인그레스 트래픽을 관리합니다.

4.7 온프레미스 옵션

온프레미스 환경에서 사용하는 대표적인 애플리케이션 게이트웨이 플랫폼을 살펴보겠습니다.

• Kong: Kong Gateway와 Kong Mesh는 경량 프록시 서버를 이용하여 API 게이트웨이와 서비스 메시 기능을 제공합니다. 플러그인으로 인증, 보안, 분석 등 다양한 기능을 지원합니다.
• Tyk: Tyk API 게이트웨이는 강력한 접근 제어와 개발자 포털 기능, REST API 기반의 구성 기능을 갖춘 오픈 소스 게이트웨이입니다.
• NGINX: NGINX는 API 게이트웨이와 로드 밸런서로 구성할 수 있습니다. 속도 제한, 접근 제어, 서비스 디스커버리 통합 기능을 제공합니다.
• HAProxy: HAProxy는 빠르고 경량화된 로드 밸런서 및 프록시로, 응용 계층에서 요청을 관리할 수 있도록 구성할 수 있습니다.