본문으로 건너뛰기
타사 테크블로그
당근

당근

이 분류에서 찾기

출처

이 분류의 문서는 아래 블로그 9편과 발표 24편을 읽고 재구성한 요약입니다. 원문 자체가 아니므로 내용은 각 링크에서 직접 확인합니다. 항목은 원문 제목, 매체나 행사, 게시일, 저자나 발표자(소속) 순입니다.

SRE팀 클러스터 파트

블로그 (Medium 당근 블로그)

발표 영상 (YouTube 당근 채널)

그 밖의 SRE 파트·다른 팀

블로그 (Medium 당근 블로그)

발표 영상 (YouTube 당근 채널)과 슬라이드

출처 판단 근거: 클러스터 파트 자료는 당근 채용 공고가 링크한 자료와, 블로그 저자 소개 및 SRE 밋업 발표자료 페이지의 소속 표기로 판단했습니다. 발표자 소속은 각 문서의 원문 정보에 적힌 대로이며, 근거가 자막이면 “자막 기준"이라고 표시했습니다. 그 밖의 묶음은 클러스터 파트가 아니라고 확인된 글과 발표입니다.

확인 범위: 2026-10-21에 당근 Medium 블로그의 전체 글 목록(2015-06~2026-10, 223편)과 SRE 밋업 1~4회 발표 목록을 확인했습니다. SRE 밋업 1회 “AWS VPC PrivateLink를 이용한 네트워크 구성 전략"은 공개된 영상과 슬라이드를 찾지 못해 요약하지 않았습니다.

어떤 주제를 다뤘나

주제글·영상한 줄 요약
쿠버네티스 운영·오토스케일링아마존 EKS 무중단 업그레이드마스터·노드 그룹을 단계별로 올리는 방식과 새 클러스터로 트래픽을 옮기는 방식을 비교하고 1.15에서 1.18까지 한 번에 업그레이드
쿠버네티스 운영·오토스케일링멀티 클러스터 Addons 관리새 EKS 클러스터마다 필요한 Addons를 Argo CD ApplicationSet으로 한꺼번에 배포
쿠버네티스 운영·오토스케일링검색 엔진을 쿠버네티스로 운영하기EC2 위 Elasticsearch 수동 배포를 ECK 기반으로 바꿔 평균 5시간 걸리던 배포를 자동화
쿠버네티스 운영·오토스케일링Karpenter 트러블슈팅ASG 기반 클러스터를 Karpenter로 옮기며 겪은 다섯 가지 문제와 해결
쿠버네티스 운영·오토스케일링검색 엔진 데이터 노드 웜업Elasticsearch 롤링 리스타트 때 생기던 지연 급증을 프록시와 데이터 노드 웜업으로 해결
쿠버네티스 운영·오토스케일링HPA Scale-in과 AZ 불균형Locality LB 때문에 생긴 Zone Skew를 Pod Deletion Cost 컨트롤러로 해결
쿠버네티스 운영·오토스케일링Job 노드 그룹 오토스케일링고정 크기이던 Job용 노드 그룹에 오토스케일링을 붙이며 bin-packing 부작용을 maxPods 등으로 해결
쿠버네티스 운영·오토스케일링Karpenter 도입 여정Cluster Autoscaler에서 Karpenter로 전환해 네임스페이스별 평균 Pending이 최대 4분에서 약 30초로 감소
배포·개발자 플랫폼당근페이 6개월 인프라 구축로그인, 서버 접근, 애플리케이션, 배포, 관측, 성능 테스트 여섯 가지를 어떻게 정했는지 회고
배포·개발자 플랫폼왜 배포 시스템을 만드는가Argo CD와 GitOps 모노레포 방식의 한계를 짚고 사내 배포 시스템 Kontrol을 만든 이유
배포·개발자 플랫폼cdk8s 배포 템플릿배포 매니페스트를 Kubernetes 매니페스트로 바꾸는 도구로 Helm 대신 cdk8s와 TypeScript를 고른 이유
배포·개발자 플랫폼CircleCI에서 GitHub Actions로Docker layer caching과 Dockerfile 순서 조정으로 15분이 넘던 배포를 약 2분까지 단축
배포·개발자 플랫폼매일 배포(1) 브랜치 전략Git Flow 주 1회 배포에서 GitHub Flow로 옮겨 배포에 쓰던 1시간을 20분 미만으로 단축
배포·개발자 플랫폼매일 배포(2) Feature Toggle어노테이션 기반 Feature Toggle을 직접 만든 과정과 설계 원칙 다섯 가지, 권한·카나리 토글 운영
배포·개발자 플랫폼개발자 플랫폼 Kontrol 2년인프라 요청 티켓의 한계에서 출발해 배포, 오너십, 비용, 리소스 생성을 하나의 UI로 묶어 온 과정
배포·개발자 플랫폼배포 시스템 교훈Kontrol을 2년간 만들며 얻은 교훈. 이해관계 충돌, 포장도로와 비포장도로 구조, 운영 컨텍스트 제공
배포·개발자 플랫폼Kontrol 멀티 클러스터 지원4개 리전 글로벌 배포를 붙인 과정과 배포 엔진을 Argo Workflows로 바꾼 결정
배포·개발자 플랫폼프로젝트 오너십 katalogKontrol 프로젝트를 오너십 단위로 삼아 AWS와 GCP 리소스를 하나의 ID로 묶은 과정
배포·개발자 플랫폼개발자가 관리하는 리소스 KRPTerraform state 약 1000개를 운영하는 부담에서 출발해 Redis 생성과 수정을 개발자가 UI에서 직접 하게 만든 과정
배포·개발자 플랫폼개발자 플랫폼의 현재배포 도구로 시작해 워크로드, 설정, 클라우드 리소스, 비용까지 넓어진 Kontrol을 화면 중심으로 소개
네트워크·서비스 메시·엣지gRPC 서비스 운영채널과 HTTP/2 연결의 관계, keepalive, 상태 코드, L7 로드밸런싱, 모니터링 지표를 당근의 구성과 함께 설명
네트워크·서비스 메시·엣지Host Network 도입기DaemonSet의 IP 점유와 Job Pod의 IP 할당 지연을 hostNetwork로 줄여 IP 할당 실패 이벤트를 시간당 약 13,000건에서 약 50건으로 감소
네트워크·서비스 메시·엣지Istio ServiceEntry 자동생성CoreDNS 로그에서 호출 도메인을 뽑아 ServiceEntry를 자동으로 만들어 Mesh 외부 트래픽을 L4로 가시화
네트워크·서비스 메시·엣지API 앞단 CloudFront캐나다 initial connection 시간 중앙값 45% 감소, 트래픽 비용 약 20% 절감, WAF와 Shield로 보안 보강
네트워크·서비스 메시·엣지당근페이 VPC 재설계흩어진 NAT Gateway와 Transit Gateway를 Network VPC로 모으고 NACL을 AWS Network Firewall로 교체
옵저버빌리티·알림서비스 모니터링 방법공통 모니터링 영역을 정하고 USE·RED 방법론을 Prometheus와 Grafana 대시보드로 구현해 Alert Delivery와 연결
옵저버빌리티·알림AlertDeliveryGrafana 레거시 알림이 여러 네임스페이스를 한 메시지로 보내는 한계를 katalog 담당자 정보와 알림별 정책으로 해결
옵저버빌리티·알림Loki 1년간 운영기로그 유실의 원인을 수집기 병목과 CPU 스로틀링에서 찾았고 느린 쿼리 기준 조회 속도가 약 50% 개선
옵저버빌리티·알림Prometheus 레코딩 룰 SLIRedis 자원의 SLI를 팀 설문과 논의로 정하고 조회 API 방식에서 레코딩 룰 방식으로 이전
옵저버빌리티·알림옵저버빌리티 재설계올해 3월 약 50분 장애에서 원인 파악이 오래 걸린 경험에서 출발해 자체 웹 플랫폼과 Doctor Agent를 개발 중
보안·감사·거버넌스AWS Config 컴플라이언스Rule과 Conformance Pack, RDK, 사내 Rulebook 연동과 써 보며 느낀 한계를 슬라이드 기준으로 정리
보안·감사·거버넌스kube-apiserver 감사 로그Pod 하나를 만들 때 컨트롤 플레인 컴포넌트가 호출하는 API를 EKS 감사 로그로 따라가는 입문 해설
비용EKS 데이터 전송 비용 절감Istio Locality Load Balancing과 Topology Aware Hints로 호출이 같은 가용 영역 안에서 끝나게 해 크로스존 비용 절감

2021년 발표는 배포 시스템과 개발자 플랫폼에서 시작합니다. EKS 업그레이드와 멀티 클러스터 Addons 관리, Argo CD와 cdk8s 기반 배포가 이 시기의 주제입니다. 2023년에는 Kontrol이 멀티 클러스터 글로벌 배포와 오너십 관리, 개발자가 직접 쓰는 리소스 플랫폼으로 넓어졌고, 같은 행사에서 모니터링과 Alert Delivery, EKS 데이터 전송 비용 절감도 함께 다뤘습니다. 2025년 발표는 Loki 운영과 외부 트래픽 가시화, CloudFront, AZ 불균형, VPC 재설계처럼 운영 중에 드러난 비용과 네트워크 문제로 옮겨 갑니다. 2026년 빌더 밋업에서는 Karpenter 전환과 함께, 장애 분석과 알림을 에이전트에게 맡기려는 옵저버빌리티 재설계가 나옵니다.

여러 글이 비슷한 순서를 따릅니다. Pending 시간, IP 할당 실패, 로그 유실, Zone Skew처럼 수치로 보이는 증상을 먼저 잡고, 병목을 좁힌 뒤 설정이나 구조를 바꿉니다. 바꾼 결과가 새 문제로 이어지는 대목도 자주 나옵니다. 이 분류의 글과 영상을 함께 읽으면 그 과정을 같은 조직의 여러 시기에 걸쳐 따라갈 수 있습니다.

마지막 수정 일자
네이버