F5 애플리케이션 서비스 자동화: 실용 가이드

애플리케이션 제공 및 보안 장치의 배포와 구성 관리를 자동화하는 것은 거의 필수적인 관행이 되었습니다. 2017년 IDG FutureScape 보고서에서는 자동화 및 멀티클라우드 관리가 2021년까지 기업에 영향을 미칠 주요 이니셔티브 중 일부로 선정되었습니다. 자동화는 애플리케이션에 필요한 필수적인 보안, 최적화 및 가용성 서비스를 배포하는 데 있어 규모성, 안정성 및 통합을 제공하며, 이러한 서비스의 제공을 주요 애플리케이션 배포 모델로 부상하고 있는 조율된 빌드, 테스트 및 배포 워크플로의 일부로 만듭니다.

새로운 가상 서버나 풀 멤버를 추가하는 것과 같은 기본 작업만 간단하게 자동화해도 운영진은 애플리케이션 소유자나 다른 자동화 시스템에 셀프 서비스 기능을 제공할 수 있으며, 이를 통해 차세대 자동화 도구 구축과 같은 보다 생산적인 작업에 시간을 할애할 수 있습니다.

조직이 IT 서비스를 제공하기 위해 여러 클라우드 플랫폼을 도입하기 시작하면 자동화의 필요성이 더욱 커집니다. 다양한 플랫폼 특성을 가진 여러 위치에 서비스를 배포하려고 할 때 자동화는 운영 오버헤드 증가를 줄이고 새로운 플랫폼에 익숙하지 않아 발생하는 오류를 줄이는 데 도움이 될 수 있습니다.

하지만 무엇을, 어떻게 자동화해야 할까? 자동화 소프트웨어는 다양한 운영 모델, 인터페이스, 언어를 통해 단일 장치 계층에서 작동할 수도 있고, 더 복잡한 다중 시스템 도구로 작동할 수도 있습니다. IaaS(Infrastructure-as-a-Service) 클라우드 플랫폼은 모두 가상 인프라와 서비스를 배포하기 위한 자체 기본 도구를 제공합니다. 또한 F5는 다양한 인터페이스와 오케스트레이션 옵션을 제공합니다. 이처럼 다양한 도구와 옵션을 통해 조직에 가장 적합한 방식으로 자동화를 구현할 수 있지만, 적절한 도구를 선택하는 것은 어려운 작업일 수 있으며, 복잡성과 도구 확산의 위험도 현실적입니다.

이 논문에서는 F5 BIG-IP 어플라이언스(물리적 및 가상)의 배포, 관리 및 구성을 자동화하는 방법에 대한 개요를 제공하고, 귀사의 비즈니스에 적합한 경로를 선택하는 방법에 대한 몇 가지 조언을 제공합니다.

자동화의 스펙트럼

자동화에는 다양한 활동이 포함됩니다. 스펙트럼의 한쪽 끝에는 Bash, TMSH, Python 또는 기타 언어로 작성된 간단한 스크립트를 개발하여 로컬에서 실행하여 수동 구성 작업의 속도를 높이는 것이 있습니다. 스펙트럼의 다른 쪽 끝에는 소스 코드 관리, 워크플로 오케스트레이터 및 (잠재적으로) 여러 자동화 도구를 결합하여 인프라 구성이 저장소에 포함된 텍스트 파일에 의해 정의되고 변경되는 시스템을 만드는 전체 "인프라 코드" 시스템이 있습니다. 이 두 가지 극단적인 상황 사이에는 BIG-IP 플랫폼의 배포와 구성을 관리하는 데 도움이 되는 다양한 옵션이 있습니다.

선언적 vs. 명령적

자동화 인터페이스가 소비자에게 노출되는 방식에는 두 가지 개념적 모델이 있습니다. 가장 흔한 "첫 번째 물결" 자동화 스키마는 필수 모델로 향하는 경향이 있습니다. 명령형 자동화 모델에서 자동화 소비자는 일반적으로 달성하고자 하는 목표와 이를 달성하기 위한 명시적 단계(일반적으로 API 호출)를 모두 알아야 합니다. 이로 인해 고급 서비스의 구성 세부 정보를 이해해야 하는 부담이 소비자에게 전가되는 경우가 많고, 자동화 도구와 서비스를 통합하기 위한 추가적인 복잡성과 노력이 발생하기도 합니다. 이는 샌드위치를 만들기 위해 필요한 모든 작업을 일일이 명시하여 샌드위치를 달라고 요청하는 것과 같습니다. 샌드위치를 그냥 달라고 요청한 다음 샌드위치를 만들기 위해 어떤 작업을 어떤 순서로 수행해야 하는지 샌드위치 만드는 사람이 알고 있기를 기대하는 것은 아닙니다.

이와 대조적으로 선언적 인터페이스는 소비자(인간이나 기계)가 원하는 것을 요청하여 서비스를 만들 수 있도록 합니다. 자동화 대상에는 필요한 결과에 따라 구성을 생성할 수 있는 사전 구성된 워크플로나 서비스 템플릿이 있으므로, 필요한 모든 단계에 대한 자세한 지식은 필요하지 않습니다. 선언적 인터페이스는 초기 설정이 약간 더 복잡하지만, 적절한 서비스 템플릿이 구축되면 작업이 간단해져 복잡성은 상쇄됩니다. 따라서 이는 일반적으로 자동화 시스템을 구축하는 데 선호되는 메커니즘입니다.

직접 또는 관리 도구를 통해

고려해야 할 또 다른 결정은 자동화 API 호출을 변경해야 하는 장치에 타사 도구에서 직접 수행해야 하는지, 아니면 추가 관리 도구를 통해 수행해야 하는지입니다. 관리 도구는 운영을 추상화하고 단순화할 수 있으며, 관리 대상 엔터티에 직접 연결하는 것보다 더 많은 제어 및 로깅 계층을 제공할 수 있습니다. 하지만 빠르게 변경하는 기능이 중요한 상황에서 관리 계층의 가용성을 높이려면 해당 도구를 지원해야 합니다.

API, 스타트업 에이전트, 아니면 CLI?

BIG-IP 장치는 대개 REST API를 통해 자동화되며, 이는 문서화된 스키마를 통해 대부분의 BIG-IP 기능을 제공합니다. Ansible과 같은 자동화 도구를 위한 F5 제공 모듈은 REST API를 광범위하게 사용합니다. 설정별 필수 인터페이스를 제공하는 것 외에도 REST API 호출을 사용하여 F5 iApp 템플릿을 시작할 수 있으며, 여기서 iApp 서비스를 구성하는 값은 API 호출에서 JSON 페이로드로 전달됩니다. iControl LX 기능을 추가하면 단일 API 호출로 여러 단계의 작업을 수행할 수 있는 사용자 정의 API 엔드포인트를 생성할 수도 있습니다.

BIG-IP 구성을 자동화하는 또 다른 일반적인 방법은 시작 에이전트를 사용하는 것입니다. 시작 에이전트는 시작 시 실행되어 BIG-IP 플랫폼을 구성하기 위한 외부 정보를 가져올 수 있습니다. 시작 에이전트는 종종 장치를 "온보딩"하기 위한 초기 구성을 수행하는 데 사용되며 GitHub 또는 자체 저장소와 같은 타사 사이트에서 추가 스크립트 및 구성 파일을 가져올 수 있습니다. 스타트업 에이전트는 특히 고정된 애플리케이션별 구성을 선택한 경우 BIG-IP 플랫폼을 완전히 구성하는 데에도 사용할 수 있습니다.

가장 일반적인 시작 구성은 cloud-init 으로, 모든 BIG-IP VE 이미지(Microsoft Azure 제외)에서 활성화되어 있지만 AWS 및 OpenStack 배포에 가장 적합합니다. F5는 cloud-init과 함께 부팅 시 BIG-IP를 구성하는 데 도움이 되는 일련의 클라우드 시작 라이브러리를 제공합니다.

부팅 후에 플랫폼을 구성하기 위해 시작 에이전트를 사용하기로 선택한 경우 외부 소스를 사용하는 경우, 특히 확장 이벤트의 일부로 인스턴스가 시작될 수 있는 경우 오류를 관리하는 데 주의하세요. 외부 리소스를 사용할 수 없다면 시스템은 어떻게 작동할까요? 수요를 충족하기 위해 추가적인 "좀비" 장치가 만들어질까요?

어떤 경우에는 자동화 시스템이 사용자처럼 동작하고 CLI 명령을 실행할 수 있습니다. 이 방법으로 API 호출이 완료되지 않은 일부 문제를 해결할 수 있는 경우가 있지만 일반적으로 지원이 어렵고 솔루션이 취약하기 때문에 이 방법은 마지막 수단으로 사용됩니다.

템플릿 및 플레이북

템플릿과 플레이북을 사용하면 자동화된 배포를 만들고 일정 수준의 표준화가 이루어진 인프라를 구축할 수 있습니다. 적절한 수준의 표준화는 인프라를 보다 강력하고 지원 가능하게 만들어줍니다. 잘 만들어진 템플릿은 선언적 인터페이스를 제공하는데, 요청하는 엔티티(사용자 또는 컴퓨터)는 구현 세부 사항이 아니라 필요한 속성만 알면 됩니다. 템플릿을 사용하여 엄격하게 배포하고 템플릿을 수정하여만 문제를 해결하면 문제가 일반적으로 한 번 해결된 후 새 템플릿에서 서비스를 다시 배포하므로 서비스 품질이 더 높아질 수 있습니다.

플랫폼 통합

플랫폼 통합 도구는 BIG-IP 서비스 구성을 프라이빗 클라우드나 컨테이너 관리 시스템과 같은 컴퓨팅 플랫폼에 연결합니다. 이러한 메커니즘은 플랫폼과 구현에 따라 다르지만 일반적으로 다음 세 가지 모델로 구분됩니다.

기존 플랫폼 구조에 F5 서비스 대체
이 모델에서는 F5 서비스가 기존 플랫폼 구조를 사용하여 삽입됩니다. 예를 들어, F5를 OpenShift 컨테이너 플랫폼 라우터 로 사용하거나 F5를 OpenStack Load Balancing as a Service(LBaaS) 시스템과 함께 사용합니다. 이러한 메커니즘을 사용하면 플랫폼 기반 인터페이스를 사용하여 서비스를 구성하고, 제공된 드라이버와 기타 소프트웨어가 플랫폼 구성 지침을 F5 구성으로 원활하게 변환하기 때문에 운영 절차를 거의 변경할 필요가 없습니다. 하지만 플랫폼 기반 인터페이스를 통해서만 사용 가능한 기능만 쉽게 배포할 수 있다는 점을 기억하세요.

플랫폼 이벤트 구독하기

또 다른 일반적인 통합 방법은 소프트웨어 모듈(예: Kubernetes 및 Mesos용 Container Connector)이 플랫폼 내의 이벤트를 구독한 다음 이벤트에 따라 구성을 수정하는 것입니다. 서비스가 필요한 애플리케이션에 태그를 지정하거나 레이블을 지정하여 배포할 이벤트와 서비스를 선택하고, 필요한 태그가 있는 이벤트를 모니터링하도록 커넥터 소프트웨어를 구성할 수 있습니다.

플랫폼 관리 도구와의 통합 

많은 프라이빗 클라우드 플랫폼에는 자동화를 위해 설계된 관리 시스템이 있습니다. 예를 들어 VMware에는 여러 관리 및 통합 도구가 있으며, 그 중에는 BIG-IP 구성을 위한 타사 플러그인이 있는 vRealize Orchestrator(vRO)가 있습니다. 다른 예로는 OpenStack HEAT 템플릿 시스템용 플러그인이 있습니다.

서비스 발견

서비스 검색은 완전한 자동화 솔루션은 아니지만 BIG-IP 구성을 환경 변화에 맞게 통합하는 간단하면서도 강력한 방법입니다. 서비스 검색은 API를 통해 클라우드 시스템을 주기적으로 폴링하여 리소스 목록을 검색하고 이에 따라 BIG-IP 구성을 수정하는 방식으로 작동합니다. 이 기능은 리소스가 자동 크기 조정 그룹으로 구성된 환경에서 특히 유용합니다. 백엔드 컴퓨팅 리소스를 확장하려면 로드 밸런서가 새 리소스를 인식해야 하기 때문입니다. 서비스 검색 구성 요소는 AWS 및 Azure 용 F5 클라우드 자동 확장 솔루션과 함께 제공됩니다.

일반적인 자동화 도구: 리소스 가이드 

상상할 수 있는 모든 자동화 또는 오케스트레이션 도구를 다룰 수는 없지만 F5 고객들이 사용하는 가장 일반적인 도구, 사용 사례 및 기능 목록은 아래와 같습니다.

언어 통합

구성 관리 및 인프라 자동화 도구

인프라 템플릿 시스템

스타트업 에이전트 및 클라우드 스크립트

클라우드 초기화
https://devcentral.f5.com/articles/f5-in-aws-part-5-cloud-init-single-nic-and-scale-out-of-big-ip-in-v12-21476

클라우드 라이브러리
https://github.com/F5Networks/f5-cloud-libs

플랫폼 통합
컨테이너 관리 플랫폼

프라이빗 클라우드 플랫폼

오케스트레이션 및 워크플로 도구에 대한 참고 사항 

위의 도구와 통합은 BIG-IP 플랫폼을 배포하고 구성하여 애플리케이션 가용성, 보안, 확장 서비스를 제공하는 자동화된 방법을 나타냅니다. 이러한 서비스는 필수적이기는 하지만 풀스택 애플리케이션 배포의 일부에 불과합니다. 서버, 데이터, 컴파일된 애플리케이션 코드, 인프라를 조율되고 테스트된 방식으로 갖춘 전체 애플리케이션 스택을 만들려면 간단한 자동화 도구 그 이상이 필요합니다.

여러 자동화 시스템과의 통합 및 관련 워크플로를 갖춘 더 높은 수준의 오케스트레이션 도구가 필요합니다. 이러한 도구는 일반적으로 CI/CD(지속적인 통합/지속적인 배포) 작업 관행에서 가장 많이 사용되며, 모든 실제 구현에서 자동화가 필요합니다. 여러 오케스트레이션 도구가 있지만 Jenkins가 가장 일반적이며 CI/CD 워크플로에 F5 인프라스트럭처 코드 기능을 통합하는 방법을 보여주는 예제 워크플로도 있습니다. 그러나 일반적으로 오케스트레이션 도구는 구성 자동화 도구 중 하나를 통해 실제로 서비스 배포를 변경합니다.

라이센스

BIG-IP 플랫폼은 작동하기 위해 라이선스가 필요하므로 자동화의 중요 경로에 라이선스를 포함하는 것이 좋습니다. BIG-IP 가상 장치를 신속하게 확장하거나 축소하거나 테스트 및 개발 목적으로 생성해야 하는 매우 역동적인 환경에서는 라이선싱 모델을 신중하게 고려해야 합니다.

퍼블릭 클라우드에서 한 가지 방법은 BIG-IP의 유틸리티 청구 버전을 사용하는 것입니다(클라우드 마켓플레이스를 통해 이용 가능). 공공 서비스 요금 청구 인스턴스는 자체 라이선스가 적용되며, 비용은 클라우드 공급자를 통해 사용량에 따른 요금 또는 시간 약정 기준으로 청구됩니다.

또 다른 옵션은 F5 BIG-IQ License Manager 와 함께 구독(또는 영구)을 통해 구매한 재사용 가능 라이선스 풀을 사용하는 것입니다. 이를 통해 풀에서 라이선스를 할당하고 취소할 수 있습니다.

스타트업 에이전트와 API 호출을 통해 라이선싱 단계를 자동화할 수 있으며, 이를 위해서는 F5 라이선스 서버에 대한 아웃바운드 인터넷 액세스가 필요합니다(클라우드 플랫폼의 유틸리티 라이선스의 경우에도 마찬가지입니다).

언제 무엇을 사용해야 하나요?

조직에 따라 적합한 자동화 및 오케스트레이션 도구를 선택하는 것은 매우 쉽거나 어려운 작업이 될 수 있습니다. 다른 구성 요소에 대한 도구나 방법론을 이미 채택했고 BIG-IP를 시스템에 통합하기만 하면 되는 경우에는 쉽습니다. 특정 도구에 통합하지 않아도 iControl LX 기능과 cloud-init을 결합한 풍부한 iControl REST API를 통해 기존 자동화 도구에 BIG-IP를 통합하는 작업이 비교적 간단해집니다(특히, 단일 API 호출로 복잡한 구성도 생성하는 데 사용할 수 있는 iApp 템플릿과 결합하는 경우 더욱 그렇습니다).

그러나 처음부터 시작한다면 상황이 더 복잡해질 수 있습니다. 다른 솔루션을 선택하는 것과 마찬가지로, 먼저 요구 사항을 이해하는 것이 중요합니다. 이 논문에서는 귀하의 요구 사항 목록을 작성할 수 없지만 귀하의 평가를 돕기 위한 질문과 권장 사항 세트는 다음과 같습니다.

• 자동화 모델: 선언적 모델을 사용하면 오케스트레이션 소비자가 상호 작용하기가 훨씬 간단해집니다. 소비자는 원하는 것이 무엇인지 알아야 할 뿐, 원하는 것이 무엇인지 알기 위해 거쳐야 할 절차적 단계를 알 필요는 없습니다.
• 잠재적인 플랫폼 및 환경: 컨테이너와 다양한 클라우드 플랫폼이 애플리케이션 인프라의 핵심 부분이 될 것이라는 가정은 이 시점에서 불가피해 보입니다. 이에 따라 계획을 세우세요.
• 기술: 이미 기반 기술 중 일부에 대한 기술을 보유하고 있나요? 이런 기술은 부서 밖에서는 존재할 수 있지만 회사 전체에서는 존재할 수 있다는 점을 명심하세요. 그렇다면 귀하의 조직에서 이미 채택한 언어를 사용하는 도구를 선택하는 것이 좋을 수 있습니다.
• 지원 가능성: 지원할 수 있는 시스템만 구축하세요. 이는 당연한 것처럼 보일 수 있지만 성공의 핵심은 조직 내에서 제공할 수 있는 복잡성 수준을 선택하는 것입니다. 이를 통해 과도한 운영 오버헤드를 발생시키지 않으면서도 자동화의 이점을 극대화할 수 있습니다.

F5 프라이빗 클라우드 솔루션 패키지 

F5 프라이빗 클라우드 솔루션 패키지는 다양한 프라이빗 클라우드 환경에서 F5 애플리케이션 서비스를 제공하는 데 필요한 기술과 서비스를 쉽게 확보할 수 있는 방법입니다. 이 패키지는 소프트웨어, 하드웨어, 전문 서비스를 함께 묶어 다양한 프라이빗 클라우드 플랫폼을 위한 턴키 방식의 검증된 솔루션을 제공합니다. 프라이빗 클라우드 솔루션 패키지를 사용하면 다른 플랫폼에 복제할 수 있는 모델 배포가 가능하므로 여러 환경에서 보다 균일하고 일관적인 애플리케이션 제공 및 보안 서비스 세트를 만들 수 있습니다.

IT 자동화 수준의 증가는 불가피합니다. 주요 애플리케이션 전달 및 보안 서비스를 제공하기 위한 전략적 접근 방식을 취하면 조직에서 배포하는 애플리케이션의 보안과 가용성이 유지됩니다. 자동화는 특히 여러 플랫폼과 퍼블릭 클라우드에서 작업하는 경우 운영 오버헤드를 줄이는 데 도움이 될 수도 있습니다.

올바른 자동화 시스템을 선택하는 것은 어려울 수 있으며, 이상적으로는 귀하가 사용할 수 있는 기술 세트와 시스템의 지원 가능성을 고려하여 협력적이고 전체적인 노력으로 이루어져야 합니다. 어떤 솔루션을 선택하든 BIG-IP 플랫폼과 F5 전문성을 활용하여 애플리케이션이 어디에 구축되어 있든 필요한 엔터프라이즈급 서비스를 제공할 수 있다는 확신을 가질 수 있습니다.