컨테이너 세계에서는 선언적 구성이 왕이다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

내부의 디지털 혁신은 외부의 디지털 혁신을 실현하는 데 필수적입니다. 내부 디지털 혁신의 기반 요소 중 하나는 자동화이며, 이는 제어 플레인에 크게 의존합니다. 제어 플레인은 자동화가 이루어지는 곳입니다. 과거 컴퓨팅 환경에서는 이를 ‘관리 네트워크’라고 불렀으며, SNMP와 같은 프로토콜을 사용해 모니터링, 구성 및 제어를 수행했습니다.

오늘날에도 관리 네트워크는 적어도 이론상으로는 여전히 존재하며, 제어 플레인을 통해 동일한 작업을 수행하는 매개체 역할을 합니다. 제어 플레인은 API, 마스터 노드, 심지어 메시지 큐까지 뒤얽힌 복잡한 영역으로, 복잡한 분산 시스템의 개별 구성 요소가 스스로를 (거의) 자동으로 관리할 수 있게 해 줍니다. 제어 플레인은 점점 더 이벤트 중심으로 변화하고 있으며, 이에 따라 주로 명령형 관리 모델에 의존했던 과거의 중앙 집중식 명령 및 제어 모델에서 벗어나 사고방식을 전환해야 합니다. 즉, 중앙 시스템이 특정 API 호출을 통해 구성 요소에 암묵적으로 지시하여 변경이 일어나게 하는 방식입니다. 반면 오늘날의 환경은 스스로를 변경할 책임을 분산하는 선언형 모델에 의존합니다.

이러한 특성이 컨테이너화된 환경보다 더 뚜렷하게 드러나는 시스템은 없습니다. 외부에서 보면 이러한 시스템은 거의 제멋대로 작동하는 것처럼 보입니다. 메시지와 이벤트가 무질서하게 게시되고 발생하지만, 누가 또는 무엇이 이에 반응해야 하는지 지시하는 중앙 통제자는 없습니다. 이제 컨트롤 플레인은 통제보다는 분산에 더 가깝고, 그 구조도 구식 관리 시스템의 허브 앤드 스포크 아키텍처보다는 메시 형태에 가깝습니다. 전통적인 환경에서는 API와 프로토콜을 사용해 구성 요소에 변경 사항을 푸시했습니다. 반면 디지털 컨테이너 환경에서는 구성 요소가 스스로 변경하는 데 필요한 정보를 API를 통해 가져옵니다.

이 새로운 세계는 반응형으로 작동하며 기존 제어 플레인의 명령형(API 기반) 모델을 지양하고, 그 대신 더 개방적인 선언형 모델을 통해 원하는 자동화된 최종 상태를 구현합니다.

이는 놀라운 일이 아닙니다. DevOps, 클라우드, NFV라는 기치 아래 모든 것에 소프트웨어 중심 접근 방식을 점점 더 많이 도입하면서, 동시에 방대한 운영 규모도 감당해야 했기 때문입니다. 허브 앤 스포크 방식의 명령형 관리 모델은 효율적으로 확장되지 않습니다. 거의 무한대에 가까운 구성 요소들과 복잡하고 다양한 API를 통해 통신할 수 있는 중앙 컨트롤러가 모든 변경 작업을 떠맡기 때문입니다. 이는 관리자(컨트롤러)가 영향을 받는 각 구성 요소에 변경 사항을 전달하는 ‘푸시’ 모델입니다. 결국 이 관리자가 전체 시스템의 성패를 좌우하는 병목 지점이 됩니다.

확장성을 확보하고 컨트롤러의 부담을 줄이려면 구성 요소가 변경 사항을 가져오는 방식에 의존하는 이벤트 기반 모델이 필요합니다. 그러려면 이 컨트롤 플레인에 참여하려는 구성 요소가 선언적 구성 모델을 원활하게 지원할 수 있어야 합니다. 컨테이너로 인해 API를 통해 변경 사항을 푸시하는 명령형 방식 대신, 선언적 구성을 통해 변경 사항을 가져오는 방식으로 전환되고 있기 때문입니다. 오픈 소스든 상용이든 구성 요소 제공업체는 변경 사항을 올바르게 구독한 다음, 해당 변경 사항을 즉시 적용하는 데 필요한 적절한 정보를 가져와야 할 책임이 있습니다.

이것이 코드형 인프라처럼 들린다면 제대로 이해한 것입니다. 선언적 구성은 기본적으로 코드이거나, 적어도 코드 산출물입니다. 자동화는 구성과 해당 서비스를 분리한다는 전제에 점점 더 의존하고 있습니다. 이상적인 유토피아 모델에서는 이러한 선언적 구성이 특정 제품이나 공급업체에 전혀 종속되지 않습니다. 즉, 해당 서비스를 지원하는 모든 공급업체의 제품(상용 또는 오픈 소스)이 이를 읽을 수 있어야 합니다. 예를 들어, 적절한 서비스(가상 서버)와 해당 리소스 풀을 구성하는 앱을 기술한 선언적 구성은 서비스 X나 서비스 Y에서 수집하여 구현할 수 있어야 합니다.

Kubernetes 리소스 파일은 무엇을 원하는지는 기술하지만, 어떻게 구현할지는 규정하지 않는 선언적 구성 모델의 좋은 예입니다. 이는 원하는 결과를 달성하기 위한 방법을 구현체가 때로는 속속들이 알고 있어야 하는 인프라 API 기반 시스템과는 확연히 다릅니다.

선언적 모델을 사용하면 인프라를 가축처럼 취급할 수도 있습니다. 하나에 장애가 발생하면 간단히 종료하고 새 인스턴스를 시작하면 됩니다. 필요한 모든 구성은 리소스 파일에 들어 있습니다. 잃어버릴 작업 자체가 없으므로 “작업을 저장하지 않으면 손실됩니다”라는 버튼도 없습니다. 이는 거의 불변 인프라이자 명백한 일회용 인프라이며, 장애의 영향을 최소화하기 위해 분 단위, 아니 초 단위로 변화하는 시스템에 반드시 필요합니다.

규모가 크고, 감히 말하자면 보안까지 갖춘 자동화 시스템으로 점차 전환해 감에 따라, 애플리케이션 데이터 경로를 구성하는 수많은 장치와 서비스를 관리하기 위해 선언적 모델을 수용해야 합니다. 그렇지 않으면 수동 통합 및 자동화 방식으로 인해 누적된 운영 부채의 눈사태에 파묻힐 위험이 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물