Amazon EKS 데이터 전송 비용 절감 사례 (SRE 밋업 3회)

주요 구간

• 03:35 크로스존 트래픽이 생기는 곳 확인하기
• 06:46 Istio Locality LB 적용과 테스트 환경
• 08:53 Outlier Detection이 필요한 이유
• 10:56 Istio를 쓰지 않는 서비스의 Topology Aware Hints
• 13:00 비용 절감 결과와 고려할 점
• 15:01 Envoy와 kube-proxy 내부 동작

비용이 큰 통신 구간 찾기

당근은 멀티 AZ EKS에서 가용 영역(AZ)을 넘는 파드 간 호출에 드는 데이터 전송 비용을 줄이려 했습니다. 어떤 파드가 얼마나 보내는지 확인하려고 VPC Flow Logs와 파드 메타데이터를 S3에 모으고 Athena로 조인했습니다.

비용이 가장 큰 곳은 외부 트래픽을 받는 Istio Ingress Gateway였고, Istio 메시 안의 파드 간 통신에서도 크로스존 트래픽이 많이 발생했습니다. Istiod와 모니터링 비용도 예상보다 컸습니다. 한 영역의 수집기가 다른 영역 파드의 메트릭을 가져가는 통신 때문입니다.

같은 영역으로 보내도록 설정

Istio 서비스에는 Locality Load Balancing과 Outlier Detection을 함께 적용했습니다. 발표자는 영역마다 Hello world 파드를 하나씩 두고 curl로 호출해 동작을 확인했습니다. DestinationRule에서 localityLbSetting만 켰을 때는 양쪽 영역의 파드가 모두 응답했고, Outlier Detection을 추가한 뒤에야 같은 영역의 파드만 응답했습니다.

Istio는 EKS 워커 노드의 리전·영역 정보를 읽어 사이드카 프록시 설정에 넣으므로 같은 영역의 파드를 우선 선택할 수 있습니다. 같은 영역에 정상 파드가 없으면 다른 영역으로 장애 조치해야 하며, 이 판단에 Outlier Detection이 필요합니다. 발표자가 Istio 커뮤니티에서 얻은 답도 이 설정이 필수라는 것이었습니다.

Istio를 쓰지 않는 서비스에는 Kubernetes Service의 Topology Aware Hints 어노테이션을 auto로 설정했습니다. EndpointSlice에 들어간 영역 정보를 바탕으로 kube-proxy가 같은 영역의 파드로만 보내는 iptables 규칙을 만듭니다. 같은 방식의 데모에서도 같은 영역의 파드만 응답했습니다. 발표자는 다른 영역 사이드카의 프록시 설정까지 전송할 이유가 없다며, Istio를 쓰는 경우에도 Istiod 서비스에 이 설정을 꼭 적용하라고 권합니다.

설정 적용 뒤 비용 변화

서비스 코드는 바꾸지 않고 Locality LB와 Topology Aware Hints 설정만 적용했습니다. 적용 다음 날 일 비용은 절반 아래로 줄었습니다. 월 단위로도 2월 말 적용 후 4월 청구액이 2월의 절반 이하로 내려갔습니다(슬라이드 막대 그래프).

영역별 파드 분포 주의

발표자는 한 영역 전체가 내려가면 Outlier Detection으로 다른 영역에 장애 조치하므로 문제가 없다고 설명합니다. 주의할 상황은 파드가 한 영역에 몰리도록 배포될 때입니다. 같은 영역으로 트래픽이 쏠리므로 파드를 영역별로 고르게 배포하는 일이 중요하며, 이 쏠림은 모니터링 발표의 가용 영역 쏠림 모니터로 이어집니다.

이 발표는 멀티 AZ 구성을 유지하는 환경을 전제로 합니다. 발표자는 비용 절감만 목표라면 단일 영역 클러스터 여러 개를 액티브-액티브로 묶는 구성이 답일 수도 있다고 덧붙입니다.