첫날 키노트 후반부입니다. 앞 글에서 AI 워크로드가 부딪히는 자원의 한계를 다뤘다면, 이번에는 실제로 Kubernetes 위에 AI 플랫폼과 대규모 인프라를 올린 사례 네 편을 정리합니다.
두 개씩 짝지어 읽으면 흐름이 잘 보입니다. 앞의 둘은 AI 플랫폼, 뒤의 둘은 선언적 대규모 운영입니다.
🧬 왜 멀티테넌시인가 : Preferred Networks
Building a Multi-Tenant AI Platform with the CNCF Ecosystem — Aya Igarashi (Preferred Networks)
10분을 받은 이 발표가 첫날 키노트 중 밀도가 가장 높았습니다.
발표자는 2016년부터 Kubernetes를 썼다고 합니다. 당시는 IaC 전환과 마이크로서비스가 화두였고 선언적 배포가 매력이었죠. 10년이 지나 AI가 인프라 요구사항을 근본적으로 바꿨는데도 Kubernetes는 여전히 기반으로 남아 있습니다. 이유로 강한 커뮤니티와 CRD·오퍼레이터로 대표되는 확장성을 꼽았습니다.
PFN은 AI 제품부터 자체 AI 칩(MN-Core)까지 수직 통합하고, 그 컴퓨팅 파워를 Kubernetes 기반 플랫폼으로 사내외 연구자에게 제공합니다. 즉 멀티테넌트 환경입니다.
왜 멀티테넌시인가? 이유는 비용입니다. AI 플랫폼 총비용의 대부분이 액셀러레이터인데 희소하고 비싸서 유휴 상태로 둘 수 없습니다. 그래서 공유합니다.
그런데 공유는 트레이드오프죠. 많이 공유할수록 격리가 약해집니다. Kubernetes는 여기서 스펙트럼을 줍니다. 왼쪽은 논리적 격리에 저비용, 오른쪽은 강한 격리에 높은 오버헤드. 정답은 없고 요구사항이 결정합니다.
PFN은 네임스페이스 격리와 전용 노드를 섞은 하이브리드를 골랐고, 그 대가로 나머지를 직접 만들어야 했습니다.
경계(Boundary): 실제 테넌트는 조직-프로젝트 계층 구조인데 네임스페이스는 평평합니다. 그래서 HNC(Hierarchical Namespace Controller)를 쓰는데, 업스트림이 아카이브돼서 자체 포크를 유지 중이라고 합니다. 그리고 경계는 벽 하나가 아니라 층으로 쌓습니다. 네트워크 계층은 NetworkPolicy, API 계층은 어드미션 컨트롤, 컨트롤러는 watch 범위 제한, 그 외 스택 전반에 추가 제약.
공정성(Fairness): 경계만으로는 한 테넌트가 다 써버리는 걸 못 막습니다. Kueue로 컴퓨트 쿼터를 관리하고 테넌트별 리소스 제한을 둡니다. 그리고 컴퓨트만이 아니라 오브젝트 생성 개수도 제한합니다. 단일 테넌트가 컨트롤 플레인에 과부하를 주지 않도록 하는 건데, 자원 쿼터만 생각하기 쉬운 지점입니다.
효율(Efficiency): AI 학습은 다수 파드가 지속적으로 통신·동기화하므로 동시에 시작해야 합니다. 일부만 뜨면 나머지가 유휴 대기죠. 그래서 갱 스케줄링을 자체 스케줄러 플러그인으로 구현했습니다(업스트림도 개발 중). 그리고 노드마다 자유 공간이 잘게 파편화되면 총량이 충분해도 큰 파드가 못 들어가므로 타이트 패킹을 합니다.
이 세 가지가 "멀티테넌트 AI 플랫폼을 만든다"는 문장을 실제 엔지니어링 항목으로 번역해줍니다. 사내 플랫폼을 고민하는 입장에서 그대로 체크리스트로 쓸 수 있겠다 싶었습니다.
마무리는 이랬습니다. 10년 뒤에는 지금 상상 못 할 워크로드를 돌리게 될 텐데, 확장성·생태계·커뮤니티 셋이 있으면 플랫폼이 계속 적응할 수 있다는 것.
🚗 3시간을 3분으로 : Subaru
How Subaru Accelerated AI Model Development for Next-Generation EyeSight with Kubernetes — Ryoji Kobayashi (Subaru)
스바루는 차세대 아이사이트의 인식 정확도를 높이기 위해 AI 모델을 사내에서 개발하고 있습니다. 그런데 개발이 확대되면서 문제가 쌓였습니다.
- 거대한 ML 컨테이너 이미지
- 수동 배포 작업
- 점점 복잡해지는 머신러닝 워크플로
이를 풀기 위해 Harbor, Envoy Gateway, MetalLB, Argo CD, Helm, Argo Workflows 조합으로 Kubernetes 기반 AI 모델 개발 플랫폼을 구축했습니다. 결과가 명료합니다.
- 컨테이너 이미지 pull 시간이 약 3시간에서 3분으로(60배)
- 25개 애플리케이션 정의에 GitOps 적용
- 머신러닝 워크플로 자동화
이 사례는 올해 KubeCon Japan 케이스 스터디 콘테스트 수상작이기도 합니다. 오프닝 키노트에서 Bryce가 직접 축하 멘트를 하기도 했고요.
앞의 PFN 사례와 붙여 보면 흥미롭습니다. 자체 AI 칩까지 만드는 조직과, 기존 개발 프로세스를 개선하려는 조직이 결국 같은 CNCF 도구 상자를 쓴다는 점이요. 규모와 성숙도는 다른데 선택지는 같습니다.
📐 15명이 1,300개 클러스터를 : LY Corporation
From 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes — Shota Yoshimura (LY Corporation)
3분 동안 나온 숫자가 이렇습니다.
1,300개 이상의 클러스터, 40,000개 이상의 노드, 그리고 플랫폼 엔지니어 15명.
슬라이드 마지막 줄이 이걸 1인 기준으로 환산해줍니다.
"오늘 플랫폼 엔지니어 한 명이 90개 클러스터를 운영합니다."
일본 최대 규모의 프라이빗 Kubernetes 플랫폼 중 하나입니다. OpenStack 기반 프라이빗 인프라 위에서 Kubernetes 커스텀 리소스와 컨트롤러로 인프라를 선언적으로 정의하고, 클러스터 프로비저닝·스케일링·업그레이드·복구를 자동화했습니다.
결과로 든 세 가지입니다.
- 프로비저닝이 수 주에서 수 시간으로
- 무중단 운영 확보
- Kubernetes를 제품 팀을 위한 셀프서비스 플랫폼으로 전환
같은 발표자가 별도 브레이크아웃에서 28분짜리 심화 발표도 진행했습니다. 그쪽은 안전한 scale-in을 다루는데, 대부분의 발표가 확장(scale-out)에 집중하는 것과 달리 온프레미스에서는 유휴 노드가 하드웨어 조달과 랙 용량에 직결되므로 축소도 중요하다는 관점이었습니다.
🌐 Argo CD 하나로 5,000개 앱을 : Hyundai AutoEver
Out of the Box, at Multi-Region Scale: How Hyundai Scales Its Platform — Jaewoo Choi (Hyundai AutoEver)
바로 다음이 현대차그룹 사례였습니다. 자체 프라이빗 클라우드 hCloud 위에서 글로벌 플랫폼을 운영하고 CI/CD 파이프라인에 오픈소스 도구를 제공합니다.
- 단일 Argo CD 인스턴스가 전 세계 300개 이상 클러스터에 걸쳐 5,000개 이상의 Application 관리
- 매달 수백 개씩 증가
- 멀티리전 Harbor 레지스트리는 5,000개 이상 저장소에 60,000개 이상 아티팩트를 3개 리전에 복제
마지막 항목의 이유가 데이터 주권 규제와 성능을 동시에 맞추기 위한 설계라는 점이 눈에 띄었습니다. 글로벌 제조사가 부딪히는 제약이 그대로 아키텍처에 반영돼 있었습니다.
발표자가 Argo CD 메인테이너이기도 해서, 도구를 쓰는 쪽과 만드는 쪽을 동시에 하는 사례이기도 합니다. 한국 발표자가 KubeCon Japan 키노트에 서는 걸 현장에서 보는 것도 반가웠고요.
🛫 마치며
뒤의 두 발표가 던지는 공통 메시지는 분명했습니다. 이 규모에서 사람이 손으로 관리하는 건 애초에 선택지가 아니고, 선언적 정의와 컨트롤러 패턴이 유일한 답이라는 것.
그리고 첫날 키노트 전체를 한 문장으로 정리하면 이렇습니다.
클라우드 네이티브가 AI 아래로 내려갔다.
AI가 클라우드 네이티브를 대체하는 게 아니라, AI 워크로드가 돌아갈 바닥을 클라우드 네이티브가 깔고 있다는 것. Bryce의 표현을 빌리면 지난 10년이 분산 워크로드를 돌릴 시스템을 만드는 기간이었다면, 다음 10년은 그 위에서 AI라는 새 워크로드를 받아내는 기간이 되는 셈입니다.
다음 글부터는 첫날 오후 브레이크아웃 세션을 하나씩 다룹니다. 먼저 GitOps의 진실 공급원을 두고 벌어진 토론, "OCI is not Git" 세션입니다.