앱 및 API 확장을 위한 앱 제공 패턴

부하 분산 알고리즘은 가용성을 보장하고 성능을 개선하기 위해 리소스 풀에 부하를 분산시키는 프로그래밍 방식입니다.

부하 분산 알고리즘은 구체적인 리소스를 선택하는 방법과 고려되는 변수를 지정합니다.

라운드 로빈 은 가장 간단한 알고리즘으로, 알려진 리소스 집합을 순차적으로 반복합니다. A, B, C라는 세 개의 리소스가 있는 경우 라운드 로빈은 첫 번째 요청을 A로, 두 번째 요청을 B로, 세 번째 요청을 C로 라우팅합니다. 그런 다음 선택 프로세스가 다시 시작됩니다.

최소 연결은 '부하가 증가하면 성능이 감소한다'는 두 번째 연산 공리(axiom)에 기반한 알고리즘입니다. 따라서 최소 연결 알고리즘 연결(부하)이 가장 적은 리소스를 선택합니다. 이 알고리즘에는 여러 변형이 있는데, 가장 주목할 만한 것은 리소스 간 용량 차이를 허용하는 가중치가 있는 최소 연결 입니다.

성능이 최우선일 때 가장 빠른 응답 시간이 사용됩니다. 로드 밸런서는 수동 또는 능동적으로 각 리소스의 응답 시간을 결정하고 모든 요청에 대해 가장 빠른 응답 시간을 선택합니다. 이 알고리즘은 마지막 마일이나 사용자 네트워크 상황에 영향을 미치지 않으므로 사용자 응답 시간을 보장하지 않습니다.

소스 IP는 소스(클라이언트) IP에 대한 간단한 해시 값을 사용하여 리소스를 선택하는 네트워크 부하 분산에서 남은 알고리즘입니다. 이 알고리즘은 주어진 소스 IP에 대해 항상 동일한 리소스를 선택합니다. 이 알고리즘은 모든 사용자가 단일 프록시/IP 주소에서 온 경우 동일한 리소스로 이동하게 되는 '메가 프록시' 문제의 영향을 받기 때문에 더 이상 선호되지 않습니다. 이러한 현상은 대상 리소스에 과도한 부담을 주어 성능이 저하되고 궁극적으로 실패로 이어질 수 있습니다.

부하 분산 알고리즘은 앱 전송 아키텍처의 중요한 부분이지만 전반적인 아키텍처적 접근 방식만큼 앱이나 디지털 서비스의 성능과 규모에 미치는 영향은 적습니다.

앱 제공은 앱, API, 디지털 서비스를 위한 확장 가능하고 성능이 뛰어난 아키텍처를 설계하는 분야입니다. 이 솔루션은 핵심 구성 요소로 부하 분산을 크게 사용하지만 레이어 7 라우팅과 같은 최신 기능을 통합하고 일반적인 아키텍처 패턴을 활용하여 성능을 최적화하고 리소스를 효율적으로 활용합니다.

우리는 로드 밸런싱(구현 세부 사항)과 아키텍처(설계 프로세스) 사이에 경계를 긋기 위해 앱 제공이라는 용어를 사용합니다.

규모는 비즈니스 결과에 대한 기술적 대응입니다. 즉, 고객 만족도 점수, 전환율, 수익 창출을 개선하기 위해 디지털 서비스를 구성하는 작업 부하 의 가용성과 성능을 유지해야 할 필요성이 있습니다. 마지막 부분은 특히 중요합니다. 우리 조사에 따르면 오늘날 대부분(58%)의 기업이 매출의 절반 이상을 디지털 서비스에서 창출하기 때문입니다.

예를 들어, 비즈니스 연속성(BC)을 위해 퍼블릭 클라우드를 사용하는 것도 고려해보세요. BC는 퍼블릭 클라우드의 가장 중요한 기본 사용 사례이며, 그 핵심은 글로벌 규모, 즉 글로벌 로드 밸런싱의 구현입니다. 장애 조치(Failover)는 앱 제공의 핵심 기능으로, 전체 사이트에 적용하면 요청을 한 위치에서 다른 위치로 빠르게 리디렉션할 수 있습니다.  기업의 디지털 존재감을 지속적으로 확보하는 것은 기술적 대응을 통해 가능해진 비즈니스 결과입니다.

이 질문에 답하는 것부터 앱 제공 아키텍처에 대한 기술 여정이 시작됩니다. 규모에는 수직(위)과 수평(바깥)의 두 가지 모델이 있습니다.

수직적 확장은 시스템에 더 많은 처리 능력을 추가하면 용량이 늘어난다는 원칙에 기초합니다. 이러한 확장 방법은 주로 자체 포함형 모노리식 애플리케이션과 시스템에 이점이 있습니다. 인프라를 제외하면 대부분의 조직은 더 이상 수직적 규모에 의존하지 않습니다. 수직적 규모를 위해서는 CPU나 RAM을 추가하거나 네트워크 용량을 확장하는 등 물리적 환경을 변경해야 하기 때문입니다. 가상화를 통해 수직적 확장이 훨씬 빨라졌지만, 특히 퍼블릭 클라우드 환경에서는 소프트웨어와 시스템을 마이그레이션해야 하는 요구 사항이 발생하면 방해가 될 수 있습니다. 이는 새로운 가상 머신으로 마이그레이션하는 경우에도 마찬가지입니다.

수평적 확장은 사용 가능한 총 리소스를 늘려서 더 많은 처리 능력을 추가하는 아키텍처적 접근 방식입니다. 이는 여러 애플리케이션, 서비스 또는 시스템 인스턴스에 처리 능력을 분산시켜 달성됩니다. 이는 리소스를 마이그레이션하는 대신 복제하는 데 의존하므로 오늘날 가장 일반적인 확장 방법입니다. 더욱이 수평적 확장은 수직적 확장 보다 더 다양한 아키텍처 옵션을 제공하므로 모든 애플리케이션과 API에 더 적합합니다.  

따라서 현대의 앱 제공 패턴이 수평적 규모의 원칙에 기반을 두고 있다는 것은 놀라운 일이 아닙니다.

단순히 수평적 규모를 선택하는 것으로 논의가 끝나는 것은 아닙니다.

결정이 내려지면(일반적으로 기본 결정입니다) 구현과 관련된 아키텍처 결정을 내릴 때 추가적인 고려 사항을 고려해야 합니다. 이러한 결정에 접근하는 가장 간단한 방법은 The Art of Scalability라는 책에서 설명한 대로 스케일 큐브 의 렌즈를 통해서입니다.

매우 간단하게 말하면, 스케일 큐브에는 x, y, z라는 세 개의 축이 있습니다. 각각은 로드 밸런싱 아키텍처 패턴에 매핑됩니다. 이러한 각 패턴은 다양한 유형의 애플리케이션과 API에 따른 성능 및 가용성과 관련된 특정 결과를 충족하는 데 적합합니다.

디지털 서비스는 성능과 리소스 소비를 동시에 최적화하기 위해 여러 패턴을 통합하는 아키텍처를 사용할 가능성이 높습니다. 이러한 접근 방식에는 시스템적 사고가 필요합니다. 모든 구성 요소, 구성 요소 간 상호작용, 사용자에서 앱으로 요청이 흐르는 방식 등을 고려해야 하기 때문입니다.

X축 패턴은 가장 기본적인 패턴입니다. 이는 수평적 복제를 기반으로 하며 대부분의 작업은 부하 분산 알고리즘을 통해 수행됩니다. 가장 간단한 패턴이며, 제가 POLB(Plain Old Load Balancing)라고 부르는 결과를 가져옵니다.

이렇게 부르는 이유는 애플리케이션 계층에서 요청 및 응답과 상호 작용하기 위해 최신 로드 밸런서의 고급 기능을 활용하지 않는 아키텍처의 단순성 때문입니다.

이 패턴은 기능 분해를 기반으로 하며, 전체 시스템이 아닌 기능에 따라 확장하기 위해 앱 제공의 애플리케이션 계층(계층 7) 기능을 활용합니다. y축 패턴은 레이어 7 라우팅이 앱 전송 아키텍처 툴박스에서 핵심 도구가 되는 첫 번째 패턴입니다.

일반적으로 y 및 z 기반 패턴은 7계층 라우팅을 활용하여 풀을 선택한 다음 부하 분산 알고리즘을 사용하여 특정 리소스를 선택합니다. 이는 7계층 라우팅이 사용되지 않는 기본 x 패턴과는 다릅니다.

Z축 패턴은 소셜 미디어와 인터넷의 폭발적인 성장에 따라 반드시 필요하게 되어 인기를 얻었습니다. 이는 본질적으로 추가 세분화가 적용된 Y축 확장 패턴으로, 일반적으로 사용자 이름이나 장치 식별자와 같은 특정 변수를 기반으로 합니다.

이 패턴은 데이터 분할에서 파생된 기술을 사용하여 아키텍처적 차별화를 허용합니다.