Loadbalancer 와 SSL 핸드 쉐이크

로드밸런서는 네트워크 트래픽을 여러 서버로 분산시켜 부하를 줄이고, 시스템의 가용성과 성능을 향상시키는 기술입니다. 로드밸런서는 크게 하드웨어 기반과 소프트웨어 기반으로 나눌 수 있으며, 다양한 알고리즘을 사용해 트래픽을 분산합니다.

로드밸런서의 종류

1. 하드웨어 로드밸런서
• 전용 하드웨어 장비를 사용해 트래픽을 분산.
• 예) F5, Citrix ADC, Radware.
• 특징: 고성능, 보안 기능 내장, 높은 비용.

2. 소프트웨어 로드밸런서
• 소프트웨어 기반으로 트래픽을 분산하며, 클라우드 환경에서 주로 사용.
• 예) HAProxy, Nginx, Apache Traffic Server.
• 특징: 저비용, 유연한 설정, 클라우드 및 컨테이너 환경에 적합.

3. DNS 로드밸런서
• DNS 응답을 기반으로 트래픽을 여러 서버로 분산.
• 클라이언트가 접속하기 전에 DNS 레벨에서 분산 처리.
• 예) Amazon Route 53, Google Cloud DNS.

4. 클라우드 네이티브 로드밸런서
• 클라우드 서비스 제공자가 제공하는 로드밸런서.
• 예) AWS Elastic Load Balancer(ELB), Azure Load Balancer, Google Cloud Load Balancer.

로드밸런싱 알고리즘

1. 라운드 로빈 (Round Robin)
• 각 요청을 서버에 순차적으로 분배.
• 균등하게 트래픽을 분산하며, 설정이 간단.
• 단점: 서버의 부하 상황을 고려하지 않음.
2. 가중치 라운드 로빈 (Weighted Round Robin)
• 각 서버에 가중치를 부여하고, 가중치 비율에 따라 트래픽을 분배.
• 서버의 성능 차이를 고려할 수 있음.
3. 최소 연결 (Least Connections)
• 현재 연결이 가장 적은 서버로 트래픽을 분배.
• 서버 부하를 동적으로 반영.
4. 가중치 최소 연결 (Weighted Least Connections)
• 서버 성능에 따라 가중치를 부여하고, 연결 수와 가중치를 함께 고려.
5. IP 해시 (IP Hash)
• 클라이언트의 IP 주소를 해싱하여 특정 서버에 연결.
• 특정 사용자가 항상 같은 서버를 연결해야 하는 경우 유용.
6. 응답 시간 기반 (Response Time-Based)
• 각 서버의 응답 시간을 기준으로 트래픽을 분배.
• 응답이 빠른 서버에 더 많은 요청을 할당.
7. 최소 요청 (Least Request)
• 요청 대기열이 가장 짧은 서버로 트래픽을 분배.
• 실시간으로 서버의 요청 상태를 고려.
8. URL 기반 (URL Hashing)
• 요청 URL을 해싱하여 특정 서버로 분배.
• 캐시 서버나 특정 데이터와 관련된 요청을 처리할 때 유용.
9. 랜덤 (Random)
• 요청을 임의의 서버로 분배.
• 설정이 간단하지만 효율성이 낮음.

로드밸런서 선택 시 고려 사항

1. 트래픽 규모: 트래픽 크기와 패턴에 따라 하드웨어 또는 소프트웨어를 선택.
2. 서버 성능: 서버 간 부하 분산의 적합성을 고려.
3. 알고리즘 적합성: 워크로드와 시스템 구조에 맞는 알고리즘 선택.
4. 확장성: 클라우드 환경에서의 확장 및 자동화 여부.
5. 보안: SSL 종료, 방화벽 기능 등의 요구사항 반영.


SSL 핸드쉐이크 개요

SSL 핸드쉐이크는 클라이언트와 서버 간에 안전한 통신 채널을 설정하기 위해 이루어지는 과정입니다. 이 과정은 양측이 서로를 인증하고 암호화 키를 교환하여 이후 통신을 암호화하는 데 사용됩니다.

SSL 핸드쉐이크의 주요 단계

1. 클라이언트 헬로우 (Client Hello)
• 클라이언트가 서버에 접속을 요청하며 다음 정보를 전달:
• 지원하는 암호화 알고리즘(예: AES, RSA).
• 지원하는 프로토콜 버전(TLS 1.2, TLS 1.3 등).
• 임의의 난수(Random Value) 생성.
2. 서버 헬로우 (Server Hello)
• 서버가 클라이언트 요청에 응답하며 다음 정보를 전달:
• 선택된 암호화 알고리즘.
• 선택된 프로토콜 버전.
• 서버의 임의 난수(Random Value).
3. 서버 인증 및 키 교환
• 서버는 자신의 디지털 인증서(SSL 인증서)를 클라이언트에 전달.
• 인증서에는 서버의 공개키(Public Key)와 인증기관(CA) 서명이 포함됨.
• 클라이언트는 인증서를 검증(CA 신뢰 여부, 만료 여부 등)함.
4. 세션 키 생성
• 클라이언트는 서버의 공개키를 사용해 암호화된 “프리마스터 키”를 서버에 전송.
• 서버는 자신의 비공개키(Private Key)로 이를 복호화하여 세션 키(Session Key)를 생성.
• 클라이언트와 서버는 세션 키를 공유하고 이후 통신은 대칭키 암호화로 진행.
5. 완료
• 핸드쉐이크가 완료되면 클라이언트와 서버는 암호화된 데이터 전송을 시작.

SSL 핸드쉐이크와 로드밸런서(LB)

로드밸런서와 백엔드 서버 간의 SSL 핸드쉐이크 처리 방식은 크게 두 가지로 나뉩니다:

1. 로드밸런서에서 SSL 종료 (SSL Termination)

• 설명: SSL 핸드쉐이크 및 암호화/복호화 작업을 로드밸런서에서 처리.
• 장점:
• 백엔드 서버의 부하를 줄임.
• 암호화/복호화 처리가 중앙에서 이루어져 관리가 용이.
• 백엔드 서버와의 통신은 일반 HTTP로 처리되어 성능 향상.
• 단점:
• LB와 백엔드 서버 간 통신은 암호화되지 않으므로 보안 취약 가능성.

2. 엔드투엔드 SSL (SSL Passthrough)

• 설명: SSL 핸드쉐이크 및 암호화/복호화 작업을 백엔드 서버에서 처리.
• 장점:
• 클라이언트와 백엔드 서버 간의 완전한 암호화 제공.
• 보안 요구사항이 높은 애플리케이션에 적합.
• 단점:
• 백엔드 서버의 부하 증가.
• SSL 인증서 관리를 모든 백엔드 서버에서 해야 하므로 관리 복잡성 증가.

3. SSL 종료 후 재암호화 (SSL Re-encryption)

• 설명: LB에서 SSL 핸드쉐이크를 처리한 후, LB와 백엔드 서버 간에도 SSL을 설정.
• 장점:
• 클라이언트와 LB 간, LB와 백엔드 간 모두 암호화 제공.
• 보안과 성능 간의 균형.
• 단점:
• LB와 백엔드 서버 간 추가 암호화/복호화 작업으로 약간의 성능 감소.

비교: LB와 인스턴스의 SSL 핸드쉐이크 처리
LB 에서 처리
- 백엔드 서버 부하 감소
- 간단
- 암호에 취약해

인스턴스 백엔드에서 처리
- 백엔드 서버 부하 증가
- 종단간 암호화 없음
- 인증서 분산 관리 필요… !

사용 사례

1. LB에서 SSL 종료 (Termination):
• 웹 서비스 트래픽이 많은 경우.
• 내부 네트워크가 신뢰할 수 있는 환경인 경우.
2. SSL Passthrough:
• 민감한 데이터 전송이 필요한 금융 서비스.
• 내부 네트워크 보안이 완전히 신뢰할 수 없는 경우.
3. SSL Re-encryption:
• 클라우드 환경에서 보안과 성능 모두 요구되는 경우.
• 보안 규정이 엄격하지만 성능도 고려해야 하는 경우.

결론

로드밸런서와 인스턴스에서의 SSL 핸드쉐이크 처리 방식은 시스템 아키텍처와 보안 요구사항에 따라 선택해야 합니다. 보안이 우선이라면 **엔드투엔드 암호화(SSL Passthrough)**를, 성능이 우선이라면 SSL Termination을, 두 가지의 균형이 필요하다면 SSL Re-encryption을 고려하면 됩니다.

로드밸런싱은 단순 트래픽 분배뿐 아니라, 장애 복구(Failover), 트래픽 암호화 및 해제(SSL Termination), 보안 정책 등 다양한 기능도 함께 제공하므로 시스템 설계에 중요한 요소입니다.