[번역] Controller vs. Instance Manager - Why You Should Look Under the Hood of your Load Balancer

출처 : https://blog.avinetworks.com/controller-vs-instance-manager-why-you-should-look-under-the-hood-of-your-load-balancer

로드 밸런서와 함께 일한다면, 아마 최근에 "컨트롤러"라는 말을 들어본 적이 있을 것이다. 기업들은 증가하는 애플리케이션 수를 따라잡기 위해 로드 밸런서 설치 공간을 크게 늘려야 했다. 컨트롤러는 데이터 센터와 클라우드 전반에 걸쳐 로드 밸런싱 장치의 관리 및 라이프사이클을 자동화하는 방법이다. 하지만 문제는, F5 네트워크, Citrix, NGINX와 같은 로드 밸런싱 벤더는 컨트롤러를 가지고 있지 않다는 겁니다. 그들에게는 인스턴스 관리자가 있다. 그 차이를 탐구해 봅시다.

하드웨어 및 소프트웨어 로드 밸런싱 어플라이언스 기저 아키텍처는 90년대 후반과 2000년대 초반에 클라우드 이전과 컨테이너 이전에 개발되었다. 각 어플라이언스에는 통합 제어면과 데이터 평면이 있다. 제어면은 각 개별 어플라이언스의 트래픽 관리, 보안 및 정책 기능을 조절할 수 있는 곳이다. 그리고 데이터 평면은 단순히 교통을 운반한다.

Appliance-Load-Balancer-Architecture.png

대부분의 소프트웨어 로드 밸런서는 각 어플라이언스에 고유한 제어면과 데이터 평면을 사용하여 동일한 아키텍처를 공유한다.

Hardware-and-Software-Appliance-Load-Balancer-Architecture.png

예를 들어 조직에서 데이터 센터와 클라우드에 50개의 로드 밸런서 어플라이언스(하드웨어 또는 가상, 상관 없음)를 가지고 있으며 개별적으로 관리해야 하는 50개의 제어기가 있다고 가정해 보십시오. 상상할 수 있듯이, 이것은 약간 골칫거리다. 따라서 로드 밸런싱 벤더는 로드 밸런싱 장치 관리를 돕기 위해 인스턴스 관리자를 지원했다. F5에는 BIG-IQ, Citrix에는 ADM, NGINX에는 컨트롤러 2.0이 있다.

Load-Balancer-Instance-Manager-Architecture.png

이러한 인스턴스 관리자는 기본적으로 SSH 또는 각 어플라이언스에 연결하여 트래픽 관리, 보안 및 정책 명령을 구성할 수 있다. 제어기는 여전히 각 개별 장비에 상주한다. 그리고 당신(관리자)은 여전히 그 작전의 두뇌들이다. 별로 변한 것이 없다. 예를 들어, 여러분은 여전히 운영의 두되다. "내가 이 환경에 부하 분산 장치를 배치하고 있는가?"와 같은 질문을 스스로에게 던져야 한다. 이 로드 밸런싱 장치에 용량이 있는지 여부, 이 로드 밸런서가 인스턴스 관리자와 함께 작동하도록 구성되었는가?" 로드 밸런서가 아직 배포되지 않았거나 새 로드 밸런서를 배포해야 하는 경우 인스턴스 관리자가 도와줄 수 없다. 수동으로 로드 밸런서를 환경에 배포하고, 로드 밸런서를 설치할 호스트를 식별하고, 인스턴스 관리자를 통해 구성해야 한다.

"애완동물 대 가축"의 비유에 익숙하다면 어플라이언스 로드밸런서는 애완동물이다. 그들은 당신이 그들의 존재를 정당화하기 위해 교통수단을 가지고 있는지 여부에 관계없이 손으로 먹이를 주고 보살펴야 한다. 인스턴스 매니저는 중앙 집중식 대시보드에서 각 어플라이언스의 관리 및 수유 관리를 단순히 도와준다. 그리고 그것은 여전히 많은 일이다.

가상 및 베어 메탈 환경에서 기존 애플리케이션에 쉽게 적용할 수 있지만, Avi Networks는 클라우드와 컨테이너 시대에 태어났다. Avi는 제어면을 로드 밸런서와 완전히 분리했기 때문에 다르다. 서비스 엔진이라고 불리는 로드 밸런서는 데이터 평면에 상주하며 모든 환경에 걸쳐 애플리케이션 서비스를 위해 중앙 집중화된 두뇌에서 모든 명령을 취한다. 두뇌는 Avi Controller다. 그리고 SDN 컨트롤러나 쿠버넷 컨트롤러처럼 작동하기 때문에 그렇게 불린다.

기존 리소스만 관리할 수 있는 인스턴스 관리자와는 달리 Avi 컨트롤러는 새로운 서비스 엔진을 가동하고 기계 학습을 활용하여 애플리케이션 및 네트워크 컨텍스트 변화에 예측적으로 대응할 수 있다. 아까 언급했던 운영의 두뇌가 기억나는가? 이제 모든 것이 사라졌다. 환경에 로드 밸런서가 없는 경우 Avi Controller가 배치해 준다. 당신은 심지어 어디에 어떤 호스트인지 말할 필요도 없다. 로드 밸런싱 장치에 용량이 있는지 여부 상관없다. 다시, Avi Controller는 당신의 필요에 따라 스케일 업/다운될 것이다.

AviArchitectureGIF.gif

"애완동물 대 가축"의 비유에서 Avi의 서비스 엔진은 가축이다. 그들을 관리하는 것에 대해 별로 생각하지 않을 것이다. 그건 Avi Controller의 일이다. Avi는 컨트롤러가 관리하는 액티브 로드 밸런싱 패브릭이다. 사용 대기 중인 액티브 스탠바이 쌍이나 과도하게 프로비저닝된 로드 밸런서는 없다. 그리고 고장이 발생할 경우 Avi 컨트롤러는 애플리케이션이 가용 인스턴스가 아닌 의도에 따라 필요한 서비스를 제공받도록 함으로써 고가용성을 유지하도록 자체 복구한다. Avi 컨트롤러(소프트웨어라는 사실이 아님)는 우리를 특별하고 무자비하게 효율적으로 만든다.

로드 밸런싱 산업은 수십 년 동안 휴면 상태였지만, 애플리케이션 아키텍처와 멀티 클라우드 환경의 발전으로 기업들은 로드 밸런싱 공급자를 재평가하지 않을 수 없게 되었다. 많은 벤더가 컨트롤러를 보유하고 있다고 주장하는 것은 현대 애플리케이션을 지원하는 이 아키텍처 모델에 대한 고객의 요구를 인정하는 것이다. 하지만 이 제품들 중 많은 것들이 실제로 그 양을 재지 못한다. 벤더가 컨트롤러를 가지고 있다고 주장할 경우 다음과 같은 간단한 질문을 하십시오.

  1. 컨트롤러가 모든 로드 밸런서에 가상 서비스를 자동으로 배치하고 모든 데이터 센터 또는 클라우드의 풀 서버에 대한 연결을 풀링할 수 있는가?
  2. 제어기가 액티브 스탠바이 어플라이언스 없이도 로드 밸런서를 자동으로 치료/복구할 수 있는가?
  3. 실시간 트래픽 패턴을 기반으로 로드 밸런싱 용량을 자동으로 스케일업 또는 스케일다운할 수 있는가?

이 기능이 없으면 로드 밸런싱 장치가 비즈니스에 보조를 맞출 수 없다.