당근마켓 서비스를 cdk8s를 활용해 쿠버네티스에 배포하기 (SRE 밋업 2회)
원문 정보
- 원문: cdk8s 활용 당근마켓 서비스 배포 탬플릿 만들기 | 당근마켓 SRE 밋업 2회 (30:24)
- 매체 · 게시일: YouTube 당근 채널 · 2021-12-02
- 발표자: 김규환 (당근마켓 SRE 팀 딜리버리 파트). 영상 설명란으로 확인했고, 자막 자기소개에서는 영어 이름이 들리는데 인식이 깨져 있습니다.
- 근거: YouTube 자동 자막 전체 + 발표 슬라이드. 슬라이드 글자 추출이 깨져 구조만 확인했고 내용은 자막을 따랐습니다.
- 이 문서는 영상을 읽고 재구성한 요약이며 원문 자체가 아닙니다.
주요 구간
- 00:00 템플릿이란 무엇인가
- 02:00 배포 매니페스트와 배포 인터페이스가 필요한 이유
- 07:30 배포 매니페스트 설계: 호스트, 프로토콜, 인스턴스 클래스
- 14:30 템플릿 엔진과 Helm, cdk8s 비교
- 21:00 cdk8s와 TypeScript 선택
- 26:00 리소스 나누기와 인자 분류, 유효성 검사
배포에 필요한 입력만 받는 인터페이스
당근은 개발자가 Kubernetes를 몰라도 서비스 저장소의 설정 파일만으로 배포할 수 있게 하는 것을 목표로 배포 매니페스트를 만들었습니다. 앞선 배포 시스템 발표에서 소개한 이 파일이 이번 발표의 출발점입니다. 배포 매니페스트는 Dockerfile 경로, 사용할 구성 목록, 배포할 워크로드, 인그레스 등 최소한의 매개 변수만 받는 사내 배포 인터페이스입니다.
발표자는 Kubernetes를 제대로 쓰려면 리소스와 옵션을 모두 알아야 한다는 점을 높은 진입 장벽으로 봤습니다. 배포에서 관심을 두는 부분도 사람마다 다릅니다. 여러 도구의 계층과 회사 고유의 규칙까지 한 사람이 모두 파악하기 어려워, 당근은 자유도를 줄이는 대신 배포에 필요한 입력을 최소화했습니다.
이 발표는 그렇게 만든 배포 매니페스트를 Kubernetes 매니페스트로 바꿀 템플릿 엔진을 고르는 과정을 다룹니다.
매니페스트 설계와 템플릿 도구 선택
배포 매니페스트에는 개발자가 결정할 내용만 남겼습니다. Istio Gateway와 VirtualService의 복잡한 호스트 이름과 규칙은 숨기고, 서비스를 내부에만 열지 외부에도 열지만 고르게 했습니다. 앞단 HAProxy가 gRPC 연결을 따로 처리하려면 호스트 접미사가 필요하므로, 개발자가 프로토콜 옵션을 지정하면 엔진이 접미사를 붙입니다. CPU와 메모리는 파드 스케줄링과 QoS를 고려해야 하는 클러스터 관리팀의 관심사로 보고, AWS 머신 타입(EC2 인스턴스 클래스)처럼 사양만 지정하도록 했습니다.
당근은 Kubernetes에 친화적인 Helm 템플릿과 cdk8s를 비교했습니다. 글로벌 배포와 잦은 실험으로 템플릿이 계속 바뀌는 상황에서, 선언형인 Helm은 조건 처리와 디자인 패턴 적용이 어려워 유지보수가 우려됐습니다. 프로그래밍 언어로 매니페스트를 만드는 cdk8s에는 IDE 자동 완성, 테스트 도구 등 기존 언어 생태계 활용, 객체지향 방식의 리소스 처리와 세부 구현 숨기기를 기대했습니다.
발표에서는 cdk8s를 AWS 팀이 2020년에 공개한 CNCF 샌드박스 프로젝트로 소개합니다. 발표 당시에는 AWS 공식 프로젝트가 아니라 별도 팀이 관리하는 오픈소스라고 설명했습니다. 지원 언어 중에서는 정적 타입과 동적 언어의 특성을 함께 가진 TypeScript를 골랐습니다. Kontrol의 주요 구성 요소가 이미 Node 기반이라 라이브러리를 npm 패키지로 배포해 재사용할 수 있다는 이유도 있었습니다. Kontrol의 배포 매니페스트 미리보기 페이지는 템플릿과 저장소가 달라도 같은 로직을 패키지로 가져다 씁니다.
패키지 재사용과 배포 전 검증
템플릿 엔진은 별도 코드베이스에서 관리하고 Kontrol은 패키지로 불러 씁니다. 같은 로직을 쓰는 미리보기 페이지에서는 실제 배포 없이 생성될 Kubernetes 리소스를 확인할 수 있습니다.
인자를 변경 빈도에 따라 나누고 유효성 검사도 추가했습니다. 잘못된 매니페스트는 배포 전에 빠르게 실패하도록 해 피드백 주기를 줄였습니다.
주의할 점
발표자는 cdk8s를 도입해도 복잡도가 저절로 줄지는 않으며, 객체지향 방식으로 리소스를 적절히 나눠야 한다고 설명합니다. 당근은 관심사를 기준으로 클래스를 묶었습니다. Deployment, Service, ServiceMonitor는 워크로드 관련 리소스로, Istio 리소스는 트래픽 관련 리소스로 분류했습니다.
인자는 변경 빈도에 따라 위치를 정했습니다. 리전, 환경, 이미지 태그처럼 자주 바뀌는 값은 Kontrol이 넣고, 환경과 관계없이 거의 바뀌지 않는 포트나 헬스 체크만 배포 매니페스트에 두었습니다.
발표자는 재생되지 않는 데모 영상을 건너뛰었고, 발표 주제도 직전에 조금 바뀌었다고 밝혔습니다. 2021년 당시 설명이므로 지원 언어와 구성은 이후 달라졌을 수 있습니다.
근거와 세부 수치
| 항목 | 내용 | 근거 |
|---|---|---|
| 배포 매니페스트에 담는 내용 | 빌드 Dockerfile 경로, 사용 구성 목록, 워크로드 목록과 세부 설정, 인그레스 설정 | 자막 기준 |
| 후보 비교 | Helm 템플릿(선언형)과 cdk8s(프로그래밍 언어) 비교 | 슬라이드, 자막 기준 |
| cdk8s 지원 언어 | 2021년 9월 7일 기준 4개 언어(TypeScript, JavaScript, Python, Java로 추정) | 자막 기준 |
| 선택 언어 | TypeScript | 자막 기준 |
| 설계에서 숨긴 것 | 호스트 도메인 규칙, gRPC 호스트 접미사, CPU와 메모리 사양(AWS 머신 타입으로 지정) | 자막 기준 |
| 쪼개기 기준 | 관심사가 같은 리소스끼리 클래스로 묶기 | 자막 기준 |
| 인자 분류 | 자주 바뀌는 인자(리전, 환경, 이미지 태그, 애플리케이션 구성)와 안 바뀌는 인자(포트, 헬스 체크 등) | 자막 기준 |
슬라이드 PDF는 글꼴 인코딩 문제로 글자를 추출할 수 없어 페이지 제목 구조만 확인했습니다. 지원 언어 목록은 자막 인식이 깨져 있어 이름을 확정하지 않았습니다. 영상 설명란에는 녹화일이 2021년 1월 17일로 적혀 있으나 게시일은 2021-12-02입니다.