[번역] 최신 네트워크 로드 밸런싱 및 프록시 소개

2018-11-05

#Microservice | #Load Balancing | #DevOps

Envoy Creator인 Matt Klein의 Envoy 소개 동영상을 보고 Envoy에 완전히 매료되어 좀 더 자세한 배경지식을 알고자 번역해 보았습니다. 원본 출처는 Introduction to modern network load balancing and proxying입니다.

최근 네트워크 로드 밸런싱과 프록시에 관한 입문 교육 자료가 부족하다는 사실이 관심을 끌었습니다. 어떻게 이게 가능하지? 라고 속으로 생각했습니다. 로드 밸런싱은 안정적인 분산 시스템 구축에 필요한 핵심 개념 중 하나입니다. 당연히 쓸만한 고급진 정보들이 있어야 합니다. 검색을 해보았으나 사실 쓸만한 것들이 별로 없다는 것을 알게 되었습니다. 위키피디아 기사에는 일부 개념에 대한 개요가 포함되어 있긴 하나, 우아한 내용들은 아니었습니다. 특히, 최신 마이크로 서비스 아키텍처에 관해서 말이죠. 로드 밸런싱을 대한 구글 검색은 주로 버즈 워드가 많고 내용은 없는 벤더 페이지들입니다.

이 글에서 저는 최신 네트워크 로드밸런싱과 프록시를 소개하며 정보 부족을 해결하려고 합니다. 이것은, 솔직히 말해서, 책 한 권 전체의 주제가 될 수 있는 방대한 주제입니다. 이 포스트의 블로그 길이를 유념하면서 복잡한 주제 세트를 간단한 개요로 뽑아보려고 합니다. 관심과 피드백에 따라 추후 개별 주제에 대한 자세한 후속 포스트를 고려해 보겠습니다.

특이하고 이상한 이 글을 왜 썼는지에 대한 약간의 배경과 함께 - 시작하겠습니다!

네트워크 로드 밸런싱과 프록싱이 무엇인가요?

위키피디아는 다음과 같이 로드 밸런싱을 정의합니다:

컴퓨팅에서 로드 밸런싱은 컴퓨터, 컴퓨터 클러스터, 네트워크 링크, 중앙 처리 장치 또는 디스크 드라이브와 같은 여러 컴퓨팅 리소스에서 작업 부하 분산을 향상시킵니다. 로드 밸런싱은 리소스 사용을 최적화하고 처리량을 극대화하며 응답 시간을 최소화하고 단일 리소스의 오버로드를 방지하는 것을 목표로 합니다. 단일 구성 요소 대신 로드 밸런싱과 함께 여러 구성 요소를 사용하면 이중화를 통해 안정성과 가용성을 높일 수 있습니다. 로드 밸런싱은 보통 멀티 레이어 스위치 또는 도메인 이름 시스템 서버 프로세스와 같은 전용 소프트웨어 또는 하드웨어가 사용됩니다.

위의 정의는 네트워크뿐만 아니라 컴퓨팅의 모든 측면에 적용됩니다. 운영 체제는 로드 밸런싱을 사용하여 물리적 프로세서 간에 작업을 스케줄링하고, Kubernetes과 같은 컨테이너 오케스트레이터는 로드 밸런싱을 사용하여 컴퓨팅 클러스터 전체에서 작업을 스케줄링하고, 네트워크 로드 밸런서는 사용 가능한 백엔드에서 네트워크 작업을 스케줄링합니다. 이 포스트의 나머지 부분에서는 네트워크 로드 밸런싱만 다룹니다.

그림 1. 네트워크 로드 밸런싱 개요

그림 1은 네트워크 로드 밸런싱의 개략적인 개요를 보여줍니다. 일부 클라이언트는 일부 백엔드에 리소스를 요청하고 있습니다. 로드 밸런서는 클라이언트와 백엔드 사이에 위치하며 상위 레벨에서 몇 가지 중요한 작업을 수행합니다.

  • 서비스 디스커버리: 시스템에서 사용할 수 있는 백엔드는 무엇인가요? 그들 주소가 어떻게 되나요?
  • 헬스 체킹: 현재 정상이며 요청을 수락할 수 있는 백엔드는 무엇인가요?
  • 로드 밸런싱: 모든 정상적인 백엔드에 대한 개별 요청의 균형을 맞추기 위해 어떤 알고리즘을 사용해야 할까요?

분산 시스템에서 로드 밸런싱을 적절하게 사용하면 다음과 같은 몇 가지 이점이 있습니다.

  • 네이밍 추상화: 모든 클라이언트가 모든 백엔드(서비스 디스커버리)을 알아야 하는 대신에, 클라이언트가 미리 정의된 메커니즘으로 로드 밸런서를 지칭하고, 이름 확인(Name resolution) 작업은 로드 밸런서에 위임할 수 있습니다. 미리 정의된 메커니즘은 기본 제공 라이브러리 및 잘 알려진 DNS/IP/포트 위치를 포함하며 아래에서 보다 자세히 설명합니다.

  • 장애 허용: 상태 확인 및 다양한 알고리즘 기술을 통해 로드 밸런서는 불량 또는 과부하가 걸린 백엔드를 효과적으로 라우팅할 수 있습니다. 이는 운영자가 전형적인 여가 시간 대비 비상 조치로 불량 백엔드를 수정할 수 있다는 것을 뜻합니다.

  • 비용 및 성능 이점: 분산 시스템 네트워크는 거의 동질적인 집단으로 구성되지 않습니다. 시스템은 여러 네트워크 Zone과 Region에 걸쳐 있을 가능성이 높습니다. Zone 내에서, 네트워크는 종종 상대적으로 요청량이 낮은 방법으로 구축됩니다. Zone 간에 과다 요청이 표준이 됩니다. 지능형 로드 밸런싱을 통해 가능한 많은 Zone 내에서 요청 트래픽을 유지할 수 있으므로 성능 (대기 시간 감소)이 향상되고 전체 시스템 비용이 절감됩니다 (Zone간 대역폭 및 광섬유 필요 감소).

로드 밸런서 대 프록시

네트워크 로드 밸런싱 장치에 대해 이야기할 때, 로드 밸런싱 장치 및 프록시라는 용어는 업계 내에서 대략적으로 서로 혼용할 수 있습니다. 이 포스트 또한 용어들을 일반적으로 동등한 것으로 취급합니다. (엄밀히 따지면, 모든 프록시가 로드 밸런서는 아니지만 대다수의 프록시는 로드 밸런싱이 기본적인 기능입니다.)

일부에서는 내장형 클라이언트 라이브러리의 부분으로 로드 밸런싱을 수행하면 로드 밸런서가 실제로 프록시가 아니라고 덧붙이며 주장할 수 있습니다. 그러나, 저는 구별이 이미 혼란스러운 주제에 불필요한 복잡성을 더하는 것이라고 반박합니다. 로드 밸런서 토폴로지의 유형은 아래에서 자세히 설명되지만, 이 포스트에서는 내장형 로드 밸런서 토폴로지를 프록시 방식의 특수한 경우로 취급하는데 이 때 애플리케이션은 로드 밸런서와 동일한 추상화를 모두 제공하는 내장된 라이브러리를 통해 프록시합니다.

L4 (연결/세션) 로드 밸런싱

오늘날 업계 전반에서 로드 밸런싱을 논의할 때 솔루션은 종종 L4와 L7의 두 가지 범주로 분류됩니다. 이러한 범주는 OSI 모델의 4계층과 7계층을 참조합니다. L7 로드 밸런싱에 대해 논의할 때 명확해질 수 있는 이유 때문에, 이것이 우리가 사용하는 용어라는 것은 유감스러운 일이라고 생각합니다. OSI 모델은 TCP 및 UDP와 같은 기존 4계층 프로토콜을 포함하지만 종종 다양한 OSI 계층의 이런저런 잡동사니 프로토콜(예, 만약 L4 TCP 로드 밸런서가 마찬가지로 TLS을 지원하게 되면, 이제 L7 로드 밸런서가 되는 건가요?)을 포함하기 일쑤인지라 로드 밸런싱 솔루션의 복잡성에 대한 매우 낮은 근사치입니다.

그림 2. TCP L4 종료 로드 밸런싱

그림 2는 기존 L4 TCP 로드 밸런서를 보여줍니다. 이 경우 클라이언트는 로드 밸런서에 TCP를 연결합니다. 로드 밸런서는 연결을 종료하고(예, SYN에 직접 응답하고) 백엔드를 선택한 다음 새 TCP 연결을 만듭니다(예, 새 SYN 전송). 다이어그램의 세부 정보는 중요하지 않으며 아래 L4 로드 밸런싱에 할애된 섹션에서 자세히 논의하겠습니다.

이 섹션의 핵심 사항은 L4 로드 밸런서가 일반적으로 L4 TCP/UDP 연결/세션 수준에서만 작동한다는 것입니다. 따라서 로드 밸런서는 바이트 앞뒤를 거칠게 셔플해서, 동일한 세션의 바이트가 동일한 백엔드에서 끝나도록 합니다. L4 로드 밸런서는 셔플링 중인 바이트의 애플리케이션 세부 정보를 인식하지 못합니다. 바이트는 HTTP, Redis, MongoDB 또는 다른 애플리케이션 프로토콜일 수 있습니다.

L7 (어플리케이션) 로드 밸런싱

L4 로드 밸런싱은 간단하면서도 널리 사용됩니다. L7 (애플리케이션) 로드 밸런싱 투자를 보증하는 L4 로드 밸런싱의 단점은 무엇일까요? 다음 L4 관련 사례를 예로 들어 보겠습니다.

  • 두 개의 gRPC/HTTP2 클라이언트는 백엔드와 통신하며 L4 로드 밸런서를 통해 연결하려고 합니다.
  • L4 로드 밸런서는 들어오는 각 TCP 연결에 대해 단일 송신 TCP 연결을 생성하므로 두 개의 수신 연결과 두 개의 송신 연결이 발생합니다.
  • 그런데, 클라이언트 A는 연결을 통해 분당 1개의 요청(RPM)을 보내고 클라이언트 B는 연결을 통해 초당 50개의 요청(RPS)을 보냅니다.

이전 시나리오에서 클라이언트 A를 처리하기 위해 선택된 백엔드는 클라이언트 B를 처리하기 위해 선택된 백엔드에 비해 약 3,000배의 부하를 처리합니다! 이것은 큰 문제이며, 일반적으로 시작부터 로드 밸런싱의 목적을 무산시킵니다. 또한 이 문제는 모든 멀티플렉싱, keep-alive 프로토콜에서 발생합니다. (멀티플렉싱은 단일 L4 연결을 통해 동시 응용 프로그램 요청을 보내고 사용 중인 요청이 없을 때 연결을 닫지 않는 것을 의미합니다.) 최신 프로토콜은 모두 효율성 이유(특히 TLS를 사용하여 연결을 암호화하는 경우)로 멀티플렉싱와 keep-alive 두 가지로 진화하고 있으므로 L4 로드 밸런서의 임피던스 불일치가 시간이 지남에 따라 더욱 뚜렷해지고 있습니다. L7 로드 밸런서가 이 문제를 해결합니다.

그림 3. HTTP/2 L7 종료 로드 밸런싱

그림 3은 L7 HTTP/2 로드 밸런서를 보여줍니다. 이 경우 클라이언트는 로드 밸런서에 단일 HTTP/2 TCP를 연결합니다. 그런 다음 로드 밸런서는 두 개의 백엔드 연결을 만듭니다. 클라이언트가 두 개의 HTTP/2 스트림을 로드 밸런서에 전송하면 스트림 1은 백엔드 1로 전송되고 스트림 2는 백엔드 2로 전송됩니다. 따라서 요청 부하가 매우 다른 멀티플렉싱 클라이언트도 백엔드에서 효율적으로 균형을 맞출 것입니다. 이것이 바로 L7 로드 밸런싱이 최신 프로토콜에 매우 중요한 이유입니다.

L7 로드 밸런싱 그리고 OSI 모델

앞서 L4 로드 밸런싱 섹션에서 말씀드린 것처럼 로드 밸런싱 기능을 설명하기 위해 OSI 모델을 사용하는 것은 문제가 있습니다. 그 이유는, 다른 것은 몰라도 OSI 모델에서 기술되는 것과 같이, L7 자체가 로드 밸런싱 추상화의 여러 개별 계층을 포괄하기 때문입니다. 예를 들어 HTTP 트래픽의 경우 다음과 같은 하위 계층을 생각해 볼 수 있습니다.

  • 선택적 TLS(Transport Layer Security). 네트워크쪽 사람들이 어떤 OSI 계층이 TLS에 속하는지 논의 중입니다. 이 논의를 위해 우리는 TLS L7을 검토할 것입니다.
  • 물리적 HTTP 프로토콜(HTTP/1 또는 HTTP/2).
  • 논리적 HTTP 프로토콜(헤더, 본문 데이터 및 트레일러).
  • 메시징 프로토콜(gRPC, REST 등).

정교한 L7 로드 밸런싱 장치는 위의 각 하위 계층과 관련된 기능을 제공할 수 있습니다. 다른 L7 로드 밸런서에는 L7 범주에 속하는 기능 중 작은 부분만 있을 수 있습니다. 즉, L7 로드 밸런서 환경은 L4 범주보다 기능을 비교하는 관점에서 훨씬 더 복잡합니다. (물론 이 섹션에서는 HTTP에 대해 좀전에 다루었습니다. Redis, Kafka, MongoDB 등은 모두 L7 로드 밸런싱의 이점을 제공하는 L7 애플리케이션 프로토콜의 예입니다.)

로드 밸런서 기능

이 섹션에서는 로드 밸런서가 제공하는 상위 레벨 기능을 간략하게 요약합니다. 모든 로드 밸런서가 모든 기능을 제공하는 것은 아닙니다.

서비스 디스커버리 (Service discovery)

서비스 디스커버리는 로드 밸런서가 사용 가능한 백엔드 셋을 결정하는 프로세스입니다. 방법은 매우 다양하며 다음과 같은 예를 들 수 있습니다.

헬스 체킹 (Health checking)

헬스 체킹은 로드 밸런서가 트래픽을 처리하는데 백엔드를 사용할 수 있는지 여부를 결정하는 프로세스입니다. 헬스 체킹은 일반적으로 두 가지 범주로 나뉩니다.

  • 활성: 로드 밸런서가 주기적인 간격(예: HTTP 요청을 /healthcheck 엔드포인트에 전송)을 통해 상태를 측정합니다.
  • 수동: 로드 밸런서가 주 데이터 플로우에서 상태를 감지합니다. 예를 들어, L4 로드 밸런서는 연속 3개의 연결 오류가 있는 경우 백엔드가 비정상이라고 결정할 수 있습니다. L7 로드 밸런서는 연속 세 개의 HTTP 503 응답 코드가 있는 경우 백엔드가 비정상이라고 결정할 수 있습니다.

부하 분산 (Load balancing)

그렇죠. 로드 밸런서는 실제로 부하 분산을 해야합니다! 정상적인 백엔드 셋이 주어질 때, 연결이나 요청에 적합한 백엔드는 어떻게 선택될까요? 로드 밸런싱 알고리즘은 활발한 리서치 영역이며 랜덤 선택 및 라운드 로빈과 같은 단순한 영역에서 다양한 레이턴시 및 백엔드 부하를 계산하는 복잡한 알고리즘에 이르기까지 다양합니다. 성능과 단순성을 고려할 때 가장 널리 사용되는 로드 밸런싱 알고리즘 중 하나는 두 가지 최소 요청 로드 밸런싱의 힘으로 알려져 있습니다. (역자 주, 링크 제목은 ‘두 가지 무작위 선택의 힘’)

고정 세션 (Sticky sessions)

특정 애플리케이션에서는 같은 세션에 의한 요청이 같은 백엔드에 도달하는 것이 중요합니다. 이는 캐싱, 일시적인 복합 구성 상태 등과 관련이 있을 수 있습니다. 세션의 정의는 다양하며 HTTP 쿠키, 클라이언트 연결 속성 또는 기타 속성을 포함할 수 있습니다. 많은 L7 로드 밸런서는 고정 세션을 지원합니다. 한편, 세션의 고착도(stickiness)는 본질적으로 취약하기 때문에 세션에 의존하는 시스템을 설계할 때는 주의해야 합니다.

TLS 종료 (TLS termination)

TLS 주제와 에지 서비스 및 서비스와 서비스 간의 통신 보안 모두에서 TLS의 역할은 따로 포스트할 만큼의 가치가 있습니다. 이에 따라 많은 L7 로드 밸런서는 종료, 인증서 확인 및 핀닝, SNI를 사용한 인증서 서비스 등을 포함한 대량의 TLS 작업을 처리합니다.

관측성 (Observability)

말씀드린 대로, “관측성, 관측성, 관측성” 입니다. 네트워크는 본질적으로 신뢰할 수 없으며, 로드 밸런서는 종종 작업자가 문제를 해결할 수 있도록 무엇이 잘못되었는지 파악하는 데 도움이 되는 통계, 추적 및 로그를 내보낼 책임이 있습니다. 로드 밸런서는 관측성에 따라 크게 다릅니다. 가장 진보된 로드 밸런서는 숫자 통계, 분산 추적 및 사용자 지정 가능한 로깅을 포함하는 많은 출력을 제공합니다. 향상된 관측성은 거저 얻어지는 게 아니라고 지적하고 싶습니다. 왜냐하면, 로드 밸런서는 이를 생성하기 위한 추가적인 작업을 해야하기 때문입니다. 그러나 이들 데이터가 주는 이득은 상대적으로 성능이 약해서 생기는 결과보다 훨씬 큽니다.

보안 및 DoS 완화 (Security and DoS mitigation)

특히 에지 배포를 위한 토폴로지(아래 참조)에서는 로드 밸런서가 속도 제한, 인증 및 DoS 완화(예: IP 주소 태깅 및 판독, 타피팅(tarpitting) 등)를 비롯한 다양한 보안 기능을 구현하는 경우가 많습니다.

환경 설정 및 컨트롤 플레인 (Configuration and control plane)

로드 밸런서는 환경 설정을 해주어야 합니다. 대규모 배포에서 이는 상당한 작업이 될 수 있습니다. 일반적으로, 로드 밸런서를 구성하는 시스템은 “컨트롤 플레인(control plane)“으로 알려져 있으며 구현이 매우 다양합니다. 이 항목에 대한 자세한 내용은 데이터 플레인 대 제어 플레인 서비스 메쉬에 대한 저의 포스트를 참조하세요.

그 외 정말 다양한 기능들 (And a whole lot more)

이 섹션에서는 로드 밸런서가 제공하는 기능들의 유형을 수박 겉핥기 식으로 다루어 보았습니다. 아래의 L7 로드 밸런서 섹션에서 추가적인 논의를 확인할 수 있습니다.

로드 밸런서 토폴로지 종류

이제 로드 밸런서가 무엇인지, L4와 L7 로드 밸런서의 차이와 로드 밸런서 기능의 요약에 대해 개괄적으로 살펴보았으므로 로드 밸런서가 적용된 다양한 분산 시스템 토폴로지로 옮겨 가겠습니다. (다음 토폴로지 중 각 항목은 L4 및 L7 로드 밸런서에 모두 적용됩니다.)

미들 프록시

그림 4. 미들 프록시 로드 밸런싱 토폴로지

그림 4에 표시된 미들 프록시 토폴로지는 대부분의 독자들이 로드 밸런싱을 확보하는 가장 익숙한 방법입니다. 이 범주에는 Cisco, Juniper, F5 등의 하드웨어 장치, Amazon의 ALB 및 NLB와 Google의 클라우드 로드 밸런서 같은 클라우드 소프트웨어 솔루션 및 HAProxy, NGINX, 그리고 Envoy와 같은 순수 소프트웨어 자체 호스팅 솔루션이 포함됩니다. 미들 프록시 솔루션의 핵심은 사용자 단순성입니다. 일반적으로 사용자는 DNS를 통해 로드 밸런서에 연결되므로 다른 어떤 것도 걱정할 필요가 없습니다. 미들 프록시 솔루션의 핵심은 프록시(클러스터된 경우에도)가 단일 장애 지점이며 병목 현상도 증가한다는 점입니다. 미들 프록시도 운영을 어렵게 만드는 블랙박스입니다. 클라이언트에서 보여지는 문제가 있나요? 물리적 네트워크에서? 중간 프록시에서? 백엔드에서? 매우 알기 어려울 수 있습니다.

에지 프록시

그림 5. 에지 프록시 로드 밸런싱 토폴로지

그림 5에 표시된 에지 프록시 토폴로지는 실제로 인터넷을 통해 로드 밸런서에 액세스할 수 있는 미들 프록시 토폴로지의 변형일 뿐입니다. 이 시나리오에서는 일반적으로 로드 밸런서가 TLS 종료, 속도 제한, 인증 및 정교한 트래픽 라우팅과 같은 추가 “API 게이트웨이” 기능을 제공해야 합니다. 에지 프록시의 장단점은 미들 프록시와 같습니다. 일반적으로 인터넷을 지향하는 대규모 분산 시스템에서 전용 에지 프록시를 배포할 수 없다는 것이 주의사항입니다. 클라이언트는 일반적으로 서비스 소유자가 제어하지 않는 임의의 네트워크 라이브러리를 사용하여 DNS를 통해 시스템에 액세스해야 합니다(다음 섹션에서 설명하는 내장형 클라이언트 라이브러리 또는 사이드카 프록시 토폴로지는 클라이언트에서 직접 실행하기에는 실용적이지 않습니다). 추가적으로, 보안상의 이유로 모든 인터넷 트래픽이 시스템에 들어오는 수단으로 단일 게이트웨이를 사용하는 것이 좋습니다.

내장형 클라이언트 라이브러리

그림 6. 내장형 클라이언트 라이브러리를 통한 로드 밸런싱

미들 프록시 토폴로지에 내재된 단일 장애 지점과 확장 문제를 피하기 위해, 보다 정교한 인프라는 그림 6에서 보는 것처럼 라이브러리를 통해 로드 밸런서를 서비스에 직접 내장하는 쪽으로 이동했으며, 대부분의 라이브러리들은 다양한 기능을 지원하고 있습니다. Finagle, Eureka/Ribbon/Hystrix 및 gRPC(Stougy라고 하는 내부 Google 시스템을 기반으로 함) 라이브러리 기반 솔루션의 주요 장점은 로드 밸런서의 모든 기능을 각 클라이언트에 완전히 분산하여 단일 장애 지점(single point of failure)과 앞서 설명한 확장성 이슈를 제거한다는 것입니다. 라이브러리 기반 솔루션의 주된 단점은 라이브러리가 조직에서 사용하는 모든 언어로 구현되어야 한다는 점입니다. 분산형 아키텍처는 점점 더 “폴리글랏(다중 언어)“이 증가하고 있습니다. 이러한 환경에서는 여러 언어로 매우 정교한 네트워킹 라이브러리를 다시 구축하는 비용이 엄청나게 들 수 있습니다. 마지막으로, 대규모 서비스 아키텍처에 걸쳐 라이브러리 업그레이드를 배포하는 것은 매우 고통스러울 수 있으며, 다양한 버전의 라이브러리가 운영 환경에서 동시에 실행되게 함으로써 운영 인지 부하(operational cognitive load)가 증가할 가능성이 매우 높습니다.

모두 그렇다고 해도, 위에서 언급한 라이브러리들은 프로그래밍 언어의 확산을 제한하고 라이브러리 업그레이드 고통을 극복한 회사들에게는 성공적이었습니다.

사이드카 프록시

그림 7. 사이드카를 통한 로드 밸런싱

내장형 클라이언트 라이브러리 로드 밸런서 토폴로지의 변형은 그림 7에 표시된 사이드카 프록시 토폴로지입니다. 최근 몇 년간 이 토폴로지는 “서비스 메시"로 대중화되었습니다. 사이드카 프록시 이면의 아이디어는 다른 프로세스에 뛰어들어 약간의 지연 시간 페널티를 지불하는 비용으로 내장된 라이브러리 접근 방식의 모든 장점을 프로그래밍 언어를 락(제한)하지 않아도 얻을 수 있다는 것입니다. 이 글을 작성할 때, 가장 인기 있는 사이드카 프록시 로드 밸런서는 Envoy, NGINX, HAProxy 및 Linkerd입니다. 사이드카 프록시 접근 방식에 대한 보다 자세한 처리에 대해서는 Envoy를 소개하는 블로그 포스트와 또한 서비스 메시 데이터 플레인 대 컨트롤 플레인에 대한 저의 포스트를 참조하시길 바랍니다.

다른 로드 밸런서 토폴로지 장단점 요약

  • 미들 프록시 토폴로지는 일반적으로 사용하기 가장 쉬운 로드 밸런싱 토폴로지입니다. 단일 장애 지점, 스케일링 제한 및 블랙 박스 운영으로 인해 성능이 떨어집니다.
  • 에지 프록시 토폴로지는 미들 프록시와 유사하지만 전형적으로 피해갈 수는 없습니다.
  • 내장된 클라이언트 라이브러리 토폴로지는 최고의 성능과 확장성을 제공하지만 라이브러리를 모든 언어로 구현해야 하는 필요성뿐 아니라 모든 서비스에 걸쳐 라이브러리를 업그레이드해야 하는 필요성 때문에 어려움을 겪고 있습니다.
  • 사이드카 프록시 토폴로지는 내장된 클라이언트 라이브러리 토폴로지와 성능이 떨어지지는 않지만 그 어떤 제한으로부터 어려움을 겪지는 않습니다.

전반적으로, 저는 사이드카 프록시 토폴로지(서비스 메시)가 서비스 간의 통신을 위해 다른 모든 토폴로지를 점차 대체할 것이라고 생각합니다. 에지 프록시 토폴로지는 항상 트래픽이 서비스 메쉬로 들어가기 전에 필요합니다.

L4 로드 밸런싱의 기술 현황

L4 로드 밸런서는 여전히 관련이 있을까요?

이 포스트는 이미 L7 로드 밸런싱 장치가 현대적 프로토콜에 얼마나 대단한지에 대해 논의했으며, 더 자세한 L7 로드 밸런서 기능에 대해 아래에서 살펴볼 예정입니다. 이는 L4 로드 밸런서가 더 이상 관련이 없다는 뜻일까요? 아니요! 비록 L7 로드 밸런서가 궁극적으로 서비스 간의 통신을 위해 L4 로드 밸런서를 완전히 대체하겠지만, L4 로드 밸런서는 여전히 에지에서 매우 유효합니다. 왜냐하면 대부분의 대규모 분산 아키텍처는 2가지 티어의 L4/L7 로드 밸런싱를 사용하기 때문입니다. 에지 배치에서 L7 로드 밸런서보다 먼저 전용 L4 로드 밸런서를 배치하여 얻는 이득은 다음과 같습니다.

  • L7 로드 밸런서는 애플리케이션 트래픽의 훨씬 더 정교한 분석, 변환 및 라우팅을 수행하므로 최적화된 L4 로드 밸런서보다 원시 트래픽 로드(초당 패킷 및 초당 바이트로 측정)의 상대적으로 작은 부분을 처리할 수 있습니다. 이러한 사실은 일반적으로 L4 로드 밸런서가 더 나은 위치에서 특정 유형의 DoS 공격(예: SYN 플러딩, 일반 패킷 플러딩 공격 등)을 처리하도록 합니다.

  • L7 로드 밸런서는 L4 로드 밸런서보다 더 활발하게 개발되고, 더 자주 배치되며, 버그가 더 많습니다. L7 로드 밸런서를 배포하는 동안, 헬스 체킹하고 축출할 수 있는 L4 로드 밸런서를 전면에 배치하는 것은 일반적으로 BGP 및 ECMP를 사용하는 최신 L4 로드 밸런서에 사용되는 배치 메커니즘보다 훨씬 더 쉽습니다(아래 내용 참조). 그리고 마지막으로, L7 로드 밸런서는 복잡한 기능들로 인해 버그를 가질 가능성이 높기 때문에, 장애 및 이상 징후를 중심으로 라우팅할 수 있는 L4 로드 밸런서를 사용하면, 보다 안정적인 전체 시스템이 만들어집니다.

다음 섹션에서는 미들/에지 프록시 L4 로드 밸런서를 위한 여러가지 디자인에 대해 설명합니다. 이 디자인들은 일반적으로 클라이언트 라이브러리 및 사이드카 프록시 토폴로지에는 적용되지 않습니다.

TCP/UDP 종료 (termination) 로드 밸런서

그림 8. L4 종료 로드 밸런서

여전히 사용 중인 L4 로드 밸런서의 첫 번째 유형은 그림 8에 표시된 종료 로드 밸런서입니다. 위의 L4 로드 밸런싱 소개에서 본 것과 동일한 로드 밸런서입니다. 이러한 유형의 로드 밸런서에서는 클라이언트와 로드 밸런서 간에, 그리고 로드 밸런서와 백엔드 간에 서로 다른 두 개의 TCP 연결이 사용됩니다.

L4 종료 로드 밸런서는 다음 두 가지 이유로 계속 사용됩니다.

  • 이들은 상대적으로 구현이 쉽습니다.
  • 클라이언트와 아주 근접한 (낮은 지연 시간) 연결 종료는 상당한 성능 영향을 미칩니다. 특히, 종료 로드 밸런서를 손실된 네트워크(예: 셀룰러)를 사용하는 클라이언트 가까이에 배치할 수 있는 경우, 최종 위치로 전송 도중에 데이터가 안정적인 광섬유 전송 장치로 이동되기 전 재전송이 더 빨리 발생할 수 있습니다. 달리 말하면, 이러한 유형의 로드 밸런서는 원시 TCP 연결 종료의 POP(Point of Presence) 시나리오에서 사용될 수 있습니다.

TCP/UDP 패스스루 (passthrough) 로드 밸런서

그림 9. L4 패스스루 로드 밸런서

두 번째 유형의 L4 로드 밸런서는 그림 9에 표시된 패스스루 로드 밸런서입니다. 이 유형의 로드 밸런서에서는 TCP 연결이 로드 밸런서에 의해 종료되지 않습니다. 대신 연결 추적 및 NAT(네트워크 주소 변환)이 수행된 후 각 연결에 대한 패킷이 선택된 백엔드로 전달됩니다. 먼저 연결 추적과 NAT을 정의하겠습니다.

  • 연결 추적: 모든 활성 TCP 연결의 상태를 추적하는 프로세스입니다. 여기에는 핸드셰이크가 완료되었는지 여부, FIN이 수신되었는지 여부, 연결 유휴 상태가 얼마나 오래되었는지, 연결에 대해 어떤 백엔드를 선택했는지에 대한 데이터가 포함됩니다.

  • NAT: NAT은 연결 추적 데이터를 사용하여 패킷이 로드 밸런서를 통과할 때 패킷의 IP/포트 정보를 변경하는 프로세스입니다.

연결 추적과 NAT을 모두 사용하며 로드 밸런서는 클라이언트에서 백엔드로 원시 TCP 트래픽을 대부분 전달할 수 있습니다. 예를 들어, 클라이언트가 1.2.3.4:80을 가리키고 있고 선택한 백엔드는 10.0.2:9000에 있다고 가정해 보겠습니다. 클라이언트 TCP 패킷은 1.2.3.4:80에 로드 밸런서에 도착합니다. 그런 다음 로드 밸런서는 패킷의 대상 IP 및 포트를 10.0.2:9000으로 교환하고 패킷의 소스 IP를 로드 밸런서의 IP 주소로 교환합니다. 따라서 백엔드가 TCP 연결에서 응답하면 패킷은 연결 추적을 실행하는 로드 밸런서로 다시 돌아가고 NAT은 역방향으로 다시 수행될 수 있습니다.

이전 섹션에서 설명한 종료 로드 밸런서 대신 더 복잡한 이 유형의 로드 밸런서가 사용되는 이유는 무엇일까요? 몇 가지 이유는 다음과 같습니다:

  • 성능 및 리소스 사용: 패스스루 로드 밸런서는 TCP 연결을 종료하지 않으므로 TCP 연결 윈도우를 버퍼링할 필요가 없습니다. 연결당 저장된 상태의 양은 매우 작고 일반적으로 효율적인 해시 테이블 검색을 통해 액세스됩니다. 이 때문에 패스스루 로드 밸런서는 일반적으로 종료 로드 밸런서보다 훨씬 많은 수의 액티브 연결 및 초당 패킷(PPS)을 처리할 수 있습니다.

  • 백엔드가 사용자 지정 혼잡 제어(congestion control)를 할 수 있게 합니다.: TCP 정체 제어는 어느 인터넷 엔드포인트가 사용 가능한 대역폭과 버퍼를 초과하지 않도록 전송되는 데이터를 제어하는 메커니즘입니다. 패스스루 로드 밸런서는 TCP 연결을 종료하지 않으므로 혼잡 제어에 참여하지 않습니다. 이 사실은 백엔드가 애플리케이션 유즈 케이스에 따라 다양한 혼잡 제어 알고리즘을 사용할 수 있게 해준다는 것입니다. 또한 혼잡 제어 변경(예: 최근 BBR 롤아웃)에 대한 실험도 보다 쉽게 할 수 있습니다.

  • DSR(Direct Server Return) 및 클러스터 L4 로드 밸런싱의 기준을 구성합니다.: DSR 및 분산 컨시스턴트 해싱을 사용한 클러스터링과 같은 고급 L4 로드 밸런싱 기법에는 패스스루 로드 밸런싱이 필요합니다(다음 섹션에서 설명함).

DSR (direct server return)

그림 10. L4 DSR (irect server return)

그림 10은 DSR(Direct Server Return) 로드 밸런서를 보여주고 있습니다. DSR은 이전 섹션에서 설명한 패스스루 로드 밸런서를 기반으로 합니다. DSR은 수신(ingress)/요청(request) 패킷만 로드 밸런서를 횡단하는 최적화입니다. 송신(engress)/응답(response) 패킷은 로드 밸런서 주위를 다시 클라이언트로 이동합니다. DSR을 수행하는 것이 흥미로운 주된 이유는 많은 작업 부하에서 응답 트래픽이 요청 트래픽을 작아지게 하기 때문입니다. (예: 전형적인 HTTP 요청/응답 패턴). 10%의 트래픽이 요청 트래픽이고 90%의 트래픽이 응답 트래픽이라고 가정한다면, 용량의 1/10을 사용하는 로드 밸런서는 시스템의 요구를 충족할 수 있습니다. 역사적으로 로드 밸런서는 매우 비싸기 때문에 이러한 유형의 최적화는 시스템 비용과 신뢰성에 상당한 영향을 미칠 수 있습니다(적은 게 항상 좋습니다). DSR 로드 밸런싱 장치는 다음과 같이 패스스루 로드 밸런서의 개념을 확장합니다.

  • 로드 밸런서는 여전히 부분적인 연결 추적을 일반적으로 수행합니다. 응답 패킷은 로드 밸런서를 이동하지 않으므로 로드 밸런서는 전체 TCP 연결 상태를 인식하지 못합니다. 그러나 로드 밸런서는 클라이언트 패킷을 보고 다양한 유형의 유휴 시간 타임아웃을 사용하여 상태를 견고히 추론할 수 있습니다.
  • NAT 대신 로드 밸런서는 일반적으로 GRE(Generic Routing Encapsulation)를 사용하여 로드 밸런서에서 백엔드로 전송되는 IP 패킷을 캡슐화합니다. 따라서 백엔드가 캡슐화된 패킷을 받으면 패킷을 분해해서 클라이언트의 원래 IP 주소와 TCP 포트를 알 수 있습니다. 이렇게 하면 응답 패킷이 로드 밸런서를 통과하지 않고 백엔드가 클라이언트에 직접 응답할 수 있습니다.
  • DSR 로드 밸런서의 중요한 부분은 백엔드가 로드 밸런싱에 참여한다는 것입니다. 백엔드에 GRE 터널이 올바르게 구성되어 있어야 하며 네트워크 설정의 하위 레벨 세부 정보에 따라 자체 연결 추적, NAT 등이 필요할 수 있습니다.

패스스루 로드 밸런서와 DSR 로드 밸런서 디자인 모두 로드 밸런서와 백엔드에서 연결 추적을 설정할 수 있는 다양한 방법이 있습니다. 불행히도 이 주제는 이 포스트의 범위를 벗어납니다.

고가용성 페어를 통한 장애 허용

그림 11. HA 페어와 연결 추적을 통한 L4 장애 허용

지금까지 우리는 단일 L4 로드 밸런서의 디자인을 고려해 왔습니다. 패스스루 및 DSR 로드 밸런서에는 모두 로드 밸런서 자체에서 어느 정도의 연결 추적과 상태가 필요합니다. 로드 밸런서가 죽으면 어떻게 될까요? 로드 밸런서의 단일 인스턴스가 죽으면 로드 밸런서를 통과하는 모든 연결이 끊어집니다. 이는 애플리케이션에 따라 애플리케이션 성능에 상당한 영향을 미칠 수 있습니다.

역사적으로 L4 로드 밸런싱 장치는 일반적인 벤더(Cisco, Juniper, F5 등)에서 구입한 하드웨어 장치입니다. 이 장치들은 매우 비싸고 많은 양의 트래픽을 처리합니다. 단일 로드 밸런서 장애로 인해 모든 연결이 끊어져 어플리케이션 중단이 발생하는 것을 피하기 위해, 그림 11과 같이 로드 밸런서는 일반적으로 고가용성 페어로 배포되었습니다. 일반적인 HA 로드 밸런서 설정은 다음과 같이 디자인되었습니다.

  • 한 페어의 HA 에지 라우터는 몇 가지 가상 IP(VIP)를 서비스합니다. 이러한 에지 라우터는 BGP(Border Gateway Protocol)를 사용하여 VIP를 알립니다. 기본 에지 라우터는 백업보다 BGP 가중치가 높으므로 모든 트래픽을 처리할 수 있습니다. (BGP는 매우 복잡한 프로토콜이므로, 이 포스트의 목적을 위해, BGP를, 네트워크 장치가 다른 네트워크 장치에서 트래픽을 가져올 수 있다는 사실을 알리며 각 링크가 링크 트래픽의 우선 순위를 매길 수 있는 메커니즘으로 간주합니다.)

  • 마찬가지로, 기본 L4 로드 밸런싱 장치는 BGP 가중치가 백업보다 높은 BGP 가중치를 가진 에지 라우터로 자신을 알리므로 모든 트래픽을 안정적으로 처리합니다.

  • 기본 로드 밸런서는 백업에 교차 연결되고 모든 연결 추적 상태를 공유합니다. 따라서 기본 로드 밸런서가 죽으면 백업이 모든 액티브 연결을 처리할 수 있습니다.

  • 두 개의 에지 라우터와 두 개의 로드 밸런서는 모두 상호 연결되어 있습니다. 즉, 에지 라우터 중 하나 또는 로드 밸런서 중 하나가 죽거나 다른 이유로 인해 BGP 알림이 취소된 경우 백업이 모든 트래픽을 처리할 수 있습니다.

위의 설정은 많은 상위 트래픽 인터넷 어플리케이션이 오늘날까지도 서비스되고 있는 방식입니다. 그러나 위의 접근 방식에는 상당한 단점이 있습니다.

  • VIP 사용량을 고려하여 HA 로드 밸런서 페어 간에 VIP를 올바르게 분할해야 합니다. 단일 VIP가 단일 HA 페어의 용량을 초과하여 확장되는 경우 VIP를 여러 VIP로 분할해야 합니다.
  • 시스템의 리소스 사용이 열악합니다. 용량의 50%는 정상 상태에서 유휴 상태입니다. 역사적으로 하드웨어 로드 밸런싱 장치가 매우 비싸기다는 것을 감안할 때, 상당한 유휴 자본이 발생합니다.
  • 최신 분산 시스템 디자인은 액티브/백업보다 장애 허용(fault torlence)이 더 큰 것을 선호합니다. 예를 들어, 시스템이 여러 가지 동시 장애를 겪고 계속 작동할 수 있어야 합니다. HA 로드 밸런서 페어는 활성 및 백업 로드 밸런서가 동시에 죽을 경우, 전체 장애가 쉽게 발생할 수 있습니다.
  • 벤더의 독점적인 대형 하드웨어 장치는 매우 고가이며 벤더에 종속됩니다. 일반적으로 이러한 하드웨어 장치를 범용 컴퓨팅 서버를 사용하여 구축된 수평 확장 가능한 소프트웨어 솔루션으로 교체하는 것이 좋습니다.

분산 컨시스턴트 해싱이 있는 클러스터를 통한 장애 허용 및 확장

그림 12. 분산 컨시스턴트 해싱이 있는 클러스터를 통한 L4 장애 허용 및 확장

이전 섹션에서는 HA 페어를 통한 L4 로드 밸런서 장애 허용과 해당 디자인의 고유한 문제점을 소개했습니다. 2000년대 초반부터 중반에 이르러 대규모 인터넷 인프라는 그림 12와 같이 대규모 병렬 L4로드 밸런싱 시스템을 디자인하고 구축하기 시작했습니다. 이러한 시스템의 목표는 다음과 같습니다.

  • 이전 섹션에서 설명한 HA 페어 디자인의 단점을 모두 완화
  • 벤더의 독점 하드웨어 로드 밸런서에서 표준 컴퓨팅 서버 및 NIC를 사용하여 구축된 범용 소프트웨어 솔루션으로 이동

이 L4 로드 밸런서 설계를 클러스터링 및 분산 컨시스턴트 해싱을 통해 장애 허용 및 확장이라고 지칭하는 것이 가장 좋습니다. 이는 다음과 같이 작동합니다:

  • N 에지 라우터는 모든 애니캐스트 VIP를 동일한 BGP 가중치로 알립니다. 일반적으로 단일 플로우의 모든 패킷이 동일한 에지 라우터에 도달하도록 하기 위해 ECMP(동일한 비용의 다중 경로 라우팅, Equal-Cost Multi-Path Routing)이 사용됩니다. 플로우는 일반적으로 출발지 IP/포트 및 목적지 IP/포트 4개의 튜플입니다. (요컨대, ECMP는 컨시턴트 해싱을 사용하여 패킷을 동일한 가중치 네트워크 링크 집합으로 배포하는 방법입니다.) 에지 라우터 자체는 어떤 패킷이 어디에 도착할지 특별히 신경 쓰지는 않지만, 일반적으로 플로우의 모든 패킷이 성능을 저하시키는 잘못된 순서의 패킷을 피하도록 동일한 링크 집합을 통과하는 것이 좋습니다.
  • N L4 로드 밸런서 시스템은 모든 VIP를 에지 라우터에 동일한 BGP 가중치로 알립니다. ECMP를 다시 사용하면 에지 라우터는 일반적으로 플로우에 대해 동일한 로드 밸런서 시스템을 선택합니다.
  • 각 L4 로드 밸런서 시스템은 일반적으로 부분 연결 추적을 수행한 다음 컨시스턴트 해싱을 사용하여 플로우를 위한 백엔드를 선택합니다. GRE는 로드 밸런서에서 백엔드로 전송된 패킷을 캡슐화하는 데 사용됩니다.
  • 그런 다음 DSR을 사용하여 에지 라우터를 통해 백엔드에서 클라이언트로 직접 패킷을 전송합니다.
  • L4 로드 밸런서가 사용하는 실제 컨시스턴트 해싱 알고리즘은 활발한 리서치 영역입니다. 로드 평준화, 지연 시간 최소화, 백엔드 변경 시 운영 중단 최소화, 메모리 오버헤드 최소화와 관련된 장단점이 있습니다. 이 주제에 대한 전체적인 논의는 이 포스트의 범위를 벗어납니다.

위의 디자인이 HA 페어 접근 방식의 모든 단점을 어떻게 완화하는지 살펴보겠습니다.

  • 필요에 따라 새 에지 라우터 및 로드 밸런서 시스템을 추가할 수 있습니다. 컨시스턴트 해싱은 새 시스템을 추가할 때 영향을 받는 플로우의 수를 가능한 많이 줄이기 위해 모든 계층에서 사용됩니다.
  • 시스템의 리소스 사용량은 버스트 마진과 장애 허용을 충분히 유지하면서 원하는 만큼 높게 실행할 수 있습니다.
  • 에지 라우터와 로드 밸런서 모두는 이제 기존 하드웨어 로드 밸런싱에 비해 훨씬 적은 비용으로 일반 하드웨어를 사용하여 구축할 수 있습니다(자세한 내용은 아래 참조).

이 디자인에 대해 일반적으로 묻는 한 가지 질문은 “에지 라우터가 ECMP를 통해 백엔드와 바로 연결되지 않는 이유는 무엇인가요? 대체 왜 로드 밸런서가 필요한가요?“입니다. 그 이유는 주로 DoS 완화 및 백엔드 운영 편의성과 관련이 있습니다. 로드 밸런서가 없으면 각 백엔드가 BGP에 참여해야 하며 롤링 배포를 수행하는 데 훨씬 더 많은 시간이 걸립니다.

모든 최신 L4 로드 밸런싱 시스템은 이 디자인(또는 그 변형)으로 이동하고 있습니다. 가장 널리 알려진 두 가지 예는 Google의 Maglev와 Amazon의 NLB(Network Load Balancer)입니다. 현재 이 디자인을 구현한 OSS 로드 밸런서는 없지만 2018년 OSS 하나를 출시할 계획 중인 것으로 알고 있는 한 회사가 있습니다. 최신 L4 로드 밸런서는 네트워킹 영역의 OSS가 놓치고 있는 가장 중요한 부분이므로 이번 릴리스에 대해 저는 매우 기쁘게 생각합니다.

L7 로드 밸런싱의 기술 현황

기술 분야의 프록시 워즈는 현재 문자 그대로 프록시 워즈이다.

또는 “프록시들의 전쟁”.

Nginx 플러스, HAProxy, linkerd, Envoy 모두 문자 그대로 죽인다. (역자 주: 대박이다는 뜻?)

서비스형 프록시/서비스형 라우팅 SaaS 벤더들도 그 기준을 높였다. 아주 흥미로운 시대이다!

네, 확실히 그렇습니다. 지난 몇 년 동안 L7로드 밸런서/프록시 개발이 부활했습니다. 이 길은 분산 시스템에서 마이크로 서비스 아키텍처로가 지속적인 추진으로 아주 잘 다져지고 있습니다. 본질적으로 결함이 있는 네트워크는 더 자주 사용될 때 효율적으로 작동하기가 훨씬 더 어려워집니다. 또한 오토 스케일링, 컨테이너 스케줄러 등의 등장으로 정적 파일에 정적 IP를 프로비저닝하는 시대는 오래 전에 사라졌습니다. 시스템은 네트워크를 더 많이 활용하고 있을 뿐만 아니라 로드 밸런서에서 새로운 기능을 요구하면서 훨씬 더 동적으로 변하고 있습니다. 이 섹션에서는 최신 L7로드 밸런서에서 가장 많이 발전한 부분을 간략히 설명하겠습니다.

프로토콜 지원

최신 L7 로드 밸런서는 여러 가지 다른 프로토콜을 명시적으로 지원합니다. 로드 밸런서가 애플리케이션 트래픽에 대해 더 많은 지식을 가질수록 관측성 아웃풋(observability output), 고급 로드 밸런싱 및 라우팅 등과 관련하여 보다 정교한 작업을 수행할 수 있습니다. 예를 들어, 현재 Envoy는 HTTP/1, HTTP2, gRPC, Redis, MongoDB 및 DynamoDB에 대한 L7 프로토콜 구문 분석 및 라우팅을 명시적으로 지원합니다. 앞으로 MySQL과 Kafka를 포함해 더 많은 프로토콜이 추가될 것입니다.

동적 구성

위에서 설명한 것처럼, 분산형 시스템의 점진적 동적 특성은 동적 및 반응형 제어 시스템을 만드는 데 병렬 투자를 필요로 합니다. Istio는 그러한 시스템의 한 예입니다. 이 주제에 대한 자세한 내용은 서비스 메시 데이터 플레인 대 컨트롤 플레인에 있는 저의 포스트를 참조하세요.

고급 로드 밸런싱

L7 로드 밸런서는 일반적으로 타임 아웃, 재시도, 속도 제한, 서킷 브레이킹, 섀도우링, 버퍼링, 컨텐츠 기반 라우팅 등과 같은 고급 로드 밸런싱 기능이 기본적으로 내장되어 있습니다.

관측성

일반 로드 밸런서 기능에 대해 위의 섹션에서 설명한 것처럼 배포되고 있는 점진적 동적 시스템을 디버그하는 것이 점점 어려워지고 있습니다. 견고한 프로토콜별 관측성 아웃풋(observability output)은 현대의 L7 로드 밸런서가 제공하는 가장 중요한 기능일 수 있습니다. 이제 모든 L7 로드 밸런싱 솔루션에 숫자 통계, 분산 추적 및 사용자 지정 가능한 로깅이 사실상 필요합니다.

확장성

최신 L7 로드 밸런서 사용자는 사용자 지정 기능을 추가하기 위해 쉽게 로드 밸런서를 확장하고자 하는 경우가 많습니다. 이 작업은 로드 밸런서에 로드되는 플러그형 필터를 작성하여 수행할 수 있습니다. 대부분의 로드 밸런서는 일반적으로 Lua를 통해 스크립팅을 지원합니다.

장애 허용

L4 로드 밸런서 장애 허용에 대해 꽤 썼습니다. L7 로드 밸런서 장애 허용은 어떻습니까? 일반적으로 L7 로드 밸런서는 소모적이고 스테이트리스인 것으로 취급합니다. 범용 소프트웨어를 사용하면 L7 로드 밸런서를 쉽게 수평으로 확장할 수 있습니다. 또한 L7 로드 밸런서가 수행하는 처리 및 상태 추적은 L4 보다 훨씬 더 복잡합니다. L7 로드 밸런서의 HA 페어링을 구축하려는 시도는 기술적으로 가능하지만 중요한 비지니스가 될 것입니다.

전반적으로 L4 및 L7 로드 밸런싱 도메인 모두에서 업계는 HA 페어링을 떠나 컨시스턴트 해싱을 통해 수렴되는 수평 확장 가능한 시스템으로 이동하고 있습니다.

그 외의 것들

L7 로드 밸런서는 엄청난 속도로 진화하고 있습니다. Envoy가 제공하는 예를 보려면 Envoy의 아키텍처 개요를 참조하세요.

글로벌 로드 밸런싱 및 중앙형 컨트롤 플레인

그림 13. 글로벌 로드밸런싱

로드 밸런싱의 미래는 점점 더 개별 로드 밸런서를 범용 장치로 취급할 것입니다. 제 생각에는, 진정한 혁신과 상업적 기회는 모두 컨트롤 플레인 안에 있습니다. 그림 13은 글로벌 로드 밸런싱 시스템의 예를 보여 줍니다. 이 예에서는 다음과 같은 몇 가지 다른 작업이 수행됩니다.

  • 각 사이드카 프록시는 세 개의 다른 Zone(A, B, C)에서 백엔드와 통신합니다.
  • 그림처럼 트래픽의 90%가 Zone C로 전송되고 트래픽의 5%는 Zone A와 B로 전송됩니다.
  • 사이드카 프록시 및 백엔드는 모두 글로벌 로드 밸런서에 주기적인 상태를 보고합니다. 이를 통해 글로벌 로드 밸런서에서 대기 시간, 비용, 로드, 현재 장애 등을 고려하여 결정을 내릴 수 있습니다.
  • 글로벌 로드 밸런서는 주기적으로 각 사이드카 프록시를 현재 라우팅 정보로 구성합니다.

글로벌 로드 밸런서는 개별 로드 밸런서가 스스로 수행할 수 없는 정교한 작업을 점점 더 많이 수행할 수 있게 됩니다. 예를 들면 다음과 같습니다.

  • 자동으로 Zone 장애를 감지하고 라우팅합니다.
  • 글로벌 보안 및 라우팅 정책을 적용합니다.
  • 머신 러닝 및 신경망을 사용하여 DDoS 공격을 비롯한 트래픽 이상을 탐지하고 완화합니다.
  • 엔지니어가 전체 분산 시스템을 이해하고 작동할 수 있도록 중앙 집중식 UI 및 시각화를 제공합니다.

글로벌 로드 밸런싱을 가능하게 하려면 데이터 플레인으로 사용되는 로드 밸런서가 정교한 동적 구성 기능을 가지고 있어야 합니다. 이 항목에 대한 자세한 내용은 Envoy의 범용 데이터 플레인 API 및 서비스 메시 데이터 플레인 대 컨트롤 플레인에 있는 저의 포스트를 참조하세요.

하드웨어에서 소프트웨어로의 진화

지금까지 이 포스트는 하드웨어와 소프트웨어를 갼략히 언급했으며, 주로 과거 L4 로드 밸런서 HA 페어와 관련된 내용이었습니다. 이 분야의 업계 동향은 어떨까요?

소프트웨어의 8계층의 새로운 OSI 스택을 보았다.

내 생각에 이게 더 맞는 것 같다:

이 트윗은 유머러스한 과장이지만 여전히 트렌드를 잘 보여주고 있습니다.

  • 역사적으로, 라우터와 로드 밸런싱 장치는 매우 비싼 독점 하드웨어로 제공되어 왔습니다.
  • 점차적으로 대부분의 독점적인 L3/L4 네트워킹 장치가 IPVS, DPDK 및 fd.io와 같은 프레임워크를 기반으로 구축된 범용 서버 하드웨어, 범용 NIC 및 특수 소프트웨어 솔루션으로 대체되고 있습니다. 5K 미만의 비용이 드는 최신 데이터 센터 시스템은 Linux를 사용하여 매우 작은 패킷과 DPDK를 사용하여 작성된 커스텀 유저스페이스 애플리케이션으로 80Gbps NIC를 쉽게 포화시킬 수 있습니다. 한편, 놀랄만한 총 대역폭과 패킷 전송 속도로 ECMP 라우팅을 수행할 수 있는 저렴하고 기본적인 라우터/스위치 ASIC는 범용 라우터로 패키지화되고 있습니다.
  • NGINX, HAProxy, Envoy와 같은 정교한 L7 소프트웨어 로드 밸런싱 장치도 F5와 같은 벤더의 영역을 빠르게 이터레이션하며 잠식하고 있습니다. 따라서 L7 로드 밸런서도 범용 소프트웨어 솔루션을 향해 적극적으로 이동하고 있습니다.
  • 동시에, 업계 전반의 IaaS, CaaS 및 FaaS를 향한 움직임과 주요 클라우드 프로바이더에 의한 확산은 점점 더 소수의 엔지니어들만이 물리적 네트워크의 작동 방식을 이해하면 된다는 것을 의미합니다 (이들은 위의 “블랙매직"과 “더 이상 우리가 힘들게 알 필요가 없는 어떤 것"입니다).

결론 및 로드 밸런싱의 미래

요약하자면, 이 포스트의 주요 내용은 다음과 같습니다.

  • 로드 밸런서는 최신 분산 시스템의 핵심 구성 요소입니다.
  • 로드 밸런서에는 L4와 L7의 두 가지 일반 클래스가 있습니다.
  • L4 및 L7 로드 밸런서는 모두 최신 아키텍처에 적합합니다.
  • L4 로드 밸런서가 수평 확장 가능한 분산형 해싱 솔루션으로 이동하고 있습니다.
  • L7 로드 밸런서는 동적 마이크로서비스 아키텍처의 확산으로 인해 최근에 많은 투자를 받고 있습니다.
  • 글로벌 로드 밸런싱 그리고 컨트롤 플레인과 데이터 플레인의 분리는 로드 밸런싱의 미래이며 향후 혁신 및 상업적 기회의 대부분을 발견할 수 있는 곳입니다.s
  • 업계에서는 네트워킹 솔루션을 위한 범용 OSS 하드웨어와 소프트웨어를 적극적으로 추진하고 있습니다. 저는 F5와 같은 기존의 로드 밸런싱 벤더가 우선 OSS 소프트웨어와 클라우드 벤더에 의해 교체될 것이라고 생각합니다. Arista/Cumulus/etc와 같은 전통적인 라우터/스위치 벤더는 온프레미스 구축이라는 커다란 탈주로가 있지만, 결국 퍼블릭 클라우드 공급업체와 자체 개발한 물리적 네트워크에 의해 이전될 것입니다.

종합적으로 저는 지금이 컴퓨터 네트워킹에 있어 매력적인 시기라고 생각합니다! 대부분의 시스템에서 OSS와 소프트웨어를 개발하려는 움직임은 이터레이션 속도를 몇 배의 규모로 높이고 있습니다. 뿐만 아니라, 분산 시스템이 “서버리스(serverless)” 패러다임을 통해 역동적인 발전을 계속함에 따라, 기본 네트워크와 로드 밸런싱 시스템의 정교함도 그만큼 발전해야할 필요가 있습니다.

Yeongpil Yoon

Powered by Hugo & Kiss.