"서버가 한 대 더 필요합니다."
서비스의 사용자가 늘어나면 서버는 느려진다. 그리고 가장 간단한 해결책은 돈이다. 서버를 늘리면 된다! (msa는 빼고 생각한다면)
그렇다면 서버를 늘렸을 때 요청들을 어떻게 서버들에게 나누어줄 수 있을까?
이럴 때 사용할 수 있는 것이 로드밸런서이다.
그리고 이 로드밸런서에는 여러가지 종류가 있지만 이번엔 가장 많이 사용하는 L4 로드밸런서와 L7 로드밸런서에 대해 알아보자.
아주 살짝 스포를 하고 시작하자면 아이언맨 죽어요.
L4 로드밸런서는 포트 번호를 바탕으로 부하를 분산키기고
L7 로드밸런서는 URL이나 HTTP 헤더를 확인해 분산시킨다.
개발자로서 이 둘의 차이를 이해하고 서비스 아키텍처에 맞는 선택을 해보자.
L4와 L7, 숫자는 어디서 왔을까? (OSI 7계층)
L4, L7이라는 숫자는 네트워크 통신 규칙을 정의한 OSI 7계층 모델에서 유래되었다. 모든 네트워크 통신은 7개의 계층을 거치는데 우리가 집중해야 할 부분은 4계층과 7계층이다.
- 4계층 (전송 계층): 데이터의 전송을 담당하는 계층
- IP 주소와 포트 번호를 통해 특정 서버의 특정 프로세스에 데이터를 전달하며 TCP, UDP 프로토콜이 여기에 속한다.
- 7계층 (애플리케이션 계층): 사용자와 상호 작용하는 소프트웨어 계층→ IP 주소와 포트 번호를 통해 들어온 요청의 내용을 확인하는 것!
- HTTP, FTP 등의 프로토콜이 있으며 GET/users, POST/login과 같이 실제 요청의 내용을 담고 있다.
L4 로드밸런서
4계층은 IP 주소와 포트 번호를 통해 데이터를 전달한다고 했다.
따라서 L4 로드밸런서는 4계층의 정보인 IP 주소와 포트 번호만을 보고 트래픽을 분산한다.
요청 내용은 확인하지 않고 서버로 빠르게 패킷을 전달하는 것이다.
L7 로드밸런서
같은 흐름으로 볼 때 당연히 L7 로드밸런서는 7계층의 정보인 HTTP 요청의 내용(URL, 헤더, 쿠키 등)을 분석하여 트래픽을 분산한다.
요청의 내용을 확인하고 이미지 요청은 이미지 처리 서버로, 동영상 요청은 스트리밍 서버로 보내는 라우팅이 가능하다.
AWS 에서 써봤을지도 몰라요!
로드벨런서를 어디서 처음 봤나요?(이론 수업 제외) 라는 질문을 듣는다면 나는 AWS로 서버를 띄우면서 써봤다고 답변할 것이다. 아마 이 글을 읽는 대부분의 사람들도 그러지 않을까 생각하며 기억을 더듬어보자.
AWS의 ELB 설정 시 확인할 수 있는 화면이다. 기억이 나시나요?!
이전 세대 선택지를 제외하고 자세히 보면 ALB와 NLB를 선택할 수 있다. 그리고 각각의 파란 동그라미 안에 HTTP, HTTPS 와 TCP, TLS, UDP 라는 단어가 보인다.
이제 기억이 나지 않는 사람들 혹은 설정을 해본 경험이 없는 사람들도 각각 어떤 기능인지 알 수 있다.
ALB가 바로 L7 로드벨런서, NLB가 L4 로드밸런서이다.
Application Load Balancer (ALB)
콘텐츠 기반 라우팅을 지원한다.
URL 경로, 호스트 이름 등 다양한 조건으로 요청을 다른 서버 그룹으로 보낼 수 있다. MSA 환경의 핵심 요소!!
또한 SSL 인증서를 탑재할 수 있다. 클라이언트와의 HTTPS 통신을 위한 SSL 암호화/복호화 작업을 ALB가 대신 처리해 준다. 이를 통해 WAS 서버는 암호화 작업의 부담을 덜고 비즈니스 로직에만 집중할 수 있게 되는 것이다.
이러한 기능 외에 HTTP 헤더 수정, 세션 유지를 위한 Sticky Session, 더 정교한 Health Check 등 다양한 부가 기능을 제공한다.
Network Load Balancer (NLB)
빠르다!
패킷 내용을 검사하지 않으므로 지연 시간이 매우 짧고 초당 수백만 개의 요청을 처리할 수 있다.
TCP와 UDP 를 사용하는 요청을 분산시키기 때문에 온라인 게임이나 실시간 스트리밍에 사용되는 TCP/UDP 트래픽도 분산할 수 있다. HTTP도 TCP 기반의 프로토콜이기 때문에 NLB 사용이 가능하다.
그러나 하위 Layer의 HTTP를 처리하기 때문에 해석은 할 수 없다. (내용은 모른다)
또한 로드밸런서에 고정 IP를 할당할 수 있어 클라이언트 측에서 방화벽 규칙을 설정하기 편하다.
그래서 언제 무엇을 써야 할까?
L7 로드밸런서
- 마이크로서비스 아키텍처(MSA) : 예를 들어 /users 요청은 사용자 서비스로 /orders 요청은 주문 서비스로 보내는 것과 같은 URL 경로 기반 라우팅이 필요할 때
- SSL 인증서 관리 간소화: 여러 WAS 서버 대신 로드밸런서에서 SSL 인증서를 통합 관리하고 싶을 때
- HTTP 헤더를 조작하거나 더 정교한 애플리케이션 레벨의 Health Check가 필요할 때
L4 로드밸런서
- 높은 성능이 필요할 때: 온라인 게임, 실시간 영상 스트리밍, IoT 데이터 수집 등 지연 시간이 매우 민감한 서비스
- HTTP가 아닌 프로토콜의 부하 분산이 필요할 때
- 클라이언트가 방화벽에서 허용해야 하는 고정 IP 주소가 필요할 때
일단 쓰긴했는데..
이제 로드밸런서가 하는 기능과 종류, 특징에 대해 알았다.
다음 상황을 가정해보자! 서버를 늘렸고 로드밸런스도 설정을 완료했다.
그럼 로드밸런스는 어떻게 동작하지..?
로드밸런서의 핵심은 요청을 나누는 것이지만 안전하게 나눠야한다. 그냥 하면 안된다..
들어오는 요청들을 서버에 잘 나눠주기 위해 기준을 정해주는 것이 분산 알고리즘이다. 여러개가 있는데 몇개만 살짝 맛보고 넘어가자.
- 라운드 로빈: 가장 기본적인 방식으로 1번, 2번, 3번 서버에 순서대로 요청 보내기
- Least Connection: 현재 처리 중인 요청이 가장 적은 서버에 보내기. 가장 한가한 애가 일하자.
- 등등~
근데 만약 여러개의 서버 중 하나의 서버에 문제가 생긴다면?
→ 그럼 아픈 친구는 병원에 보내고 일을 시키면 안된다. 요청을 주지 말자.
즉 서버가 응답 가능한 상태인지 로드밸런서는 확인해야한다. 그 때 사용하는 것이 Health Check 이다.
로드밸런서가 주기적으로 서버에 테스트 요청을 보내고 서버가 응답하지 않으면 더이상 요청을 보내지 않는다. 때문에 일부 서버에 문제가 생겨도 전체 서비스에는 문제가 없는 것이다.
그럼 로드밸런서는 알아서 서버 상태도 확인하고 부하도 나눠주고.. 다른 문제는 없을까?
하지만! 우리는 로드밸런서가 말썽을 부릴 때는 언제인지 알아둬야한다!!
로드밸런서를 사용하는 환경에서 마주칠 수 있는 문제는 세션 불일치 문제이다. 만약 사용자가 1번 서버에서 로그인을 하고 다른 요청을 보냈을 때 그 요청이 2번 서버에 전달되면 2번 서버는 누구세요? 로그인부터 ㄱㄱ 라고 할 수 밖에 없다. 누군지 모르니까..
이것이 바로 세션 불일치 문제이다.
이런 문제를 해결해보자.
방법 1 : Sticky Session
끈적하게 달라붙는거다. 특정 사용자의 요청은 항상 같은 서버로 보내도록 고정시키는 방법을 사용하자.
L7에서는 쿠키를, L4에서는 IP Hash 알고리즘을 이용하면 되기 때문에 구현은 간단할 수 있지만 만약 고정시켜놓은 서버에 문제가 생기면 모든 정보다 날아가게 되는 단점도 있다.
방법 2 : 세션 스토리지 분리
모든 서버가 공유하는 저장소를 사용하자. 예를 들어 Redis를 사용할 수 있다. 이렇게 설계하면 어떤 서버가 요청을 받는지와 관계 없이 저장소에 가서 세션 정보를 조회하면 된다. 이것이 바로 Stateless..
로드밸런서 그 이후..
로드밸런스를 통해 들어온 요청은 다시 웹서버와 WAS를 마주친다.
정적 파일에 대한 요청이라면 웹서버가, 동적 로직 처리라면 WAS가 응답하게 될 것이다.
그렇게 우리가 응답을 받아본다~!
'CS 먹고 레벨업~' 카테고리의 다른 글
| JOIN이 느린건 내 골반이 멈추지 않는 탓일까? ㅜ.ㅜ (2) | 2025.10.28 |
|---|---|
| 이건 트랜잭션 두번째 레슨 좋은 건 너만 알기 (0) | 2025.10.21 |
| 자OO스가 모르는 것, 못하는 것, 내가 전부 가르쳐줄게. (0) | 2025.10.15 |
| 내 기술은 모두 한 단계 진화한다. (2) | 2025.10.01 |
| 혼자야? (1) | 2025.09.17 |
