https://blog.avinetworks.com/controller-vs-instance-manager-why-you-should-look-under-the-hood-of-your-load-balancer
로드 밸런서와 함께 일한다면, 아마 최근에 “Controller”라는 말을 들어본 적이 있을 것이다. 기업들은 증가하는 애플리케이션 수를 따라잡기 위해 로드 밸런서 설치 공간을 크게 늘려야 했다. 컨트롤러는 데이터 센터와 클라우드 전반에 걸쳐 로드 밸런싱 장치의 관리 및 라이프사이클을 자동화하는 방법이다. 하지만 문제는, F5 네트워크, Citrix, NGINX와 같은 로드 밸런싱 벤더는 컨트롤러를 가지고 있지 않다는 겁니다. 그들에게는 Instance Manager가 있다. 그 차이를 탐구해 봅시다.
하드웨어 및 소프트웨어 로드 밸런싱 어플라이언스 기저 아키텍처는 90년대 후반과 2000년대 초반에 클라우드 이전과 컨테이너 이전에 개발되었다. 각 어플라이언스에는 통합 제어면과 데이터 평면이 있다. 제어면은 각 개별 어플라이언스의 트래픽 관리, 보안 및 정책 기능을 조절할 수 있는 곳이다. 그리고 데이터 평면은 단순히 교통을 운반한다.
대부분의 소프트웨어 로드 밸런서는 각 어플라이언스에 고유한 제어면과 데이터 평면을 사용하여 동일한 아키텍처를 공유한다.
예를 들어 조직에서 데이터 센터와 클라우드에 50개의 로드 밸런서 어플라이언스(하드웨어 또는 가상, 상관 없음)를 가지고 있으며 개별적으로 관리해야 하는 50개의 제어기가 있다고 가정해 보십시오. 상상할 수 있듯이, 이것은 약간 골칫거리다. 따라서 로드 밸런싱 벤더는 로드 밸런싱 장치 관리를 돕기 위해 Instance Manager를 지원했다. F5에는 BIG-IQ, Citrix에는 ADM, NGINX에는 Controller 2.0이 있다.
이러한 Instance Manager 관리자는 기본적으로 SSH 또는 각 어플라이언스에 연결하여 트래픽 관리, 보안 및 정책 명령을 구성할 수 있다. 제어기는 여전히 각 개별 장비에 상주한다. 그리고 당신(관리자)은 여전히 그 작전의 두뇌들이다. 별로 변한 것이 없다. 예를 들어, 여러분은 여전히 운영의 두뇌다. “내가 이 환경에 부하 분산 장치를 배치하고 있는가?”와 같은 질문을 스스로에게 던져야 한다. 이 로드 밸런싱 장치에 용량이 있는지 여부, 이 로드 밸런서가 인스턴스 관리자와 함께 작동하도록 구성되었는가?” 로드 밸런서가 아직 배포되지 않았거나 새 로드 밸런서를 배포해야 하는 경우 인스턴스 관리자가 도와줄 수 없다. 수동으로 로드 밸런서를 환경에 배포하고, 로드 밸런서를 설치할 호스트를 식별하고, 인스턴스 관리자를 통해 구성해야 한다.
“pets vs. cattle”의 비유에 익숙하다면 어플라이언스 로드밸런서는 애완동물이다. 그들은 당신이 그들의 존재를 정당화하기 위해 교통수단을 가지고 있는지 여부에 관계없이 손으로 먹이를 주고 보살펴야 한다. 인스턴스 매니저는 중앙 집중식 대시보드에서 각 어플라이언스의 관리 및 수유 관리를 단순히 도와준다. 그리고 그것은 여전히 많은 일이다.
가상 및 베어 메탈 환경에서 기존 애플리케이션에 쉽게 적용할 수 있지만, Avi Networks는 클라우드와 컨테이너 시대에 태어났다. Avi는 제어면을 로드 밸런서와 완전히 분리했기 때문에 다르다. Service Engine이라고 불리는 로드 밸런서는 데이터 평면에 상주하며 모든 환경에 걸쳐 애플리케이션 서비스를 위해 중앙 집중화된 두뇌에서 모든 명령을 취한다. 두뇌는 Avi Controller다. 그리고 SDN 컨트롤러나 쿠버넷 컨트롤러처럼 작동하기 때문에 그렇게 불린다.
기존 리소스만 관리할 수 있는 인스턴스 관리자와는 달리 Avi Controller는 새로운 Service Engine을 가동하고 기계 학습을 활용하여 애플리케이션 및 네트워크 컨텍스트 변화에 예측적으로 대응할 수 있다. 아까 언급했던 운영의 두뇌가 기억나는가? 이제 모든 것이 사라졌다. 환경에 로드 밸런서가 없는 경우 Avi Controller가 배치해 준다. 당신은 심지어 어디에 어떤 호스트인지 말할 필요도 없다. 로드 밸런싱 장치에 용량이 있는지 여부 상관없다. 다시, Avi Controller는 당신의 필요에 따라 스케일 업/다운될 것이다.
“애완동물 대 가축(pets vs. cattle)”의 비유에서 Avi의 Service Engine은 가축이다. 그들을 관리하는 것에 대해 별로 생각하지 않을 것이다. 그건 Avi Controller의 일이다. Avi는 컨트롤러가 관리하는 액티브 로드 밸런싱 패브릭이다. 사용 대기 중인 액티브 스탠바이 쌍이나 과도하게 프로비저닝된 로드 밸런서는 없다. 그리고 고장이 발생할 경우 Avi Controller는 애플리케이션이 가용 인스턴스가 아닌 의도에 따라 필요한 서비스를 제공받도록 함으로써 고가용성을 유지하도록 자체 복구한다. Avi 컨트롤러(소프트웨어라는 사실이 아님)는 우리를 특별하고 무자비하게 효율적으로 만든다.
로드 밸런싱 산업은 수십 년 동안 휴면 상태였지만, 애플리케이션 아키텍처와 멀티 클라우드 환경의 발전으로 기업들은 로드 밸런싱 공급자를 재평가하지 않을 수 없게 되었다. 많은 벤더가 컨트롤러를 보유하고 있다고 주장하는 것은 현대 애플리케이션을 지원하는 이 아키텍처 모델에 대한 고객의 요구를 인정하는 것이다. 하지만 이 제품들 중 많은 것들이 실제로 그 양을 재지 못한다. 벤더가 컨트롤러를 가지고 있다고 주장할 경우 다음과 같은 간단한 질문을 하십시오.
- 컨트롤러가 모든 로드 밸런서에 가상 서비스를 자동으로 배치하고 모든 데이터 센터 또는 클라우드의 풀 서버에 대한 연결을 풀링할 수 있는가?
- 제어기가 액티브 스탠바이 어플라이언스 없이도 로드 밸런서를 자동으로 치료/복구할 수 있는가?
- 실시간 트래픽 패턴을 기반으로 로드 밸런싱 용량을 자동으로 스케일업 또는 스케일다운할 수 있는가?
이 기능이 없으면 로드 밸런싱 장치가 비즈니스에 보조를 맞출 수 없다.
