서버/인프라를 지탱하는 기술 Ch.1 — 다중화와 부하분산의 기본

『서버/인프라를 지탱하는 기술』 1장 “다중화/부하분산의 기본”을 읽고 정리한 내용이다.

다중화의 기본

다중화란 장애가 발생해도 예비 운용장비로 시스템의 기능을 계속 유지하는 것이다. 본질은 세 단계로 볼 수 있다.

1. 장애를 상정한다. (라우터 장애, 서버 장애로 서비스가 정지한다)
2. 예비 운용장비를 준비한다.
3. 장애 발생 시 예비 운용장비로 교체하는 운용체제를 정비한다.

Cold Standby와 Hot Standby

• Cold Standby: 평소에는 예비 장비를 꺼 두고, 장애가 발생하면 연결한다. 현재 장비와 예비 장비의 설정을 동일하게 맞춰 두어야 한다.
• Hot Standby: 예비 장비의 전원을 항상 켜 두고 네트워크에 연결해 둔다. 웹 서버는 사이트 내용 갱신이나 버전업이 잦아서, 꺼져 있는 예비 장비에 매번 같은 작업을 반영하기 번거롭기 때문이다.

전원이 켜져 있는지에 따라 Cold와 Hot으로 나뉘고, Hot Standby는 즉시 교체가 가능하다.

장애 극복 (Failover)

VIP(Virtual IP)를 사용하면 실제 운용 장비가 바뀌어도 같은 주소로 손쉽게 가리킬 수 있다.

장애 검출 (Health Check)

방식	계층	예시	특징
ICMP 감시	Layer 3	ping	네트워크 도달 여부를 검사한다. ICMP를 막아 둔 곳에서는 쓸 수 없다.
포트 감시	Layer 4	telnet	TCP 접속 가능 여부를 체크한다. 과부하로 응답하지 못하거나 에러를 반환하는 상황은 감지하지 못한다.
서비스 감시	Layer 7	curl	실제 HTTP 요청을 보내 정상 응답이 돌아오는지 체크한다. AWS 로드밸런서의 헬스 체크가 이 방식이다.

읽으면서 든 고민은 서비스 감시를 어느 단까지 하는 것이 좋은가였다. NGINX까지만 확인할지, 뒤의 Django 애플리케이션까지 확인할지에 따라 감지할 수 있는 장애의 범위가 달라진다.

Active/Backup 구성과 ARP

• ARP(Address Resolution Protocol)는 IP 주소로 MAC 주소를 조회하는 프로토콜이다.
• 한 번 얻은 MAC 주소는 ARP 테이블에 일정 시간 캐싱한다.
• 그래서 다른 서버에 같은 IP 주소가 할당되더라도, ARP 테이블이 갱신될 때까지는 그 서버와 통신할 수 없다.

이를 해결하는 것이 gratuitous ARP이다. “내 IP 주소와 MAC 주소는 이것이다”라고 다른 장비들에 먼저 통지해 ARP 테이블을 갱신시킨다.

웹 서버의 다중화

DNS 라운드로빈

• 하나의 도메인에 여러 레코드를 등록해, DNS만으로 여러 대의 서버에 요청을 분산시키는 방법이다.
• 모바일 사이트에서는 문제가 될 수 있다. 캐리어 게이트웨이라는 프록시를 여러 사용자가 공유하는데, 여기서 DNS 응답이 캐싱되어 분산이 치우친다. TTL을 짧게 설정해 개선할 수 있다.

결국 결론은 로드밸런서다.

로드밸런서

로드밸런서는 하나의 IP 주소로 들어온 요청을 여러 서버로 분산한다. 서버마다 글로벌 주소를 줄 필요가 없으므로 글로벌 주소도 절약할 수 있다.

• L4 스위치: TCP(4계층)까지의 정보를 분석하므로 IP 주소와 포트 번호에 따라 분산 대상 서버를 지정한다.
• L7 스위치: 애플리케이션(7계층)까지의 정보를 분석하므로 요청 URL(/api/1, /api/2)이나 헤더에 따라 분산 대상 서버를 지정할 수 있다.

구분	L4	L7
TCP 연결	Client ↔ Real Server	Client ↔ LB ↔ Real Server
지향점	성능	유연한 설정

IPVS

IPVS는 리눅스 커널에서 동작하는 소프트웨어 L4 로드밸런서다. Netfilter를 기반으로 하며 TCP/UDP 요청을 처리할 수 있다. ipvsadm으로 가상 서버를 정의하고 리얼 서버를 할당하며, 설정 내용과 접속 상황을 확인한다.

L4 로드밸런서의 패킷 전달 방식은 두 가지다.

• NAT: 패킷의 수신지 주소를 변경해 리얼 서버로 전송한다. 응답도 로드밸런서를 거쳐 주소를 되돌린다.
• DSR(Direct Server Return): 응답 패킷의 주소를 되돌릴 필요가 없어, 리얼 서버가 로드밸런서를 경유하지 않고 직접 응답한다. 로드밸런서가 병목이 되지 않으므로 높은 트래픽을 견뎌야 할 때 사용한다.

동일 서브넷에서 NAT 구성을 사용할 수 없는 이유

NAT는 서로 다른 네트워크 간의 통신에서 주소를 변환하도록 설계되었다. 클라이언트와 리얼 서버가 동일 서브넷에 있으면, 서로 ARP로 MAC 주소를 확인해 직접 통신하려고 한다. 응답 패킷이 NAT 장비(로드밸런서)를 경유하지 않으니 주소를 되돌릴 기회가 없고, 통신이 성립하지 않는다.

라우터 및 로드밸런서의 다중화

로드밸런서 자체도 단일 장애점이 되므로 다중화해야 한다. 여기에 쓰이는 것이 VRRP(Virtual Router Redundancy Protocol)이다.

• 게이트웨이를 이중화하는 프로토콜이다.
• 마스터 노드가 정상 가동 중인지 체크하다가, 정지되면 백업 노드가 VIP를 인계받아 장애를 극복한다.

헬스 체크

• 마스터 노드는 정기적으로 VRRP 패킷을 멀티캐스트 주소로 송신해 자신이 정상 동작 중임을 광고한다. 백업 노드는 이 패킷으로 마스터의 가동을 감시한다.
• 로드밸런서 쌍이 여러 개여도 멀티캐스트 주소는 동일하며, 가상 라우터 ID로 구분한다.

가상 MAC 주소

• VRRP에는 가상 IP 주소와 별개로 가상 MAC 주소가 정의되어 있다.
• 장애 극복 시 IP 주소뿐 아니라 MAC 주소도 함께 인계된다.
• 이렇게 하면 주변 모든 장비의 ARP 테이블을 갱신하지 않아도 된다.