부하 분산 101: 너트와 볼트

오늘날의 역동적인 애플리케이션 중심 시장에서 기업은 고객이 기대하는 정보, 서비스, 경험을 빠르고 안정적이며 안전하게 제공해야 하는 압박을 점점 더 많이 받고 있습니다. 부하 분산, 암호화, 가속, 보안과 같은 주요 네트워크 및 애플리케이션 기능은 물리적 서버의 프록시 역할을 하는 물리적 또는 가상 어플라이언스인 ADC(애플리케이션 전송 컨트롤러)를 통해 제공될 수 있습니다. 애플리케이션의 폭발적 증가와 엄격한 CI/CD(Continuous Integration and Continuous Deployment) 주기로 인한 조직의 요구 사항을 고려하면 ADC 시장이 2020년까지 연간 29억 달러에 이를 것으로 예상되는 것도 당연한 일입니다.¹

하지만 미래로 나아가기 전에, 우리가 어떻게 여기까지 왔는지 살펴보겠습니다. 네트워크 기반 부하 분산은 ADC가 작동하는 데 필수적인 기반입니다. 1990년대 중반, 최초의 로드 밸런싱 하드웨어 어플라이언스가 등장하여 조직이 서버와 네트워크에 걸쳐 작업 부하를 분산시켜 애플리케이션을 확장하는 데 도움을 주기 시작했습니다. 이러한 최초의 장치는 애플리케이션에 중립적이었고 애플리케이션 서버 외부에 위치했기 때문에 간단한 네트워크 기술을 사용하여 부하를 분산할 수 있었습니다. 기본적으로 이러한 장치는 외부 세계에 "가상 IP 주소"를 제공하고 사용자가 연결을 시도하면 양방향 네트워크 주소 변환(NAT)을 수행하는 가장 적합한 실제 서버로 연결을 전달합니다.

그러나 가상화와 클라우드 컴퓨팅이 등장하면서 하이퍼바이저에서 실행되도록 소프트웨어로 제공되는 가상 에디션으로 새로운 버전의 로드 밸런싱 ADC가 등장했습니다. 오늘날 가상 어플라이언스는 특수 목적으로 구축된 하드웨어에서 실행되는 어플라이언스와 동일한 광범위한 기능을 갖춘 애플리케이션 서비스를 제공할 수 있습니다. 또한, 이러한 가상 에디션은 가상, 클라우드 및 하이브리드 환경 간에 애플리케이션 서비스를 이동하는 데 관련된 복잡성을 크게 제거하여 조직이 프라이빗 또는 퍼블릭 클라우드 환경에서 빠르고 쉽게 애플리케이션 서비스를 시작할 수 있도록 합니다.

데이터 센터에 적용되는 최신 트렌드는 컨테이너화입니다. 컨테이너화는 분산형 애플리케이션을 배포하고 실행하는 데 도움이 되는 애플리케이션 가상화 방법입니다. 이 프로세스는 애플리케이션을 분리하여 공유 OS의 명확하게 구분된 메모리 공간에 포함합니다. 이를 통해 가상 어플라이언스를 구축하는 것보다 애플리케이션을 쉽게 개발하고 배포할 수 있을 뿐만 아니라 작업 속도도 빨라집니다. 이식성과 성능이 극적으로 향상되어 컨테이너화는 기업에 더 큰 확장성과 민첩성을 제공할 수 있습니다. 미래에는 컨테이너 아키텍처가 조직이 다양한 클라우드 환경을 더 잘 활용하는 데 도움이 될 수도 있습니다.

오늘날의 ADC는 최초의 로드 밸런서에서 서비스 가상화 프로세스를 거쳐 발전했습니다. 이제 소프트웨어 전용 가상 에디션을 통해 ADC는 가용성을 개선할 수 있을 뿐만 아니라 조직이 비즈니스에 필요한 확장 가능하고 성능이 뛰어나며 안전한 애플리케이션을 제공하는 데 도움을 줄 수 있습니다. 하지만 결국 이 모든 가상화된 애플리케이션 서비스, 공유 인프라 구축, 지능형 라우팅 기능은 부하 분산 기술의 견고한 기반 없이는 불가능할 것입니다.

기업이 동적으로 변화하는 시장의 복잡한 과제를 더 잘 해결할 수 있는 방법을 이해하기 위해 애플리케이션 제공의 기반을 살펴보겠습니다. 부하 분산 101.

시작하기에 앞서, 로드 밸런싱의 기본 용어를 살펴보겠습니다. 모두가 동일한 어휘를 사용하면 더 쉬울 것입니다. 안타깝게도 모든 부하 분산 장치 공급업체(그리고 ADC)가 서로 다른 용어를 사용하는 것 같습니다. 하지만 조금만 설명하면 혼란을 해소할 수 있습니다.

대부분의 로드 밸런싱 ADC는 노드, 호스트, 멤버 또는 서버의 개념을 활용합니다. 네 가지 개념을 모두 사용하는 경우도 있지만, 각각 다른 의미를 갖습니다. 이러한 용어는 모두 두 가지 기본 개념을 표현하려고 합니다. 일반적으로 노드 또는 서버라고 하는 한 가지 개념은 ADC에서 트래픽을 수신하는 물리적 또는 가상 서버 자체의 개념입니다. 이는 물리적 서버의 IP 주소와 동의어이며 로드 밸런서가 없는 경우 서버 이름(예: www.example.com)이 확인되는 IP 주소가 됩니다. 이 논문의 이후 부분에서는 이 개념을 호스트라고 부르겠습니다.

두 번째 개념은 "멤버"(불행히도 일부 제조업체에서는 노드라고도 함)라는 용어로 표현됩니다. 멤버는 일반적으로 호스트보다 좀 더 구체적으로 정의되는데, 트래픽을 수신하는 실제 애플리케이션의 TCP 포트를 포함합니다. 예를 들어, www.example.com이라는 호스트는 호스트를 나타내는 주소 172.16.1.10으로 확인될 수 있으며, TCP 포트 80에서 실행되는 애플리케이션(웹 서버)이 있을 수 있으므로 멤버 주소는 172.16.1.10:80이 될 수 있습니다. 간단히 말해서, 멤버는 물리적/가상 서버의 IP 주소뿐만 아니라 애플리케이션 포트의 정의도 포함합니다. 이 논문의 이후 부분에서는 이것을 서비스라고 부르겠습니다.

왜 이렇게 복잡한 걸까요? 서버와 해당 서버에서 실행되는 애플리케이션 서비스를 구분함으로써 로드 밸런서는 데이터 센터나 클라우드에서 기본 하드웨어나 하이퍼바이저가 아닌 애플리케이션과 개별적으로 상호 작용할 수 있습니다. 호스트(172.16.1.10)는 두 개 이상의 서비스(HTTP, FTP, DNS 등)를 사용할 수 있습니다. 각 애플리케이션을 고유하게 정의하면(예: 172.16.1.10:80, 172.16.1.10:21, 172.16.1.10:53) ADC는 호스트가 아닌 서비스를 기반으로 고유한 부하 분산 및 상태 모니터링(나중에 설명할 개념)을 적용할 수 있습니다.

대부분의 로드 밸런싱 기반 기술은 호스트 또는 물리적 서버를 나타내는 데 한 가지 용어를 사용하고, 해당 서버에서 사용할 수 있는 서비스를 나타내는 데는 다른 용어를 사용합니다. 이 경우에는 간단히 호스트와 서비스를 사용합니다.

부하 분산을 통해 조직은 퍼블릭 또는 프라이빗 클라우드에 배포하는 것을 포함하여 여러 백엔드 대상에 인바운드 애플리케이션 트래픽을 분산시킬 수 있습니다. 그러므로 백엔드 목적지 컬렉션이라는 개념이 필요합니다. 클러스터(풀이나 팜이라고도 함)는 아무리 많은 호스트에서나 사용할 수 있는 유사한 서비스의 모음입니다. 예를 들어, 회사 웹 페이지를 제공하는 모든 서비스는 "회사 웹 페이지"라는 클러스터에 수집되고, 전자 상거래 서비스를 제공하는 모든 서비스는 "전자 상거래"라는 클러스터에 수집됩니다.

가상 서버는 실제 서버(물리적, 가상 또는 컨테이너)의 프록시입니다. 가상 IP 주소와 결합하여 외부 세계에 표시되는 애플리케이션 엔드포인트입니다.

이러한 용어를 이해하면 로드 밸런싱의 기본을 이해할 수 있습니다. 부하 분산 ADC는 가상 서버를 외부 세계에 제공합니다. 각 가상 서버는 하나 이상의 물리적 호스트에 있는 서비스 클러스터를 가리킵니다.

그림 2는 실제 배포 상황을 대표하지는 않지만, 부하 분산 및 애플리케이션 제공 프로세스에 대한 논의를 계속할 수 있는 기본적인 구조를 제공합니다.

이러한 공통적인 어휘를 확립했으므로, 애플리케이션이 고객에게 전달되는 간단한 거래를 살펴보겠습니다. 그림에서 보듯이, 로드 밸런싱 ADC는 일반적으로 클라이언트와 클라이언트가 사용하려는 서비스를 제공하는 호스트 사이에 인라인으로 배치됩니다. 애플리케이션 제공의 대부분 사항과 마찬가지로, 이러한 포지셔닝은 규칙이 아니라 모든 종류의 배포에서 적용되는 모범 사례입니다. 또한 ADC가 두 개의 서비스 지점으로 구성된 클러스터를 가리키는 가상 서버로 이미 구성되어 있다고 가정해 보겠습니다. 이러한 배포 시나리오에서는 호스트가 로드 밸런서를 가리키는 반환 경로를 갖는 것이 일반적이며, 반환 트래픽이 클라이언트로 돌아가는 길에 해당 경로를 거쳐 처리됩니다.

기본적인 애플리케이션 전달 거래는 다음과 같습니다.

• 클라이언트가 서비스에 연결을 시도합니다.
• ADC는 연결을 수락하고, 어떤 호스트가 연결을 수신해야 할지 결정한 후 대상 IP(그리고 아마도 포트)를 선택한 호스트의 서비스와 일치하도록 변경합니다(클라이언트의 소스 IP는 변경되지 않습니다).
• 호스트는 연결을 수락하고 기본 경로인 ADC를 통해 원래 소스인 클라이언트에게 응답합니다.
• ADC는 호스트에서 반환되는 패킷을 가로채서 소스 IP(및 가능한 포트)를 가상 서버 IP 및 포트와 일치하도록 변경하고, 패킷을 클라이언트로 다시 전달합니다.
• 클라이언트는 반환 패킷을 가상 서버에서 왔다고 믿고 프로세스를 계속 진행합니다.

이 매우 간단한 예는 비교적 간단해 보이지만, 주목해야 할 핵심 요소가 몇 가지 있습니다. 첫째, 클라이언트가 아는 한, 클라이언트는 가상 서버로 패킷을 보내고 가상 서버는 응답합니다. 간단합니다. 두 번째로 NAT가 발생합니다. 이는 ADC가 클라이언트(가상 서버)가 보낸 대상 IP를 요청의 부하를 분산하기 위해 선택한 호스트의 대상 IP로 대체하는 것입니다. 세 번째는 NAT를 "양방향"으로 만드는 프로세스의 일부입니다. 호스트에서 반환되는 패킷의 소스 IP는 호스트의 IP가 됩니다. 이 주소가 변경되지 않고 패킷이 단순히 클라이언트로 전달된다면 클라이언트는 요청하지 않은 상대방으로부터 패킷을 수신하게 되고, 해당 패킷을 그냥 버립니다. 대신, 로드 밸런서는 연결을 기억하고 패킷을 다시 작성하여 소스 IP가 가상 서버의 IP가 되도록 하여 이 문제를 해결합니다.

일반적으로 이 시점에서 두 가지 질문이 발생합니다. 로드 밸런싱 ADC는 연결을 보낼 호스트를 어떻게 결정합니까? 선택한 호스트가 작동하지 않으면 어떻게 되나요?

먼저 두 번째 질문부터 논의해 보겠습니다. 선택한 호스트가 작동하지 않으면 어떻게 되나요? 간단한 답은 클라이언트 요청에 응답하지 않고 연결 시도는 결국 시간 초과되어 실패한다는 것입니다. 이는 높은 가용성을 보장하지 않으므로 분명 선호되는 상황은 아닙니다. 그렇기 때문에 대부분의 부하 분산 기술에는 호스트에 연결을 보내기 전에 호스트가 실제로 사용 가능한지 확인하기 위한 일정 수준의 상태 모니터링이 포함되어 있습니다.

건강 모니터링에는 여러 수준이 있으며, 각 수준이 점점 더 세부적이고 집중적으로 이루어집니다. 기본 모니터는 단순히 호스트 자체에 ping을 보냅니다. 호스트가 ping에 응답하지 않으면 호스트에 정의된 모든 서비스가 다운되었을 가능성이 높으며, 사용 가능한 서비스 클러스터에서 제거해야 한다고 추측할 수 있습니다. 안타깝게도 호스트가 ping에 응답하더라도 반드시 서비스 자체가 작동하고 있다는 것을 의미하지는 않습니다. 따라서 대부분의 장치는 간단한 TCP 연결부터 스크립트나 지능형 상호 작용을 통한 애플리케이션과의 상호 작용에 이르기까지 어떤 종류의 "서비스 ping"을 수행할 수 있습니다. 이러한 상위 수준의 상태 모니터는 호스트가 아닌 실제 서비스의 가용성에 대한 더 큰 확신을 제공할 뿐만 아니라 로드 밸런서가 단일 호스트의 여러 서비스를 구별할 수 있도록 합니다. 로드 밸런서는 한 서비스를 사용할 수 없더라도 같은 호스트의 다른 서비스는 잘 작동하고 있을 수 있으며 여전히 사용자 트래픽의 유효한 대상으로 간주되어야 한다는 점을 이해합니다.

이제 첫 번째 질문으로 돌아가보겠습니다. ADC는 어떤 호스트에 연결 요청을 보낼지 어떻게 결정하나요? 각 가상 서버에는 특정 서비스 전용 클러스터가 있으며(해당 서비스를 제공하는 호스트가 나열됨) 이것이 가능성 목록을 구성합니다. 또한, 상태 모니터링은 해당 목록을 수정하여 지정된 서비스를 제공하는 "현재 사용 가능한" 호스트 목록을 만듭니다. ADC가 새로운 연결을 수신할 호스트를 선택하는 기준은 바로 이 수정된 목록입니다. 정확한 호스트를 결정하는 것은 해당 클러스터와 관련된 부하 분산 알고리즘에 따라 달라집니다. 이러한 알고리즘에는 최소 연결, 동적 비율, 로드 밸런서가 목록의 맨 위부터 아래로 내려가며 각각의 새 연결을 다음 호스트에 할당하는 단순 라운드 로빈 등이 있습니다. 목록의 맨 아래에 도달하면 다시 맨 위에서 시작합니다. 이는 간단하고 예측이 가능하지만, 모든 연결이 백엔드 호스트에서 비슷한 부하와 지속 시간을 갖는다고 가정하는 것이 일반적이며, 이는 항상 그런 것은 아닙니다. 더욱 진보된 알고리즘은 현재 연결 수, 호스트 활용도, 심지어 호스트로의 기존 트래픽에 대한 실제 응답 시간과 같은 사항을 사용하여 사용 가능한 클러스터 서비스 중에서 가장 적합한 호스트를 선택합니다.

충분히 발전된 애플리케이션 제공 시스템이라면 부하 분산 알고리즘과 상태 모니터링 정보를 합성하여 서비스 종속성을 이해할 수도 있을 것입니다. 이 기능은 단일 호스트에 여러 서비스가 있고, 이 모든 서비스가 사용자 요청을 완료하는 데 필요한 경우에 유용합니다. 이런 경우에는 하나의 서비스는 작동하지만 다른 서비스는 작동하지 않는 호스트로 사용자가 이동하는 것을 원하지 않을 것입니다. 다시 말해, 호스트에서 한 서비스가 실패하면 해당 호스트의 다른 서비스도 클러스터의 사용 가능한 서비스 목록에서 제거되어야 합니다. HTML과 스크립팅으로 서비스가 더욱 차별화됨에 따라 이 기능은 점점 더 중요해지고 있습니다.

클라이언트가 트랜잭션 요청을 시작할 때 사용 가능한 서비스를 선택하는 부하 분산 부분은 솔루션의 절반에 불과합니다. 연결이 설정되면 ADC는 해당 사용자의 후속 트래픽에 대해 부하를 분산해야 하는지 여부를 추적해야 합니다. 일반적으로 부하 분산이 완료된 후 후속 트래픽을 처리하는 데에는 연결 유지 관리와 지속성이라는 두 가지 문제가 있습니다.

사용자가 장기 TCP 연결(포트 21)을 활용하려고 하는 경우: FTP, 포트 23: Telnet이나 기타)가 즉시 닫히지 않는 경우, 로드 밸런서는 해당 연결을 통해 전송되는 여러 데이터 패킷이 다른 사용 가능한 서비스 호스트로 로드 밸런싱되지 않도록 해야 합니다. 이는 연결 유지 관리이며 두 가지 핵심 기능이 필요합니다. 첫 번째는 열려 있는 연결과 해당 연결이 속한 호스트 서비스를 추적하는 기능입니다. 두 번째로, 로드 밸런서는 해당 연결을 지속적으로 모니터링하여 연결이 닫힐 때 연결 테이블을 업데이트할 수 있어야 합니다. 이는 대부분 ADC의 표준적인 요금입니다.

그러나 클라이언트가 여러 개의 단명 TCP 연결(예: 포트 80)을 사용하는 경우가 점점 더 흔해지고 있습니다. HTTP)를 사용하여 단일 작업을 완료합니다. 표준 웹 브라우징과 같은 어떤 경우에는 문제가 되지 않으며 각각의 새로운 요청은 어느 백엔드 서비스 호스트로든 전송될 수 있습니다. 그러나 XML, 전자상거래 등과 같이 동일한 사용자의 여러 연결이 동일한 백엔드 서비스 호스트로 전송되고 부하 분산이 되어서는 안 되는 매우 중요한 경우가 많습니다. 이 개념을 지속성 또는 서버 친화성이라고 합니다.

프로토콜과 원하는 결과에 따라 이를 해결하는 방법이 여러 가지 있습니다. 예를 들어, 최신 HTTP 트랜잭션에서 서버는 "keep-alive" 연결을 지정할 수 있습니다. 이를 통해 여러 개의 단기 연결을 단일 장기 연결로 전환하여 다른 장기 연결과 마찬가지로 처리할 수 있습니다. 그러나 이 방법은 별로 효과가 없습니다. 주된 이유는 웹과 모바일 서비스 사용이 늘어나면서 모든 연결을 필요 이상으로 오랫동안 열어 두면 전체 시스템 리소스에 부담을 주기 때문입니다. 이것이 오늘날 많은 조직이 확장성과 이동성을 위해 API에 의존하는 상태 비저장 애플리케이션을 구축하는 방향으로 이동하는 이유입니다. 기본적으로 이는 서버가 리소스의 부하를 줄이기 위해 모든 세션 정보를 잊어버리고, 이러한 경우 세션 ID를 전달하고 지속성 개념을 통해 상태가 유지된다는 것을 의미합니다.

지속성의 가장 기본적인 형태 중 하나는 소스 주소 친화성으로, 들어오는 요청의 소스 IP 주소와 부하를 분산한 서비스 호스트를 간단히 기록하고, 이후의 모든 트랜잭션이 동일한 호스트로 이동하도록 하는 것입니다. 이를 달성하는 두 가지 방법은 SSL 세션 ID와 쿠키를 사용하는 것입니다. SSL 지속성은 SSL 세션 ID를 사용하여 SSL 세션을 추적합니다. 즉, 클라이언트의 IP 주소가 변경되더라도 로드 밸런서는 세션 ID를 기반으로 세션이 지속되는 것을 인식합니다. 쿠키 기반 지속성은 클라이언트의 컴퓨터에 쿠키를 삽입하여 세션을 고유하게 식별한 다음 요청에서 해당 쿠키를 참조하여 연결이 올바른 서버로 이동하도록 하는 옵션을 제공합니다.

오늘날 ADC의 지능 덕분에 조직에서는 데이터 패킷을 열고 패킷 내의 모든 항목에 대한 지속성 테이블을 생성할 수 있습니다. 이를 통해 사용자 이름과 같은 고유 정보를 사용하여 지속성을 유지할 수 있습니다. 그러나 조직에서는 이러한 식별 가능한 클라이언트 정보가 모든 요청에 포함되어 있는지 확인해야 합니다. 이 정보가 없는 패킷은 유지되지 않고 다시 부하가 분산되어 애플리케이션이 중단될 가능성이 높습니다.

초기에는 로드 밸런싱이 네트워크 전체에 걸쳐 작업 부하를 분산시키고 애플리케이션과 서비스의 가용성을 보장하는 데 초점을 맞췄습니다. 하지만 기술이 발전함에 따라 로드 밸런서는 애플리케이션 전송을 위한 플랫폼이 되었고, 조직의 중요한 애플리케이션의 높은 가용성과 보안을 보장하게 되었습니다. 기본적인 로드 밸런싱이 여전히 애플리케이션 제공의 기반인 반면, 최신 ADC는 훨씬 더 향상된 기능을 제공합니다.

기업들은 단순히 애플리케이션에 접속할 수 있다고 해서 그것을 사용할 수 있는 것은 아니라는 사실을 깨닫고 있으며, 사용할 수 없는 애플리케이션은 이를 배포하는 조직에 시간과 비용 낭비를 의미한다. 바로 여기서 현대식 ADC가 등장합니다. 이를 통해 조직은 SSL/TLS 오프로드, 캐싱, 압축, 속도 조절, 침입 탐지, 애플리케이션 방화벽, 심지어 원격 액세스와 같은 네트워크 기반 서비스를 모든 애플리케이션 서비스와 모든 호스트에서 공유하고 재사용할 수 있는 단일 전략적 지점으로 통합하여 가상화된 애플리케이션 전송 네트워크를 구축할 수 있습니다. 이를 통해 네트워크, 애플리케이션 및 운영 팀은 보안에 대한 필요성을 희생하지 않고도 더 짧은 납품 일정과 더 큰 확장성을 요구하는 비즈니스 요구에 더 잘 대응할 수 있습니다.

고급 애플리케이션 전송의 작동 방식과 ADC의 미래에 대해 자세히 알고 싶다면 애플리케이션 전송 컨트롤러의 진화 와 일반적인 부하 분산을 넘어서는 방법 을 읽어보세요.