클라우드 지원 ADC

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

클라우드 지원 애플리케이션 전송 컨트롤러(ADC)는 기존의 전통적인 ADC와는 다릅니다. 맞춤형 또는 상용 기성품(COTS) 하드웨어에 배포할 수 있는 확장 가능한 소프트웨어 솔루션으로, 애플리케이션을 빠르고 안전하며 안정적으로 전송하고 배포해야 하는 요구 사항을 모두 지원합니다. 클라우드 지원 ADC를 사용하면 기존의 안정성, 보안 및 확장성과 현대적이고 유연하며 클라우드 및 DevOps 친화적인 프로그래밍 기능을 결합한 최신 2계층 방식의 데이터 센터 아키텍처를 구현할 수 있습니다.

그럴듯한 설명이지만, 그게 무슨 뜻일까요?

저는 이전에 어떤 요건을 갖춰야 최신 앱 프록시로 인정받을 수 있는지에 대해 쓴 적이 있습니다. 이는 분명 클라우드 지원 ADC에 필요한 요소 중 하나이지만, 오늘날의 까다로운 환경에서는 단순한 기술 역량만으로는 부족합니다. 운영 및 에코시스템과의 통합은 물론, 최신 애플리케이션 아키텍처와 새롭게 부상하는 애플리케이션 아키텍처를 지원할 수 있는 역량도 필요합니다.

솔직히 말해, 시중의 많은 ADC도 클라우드 지원과 기존 및 새로운 애플리케이션 아키텍처 지원을 비롯해 이와 유사한 주장을 내세울 것입니다. 따라서 오늘은 클라우드 지원 ADC가 기존 ADC와 어떻게 다른지 먼저 자세히 살펴본 다음, 오늘날의 애플리케이션 환경에서 이것이 왜 그토록 중요한지 더 깊이 알아보겠습니다.

차별화의 다섯 가지 요소

기본적으로 클라우드 지원 ADC가 기존 ADC와 차별화되는 방식은 다섯 가지(아주 엄밀히 따지자면 여섯 가지)입니다. 그리고 제가 합류하기 훨씬 전부터 F5가 ADC의 기준을 사실상 정립해 왔기 때문에, 저희는 누구보다 ADC를 잘 이해하고 있습니다. 과거에 ADC가 어떤 모습이어야 했는지는 물론, 비즈니스에 필요한 속도, 보안, 안정성을 갖춰 애플리케이션을 지속적으로 제공하려면 앞으로 어떻게 발전해야 하는지도 잘 알고 있습니다.

성능

이건 너무나 당연한 이야기죠. 결국 애플리케이션 앞단에서 프록시 역할을 하려면, 제공하는 애플리케이션만큼 빠르거나 그보다 더 빨라야 합니다. 기존 ADC는 어플라이언스 폼 팩터로 제공됩니다. 섀시, 하드웨어, 어플라이언스 형태로 말이죠. 하지만 기존 ADC는 사용할 수밖에 없는 맞춤형 하드웨어의 CPU 성능에 제약을 받아 왔습니다. ADC는 플랫폼이므로, 범용 CPU가 전반적인 처리 성능에 초점을 맞추듯 전반적인 속도 향상에 주력해 왔습니다. 그러나 거의 항상 다양한 하드웨어 가속 옵션이 포함되며, 이러한 옵션은 배포 전에 결정해야 합니다. 다소 무리한 생각일 수도 있지만, 클라우드 지원 ADC라면 이러한 한계를 뛰어넘어야 한다고 생각합니다. 한 애플리케이션은 특정 서비스가 더 많이 필요할 수 있고, 다른 애플리케이션은 또 다른 서비스가 더 많이 필요할 수 있다는 점을 이해해야 합니다. 클라우드 컴퓨팅이라는 개념 전체를 뒷받침하는 핵심이 필요에 따라 컴퓨팅 리소스의 용도를 전환하는 것인 만큼, 어떤 종류든 하드웨어에 투자한 조직이라면 그 하드웨어의 용도 역시 전환할 수 있어야 합니다.

네트워크 상위 계층에서 제공되는 서비스에서 이것이 중요한 이유는, 일반적인 작업을 특정 하드웨어(FPGA)에 오프로딩하면 CPU가 요청/응답 검사, 수정, 정제 등의 다른 작업을 수행할 수 있기 때문입니다. 그러면 프록시에서 이루어지는 전체 처리 과정이 빨라져 지연 시간이 줄어들고 사용자 만족도가 높아집니다.

그렇기 때문에 클라우드 지원 ADC는 소프트웨어 정의 성능을 활용하고, 보안과 같은 특정 유형의 처리에 대해 조직이 프로그래밍 방식으로 ADC의 성능을 높일 수 있도록 함으로써 기존의 한계를 뛰어넘을 수 있습니다. 즉, 조직의 요구 사항이 바뀌면 해당 하드웨어의 성능 프로파일도 필요에 따라 함께 변경할 수 있습니다. 이것이 바로 하드웨어의 민첩성입니다. 역설적으로 들리시죠? 하지만 이것이 클라우드 지원 ADC의 특징 중 하나입니다. 특수 하드웨어의 용도를 변경할 수 있어 기존 투자를 보호하고, 비용이 많이 드는 전면적인 장비 교체 업그레이드의 필요성을 없앨 수 있습니다.

프로그래밍 가능성

제가 고객들로부터 오랫동안 반복해서 들어온 불만 중 하나는 스크립팅 기능을 둘러싼 NetOps와 DevOps 간의 불협화음이었습니다. 문제는 기존 ADC가 가장 기본적인 수준의 스크립팅만 지원했으며, 사용 언어도 DevOps보다 NetOps에 더 익숙한 언어였다는 점입니다. DevOps는 데이터 경로에서 스크립팅을 활용하면 더욱 민첩한 다양한 요청/응답 라우팅과 확장 전략은 물론 보안 서비스까지 구현할 수 있었기 때문에 이를 기꺼이 배우려 했습니다. 하지만 기존 ADC가 업스트림의 코어 네트워크에 자리 잡고 있는 상황에서 NetOps는 트래픽 흐름을 망가뜨릴 수도 있는 스크립트를 DevOps가 배포하도록 허용할 생각이 없었습니다.

가상 에디션이 제공되면서 DevOps는 가상 머신 형태의 개인 전용 ADC를 사용할 수 있게 되었지만, 여전히 네트워크 중심의 스크립팅 언어를 배워야 했습니다. 이는 바람직하지 않습니다. 클라우드 지원 ADC라면 코어 네트워크의 NetOps와 클라우드 같은 애플리케이션 네트워크의 DevOps를 모두 지원해야 합니다. 특히 DevOps와 개발자는 node.js처럼 개발자에게 친숙한 언어를 선호합니다. 단지 해당 언어를 알고 있기 때문만이 아니라, 개발자 친화적인 인프라와 더 빠르게 통합할 수 있도록 지원하는 풍부한 라이브러리 저장소(예: NPM)와 서비스가 이미 존재하기 때문입니다. 따라서 클라우드 지원 ADC는 양쪽 모두를 지원해야 합니다.

앱 보안

기존 ADC는 오랫동안 기본적인 애플리케이션 보안 기능을 제공해 왔습니다. ADC는 애플리케이션, 특히 웹 애플리케이션의 앞단에 위치하기 때문에 일반적으로 데이터 센터에서 공격을 가장 먼저 인식하고 대응할 수 있는 요소였으며, 지금도 마찬가지입니다. 이러한 보안 기능의 대부분은 당연히 프로토콜 수준의 보안에 중점을 두었습니다. SYN 플러드 방어, DDoS 탐지, 기타 TCP 및 기본 HTTP 관련 보안 옵션은 이미 오래전부터 기존 ADC의 핵심 기능으로 자리 잡았습니다.

하지만 클라우드 지원 ADC는 여기서 한 걸음 더 나아가야 합니다. 오늘날의 애플리케이션에 필연적으로 요구되는 확장성을 보장하려면 ADC가 애플리케이션 아키텍처 자체에 포함되는 몇 안 되는 "장치" 중 하나가 될 가능성이 높으므로, 풀 스택 보안에도 그에 상응하는 초점을 맞추는 것이 합리적입니다. 적어도 저희는 그렇게 생각하며, 특히 이것이 성능 향상에도 도움이 되기 때문입니다. 어떤 처리를 위해 한 번 멈춰야 한다면, 그때 가능한 한 많은 작업을 동시에 수행하는 것이 합리적입니다. 이렇게 하면 효율성이 높아지고 여러 장비를 차례로 거치면서 발생하는 지연 시간도 줄일 수 있습니다. 아이들과 장거리 여행을 해본 적이 있다면 무슨 말인지 아실 겁니다. 주유소에 화장실이 있는데 5분 뒤 휴게소에 또 들르고 싶지는 않겠죠? 네트워크 보안도 마찬가지입니다. 한 번에 최대한 많은 작업을 처리해 고객과 기업 모두에게 불편을 초래하는 오버헤드를 줄여야 합니다. 성능은 매우 중요하며, 클라우드 지원 ADC는 더 빠른 애플리케이션 경험을 보장하기 위해 할 수 있는 모든 일을 해야 합니다.

이는 모바일 디바이스와 앱 간의 보안 통신 지원에 대한 증가하는 수요(경우에 따라서는 필수 요건)를 관리하기 위한 새로운 모델을 제공하는 것을 의미할 수 있습니다. 또한 순방향 비밀성(FS)과 이를 구현하는 암호화 기술을 지원해야 한다는 뜻입니다. 마이크로서비스와 새로운 애플리케이션을 지원하는 데 필요한 아키텍처를 훼손하지 않으면서, 연산 비용이 많이 드는 암호화 및 복호화 처리를 이에 특화된 하드웨어로 오프로드하는 새로운 모델도 구현해야 합니다. 클라우드 지원 ADC는 이 두 가지를 모두 지원하여 빠르고 안전한 통신을 제공하는 동시에 오늘날의 아키텍처와 클라우드 환경에 원활하게 통합되어야 합니다.

파트너 생태계 및 자동화

또 다른 API 경제는 프라이빗 클라우드의 성공과 자동화 및 오케스트레이션의 확대로 기업이 얻는 경쟁 우위에 매우 중요합니다. 하지만 아무리 바람직하더라도 데이터 센터에는 서로 다른 공급업체가 제공하는 다양한 서비스가 항상 존재하며, 각 서비스의 통합 방식과 객체 모델도 모두 다릅니다. 이로 인해 필요한 모든 구성 요소에 대한 전문 지식을 요구하는 까다로운 API 기반 자동화가 필요한 경우가 많습니다. 실제로는 두 가지 수준의 통합이 필요합니다. 하나는 오케스트레이션을 위한 것이고, 다른 하나는 자동화를 위한 것입니다 (둘은 같은 개념이 아닙니다). 플랫폼에는 API와 템플릿을 통한 자체 자동화 기능이 있으며, 오케스트레이션이 핵심적인 역할을 하는 파트너 에코시스템과의 네이티브 통합도 있습니다. 클라우드 지원 ADC에는 이 두 가지가 모두 필요합니다. 전자는 독점 제품이나 사용자 지정 스크립트, Puppet 및 Chef 같은 프레임워크를 통한 자동화를 보장하고, 후자는 OpenStack, VMware, Cisco처럼 중요성이 점점 커지는 컨트롤러를 통한 오케스트레이션을 지원합니다.

클라우드 지원 ADC는 포괄적인 오케스트레이션 솔루션을 제공하는 데 사용되는 프레임워크 및 시스템과 기본적으로 통합되고, 이를 통해 오케스트레이션 기능을 제공해야 합니다.

클라우드 지원 ADC가 클라우드 템플릿을 지원해야 한다는 점은 두말할 필요가 없습니다.

그러니 그 점에 대해서는 이만 말하겠습니다.

앱 모델

기존 ADC는 전통적인 애플리케이션에 강력한 서비스 세트를 제공해야 한다는 필요에서 탄생했습니다. 말하자면 모놀리식 애플리케이션을 위한 것이었습니다. 오늘날의 애플리케이션은 다양한 아키텍처, 플랫폼 및 배포 모델을 활용하면서 기존 애플리케이션보다 점점 더 분산되고 다양해지며 차별화되고 있습니다. 컨테이너든 가상 머신이든, 클라우드든 클라우드와 유사한 환경이든, 애플리케이션에는 여전히 이러한 서비스 중 일부가 필요합니다. 그리고 한 번에 둘 이상의 서비스(예를 들어 로드 밸런싱과 애플리케이션 보안)가 필요한 경우에는 ADC도 필요합니다. 기존 ADC는 마이크로서비스에 적합하지 않을 수 있지만, 클라우드 지원 ADC라면 적합합니다. 여기에는 로드 밸런싱과 보안의 이점을 누릴 수 있는 더 광범위한 서비스가 포함되며, 이러한 서비스는 NetOps가 아닌 DevOps의 영역에 속합니다. 예를 들면 memcached가 있습니다.

클라우드 지원 ADC는 여전히 플랫폼이지만, 기존 애플리케이션과 새로운 애플리케이션 모두에 필요한 서비스를 각 애플리케이션이 요구하는 환경에서 제공하는 데 필수적인 프로그래밍 기능, 통합 및 폼 팩터 요건을 지원합니다.

기존 ADC와 클라우드 지원 ADC는 유사한 점이 많습니다. 둘 다 공통 운영 모델을 통해 여러 서비스를 지원할 수 있는 플랫폼입니다. 또한 프로그래밍이 가능하고, 다른 데이터 센터 및 클라우드 시스템과 통합되며, 성능 역량을 유연하게 조정할 수 있습니다. 하지만 클라우드 지원 ADC는 기존 ADC의 범위를 넘어 기존 환경을 지원하는 동시에 비즈니스와 애플리케이션의 미래를 뒷받침하며, 갈수록 다양해지는 요구에 맞춰 폭넓은 인프라 및 환경과 통합되고 상호 운용될 수 있도록 합니다.

작성자 소개

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

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

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