로드 밸런싱 앱 및 API: 알고리즘 대 아키텍처

대부분의 경우 앱과 API 확장은 사실상 똑같은 것입니다. 둘 다 일종의 로드 밸런서(일반적으로 프록시)가 필요하며 리소스 풀에 요청을 분산해야 합니다.

하지만 해당 요청이 리소스 전반에 분산되는 방식 에는 상당한 차이가 있습니다. 알고리즘의 경우 부하를 분산시키는 것이고, 아키텍처의 경우 부하를 지시하는 것입니다. 이건 학계에 맡겨두는 게 가장 좋을 듯한 교조적인 구별처럼 들릴지도 모릅니다. 사실 알고리즘과 아키텍처 중 무엇을 선택하느냐에 따라 규모와 성능에 큰 영향을 미칩니다. 둘 다 로드 밸런싱을 사용하는 이유이므로 이 구분은 중요합니다.

평범한 오래된 로드 밸런싱

알고리즘 기반 부하 분산은 단순히 부하 분산이라고도 하며, 저는 이를 일반 부하 분산 이라고 부르고 싶습니다. 이것은 우리가 20세기 이전부터 사용해 온 규모 측정 방법입니다. 오래되었다고 해서 버려야 한다는 뜻은 아니다. 오히려 그 반대다. 많은 경우, 규모와 성능의 균형을 맞추기 위해서는 기존의 로드 밸런싱이 가장 좋은 선택입니다.

기존의 알고리즘적 부하 분산은, 추측할 수 있듯이, 의사 결정 프로세스에 알고리즘을 사용합니다. 즉, 라운드 로빈, 최소 연결, 가장 빠른 응답과 같은 분산 알고리즘과 이에 상응하는 가중치가 적용된 알고리즘이 주어진 요청에 응답할 리소스를 선택하는 데 사용됩니다.

이는 간단한 결정입니다. 꿀오소리처럼 알고리즘은 사용 가능한 데이터에 따라 실행하는 것 외에는 다른 것에 관심이 없습니다. 사용 가능한 리소스가 5개 있는 경우 알고리즘에 따라 그 5개 중 하나가 선택됩니다. 기간.

알고리즘 기반의 부하 분산은 상상할 수 있듯이 매우 빠릅니다. 오늘날의 처리 능력을 사용하면 적절한 알고리즘을 실행하고 결정을 내리는 데 오랜 시간이 걸리지 않습니다. 라운드 로빈과 특정 가중 분포 알고리즘을 제외하고 알고리즘은 상태가 있습니다. 즉, "지금 리소스 A, B, C에 몇 개의 연결이 있는가?" 또는 "마지막 요청에 가장 빨리 응답한 리소스는 무엇인가?"와 같은 변수를 추적해야 한다는 의미입니다. 로드 밸런서는 이 정보를 추적해야 합니다. 이러한 정보는 상당히 커질 수 있으며 여러 개의 장기 연결이 필요한 기존의 모놀리식 애플리케이션을 확장하는 환경에서는 관리하는 데 더 많은 리소스가 필요할 수 있습니다.

기존의 로드 밸런싱이 탁월한 점은 마이크로서비스의 확장입니다. 그 이유는 각 마이크로서비스가 하나의 기능을 갖고 있기 때문입니다(이상적인 아키텍처에서는 하나의 기능을 갖고 있어야 함). 이러한 서비스의 확장은 기본 알고리즘(일반적으로 라운드 로빈)을 사용하면 쉽게 달성할 수 있습니다. 이는 일반적으로 용량과 성능이 동일하기 때문입니다. 단일 사용자 요청을 이행하기 위해 여러 서비스 호출이 필요할 수 있는 마이크로서비스 아키텍처의 특성으로 인해 빠른 의사 결정이 필수입니다. 그러므로 이러한 환경에는 기본 알고리즘 기반의 부하 분산이 좋은 선택입니다.

기본적인 경험 법칙은 다음과 같습니다. 성능 면에서 일반적으로 동일한 제한된 기능 세트를 갖는 간단한 서비스를 확장하는 경우, 기존의 로드 밸런싱으로 충분합니다. 컨테이너 환경 내부에서 볼 수 있는 내용은 다음과 같으며, 대부분의 기본 확장 기능이 간단한 알고리즘을 기반으로 하는 이유입니다.  

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

HTTP 부하 분산

아키텍처 기반 로드 밸런싱은 로드 밸런서를 사용하여 요청을 확장하는 애플리케이션의 아키텍처와 일치하는 방식으로 슬라이스하고 다이싱하는 기술(예, 과학이 아닌 기술)입니다. 아키텍처 기반 로드 밸런싱은 트래픽을 분산하는 것보다 트래픽을 유도하는 데 더 중점을 둡니다. 이는 요청이 어디로 가야 하는지 결정하기 위해 7계층(일반적으로 HTTP)을 활용하기 때문이며, 우리가 이를 HTTP 부하 분산(다른 난해하고 네트워킹 중심의 용어와 함께)이라고 부르는 이유입니다. 

API가 공개되고 마이크로서비스 기반으로 구축된 세상에서는 요청을 지시하는 능력이 점점 더 중요해지고 있습니다. 버전에 따라 API 요청을 전달하고, 호스트 이름이나 URI 경로를 사용하여 특정 마이크로서비스에 요청을 전송하거나, 애플리케이션을 기능 분해해야 하기 때문입니다.

대부분의 조직에서는 사용하기 쉬운 일관된 API를 공개하고 싶어합니다. 시민 개발자가 API를 사용하는 새로운 애플리케이션을 만들도록 장려하든 파트너가 쉽게 연결하고 통합할 수 있도록 하든 일관되고 간단한 API는 채택을 보장하는 데 필수적입니다.

하지만 API는 현실적으로 종종 지저분합니다. 이러한 플랫폼은 여러 서비스(종종 마이크로서비스)로 지원되며 여러 위치에 분산될 수 있습니다. 그들은 단일 서비스에만 국한되는 경우가 거의 없습니다. 복잡한 문제는 이전 세대 앱보다 더 자주 업데이트되고, 안정적으로 이전 버전과의 호환성이 보장되지 않는다는 것입니다. 또한 모바일 앱은 기존 리소스와 새로운 리소스를 모두 활용할 수 있습니다. 즉, 웹 앱과 이미지를 공유하고 다른 모든 사람과 동일한 API를 사용할 수 있습니다.

이러한 "앱"과 API를 확장하려면 부하 분산에 대한 아키텍처적 접근 방식이 필요합니다. 트래픽을 분산하기 전에 먼저 트래픽 을 지시해야 합니다. 즉, URL 전송, 데이터 분할, 기능 분해와 같은 아키텍처 패턴을 구현하기 위해 계층 7(HTTP)을 지원하는 로드 밸런서를 사용해야 합니다. 이러한 각 패턴은 본질적으로 아키텍처적이므로 기존 앱보다 애플리케이션이나 API 디자인에 대한 더 큰 친화성이 필요합니다.

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

확장성에는 두 가지가 모두 필요합니다.

실제 세계에서 한 가지 유형의 스케일만 보는 일은 거의 없습니다. 그 이유는 조직이 점점 더 수십 년에 걸친 개발, 앱 아키텍처, 플랫폼, 기술을 아우르는 강력한 애플리케이션 세트를 제공하기 때문입니다. "최신" 애플리케이션만 지원한다고 자랑할 수 있는 조직은 거의 없습니다(최신 애플리케이션이 메인프레임에서 실행되지 않는 모든 것을 포함하지 않는 한).

따라서 다양한 애플리케이션을 확장하기 위해 알고리즘적 부하 분산과 아키텍처적 부하 분산을 모두 보고 사용할 가능성이 높습니다. 그렇기 때문에 차이점을 이해하는 것이 중요합니다. 둘 중 하나를 더 적합한 경우에 사용하면 성능이 저하되거나 중단이 발생할 수 있으며, 이는 사용자, 비즈니스 또는 여러분 모두에게 좋지 않습니다. 

현대적 애플리케이션을 확장하기 위해 두 가지 접근 방식이 결합되는 모습을 점점 더 많이 볼 수 있을 것입니다. 때로는 두 가지가 논리적(API)과 물리적(API 뒤에 있는 실제 서비스)을 확장하도록 설계된 단일 서비스로 존재하기도 합니다. 애플리케이션 전송 컨트롤러(ADC)는 일반적으로 두 가지 접근 방식을 모두 구현하는 플랫폼으로, 두 가지를 동일한 속도로 수행할 수 있기 때문입니다.

때로는 두 개의 서로 다른 시스템에 의해 수행됩니다. 예를 들어, 컨테이너화된 환경에서 인그레스 컨트롤러는 아키텍처적 로드 밸런싱을 담당하는 반면, 내부의 네이티브 서비스는 일반적으로 알고리즘적 로드 밸런싱을 사용하여 확장을 담당합니다.

구현 및 배포 세부 사항과 상관없이 실제로는 로드 밸런싱에 대한 알고리즘 기반 접근 방식과 아키텍처 기반 접근 방식이 모두 앱과 API 확장에 중요한 역할을 합니다. 애플리케이션 아키텍처에 맞춰 로드 밸런싱을 조정하여 장점을 극대화하는 것이 핵심입니다.

확장하세요.