AWS 로드밸런서를 운영하다 보면 가용 영역 하나에서 장애가 났을 때 트래픽이 특정 서버로 몰리거나, 배포 중에 요청이 끊겨 사용자 불만이 생기는 상황을 겪게 됩니다. 이 글에서 다루는 크로스존 로드밸런싱, SSL 종료, 커넥션 드레이닝 설정은 이런 장애 상황에서 서비스 연속성을 유지하는 데 핵심적인 역할을 합니다. 세 가지 설정을 제대로 적용하면 인프라 장애로 인한 서비스 중단과 요청 유실을 상당 부분 줄일 수 있습니다.
크로스존 로드밸런싱을 켜야 트래픽이 한쪽에 몰리지 않는다
로드밸런서는 기본적으로 요청이 들어온 가용 영역(AZ)에 있는 EC2 인스턴스에만 트래픽을 전달합니다. 예를 들어 가용 영역 A와 B에 각각 인스턴스가 3대씩 있는데, 클라이언트 DNS 캐시 때문에 A로 요청이 70% 몰린다면 A의 인스턴스 3대가 과부하에 걸리고 B의 인스턴스 3대는 상대적으로 한가해집니다.
크로스존 로드밸런싱(Cross-Zone Load Balancing)을 활성화하면 로드밸런서 노드가 모든 가용 영역에 등록된 인스턴스를 하나의 풀로 보고 트래픽을 균등하게 분산합니다. A로 들어온 요청이 B에 있는 인스턴스로도 전달될 수 있다는 뜻입니다. 참고 자료에 따르면 이 기능을 켜면 가용 영역마다 인스턴스 개수가 달라도 트래픽이 특정 영역에 쏠리는 현상을 방지할 수 있습니다.
- 크로스존을 켜면 가용 영역별 인스턴스 수가 달라도 부하가 자동으로 균형을 이룸
- 특정 가용 영역의 인스턴스가 다운되면 다른 영역의 인스턴스가 요청을 수용하므로 장애 영향 범위가 줄어듦
- AWS Management Console에서 로드밸런서 속성 편집 화면에 들어가 크로스존 로드밸런싱을 활성화하면 됨
만약 가용 영역마다 인스턴스 용량이 다르거나, 특정 영역의 인스턴스가 더 좋은 사양이라면 크로스존을 끄고 가중치를 두는 방식도 고려할 수 있습니다. 하지만 대부분의 웹 서비스에서는 크로스존을 켜는 것이 장애 허용 측면에서 유리합니다.
SSL 종료를 로드밸런서에서 처리하면 서버 부담이 줄어든다
SSL은 클라이언트와 로드밸런서 사이의 트래픽을 암호화하는 역할을 합니다. 네트워크를 이동하는 동안 데이터가 암호화되고, 송신자와 수신자 측에서만 복호화할 수 있기 때문에 중간에 패킷을 가로채도 내용을 읽을 수 없습니다. AWS에서는 ACM(AWS Certificate Manager)을 통해 SSL 인증서를 발급받아 로드밸런서에 직접 적용할 수 있습니다.
로드밸런서에서 SSL을 종료하면 클라이언트와 로드밸런서 구간은 HTTPS로 암호화되고, 로드밸런서와 백엔드 EC2 인스턴스 사이는 HTTP로 통신할 수 있습니다. 이렇게 하면 각 EC2 인스턴스에 인증서를 설치하고 관리할 필요가 없어져 운영 부담이 줄어듭니다. 참고 자료에서는 SSL이 전송 중(in-flight) 데이터 암호화를 담당하며, 이를 통해 사용자 신뢰를 확보하고 데이터 안전성을 높일 수 있다고 설명합니다.
- ACM에서 인증서를 발급받아 로드밸런서 리스너에 HTTPS(443) 규칙으로 연결
- 인스턴스별 인증서 설치 없이 로드밸런서에서 일괄적으로 SSL 처리 가능
- 인스턴스와 로드밸런서 사이는 VPC 내부 통신이므로 별도 암호화가 필요 없는 경우가 많음
주의할 점은 보안 요구사항이 엄격한 환경에서는 로드밸런서와 백엔드 사이도 암호화해야 할 수 있습니다. 이 경우 백엔드에 인증서를 설치하고 HTTPS로 통신하도록 구성해야 하므로, 내부 트래픽 암호화 정책을 먼저 확인하는 것이 좋습니다.
커넥션 드레이닝으로 배포 중 요청 유실을 막는 방법
커넥션 드레이닝(Connection Draining)은 로드밸런서에 등록된 인스턴스가 종료될 때, 이미 진행 중인 요청을 안전하게 완료시키고 새로운 요청은 다른 인스턴스로 보내는 기능입니다. 배포나 스케일인 과정에서 인스턴스가 갑자기 종료되면 사용자가 파일 업로드나 결제 같은 중요한 요청을 처리하는 도중 연결이 끊길 수 있는데, 이 설정을 활성화하면 이런 문제를 방지할 수 있습니다.
AWS에서는 대상 그룹의 등록 취소 지연(deregistration delay) 설정을 통해 커넥션 드레이닝 시간을 조정합니다. 이 시간 동안 로드밸런서는 해당 인스턴스로 새 요청을 보내지 않고, 기존 연결이 끝나기를 기다립니다. 참고 자료에서는 이 기능이 서비스 종료나 업데이트 시 연결을 안전하게 종료하는 데 사용되며, 데이터 손실을 방지한다고 설명합니다.
- 대상 그룹 속성에서 등록 취소 지연 값을 설정하면 커넥션 드레이닝이 동작
- 일반적으로 30초에서 300초 사이로 설정하며, 처리 중인 요청이 길게 유지되는 서비스라면 더 긴 시간을 지정
- Auto Scaling 축소 정책과 연동하면 인스턴스가 종료될 때 자동으로 드레이닝이 적용됨
드레이닝 시간을 너무 길게 설정하면 배포나 스케일인이 지연될 수 있고, 너무 짧게 설정하면 요청이 유실될 수 있습니다. 서비스 특성에 맞춰 요청 처리 시간을 측정한 뒤 여유를 두고 설정하는 것이 바람직합니다.
설정 적용 후 장애 대응이 달라지는 지점
세 가지 설정을 모두 적용하면 장애 상황에서의 동작 방식이 확연히 달라집니다. 크로스존 로드밸런싱이 켜져 있으면 특정 가용 영역의 인스턴스가 다운되어도 나머지 영역의 인스턴스가 트래픽을 흡수합니다. SSL을 로드밸런서에서 처리하면 인스턴스 교체 시 인증서 문제로 서비스가 중단되는 일이 없습니다. 커넥션 드레이닝이 활성화되어 있으면 배포 중에도 진행 중이던 요청이 끝까지 처리됩니다.
실제 운영 환경에서는 이 세 가지 설정이 단독으로 적용되기보다 함께 구성되어야 효과를 발휘합니다. 크로스존으로 부하를 분산하면서도 SSL 종료를 통해 보안을 유지하고, 배포 시에는 커넥션 드레이닝으로 요청 유실을 방지하는 식입니다. AWS CLI를 사용하는 경우 다음 명령어로 각 속성을 확인하고 변경할 수 있습니다.
aws elbv2 modify-load-balancer-attributes --load-balancer-arn <로드 밸런서 ARN> --attributes Key=load_balancing.cross_zone.enabled,Value=true
aws elbv2 modify-target-group-attributes --target-group-arn <대상 그룹 ARN> --attributes Key=deregistration_delay.timeout_seconds,Value=60
설정을 변경한 뒤에는 반드시 대상 그룹의 상태 확인(health check) 결과와 함께 실제 트래픽이 의도한 대로 분산되는지 모니터링해야 합니다. 장애 상황을 가정한 테스트를 주기적으로 수행해 두면 실제 장애 발생 시 대응이 훨씬 수월해집니다.