F5 애플리케이션 서비스 자동화: 실무 가이드
소개
애플리케이션 전송 및 보안 장비의 배포와 구성 관리를 자동화하는 것은 이제 거의 필수적인 관행이 되었습니다. 2017년 IDG FutureScape 보고서에서는 자동화와 멀티 클라우드 관리가 2021년까지 비즈니스에 영향을 미칠 주요 이니셔티브로 꼽혔습니다. 자동화는 애플리케이션에 필요한 핵심 보안, 최적화 및 가용성 서비스의 배포에 확장성, 안정성, 통합성을 더하며, 이러한 서비스의 제공을 애플리케이션 배포의 지배적인 모델로 부상하고 있는 오케스트레이션된 빌드, 테스트 및 배포 워크플로의 일부로 만듭니다.
새 가상 서버나 풀 멤버를 추가하는 것과 같은 기본 작업을 단순히 자동화하는 것만으로도 운영팀은 애플리케이션 소유자나 다른 자동화 시스템에 셀프서비스 기능을 제공할 수 있으며, 차세대 자동화 도구 개발과 같이 생산성이 더 높은 업무에 집중할 시간을 확보할 수 있습니다.
조직이 IT 서비스를 제공하기 위해 여러 클라우드 플랫폼을 도입하기 시작하면 자동화의 필요성은 더욱 중요해집니다. 서로 다른 플랫폼 특성을 지닌 여러 위치에 서비스를 배포하려는 경우, 자동화를 통해 늘어난 운영 부담을 줄이고 새로운 플랫폼에 익숙하지 않아 발생하는 오류를 감소시킬 수 있습니다.
하지만 무엇을 어떻게 자동화해야 할까요? 운영 모델, 인터페이스, 언어가 서로 다른 환경에서 자동화 소프트웨어는 단일 디바이스 계층에서 작동할 수도 있고, 여러 시스템을 아우르는 보다 복잡한 도구로 활용될 수도 있습니다. 서비스형 인프라(IaaS) 클라우드 플랫폼은 모두 가상 인프라와 서비스를 배포하기 위한 자체 네이티브 도구를 제공합니다. 또한 F5는 다양한 인터페이스와 오케스트레이션 옵션을 제공합니다. 이처럼 폭넓은 도구와 옵션을 활용하면 조직에 가장 적합한 방식으로 자동화할 수 있지만, 적절한 도구를 선택하는 일은 쉽지 않으며 복잡성이 증가하고 도구가 난립할 위험도 분명히 존재합니다.
이 백서에서는 F5 BIG-IP 어플라이언스(물리 및 가상)의 배포, 관리, 구성을 자동화하는 방법을 개괄적으로 살펴보고, 비즈니스에 적합한 방식을 선택하는 데 도움이 되는 몇 가지 조언을 제공합니다.
자동화: 몇 가지 주요 고려 사항
자동화의 스펙트럼
자동화는 다양한 활동을 포괄합니다. 스펙트럼의 한쪽 끝에는 수동 구성 작업의 속도를 높이기 위해 로컬에서 실행할 수 있는 Bash, TMSH, Python 또는 기타 언어로 작성된 간단한 스크립트 개발이 있습니다. 반대쪽 끝에는 소스 코드 관리, 워크플로 오케스트레이터 및 여러 자동화 도구를 결합하여 리포지토리에 포함된 텍스트 파일로 인프라 구성을 정의하고 변경하는 완전한 ‘코드형 인프라(infrastructure-as-code)’ 시스템이 있습니다. 이 두 극단 사이에는 BIG-IP 플랫폼의 배포 및 구성을 관리하는 데 도움이 되는 다양한 옵션이 있습니다.
가변과 불변
현재 대부분의 BIG-IP 배포는 가변형으로 볼 수 있으며, 이는 시간이 지남에 따라 구성이 변경될 수 있음을 의미합니다. BIG-IP 플랫폼은 주로 여러 애플리케이션에 서비스를 제공하는 멀티테넌트 장치로 배포되기 때문입니다. 새로운 애플리케이션이 배포되거나 기존 애플리케이션이 확장되거나 추가 서비스를 필요로 하면 그에 맞게 BIG-IP 구성이 업데이트됩니다. 이러한 배포 방식에서는 인프라 팀이 공통 플랫폼을 통해 애플리케이션에 서비스를 제공하는 중앙 집중식 인프라를 관리할 수 있습니다.
그러나 경우에 따라 BIG-IP 플랫폼은 독립적인 애플리케이션 스택의 일부로 배포되며, 이때 특정 BIG-IP의 서비스는 특정 애플리케이션이나 서비스에 연결됩니다. 이러한 상황에서는 BIG-IP 구성을 불변으로 취급할 수 있습니다. 즉, 구성은 부팅 시 또는 소프트웨어 이미지의 일부로 설치되며 BIG-IP 인스턴스의 수명 주기 동안 변경되지 않습니다. 구성을 변경하려면 소프트웨어 이미지나 시작 에이전트 스크립트의 내용을 수정한 후 다시 배포합니다. 이 모델은 흔히 “완전히 제거한 후 새로 구축하기(nuke and pave)”라고 합니다. 전반적으로는 덜 일반적이지만, 애플리케이션별 인스턴스를 지원하는 새로운 BIG-IP 라이선스 모델, 향상된 라이선스 도구, 그리고 F5 cloud libs(클라우드에서 BIG-IP를 온보딩하는 데 도움이 되도록 설계된 Node.js 스크립트 및 라이브러리 모음)와 같은 도구가 등장하면서, 코드와 인프라가 긴밀하게 결합된 격리형 스택을 애플리케이션에 제공해야 하는 조직에서도 이 배포 모델을 실용적인 옵션으로 채택할 수 있게 되었습니다.
선언형과 명령형 비교
자동화 인터페이스를 소비자에게 제공하는 방식에는 두 가지 개념적 모델이 있습니다. 가장 일반적인 ‘1세대’ 자동화 스키마는 명령형 모델을 따르는 경향이 있습니다. 명령형 자동화 모델에서는 일반적으로 자동화 소비자가 달성하려는 목표뿐만 아니라 이를 달성하기 위한 구체적인 단계(대개 API 호출)까지 알아야 합니다. 이로 인해 고급 서비스의 구성 세부 정보를 이해해야 하는 부담은 물론, 해당 서비스를 자동화 도구와 통합하는 데 따르는 추가적인 복잡성과 수고까지 소비자가 떠안게 되는 경우가 많습니다. 이는 단순히 샌드위치를 주문하고 만드는 사람이 어떤 작업을 어떤 순서로 수행해야 하는지 알아서 처리해 주기를 기대하는 대신, 샌드위치를 만드는 데 필요한 모든 작업을 하나하나 지정해 주문하는 것과 같습니다.
반면, 선언형 인터페이스에서는 소비자(사람 또는 기계)가 원하는 것을 요청하여 서비스를 생성할 수 있습니다. 자동화 대상에 사전 구성된 워크플로 또는 서비스 템플릿이 있어 요구되는 결과에 따라 구성을 생성하므로, 필요한 모든 단계를 상세히 알 필요가 없습니다. 선언형 인터페이스는 초기 설정이 다소 복잡하지만, 적절한 서비스 템플릿을 구축하고 나면 운영이 간편해져 이러한 복잡성이 상쇄됩니다. 따라서 일반적으로 자동화 시스템을 구축할 때 선호되는 방식입니다.
직접 또는 관리 도구를 통해
고려해야 할 또 다른 사항은 타사 도구에서 변경 대상 장치로 자동화 API를 직접 호출할지, 아니면 별도의 관리 도구를 통해 호출할지 여부입니다. 관리 도구를 사용하면 작업을 추상화하고 간소화할 수 있으며, 관리 대상에 직접 연결하는 방식보다 더 강화된 제어 및 로깅 기능을 제공할 수도 있습니다. 하지만 신속한 변경이 매우 중요한 상황에서 관리 계층의 고가용성을 보장하려면 해당 도구를 지속적으로 지원해야 합니다.
API, 시작 에이전트 또는 CLI?
BIG-IP 디바이스는 일반적으로 BIG-IP 기능 대부분을 문서화된 스키마를 통해 제공하는 REST API를 사용하여 자동화됩니다. 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를 OpenShift Container Platform 라우터로 사용하거나 F5를 OpenStack 서비스형 로드 밸런싱(LBaaS) 시스템과 함께 사용하는 등 기존 플랫폼 구성 요소를 활용하여 F5 서비스를 적용합니다. 플랫폼 네이티브 인터페이스를 사용해 서비스를 구성하고, 제공된 드라이버와 기타 소프트웨어가 플랫폼 구성 지시문을 F5 구성으로 원활하게 변환하므로 이러한 메커니즘을 사용할 때 운영 절차를 거의 변경할 필요가 없습니다. 단, 플랫폼 네이티브 인터페이스를 통해 제공되는 기능만 손쉽게 배포할 수 있다는 점에 유의하십시오.
플랫폼 이벤트 구독
또 다른 일반적인 통합 방법은 소프트웨어 모듈(예: Kubernetes 및 Mesos용 Container Connector)이 플랫폼 내 이벤트를 구독한 다음, 해당 이벤트에 따라 구성을 변경하도록 하는 것입니다. 서비스를 제공해야 하는 애플리케이션에 태그나 레이블을 지정하고, 필요한 태그가 있는 이벤트를 모니터링하도록 커넥터 소프트웨어를 구성하여 배포할 이벤트와 서비스를 선택할 수 있습니다.
플랫폼 관리 도구와의 통합
많은 프라이빗 클라우드 플랫폼에는 자동화를 위해 설계된 관리 시스템이 있습니다. 예를 들어 VMware는 vRealize Orchestrator(vRO)를 비롯한 여러 관리 및 통합 도구를 제공하며, vRO에는 BIG-IP 구성을 위한 타사 플러그인이 있습니다. 또 다른 예로는 OpenStack HEAT 템플릿 시스템용 플러그인이 있습니다.
서비스 검색
서비스 검색은 완전한 자동화 솔루션은 아니지만, 환경 변화에 맞춰 BIG-IP 구성을 통합할 수 있는 간단하면서도 강력한 방법입니다. 서비스 검색은 API를 통해 클라우드 시스템을 주기적으로 폴링하여 리소스 목록을 가져오고, 그에 따라 BIG-IP 구성을 수정하는 방식으로 작동합니다. 이는 리소스가 자동 확장 그룹으로 구성된 환경에서 특히 유용합니다. 백엔드 컴퓨팅 리소스를 확장하려면 로드 밸런서가 새 리소스를 인식해야 하기 때문입니다. 서비스 검색 구성 요소는 다음 플랫폼용 F5 클라우드 자동 확장 솔루션과 함께 제공됩니다: AWS 및 Azure.
일반적인 자동화 도구: 리소스 가이드
가능한 모든 자동화 또는 오케스트레이션 도구를 다룰 수는 없지만, 아래에는 F5 고객이 가장 많이 사용하는 도구와 사용 사례 및 기능을 정리했습니다.
-------------------------
언어 통합
언어
상태
예시 및 출처
Python
F5 기여
https://github.com/F5Networks/f5-common-python
Go
사용자 기여
https://github.com/f5devcentral/go-bigip
PowerShell
F5 지원
https://devcentral.f5.com/wiki/icontrol.powershell.ashx
구성 관리 및 인프라 자동화 도구
도구
상태
예시 및 출처
Ansible
F5 제공
https://github.com/F5Networks/f5-ansible
Terraform
F5 제공
https://github.com/f5devcentral/terraform-provider-bigip
Puppet
F5 기여
https://github.com/f5devcentral/f5-puppet
Chef
사용자 제공
https://github.com/target/f5-bigip-cookbook
SaltStack
서드 파티
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html
인프라 템플릿 시스템
플랫폼
상태
예시 및 출처
AWS
F5 지원2
https://github.com/F5Networks/f5-aws-cloudformation
Azure
F5 지원1
https://github.com/F5Networks/f5-azure-arm-templates
F5 지원1
https://github.com/F5Networks/f5-google-gdm-templates
OpenStack
F5 지원1
https://github.com/F5Networks/f5-openstack-hot
----------------------------
시작 에이전트 및 클라우드 스크립트
클라우드 라이브러리
https://github.com/F5Networks/f5-cloud-libs
---------------------------
플랫폼 통합
컨테이너 관리 플랫폼
플랫폼
상태
예시 및 출처
쿠버네티스
F5 지원1
https://github.com/F5Networks/k8s-bigip-ctlr
마라톤
F5 지원1
https://github.com/F5Networks/marathon-bigip-ctlr
CloudFoundry
F5 지원1
https://github.com/F5Networks/cf-bigip-ctlr
프라이빗 클라우드 플랫폼
플랫폼
상태
예시 및 출처
OpenStack (LBaaS)
F5 지원1
https://github.com/F5Networks/f5-openstack-lbaasv2-driver
OpenStack(Heat)
F5 지원1
https://github.com/F5Networks/f5-openstack-hot
VMWare (vRO)
타사
https://bluemedora.com/products/f5/big-ip-for-vrealize-operations/
-------------------
오케스트레이션 및 워크플로 도구에 관한 참고 사항
위의 도구와 통합 기능은 애플리케이션 가용성, 보안 및 확장 서비스를 제공하도록 BIG-IP 플랫폼을 자동으로 배포하고 구성하는 방법을 나타냅니다. 이러한 서비스는 필수적이지만 전체 스택 애플리케이션 배포의 한 부분일 뿐입니다. 서버, 데이터, 컴파일된 애플리케이션 코드 및 인프라를 포함하는 전체 애플리케이션 스택을 조율되고 검증된 방식으로 구축하려면 단순한 자동화 도구 이상의 것이 필요합니다.
관련 워크플로 및 여러 자동화 시스템과의 통합 기능을 갖춘 상위 수준의 오케스트레이션 도구가 필요합니다. 이러한 도구는 자동화가 사실상 필수인 지속적 통합/지속적 제공(CI/CD) 업무 방식에서 가장 일반적으로 사용됩니다. 여러 오케스트레이션 도구가 있지만 Jenkins가 가장 널리 사용되며, Jenkins, F5 및 Ansible을 사용하여 F5의 코드형 인프라 기능을 CI/CD 워크플로에 통합하는 방법을 보여 주는 예제 워크플로가 제공됩니다. 하지만 일반적으로 오케스트레이션 도구는 구성 자동화 도구 중 하나를 통해 실제로 변경 사항을 적용하고 서비스를 배포합니다.
라이선스
BIG-IP 플랫폼이 작동하려면 라이선스가 필요하므로, 자동화의 핵심 경로에 라이선스 부여를 포함하는 것이 좋습니다. BIG-IP 가상 디바이스를 신속하게 확장 또는 축소하거나 테스트 및 개발 목적으로 생성해야 할 수 있는 매우 동적인 환경에서는 라이선스 모델을 신중하게 고려해야 합니다.
퍼블릭 클라우드에서는 클라우드 마켓플레이스를 통해 제공되는 BIG-IP의 사용량 기반 과금 버전을 사용하는 방법이 있습니다. 사용량 기반 과금 인스턴스는 라이선스를 자동으로 활성화하며, 비용은 사용량 기반 또는 약정 기간 기준으로 클라우드 제공업체를 통해 청구됩니다.
또 다른 옵션은 구독 방식(또는 영구 라이선스)으로 구매한 재사용 가능한 라이선스 풀을 F5 BIG-IQ License Manager와 함께 사용하는 것입니다. 이를 통해 풀에서 라이선스를 할당하고 회수할 수 있습니다.
시작 에이전트와 API 호출을 통해 라이선스 부여 단계를 자동화할 수 있으며, 이를 위해서는 F5 라이선스 서버에 대한 아웃바운드 인터넷 액세스가 필요합니다(클라우드 플랫폼의 유틸리티 라이선스도 마찬가지입니다).
언제 무엇을 사용해야 하나요?
조직의 상황에 따라 적합한 자동화 및 오케스트레이션 도구를 선택하는 일은 매우 쉬울 수도 있고 어려운 과제가 될 수도 있습니다. 다른 구성 요소에 사용할 도구나 방법론을 이미 도입했으며 BIG-IP을 시스템에 통합하기만 하면 되는 경우에는 간단합니다. 특정 도구와 통합하지 않더라도 풍부한 iControl REST API를 iControl LX 기능 및 cloud-init과 함께 활용하면 BIG-IP을 기존 자동화 도구에 비교적 쉽게 통합할 수 있습니다. 특히 단 한 번의 API 호출로 복잡한 구성까지 생성할 수 있는 iApp 템플릿과 함께 사용하면 더욱 간편합니다.
하지만 처음부터 시작하는 경우에는 상황이 더 복잡할 수 있습니다. 다른 솔루션을 선택할 때와 마찬가지로 먼저 요구 사항을 파악해야 합니다. 이 문서에서 요구 사항 목록을 대신 작성해 드릴 수는 없지만, 평가에 도움이 되는 몇 가지 질문과 권장 사항을 제시합니다.
- 자동화 모델: 선언적 모델은 오케스트레이션 사용자가 훨씬 더 간편하게 이용할 수 있습니다. 사용자는 원하는 결과에 도달하기 위한 모든 절차적 단계를 알 필요 없이, 자신이 원하는 것이 무엇인지만 알면 됩니다.
- 잠재적 플랫폼 및 환경: 이제 컨테이너와 다양한 클라우드 플랫폼이 애플리케이션 인프라의 핵심 요소가 될 것은 불가피해 보입니다. 이에 맞춰 계획을 수립하세요.
- 기술 역량: 기반 기술 중 일부에 대해 이미 보유한 역량이 있나요? 이러한 역량은 소속 부서가 아닌 회사 내 다른 부서에 있을 수도 있다는 점을 염두에 두세요. 그렇다면 조직에서 이미 도입한 언어를 사용하는 도구를 선택하는 것이 합리적일 수 있습니다.
- 지원 가능성: 지원할 수 있는 시스템만 구축하세요. 당연한 말처럼 들릴 수 있지만, 성공의 핵심은 조직 내에서 구현할 수 있는 수준의 복잡성을 선택하는 것입니다. 그래야 과도한 운영 부담을 초래하지 않으면서 자동화의 이점을 극대화할 수 있습니다.
F5 프라이빗 클라우드 솔루션 패키지
F5 프라이빗 클라우드 솔루션 패키지는 다양한 프라이빗 클라우드 환경에서 F5 애플리케이션 서비스를 제공하는 데 필요한 기술과 서비스를 손쉽게 확보할 수 있는 방법입니다. 이 패키지는 소프트웨어, 하드웨어 및 전문 서비스를 하나로 묶어 다양한 프라이빗 클라우드 플랫폼을 위한 검증된 턴키 솔루션을 제공합니다. 프라이빗 클라우드 솔루션 패키지를 사용하면 다른 플랫폼에도 복제할 수 있는 모델 배포 환경을 구축하여 여러 환경에서 더욱 통일되고 일관된 애플리케이션 제공 및 보안 서비스를 구현할 수 있습니다.
결론
IT 자동화 수준의 향상은 피할 수 없는 흐름입니다. 핵심 애플리케이션 전송 및 보안 서비스를 전략적으로 제공하면 조직에서 배포하는 애플리케이션의 보안과 가용성을 유지할 수 있습니다. 또한 자동화는 특히 여러 플랫폼과 퍼블릭 클라우드에서 작업할 때 운영 부담을 줄이는 데 도움이 됩니다.
적합한 자동화 시스템을 선택하는 일은 쉽지 않으며, 보유한 기술 역량과 시스템의 지원 가능성을 모두 고려해 협업을 바탕으로 종합적으로 결정하는 것이 바람직합니다. 어떤 솔루션을 선택하든 BIG-IP 플랫폼과 F5의 전문성을 활용하여 애플리케이션이 어디에 배포되어 있든 애플리케이션 운영에 필수적인 엔터프라이즈급 서비스를 제공할 수 있습니다.
2018년 2월 9일 게시