애플리케이션 제공 컨트롤러의 진화

소개

오늘날의 역동적인 세상에서 기업은 전 세계 수백만 명의 사용자에게 중요한 애플리케이션을 제공해야 하는 과제에 끊임없이 직면합니다. 앱의 확장성, 보안성, 가용성을 높이기 위해 네트워크 및 애플리케이션 서비스를 구축하는 것이 매우 중요합니다. 이는 ADC(애플리케이션 전송 컨트롤러)가 발전한 주요 이유 중 하나입니다. 하지만 기본적인 부하 분산 기술에 대한 확실한 기반이 없이는 이러한 기능을 구현할 수 없습니다. 그렇다면 부하 분산의 중요성, 부하 분산이 효율적인 애플리케이션 제공으로 이어지는 방식, ADC가 어떻게 계속 발전하고 클라우드 우선 세계를 수용하고 있는지 이해하는 것으로 시작해 보겠습니다.

부하 분산 수요 드라이버

부하 분산의 전체적인 목적은 들어오는 네트워크나 애플리케이션 트래픽을 여러 물리적 서버로 분산하여 외부 세계에서는 해당 서버가 하나의 서버처럼 보이도록 하는 것입니다. 이를 수행하는 데에는 여러 가지 이유가 있지만 가장 중요한 이유는 "확장성", "고가용성" 및 "예측 가능성"의 필요성입니다.

확장성이란 기존 성능에 영향을 주지 않고 증가한 부하에 동적으로, 또는 쉽게 적응할 수 있는 능력을 말합니다. 반면 고가용성(HA)은 하나 이상의 시스템에 장애가 발생하더라도 사이트의 가용성과 접근이 가능한 기능을 말합니다. 서비스 가상화(소프트웨어 구성 요소의 동작을 모방하여 애플리케이션 개발을 가속화하고 테스트하는 것)는 확장성과 가용성 모두에 흥미로운 기회를 제공합니다. 서비스나 사용자 접점이 실제 서버와 분리되어 있으면, 더 많은 서버를 추가하여 애플리케이션을 확장할 수 있습니다. 게다가 개별 서버에 장애가 발생해도 전체 애플리케이션을 사용할 수 없게 되는 것은 아닙니다. 예측 가능성은 HA의 일부와 그 과정에서 얻은 몇 가지 교훈을 나타내기 때문에 그다지 명확하지 않습니다. 이는 가용성 및 성능과 관련하여 서비스가 제공되는 방법과 시기를 제어하는 것으로 가장 잘 설명될 수 있습니다.

로드 밸런싱: 역사적 관점

상업용 인터넷의 초창기, 많은 도트컴 백만장자들은 자신의 계획에 심각한 문제가 있음을 발견했습니다. 메인프레임에는 웹 서버 소프트웨어가 없었습니다(AS/400e가 나오기 전까지는 말이죠). 설령 있었다 하더라도 창업 예산으로는 감당할 수 없었습니다. 그들이 감당할 수 있었던 것은 널리 보급된 PC 제조업체에서 출시한 표준형 기성형 서버 하드웨어뿐이었습니다. 대부분의 기업의 가장 큰 문제는 단 하나의 PC 기반 서버로는 기업에서 발생하는 트래픽 양을 처리할 수 없다는 것이었습니다. 그리고 만약 문제가 생기면, 그들은 오프라인이 되어 사업을 중단하게 됩니다. 다행히도 그 사람들 중 일부는 그 특정 문제를 해결해서 수백만 달러를 벌 계획을 가지고 있었습니다. 이로 인해 로드 밸런싱이 탄생했습니다.

태초에 DNS가 있었습니다

상업적으로 이용 가능한 특정 목적의 로드 밸런싱 장치가 나오기 전에는 기존 기술을 활용해 확장성과 가용성의 목표를 달성하려는 시도가 많이 있었습니다. 가장 널리 퍼진 (그리고 지금도 사용되는) 기술은 DNS 라운드 로빈입니다.

이 방법에서는 DNS가 동일한 DNS 이름으로 여러 개의 고유한 IP 주소를 여러 서버에 할당합니다. 이는 사용자가 처음으로 " www.example.com "에 대한 확인을 요청했을 때 DNS 서버가 각 새 연결을 줄의 첫 번째 서버로 전달하여 줄의 맨 아래에 도달할 때까지 진행한 후 다시 첫 번째 서버로 돌아갔다는 것을 의미합니다. 이 솔루션은 간단했고 여러 장비에 걸쳐 연결을 균등하게 분산시키는 데 도움이 되었습니다.

중복성을 위한 기본 DNS 응답입니다.
그림 1 : 중복성을 위한 기본 DNS 응답입니다.

확장성 관점에서 볼 때, 이 솔루션은 DNS 이름에 거의 무제한의 서버를 추가할 수 있는 기회를 제공했기 때문에 매우 효과적이었습니다. 그러나 가용성 측면에서 이 솔루션은 DNS가 나열된 서버가 작동하는지 여부를 알 수 있는 기능이 없어 장애물이 되었습니다. 서버를 사용할 수 없게 되어 사용자가 해당 서버에 접속하려고 하면, 해당 요청은 다운된 서버로 전송될 수 있습니다.

DNS 라운드 로빈의 또 다른 동인은 예측 가능성이었습니다. 예측 가능성은 사용자가 특정 서버로 전송될 것이라는 높은 수준의 확신을 의미합니다. 이는 세션이 시작되거나 사용자가 이전에 중단된 세션을 재개할 때 사용자가 새 서버로 로드 밸런싱되지 않도록 하는 개념인 지속성이라는 아이디어를 중심으로 합니다. 이것은 DNS 라운드 로빈으로는 해결할 수 없는 매우 중요한 문제입니다.

소프트웨어의 독점적 로드 밸런싱

이 문제를 해결하기 위해 고안된 최초의 솔루션 중 하나는 애플리케이션 소프트웨어나 애플리케이션 서버의 운영 체제(OS)에 직접 내장된 로드 밸런싱이었습니다. 이를 개발한 회사의 수만큼 다양한 구현 방식이 있었지만 대부분의 솔루션은 기본적인 네트워크 속임수를 중심으로 이루어졌습니다. 예를 들어, 그러한 솔루션 중 하나는 모든 서버를 풀(클러스터라고도 함)에 두고, 각 서버마다 고유한 물리적 IP 주소를 갖는 방식입니다.

독점적인 풀 IP 로드 밸런싱.
그림 2: 독점적인 풀 IP 로드 밸런싱.

사용자가 서비스에 연결을 시도했을 때, 서버의 실제 IP 대신 풀 IP에 연결되었습니다. 풀 내의 서버 중 연결 요청에 먼저 응답한 서버가 사용자를 실제 IP 주소(자체 또는 풀 내의 다른 시스템)로 리디렉션하고 서비스 세션이 시작됩니다. 이 솔루션의 주요 이점 중 하나는 애플리케이션 개발자가 다양한 정보를 사용하여 클라이언트가 연결해야 할 실제 IP 주소를 결정할 수 있다는 것입니다. 예를 들어, 풀에 있는 각 서버가 각 풀 멤버가 이미 처리하고 있는 세션 수를 계산한 다음, 가장 덜 활용되는 서버로 새로운 요청을 전달하도록 할 수 있습니다.

처음에는 이 솔루션의 확장성이 명확했습니다. 새로운 서버를 만들어 풀에 추가하기만 하면 애플리케이션의 용량이 늘어납니다. 하지만 시간이 지나면서 애플리케이션 기반 부하 분산의 확장성에 대한 의문이 제기되었습니다. 풀 구성원들은 다음 연결이 누구에게 연결되어야 하는지에 관해 끊임없이 서로 연락해야 했기 때문에 풀에 새로운 서버가 추가될 때마다 풀 구성원 간의 네트워크 트래픽이 기하급수적으로 증가했습니다. 풀이 일정 크기(일반적으로 호스트 5~10개)로 커지면 이 트래픽은 최종 사용자 트래픽은 물론, 서버 자체의 프로세서 사용률에도 영향을 미치기 시작했습니다. 따라서 서버 수가 적어야 하는 경우(DNS 라운드 로빈보다 적음)에는 확장성이 뛰어납니다.

DNS 라운드 로빈과 소프트웨어 로드 밸런싱을 통해 HA가 획기적으로 증가했습니다. 풀 구성원이 서로 끊임없이 통신하고, 애플리케이션 개발자가 광범위한 애플리케이션 지식을 사용하여 서버가 정상적으로 실행되는지 알 수 있었기 때문에 이러한 솔루션은 사용자가 요청을 처리할 수 없는 서버에 접속할 가능성을 사실상 없앴습니다. 그러나 인텔리전스 기반 HA 특성을 구현하는 각 반복 작업에는 해당 서버 및 네트워크 활용도에 미치는 영향이 있어 확장성이 더욱 제한된다는 점을 지적해야 합니다. HA의 또 다른 부정적인 영향은 신뢰성 영역에 있었습니다. 이러한 시스템에서 트래픽을 분산하는 데 사용된 네트워크 트릭 중 다수는 복잡했으며 상당한 네트워크 수준의 모니터링이 필요했습니다. 따라서 이러한 배포 방법은 전체 애플리케이션과 애플리케이션 네트워크의 모든 트래픽에 영향을 미치는 문제에 자주 직면하게 되었습니다.

이러한 솔루션은 예측 가능성도 향상시켰습니다. 애플리케이션 설계자는 사용자를 로드 밸런싱하는 대신 언제, 왜 동일한 서버로 돌려보내야 하는지 알고 있었기 때문에 필요할 경우 사용자가 지속적으로 접속하도록 보장하는 로직을 내장할 수 있었습니다. 또한 그들은 동일한 "풀링" 기술을 사용하여 서버 간에 사용자 상태 정보를 복제함으로써 처음부터 지속성이 필요한 많은 인스턴스를 제거했습니다. 마지막으로, 심층적인 애플리케이션 지식 덕분에 연결과 같은 요소 대신 애플리케이션의 실제 상태를 기반으로 로드 밸런싱 알고리즘을 더 잘 개발할 수 있었습니다.연결은 항상 서버 부하를 잘 나타내는 지표는 아니었습니다.

진정한 확장성에 대한 잠재적인 제한과 안정성 문제 외에도 독점적인 애플리케이션 기반 부하 분산에는 다음과 같은 추가적인 단점이 있습니다. 개발과 유지관리는 애플리케이션 공급업체에 의존했습니다. 여기서 가장 큰 문제는 모든 애플리케이션이 로드 밸런싱(또는 풀링) 기술을 제공하지는 않는다는 것이었고, 제공하는 애플리케이션도 다른 애플리케이션 공급업체가 제공하는 기술과 작동하지 않는 경우가 많았습니다. 공급업체에 중립적인 OS 수준의 부하 분산 소프트웨어를 생산하는 조직이 몇몇 있었지만, 불행히도 이들 역시 동일한 확장성 문제를 겪었습니다. 또한 애플리케이션과 긴밀하게 통합되지 않아 이러한 소프트웨어 "솔루션"은 추가적인 HA 과제에 직면하게 되었습니다.

네트워크 기반 로드 밸런싱 하드웨어

특수 목적의 로드 밸런싱의 두 번째 버전은 네트워크 기반 어플라이언스로 출시되었습니다. 이들은 오늘날 애플리케이션 제공 컨트롤러의 진정한 창시자입니다. 이러한 어플라이언스는 물리적으로 애플리케이션 자체 외부에 상주하며 로드 밸런서로 시작했지만 NAT와 같은 훨씬 더 간단한 네트워크 기술을 사용하여 로드 밸런싱을 달성했습니다. 이러한 장치는 외부에 가상 서버 주소를 제공하고, 사용자가 연결을 시도하면 장치는 가장 적합한 실제 서버로 연결을 전달합니다.

네트워크 기반 하드웨어를 사용한 부하 분산
그림 3: 네트워크 기반 하드웨어를 사용한 부하 분산.

로드 밸런서는 각 서버가 어떤 연결을 수신하는지 정확히 제어할 수 있으며 점점 더 복잡해지는 "상태 모니터"를 사용하여 애플리케이션 서버(실제 물리적 서버)가 필요에 따라 응답하는지 확인할 수 있습니다. 서버가 올바르게 응답하지 않으면 로드 밸런서는 원하는 응답이 생성될 때까지 해당 서버로의 트래픽 전송을 자동으로 중단합니다. 상태 모니터가 애플리케이션 개발자가 직접 만든 것만큼 포괄적이지는 않지만, 네트워크 기반 하드웨어 접근 방식은 거의 모든 애플리케이션에 균일하고 일관된 방식으로 기본적인 부하 분산 서비스를 제공할 수 있습니다. 마침내 애플리케이션 서버에 고유한 진정한 가상화된 서비스 진입점을 만들 수 있습니다.

확장성 관점에서 볼 때, 소프트웨어 기반 부하 분산을 하드웨어 기반 솔루션으로 대체하기 시작한 조직은 서버 활용도가 극적으로 떨어지는 것을 경험했습니다. 이를 통해 단기적으로 추가 서버를 구매할 필요가 없어졌으며, 장기적으로 투자수익률(ROI)을 높이는 데 도움이 되었습니다.

마찬가지로 HA는 솔루션의 복잡성을 줄이고 애플리케이션에 독립적인 부하 분산을 제공하여 솔루션으로서의 안정성과 심도 있는 기능을 강화하는 데 도움이 됩니다. 네트워크 기반 로드 밸런싱 하드웨어를 사용하면 기업 소유자는 내장된 로드 밸런싱을 통해 선택된 일부 애플리케이션 대신 모든 애플리케이션에 높은 수준의 가용성을 제공할 수 있습니다.

예측 가능성은 네트워크 기반 부하 분산 하드웨어에 의해 추가된 핵심 구성 요소입니다. 이제 새로운 연결이 어디로 향할지 예측하는 것이 훨씬 쉬워졌고 조작하기도 훨씬 수월해졌습니다. 이러한 장치는 프로세스에 지능을 추가하여 제어된 부하 분산(제어되지 않은 동적 DNS 분산과 대조적으로)을 만드는 데 도움이 되었습니다. 이를 통해 기업 소유자는 서버의 부하 처리 능력에 따라 부하를 서버에 분산할 수 있습니다.

네트워크 기반 로드 밸런서와 가상화의 등장으로 보안과 관리 측면에서 새로운 이점이 생겨났습니다. 예를 들어, 인터넷 커뮤니티에서 애플리케이션 서버의 신원을 가리고, 사용자에게 영향을 주지 않고 유지 관리를 위해 서버의 연결을 '블리딩'하여 오프라인으로 전환할 수 있는 기능을 제공합니다. 이것이 ADC가 유래된 기반입니다.

애플리케이션 제공 컨트롤러

중앙 로드 밸런싱 기능이자 풀 프록시 기능을 통해 IT 부서는 새롭고 떠오르는 서비스를 계층화하고 통합할 수 있는 좋은 장소를 찾았습니다. 이로 인해 로드 밸런싱 장치가 확장 가능한 ADC 플랫폼으로 발전하게 되었습니다. 간단히 말해서 프록시는 부하 분산의 기반이며 ADC를 가능하게 하는 기반 기술입니다.  

ADC 보안을 논의할 때, 프록시(기반 기술)로 만들어진 가상화가 중요합니다. SSL/TLS 암호화 오프로드, 중앙 집중식 인증, 심지어 애플리케이션에 유연한 방화벽에 대해 논의하든, 이러한 솔루션의 힘은 로드 밸런서(하드웨어 또는 가상 에디션)가 모든 애플리케이션에 걸친 가상화의 집계 지점이라는 사실에 있습니다. 중앙 집중식 인증이 전형적인 예이다. 기존의 인증 및 권한 부여 메커니즘은 항상 애플리케이션 자체에 직접 내장되어 있었습니다. 애플리케이션 기반 부하 분산과 마찬가지로, 각 구현은 각 애플리케이션의 구현에 따라 달라지고 고유하므로 다양하고 다양한 방법이 생겨났습니다. 대신 모든 애플리케이션의 가상화된 진입점에서 인증을 적용함으로써 단일하고 통일된 인증 방법을 적용할 수 있습니다. 이를 통해 인증 시스템의 설계 및 관리가 크게 간소화될 뿐만 아니라, 해당 기능을 수행할 필요성이 없어져 애플리케이션 서버 자체의 성능도 향상됩니다. 더욱이, 특히 자체 개발 애플리케이션의 경우 각각의 애플리케이션에서 인증 프로세스를 개발하는 데 시간과 비용을 투자할 필요성이 없어집니다.

가용성은 모든 기본 로드 밸런서 속성(확장성, 고가용성, 예측 가능성)과 관련이 있으므로 원래 로드 밸런서에 다시 연결하기 가장 쉬운 ADC 속성입니다. 하지만 ADC는 로드 밸런서보다 한 단계 더 발전했습니다. ADC의 가용성은 애플리케이션 종속성 및 동적 프로비저닝과 같은 고급 개념을 나타냅니다. ADC는 이제 애플리케이션이 자체 포함 방식으로 작동하는 경우가 거의 없다는 사실을 이해할 수 있습니다. 그들은 종종 다른 응용 프로그램을 사용하여 디자인을 구현합니다. 이러한 지식은 다른 프로세스도 고려하여 애플리케이션 가용성을 제공하는 ADC의 기능을 향상시킵니다. 시중에 나와 있는 가장 지능적인 ADC는 외부 입력에 따라 서비스 제공 방식을 동적으로 변경할 수 있는 프로그래밍 인터페이스도 제공합니다. 이러한 인터페이스는 클라우드와 컨테이너화된 배포와 같은 최신 환경에 필요한 동적 프로비저닝과 자동화된 확장/축소를 가능하게 합니다.

성능 향상은 부하 분산 개념의 또 다른 명백한 확장이었습니다. 로드 밸런서는 연결이 사용 가능한 서비스(그리고 허용 가능한 시간 프레임 내에 응답)로 전달될 뿐만 아니라 연결 수 및/또는 프로세서 사용률이 가장 낮은 서비스로 전달되도록 보장함으로써 애플리케이션의 성능을 본질적으로 개선합니다. 이를 통해 각각의 새로운 연결이 이를 가장 잘 처리할 수 있는 시스템에 의해 처리되도록 보장했습니다. 이후 SSL/TLS 오프로드(전용 하드웨어 사용)가 로드 밸런싱 서비스의 일반적인 기본이 되면서 암호화된 트래픽의 계산 오버헤드와 백엔드 서버의 부하가 줄어들어 성능도 향상되었습니다.

오늘날의 ADC는 한층 더 발전했습니다. 이러한 장치에는 캐싱, 압축, 심지어 속도 조절 기술까지 포함되어 있어 애플리케이션의 전반적인 성능과 전송 속도를 더욱 향상시킵니다. 또한 ADC는 이러한 서비스를 제공하는 기존 독립형 어플라이언스의 정적 구현이 아닌 고유한 애플리케이션 인텔리전스를 사용하여 성능상 이점이 있을 때만 이러한 서비스를 적용하므로 서비스 사용을 최적화할 수 있습니다.

예를 들어, 압축 기술 —일반적인 믿음과 달리—반드시 모든 애플리케이션 사용자에게 유익한 것은 아닙니다. 물론, 대역폭이 작은 사용자는 실제 처리량에서 병목 현상이 발생하기 때문에 더 작은 패킷에서 엄청난 이점을 얻을 수 있습니다. 먼 거리를 이동해야 하는 연결도 패킷이 작을수록 데이터를 전송하는 왕복 횟수가 줄어들어 네트워크 지연의 영향이 감소하므로 이점을 얻을 수 있습니다. 그러나 대역폭이 큰 단거리 연결(예: 같은 대륙 내)의 경우 압축을 적용하면 성능이 저하될 수 있습니다. 처리량이 반드시 병목 현상의 원인은 아니기 때문에 압축 및 압축 해제의 추가적인 오버헤드로 인해 지연 시간이 발생하는데, 이는 처리량 증가로 인해 성능 측면에서 메워질 수 없습니다. 다시 말해, 압축 기술을 적절히 관리하지 않으면 원래 문제보다 더 심각한 문제가 발생할 수 있습니다. 그러나 전반적인 성능에 도움이 될 때만 압축을 지능적으로 적용함으로써 ADC는 압축 기술의 사용과 비용을 최적화하고, 이를 통해 가장 많은 성능을 얻을 수 있는 기능에 더 많은 프로세서 주기를 할당할 수 있습니다.

세계는 어디로 향하고 있는가

디지털 혁신이 매우 중요한 전략적 명령이기 때문에 많은 기업이 클라우드로의 전환을 시작했습니다. 우리 주변의 세계를 변화시키는 애플리케이션의 수가 증가함에 따라 클라우드로 이동하는 조직은 더 큰 민첩성, 더 잘 정렬된 운영 비용, 주문형 확장성 및 핵심 비즈니스에 대한 더 많은 집중과 같은 많은 이점을 누릴 수 있을 것으로 믿어집니다.  

"클라우드"는 공유 컴퓨팅, 스토리지 및 네트워킹 리소스의 모호한 단일 엔터티가 아닙니다. 오히려 종종 여러 글로벌 노드에 배포되는 복잡한 공급자, 인프라, 기술 및 환경의 조합으로 구성됩니다. 이것이 많은 기업이 실제로 다양한 클라우드(공개, 비공개, 심지어 이 모든 것을 결합한 클라우드)에 애플리케이션을 배포한 이유입니다. 이것이 멀티 클라우드, 새로운 현실입니다.

이처럼 빠르게 변화하는 환경에도 불구하고, 여러 요인으로 인해 클라우드 도입이 늦어지고 있습니다. 첫 번째 과제는 멀티 클라우드 확산으로, 기존 애플리케이션이 "리프트 앤 시프트"되었고 "클라우드에서 탄생한" 애플리케이션이 계획되지 않고 관리되지 않는 방식으로 배포되었습니다. 또한 조직에서는 단기적인 요구 사항을 충족하기 위해 서로 다른 클라우드 플랫폼, 서로 다른 아키텍처, 다양한 애플리케이션 서비스, 여러 툴셋을 사용하는 경향이 있습니다. 이로 인해 기업 전체에 아키텍처가 복잡해지고, 한 환경에서 다른 환경으로 애플리케이션을 전환하는 것이 훨씬 더 어려워지며, 비용도 많이 듭니다.

각 클라우드 아키텍처는 운영 방식, 관리 방식, 가시성 수준이 다릅니다.
그림 3: 각 클라우드 아키텍처는 운영 방식, 관리 방식, 가시성 수준이 다릅니다.

이러한 과제에도 불구하고, 향후 몇 년 안에 퍼블릭 및 프라이빗 클라우드에서 새로운 배포가 불가피하게 증가할 것입니다. 멀티 클라우드가 빠르게 다가오고 있으며, 기업이 제한된 애플리케이션을 지원하는 것 이상의 기능을 제공하거나 하드웨어와 단일 클라우드에서만 작동하는 스마트 애플리케이션 서비스와 ADC를 배포해야 할 때입니다.

요약

ADC는 과거 로드 밸런서가 차지했던 중요한 네트워크 자산에 대한 자연스러운 진화입니다. ADC는 이러한 오래된 장치로부터 많은 도움을 받았지만, 단순히 가용성뿐만 아니라 성능과 보안까지 제공하는 완전히 새로운 종류입니다. 이름에서 알 수 있듯이, 그들은 가능한 한 최상의 방법으로 애플리케이션을 전달하는 모든 측면에 관심을 둡니다.

애플리케이션 인텔리전스, SSL 오프로드, 프로그래밍 인터페이스와 같은 고급 기능을 갖춘 최신 ADC는 조직이 비즈니스를 확장하고 언제 어디서나 사용자에게 도달할 수 있도록 지원합니다. 끊임없이 변화하는 기술 세계의 요구 사항에 따라 ADC도 멀티 클라우드 및 컨테이너 환경의 최신 기술에 적응할 수 있는 능력이 더욱 향상되었습니다.

결국, ADC는 애플리케이션을 더 빠르고 스마트하고 안전한 방식으로 제공하는 주요 통로이자 통합 지점일 뿐만 아니라, 계속해서 발전하여 클라우드 중심 세계를 수용할 것이라고 안전하게 말할 수 있습니다. 

2017년 9월 10일 게시
  • 페이스북에 공유하기
  • X에 공유
  • Linkedin에 공유하기
  • 이메일로 공유하기
  • AddThis를 통해 공유

F5에 연결

F5 Labs

최신 애플리케이션 위협 인텔리전스입니다.

DevCentral

토론 포럼과 전문가 기사를 제공하는 F5 커뮤니티입니다.

F5 뉴스룸

뉴스, F5 블로그 등.