확장성을 위한 5가지 핵심 패턴

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

애플리케이션이 곧 화폐인 경제에서 가용성은 매우 중요한 문제입니다. 응답하지 않는 앱은 즉시 삭제되고, 부정적인 Yelp 리뷰처럼 빠르고 신랄하게 인터넷에서 혹평을 받습니다.

인터넷이 처음 등장한 이래로 조직들은 애플리케이션(예전에는 웹사이트)을 연중무휴 24시간 이용할 수 있도록 노력해 왔습니다. 인터넷은 잠들지도, 휴가를 떠나지도, 아프다고 결근하지도 않기 때문입니다.

이러한 필요(정확히 말하면 요구 사항)를 충족하기 위해 확장성은 가용성을 보장하는 최초의 애플리케이션 서비스 중 하나로 부상했습니다. 가용성 요구를 충족하는 애플리케이션 서비스 가운데 가장 널리 알려져 있고 이해도도 높은 것은 로드 밸런싱입니다.

하지만 로드 밸런싱에는 다양한 형태가 있으며, 이 핵심 기술을 활용해 구현할 수 있는 확장성 패턴도 많습니다. 오늘은 애플리케이션과 인터넷이 연중무휴 24시간 온라인 상태와 가용성을 유지하도록 하는, 현재 널리 사용되는 5가지 주요 확장성 패턴을 소개하겠습니다.

글로벌 서버 부하 분산(GSLB)

GSLB라는 명칭은 매우 부적절합니다. 실제로는 서버 부하 분산이 아니라 사이트 가용성을 위한 것이었습니다. 오늘날에는 그 의미가 앱 가용성까지 확장되고 있습니다.

GSLB는 한 데이터 센터(클라우드 또는 기존 데이터 센터)가 응답하지 않을 경우 다른 데이터 센터를 찾을 수 있도록 보장하는 수단입니다. GSLB는 도메인 또는 호스트 수준에서 적용할 수 있습니다. 따라서 example.com을 여러 위치 간에 전환하는 것은 물론 api.example.com.도 전환할 수 있습니다.

가장 기본적인 형태에서 GSLB는 단순한 DNS 기반 부하 분산을 사용합니다. 즉, 도메인이나 호스트에 연결된 IP 주소 목록을 보유하고 있다가 첫 번째 주소를 사용할 수 없으면 요청을 목록의 두 번째 주소로 전달하며, 필요에 따라 세 번째, 네 번째 주소 등으로 계속 전달합니다.

이 프로세스는 두 단계로 이루어집니다:

1. 글로벌 로드 밸런서에 적절한 IP 주소를 요청합니다. 이는 GSLB에 항상 따르는 단점입니다. 최근 15분 이내 또는 cheese.com IP 주소의 현재 TTL에 해당하는 시간 이내에 요청한 적이 있다면, 마지막으로 받은 응답을 다시 받게 됩니다. 따라서 그사이에 해당 사이트가 다운되었다면 연결할 수 없습니다.
2. GSLB 조회에서 반환된 사이트의 IP 주소로 요청을 보냅니다. 이 주소는 대개 자체 알고리즘과 의사 결정 프로세스를 사용하여 요청을 적절한 리소스로 전달하는 로컬 로드 밸런서로 연결됩니다.

일반적으로 1단계의 결정에는 지능적인 판단이 개입되지 않으며, 특정 사이트의 응답 여부만을 기준으로 엄격하게 이루어집니다. 하지만 이러한 방식으로 클라우드, 호스팅 제공업체, 온프레미스 등 여러 위치를 활용하여 가용성을 보장할 수 있습니다. 지리적으로 분산된 지역의 위치를 전략적으로 선택하면 자연재해나 인터넷 장애의 영향을 피할 수 있습니다.

하지만 이는 DR(재해 복구) 또는 BC(비즈니스 연속성) 시나리오에 더 가깝습니다. 이 밖에도 지리적 위치 및 애플리케이션 성능과 같은 더욱 지능적인 GSLB 애플리케이션 서비스를 활용하는 시나리오가 있습니다. 예를 들어 사이트 A의 앱 성능이 저하되면 문제가 해결될 때까지 방문자를 사이트 B로 보낼 수 있습니다. 또는 성능 향상을 위해 사용자를 지리적으로 가장 가까운 위치로 안내할 수도 있습니다. 빛의 속도에는 한계가 있으며, 거리는 앱 성능에 영향을 미치기 때문입니다.

의사 결정 방식과 관계없이 기본 패턴은 동일합니다. GLSB는 사용 가능한 사이트 중 하나의 IP 주소를 반환하여 물리적으로 분리된 여러 사이트에 요청을 분산합니다. API든 앱이든 GSLB는 최상위 수준의 가용성 보장 패턴입니다.

일반적인 로드 밸런싱(POLB)

연결 기반 가용성

Plain Old Load Balancing(POLB)은 표준 TCP 기반 로드 밸런싱을 설명할 때 제가 즐겨 사용하는 용어입니다. 이 패턴에서는 앱을 복제하고 클라이언트(사용자, 기기)와 앱 간에 연결이 이루어지도록 하는 것만으로 가용성을 확보할 수 있습니다.

로드 밸런서(원한다면 프록시라고 불러도 됩니다)는 연결 요청을 수신하고, 사용 가능한 앱 인스턴스를 선택한 다음 연결을 전달합니다. 이것이 로드 밸런서가 능동적으로 관여하는 마지막 단계입니다. 두 동료가 만날 수 있도록 주선하는 ‘소개 이메일’과 비슷합니다. 처음에는 대화에 적극적으로 참여하지만, 이후에는 참조(cc)로 옮겨지고 대체로 더 이상 관여하지 않습니다.

요청을 어디로 보낼지 결정하는 데는 알고리즘만 관여하므로 저는 POLB라는 용어를 사용합니다. 안타깝게도 요청 분산에 어떤 알고리즘을 사용하느냐에 따라 많은 문제가 발생할 수 있습니다. 예를 들어 라운드 로빈은 용량이나 성능을 고려하지 않습니다. 단순히 ‘다음 앱’을 선택해 요청을 보낼 뿐입니다. ‘최소 연결’ 방식을 선택하면 특정 리소스에 부하가 집중되어 성능이 빠르게 저하될 수 있으며, 다른 리소스가 더 빠를 수도 있습니다. 따라서 알고리즘 선택은 가용성을 유지하는 데 매우 중요한 요소가 됩니다.

POLB는 컨테이너 환경과 많은 클라우드 네이티브 부하 분산 서비스에서 기본적으로 사용되는 부하 분산 방식입니다.

지속성

고정 세션 및 SSL

3계층 애플리케이션의 현실 중 하나는 일반적으로 상태를 유지한다는 점입니다. 즉, 애플리케이션 운영에 필수적인 정보를 요청과 응답 사이에 저장합니다. 장바구니, 자격 증명, 상태, 마지막으로 방문한 페이지, 현재 진행 중인 절차의 단계와 같은 정보는 흔히 ‘세션’의 일부로 저장됩니다. 문제는 3계층 프레임워크를 사용해 개발된 많은 앱이 이 세션을 데이터베이스가 아닌 애플리케이션 서버나 웹 서버에 저장하게 되었다는 것입니다. 따라서 일단 특정 서버에 연결되면 모든 정보를 계속 사용할 수 있도록 해당 서버로 계속 요청을 보내야 했습니다.

로드 밸런서는 다양한 방식으로 지속성을 구현했으며, 그중 가장 널리 사용된 방식은 쿠키 기반이었습니다. 세션 ID를 쿠키에 저장한 다음, 로드 밸런서가 이를 사용해 요청을 올바른 서버로 전달함으로써 사실상 알고리즘 기반의 선택 과정을 우회했습니다.

쇼핑객이 안심할 수 있도록 SSL/TLS 사용이 필수 요건이 되자 동일한 문제가 다시 발생했습니다. SSL/TLS는 클라이언트와 특정 애플리케이션 서버 간에 보안 세션을 설정합니다. 통신 양측이 해당 연결을 통해 교환되는 데이터를 복호화하고 사용할 수 있도록 하려면, 로드 밸런서가 클라이언트 요청을 세션이 시작된 동일한 서버로 전송할 수 있어야 했습니다. 로드 밸런서는 세션 기반 지속성을 구현하는 것과 동일한 기법을 사용하여 SSL/TLS 기반 지속성을 지원할 수 있었습니다.

사용되는 지속성의 구체적인 유형과 관계없이 패턴은 동일합니다. 세션이 이미 설정되었음을 나타내는 지표가 있으면 로드 밸런서는 기존 연결을 유지하고 사용자 세션이 지속되는 동안 해당 연결이 계속 유지되도록 합니다. 그러한 지표가 없으면 로드 밸런서는 구성과 알고리즘에 따라 리소스를 선택하고 연결을 설정합니다.

이는 부하 분산 알고리즘을 선택할 때 용량 계획에 영향을 미칩니다. 최소 연결 방식은 다른 리소스가 유휴 상태인 동안 특정 리소스 하나에 진행 중인 세션이 몰려 과부하가 발생하지 않도록 하므로 이 시나리오에 적합합니다. 다른 알고리즘을 사용하면 하나의 리소스가 동시에 많은 사용자 세션을 유지하게 될 가능성이 있으며, 이는 해당 서버로 연결된 모든 사용자의 성능에 부정적인 영향을 미칩니다.

호스트 기반 부하 분산

가상 서버

호스트 기반 부하 분산은 가장 일반적이며 거의 모든 환경에서 지원되는 확장성 패턴 중 하나입니다. 모든 웹 서버가 동시에 여러 호스트인 것처럼 동작하는 기능을 지원하므로, 이를 구현하는 데 로드 밸런서가 필요하지 않다고 생각할 수도 있습니다. 하지만 로드 밸런서는 필요합니다. 웹/애플리케이션 서버가 여러 가상 서버를 호스팅할 수는 있지만, 이들 간에 반드시 부하를 분산하는 것은 아니기 때문입니다. 따라서 확장하려면 여전히 로드 밸런서가 필요합니다. 관건은 로드 밸런서가 호스트를 분리하도록 할 것인지, 아니면 웹/애플리케이션 서버가 이를 처리하도록 둘 것인지입니다.

웹/앱 서버 지시문을 사용하든 외부 로드 밸런서를 사용하든 처리 흐름은 동일합니다. 요청이 전송되면 대상(로드 밸런서 또는 웹/앱 서버)이 이를 수신합니다. 그런 다음 대상 서버는 HTTP 헤더를 검사하여 호스트 값을 확인한 후 요청을 적절한 가상 서버로 전달합니다.

로드 밸런서를 사용해 호스트를 분리하면 호스트를 기준으로 도메인을 격리하고 각각 독립적으로 확장할 수 있다는 이점이 있습니다. 이는 더 효율적이며 애플리케이션 확장에 필요한 서버(하드웨어 및 소프트웨어) 수를 줄일 수 있습니다. 또한 특정 시점에 각 호스트 서버가 처리할 수 있는 부하를 더 정확히 예측할 수 있어 용량 계획도 수월해집니다.

이는 비즈니스 로직을 호출하는 데 필요한 컴퓨팅 리소스가 이미지를 요청할 때와 같지 않기 때문입니다. 동일한 확장성 도메인에 여러 호스트를 혼합해 배치하면 부하 변동성이 커지고 용량을 예측하기 어려워집니다. 로드 밸런서를 일반적인 부하 분산 용도로 사용한다면, 호스트를 분리하고 요청을 적절한 가상 서버로 전달하는 작업은 웹/앱 서버가 담당합니다. 이 접근 방식에는 공유 인프라로 인한 단점도 있습니다. 버전 충돌과 패치 적용 문제뿐 아니라 앱 업데이트로 인해 가상 서버 간에 마찰이 발생할 수 있습니다.

컨테이너와 마이크로서비스의 도입이 확대되면서 호스트 기반 부하 분산이 인그레스 컨트롤러의 형태로 활용되고 있습니다.

라우팅 및 반환

계층 7(HTTP) 부하 분산

계층 7(HTTP) 부하 분산은 뛰어난 유연성(민첩성?) 덕분에 제가 가장 선호하는 방식입니다. 페이로드를 포함해 HTTP와 관련된 모든 요소를 기준으로 요청의 부하를 분산할 수 있습니다. 대부분의 사람들은 (제 생각에는 현명하게도) 부하 분산 규칙을 HTTP 헤더에서 확인할 수 있는 정보로 제한합니다. 여기에는 호스트, HTTP 메서드, 콘텐츠 유형, 쿠키, 사용자 지정 헤더, 사용자 에이전트 등이 포함됩니다.

HTTP 부하 분산에서는 먼저 라우팅을 수행한 다음 부하를 분산합니다. 일반적인 HTTP 부하 분산 패턴은 라우팅 –> 분산 형태입니다. 즉, 먼저 요청을 어느 가상 서버로 보낼지 결정한 다음, 알고리즘이 해당 가상 서버를 지원하는 풀에서 리소스를 선택합니다.

HTTP 부하 분산을 사용하면 API 버전이 URI(또는 사용자 지정 HTTP 헤더)에 포함되는 API 버전 관리와 같은 패턴을 구현할 수 있습니다. 부하 분산기는 버전을 구분하여 클라이언트의 요청이 실행을 담당하는 올바른 백엔드 서비스로 전달되도록 합니다. 따라서 강제로 업그레이드할 수 없는 상황에서도 클라이언트를 원활하게 마이그레이션할 수 있습니다.

이러한 유형의 확장성 패턴은 기능 분해 및 데이터 파티셔닝과 같은 다른 확장성 패턴도 지원합니다. 여러 패턴 중 가장 견고하고 민첩한 확장성 패턴으로, 애플리케이션은 물론 점차 늘어나는 마이크로서비스를 확장할 때도 매우 다양한 선택지를 제공합니다.

요약하자면, 주요 확장성 패턴은 다섯 가지이며, 이 중 대부분은 리소스를 가장 효율적으로 활용하고 성능을 극대화하기 위해 함께 사용할 수 있고 실제로도 자주 함께 사용됩니다. 지금 이 패턴 중 하나를 사용하고 있지 않더라도 앞으로는 사용하게 될 가능성이 높습니다. 따라서 어떤 종류의 앱을 사용하든, 어디에 배포하든 확장 가능한 아키텍처를 구축하려면 이러한 패턴의 기본 구성을 이해하는 것이 좋은 출발점입니다.

마음껏 확장하세요!

작성자 소개

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

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

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