로드 밸런싱의 미래는 데이터에 달려 있습니다

클라우드 기반 애플리케이션이 빠른 속도로 구축되고 있습니다. 아직 앱 포트폴리오에서 압도적인 우위를 차지하지는 못했지만, 그 수는 늘어나고 있습니다. 컨테이너에 대한 관심은 통신 및 확장성을 위한 인프라에 대한 본질적인 종속성 때문에 클라우드 네이티브(마이크로서비스 기반) 아키텍처와 밀접한 관련이 있습니다.

일반적으로 마이크로서비스의 확장은 수평 복제를 통해 달성됩니다. 즉, 특정 서비스의 인스턴스가 더 필요하면 해당 서비스를 복제하여 로드 밸런서가 요청에 응답하기 위해 선택한 사용 가능한 풀에 추가하기만 하면 됩니다. 아주 쉽죠. 해당 마이크로서비스가 기능적 요소를 긴밀하게 나타낼 때 이 모델은 더욱 효과적으로 작동합니다.

문제의 로드 밸런서는 종종 컨테이너 오케스트레이터의 구성 요소이며 업계 표준인 라운드 로빈 TCP 기반 알고리즘을 기본적으로 사용합니다. 즉, 요청이 들어오면 로드 밸런서는 응답할 '다음 순서'의 리소스를 선택합니다.

이 방법은 종종 은행이나 DMV의 줄과 유사합니다. 하지만 전적으로 정확하지는 않습니다. 진정한 라운드 로빈 시나리오에서는 "다음으로 사용 가능한" 리소스로 이동하지 않습니다. 해당 리소스가 사용 중이더라도 "다음 대기자" 리소스로 이동됩니다. 아이러니하게도 DMV와 지역 은행의 분배 방법은 진정한 라운드 로빈 알고리즘보다 더 효율적입니다.

그렇죠?

이는 응용 프로그램에도 해당됩니다. 동일한 서비스(기능 수준에서도)는 동일한 요청 집합을 처리하기 때문에 복제될 수 있습니다. 하지만 이러한 요청은 데이터가 항상 동일하지는 않습니다. 그렇습니다, 데이터입니다. 동일한 기능적 요청 또는 API 호출은 제출되거나 요청되는 데이터에 따라 실행하는 데 걸리는 시간이 더 길거나 짧을 수 있습니다. 결국, 고객 레코드 1개를 검색하여 직렬화하는 데 걸리는 시간은 고객 레코드 10개나 100개를 검색하여 직렬화하는 데 걸리는 시간보다 짧습니다.

여기서 라운드 로빈 방식이 제대로 작동하지 않고 성능에 영향을 줄 수 있는 변동성이 발생합니다. 운영상의 공리 #2는 클라우드 네이티브 및 마이크로서비스 기반 아키텍처에도 여전히 적용됩니다. 즉, 부하가 증가하면 성능이 저하됩니다 .

라운드 로빈은 꿀오소리와 같습니다. 상당한 양의 데이터 세트를 응답으로 요청하여 리소스가 과부하되는 것은 상관하지 않습니다. 라운드 로빈 방식은 당신이 준비되었든 아니든 "다음이 당신입니다"라는 방식입니다. 이로 인해 점점 더 많은 부담을 주는 리소스에서 요청이 대기열에 쌓이는 사용자에게는 성능이 고르지 않게 나타날 수 있습니다.

성능이 걱정된다면(그래야 하겠지만) 최소 연결이나 가장 빠른 응답 시간 등 다른 표준 알고리즘을 사용하는 것이 더 나은 대안입니다. 기본적으로 알고리즘은 최적의 선택이 아닐 수 있는 리소스에 무작정 요청을 강요하는 대신 부하 및/또는 속도를 고려해야 합니다.

로드 밸런싱의 미래

일부 사람들은 TCP에서 HTTP로, 그리고 HTTP+로 스택을 올라가면 이 문제가 스스로 해결될 것이라고 생각할 수도 있습니다. 전혀 그렇지 않습니다. 분산 방법, 즉 부하 분산 알고리즘은 기반이 되는 계층에 관계없이 여전히 관련성이 있습니다. 라운드 로빈 방식은 아키텍처에 관심이 없고, 리소스에 관심이 있으며, 사용 가능한 풀을 기준으로 결정을 내립니다. 해당 풀이 단일 API 호출을 확장하기 위한 것인지 아니면 전체 모놀리스를 확장하기 위한 것인지는 알고리즘에 아무런 차이가 없습니다.

따라서 로드 밸런서가 쿼리를 실행하기 전에 "평균 이상"의 데이터가 생성되는 경우를 인식할 만큼 스마트하다면 좋을 것입니다. F5 WAF 와 같은 웹 애플리케이션 방화벽은 결과가 정상적이지 않을 때를 인식할 수 있지만 이는 응답에 대한 것이며 주로 애플리케이션 보안을 강화합니다. 우리에게 필요한 것은 로드 밸런서가 "매우 큰" 합법적인 응답을 예측할 수 있을 만큼 스마트해지는 것입니다.

로드 밸런서가 그런 종류의 식별력을 가지고 있다면, 이를 의사 결정에 반영하여 사용 가능한 리소스에 걸쳐 요청을 보다 균등하게 분산시킬 수 있습니다. 우리가 정말 원하는 것은 결정을 내리기 위해 엄격한 알고리즘을 강요받지 않는 것입니다. 로드 밸런서가 응답 시간, 예상 실행 시간, 반환된 데이터 크기, 각 리소스의 현재 부하와 같은 비즈니스 임계값과 기술적 특성을 기반으로 결정을 내릴 수 있다면 더 좋을 것입니다.

궁극적으로 이는 더 나은 가시성과 머신 러닝을 통해서만 실현될 수 있는 종류의 지능입니다. 로드 밸런서가 경험을 통해 어떤 쿼리가 다른 쿼리보다 시간이 더 많이 걸리는지 인식할 수 있다면, 이 지식을 적용하여 요청을 보다 효과적으로 분산시켜 일관되고 예측 가능한 응답 시간을 달성할 수 있습니다.

부하 분산은 사라지지 않을 것입니다. 이는 네트워크부터 애플리케이션까지 모든 것을 확장하기 위한 최고의 기술적 대응입니다. 하지만 보다 역동적이고 자율적이며 지능적이 되려면 나머지 인프라와 함께 발전해야 합니다.