“k8s” 검색 결과

AWS에서 분산 학습 클러스터를 구축·운영하는 실전 가이드 3편으로, Enroot+Pyxis 컨테이너 환경 구성, 클러스터 기동 전 점검사항, 온프레미스 대비 AWS 운영 모델 차이, GPU vs Trainium 선택, 현장 반복 장애 해결법을 다룬다. 수십~수백 노드가 동일한 소프트웨어 스택을 실행해야 하는 분산 학습의 핵심 문제를 컨테이너로 해결하는 접근과, EFA·NCCL 설정 실수가 학습 성능에 조용히 영향을 주는 함정들을 정리했다.

Pinterest가 수백 개 Terraform 워크스페이스와 수만 개 클라우드 리소스를 안전하게 변경하려고 만든 전용 Terraform 실행 엔진 RPP(Resource Provisioner Pipeline)를 소개한다. 팀별로 흩어진 멀티 레포 구조에서 CI/CD가 과도한 권한을 쥐지 않도록 secure role-chaining으로 최소 권한을 강제하고, 모든 변경을 PR 기반으로 계획·검토·적용한다. 취약점 스캔·LocalStack 사전 테스트·중앙 감사까지 파이프라인에 녹였다.

인프라 접근 권한 관리가 AWS IAM, SSH 설정, DB 접근 제어, Kubernetes RBAC, 애플리케이션 레이어 등 다섯 개 독립 시스템에 분산된 문제를 Teleport의 Access as Code(AaC) 방식으로 통합한 사례를 다룬다. 권한 변경을 YAML 코드로 선언하고 Git으로 버전 관리하며, Teleport가 단기 인증서를 동적으로 발급해 오프보딩 누락과 정적 비밀 키 노출 위험을 제거한다. 네 가지 조건(선언적 정의·버전 관리·프로토콜 통합·동적 자격증명)으로 AaC를 정의하고 CyberArk·Cloudflare·HashiCorp Boundary·Teleport를 비교 분석한다.

네이버 검색의 대규모 메트릭 저장소인 VictoriaMetrics 클러스터를 장비 증설 없이 소프트웨어 최적화만으로 리소스 위기에서 구한 과정을 다룬다. 쿠버네티스 전환으로 컨테이너가 수백만 개를 넘고 카디널리티가 폭증하면서 조회 컴포넌트 OOM과 저장소 디스크 고갈이 동시에 터졌다. 데이터 파이프라인을 조회·저장·수집 세 레이어로 나눠 각 구간을 따로 최적화했다.

GitOps 환경에서 PR만 봐서는 실제 쿠버네티스 매니페스트 변경이 무엇인지 알기 어렵다는 문제와, 공유 Helm Chart 구조로 인해 단일 변경이 모든 서비스에 즉시 반영되던 문제를 강남언니 팀이 두 가지 독립적 자동화로 해결한 사례다. ChartMuseum + Release Please로 Helm Chart 버전 관리를 도입하고, GitHub Actions + dyff로 PR마다 before/after 매니페스트 diff를 자동 생성해 PR 리뷰 시간을 10분에서 1분으로 단축했다. 50개 서비스 Helm Chart 업그레이드 PR에서 "No manifest diff found" 전체 확인 후 안심하고 머지할 수 있게 됐다.

네이버 ENGINEERING DAY 2026 발표. AI 코딩 에이전트와 그 실행 환경을 API로 추상화하고 관리할 수 있는 오픈소스 프레임워크 Kelos를 소개한다. 쿠버네티스 네이티브 설계로 코딩 에이전트의 자동화와 오케스트레이션을 지원한다.

LY Corporation SRE1팀이 여러 팀에 산재한 인프라 관리 방식을 OpenTofu(Terraform 오픈소스 포크)와 Terragrunt 기반 IaC로 통합한 전 과정을 다룬다. 300여 대 VM, 160개 LB, 350개 DNS 레코드를 포함한 약 1,500개 리소스를 코드화하고, AI 에이전트와 MCP를 결합해 Slack 자연어 요청만으로 인프라 변경이 가능한 ChatOps 파이프라인까지 구현했다.

토스증권 Data Infra팀이 Spark Connect를 Kubernetes 위에서 멀티테넌트 서비스로 운영하며 맞닥뜨린 구조적 문제 3가지(Driver SPOF, 리소스 경합, 고정 스케일)와 그 해결책을 다룬다. 단일 SparkContext를 공유하는 구조에서 한 사용자의 OOM 쿼리가 전체 세션을 종료하는 문제를, Executor 실패 카운터 재설계와 멀티 Replica 아키텍처로 극복했다.

Amazon EKS 환경에서 무중단 배포(Rolling Update/Blue-Green)를 적용했음에도 간헐적으로 502 Bad Gateway·504 Gateway Timeout이 발생하는 근본 원인과 해결책을 다룬다. ALB·K8s·Istio·Argo Rollouts의 종료 시퀀스가 어긋나는 타이밍 문제가 핵심이며, terminationGracePeriodSeconds·preStop hook·ALB deregistration_delay 세 축을 정렬해 해결한다.

Spotify가 AI 코딩 도구를 조직 전반에 확산하며 얻은 결론은 "코딩은 더 이상 병목이 아니고, 이제 무엇을 만들지 결정하는 일이 새 병목"이라는 것이다. 프로덕션 코드베이스가 엔지니어 수보다 7배 빠르게 커지며 폭증한 유지보수 부담을, 배경 코딩 에이전트 Honk와 자동화 파이프라인으로 흡수한 과정을 다룬다.

레포를 AI Native하게 만들고 나니 다른 병목이 보였다는 데서 시작한다. 문제는 AI가 코드를 못 쓰는 게 아니라 사람이 여러 도구를 오가며 AI를 오케스트레이션해야 한다는 점이었다. 태스크는 팀챗에서 설명하고 코드는 터미널에서 만들고 리뷰는 GitHub에서 하고 운영 확인은 Datadog과 Grafana에서 했다. hollon-ai는 팀챗이라는 공용 인터페이스 위에 실행 harness와 메모리 계층을 올려 보안 대응·배포 직후 관측·코드 수정·지식 축적이 같은 스레드에서 이어지게 만든 시스템이다.

광고 플랫폼의 대규모 데이터 처리를 YARN 클러스터로 운영하면 자원 활용도와 격리에서 한계가 온다.

스캐터랩이 자체 LLM Spotwrite로 AI 엔터테인먼트 서비스 제타를 운영하며, WAU 150만·초당 3~4천 RPS의 LLM 트래픽을 8개 이상 Azure 리전의 멀티 클러스터로 처리하는 인프라 개선 여정을 다룬다. Neo Cloud 시절의 GPU 확보난·안정성·스토리지·failover 문제를 AKS와 Karmada, Istio, Terraform 조합으로 풀었다. 그 결과 서빙 비용을 20% 이상, 운영 리소스를 절반 이상 줄였다.

채널톡 AI팀이 상담 에이전트 ALF의 RAG 문서 전처리 파이프라인을 FastAPI background tasks에서 dagster로 옮긴 과정이다. 초기에는 트래픽이 적어 문제가 없었지만 고객사가 늘면서 같은 인스턴스에서 여러 문서를 동시에 처리하다 타임아웃이 나거나 OOM으로 파드가 죽었다. 워크플로우 오케스트레이션 도구 넷을 비교한 뒤 dagster를 골랐고, 지금은 하루 1만 건이 넘는 무거운 전처리 요청을 별 이슈 없이 처리한다.

Kubernetes 환경에서 Node.js 배치 컨슈머가 SIGTERM을 받아도 깔끔하게 종료되지 않는 문제를 단계별로 해결한 경험이다. PID 1의 시그널 무시 동작, 이벤트 루프와 프로세스 종료의 차이, dumb-init 도입까지 원인을 하나씩 파악하고 최종 해결책을 찾아간 과정을 기술한다.

EKS Blue/Green 운영에서 AWS Route 53 가중치·다중값 응답 라우팅은 DNS 전파 1~5분 + 클라이언트 캐시로 즉각 전환이 어려웠다.

네이버페이 백엔드 개발자가 'Node.js는 싱글스레드냐 멀티스레드냐'라는 흔한 질문을 실무 관점에서 다시 뜯어본다. 결론은 둘 다 맞다다. JS 코드와 이벤트 루프는 하나의 메인 스레드(V8)에서 돌지만, 오래 걸리는 I/O는 libuv의 워커 스레드가 병렬로 처리한다. 후반부에서는 이 구조의 CPU 약점과, 네이버페이 타임라인의 60억 건 마이그레이션을 k8s 스케일아웃으로 해결한 사례를 정리한다.

쏘카 데이터엔지니어링팀 신입 엔지니어가 K8s·Airflow·MSK·KDS를 처음 접하며 3개월 만에 실프로젝트 2개를 완료한 온보딩 회고다. 운전 점수 MSK Produce와 서버 로그 KDS Consumer를 구현하며 MSK vs KDS 차이를 실전에서 체감한 내용을 담았다.

MADUP의 Prism은 K8s 환경에서 마이크로서비스가 비동기 메시지로 통신하는데, 처리 시간이 1~30분으로 들쭉날쭉하고 컨슈머 오토스케일·at-least-once 전달까지 동시에 만족시켜야 했다.

데이터 파이프라인용 Airflow를 관리형 서비스(MWAA/Composer)에서 직접 운영하는 Kubernetes로 이관하며 겪은 운영 이슈(스케줄러 CPU 폭증, 워커 OOM, 사라진 실행 로그)와 해결을 다룬 경험기다.