이 블로그는 “다수의 Kubernetes 클러스터를 운영하기에 적합한 컨트롤 플레인이란 무엇인가”의 후속 글입니다. 이전 블로그에서는 인프라 사이트와 애플리케이션으로 구성된 플릿을 관리하는 Volterra만의 고유한 플릿 운영 방식을 설명했습니다. 이번 블로그에서는 운영 팀이 다수의 클러스터 또는 사이트에 걸쳐 구성을 변경할 때 직면하는 핵심 과제인 구성 드리프트를 다룹니다. 저는 이 과제를 “적용 소요 시간(Time to Effect)”이라고 부릅니다.
적용 소요 시간이란 무엇인가?
간단히 말해, 작업의 의도가 실제로 반영되기까지 걸리는 시간을 의미합니다. 예를 들면 다음과 같습니다:
- 내 보안 정책 구성이 모든 사이트에 적용되기까지 얼마나 걸리나요?
- 내 애플리케이션의 최신 버전이 모든 사이트에 배포되는 데 얼마나 걸리나요?
- 전 세계에 분산된 모든 사이트의 운영 체제 또는 인프라 소프트웨어를 업그레이드하는 데 얼마나 걸리나요?
왜 중요한가요?
이 질문은 몇 가지 실제 고객 사례를 통해 답할 수 있습니다:
- Meltdown과 Spectre — Meltdown/Spectre 소식이 알려진 후 모든 CISO의 최대 관심사는 전체 인프라의 운영 체제를 얼마나 신속하게 패치할 수 있느냐였습니다. 운영팀은 의도한 변경 사항(즉, OS 버전 업그레이드)이 적용되기까지 걸리는 시간을 기준으로 매시간 평가받았습니다.
- 대학교를 대상으로 서비스 거부 공격을 일으킨 자판기 무리에 대해 들어보셨을 겁니다. 해당 공격을 접하지 못한 분들을 위해 간단히 요약하면, 해커들이 제로데이 취약점을 악용해 악성코드를 설치했고, 이 악성코드는 다른 자판기들과 연결되어 자판기 봇 군단을 만들었습니다. 이후 엄청난 양의 트래픽을 전송해 대학교에 서비스 거부 공격을 일으켰습니다. 공격을 탐지한 대학교는 명령 및 제어 서버에 대한 접근을 차단하기 위해 각 자판기에 네트워크 정책 규칙을 하나씩 설정해야 했습니다. 피해 확산을 막으려면 모든 자판기에서 의도한 조치(즉, 특정 웹사이트에 대한 접근 차단)가 즉시 적용되는 것이 매우 중요했습니다.
효력 발생 시간은 인프라 소프트웨어, 애플리케이션 소프트웨어, 네트워크 정책, 보안 정책 등 여러 범주에서 중요합니다.
어떤 과제가 있나요?
운영팀이 관리 업무를 수행해야 할 때 이 문제의 심각성이 가장 크게 체감됩니다.
- 대규모 사이트
- 전 세계에 분산된 사이트
- 이기종 환경, 즉 프라이빗 클라우드, 퍼블릭 클라우드, 통신사 클라우드 및 엣지 디바이스에 위치한 사이트
- 사이트의 불안정한 연결
이러한 운영 팀의 좋은 예로는 자동차의 소프트웨어 업데이트와 연결성 관리를 담당하는 자동차 OEM의 운영 팀을 들 수 있습니다(이하 자동차를 고객 사이트라고 함). 일반적인 배포 환경에는 운영 팀이 전 세계(또는 조직 구조에 따라 특정 지역)의 자동차를 제어하는 프라이빗 데이터 센터가 포함됩니다.
이 과제를 이해하기 위해 운영 팀이 활용할 수 있는 솔루션을 살펴보겠습니다. 대부분의 솔루션은 고객의 프라이빗 데이터 센터에 호스팅되는 관리 소프트웨어를 제공하여 대규모 분산 사이트를 중앙에서 관리합니다. 자동차 OEM이 모든 차량에 적용해야 하는 정책을 구성하면 중앙 관리 소프트웨어는 기본적으로 각 차량에 구성 스크립트를 하나씩 다운로드합니다. 구성 스크립트는 각 사이트에서 일련의 구성 명령을 실행하는 Ansible 플레이북이나 Helm 차트일 수 있습니다. 이는 아래 다이어그램과 같이 시각화할 수 있습니다.
문제는 효과가 나타나기까지 걸리는 시간이 사이트 수에 정비례한다는 점입니다. 중앙 집중식 관리 소프트웨어 공급업체들은 모든 작업을 원격으로 자동 수행할 수만 있다면 이것이 달성 가능한 최선이라고 주장할 것입니다.
Volterra는 이에 동의하지 않으며, 이 블로그에서 그 근거를 제시하겠습니다. 당사는 효과 발현 시간(Time to Effect)을 최소화하도록 설계된 계층적 스케일아웃 아키텍처 방식의 분산형 컨트롤 플레인을 구축했습니다.
효과 발현 시간을 최소화하는 Volterra 아키텍처
효과 발현 시간을 최소화하기 위한 핵심 구성 요소는 다음과 같습니다:
- 계층적 트리 기반 아키텍처
- 특정 목적에 맞게 설계된 분산형 제어 플레인
다음은 상위 수준의 아키텍처 개요입니다.
Volterra의 계층형 아키텍처는 구성 배포를 위한 노드 트리를 생성하는 방식입니다. 각 노드는 저장 후 전달(store and forward)을 수행합니다. 즉, 구성을 로컬에 저장한 다음 하위 노드로 전달합니다. 예를 들어 설명하면 가장 이해하기 쉽습니다. 사용자가 Volterra Console에서 네트워크 정책과 같은 객체를 구성하면 제어 및 관리 플레인이 바로 아래의 하위 노드인 리전 에지(RE)에 해당 구성을 배포합니다. 각 RE는 구성을 로컬에 저장한 후 하위 노드로 전달합니다. RE의 하위 노드는 해당 RE에 연결된 고객 사이트입니다.
계층적 트리 기반 아키텍처는 적용 시간(Time to Effect)을 최소화합니다. 적용 시간은 트리의 계층 수와 노드당 하위 노드 수에 따라 결정됩니다. 트리의 최대 계층 수는 3개입니다(컨트롤러 → RE → 고객 사이트). 노드당 하위 노드 수는 RE에 연결된 사이트 수에 정비례합니다. 여러 사이트의 구성을 처리하기 위해 RE에 서비스 인스턴스가 생성됩니다. RE에 연결된 사이트 수가 증가하면 Volterra의 스케일아웃 제어 플레인이 필요에 따라 새로운 서비스 인스턴스를 생성합니다.
테스트 환경
효과 발생 시간(Time to Effect)은 뉴욕(NY8-NYC)과 파리(PA4-PAR)에 위치한 두 리전 엣지에 연결된 대규모 고객 사이트를 대상으로 측정했습니다. 고객 사이트는 산타클라라(캘리포니아), 휴스턴(텍사스), 마드리드(스페인), 프라하(체코), 런던(영국) 등 전 세계에 분산되어 있었습니다. 또한 고객 사이트는 AWS, 가상 머신(ESXi), Intel NUC 및 Fitlet2를 포함한 엣지 게이트웨이 등 다양한 환경으로 구성되어 있었습니다.
Volterra의 고객 포털과 글로벌 제어 플레인은 Azure(워싱턴-IAD)에서 실행되었습니다. 실제 운영 환경을 재현하기 위해 고객 사이트는 여러 네임스페이스와 테넌트에 분산되었습니다.
RE에서 서비스 인스턴스를 종료하고 RE와 고객 사이트 간에 품질이 낮은 연결 링크를 사용하여 장애 상황을 시뮬레이션했습니다. 단일 네임스페이스에 속한 전체 플릿의 일부를 특정 시점에 캡처한 모습이 그림 3에 나와 있습니다.
테스트 방법론
Volterra 콘솔에서 객체를 구성하고 각 고객 사이트에 구성을 적용할 때마다 타임스탬프가 포함된 감사 로그가 Volterra 시스템에 기록됩니다. 전파 시간은 포털에서 구성을 설정한 시점부터 고객 사이트에 해당 구성이 적용된 시점까지의 시간 차이로 측정했습니다. 자세한 단계별 절차는 다음과 같습니다.
- 고객 포털에서 객체를 구성합니다.
- 고객 포털(이하 Volterra Global Controller)에서 객체가 생성된 시간을 시작 시간으로 측정합니다. 예시는 그림 4를 참조하십시오.
- 종료 시간은 고객 사이트에서 객체가 생성된 시간으로 측정합니다. 예시는 그림 5를 참조하십시오.
표시된 스크린샷은 예시로 추출된 것이며 동일한 측정 반복 회차를 나타내지 않습니다.
구성 시작 시간
구성 종료 시간
테스트 결과
전파 시간에 대한 테스트 결과는 그림 6과 7에 나와 있습니다. 그림 6의 그래프를 보면 대부분의 측정 샘플에서 전파 시간이 0~400ms 사이였습니다. 이는 모든 고객 사이트가 0~400ms 이내에 새 구성으로 업데이트된다는 의미입니다. 앞서 언급했듯이 RE에서 서비스를 다시 시작하고 고객 사이트에 연결 장애/지연을 발생시켜 장애 상황을 시뮬레이션했습니다. 이러한 장애 상황에서는 구성 전파 시간이 더 길어졌으며, 해당 테스트에서는 장애 유형에 따라 600ms에서 9초까지 걸렸습니다. 예를 들어 RE와 고객 사이트 간에 연결 장애가 발생하면 구성이 고객 사이트에 도달하는 데 걸리는 시간이 늘어납니다. 하지만 Volterra의 분산 제어 플레인은 최종적으로 일관된 구성 패러다임을 따른다는 이점이 있습니다. 즉, 모든 고객 사이트의 구성이 고객이 정의한 의도에 부합하도록 계속 재시도합니다.
그림 7의 그래프에 따르면 85%의 경우 모든 고객 사이트가 322밀리초 이내에 새 구성으로 업데이트됩니다. 장애 상황이 발생하면 일부 고객 사이트에서는 전파에 약 3~9초가 걸릴 수 있습니다.
면책 조항: 이 측정 결과는 시뮬레이션에 사용된 토폴로지, 규모, 배포 환경 및 장애 상황과 밀접하게 연관되어 있습니다. 가능한 모든 장애 상황이나 다른 환경을 측정한 것은 아닙니다. 따라서 테스트하지 않은 다른 상황이나 환경에서의 전파 지연에 대해서는 단정할 수 없습니다. 예를 들어 Kubernetes 클러스터에 장애가 발생하면 시스템은 장애 감지, 재시작 및 구성 재시도를 기다려야 하므로 전파 지연이 더 길어질 수 있습니다.
관련 블로그
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.