트래픽 관리 - 로드 밸런서

https://product.kyobobook.co.kr/detail/S000211468119

모니터링의 새로운 미래 관측 가능성 | 정현석 - 교보문고

 

 

[모니터링의 새로운 미래 관측 가능성] 를 공부하며 정리하는 포스트입니다.

 

트래픽 관리

단일 구조

클라우드 환경은 많은 사용자들이 공용의 리소스를 사용하는 멀티 테넌트 환경입니다. 많은 장애의 대부분은 사용자가 알지 못하는 사이에 발생할 가능성이 높기 때문에 장애 발생으로 인한 원인 분석이 미흡하고, 고객에게 정확한 사실이 전달되지 않는다는 단점이 있습니다.

 

분산 클라우드 네이티브 환경에서 대부분의 치명적인 장애는 네트워크와 관련이 있습니다. 클라우드사업자의 데이터 센터는 다중화 시스템으로 구성됨에도 불구하고 네트워크로 인한 장애는 치명적이고, 간혹 서비스 이용이 불가능한 상황이 발생하기도 합니다. 특히 로드 밸런서, 웹서버 엑세스 로그, 보안 접근 제어 데이터 등은 중요하게 관리해야 합니다. 나아가 쿠버네티스의 네트워크 구성은 복잡한데 DNS(kube-dns), proxy(kube-proxy), gateway(ingress)를 내부적으로 관리하며, 각 구성 요소에 문제가 발생하면 클러스터 전체에 장애로 이어집니다.

 

네트워크는 SPOF(single point of failure/단일 장애점)의 특징을 갖고 있어, 네트워크 장애가 생기면 기업과 고객에게 많은 손해를 입히게 됩니다.

 

로드 밸런서

복원성이 뛰어나고 탄력적인 네트워크를 구축하기 위해서는 로드 밸런서(load balancer)가 필요합니다. 클라우드와 쿠버네티스를 도입함으로써 네트워크 구조가 복잡해졌고, 그로 인해 여러 개의 DNS서버와 여러 유형의 로드 밸런서를 구성해야 합니다.

 

AWS 기반의 네트워크 흐름

외부에서 유입되는 트래픽은 AWS NAT 게이트웨이를 통해 VPC로 유입됩니다. VPC 내부는 여러 개의 서브넷으로 구성되며 해당 트래픽이 들어온 서브넷에서 AWS ELB(Elastic Load Balancer)를 경유하여 쿠버네티스 클러스터 내부로 트래픽이 들어오게 됩니다. 그 후 쿠버네티스의 인그레스의 경로에 맞게 특정 애플리케이션으로 라우팅 됩니다. 라우팅된 트래픽은 CoreDNS를 통해 서비스를 찾아내고 kube-proxy를 통해 특정 pod로 로드 밸런싱합니다.

 

 

플랫폼 로드 밸런싱

- AWS ELB, Nginx가 대표적인 예시이며, 레이어 4계층은 네트워크 로드밸런서, 레이어 7계층은 애플리케이션 로드 밸런서를 제공합니다.

- Grafana Observability는 Nginx를 사용하여 플랫폼 로드 밸런서를 구현하고, 퍼블릭 클라우드에서 사용하는 경우엔 Nginx 앞에 AWS Application LoadBalancer(ALB)를 사용합니다. 나아가 Nginx Reverse Proxy를 사용하며 Configmap을 사용하여  Nginx에 Nginx Reverse Proxy 구성 파일을 생성해야 합니다.

- 라운드 로빈 방식으로 게이트웨이에 사용자 트래픽을 분산합니다.

 

게이트 웨이 로드 밸런싱

- Spring Cloud Gateway, Netflix Zuul 처럼 소프트웨어 기반 게이트웨이는 오픈 소스로 쉽게 구현할 수 있습니다. 일반적인 용어로는 API Gateway라고 하며, 자바의 SpringBoot나 Node의 Express, Python의 Flask를 지칭하지는 않습니다.

- API 게이트 웨이는 기본적인 Routing 기능을 포함해서 비율 제한 A/B 테스트, 카나리아 배포를 제공하며, 쿠버네티스 연계를 위한 ingress 기능도 제공합니다.

- 기본적인 쿠버네티스 ingress와는 다르게 다양한 기능을 제공하며, 높은 안정성과 확장성을 제공합니다. Proxy와 Sidecar 방식이 아니므로 클라이언트 측 부하 분산과 비교해서 복원성 기능은 부족합니다. 이에 Istio는 많은 장점을 제공하지만 Sidecar 방식으로 인해서 추가적인 리소스가 필요하며, Proxy가 네트워크 전반을 제어하므로 불필요한 네트워크 트래픽이 발생합니다. Service Mesh와 멀티 클러스터 때문에 Istio를 사용하는데 Cilium CNI를 사용해서 Sidecar없이 Linux kurnel 레벨에서 구현하는 것이 좋습니다.

 

 

클라이언트 측 부하 분산

- 클라이언트 측 로드 밸런서는 A 서비스의 애플리케이션 코드 일부로 구현됩니다. 인스턴스 목록은 일반적으로 Netflix Eureka나 HashiCorp Consul 등의 디스커버리 서비스에서 얻고, 로드 밸런서는 B 인스턴스를 선정해 트래픽을 전달합니다. 따라서 B 서비스 앞단에 플랫폼 로드밸런서가 필요하지 않습니다.

- 클라이언트 측 로드 밸런싱은 다양한 목적을 활용됩니다. 원래는 Netflix Eureka나 HashiCorp Consul 등의 디스커버리 메커니즘에서 서버 IP나 Hostname을 동적으로 가져오기 위하여 사용했고, Netflix Eureka와 Istio는 클라이언트 측 부하 분산을 구현한 best practice입니다.