제 3회 당근마켓 SRE 밋업

2023.6.15

개요

제3회 당근마켓 SRE 밋업의 표를 구한 소마고 백엔드 개발자인 나는 바로 서울 교보타워로 현장체험학습신청서를 쓰고 달려갔다.

솔직히 어려운내용이 많았다. 이해가 되지 않는 내용도 있었다. 그러나 데브옵스 엔지니어가 아닌 백엔드 개발자인 나의 관점에서도 여러가지를 느낄 수 있었던 좋은 경험이였다.

아래는 내가 밋업 내용을 정리한 것이다. 야매로 적은거라 별로 부정확한 내용이 있을 수도 있다. 참고 바란다..

그리고 맨 아래에는 백엔드 개발자 관점으로 본 나의 후기도 남겨보았다.

1. 당근마켓은 지난 2년간 무엇을 만들었는가? (변정훈)

당근마켓 개발자 플랫폼!

Kontrol(개발자 플랫폼) 운영하게된 이유

서비스 개발 && SRE

서비스 개발 → 요청 | 인프라 ←SRE

엔지니어 티켓요청 → SRE 작업(자동화, 스크립트) → 인프라

서비스 개발팀이 추구하는 방향

• 빠른 변경
• 다양한시도

SRE팀이 추구하는 방향

• 안정적 운영
• 정책 적용
• 일관된 형태
• 승인

커가는 조직과 서비스 규모

+200 엔지니어

4개의 리전

8개의 클러스터

+200 네임 스페이스 (네임스페이스 하나당 하나의 프로젝트라고 보면됨)

Developer Self-Service (엔지니어가 인프라를 직접)

Kontrol

SRE 팀에서 제공하는 프로젝트 컨트롤 플레인

배포: 2021년 11월

사용: 도커파일 기본으로 만들고 프로젝트를 처음엔 수동으로 등록 → 안내가이드가 나온다 쿠버네티스를 추상화해서 서비스 라우팅을 정의한 배포 메인 테스트 → 액션도 제공하고 있어서 배포를 할 수 있긴함 → 배포를 누르면 (저장소의 기본 브랜치의 최신 커밋을 가져와서 배포를 시작 파이프라인을 가지고 있음)

도커 이미지를 만들어서 도커 푸쉬를 하는 과정을 kontrol안에서 기능이 있음

yml → 쿠버네티스 yml로 변환해서 사용

배포된 서버 Url을 누르면 바로 당근 서버 클러스터에 서버가 띄워진다.

(argo cd에서는 프로젝트가 흩뿌려져있어서 뭐가 무슨 프로젝트인지 구별하기 힘들었던 단점을 케어함 , 깃허브 아이디별로 띄우는 것이 아닌 직원 별로 띄워지게함, 언제 누가 배포를 했는지 히스토리를 시각화함 ).

배포 메인 테스트 실시간 시각화 (쿠버네티스)

kontrol → go cd → 쿠버네티스 클러스터

환경변수

kontrol을 만들면서 시크릿은 aws secret manager로 통합.

전 argo cd에서는 다 따로 yml로 관리하고 있었음. (쿠버네티스 리소스 관점)

config를 종류별로 yml 만들어서 환경변수를 세팅함

CronJob → 스케줄, 디버그할때 수동 트리거를 주고싶음.. 수동식으로 실행할 수 있게함 (로그 기록 제공)

kontrol에 db를 붙여 확장함, 글로벌 배포 Kontrol 구현 gocd → argo workflows로 교체

Kontrol을 보완하는 프로젝트

• katalog: 프로젝트 오너쉽을 관리를 용이하게 하는 DevOps 프로젝트 kontrol에 뒤로 연동이 되어서 통합되어있다.
• kost: 비용 시각화 프로젝트. 비용 이슈가 있다. 리소스 오너쉽을 관리하기 시작했기 때문에 비용 시각화를 하기 시작했다. (그래프, 일별, 시간별 시각화, 할인률을 중요하게 생각 안하고있다.. 의도치 않게 비용이 증가하진 않았는지) 이것도 kontrol 뒤에 연동이 되어 통합되어있다.
• krp: 리소스 생성을 쉽게 도와주는 프로젝트

플랫폼으로 얻은 이득

1. 인프라 작업 요청 감소
2. 설정 디버깅 시간 감소
3. 설정 변경시 일괄 적용
4. 통일된 인프라.

2. 전사 배포 시스템을 만들기 전 알았으면 좋았을 것들 (김규환)

Kontrol을 만들면서 겪었던 경험과 인사이트

목차

1. 배포시스템 특징 및 현황
2. 개발자와 SRE간 이해 관계
3. 운영 컨텍스트 제공
4. 요약

배포시스템 특징 및 현황

container 애플리케이션

Dockerfile과 jib빌드지원

Low threshold

Self Service

kontrol 배포 현황

Kontrol 45 → 129

argocd 122 → 134

일 평균 76건

개발자와 SRE간 이해 관계

SRE: 안정성을 위한 구성 제약

개발자: 생산성 개선

개발자 관점 ≠ SRE 관점

개발자

• 빠르게 배포
• 문제가 있을때 바로 Rollback
• 빠르게 문제 파악

SRE

• 안정적으로 운영
• 일괄적으로 관리
• Low threshold를 제공

Kontrol 컨셉과 개발팀 고유 문화간 충돌

Kontrol 컨셉

• 이미지는 각 환경 구분없이 한번만 빌드

개발팀 상황

• 환경 별로 각 이미지들을 빌드해야 하는 애플리케이션 개발하는 개발팀

충돌시에 사용률 저조

신뢰저하

아무도 원치 않는 시스템 → 잠재적인 위험

이것이 전파되면 전시에서 사용X

이해관계를 맞출수있는 인센티브가 필요

주요 운영 지표 활용

배포 요청 실패 원인

배포 외 사용자 작업 타입 비율

기간별 배포수

배포별 배포 소요 시간

배포 실패율

→ 일찍 쌓을수록 좋다. → 최대한 일찍 쌓아라

운영 컨텍스트 제공

다음에 일어날 일을 이해하기 위해서 가능한 한 많은 컨텍스트가 필요

적절한 컨텍스트가 제공된다면

• 개발자와 SRE간 커뮤니케이션 비용 절감
• 문제원인 빠르게 파악

config와 Secret 변경 이력 확인에대한 어려움

플랫폼을 이동하면서 확인해야함

장애상황때 제대로 컨텍스트가 공유되지 않는 문제 → 커뮤니케이션이 어려움

배포

인스턴스 재시작

레플리카 스케일 인/아웃

각 상황에 필요한 컨텍스트를 적절한 공간에서 제공

트래픽이 얼마나 틀어오고

어떤 이벤트가 있는지 표시

요약

포장도로와 비포장도로 개념으로 운용

핵심 지표들을 최대한 빠르게 준비

의미있는 컨텍스트를 적절한 곳에서 제공

3. 클릭! 클릭! 글로벌로 향하는 멀티 클러스터 지원 스토리 (유병화)

2022년 6월

Argo CD vs Kontrol

ArgoCD

• K8S를 잘 알아야함
• JIRA로 요청하고 사람이 처리해야함
• 중앙 통제가 쉽지 않음, 설정 파편화 문제
• 자유도가 높음
• 한국 외 글로벌 리전 배포가 가능

Kontrol

• 낮은 진입 장벽
• 셀프 서비스
• 중앙 통제, 표준화가 쉬움 = 공짜 점심 ㄱㅇㄷ
• 자유도가 높지 않음
• 한국 리전만 배포 가능

kontrol은 글로벌 서비스가 배포가 안되었어서 ㅜㅜ 사용하기 꺼려짐

→ 딜리버리 파트 2022년 2분기 부터 OKR START!

Kontrol을 2023년 1분기 까지 글로벌 배포 지원 작업을 진행하게 된다!

리전 목록 설정을 어디에?

A안. 프로젝트 저장소의 values.yaml 파일 예시

 regions:
	 - kr
	 - ca 

문제: 위에서 ca를 삭제하고 배포를하면 ca 서비스의 리전의 프로젝트를 내려야하는가?

배포 파이프라인

Prepare

• 어떤 프로젝트의 어떤 Git revision을 배포할지 전달 받음
• Git 프로젝트를 클론, 해당 reversion으로 체크 아웃

Kontrol에서는 프로젝트를 생성하면 단계별로 프로젝트 파이프라인 3개를 생성함

→ Stateless 파이프라인으로 이동

• Kontrol에서 배포 id 생성, 디비에 Auto Increment 값 활용
• 컨트롤에서 디비를 활용해 낙관적 락으로 뮤텍스 구현

환경변수 관리

• Config 하나는 최대 8개의 (AWS Secret manager) Secret을 참조
• 이 Secret들의 상태를 Atomic 관리하기 위해 DB로 관리 시작

개발 경험을 높여주었던 3대장

1. TypeScript

대규모 작업을 할때 버그가 별로 발견되지 않았고 큰 변경을 할 때 자신감 있게 가능

1. Prisma

자바스크립트와 타입스크립트 커뮤니티에서 주목받고 있는 차세대 ORM(Object Relational Mapping) 프레임워크입니다.

1. Graphite

코드리뷰어 입장에서 높은 퀄리티의 리뷰를 할 수 있게 해줌 ( stack change 방식의 개발 가능 )

GoCD 좋은 도구이지만 Kontrol과 맞지 않음

4. 프로젝트 오너십 관리를 통한 DevOps 기반 만들기

클라우드 리소스 오너십 관리

리소스 오너가 없다면? 클라우드 리소스 관련 오너가 없다면 여러 이슈에 관한 질문을 할 수 없음

태그를 붙여준다? 태깅작업

문제

• chatA의 이름이 채팅A팀으로 변경된다면? → 다 하나하나 변경?!
• 해당 리소스의 오너십이 채팅 B팀으로 넘어간다면? → 다 하나하나 변경?!
• 해당 태그를 변경할 때 테라폼 싱크도 고려한다면?

오너십이 필요했던 Kontrol..

플랫폼에서의 오너십 필요성

kontrol이 하나 있고 그 위에 여러가지 서비스들이 존재함 (채팅, 배송 등등등 서비스들) → 프로젝트 네임만으로 오너쉽을 구분하기는 어려웠다.

데브옵스에 맞는 플랫폼이 필요해…

신뢰성 있는 오너십 정보를 한 곳에서 통합 관리하자!

katalog 서비스 설명, 아키텍처, 미래

1. 서비스

프로젝트 오너십을 제공하고, 오너십 기반으로 여러 메타데이터를 관리하는 서비스를 만들면 직/간접적으로 인사이트를 제공할 수 있는 데브옵스 기반을 만들 수 있을 것 → katalog 서비스 개발 karrot + service catalog

katalog

각 kontrol에서 배포되는

katalog에서 관리하는 클라우드 리소스 ownership

katalog를 도입 이후

사내 HR api에서 Team의 code값으로 리소스 ownership 관리 → 팀 ,조직이름과 같은 정보들이 변경이되어도 고유 값을 가지고 있기 때문에 문제가 없음

1. 아키텍처

go를 채택,

aws는 태그 에디터 api를 사용해 관리

AWS Resource Groups Tag Editor API를 활용해서 각 리소스에 카탈로그 아이디를 활용해 리소스 조회 또는 오너십 태그를 변경할 수 있음

GCP는 각 서비스 별 api, label로 조회하는 리소스 오너십 관리

GCP Cloud Asset API 특정 api, label을 기준으로 필터링

단점 → AWS는 라벨 업데이트 기능도 있는데 GCP는 라벨 업데이트가 없었다 ㅠ

대신 각 서비스별 api는 cloud asset api에 비해 한 번에 불러올 수 있는 리소스 개수가 더 많았다.

1. 미래

2. 카탈로그의 확장: 카탈로그가 관리하고있는 메타데이터, 언어, 서비스 티어링, 프로젝트 SLO등

   1. ex) datadog의 언어, 서비스 티어링, 프로젝트의 SLO등 katalog가 관리하는 데이터의 확장

3. 카탈로그를 이용하는 서비스의 확장: katalog api를 사용하게되는 확장 프로그램들 → 오너십 기반 알림, 비용 대시보드, 클라우드 리소스 셀프 운영 서비스, 오너십 기반 ... 서비스들이 확장될 것이다.

5. 개발자가 직접 관리하는 클라우드 리소스 (김승호)

손 (창업 시점) → 코드 (개발팀이 늘어남) → 손 (인프라팀 구성) → 코드 (인프라팀이 늘어남)

당근마켓 이야기

당근마켓은 생각보다 빨리 테라폼을 적용함

손 -? Terraform (창업시점)

• 국가별 클라우드 리소스 격리 가능하리라 기대
  • 한 국가만 테라폼으로 잘 구축해두면 나머지 국가는 날로먹는다?!
• 개발팀이 직접 리소스를 생성 관리 가능 (테라폼 코드 PR or 콘솔 조작 가능)
• 모든 개발팀에 테라폼 개발자가 존재할 수 없다는 현실도 인정 (=인프라팀에 요청가능)

테라폼 운영이 부담되기 시작

1000개의 테라폼 state..

3년전에 만들고 한 번도 수정하지 않은 프로젝트 리소스를 추가하려면..?

테라폼 버전, 프로바이더 버전, state 맞추다보면 하루가 금방

특정 리소스에만 apply → 이럴꺼면 테라폼 왜써 ㅠㅠ

해결책

→ 개발팀마다 클라우드 계정을 주고 인프라 관리를 일임 :

• 개발팀 인력 부담
• 인프라 비효율

vs

→ 개발팀의 모든 권한을 빼앗아서 인프라팀만 관리한다. :

• 인프라 인력 부담, 개발팀 효율 저하,
• 당근마켓 개발 문화에 어울리지 않음

잔짜해결책

• 테라폼만큼 어렵지 않고
• 인프라팀을 기다리지 않고
• 내부 관리 규칙을 준수하면서도
• 개발자가 직접 클라우드 리소스를 관리한다면? → 마침 kontrol이 있네?

나왔다 krp

Krp

사용자에게 가치 전달 극대화 목표

• 파이썬/FastAPI 도입
  • 디비 도입은 최대한 늦추자
  • 처음부터 디비가 필요했다면 쟝고 썼다
• AWS
  • 대다수 리소스는 AWS에 존재
• Boto3 라이브러리로 AWS API 호출
  • 테라폼에 의존하지 않기로 함 테라폼과헤어질결심ㅠㅠ
  • plan이 깨지거나 state가 안 맞을 대 괴로움 예상

목표

1. 반복되는 aws 리소스 생성 jira이슈를 0으로 만들자
2. 멀티 환경 멀티 리전의 리소스 생성 시간 복잡도가 O(n) → O(1)
3. 리소스 생성 누락 0으로

UI 뒷편에는 당근마켓 규칙 적용

• 레디스별 서브넷 그룹 생성
• 계정 환결병 값 지정
  • 서브넷이나 보안그룹
  • AZ, snapshot window, maintenance window
• 소유권 관리용 태그를 katalog 받아와서 적용
• 엔진 버전별 Parameters Group 지정
  • Keys 명령어 사용 제어

Redis 기능추가

• 모니터링용 datadog 대시보드 생성
• 슬랙에 메시지 발송
• Replica 개수 조정
• Shard 개수 조정
• 노드 타입 수정
• 삭제 요청
• 관리 이력

회고

• 디비 도입은 최대한 늦추자
  • 처음엔 디비가 없어서 빠르게 기능 개발에 집중 가능
  • 10개월쯤 지나서 필요성 느낌
• Boto3 AWS API가 생각보다 복잡 의외로 테라폼도 괜찮을지도
  • 지나치게 쪼개진 api client
  • 내부적으로 비동기 처리여서 응답은 빠르지만 번거롭다
  • 생성 도중 실패하면 중간에 생성했던 리소스도 삭제 필요
  • 하지만 대안이 없다..

추가 대응중인 리소스

• StaticStie(S3 + Cloudfront + Route53)
• DynamoDB

6. 당근마켓 서비스를 모니터링하는 방법 (배상익)

1. 당근 마켓의 과거와 현재

2021년 8월 26일(약 1년반 전)

http 75k rps, gRPC 60k rps

→ http 145k rps, gRPC 344k rps (2023. 6.10)

MAU 1200만명에서 1800만명으로!

조직 구조와 scalability

고층 건물을 짓기 전에 지반이 탄탄한게 우선!

인프라 정책 다듬기

인프라실 안에서 얼라인이 안되어있다면 개발자들 역시 혼란스러울 수 있음.

기술 부채와 파편화, 비용에 대해 항상 경계

메타데이터를 정의하고 효율화하는 부분에서 정책은 굉장히 중요하다.

공통 모니터링 영역에 대해 잘 케어함으로써 개발자가 놓칠 수 있는 부분을 서포트

2. 모니터링 방법론

USE method

• utilization
• saturation
• errors

RED method

• rate
• errors
• duration

Four golden Signals

당근마켓 모니터링 인프라

main은 prometheus와 cortex, loki등으로 구성된 내부 모니터링 인프라

sub로 데이터독 도움을 받는중(그림은 watchdog, apm, cloud integration 잘 활용중)

모니터링 방법론을 우리 상황에 맞게 구현

• 서비스 대시보드
  • 네임스페이스를 기준으로 각 개발자들이 자신의 서비스를 더 잘 이해할수 있도록 제공 일관성 있는 대시보드를 보며 함께 이야기하고 성장
• 서비스 오버롤 대시보드
  • 네임스페이스기준을 더 벗어난다.

공통영역인 쿠버네티스 event/status를 잘 보여주려고 한 k8s group

서비스 overall 대시보드를 운영 (지역 기준 전역적인 쿼리)

전역 모니터링과 깨진창 관리

모니터링을 토대로 이상감지 후 얼럿 기반으로 디버깅 스코프를 줄인 뒤

Root Cause는 Loki에 쌓인 로그나 별도 데이터 파이프라인, APM등을 활용해 찾을 때가 많음

변화하는 상황에 따른 대시보드 축적

장애일지와 대시보드 보강

• 장애 일지에 5 whys와 lesson learned를 작성하고 있음
• 매주 목요일 개발팀 미팅에 서로 공유
• 인프라실 보강할 후속 조치

1분기 OKR 비용 절감

Container CPU limit 해제에 따른 노드 모니터링 보강

• CPU, Memory, Disk, Network.. etc

Spot Instance 프로덕션 도입에 따른 Pod eviction 리스트 및 대시보드 보강

Locality Load Balancing 적용에 따른 region skew monitor 추가

인프라 닥터 대시보드 구축중

• Istio Doctor Dashboard
• HAproxy Doctor Dashboard
• Kube-system Doctor Dashboard

인프라 이슈인지 아닌지 큰 줄기의 판단으로 엔지니어의 불필요한 디버깅 시간을 단축시킬 수 있다

Infra Planning

• 매트릭, 대시보드 등의 도움을 받아 capacity, planning에도 사용
• 영향도를 고려해 작업의 우선순위, 이슈레벨을 판단
• 이슈와 대시보드 데이터를 토대로 다음 업그레이드까지의 분석

역량 축적

• 지식 공유와 휠을 대시보드와 얼럿 시스템 보강으로 더 돌리기
• 당근마켓 서비스 안정성과 SRE 역량 강화로 이어지고
• 이를 토대로 예측가능한 인프라를 만든다고 믿는다.

7. Mutli-AZ EKS 클러스터에서 Locality LB를 활용한 비용 절감 사례 (허진수)

개요

어떤 pod들이 cross-zone traffic을 많이 발생시킬까?

cross-zone (redis, eks….etc)

→ VPC Flog Logs와 Pod Metadata를 결합해서 Cross-zone traffic을 봤어요.

• Istio Ingress Gateway가 주범
• Istio Mesh 안에서도 많이 발생
• Istiod가 비용을 많이 먹었다.
• Monitoring도 많이 먹네..

Istio Locality LB

Istio Locality LB를 어떻게 구현할 수 있을까?

EKS Worker Node 정보엔 Topology 정보가 있다.

Istio Locality LB를 위해 Istio OutlierDetection이 필요하다

Virtual Service에 붙어있는 Destination Rule에 outtlier Detection이 꼭 필요하다

Topology Aware Hints

Istio를 안쓰는 Pod들은 어떻게 하나요?

service.kubernetes.to/topology-aware-hints: auto

cost

과연 비용이 얼마나 줄었을까요?

당근은 7만불 넘게 줄였다 ㄱㅇㄷ

가용성과 부하 분산에 대한 고민

AZ가 무너지거나 균등 배포가 깨지면 어쩌지?

• AZ가 무너지면 자동으로 Failover
• 진짜 문제는 균등 배포가 깨졌을 때
• 모든 Pod이 균등하게 트래픽 분산 x
• 싱글존 EKS의 Active-Active 구성

How it works?

Istio란

서비스 메시를 구현하는 오픈 소스 프레임워크, 마이크로서비스간의 통신을 제어하고 관리할 수 있는 기능을 제공한다. 이중에는 서비스 간의 로드밸런싱 기능도 퍼함되어 있으며 이는 Istio의 Envoy 프록시를 통해 구현된다.

8. grafana를 활용한 효율적인 알림 시스템 구축 (이시은)

grafana elert 소개

Alerting (legacy)

• grafana v10부터 지원 x ㅠㅠ

alert rule에는 3가지 상태가 존재

1. OK ( 건강한 상태 )
2. PENDING : 알람 조건에 충족하여 알람 세트가 생성된 상태이다. Alert Rule에 정의된 "for" 기간 동안 이 상태를 유지하게 되면 "FIRING" 상태가 된다.
3. FIRING : "PENDING" 상태가 주어진 기간동안 유지될 경우, 이 상태로 전이한다. 이 상태가 되면 Prometheus는 알람의 "Notification"을 Alertmanager로 전송한다.

Rule

• Evaluate Every : 몇 분에 한 번씩 평가
• Evaluate For : 몇 분 동안 지켜본다

Conditions

• 알림 평가 조건 (임계치)

No data and error handling

Notifications

notification channels

• 다양한 타입의 알림 채널 설정

한계

1. 평가된 모든 time series가 하나의 메시지로 전송
2. 네임스페이스별 알림 대응 불가능
3. 메시지 내용 커스텀의 한계로 인한 가독성 저하
4. 알림 종류별 reminder 시간 조정 불가능
5. 프로젝트별 담당자 정보를 함께 봐야할 필요성

alert-delivery의 등장

• 알림을 네임스페이스별로 나누어서 볼 수 있게하자
• 메시지의 가독성을 높이자
• 개별적인 알림 제어
• 알림에 담당자 정보를 담자
• 전체 알림 상황을 한 번에 볼 수 있도록!

→ 최종 메시지 형태

• 제목에 네임 스페이스 알림 타입 포함
• metric label을 추가해 가독성 up
• kontrol 프로젝트 링크 추가
• katalog api를 이용해 담당자 정보 추가
• 서비스 대시보드 & 로그 대시보드 링크 추가
• 필요 시(알림 n회 이상 발생) 담당자 바로 멘션
• 알림 끄기 버튼으로 슬랙 내에서 snooze 가능

알림 개별 제어 기능 - 팀 멘션

세부 제어 예시1 (

ingress 5xx 에러에 대해서 503 코드에 대해서는 팀 멘션 하지 않기

but 503 이지만, responseFlag가 UC 이거나 메트릭 값이 1000이상일 경우에는 멘션

5xx 에러 값이 1200이 넘으면 SRE팀 전체를 바로 멘션하기

)

알림 개별 제어 기능2 - snooze

slack, web에서 알림 끄기 → grafana에서 alerting 상태여도 슬랙 알림이 x

효용과 과제

• 개별 알림 제어로 verbose한 알림의 감소
• 매 시간마다 알림 진행상황 리포트
• namespace 별 알림 history를 쉽게 확인
• 전체 알림 현황 시각화

백엔드 개발자(나)의 관점에서 본 후기

• 백엔드 개발과 SRE 파트가 나누어져 있더라도 항상 인프라에 관심을 가져야할 것 같다
• 백엔드 개발자는 프레임워크를 다루면서 api만 만드는 것이 아닌 인프라 구축에도 힘써야한다
  • 즉 데브옵스에 신경을 많이 써야한다
• 도커, 쿠버네티스, 테라폼과 같은 도구들을 사용할 줄 알면 정말 좋다
• MSA 최고다
• 큰 기업일 수록 여러 방면의 환경적 문제를 관리하는 것이 보이며 비용과 트래픽 분석에 더욱 심오하게 파고들어야한다고 생각한다.
• 이러한 안정적인 환경을 조성함으로써 더욱 탄탄한 인프라를 구성해 더욱 좋은 환경을 구성할 수 있다.
• grapana 사용과 같이 서버의 상태의 alert를 띄워주는 작업은 간단한 것 같으면서도 요구사항을 적용해서 띄워야 하는 것은 어렵다.. 그래도 만약 띄운다면 정말 유용할 것 같다!