본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘은 전체 프로젝트 정리 개념인 강의라 여러가지 내용이 전반적으로 간단하게 소개되었다. 그 중에서 로드밸런서의 내용도 가볍게 다뤘는데 더 깊이 있는 이해가 필요할 것 같아서, 로드 밸런서쪽 내용을 추가적으로 찾아보고 정리해보았다.
로드밸런서란?
로드 밸런서는 컴퓨터 네트워킹 및 웹 서비스 인프라에서 필수적인 구성 요소이다. 효율적이고 안정적인 시스템 운영을 보장하기 위해 들어오는 네트워크 트래픽이나 요청을 여러 서버나 리소스에 분산하는 데 중요한 역할을 한다. 로드 밸런서의 주요 목적은 리소스 활용도를 최적화하고, 애플리케이션 가용성을 개선하며, 시스템 확장성을 강화하는 것이다. 로드밸런서의 핵심 기능과 종류를 살펴보자.
트래픽 분산
- HTTP 요청, TCP 연결, UDP 패킷 등을 백엔드 서버 그룹에 균등하게 배분한다.
- 이를 통해 모든 서버가 효율적으로 활용되며 단일 서버의 과부하를 방지한다.
고가용성 보장
- 로드밸런서는 백엔드 서버의 상태를 지속적으로 모니터링한다. 헬스 체크를 통해 응답하지 않거나 느린 서버를 발견하면 자동으로 트래픽 라우팅에서 제외하고, 정상 서버로만 트래픽을 전달한다.
- 많은 로드밸런서는 자체적으로도 여러 가용 영역에 중복 배포되어 단일 장애점을 제거한다.
수평 확장 지원
- 서비스를 중단하지 않고 서버 풀에 새로운 서버를 추가할 수 있다.
- 트래픽이 증가하면 추가 서버를 투입하고 로드밸런서가 자동으로 트래픽을 비례 배분한다.
세션 지속성
- 일부 애플리케이션은 사용자 세션이 동일한 백엔드 서버에 유지되어야 한다.
- 로드밸런서는 쿠키 기반 또는 IP 기반 어피니티를 사용해 동일 클라이언트의 요청이 같은 서버로 가도록 보장한다.
SSL/TLS 터미네이션
- SSL/TLS 암복호화는 계산 비용이 높다. 로드밸런서가 이 작업을 담당하면 백엔드 서버의 부하를 줄이고 전체 성능을 개선할 수 있다.
로드밸런서 종류
Layer 4 로드밸런서 (전송 계층)
OSI 모델의 4계층에서 동작하며 IP 주소와 포트 정보를 기반으로 라우팅한다. 패킷 내용을 검사하지 않기 때문에 빠르고 효율적이지만 지능적인 라우팅에는 제한적이다. 예시로는 HAProxy와 AWS Network Load Balancer가 있다.
Layer 7 로드밸런서 (애플리케이션 계층)
애플리케이션 계층에서 동작하며 요청 내용을 검사할 수 있다. HTTP 메서드, URL 경로, 헤더, 쿠키 등을 기반으로 라우팅 결정을 내린다. 예를 들어 /api 요청은 API 서버 그룹으로, /images 요청은 이미지 서버로 전달할 수 있다. NGINX와 AWS Application Load Balancer가 대표적이다.
글로벌 로드밸런서
여러 데이터센터나 리전에 걸쳐 트래픽을 분산한다. 지리적 근접성이나 지연시간을 기반으로 트래픽을 라우팅할 수 있다. Google Cloud Load Balancing과 Azure Traffic Manager가 이에 해당한다.
클래식 로드밸런서: 애플리케이션과 네트워크 레이어를 지원하는 로드밸런서, 현재 AWS는 여러 레이어에 동시에 작용하는 로드 밸런서를 만드는 것이 이상적이지 않다고 판단하여 CLB 사용을 권장하지 않는다고 한다.
Load Balancing Algorithms
- 로드밸런서가 트래픽을 어떻게 배분할지 결정하는 알고리즘은 시스템 요구사항에 따라 선택된다.
Round Robin
가장 단순한 알고리즘으로 순환 방식으로 각 서버에 요청을 분배한다. 모든 백엔드 서버의 처리 능력이 유사할 때 적합하다.
Least Connections
현재 활성 연결이 가장 적은 서버로 요청을 전달한다. 서버 간 처리 용량이 다양하고 현재 부하에 따라 분산하려 할 때 유용하다.
IP Hash
클라이언트 IP 주소를 사용해 어느 백엔드 서버로 라우팅할지 결정한다. 동일 IP는 항상 같은 서버에 매핑되어 세션 지속성이 중요한 시나리오에 적합하다.
Weighted Round Robin
각 서버에 가중치를 부여하여 더 높은 가중치를 가진 서버가 더 많은 트래픽을 받도록 한다. 서버 용량이나 성능이 다를 때 리소스를 비례적으로 할당할 수 있다.
Weighted Least Connections
Weighted Round Robin과 유사하지만 서버의 부하 대신 활성 연결 수를 고려한다. 서버 용량도 다르고 현재 부하 기반 분산도 필요한 경우에 유용하다.
Least Response Time
이전 성능 지표를 기반으로 가장 빠른 응답 시간을 가진 서버로 트래픽을 전달한다. 지연시간을 최소화하는 것이 목표일 때 적합하다.
Random
각 새 요청에 대해 무작위로 백엔드 서버를 선택한다. 단순하지만 균등 분산을 보장하지 않으며 서버 용량과 부하가 균일할 때만 사용할 수 있다.
Reverse Proxy
로드 밸런싱과 리버스 프록시는 웹 애플리케이션 및 서비스의 성능, 확장성, 보안을 개선하기 위해 함께 사용되는 밀접하게 연관되지만 별개의 개념이다. 리버스 프록시는 클라이언트와 하나 이상의 백엔드 서비스 사이에 위치한 서버다. 클라이언트가 요청을 보내면 리버스 프록시가 이를 가로채서 사전 정의된 규칙에 따라 어떤 내부 서비스가 처리할지 결정한다. 클라이언트 관점에서는 모든 콘텐츠가 단일 서버에서 오는 것처럼 보인다.
주요 기능
보안과 추상화
- 백엔드 서버를 직접 접근으로부터 보호하는 것이 리버스 프록시의 가장 중요한 역할이다. IP 주소, 포트 설정 및 기타 식별 정보를 숨겨 DDoS 공격, 포트 스캔, 애플리케이션 핑거프린팅 등의 공격으로부터 백엔드 서비스를 덜 취약하게 만든다.
중앙화된 SSL/TLS 터미네이션
- 리버스 프록시가 SSL/TLS 암복호화를 처리하여 클라이언트와 프록시 간 트래픽은 안전하게 유지하면서, 프록시에서 백엔드 서버로의 트래픽은 신뢰할 수 있는 내부 네트워크에서 암호화하지 않을 수 있다.
정적 및 동적 콘텐츠 캐싱
- 이미지, JavaScript 파일, CSS 스타일시트, HTML 페이지 등 자주 접근하는 콘텐츠를 캐시할 수 있다. 캐시된 응답을 직접 제공함으로써 백엔드 서버의 부하를 줄이고 클라이언트 응답 시간을 개선하며 네트워크 대역폭 사용을 절감한다.
압축
- 성능 개선과 대역폭 사용 감소를 위해 리버스 프록시는 서버 응답을 클라이언트에 보내기 전에 압축한다. Gzip이나 Brotli 같은 알고리즘이 응답 크기를 줄여 페이지 로딩을 가속화한다.
URL 재작성 및 라우팅
- 리버스 프록시는 백엔드 서비스로 전달되기 전에 들어오는 URL을 재작성할 수 있다. 이를 통해 깔끔하고 사용자 친화적인 URL을 제공하면서 내부적으로 마이크로서비스로 원활하게 라우팅할 수 있다. 예를 들어 /products 요청을 내부적으로 http://product-service.internal/api/v1/items로 라우팅할 수 있다.
로드밸런싱 기능
- 로드밸런싱은 일반적으로 별도 기능으로 간주되지만 많은 리버스 프록시는 내장 로드밸런싱을 지원한다. 이러한 중복은 리버스 프록시가 라우팅 및 캐싱 외에도 트래픽을 효율적으로 분산할 수 있게 한다.
리버스 프록시와 로드밸런서 함께 사용하기
실제 시스템에서는 리버스 프록시와 로드밸런서가 함께 사용되는 경우가 많으며, NGINX와 같은 단일 도구가 두 기능을 모두 수행할 수 있다.
일반적인 패턴은 여러 로드밸런서 앞에 리버스 프록시를 배치하는 것이다
- 클라이언트 요청(예: 브라우저 또는 모바일 앱)이 역방향 프록시 에 도달
- 요청 경로(예: /orders)를 기반으로 프록시는 트래픽을 적절한 로드밸런서로 라우팅
- 그러면 로드 밸런서는 할당된 서버 그룹 내의 정상 서버 중 하나로 요청을 전달
- 선택된 서버는 요청을 처리하고 체인을 통해 클라이언트에게 응답을 다시 전달
언제 무엇을 사용할까?
로드 밸런서를 사용해야 하는 경우
- 주요 목표가 여러 서버나 서비스에 들어오는 트래픽을 분산하여 높은 가용성, 확장성 및 내결함성을 보장하는 것이라면 로드 밸런서를 사용
이상적인 시나리오:
- 웹 애플리케이션이나 마이크로서비스의 여러 동일한 인스턴스를 호스팅하고 이들 간에 트래픽을 분산해야 하는 경우
- 증가한 트래픽을 처리하기 위해 애플리케이션을 수평적으로 확장 하려고 하는 경우
- 요청이 정상적인 백엔드 노드로만 라우팅되도록 자동 장애 조치가 필요하는 경우
- 트래픽 분산 전략 (예: 라운드 로빈, 최소 연결, IP 해시) 을 구현하려고 하는 경우
- 모든 인스턴스가 모든 요청을 처리할 수 있는 상태 비저장 애플리케이션을 제공하고 있는 경우
- 오케스트레이터(예: Kubernetes, ECS) 뒤에서 컨테이너화된 서비스를 실행하고 있으며 내부 또는 외부 트래픽 분산이 필요한 경우
역방향 프록시를 사용해야 하는 경우
- 백엔드 서비스나 웹 서버 앞에 유연한 트래픽 라우터 , 성능 최적화 프로그램 또는 보안 계층이 필요한 경우 역방향 프록시를 사용
이상적인 시나리오:
- 외부 클라이언트로부터 백엔드 인프라를 숨기고 싶은 경우
- 애플리케이션 서버의 부담을 줄이려면 SSL/TLS 종료가 필요한 경우
- 성능을 향상시키려면 정적 또는 동적 콘텐츠를 캐시 해야 하는 경우
- 클라이언트로 전송하기 전에 서버 응답을 압축 해야 하는 경우
- 요청 경로에 따라 URL을 다시 작성하거나 , 사용자 정의 헤더를 추가하거나, 라우팅 논리를 적용하고 싶은 경우
- 동일한 도메인이나 IP 주소 뒤에 여러 서비스나 애플리케이션을 호스팅하고 있는 경우
- 캐싱 및 라우팅 기능과 함께 기본적인 부하 분산 기능 을 제공하려고 하는 경우
API 게이트웨이를 사용해야 하는 경우
- api 게이트 웨이란??
- API 게이트웨이 는 백엔드 서비스와의 모든 클라이언트 상호작용에 대한 중앙 진입점 역할을 하는 서버
- 특히 여러 서비스가 존재하고 클라이언트 요청을 효율적으로 관리, 보호, 라우팅 및 조율해야 하는 마이크로서비스 아키텍처 에서 매우 유용하다.
- 애플리케이션이 여러 API나 마이크로서비스를 노출하고 보안, 라우팅, API 수명 주기 관리 에 대한 중앙 집중식 제어가 필요한 경우 API Gateway를 사용
이상적인 시나리오:
- 마이크로서비스 아키텍처가 있고 모든 API에 대한 단일 진입점이 필요한 경우
- 토큰(예: JWT, OAuth2)을 사용하여 인증 및 권한 부여를 시행해야 하는 경우
- 백엔드 API를 보호하기 위해 속도 제한 , 요청 할당량 또는 조절을 적용하려고 하는 경우
- 요청과 응답을 변환하고 싶습니다 (eg: 헤더 수정, 형식 변환)
- 여러 마이크로서비스의 응답을 단일 API 호출로 집계 하려고 하는 경우
- 외부 개발자나 파트너 에게 API를 공개하고 있으며 API 문서 , 키 관리 또는 개발자 포털이 필요한 경우
- API 버전을 관리하고, 더 이상 사용되지 않는 경로를 관리하거나, API 버전에 따라 트래픽을 라우팅하고 싶은 경우
참고 출처
- https://dev.to/rajrathod/load-balancers-and-reverse-proxy-system-design-k51?utm_source=chatgpt.com
- https://blog.algomaster.io/p/load-balancer-vs-reverse-proxy-vs-api-gateway
