앱 및 API 로드 밸런싱: 알고리즘과 아키텍처의 비교

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

대체로 앱과 API를 확장하는 방식은 거의 동일합니다. 둘 다 일종의 로드 밸런서(일반적으로 프록시)가 필요하며, 리소스 풀 전체에 요청을 분산해야 합니다.

하지만 이러한 요청이 리소스 전반에 분산되는 방식에는 상당히 중요한 차이가 있습니다. 알고리즘의 경우에는 실제로 부하를 분산하는 반면, 아키텍처의 경우에는 부하를 특정 방향으로 전달합니다. 이는 학계에서나 따질 법한 현학적인 구분처럼 보일 수도 있습니다. 하지만 실제로 알고리즘과 아키텍처 중 무엇을 선택하느냐는 확장성과 성능에 지대한 영향을 미칩니다. 둘 다 부하 분산을 사용하는 주된 이유와 관련되어 있으므로, 이러한 구분은 중요합니다.

일반적인 로드 밸런싱

알고리즘 기반 로드 밸런싱은 간단히 로드 밸런싱이라고 하거나, 제가 즐겨 부르는 표현으로는 전통적인 로드 밸런싱이라고 할 수 있습니다. 이는 21세기가 시작되기 전부터 사용해 온 확장 방식입니다. 오래되었다고 해서 버려야 하는 것은 아닙니다. 오히려 그 반대입니다. 많은 상황에서 전통적인 로드 밸런싱은 확장성과 성능의 균형을 맞추는 데 가장 적합한 선택입니다.

전통적인 알고리즘 기반 부하 분산은 짐작할 수 있듯이 의사 결정 과정에 알고리즘을 사용합니다. 즉, 라운드 로빈, 최소 연결, 최단 응답 시간과 같은 분산 알고리즘 및 각각의 가중치 적용 방식으로 주어진 요청에 응답할 리소스를 선택합니다.

이는 매우 단순한 결정입니다. 벌꿀오소리처럼 알고리즘은 주어진 데이터를 바탕으로 실행하는 것 외에는 아무것도 신경 쓰지 않습니다. 사용 가능한 리소스가 5개라면 알고리즘에 따라 그중 하나가 선택됩니다. 그게 전부입니다.

알고리즘 기반 부하 분산은 예상할 수 있듯이 상당히 빠릅니다. 오늘날의 처리 성능으로는 적절한 알고리즘을 실행해 결정을 내리는 데 오랜 시간이 걸리지 않습니다. 라운드 로빈과 일부 가중 분산 알고리즘을 제외하면 알고리즘은 상태를 유지합니다. 즉, “현재 리소스 A, B, C에 각각 몇 개의 연결이 있는가?” 또는 “마지막 요청에 가장 빠르게 응답한 리소스는 무엇인가?”와 같은 변수를 추적해야 합니다. 부하 분산 장치는 이러한 정보를 계속 관리해야 합니다. 여러 개의 장기 연결이 필요한 기존 모놀리식 애플리케이션을 확장하는 환경에서는 이 정보가 상당히 방대해질 수 있으며, 이를 관리하는 데 더 많은 리소스가 필요할 수 있습니다.

기존의 일반적인 부하 분산 방식은 마이크로서비스를 확장할 때 특히 뛰어난 성능을 발휘합니다. 각 마이크로서비스는 하나의 기능만 담당하기 때문입니다(이상적인 아키텍처라면 그래야 합니다). 이러한 서비스는 일반적으로 용량과 성능이 비슷하므로 기본 알고리즘(대개 라운드 로빈)을 사용하면 손쉽게 확장할 수 있습니다. 하나의 사용자 요청을 처리하기 위해 여러 서비스를 호출해야 할 수 있는 마이크로서비스 아키텍처의 특성상 빠른 의사 결정은 필수입니다. 따라서 이러한 환경에는 기본적인 알고리즘 기반 부하 분산이 적합합니다.

기본적인 경험 법칙은 다음과 같습니다. 기능이 제한적이고 성능 면에서 대체로 동등한 단순한 서비스를 확장하는 경우에는 일반적인 로드 밸런싱만으로도 충분합니다. 이는 컨테이너 환경 내부에서 볼 수 있는 방식이며, 기본 확장 기능의 상당 부분이 단순한 알고리즘을 기반으로 하는 이유이기도 합니다.

그 밖의 애플리케이션과 상황에서는 아키텍처 기반의 부하 분산을 고려해야 합니다.

HTTP 부하 분산

아키텍처 기반 로드 밸런싱은 로드 밸런서를 사용하여 확장 대상 애플리케이션의 아키텍처에 맞게 요청을 세분화하는 기술입니다(그렇습니다. 과학이 아니라 기술입니다). 아키텍처 기반 로드 밸런싱은 트래픽을 분산하기보다는 적절한 대상으로 전달하는 데 더 중점을 둡니다. 이는 계층 7(일반적으로 HTTP)을 활용하여 각 요청을 어디로 보내야 할지 결정하기 때문이며, 그래서 여러 난해한 네트워크 중심 용어 중에서도 이를 흔히 HTTP 로드 밸런싱이라고 부릅니다.

API로 공개되고 마이크로서비스를 기반으로 구축되는 환경에서는 요청을 적절한 대상으로 전달하는 기능이 갈수록 중요해지고 있습니다. 버전에 따라 API 요청을 전달하고, 호스트 이름이나 URI 경로를 사용해 특정 마이크로서비스로 요청을 보내거나, 애플리케이션을 기능별로 분해할 수 있어야 하기 때문입니다.

대부분의 조직은 사용하기 쉽고 일관된 API를 제공하고자 합니다. 시민 개발자가 API를 활용해 새로운 애플리케이션을 만들도록 장려하거나 파트너가 손쉽게 연결하고 통합할 수 있도록 하려면, 일관되고 간단한 API가 널리 사용되도록 하는 데 필수적입니다.

하지만 실제로 API는 복잡한 경우가 많습니다. API는 여러 서비스(주로 마이크로서비스)를 기반으로 하며, 여러 위치에 분산되어 있을 수도 있습니다. 단일 서비스에만 국한되는 경우는 드뭅니다. 더 복잡한 점은 이전 세대의 앱보다 업데이트가 더 자주 이루어지고, 이전 버전과의 호환성도 안정적으로 보장되지 않는다는 것입니다. 또한 모바일 앱은 기존 리소스와 새로운 리소스를 모두 사용할 수 있습니다. 예를 들어 웹 앱과 이미지를 공유하고 다른 모든 앱과 동일한 API를 사용하기도 합니다.

이러한 ‘앱’과 API를 확장하려면 부하 분산에 아키텍처적 접근 방식이 필요합니다. 트래픽을 분산하기 전에 먼저 전달할 방향을 지정해야 합니다. 즉, URL 디스패치, 데이터 파티셔닝, 기능 분해와 같은 아키텍처 패턴을 구현하려면 레이어 7(HTTP)을 지원하는 부하 분산 장치를 사용해야 합니다. 이러한 패턴은 각각 본질적으로 아키텍처와 관련되어 있으므로 기존 앱보다 애플리케이션 또는 API 설계와의 연계성이 더 높아야 합니다.

앱을 확장하면서 효율성과 민첩성의 균형을 유지하고 API를 지원하려면 HTTP 부하 분산이 점점 더 중요해지고 있습니다.

확장성을 위해서는 둘 다 필요합니다

현실에서는 한 가지 유형의 확장만 이루어지는 경우를 거의 찾아볼 수 없습니다. 조직이 수십 년에 걸친 개발 역사와 다양한 애플리케이션 아키텍처, 플랫폼 및 기술을 아우르는 탄탄한 애플리케이션 포트폴리오를 점점 더 많이 제공하고 있기 때문입니다. 오직 ‘현대적인’ 애플리케이션만 지원한다고 자신 있게 말할 수 있는 조직은 거의 없습니다(메인프레임에서 실행되지 않는 모든 것을 현대적이라고 정의하지 않는 한 말입니다).

따라서 다양한 애플리케이션을 확장하기 위해 알고리즘 기반 로드 밸런싱과 아키텍처 기반 로드 밸런싱을 모두 접하고 사용하게 될 가능성이 높습니다. 그렇기 때문에 두 방식의 차이를 이해하는 것이 중요합니다. 더 적합한 방식이 있는데도 다른 방식을 사용하면 성능 저하나 서비스 중단이 발생할 수 있으며, 이는 사용자와 비즈니스는 물론 여러분에게도 결코 바람직하지 않습니다.

최신 애플리케이션을 확장하기 위해 이 두 가지 접근 방식을 결합하는 사례가 점점 더 많아질 것입니다. 때로는 논리적 요소(API)와 물리적 요소(API 뒤에서 실제로 작동하는 서비스)를 모두 확장하도록 설계된 하나의 서비스로 통합되기도 합니다. 애플리케이션 전송 컨트롤러(ADC)는 두 가지 작업을 모두 민첩하게 수행할 수 있으므로, 일반적으로 이러한 결합형 접근 방식을 구현하는 플랫폼으로 사용됩니다.

경우에 따라 이러한 작업은 서로 다른 두 시스템에서 수행됩니다. 예를 들어 컨테이너화된 환경에서는 인그레스 컨트롤러가 아키텍처 수준의 부하 분산을 담당하는 반면, 내부 네이티브 서비스는 일반적으로 알고리즘 기반 부하 분산을 통해 확장을 담당합니다.

구현 및 배포 세부 사항과 관계없이, 알고리즘 기반 방식과 아키텍처 기반 방식의 부하 분산은 모두 앱과 API를 확장하는 데 중요한 역할을 합니다. 각각의 강점을 최대한 활용하려면 애플리케이션 아키텍처에 적합한 부하 분산 방식을 선택해야 합니다.

계속 확장하세요.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물