Kubernetes and Cloud Native Associate (KCNA) #5 Cloud Native Architecture (16%): 오토스케일링, 서버리스, 커뮤니티, 오픈 스탠다드

#4에서 컨테이너 런타임,보안,네트워킹,스토리지,Service Mesh까지, 쿠버네티스 아래에서 컨테이너를 떠받치는 계층을 정리했습니다. 이번 글은 시선을 한 단계 위로 끌어올립니다. 쿠버네티스라는 도구 자체가 아니라, 쿠버네티스가 속한 클라우드 네이티브라는 설계 사상과 그 생태계 전체를 묻는 도메인입니다.

KCNA의 Domain 3 Cloud Native Architecture는 비중 16%로, 시험의 여섯 분의 일가량을 차지합니다. 이 도메인은 명령어나 매니페스트가 아니라 왜 이렇게 설계하는가를 묻습니다. 왜 부하에 따라 자동으로 늘리고 줄이는가, 왜 인프라를 직접 관리하지 않는 서버리스를 쓰는가, 왜 CNCF라는 재단과 오픈 스탠다드가 중요한가. 이 글에서 그 사상과 어휘를 정리하겠습니다.

클라우드 네이티브란 무엇인가 #

이 도메인의 출발점은 클라우드 네이티브(cloud native)의 정의입니다. CNCF(Cloud Native Computing Foundation)는 클라우드 네이티브를 다음과 같이 정의합니다. 퍼블릭,프라이빗,하이브리드 클라우드 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 구축하고 실행하는 방식입니다. 그 대표 기술로 컨테이너, 서비스 메시, 마이크로서비스, 불변 인프라, 선언형 API를 꼽습니다.

시험에서는 이 정의를 구성하는 키워드 각각이 무엇을 뜻하는지 분류할 수 있어야 합니다.

이 정의를 떠받치는 운영 특성이 두 가지 더 있습니다.

• 자가 치유(self-healing). 컨테이너나 노드가 죽으면 시스템이 알아서 재생성하고 복구합니다. 쿠버네티스의 컨트롤러가 원하는 상태와 현재 상태의 차이를 계속 메우는 reconciliation 루프가 바로 자가 치유의 구현입니다.
• 회복탄력성(resilience). 일부 구성 요소가 실패해도 전체 시스템은 계속 동작하도록 설계합니다. 복제(replication), 장애 격리, 재시도가 그 수단입니다.

여기에 12-factor app이라는 클라우드 네이티브 애플리케이션 설계 원칙도 한 번쯤 들어 두면 좋습니다. 설정을 환경 변수로 분리하기, 애플리케이션을 상태 없는(stateless) 프로세스로 만들기, 로그를 이벤트 스트림으로 다루기 같은 12개 지침으로, 클라우드 위에서 확장과 배포가 쉬운 애플리케이션을 만드는 권고안입니다.

오토스케일링 #

클라우드 네이티브의 핵심 약속은 부하에 맞춰 자원을 자동으로 늘리고 줄인다는 것입니다. 쿠버네티스 생태계에는 이 자동 확장을 담당하는 메커니즘이 여러 층으로 나뉘어 있고, KCNA는 각각이 무엇을 조정하는지를 정확히 구분하는지 묻습니다.

HPA (Horizontal Pod Autoscaler) #

HPA는 Pod 의 개수를 수평으로 늘리고 줄입니다. CPU 사용률이나 메모리, 혹은 커스텀 메트릭이 설정한 목표치를 넘으면 Pod 복제본 수를 늘리고, 부하가 줄면 다시 줄입니다. “트래픽이 몰리면 동일한 Pod 를 여러 개 띄운다"가 HPA의 그림입니다. 가장 자주 쓰이고 시험에도 가장 많이 나오는 오토스케일러입니다.

VPA (Vertical Pod Autoscaler) #

VPA는 Pod 하나에 할당되는 리소스(CPU,메모리 requests/limits)를 수직으로 조정합니다. Pod 개수가 아니라 Pod 한 개의 크기를 키우거나 줄이는 방식입니다. 적정 리소스 요청량을 자동으로 추천하고 적용해, 과다 할당으로 인한 낭비나 과소 할당으로 인한 성능 저하를 줄입니다. HPA와 같은 메트릭(CPU,메모리)을 동시에 기준으로 삼으면 충돌하므로, 보통 둘을 같은 워크로드에 함께 쓰지 않습니다.

Cluster Autoscaler (CA) #

CA는 노드(node)의 개수를 조정합니다. Pod 가 스케줄될 자리가 없어 Pending 상태로 남으면 클라우드 제공자에게 노드를 추가로 요청하고, 노드가 비어 있으면 줄여서 비용을 절감합니다. HPA가 Pod 를 늘렸는데 그 Pod 를 올릴 노드가 부족할 때 CA가 노드를 보태는 식으로, HPA와 CA는 서로 다른 층에서 협력합니다.

KEDA (Kubernetes Event-Driven Autoscaling) #

KEDA는 이벤트 기반 오토스케일링을 담당하는 CNCF 프로젝트입니다. CPU,메모리뿐 아니라 메시지 큐의 적체 길이, Kafka 토픽의 lag, 데이터베이스 쿼리 결과 같은 외부 이벤트 소스를 메트릭으로 삼아 Pod 를 확장합니다. 특히 처리할 이벤트가 없을 때 Pod 를 0개까지 줄이는 scale-to-zero를 지원한다는 점이 핵심입니다. HPA는 기본적으로 최소 1개를 유지하지만, KEDA는 0까지 내려갔다가 이벤트가 들어오면 다시 띄웁니다.

네 가지 오토스케일러 비교 #

시험 포인트는 명확합니다. HPA는 수평(개수), VPA는 수직(크기), CA는 노드, KEDA는 이벤트와 scale-to-zero입니다. 이 한 줄을 헷갈리지 않으면 이 영역의 문항은 대부분 풀립니다. 실무에서 직접 띄워 본 흐름은 실무 트랙 중급 #6 오토스케일링에 정리해 두었습니다.

오토스케일링이 동작하는 원리 #

오토스케일링이 가능하려면 현재 부하를 측정하는 메트릭 출처가 있어야 합니다. HPA와 VPA는 클러스터의 metrics-server나 커스텀 메트릭 API에서 CPU,메모리 사용량을 읽어 와, 목표치와 현재값의 비율을 계산해 원하는 복제본 수를 산출합니다. 이렇게 산출한 값을 Deployment의 복제본 수에 반영하는 것이 HPA의 한 사이클입니다.

여기서 주의할 점은 오토스케일러도 선언형 모델 위에서 동작한다는 사실입니다. HPA는 “Pod 를 늘려라"라는 명령을 한 번 내리는 것이 아니라, 원하는 복제본 수를 계속 다시 계산해 현재 상태를 그 값으로 수렴시킵니다. 부하가 출렁일 때 Pod 수가 과도하게 진동하지 않도록 안정화 구간(stabilization window)을 두는 것도 이 때문입니다. 자가 치유와 마찬가지로, 오토스케일링 역시 reconciliation 루프의 한 형태로 이해하면 시험 문항의 맥락이 잘 잡힙니다.

서버리스 #

서버리스(serverless)는 인프라를 직접 관리하지 않고 코드(함수나 컨테이너)를 실행하는 모델입니다. 이름과 달리 서버가 없는 것이 아니라, 서버의 프로비저닝,확장,패치 같은 운영을 클라우드 제공자나 플랫폼이 대신 맡아 개발자가 서버를 의식하지 않는 모델이라는 뜻입니다.

서버리스의 특성은 다음과 같습니다.

• 요청이 없으면 0까지 줄어든다(scale-to-zero). 유휴 상태에서는 자원을 쓰지 않으므로 비용 효율이 높습니다.
• 사용한 만큼만 과금. 실행 시간과 호출 횟수 기준으로 비용이 매겨집니다.
• 이벤트 기반. HTTP 요청, 메시지 도착, 파일 업로드 같은 이벤트가 함수 실행을 촉발합니다.

FaaS와 Knative #

서버리스를 구현하는 대표 형태가 **FaaS(Function as a Service)**입니다. 함수 단위로 코드를 배포하면 플랫폼이 호출에 맞춰 실행하고 확장합니다. 퍼블릭 클라우드의 관리형 FaaS가 널리 쓰이지만, KCNA에서 더 중요한 것은 쿠버네티스 위에서 서버리스를 구현하는 프로젝트입니다.

• Knative. 쿠버네티스 위에 서버리스 워크로드를 올리기 위한 CNCF 플랫폼입니다. 요청이 없으면 Pod 를 0개로 줄였다가 요청이 들어오면 자동으로 다시 띄우는 scale-to-zero, 그리고 이벤트 라우팅(Eventing) 기능을 제공합니다. “쿠버네티스 위의 서버리스"를 묻는 문항의 정답은 거의 Knative입니다.
• OpenFaaS. 쿠버네티스 위에서 함수를 컨테이너로 패키징해 실행하는 또 다른 서버리스 프레임워크입니다.

서버리스는 언제 적합한가 #

서버리스는 트래픽이 들쭉날쭉하거나 간헐적인 워크로드, 이벤트에 반응하는 짧은 작업, 빠르게 만들어 띄워 보는 프로토타입에 잘 맞습니다. 반대로 항상 일정한 부하가 꾸준히 들어오거나, 콜드 스타트(cold start) 지연을 허용하기 어려운 저지연 서비스, 장시간 실행되는 작업에는 덜 적합합니다.

콜드 스타트는 0까지 줄어 있던 워크로드가 첫 요청에 다시 떠오르는 데 걸리는 지연을 말합니다. scale-to-zero가 비용을 아끼는 대신 치르는 대가이며, 서버리스의 대표적인 트레이드오프로 시험에 나오기 좋은 개념입니다.

커뮤니티와 거버넌스 #

클라우드 네이티브 생태계는 한 회사의 제품이 아니라 CNCF라는 오픈 거버넌스 재단 아래 수백 개 프로젝트가 모인 공동체입니다. KCNA는 이 커뮤니티의 구조를 묻습니다.

CNCF의 역할 #

CNCF는 리눅스 재단(Linux Foundation) 산하의 비영리 재단으로, 클라우드 네이티브 오픈 소스 프로젝트를 중립적으로 보유하고 육성하는 곳입니다. 특정 벤더가 프로젝트를 독점하지 못하도록 공급사 중립(vendor-neutral) 거버넌스를 유지하고, 프로젝트의 성숙도를 심사하며, 자격증과 교육 프로그램을 운영합니다. 쿠버네티스를 처음 CNCF에 기증한 곳이 구글이라는 사실도 가끔 출제됩니다.

프로젝트 성숙도 단계 #

CNCF 프로젝트는 성숙도에 따라 세 단계로 나뉩니다. 순서와 의미를 외워 두는 것이 이 영역의 핵심 시험 포인트입니다.

흐름은 Sandbox → Incubating → Graduated 입니다. 단계가 올라갈수록 채택률,안정성,거버넌스 성숙도 기준이 높아집니다. Graduated 졸업 프로젝트의 대표 예시는 다음과 같습니다.

• Kubernetes. 컨테이너 오케스트레이션. CNCF의 첫 졸업 프로젝트입니다.
• Prometheus. 메트릭 수집과 모니터링. 두 번째 졸업 프로젝트입니다.
• Envoy. 고성능 프록시이자 Service Mesh의 데이터 플레인.
• 그 밖에 containerd, Helm, etcd, Fluentd, ArgoCD, OpenTelemetry 등이 졸업 단계에 올라 있습니다.

오픈 거버넌스와 KubeCon #

CNCF 프로젝트는 한 회사가 아니라 여러 조직과 기여자가 함께 의사결정에 참여하는 오픈 거버넌스 모델로 운영됩니다. 메인테이너, 기여자, 커뮤니티가 공개된 절차로 로드맵을 정합니다. 이 커뮤니티가 모이는 대표 행사가 KubeCon + CloudNativeCon입니다. CNCF가 주최하는 클라우드 네이티브 생태계의 가장 큰 컨퍼런스로, 프로젝트 발표와 사례 공유가 이루어집니다.

오픈 스탠다드 #

클라우드 네이티브가 특정 벤더에 갇히지 않는 이유는 오픈 스탠다드(open standard) 덕분입니다. 표준 인터페이스가 정의되어 있으면, 구현체를 자유롭게 바꿔 끼워도 위층 시스템은 그대로 동작합니다. 이것이 벤더 락인(vendor lock-in)을 피하고 상호운용성(interoperability)을 확보하는 방식입니다.

KCNA에 나오는 주요 표준은 다음과 같습니다.

표준의 본질은 같습니다. **“위층은 표준 인터페이스만 알고, 아래층 구현체는 자유롭게 갈아 끼운다”**입니다. 예를 들어 쿠버네티스는 CRI라는 인터페이스만 알면 되므로, 그 뒤에 containerd가 있든 CRI-O가 있든 동일하게 동작합니다. CRI,CNI,CSI의 경계는 #4에서 자세히 다루었습니다. OCI가 이미지와 런타임을, CRI가 쿠버네티스와 런타임의 연결을 정의한다는 구분이 헷갈리기 쉬우니 분리해 두는 편이 안전합니다.

롤아웃과 배포 개념 #

클라우드 네이티브 아키텍처는 서비스를 멈추지 않고 새 버전으로 교체하는 배포 모델을 전제합니다. 쿠버네티스의 Deployment가 기본으로 제공하는 방식이 **롤링 업데이트(rolling update)**입니다.

• 롤링 업데이트. 기존 Pod 를 한꺼번에 죽이지 않고, 새 버전 Pod 를 하나씩 띄우면서 옛 버전 Pod 를 하나씩 내립니다. 이 과정에서 항상 일정 수의 Pod 가 트래픽을 받으므로 무중단(zero-downtime) 배포가 됩니다. 문제가 생기면 이전 버전으로 되돌리는 **롤백(rollback)**도 선언형으로 가능합니다.
• 불변 인프라. 실행 중인 컨테이너를 직접 고치지 않고, 새 이미지로 만든 새 Pod 로 통째 교체합니다. 같은 이미지에서 띄운 Pod 는 항상 같은 상태이므로, 환경 차이로 인한 문제를 줄이고 롤백을 단순하게 만듭니다.

이 두 개념은 클라우드 네이티브의 자가 치유,선언형 모델과 한 묶음입니다. 원하는 상태(버전 v2의 Pod 3개)를 선언하면 쿠버네티스가 현재 상태를 그 방향으로 무중단으로 수렴시키고, 그 과정에서 죽은 Pod 는 자동으로 다시 띄웁니다.

시험 포인트 정리 #

이 도메인에서 가장 자주 점수를 가르는 비교를 모았습니다.

• HPA vs VPA vs CA. HPA는 Pod 개수(수평), VPA는 Pod 리소스 크기(수직), CA는 노드 개수입니다. KEDA는 이벤트 기반에 scale-to-zero입니다.
• 프로젝트 성숙도 단계 순서. Sandbox → Incubating → Graduated. 단계가 올라갈수록 채택률과 안정성 기준이 높습니다.
• 서버리스 정의. 서버가 없는 것이 아니라 서버 운영을 의식하지 않는 모델. 쿠버네티스 위 서버리스는 Knative, scale-to-zero가 핵심.
• 오픈 스탠다드 구분. OCI(이미지,런타임), CRI(런타임 연결), CNI(네트워크), CSI(스토리지), OTel(텔레메트리). 표준의 목적은 벤더 락인 회피와 상호운용성.
• CNCF의 성격. 리눅스 재단 산하 공급사 중립 거버넌스. KubeCon이 대표 행사.

자주 만나는 함정 #

• HPA와 VPA를 같은 메트릭으로 동시에 건다. 둘 다 CPU,메모리를 기준으로 삼으면 한쪽이 크기를 늘리는 동안 다른 쪽이 개수를 줄이는 충돌이 생깁니다. 보기에서 이 조합을 정상 구성으로 제시하면 함정입니다.
• scale-to-zero를 HPA의 기본 기능으로 착각한다. 기본 HPA는 최소 1개를 유지합니다. 0까지 줄이는 것은 KEDA나 Knative의 특성입니다.
• 성숙도 단계 순서를 뒤집는다. Sandbox가 가장 초기, Graduated가 가장 성숙입니다. Incubating을 가장 높은 단계로 고르는 보기가 자주 섞입니다.
• OCI와 CRI를 같은 표준으로 묶는다. OCI는 이미지,런타임 포맷 규격이고, CRI는 쿠버네티스 kubelet과 런타임을 잇는 인터페이스입니다. 층이 다릅니다.

정리 #

이번 글에서 잡은 것:

• 클라우드 네이티브. 컨테이너,마이크로서비스,선언형 API,불변 인프라,서비스 메시. 자가 치유와 회복탄력성이 운영 특성
• 오토스케일링. HPA(Pod 수평),VPA(Pod 수직),CA(노드),KEDA(이벤트,scale-to-zero) 네 층의 구분
• 서버리스. 인프라를 의식하지 않는 실행 모델. Knative와 FaaS, scale-to-zero
• 커뮤니티. CNCF의 공급사 중립 거버넌스, Sandbox → Incubating → Graduated 성숙도 단계, KubeCon
• 오픈 스탠다드. OCI,CRI,CNI,CSI,SMI,OpenTelemetry. 벤더 락인 회피와 상호운용성
• 롤아웃. 롤링 업데이트로 무중단 배포, 불변 인프라로 통째 교체

쿠버네티스 입문이 처음이라면 실무 트랙 #1에서 클러스터를 직접 띄우는 흐름을 먼저 익히는 편이 이 개념들을 체화하는 지름길입니다.

다음: Cloud Native Observability #

설계 사상과 생태계까지 정리했습니다. 이제 그 위에서 운영 중인 시스템을 어떻게 들여다보는가로 넘어갑니다.

#6 Cloud Native Observability (8%): 텔레메트리, Prometheus, 비용 관리에서는 텔레메트리의 세 기둥(메트릭,로그,트레이스), Prometheus를 통한 메트릭 수집, SLI,SLO,SLA, 그리고 비용 관리(FinOps) 개념까지 정리하겠습니다.