blog,Cloud Native,미분류

한마디로: 인력이 아니라 자동화로 인프라를 확장한 실제 수치가 담긴 초대규모 사례입니다.

대규모 서비스를 운영하는 조직은 대부분 같은 벽에 부딪힙니다. 트래픽과 서비스 수가 늘면 클러스터가 늘고, 클러스터가 늘면 이를 관리할 사람도 비례해서 늘어난다는 통념입니다. LY Corporation의 사례가 주목받는 이유는 이 통념을 정면으로 반박하기 때문입니다. 이 회사는 e커머스, 포털, 메신저, 엔터테인먼트까지 수백 개의 웹 애플리케이션 프로젝트를 프라이빗 인프라 위에서 돌립니다. 그런데도 인프라 컨트롤 플레인을 담당하는 플랫폼 엔지니어는 15명에 그칩니다. (출처: CNCF Case Study)

배경에는 통합이라는 사건이 있습니다. LINE의 프라이빗 클라우드 Verda는 2016년에 시작해 OpenStack과 Kubernetes를 함께 써 왔고, 발표 시점 기준으로 13만여 대의 VM과 1만여 대의 호스트, “4백만 코어”에 이르는 규모까지 커졌습니다. (출처: LINE Engineering) 여기에 Yahoo! JAPAN의 인프라가 합쳐지면서, 두 초대형 인터넷 서비스의 클라우드를 하나로 묶는 차세대 플랫폼 Flava 프로젝트가 진행됐습니다. Yahoo! JAPAN 쪽만 해도 164개의 OpenStack 클러스터를 단일화하는 대규모 정리 작업이 함께 있었습니다. (출처: LY Corporation Tech Blog) 이 규모의 통합에서 “사람을 더 뽑아 감당한다”는 선택지는 애초에 없었습니다.

그래서 이 사례를 읽는 우리 조직은 자신에게 먼저 물어야 합니다. 지금 클러스터가 두 배로 늘면 운영 인력도 두 배가 되어야 하는가. 그렇다면 확장 전략의 전제부터 다시 점검해야 합니다.

한마디로: 사람이 손으로 처리하던 프로비저닝·복구·패치가 확장의 진짜 병목이었습니다.

통합 이전의 방식에서 가장 큰 병목은 수작업이었습니다. 새 클러스터나 노드를 준비하는 데에만 1주 이상이 걸렸고, 이 리드 타임이 서비스 확장의 속도를 그대로 결정했습니다. 노드에 장애가 나면 복구에 며칠이 들었고, 그동안 용량은 비어 있는 채로 남았습니다. 더 위험한 것은 패치였습니다. 보안 패치가 늦어지면 그만큼 취약점에 노출되는 창(window)이 길어지는데, 노드가 수만 대라면 이 지연은 곧바로 조직 전체의 보안 리스크로 번집니다. (출처: CNCF Case Study)

문제의 본질은 개별 작업이 느리다는 데 있지 않았습니다. 작업의 구조가 사람의 개입을 전제로 짜여 있다는 점이 핵심이었습니다. 프로비저닝, 복구, 패치, 순환이 모두 “누군가 콘솔에 접속해 절차를 밟는” 방식으로 설계되어 있으면, 규모가 커질수록 사람이 병목이 됩니다. 여러 프로젝트가 저마다 VM과 클러스터를 직접 관리하던 구조에서는 같은 작업이 프로젝트마다 중복됐고, 운영 품질도 팀마다 제각각이었습니다. (출처: CNCF Case Study)

이 지점에서 우리 조직은 “느린 작업을 빠르게” 만드는 대신 “사람이 개입하지 않아도 되는 구조”로 바꿀 수 있는지를 먼저 결정해야 합니다. 개별 속도 개선만으로는 수만 대 규모에서 반드시 다시 막힙니다.

한마디로: 클러스터의 원하는 상태를 CRD로 선언하면 컨트롤러가 실제 상태를 맞춰 줍니다.

LY Corporation이 택한 해법은 Kubernetes의 쓰임새 자체를 바꾸는 것이었습니다. 보통 Kubernetes는 애플리케이션(파드)을 올려 돌리는 오케스트레이터로 씁니다. 이 회사는 여기서 한 층 위로 올라가, 인프라 그 자체를 관리하는 컨트롤 플레인(control plane, 시스템의 원하는 상태를 지속적으로 실제 상태에 반영하는 제어 계층)으로 Kubernetes를 사용합니다. (출처: CNCF Case Study)

핵심 도구는 CRD(Custom Resource Definition, Kubernetes에 새로운 리소스 타입을 추가하는 확장 기능)와 커스텀 컨트롤러입니다. 이 회사는 KubernetesCluster라는 커스텀 리소스를 정의해, 클러스터가 어떤 버전과 규모로 존재해야 하는지를 하나의 선언으로 표현합니다. 운영자가 이 리소스를 생성하면, 커스텀 컨트롤러가 그 원하는 상태(desired state)와 실제 상태의 차이를 계산해 클러스터를 만들고, 노드를 붙이고, 필요한 구성 요소를 채워 넣습니다. 사람이 절차를 밟는 대신, 선언과 실제의 차이를 좁히는 제어 루프(reconcile loop)가 이 일을 대신합니다.

apiVersion: infra.ly.example/v1
kind: KubernetesCluster
metadata:
  name: workload-tokyo-042
spec:
  version: "1.31"
  nodePools:
    - name: general
      count: 240
      rotationPolicy: "quarterly-100pct"  # 3~4개월마다 100% 노드 순환
  addons:
    - prometheus
    - cert-manager
    - ingress

이 방식의 값어치는 반복성과 회복력에 있습니다. 같은 선언은 언제 적용해도 같은 결과를 만들고, 사람이 그 사이에 다른 손질을 하지 않습니다. 노드 하나가 죽으면 컨트롤러가 선언과의 차이를 감지해 자동으로 교체하므로, 수동 복구라는 절차 자체가 사라집니다. 실제로 이 회사는 노드 복구를 사람이 직접 처리한 사례가 0건이라고 밝힙니다. (출처: CNCF Case Study) 인프라를 코드로 다루는 이 패턴은 CNCF 생태계에서 오퍼레이터(Operator) 패턴이라 부르며, Crossplane 같은 프로젝트도 같은 문제를 겨냥합니다. (출처: InfoQ)

이 구조를 우리 환경에 대입하려면, 먼저 “인프라의 원하는 상태를 무엇으로 선언할 것인가”를 정의해야 합니다. 선언 대상이 없으면 컨트롤러가 맞출 목표도 없기 때문입니다.

한마디로: Prometheus로 상태를 감시하고 cert-manager로 인증서를 자동 순환합니다.

선언형 제어가 성립하려면, 실제 상태를 끊임없이 관찰하는 눈이 있어야 합니다. LY Corporation은 관측성(observability, 시스템의 내부 상태를 외부 신호로 추론하는 능력)을 Prometheus로 구성합니다. node-exporter로 노드 지표를, kube-state-metrics로 Kubernetes 오브젝트 상태를 수집하고, Alertmanager로 이상을 알립니다. 컨트롤러가 자동으로 조치하더라도, 무엇이 왜 바뀌었는지를 사람이 확인할 수 있어야 신뢰가 쌓입니다. (출처: CNCF Case Study)

인증서도 자동화 대상입니다. 수만 대 규모에서 TLS 인증서를 사람이 발급하고 갱신하면 만료 사고가 반드시 생깁니다. 이 회사는 cert-manager로 인증서 발급과 순환을 자동화해, 만료로 인한 장애 가능성을 구조적으로 줄였습니다. (출처: CNCF Case Study) 노드 자체도 오래 두지 않습니다. 3~4개월마다 전체 노드를 100% 순환시켜 커널·OS·패치 수준을 라이프사이클에 맞춰 정렬하므로, “패치가 밀린 오래된 노드”라는 리스크가 누적되지 않습니다.

여기서 얻을 교훈은 분명합니다. 자동화가 사람의 판단을 대신하려면, 그만큼 촘촘한 관측성이 뒷받침되어야 합니다. 우리 조직도 자동 조치를 늘리기 전에 지표 수집 범위와 경보 규칙부터 점검해야 합니다. 눈이 없는 자동화는 사고를 조용히 키웁니다.

한마디로: 개발자는 매니페스트 한 장만 내면 TLS·메트릭·안정화 설정이 자동으로 붙습니다.

인프라 자동화는 이야기의 절반입니다. 나머지 절반은 그 위에 올라간 개발자 셀프서비스 PaaS 레이어입니다. 이 레이어는 프로덕션에서 파드 9만여 개, 노드 1만여 개, 프로젝트 600여 개를 지원하며, 하루 약 3,000회의 프로덕션 릴리스를 처리합니다. (출처: CNCF Case Study)

이 규모가 가능한 비결은 추상화의 위치입니다. 개발자는 최소한의 매니페스트(manifest, 원하는 상태를 적은 선언 파일) 한 장으로 애플리케이션을 정의하기만 하면 됩니다. 그러면 플랫폼이 TLS 엔드포인트 노출, 메트릭 수집, 그리고 PDB(Pod Disruption Budget)·preStop 대기 같은 안정화 관행을 자동으로 붙여 줍니다. 정책 검증은 OPA(Open Policy Agent, 정책을 코드로 강제하는 CNCF 프로젝트)가, 서비스 디스커버리는 CoreDNS가 맡습니다. 다수의 워크로드 클러스터와 하나의 컨트롤 플레인 클러스터를 논리적으로 단일 클러스터처럼 묶어, 개발자에게는 복잡성이 드러나지 않습니다. (출처: CNCF Case Study)

구조를 요약하면 2단입니다. 아래층은 CRD와 컨트롤러로 인프라를 자동으로 다스리는 컨트롤 플레인이고, 위층은 개발자가 인프라를 몰라도 배포할 수 있게 하는 PaaS입니다. 두 층 모두 “선언하면 나머지는 플랫폼이 알아서” 라는 같은 원리를 따릅니다. 우리 조직이 셀프서비스를 도입한다면, 개발자에게 무엇을 감추고 무엇을 노출할지의 경계부터 결정해야 합니다. 이 경계가 흐리면 추상화가 오히려 새로운 운영 부담이 됩니다.

한마디로: 프로비저닝 주→시간, 릴리스 수 시간→10분, 수동 노드 복구 0건입니다.

이 사례의 설득력은 서사가 아니라 수치에 있습니다. 프로비저닝 리드 타임은 1주 이상에서 시간 단위로 단축됐습니다. 릴리스에 걸리던 수 시간은 약 10분으로 줄었습니다. 노드 장애는 컨트롤러가 자동 교체하므로 사람이 직접 복구한 사례가 0건입니다. 트래픽이 초당 2,000건 수준으로 튀어도 오토스케일링이 자동으로 받아 냅니다. (출처: CNCF Case Study)

한 가지 유의할 점은 노드 수치의 출처 차이입니다. 인프라 컨트롤 플레인 사례에서는 4만여 노드로, PaaS 레이어 사례에서는 1만여 노드로 집계됩니다. 측정 시점과 범위가 다르기 때문이므로, 인용할 때는 반드시 어느 사례의 수치인지 함께 밝혀야 합니다. (출처: CNCF Case Study) 이런 편차를 그대로 옮기지 않으려면, 우리도 지표를 인용하기 전에 측정 기준부터 확인해야 합니다.

효과를 한 줄로 정리하면, 확장의 비용이 인력에서 자동화로 옮겨 갔다는 것입니다. 사람 수는 고정된 채로 규모만 커졌고, 늘어난 부하는 컨트롤 플레인과 PaaS가 흡수했습니다.

한마디로: 규모를 흉내 내기 전에 선언형 제어와 관측성 자동화의 원리를 먼저 가져가야 합니다.

LY Corporation의 규모를 그대로 재현할 수 있는 조직은 많지 않습니다. 하지만 이 사례에서 배울 원리는 규모와 무관합니다. 첫째, 인프라를 절차가 아니라 선언으로 다루는 것입니다. 클러스터·노드·인증서의 원하는 상태를 코드로 선언하고, 그 차이를 좁히는 일은 컨트롤러에게 맡깁니다. 둘째, 자동화의 전제로 관측성을 먼저 갖추는 것입니다. 자동 조치가 늘수록 “무엇이 왜 바뀌었는가”를 사람이 추적할 수 있어야 하며, 그렇지 못하면 자동화는 통제 불능이 됩니다.

이 두 원리는 국내 환경에서도 그대로 유효합니다. 특히 온프레미스와 프라이빗 클라우드 비중이 큰 국내 대규모 서비스라면, “15명이 4만 노드를 운영한다”는 문장은 곧 관측성과 자동화 도구에 투자할 근거가 됩니다. 사람을 늘리는 대신 선언형 제어와 관측성 자동화에 먼저 투자할 수 있는지를, 우리 조직도 진지하게 검토해야 합니다. 국내에서도 클라우드 네이티브 기반의 관측성 플랫폼과 대규모 Kubernetes 운영을 다루는 자료가 늘고 있으므로, 이런 레퍼런스를 함께 살펴보며 자사 환경에 맞는 수준을 준비해야 합니다.

마지막으로 남는 질문은 하나입니다. 확장을 인력의 문제로 볼 것인가, 구조의 문제로 볼 것인가. LY Corporation의 답은 명확했고, 그 답을 뒷받침하는 것이 CNCF 생태계의 오픈소스 구성 요소들이었습니다.

Kubernetes를 인프라 컨트롤 플레인으로 쓴다는 게 무슨 뜻인가요?
애플리케이션을 올리는 용도를 넘어, 클러스터와 노드 같은 인프라의 원하는 상태를 CRD로 선언하고 컨트롤러가 실제 상태를 맞추게 하는 방식입니다. 인프라 자체를 쿠버네티스 오브젝트처럼 다룬다고 이해하면 됩니다.

정말 15명이 4만 노드를 운영하는 게 가능한가요?
사람이 절차를 밟는 대신 컨트롤러가 프로비저닝·복구·순환을 자동으로 처리하기 때문에 가능합니다. 수동 노드 복구가 0건이라는 수치가 이 구조를 뒷받침합니다. 다만 이는 촘촘한 관측성과 표준화된 선언이 전제된 결과입니다.

우리 조직도 이 방식을 바로 도입할 수 있나요?
규모 자체보다 원리를 먼저 가져오는 편이 현실적입니다. 인프라의 원하는 상태를 선언으로 정의하고, 자동화보다 관측성을 먼저 갖추는 순서를 권합니다. 무엇을 선언 대상으로 삼을지부터 결정해야 합니다.

CRD와 오퍼레이터 패턴은 표준 기술인가요?
네. CRD는 쿠버네티스의 표준 확장 방식이고, 컨트롤러와 결합한 오퍼레이터 패턴은 CNCF 생태계에서 널리 쓰입니다. Crossplane처럼 인프라 컨트롤 플레인을 겨냥한 프로젝트도 있습니다.

• CNCF Case Study — LY Corporation (자동화 프라이빗 쿠버네티스 플랫폼)
• CNCF Case Study — LY Corporation (대규모 PaaS)
• LINE Engineering — Verda 프라이빗 클라우드
• LY Corporation Tech Blog — 차세대 플랫폼 Flava
• InfoQ — Kubernetes as a Foundation for Infrastructure Control Planes
• CNF — 쿠버네티스 아키텍처 완벽 가이드
• CNF — 플랫폼 엔지니어란?
• CNF — AI 시대, 베어메탈 쿠버네티스 구축 전략
• MSAP — 코드 수정 없이 쿠버네티스 운영 상태를 보는 방법
• MSAP — AI Native Observability 완전 가이드
• 오픈마루 — 활용 사례로 이해하는 쿠버네티스 모니터링
• 오픈마루 Observability — 메트릭·로그·트레이스 통합