효과를 낼 시간
이 블로그는 “대규모 Kubernetes 클러스터를 운영하기 위한 좋은 제어 평면은 무엇인가” 에 대한 후속 글입니다. 이전 블로그에서는 Volterra의 고유한 Fleet Operations 접근 방식을 설명하여 인프라 사이트와 애플리케이션을 관리하는 방법을 설명했습니다. 이 특정 블로그에서는 다수의 클러스터나 사이트에서 구성을 변경할 때 운영 팀이 직면하는 구성 드리프트의 주요 과제에 대해 설명합니다. 저는 이 도전을 "효과를 낼 시간"이라고 부릅니다.
효과 발생 시간이란 무엇입니까?
이는 작업의 의도가 효과를 발휘하는 데 걸리는 시간으로 간단히 설명할 수 있습니다. 예를 들면 다음과 같습니다.
- 모든 사이트에 보안 정책 구성이 적용되는 데 얼마나 걸리나요?
- 내 애플리케이션의 최신 버전이 모든 사이트에 전파되는 데 얼마나 걸리나요?
- 전 세계에 분산된 모든 사이트에서 운영 체제나 인프라 소프트웨어를 업그레이드하는 데 얼마나 걸릴까요?
왜 중요한가요?
이 질문은 몇 가지 실제 고객 사례를 통해 답할 수 있습니다.
- 멜트다운과 스펙터 — 멜트다운/스펙터 소식이 알려진 후 모든 CISO의 최우선 관심사는 모든 인프라의 운영 체제를 신속하게 패치하는 방법이었습니다. 운영 팀은 의도(즉, OS 버전 업그레이드)가 적용되는 시점까지 매 시간 측정을 받고 있었습니다.
- 대학에 서비스 거부 공격을 일으킨 자판기 함대에 대해 들어보셨을 겁니다. 공격을 이해하지 못했을 경우를 대비해 간단히 설명드리자면, 해커들은 제로데이 취약점을 악용해 다른 자판기와 연결된 맬웨어를 설치하고 자판기 봇 함대를 만들었습니다. 그런 다음 엄청난 양의 트래픽을 전송하여 대학에 서비스 거부 공격을 일으켰습니다. 공격을 감지한 대학에서는 명령 및 제어 서버에 대한 접근을 막기 위해 각 자판기의 네트워크 정책 규칙을 하나씩 구성해야 했습니다. 그들에게는 출혈을 멈추기 위해 자신의 의도(즉, 특정 웹사이트에 대한 접근 차단)를 모든 자판기에 즉시 적용하는 것이 매우 중요했습니다.
적용 시간은 인프라 소프트웨어, 애플리케이션 소프트웨어, 네트워크 정책, 보안 정책 등 여러 범주에 중요합니다.
무엇이 과제인가요?
운영팀이 다음과 같은 문제를 관리해야 할 때 문제의 심각성을 가장 많이 경험하게 됩니다.
- 대규모 사이트
- 전 세계적으로 분산된 사이트
- 이기종 환경, 즉 개인, 공공, 통신사 클라우드 및 에지 장치의 사이트
- 사이트의 연결성이 일관되지 않음
자동차 OEM의 소프트웨어 업데이트와 자동차 연결성 관리를 담당하는 운영 팀의 좋은 예입니다(이하 고객 사이트라고 함). 일반적인 배치에는 운영팀이 전 세계적으로(또는 조직 구조에 따라 지역적으로) 자동차를 제어하는 개인 데이터 센터가 포함됩니다.
과제를 이해하기 위해 운영팀이 활용할 수 있는 솔루션을 살펴보겠습니다. 대부분의 솔루션은 고객의 개인 데이터 센터에 호스팅된 관리 소프트웨어를 제공하여 대규모 분산 사이트를 중앙에서 관리합니다. 자동차 OEM이 모든 자동차에 적용해야 할 정책을 구성할 때, 중앙 관리 소프트웨어는 기본적으로 각 자동차에 하나씩 구성 스크립트를 다운로드합니다. 구성 스크립트는 각 사이트에서 일련의 구성 명령을 실행하는 Ansible 플레이북이나 Helm 차트가 될 수 있습니다. 이는 아래 다이어그램과 같이 시각화할 수 있습니다.
문제는 효과 발생 시간이 사이트 수에 정비례한다는 것입니다. 중앙 관리 소프트웨어 공급업체는 모든 작업을 원격으로 자동화된 방식으로 수행할 수 있다면 이것이 최선이라고 주장합니다.
볼테라는 이에 반대하며, 우리는 이 블로그에서 그것을 증명할 수 있습니다. 우리는 효과 발생 시간을 최소화하도록 설계된 계층적, 확장형 아키텍처 방식을 갖춘 분산 제어 평면을 구축했습니다.
최소 시간 내에 효과를 낼 수 있는 Volterra 아키텍처
효과 발생 시간을 최소화하기 위한 기본 구성 요소는 다음과 같습니다.
- 계층적 트리 기반 아키텍처
- 목적에 맞게 구축된 분산 제어 평면
다음은 개략적인 아키텍처 개요입니다.
Volterra의 계층적 아키텍처 접근 방식은 구성 배포를 위한 노드 트리를 만드는 것입니다. 각 노드는 저장 및 전달을 수행합니다. 즉, 구성을 로컬에 저장한 다음 자식으로 전달합니다. 이를 가장 잘 설명하려면 예를 들어 설명하면 됩니다. 사용자가 Volterra 콘솔에서 네트워크 정책과 같은 객체를 구성하면 제어 및 관리 평면은 해당 구성을 직접적인 자식인 지역 에지(RE)에 배포합니다. 각 RE는 구성을 로컬에 저장하고 자식에게 전달합니다. RE의 자식 사이트는 해당 RE에 연결된 고객 사이트입니다.
계층적 트리 기반 아키텍처는 효과 발생 시간을 최소화합니다. 적용 시간은 트리의 레벨 수와 노드당 자식 수에 따라 제한됩니다. 트리의 최대 레벨 수는 3입니다(컨트롤러 → RE → 고객 사이트). 노드당 자식의 수는 RE에 연결된 사이트의 수에 정비례합니다. 사이트 집합에 대한 구성을 처리하기 위해 RE에 서비스 인스턴스가 생성됩니다. Volterra의 확장형 제어 평면은 RE에 연결된 사이트 수가 증가하면 주문형으로 새로운 서비스 인스턴스를 생성합니다.
테스트 설정
효과 측정 시간은 뉴욕(NY8-NYC)과 파리(PA4-PAR)에 위치한 두 지역 에지에 연결된 많은 고객 사이트에서 수행되었습니다. 고객 사이트는 산타클라라(캘리포니아), 휴스턴(텍사스), 마드리드(스페인), 프라하(체코), 런던(영국) 등 전 세계에 분산되어 있습니다. 또한 고객 사이트는 AWS, 가상 머신(ESXi), Intel NUC 및 Fitlet2를 포함한 Edge Gateway 등 이기종 환경에 걸쳐 있었습니다.
Volterra의 고객 포털과 글로벌 제어 평면은 Azure(Washington-IAD)에서 실행되었습니다. 고객 사이트는 실제 운영 환경을 나타내기 위해 여러 네임스페이스와 테넌트에 분산되었습니다.
RE의 서비스 인스턴스를 중단하고 RE와 고객 사이트 간에 품질이 낮은 연결 링크를 사용하여 장애 조건을 시뮬레이션했습니다. 그림 3에서는 단일 네임스페이스에서 전체 함대의 세그먼트에 대한 스냅샷 보기를 보여줍니다.
테스트 방법론
Volterra 콘솔에서 개체가 구성되고 각 고객 사이트에 구성이 적용될 때마다 타임스탬프가 포함된 감사 로그가 Volterra 시스템에 캡처됩니다. 전파 시간은 포털의 구성과 고객 사이트에 구성을 적용하는 데 걸리는 시간 차이로 측정되었습니다. 단계별 자세한 프로세스는 다음과 같습니다.
- 고객 포털에서 객체를 구성합니다.
- 고객 포털에서 객체 생성 시간을 시작 시간으로 측정합니다(이하 Volterra 글로벌 컨트롤러라고 함). 예를 들어 그림 4를 참조하세요.
- 고객 사이트에서 객체 생성 시간을 종료 시간으로 측정합니다. 예를 들어 그림 5를 참조하세요.
표시된 스크린샷은 샘플링된 것이며 동일한 측정 반복을 참조하지 않습니다.
구성 시작 시간
구성 종료 시간
테스트 결과
전파시간의 테스트 결과는 그림 6과 7에 나타나 있다. 그림 6의 그래프는 대부분 측정 샘플의 전파 시간이 0~400ms 사이였음을 나타냅니다. 즉, 모든 고객 사이트는 0~400ms 사이에 새로운 구성으로 업데이트됩니다. 앞서 언급했듯이, RE에서 서비스를 다시 시작하고 고객 사이트에서 연결 장애/지연을 발생시키는 방식으로 장애 조건을 시뮬레이션했습니다. 이러한 장애 조건에서는 구성 전파 시간이 더 길었고, 이러한 특정 테스트에서는 장애 유형에 따라 600ms에서 9초까지 다양했습니다. 예를 들어, RE와 고객 사이트 간의 연결 장애로 인해 구성이 고객 사이트에 도달하는 데 시간이 더 오래 걸립니다. 그러나 Volterra의 분산 제어 평면의 이점은 결국 일관된 구성의 패러다임을 따른다는 것입니다. 즉, 모든 고객 사이트의 구성이 고객이 정의한 의도에 맞춰져 있는지 확인하기 위해 계속해서 재시도합니다.
그림 7의 그래프는 85%의 경우 모든 고객 사이트가 322밀리초 이내에 새로운 구성으로 업데이트된다는 것을 나타냅니다. 장애 조건이 도입되는 상황에서는 일부 고객 사이트에서 약 3~9초의 전파 시간을 경험할 수 있습니다.
부인 성명: 이러한 측정은 시뮬레이션된 토폴로지, 규모, 배포 환경 및 장애 상황과 밀접하게 연관되어 있습니다. 우리는 가능한 모든 실패 상황이나 기타 환경을 측정하지 않았습니다. 따라서 테스트되지 않은 다른 상황이나 환경에서의 전파 지연에 대해서는 주장할 수 없습니다. 예를 들어, Kubernetes 클러스터에 장애가 발생하면 시스템은 장애 감지, 재시작 및 구성 재시도를 기다려야 하므로 전파 지연 시간이 길어집니다.