1. 로드 밸런서
로드 밸런서를 비유로 설명해보겠습니다.
상상해보세요, 여러분이 유명한 레스토랑에 방문하였습니다. 이 레스토랑은 매우 인기가 많고 항상 많은 손님이 몰려옵니다. 그러나 한 명의 요리사가 이 모든 주문을 처리하기에는 너무 바쁩니다.
이때 레스토랑은 로드 밸런서를 도입합니다. 로드 밸런서는 이제 주문을 받아들이고 있는 요리사 앞에 설치됩니다. 로드 밸런서는 주문이 들어오면 요리사들 사이에서 공평하게 주문을 분산합니다.
예를 들어, 로드 밸런서가 라운드 로빈 방식을 사용한다고 가정해봅시다. 그렇다면 주문은 번갈아가며 요리사들에게 배정될 것입니다. 첫 번째 주문은 요리사 A에게, 두 번째 주문은 요리사 B에게, 세 번째 주문은 요리사 C에게, 그리고 네 번째 주문은 다시 요리사 A에게로 배정됩니다. 이렇게 주문이 순서대로 처리되어 모든 요리사들이 공평하게 일하게 됩니다.
이렇게 로드 밸런서는 요리사들의 작업 부하를 균형적으로 분산하여 레스토랑의 서비스 품질을 향상시킵니다. 만약 한 명의 요리사가 휴식을 취하거나 작업에 문제가 발생한다면, 다른 요리사들이 계속해서 주문을 처리할 수 있으므로 레스토랑은 고객들에게 지속적으로 원활한 서비스를 제공할 수 있습니다.
이와 마찬가지로, 로드 밸런서는 서버 간에 트래픽을 분산하여 한 서버에 과부하가 걸리는 것을 방지하고, 서비스의 가용성과 성능을 향상시키는 역할을 합니다.
2. 로드밸런서 사진
3. L4 & L7 로드밸런서
- L4 로드 밸런서 (Transport Layer Load Balancer):
- L4 로드 밸런서는 전송 계층(Transport Layer)에서 동작합니다. 주로 IP 주소와 포트 번호를 기반으로 트래픽을 분산시킵니다.
- 클라이언트의 요청을 받아 대상 서버로 전송하기 전에, 클라이언트의 IP 주소와 포트 번호를 보고 트래픽을 분산시킵니다.
- L4 로드 밸런서는 TCP와 UDP와 같은 전송 계층의 프로토콜을 인식하고, 프로토콜에 따라 트래픽을 조절합니다.
- L4 로드 밸런서는 주로 성능과 처리량이 중요한 경우에 사용되며, 대규모의 네트워크 트래픽을 효율적으로 분산시키는 데 사용됩니다.
- L7 로드 밸런서 (Application Layer Load Balancer):
- L7 로드 밸런서는 응용 계층(Application Layer)에서 동작합니다. HTTP 프로토콜과 같은 응용 계층의 프로토콜을 인식하여 트래픽을 분산시킵니다.
- 클라이언트의 요청을 받아 HTTP 헤더, 쿠키, URL 등의 요청 내용을 분석하여 트래픽을 조절합니다.
- L7 로드 밸런서는 HTTP 요청과 응답에 따라 트래픽을 분산시키기 때문에 기능적인 다양성과 유연성이 있습니다. 예를 들어, 특정 URL 패턴으로 트래픽을 분산시키거나, HTTP 헤더에 따라 트래픽을 필터링할 수 있습니다.
- L7 로드 밸런서는 주로 웹 애플리케이션 로드 밸런싱에 사용되며, SSL 오프로딩, 캐싱, 세션 관리와 같은 고급 기능을 지원할 수 있습니다.
요약하자면,
L4 로드 밸런서는 전송 계층에서 IP 주소와 포트 번호를 기반으로 트래픽을 분산시키고, L7 로드 밸런서는 응용 계층에서 HTTP 요청과 응답을 분석하여 트래픽을 분산시킵니다. 두 방식은 각각 다른 상황과 요구사항에 맞게 선택하여 사용할 수 있습니다.
4. LB 의 구성방식
로드 밸런서(Load Balancer, LB)의 구성 방식은 다양한 방법으로 이루어질 수 있습니다. 주요 구성 방식으로는 NAT(네트워크 주소 변환), DR(다이렉트 라우팅), 그리고 Proxy(프록시) 방식이 있습니다. 각각의 방식을 자세히 설명하겠습니다:
- NAT (Network Address Translation) 방식:
- NAT 방식의 로드 밸런서는 클라이언트의 요청을 받아서 서버로 전달하기 전에 클라이언트 IP 주소와 포트를 변경하여 서버로 전달합니다.
- 로드 밸런서 자체가 서버로 트래픽을 직접 전달하는 것이 아니라, 클라이언트의 IP 주소를 숨기고 클라이언트와 서버 사이에서 중계 역할을 수행합니다.
- 클라이언트와 서버 사이에 있으므로, 두 개의 독립적인 네트워크 연결이 필요하지 않습니다.
- 일반적으로 L4 로드 밸런서에서 NAT 방식이 주로 사용됩니다.
- DR (Direct Routing) 방식:
- DR 방식의 로드 밸런서는 클라이언트의 요청을 받은 후, 패킷을 실제 서버로 전달하기 위해 로드 밸런서와 서버 사이에 물리적 레이어 2 연결을 사용합니다.
- 로드 밸런서는 클라이언트 요청을 받은 후 MAC 주소를 변경하여 서버로 패킷을 전송합니다. 이렇게 하면 서버는 응답 패킷을 로드 밸런서로 직접 보냅니다.
- 이 방식은 로드 밸런서가 서버에 대한 NAT 연결을 유지하지 않기 때문에 성능 면에서 이점이 있습니다.
- DR 방식은 L2 스위치에서 지원해야 하므로, 네트워크 인프라의 지원이 필요합니다.
- Proxy (프록시) 방식:
- Proxy 방식의 로드 밸런서는 클라이언트의 요청을 받은 후, 클라이언트와 서버 사이에서 중계 역할을 하는 프록시 서버를 사용합니다.
- 클라이언트의 요청을 받은 로드 밸런서가 요청을 분석하고, 해당 요청에 대해 가장 적합한 서버에 대한 결정을 내린 후, 서버로 요청을 전달합니다.
- 로드 밸런서는 클라이언트의 IP 주소를 보호하고, 서버의 응답을 클라이언트로 전달하는 역할을 수행합니다.
- 이 방식은 L7 로드 밸런서에서 주로 사용되며, HTTP/HTTPS와 같은 애플리케이션 계층의 프로토콜을 지원하는 경우 고급 기능을 제공할 수 있습니다.
5. 로드밸런서 알고리즘
- 라운드 로빈 (Round Robin):
- 각 서버에 차례대로 트래픽을 순서대로 분배하는 방식입니다.
- 서버들의 성능이 동일한 경우에 적합합니다.
- 가중 라운드 로빈 (Weighted Round Robin):
- 각 서버에 가중치를 부여하여 트래픽을 분배하는 방식입니다.
- 가중치가 높은 서버에 더 많은 트래픽이 전달되도록 설정할 수 있습니다.
- 최소 연결 (Least Connections):
- 현재 연결된 클라이언트의 수가 가장 적은 서버에 트래픽을 보내는 방식입니다.
- 서버들의 성능이 다를 경우에 유용합니다.
- 가중 최소 연결 (Weighted Least Connections):
- 최소 연결 알고리즘에 가중치를 부여하여 트래픽을 분배하는 방식입니다.
- 가중치가 높은 서버에 더 적은 연결을 유지하도록 설정할 수 있습니다.
- IP 해시 (IP Hash):
- 클라이언트의 IP 주소를 해시화하여 특정 서버에 할당하는 방식입니다.
- 동일한 IP 주소는 항상 동일한 서버로 연결됩니다.
- 최소 응답 시간 (Least Response Time):
- 서버들의 응답 시간을 모니터링하여 가장 빠른 응답 시간을 가진 서버에 트래픽을 보내는 방식입니다.
- 최소 부하 (Least Load):
- 서버들의 현재 부하 상태를 고려하여 가장 적은 부하를 가진 서버에 트래픽을 보내는 방식입니다.
6. 로드밸런서 에 SSL 적용하여 HTTPS 로 전환하기
로드 밸런서에 SSL을 적용하면 80 포트(HTTP)와 443 포트(HTTPS)를 효과적으로 사용할 수 있습니다. SSL을 적용하면 기존의 HTTP(80 포트) 요청은 HTTPS(443 포트)로 자동으로 리다이렉트되도록 구성할 수 있습니다.
일반적으로 다음과 같은 방법으로 로드 밸런서에서 SSL을 적용하고 80 포트와 443 포트를 처리합니다:
- HTTP(80 포트) 요청 처리:
- 로드 밸런서의 리스너를 생성할 때, 프로토콜을 HTTP(80)로 설정합니다.
- 클라이언트가 HTTP(80)로 접속하면, 로드 밸런서는 HTTP 요청을 암호화하지 않은 상태로 서버로 전달합니다.
- 서버는 HTTP 요청을 처리하고 응답을 클라이언트에게 전송합니다.
- HTTPS(443 포트) 요청 처리:
- 로드 밸런서의 리스너를 생성할 때, 프로토콜을 HTTPS(443)로 설정합니다.
- SSL 인증서를 로드 밸런서에 적용하고, 암호화된 SSL 트래픽을 해독하여 HTTP로 변환하여 서버로 전달합니다.
- 서버는 HTTPS 요청을 처리하기 위해 SSL 인증서를 사용하여 통신하며, 암호화된 응답을 클라이언트에게 전송합니다.
- SSL 리다이렉트 처리:
- 로드 밸런서에 SSL 리다이렉트를 구성하면, HTTP(80 포트) 요청을 받았을 때 HTTPS(443 포트)로 리다이렉트할 수 있습니다.
- 클라이언트가 HTTP(80 포트)로 접속하면, 로드 밸런서는 HTTP 리다이렉트 규칙에 따라 HTTPS(443 포트)로 리다이렉트하는 응답을 클라이언트에게 전송합니다.
- 클라이언트는 이 리다이렉트 응답을 받고, HTTPS(443 포트)로 재요청을 보내게 됩니다.
이렇게 구성된 로드 밸런서는 HTTP 요청을 HTTPS로 리다이렉트하여 보안 통신을 강제하고, HTTPS 요청을 암호화하여 서버로 전달하여 안전한 통신을 유지합니다. 이렇게 함으로써 사용자 데이터와 트래픽이 보안되고, HTTPS를 사용하는 모든 사용자들이 인증된 보안 연결을 경험할 수 있습니다.
7. 로드밸런서에 SSL 을 적용켜 HTTP → HTTPS 로 전환시 얻는 이점
- 보안 강화: HTTPS는 SSL 또는 TLS를 사용하여 데이터를 암호화하여 중간에 데이터 감청을 방지합니다. 이로 인해 사용자의 개인정보, 로그인 정보, 결제 정보 등 민감한 데이터가 안전하게 전송됩니다.
- 신뢰성과 신원 확인: HTTPS를 사용하는 웹사이트는 브라우저에 의해 "안전함"으로 표시되며, 사용자들에게 더 높은 신뢰성을 제공합니다. 또한 SSL 인증서를 사용하여 웹사이트의 신원을 확인할 수 있으므로, 사용자들이 사이트의 정품성을 인식할 수 있습니다.
- 검색 엔진 최적화(SEO): 검색 엔진들은 안전한 웹사이트를 선호하며, HTTPS를 적용한 웹사이트는 검색 엔진 최적화에 도움이 될 수 있습니다.
- PCI DSS 요구사항: 만약 웹사이트가 결제 정보와 같은 민감한 데이터를 처리한다면, PCI DSS 준수를 만족시키기 위해 HTTPS를 사용해야 합니다.
- 모던 웹 보안 요구 사항: 현대 웹 보안에서는 HTTPS를 적용하여 사용자들에게 보안을 제공하는 것이 기본적인 요구 사항입니다.
HTTPS 전환은 인터넷에서 안전하고 신뢰성 있는 서비스를 제공하기 위해 반드시 고려해야 하는 중요한 작업입니다. 사용자 데이터와 웹사이트의 보안을 강화하고, 사용자들이 안심하고 서비스를 이용할 수 있도록 하는 데 도움이 됩니다. 따라서 HTTPS 적용은 현대적인 웹 개발에서 반드시 고려해야 하는 사항입니다.
8. 쿠버네티스에서의 로드밸런서
쿠버네티스에서 생성된 Pod들은 각각 고유한 IP 주소와 포트 번호를 가지고 있습니다. 이러한 Pod들의 IP 주소와 포트 번호는 클러스터 내에서 트래픽을 분산시키는 데 사용되며, 기본적으로 쿠버네티스는 L4 로드 밸런서를 사용하여 트래픽을 분산시킵니다.
L4 로드 밸런서는 클라우드 제공자가 제공하는 로드 밸런서 서비스를 이용하여 클러스터 내의 각 Pod에 대한 트래픽을 분산시킵니다. 클라우드 제공자는 L4 로드 밸런서를 통해 클라이언트가 Pod의 IP 주소와 포트 번호로 요청을 보내도록 설정합니다. 이로 인해 클라이언트는 각 Pod의 IP 주소와 포트 번호를 알 필요 없이 L4 로드 밸런서의 IP 주소와 포트 번호로 트래픽을 보낼 수 있습니다.
L4 로드 밸런서는 주로 TCP와 UDP와 같은 전송 계층 프로토콜을 인식하고, IP 주소와 포트 번호를 기반으로 트래픽을 분산시킵니다. 클라이언트의 요청이 L4 로드 밸런서로 전달되면, 로드 밸런서는 해당 요청을 클러스터 내의 여러 Pod 중 하나로 라우팅합니다. 이때 Pod의 IP 주소와 포트 번호를 기반으로 트래픽을 분배합니다.
쿠버네티스는 Pod의 IP 주소와 포트 번호를 관리하여 L4 로드 밸런서를 통해 트래픽을 분산시킵니다. 이를 통해 클라이언트들은 단일 IP 주소와 포트 번호를 사용하여 쿠버네티스 클러스터의 서비스에 접근할 수 있으며, 클러스터 내의 다양한 Pod들에게 효율적으로 트래픽을 분배할 수 있습니다.
