클라우드 지원 ADC

로리 맥비티

2016년 12월 5일 게시

클라우드 지원 애플리케이션 제공 컨트롤러(ADC)는 기존의 ADC가 아닙니다. 사용자 지정 또는 COTS 하드웨어에 배포할 수 있으며, 빠르고 안전하며 사용 가능한 애플리케이션 제공 및 배포에 대한 필요성을 모두 지원하는 확장 가능한 소프트웨어 솔루션입니다. 클라우드 지원 ADC는 기존의 안정성, 보안 및 확장성과 현대적이고 유연하며 클라우드와 DevOps 친화적인 프로그래밍 기능을 결합하여 데이터 센터 아키텍처에 대한 현대적이고 2계층적인 접근 방식을 구현합니다.

좋은 설명이네요. 하지만 무슨 뜻인가요?

저는 이전에 현대적 앱 프록시 로 간주되는 데 필요한 것에 대해 글을 쓴 적이 있으며, 그것은 클라우드 지원 ADC에 필요한 것의 일부임이 분명합니다. 하지만 오늘날의 까다로운 환경에는 기술적 역량 그 이상이 필요합니다. 운영 및 생태계 통합과 현대적이고 새로운 애플리케이션 아키텍처를 지원하는 능력이 필요합니다.

솔직히 말해서, 클라우드 지원 및 기존 애플리케이션 아키텍처와 새로운 애플리케이션 아키텍처 모두에 대한 지원을 주장하는 ADC가 많이 있습니다. 그래서 오늘은 오늘날의 애플리케이션 세계에서 왜 클라우드 지원 ADC가 중요한지 더 자세히 알아보기 전에, 클라우드 지원 ADC가 기존 ADC와 어떻게 다른지 살펴보겠습니다.

5단계의 차별화

클라우드 지원 ADC가 기존 ADC와 차별화되는 데는 기본적으로 5가지(정말로 까다롭게 말하자면 6가지)의 다른 방식이 있습니다. 그리고 F5가 제가 여기 오기 훨씬 전부터 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는 오랫동안 기본적인 애플리케이션 보안을 제공해 왔습니다. 앱, 특히 웹 앱 앞에 앉아 있으면, 해당 앱이 데이터 센터에서 공격을 인식하고 조치를 취할 수 있는 첫 번째 수단이 됩니다(지금도 그렇습니다). 대부분의 보안은 당연히 프로토콜 수준의 보안을 중심으로 이루어졌습니다. SYN 플러드 보호, DDoS 감지, 기타 TCP 및 기본 HTTP 관련 보안 옵션은 오랫동안 기존 ADC의 일부로 포함되어 왔습니다.

하지만 클라우드 지원 ADC는 더 나아갈 것입니다. 오늘날의 애플리케이션에 필요한 불가피한 규모를 보장하기 위해 앱 아키텍처 자체에 포함된 몇 안 되는 "장치" 중 하나가 될 가능성이 높으므로 전체 스택 보안에 초점을 맞추는 것이 합리적입니다. 적어도 우리는 그렇게 생각합니다. 특히 그렇게 하면 성과가 좋아지니까요. 어떤 종류의 처리를 위해 멈춰야 한다면, 가능한 한 많은 일을 동시에 하는 것이 합리적입니다. 더 효율적이며 박스에서 박스로 이동하는 데 필요한 대기 시간을 제거합니다. 아이들과 함께 먼 거리를 여행해 본 사람이라면 제가 무슨 말을 하는지 아실 겁니다. 주유소에는 화장실이 있습니다. 5분 후에 다시 휴게소에 들르고 싶지는 않을 거예요, 그렇죠? 네트워크의 보안도 마찬가지입니다. 고객과 기업 모두에게 좌절감을 주는 경우가 많은 간접비를 없애기 위해 한 번에 할 수 있는 일을 최대한 많이 하세요. 성능이 매우 중요하며, 클라우드 지원 ADC는 더 빠른 앱 경험을 보장하기 위해 최선을 다해야 합니다.

즉, 모바일 기기와 앱 간의 안전한 통신을 지원하려는 증가하는 수요(그리고 어떤 경우에는 요구 사항)를 관리하기 위한 새로운 모델을 제공해야 한다는 의미일 수도 있습니다. 즉, FS(Forward Secrecy)와 이를 가능하게 하는 암호화에 대한 지원을 의미합니다. 이는 마이크로서비스와 새로운 애플리케이션을 지원하는 데 필요한 아키텍처를 손상시키지 않으면서 암호화 및 복호화의 컴퓨팅 비용이 높은 처리를 이를 처리하도록 설계된 하드웨어로 오프로드하는 새로운 모델을 구현하는 것을 의미합니다. 클라우드에 적합한 ADC는 두 가지 모두를 지원하여 빠르고 안전한 통신을 구현하는 동시에 오늘날의 아키텍처와 클라우드 환경에 원활하게 적용되어야 합니다.

파트너 에코시스템 및 자동화

다른 API 경제는 프라이빗 클라우드의 성공과 자동화 및 오케스트레이션 증가를 통해 비즈니스에 제공되는 경쟁 우위에 매우 중요합니다. 하지만 아무리 좋더라도 데이터 센터에는 항상 다양한 공급업체가 제공하는 다양한 서비스가 존재하며, 각 서비스는 서로 다른 통합 및 객체 모델을 가지고 있습니다. 이는 모든 필수 구성 요소에 대한 전문 지식이 필요한 고통스러운 API 기반 자동화를 의미합니다. 현실적으로 두 가지 수준의 통합이 필요합니다. 하나는 오케스트레이션을 위한 것이고 다른 하나는 자동화를 위한 것입니다 (아니요, 이 둘은 같은 것이 아닙니다) . API와 템플릿을 통한 플랫폼의 고유한 자동화 기능이 있으며, 파트너 생태계와의 기본 통합이 뛰어나 오케스트레이션이 최고입니다. 둘 다 클라우드 지원 ADC에 필요합니다. 전자는 Puppet 및 Chef와 같은 독점 제품 또는 사용자 정의 스크립트 및 프레임워크를 통해 자동화를 보장하는 반면, 후자는 OpenStack, VMware 및 Cisco와 같은 점점 더 중요해지는 컨트롤러를 통해 오케스트레이션을 가능하게 합니다.

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

클라우드 지원 ADC가 클라우드 템플릿을 지원해야 한다는 것은 두 번 이상 말할 필요가 없을 것입니다.

그러니 제가 그 문제에 대해 말할 것은 전부입니다.

앱 모델

기존 ADC는 기존 애플리케이션에 대한 견고한 서비스 세트를 제공해야 한다는 필요성에서 탄생했습니다. 말하자면 거석(monolith)이죠. 오늘날의 애플리케이션은 점점 더 분산되고 다양해지고 있으며, 기존의 애플리케이션과 비교해 더욱 다르고 다양한 아키텍처, 플랫폼 및 배포 모델을 활용하고 있습니다. 컨테이너든 가상 머신이든, 클라우드든 클라우드와 유사한 환경이든, 애플리케이션에는 여전히 일부 서비스가 필요합니다. 그리고 한 번에 여러 서비스가 필요한 경우(예: 로드 밸런싱 및 앱 보안) ADC가 필요합니다. 기존 ADC는 마이크로서비스에 적합하지 않을 수 있지만 클라우드 지원 ADC는 적합합니다. 여기에는 로드 밸런싱 및 보안의 이점을 얻을 수 있는 보다 광범위한 서비스, memcached 와 같이 netops가 아닌 devops의 영역에 속하는 서비스가 포함됩니다.

여전히 플랫폼이기는 하지만 클라우드 지원 ADC는 기존 앱과 새로운 앱에 필요한 서비스를 필요한 환경에서 제공하는 데 필요한 프로그래밍 가능성, 통합 및 폼 팩터 요구 사항을 지원합니다.

기존 ADC와 클라우드 지원 ADC 사이에는 많은 유사점이 있습니다. 둘 다 여전히 플랫폼이며, 공통된 운영 모델로 여러 서비스를 활성화할 수 있습니다. 두 제품 모두 프로그래밍이 가능하고, 다른 데이터 센터 및 클라우드 시스템과 통합되며 성능 기능에 있어 유연성을 제공합니다. 그러나 클라우드 지원 ADC는 기존 방식을 한 단계 더 발전시켜 두 가지 모두를 지원하는 동시에 다양한 인프라와 환경과 통합하고 상호 운용해야 하는 비즈니스, 애플리케이션의 미래와 점점 더 다양해지는 요구 사항을 충족합니다.