애플리케이션 딜리버리 컨트롤러의 진화
소개
오늘날과 같이 급변하는 환경에서 조직은 전 세계 수백만 명의 사용자에게 핵심 애플리케이션을 제공해야 하는 과제에 끊임없이 직면하고 있습니다. 애플리케이션의 확장성, 보안 및 가용성을 확보하려면 네트워크 및 애플리케이션 서비스를 구축하는 것이 매우 중요합니다. 이는 애플리케이션 딜리버리 컨트롤러(ADC)가 발전하게 된 주요 이유 중 하나입니다. 하지만 기본적인 부하 분산 기술이라는 탄탄한 기반 없이는 이러한 기능을 구현할 수 없습니다. 이제 부하 분산의 중요성과 이를 통해 효율적인 애플리케이션 제공이 어떻게 가능해지는지, 그리고 ADC가 클라우드 우선 환경에 발맞춰 어떻게 지속적으로 발전하고 있는지 살펴보겠습니다.
로드 밸런싱 수요를 이끄는 요인
로드 밸런싱의 목적은 유입되는 네트워크 또는 애플리케이션 트래픽을 여러 물리적 서버에 분산하고, 외부에서는 이러한 서버들이 하나의 서버처럼 보이게 하는 것입니다. 이렇게 하는 데에는 여러 이유가 있지만, 주된 요인은 "확장성", "고가용성", "예측 가능성"에 대한 필요성입니다.
확장성이란 기존 성능에 영향을 주지 않으면서 증가하는 부하에 동적으로 또는 손쉽게 대응할 수 있는 능력을 말합니다. 반면 고가용성(HA)이란 하나 이상의 시스템에 장애가 발생하더라도 사이트를 계속 사용하고 접속할 수 있도록 유지하는 능력입니다. 서비스 가상화(애플리케이션 개발을 가속화하고 테스트하기 위해 소프트웨어 구성 요소의 동작을 모방하는 기술)는 확장성과 가용성을 모두 향상할 수 있는 흥미로운 기회를 제공합니다. 서비스 또는 사용자 접점이 실제 서버와 분리되어 있으면 서버를 추가하여 애플리케이션을 확장할 수 있습니다. 또한 개별 서버에 장애가 발생하더라도 전체 애플리케이션을 사용할 수 없게 되지는 않습니다. 예측 가능성은 고가용성의 일부 요소와 그 과정에서 얻은 교훈을 함께 아우르는 개념이므로 다소 명확하지 않을 수 있습니다. 가용성과 성능 측면에서 서비스가 언제, 어떻게 제공되는지를 제어할 수 있는 능력이라고 설명하는 것이 가장 적절합니다.
로드 밸런싱의 역사적 관점
상업용 인터넷이 막 태동하던 시절, 닷컴으로 백만장자가 되려던 많은 이들은 자신들의 계획에 심각한 문제가 있음을 깨달았습니다. 메인프레임에는 웹 서버 소프트웨어가 없었고(적어도 AS/400e가 나오기 전까지는), 설령 있었다 해도 스타트업 예산으로는 감당할 수 없었습니다. 그들이 구입할 수 있었던 것은 흔히 볼 수 있는 PC 제조업체 중 한 곳에서 판매하는 표준 기성 서버 하드웨어였습니다. 하지만 대부분의 서버에는 큰 문제가 있었습니다. PC 기반 서버 한 대로는 사업에서 발생할 트래픽을 도저히 감당할 수 없었던 것입니다. 게다가 서버가 다운되면 서비스가 중단되어 사업도 멈출 수밖에 없었습니다. 다행히도 그중 일부는 바로 이 문제를 해결해 큰돈을 벌 계획을 세웠습니다. 그렇게 로드 밸런싱이 탄생했습니다.
태초에 DNS가 있었다
상용으로 판매되는 전용 로드 밸런싱 장치가 등장하기 전에는 확장성과 가용성이라는 목표를 달성하기 위해 기존 기술을 활용하려는 시도가 많았습니다. 그중 가장 널리 사용되었고 지금도 사용되는 기술은 DNS 라운드 로빈이었습니다.
이 방식에서는 DNS가 동일한 DNS 이름 아래 서로 다른 서버에 여러 개의 고유한 IP 주소를 할당했습니다. 즉, 사용자가 처음으로 “www.example.com”의 주소 확인을 요청하면 DNS 서버는 대기열의 첫 번째 서버부터 시작해 각 신규 연결을 차례로 전달하고, 마지막 서버에 도달하면 다시 첫 번째 서버로 돌아갔습니다. 이 솔루션은 간단했으며 여러 시스템에 연결을 고르게 분산할 수 있었습니다.
확장성 측면에서 이 솔루션은 하나의 DNS 이름에 사실상 무제한으로 서버를 추가할 수 있어 매우 효과적이었습니다. 그러나 가용성 측면에서는 DNS가 목록에 있는 서버의 작동 여부를 확인할 수 없다는 문제가 있었습니다. 서버를 사용할 수 없는 상태에서 사용자가 해당 서버에 접속하려고 하면, 요청이 중단된 서버로 전송될 수 있었습니다.
DNS 라운드 로빈을 도입하게 된 또 다른 요인은 예측 가능성, 즉 사용자가 특정 서버로 연결될 것이라는 높은 수준의 확신이었습니다. 이는 지속성이라는 개념을 중심으로 합니다. 지속성이란 세션이 시작된 후 또는 사용자가 이전에 일시 중단한 세션을 재개할 때 사용자가 부하 분산으로 인해 새 서버에 연결되지 않도록 보장하는 것을 의미합니다. 이는 DNS 라운드 로빈으로는 해결할 수 없었던 매우 중요한 문제였습니다.
소프트웨어 기반 독점 로드 밸런싱
이 문제를 해결하기 위해 초기에 등장한 전용 솔루션 중 하나는 애플리케이션 소프트웨어나 애플리케이션 서버의 운영 체제(OS)에 로드 밸런싱 기능을 직접 내장하는 방식이었습니다. 이를 개발한 회사만큼이나 구현 방식도 다양했지만, 대부분의 솔루션은 기본적인 네트워크 기법을 활용했습니다. 예를 들어, 한 솔루션에서는 풀(클러스터라고도 함)에 속한 모든 서버가 각자의 물리적 IP 주소 외에 별도의 IP 주소를 갖도록 했습니다.
사용자가 서비스에 연결하려고 하면 서버의 물리적 IP가 아닌 풀 IP에 연결되었습니다. 풀에서 연결 요청에 가장 먼저 응답한 서버는 사용자를 물리적 IP 주소(자신의 주소 또는 풀에 있는 다른 시스템의 주소)로 리디렉션했고, 그러면 서비스 세션이 시작되었습니다. 이 솔루션의 주요 이점 중 하나는 애플리케이션 개발자가 다양한 정보를 활용하여 클라이언트가 연결할 물리적 IP 주소를 결정할 수 있다는 점이었습니다. 예를 들어 풀의 각 서버가 각 풀 구성원이 이미 처리 중인 세션 수를 집계하도록 한 다음, 새로운 요청을 사용률이 가장 낮은 서버로 전달할 수 있었습니다.
처음에는 이 솔루션의 확장성이 분명해 보였습니다. 새 서버를 구축하여 풀에 추가하기만 하면 애플리케이션의 용량을 늘릴 수 있었습니다. 하지만 시간이 지나면서 애플리케이션 기반 부하 분산의 확장성에 의문이 제기되었습니다. 다음 연결을 어느 서버로 보낼지 결정하기 위해 풀 구성원들이 서로 지속적으로 통신해야 했기 때문에, 풀에 새 서버가 추가될 때마다 구성원 간 네트워크 트래픽이 기하급수적으로 증가했습니다. 풀이 일정 규모(일반적으로 호스트 5~10대)에 이르면 이 트래픽은 최종 사용자 트래픽뿐만 아니라 서버 자체의 프로세서 사용률에도 영향을 미치기 시작했습니다. 따라서 소수의 서버만 필요하다면 확장성이 뛰어났지만, 그 수를 초과해야 하는 경우에는 그렇지 않았습니다(참고로 DNS 라운드 로빈보다도 적은 수였습니다).
DNS 라운드 로빈과 소프트웨어 로드 밸런싱을 통해 HA가 크게 향상되었습니다. 풀 구성원들이 서로 지속적으로 통신하고 있었고, 애플리케이션 개발자들이 애플리케이션에 대한 폭넓은 지식을 활용해 서버가 정상적으로 작동하는지 판단할 수 있었기 때문에, 이러한 솔루션은 사용자가 요청을 처리할 수 없는 서버에 연결될 가능성을 사실상 없앴습니다. 그러나 HA 기능에 지능형 특성이 추가될 때마다 그에 상응하는 서버 및 네트워크 사용량 증가가 발생하여 확장성이 더욱 제한되었다는 점을 지적해야 합니다. HA에 미친 또 다른 부정적인 영향은 안정성 측면에서 나타났습니다. 이러한 시스템에서 트래픽을 분산하는 데 사용된 여러 네트워크 기법은 복잡했으며 상당한 수준의 네트워크 모니터링이 필요했습니다. 따라서 이러한 분산 방식에서는 전체 애플리케이션과 애플리케이션 네트워크의 모든 트래픽에 영향을 미치는 문제가 자주 발생했습니다.
이러한 솔루션은 예측 가능성도 향상시켰습니다. 애플리케이션 설계자는 사용자를 부하 분산하는 대신 동일한 서버로 다시 보내야 하는 시점과 이유를 알고 있었으므로, 필요한 경우 사용자의 세션 지속성을 보장하는 로직을 구현할 수 있었습니다. 또한 동일한 "풀링" 기술을 사용하여 서버 간에 사용자 상태 정보를 복제함으로써, 애초에 세션 지속성이 필요했던 많은 상황을 해소했습니다. 마지막으로, 애플리케이션에 대한 깊은 이해를 바탕으로 서버 부하를 항상 정확히 나타내지는 못하는 연결 수와 같은 지표 대신 애플리케이션의 실제 상태를 기준으로 부하 분산 알고리즘을 개발할 수 있었습니다.
실질적인 확장성의 잠재적 한계와 안정성 문제 외에도, 독점적인 애플리케이션 기반 부하 분산에는 또 하나의 단점이 있었습니다. 개발과 유지 관리가 애플리케이션 공급업체에 의존한다는 점이었습니다. 가장 큰 문제는 모든 애플리케이션이 부하 분산(또는 풀링) 기술을 제공하는 것은 아니었으며, 이를 제공하더라도 다른 애플리케이션 공급업체의 기술과 호환되지 않는 경우가 많았다는 것입니다. 공급업체에 종속되지 않는 OS 수준의 부하 분산 소프트웨어를 개발한 조직도 여러 곳 있었지만, 안타깝게도 이러한 소프트웨어 역시 동일한 확장성 문제를 겪었습니다. 또한 애플리케이션과 긴밀하게 통합되지 않았기 때문에 이러한 소프트웨어 "솔루션"에는 고가용성(HA)과 관련된 추가적인 문제도 있었습니다.
네트워크 기반 부하 분산 하드웨어
전용 로드 밸런싱의 두 번째 형태는 네트워크 기반 어플라이언스로 등장했습니다. 이는 오늘날 애플리케이션 전송 컨트롤러의 진정한 시초입니다. 이러한 어플라이언스는 애플리케이션 외부에 물리적으로 배치되었으며, 처음에는 로드 밸런서로 출발했지만 NAT와 같은 훨씬 단순한 네트워크 기술을 사용해 부하를 분산했습니다. 이 장치는 외부에 가상 서버 주소를 제공하고, 사용자가 연결을 시도하면 가장 적합한 실제 서버로 연결을 전달했습니다.
로드 밸런서는 어떤 서버가 어떤 연결을 수신할지 정확하게 제어할 수 있었으며, 점점 더 정교해지는 "상태 모니터"를 사용하여 애플리케이션 서버(실제 물리적 서버)가 필요에 따라 응답하는지 확인했습니다. 서버가 올바르게 응답하지 않으면 로드 밸런서는 원하는 응답이 나올 때까지 해당 서버로 트래픽을 보내는 작업을 자동으로 중단했습니다. 상태 모니터가 애플리케이션 개발자가 직접 구축한 것만큼 포괄적인 경우는 드물었지만, 네트워크 기반 하드웨어 방식은 거의 모든 애플리케이션에 기본적인 로드 밸런싱 서비스를 일관되고 통일된 방식으로 제공할 수 있었습니다. 이로써 마침내 애플리케이션 서버 전용의 완전히 가상화된 서비스 진입점이 만들어졌습니다.
확장성 측면에서 소프트웨어 기반 부하 분산을 하드웨어 기반 솔루션으로 교체하기 시작한 조직은 서버 사용률이 크게 감소하는 효과를 보았습니다. 그 결과 단기적으로 추가 서버를 구매할 필요가 없어졌으며, 장기적으로는 투자 수익률(ROI)을 높이는 데 도움이 되었습니다.
마찬가지로 HA는 솔루션의 복잡성을 줄이고 애플리케이션에 구애받지 않는 로드 밸런싱을 제공함으로써 안정성을 높이고 솔루션의 완성도를 향상하는 데 기여했습니다. 네트워크 기반 로드 밸런싱 하드웨어를 통해 기업은 로드 밸런싱 기능이 내장된 일부 애플리케이션뿐만 아니라 모든 애플리케이션에 높은 수준의 가용성을 제공할 수 있었습니다.
네트워크 기반 부하 분산 하드웨어가 추가한 핵심 요소는 예측 가능성이었습니다. 이제 새로운 연결이 어디로 전달될지 훨씬 쉽게 예측하고 조정할 수 있게 되었습니다. 이러한 장치는 프로세스에 지능을 더해 동적 DNS의 제어되지 않는 분산과 달리 부하를 제어된 방식으로 분산할 수 있도록 했습니다. 이에 따라 비즈니스 소유자는 각 서버의 부하 처리 능력에 맞춰 부하를 분산할 수 있었습니다.
네트워크 기반 로드 밸런서와 가상화의 등장으로 인터넷 사용자에게 애플리케이션 서버의 신원을 숨기고, 사용자에게 영향을 주지 않으면서 유지보수를 위해 서버의 연결을 점진적으로 해제한 후 오프라인으로 전환할 수 있게 되는 등 보안 및 관리 측면에서 새로운 이점이 생겼습니다. 이것이 ADC의 기원이 되었습니다.
애플리케이션 전송 컨트롤러
완전 프록시이기도 한 중앙 집중식 부하 분산 기능은 IT 부서가 새롭게 등장하는 서비스를 추가하고 통합하기에 매우 적합한 기반이 되었습니다. 그 결과 부하 분산 장치는 확장 가능한 ADC 플랫폼으로 발전했습니다. 간단히 말해, 프록시는 부하 분산의 기반이자 ADC를 가능하게 하는 핵심 기술입니다.
ADC 보안을 논할 때는 기반 기술인 프록시가 구현하는 가상화가 매우 중요합니다. SSL/TLS 암호화 오프로딩, 중앙 집중식 인증, 심지어 애플리케이션 인식 방화벽에 이르기까지 이러한 솔루션의 강점은 로드 밸런서(하드웨어 또는 가상 에디션)가 모든 애플리케이션을 아우르는 가상화의 통합 지점이라는 데 있습니다. 중앙 집중식 인증이 대표적인 예입니다. 기존의 인증 및 권한 부여 메커니즘은 항상 애플리케이션 자체에 직접 내장되어 있었습니다. 애플리케이션 기반 로드 밸런싱과 마찬가지로 각 구현 방식은 해당 애플리케이션의 구현에 종속되고 애플리케이션마다 고유했기 때문에 수많은 서로 다른 방식이 생겨났습니다. 이와 달리 모든 애플리케이션의 가상화된 진입점에서 인증을 적용하면 일관된 단일 인증 방식을 사용할 수 있습니다. 이는 인증 시스템의 설계와 관리를 획기적으로 간소화할 뿐만 아니라, 애플리케이션 서버가 해당 기능을 직접 수행할 필요를 없애 서버 자체의 성능도 향상합니다. 또한 특히 자체 개발 애플리케이션의 경우, 개별 애플리케이션마다 인증 프로세스를 개발하는 데 시간과 비용을 들일 필요도 없어집니다.
가용성은 확장성, 고가용성, 예측 가능성 등 로드 밸런서의 모든 기본 속성과 관련되므로 기존 로드 밸런서와 가장 쉽게 연관 지을 수 있는 ADC 속성입니다. 하지만 ADC는 기존 로드 밸런서보다 이 개념을 한층 더 발전시킵니다. ADC에서 가용성은 애플리케이션 종속성과 동적 프로비저닝 같은 고급 개념도 포함합니다. ADC는 오늘날 애플리케이션이 독립적으로 작동하는 경우가 드물며, 설계된 기능을 수행하기 위해 다른 애플리케이션에 의존하는 경우가 많다는 점을 이해할 수 있습니다. ADC는 이러한 다른 프로세스까지 고려함으로써 애플리케이션 가용성을 제공하는 역량을 강화합니다. 시중의 가장 지능적인 ADC는 외부 입력에 따라 서비스 제공 방식을 동적으로 변경할 수 있는 프로그래밍 인터페이스도 제공합니다. 이러한 인터페이스를 통해 동적 프로비저닝은 물론, 클라우드 및 컨테이너화된 배포와 같은 최신 환경에 필요한 자동 확장 및 축소가 가능합니다.
성능 향상은 부하 분산 개념에서 자연스럽게 확장된 또 하나의 기능이었습니다. 로드 밸런서는 연결을 사용 가능하고 허용 가능한 시간 내에 응답하는 서비스로 전달할 뿐만 아니라, 연결 수 및/또는 프로세서 사용률이 가장 낮은 서비스로 전달함으로써 본질적으로 애플리케이션의 성능을 향상시켰습니다. 이를 통해 각각의 새 연결이 해당 연결을 가장 원활하게 처리할 수 있는 시스템에서 서비스되도록 했습니다. 이후 전용 하드웨어를 사용하는 SSL/TLS 오프로딩이 부하 분산 솔루션의 보편적인 기능으로 자리 잡으면서 암호화된 트래픽의 연산 오버헤드와 백엔드 서버의 부하가 줄어들었고, 그 결과 서버의 성능도 향상되었습니다.
오늘날의 ADC는 여기서 한 단계 더 나아갑니다. 이러한 장치에는 애플리케이션의 전반적인 성능과 전송 효율을 더욱 높이기 위해 캐싱, 압축은 물론 속도 제어 기술까지 포함되는 경우가 많습니다. 또한 이러한 서비스를 제공하는 기존 독립형 어플라이언스처럼 정적으로 구현되는 대신, ADC는 자체적인 애플리케이션 인텔리전스를 활용하여 성능 향상 효과가 있을 때만 해당 서비스를 적용함으로써 서비스 활용을 최적화할 수 있습니다.
예를 들어, 일반적인 인식과 달리 압축 기술이 애플리케이션의 모든 사용자에게 반드시 유용한 것은 아닙니다. 대역폭이 좁은 사용자의 경우 실제 처리량이 병목 지점이므로 패킷 크기가 작아지면 큰 이점을 얻을 수 있습니다. 장거리를 거쳐야 하는 연결도 패킷이 작을수록 데이터 전송에 필요한 왕복 횟수가 줄어 네트워크 지연의 영향이 감소하므로 이점을 얻을 수 있습니다. 그러나 대역폭이 넓은 단거리 연결(예: 동일한 대륙 내 연결)은 압축을 적용할 경우 오히려 성능이 저하될 수 있습니다. 처리량이 반드시 병목 지점인 것은 아니므로 압축 및 압축 해제에 따른 추가 오버헤드로 지연 시간이 늘어나며, 처리량 증가만으로는 이러한 성능 저하를 상쇄할 수 없습니다. 즉, 제대로 관리하지 않으면 해결책으로 도입한 압축 기술이 원래 문제보다 더 큰 문제가 될 수 있습니다. 하지만 ADC는 전반적인 성능 향상에 도움이 되는 경우에만 지능적으로 압축을 적용함으로써 압축 기술의 활용도와 비용을 최적화하고, 프로세서 사이클을 가장 효과적으로 활용할 수 있는 기능에 더 많은 처리 자원을 할당합니다.
세계가 나아가는 방향
디지털 트랜스포메이션이 매우 중요한 전략적 과제로 자리 잡으면서 많은 기업이 클라우드로의 여정을 시작했습니다. 애플리케이션이 급증하며 우리 주변의 세상을 변화시키는 가운데, 클라우드로 전환하는 조직은 민첩성 향상, 운영 비용 최적화, 온디맨드 확장성, 핵심 비즈니스에 대한 집중 강화 등 다양한 이점을 누릴 수 있을 것으로 기대됩니다.
“클라우드”는 컴퓨팅, 스토리지 및 네트워킹 리소스를 공유하는 하나의 불분명한 개체가 아닙니다. 오히려 여러 글로벌 노드에 배포되는 경우가 많은 공급자, 인프라, 기술 및 환경이 복잡하게 결합된 형태입니다. 이 때문에 많은 기업이 실제로 퍼블릭 클라우드, 프라이빗 클라우드, 심지어 이들을 조합한 환경 등 여러 클라우드에 애플리케이션을 배포하고 있습니다. 이것이 바로 새로운 현실인 멀티클라우드입니다.
이처럼 환경이 빠르게 변화하고 있음에도 불구하고, 여러 요인이 클라우드 도입을 늦추고 있습니다. 첫 번째 과제는 멀티 클라우드의 무분별한 확산입니다. 기존 애플리케이션은 단순히 ‘리프트 앤 시프트’ 방식으로 이전되고, ‘클라우드 네이티브’ 애플리케이션은 계획이나 관리 없이 배포되어 왔습니다. 또한 조직은 단기적인 요구 사항을 충족하기 위해 서로 다른 클라우드 플랫폼과 아키텍처, 다양한 애플리케이션 서비스 및 여러 도구 세트를 사용하는 경향이 있습니다. 그 결과 기업 전반의 아키텍처가 복잡해지고, 애플리케이션을 한 환경에서 다른 환경으로 이전하기가 훨씬 더 어려워질 뿐만 아니라 비용도 많이 듭니다.
이러한 과제에도 불구하고, 향후 몇 년 동안 퍼블릭 및 프라이빗 클라우드 내부와 클라우드 간의 신규 배포는 필연적으로 증가할 것입니다. 멀티 클라우드 시대가 빠르게 다가오고 있는 만큼, 이제 기업은 제한된 애플리케이션만 지원하거나 하드웨어 및 단일 클라우드에서만 작동하는 수준을 넘어서는 지능형 애플리케이션 서비스와 ADC를 배포해야 합니다.
요약
ADC는 과거 로드 밸런서가 차지했던 네트워크의 핵심 영역을 자연스럽게 발전시킨 기술입니다. ADC는 이러한 과거의 장치에 많은 부분을 빚지고 있지만, 가용성뿐만 아니라 성능과 보안까지 제공하는 완전히 새로운 유형의 장치입니다. 이름에서 알 수 있듯이 ADC는 애플리케이션을 가능한 한 최상의 방식으로 제공하는 데 필요한 모든 측면을 다룹니다.
애플리케이션 인텔리전스, SSL 오프로딩, 프로그래밍 방식의 인터페이스와 같은 고급 기능을 갖춘 최신 ADC는 조직이 비즈니스를 확장하고 언제 어디서나 사용자에게 서비스를 제공할 수 있도록 지원합니다. 끊임없이 변화하는 기술 환경의 요구에 발맞춰 ADC 역시 멀티 클라우드 및 컨테이너 환경의 최신 기술에 더욱 유연하게 적응할 수 있습니다.
결론적으로 ADC는 애플리케이션을 더 빠르고 스마트하며 안전하게 제공하는 핵심 통로이자 통합 지점이 될 뿐만 아니라, 앞으로도 계속 발전하며 클라우드 우선 환경을 적극 수용해 나갈 것이라고 확신할 수 있습니다.
2017년 9월 10일 게시