[컨퍼런스] 2025 당근 플랫폼 밋업 참여 후기 (2025.11.07.)

서론

https://www.ticketa.co/events/32

 

최근에 AWSKRUG AI enginnering 소모임, AWS Community Day 등 크고작은 컨퍼런스들에 참여해서 인사이트를 얻어왔는데, 최근 다녀온 당근 Platform Meetup에서도 인상 깊은 발표가 많았어서 해당 내용을 정리해보려 한다.

 

수빈님께 무한한 감사를 / KRUG 소모임 갔을 때

 

AUSG 슬랙방에 수빈님께서 관련 링크를 올려주셔서 미리 알고 광클해서 예매할 수 있었다. 예매하고 다시 들어가보니 2분만에 매진되어있었는데 느긋하게 예매했으면 못 갈뻔했다.

 

총 7개의 발표와 네트워킹 시간으로 구성되어 있었는데 그 중 몇가지를 정리해보겠다.

발표장이 넓고 좋았다. 마치 연극이나 영화관 처럼 생긴 공간이었다.

발표1 - 달리는 자동차의 잠금장치 교체하기: 인증 시스템의 중앙화

오현준님께서 발표해주셨다. 주된 내용은 MSA의 인증 시스템을 중앙화 시키기 위해 로직을 교체하는 과정에서 중단 없이 교체한 내용이었다. 수십만 트래픽을 받는, 심지어 앱 서비스라 버전에 따른 처리도 해줘야하는 상황에서 프로덕션 환경의 인증 서비스를 교체한 부분이었다. 제일 인상 깊었던 부분은 기존 API도 살리면서, 새로운 인증도 병행해서 동작할 수 있게 한다음 기존 인증을 제거하는 방식이었다.
MSA에서 이런식으로 설계하면 확실히 역할과 책임의 분리가 되겠다는 생각이 들었다.

 

인증 시스템 중앙화 & 무중단 마이그레이션

• 로그아웃 전까지 토큰이 유지되는 등 보안 문제
• 트래픽 증가로 인한 DB 부하

인증 중앙화

• JWT + 토큰 페어
  • 성능 문제 & 보안 문제 해결 → JWT는 스스로 정보를 담을 수 있음
• 마이크로 서비스가 많았기에 매번 미들웨어에서 인증하는데, 인증 갈아끼면 모든 MSA에서 미들웨어 교체해야함
• 당근의 MSA 인프라 쿠버네티스와 Istio (서비스 mesh?)
• 쿠버위에 Istiod 설치하면 각 pod에 istio-proxy를 주입함
  • Istio의 AutorizationPolicy 를 만들어두고, istio-proxy가 rule base로 api 인증 가능
  • 커스텀도 가능해서 gRPC 요청을 auto-rule-server로 넘겨줌
• 인증 로직 gRPC로 중앙화

무중단 마이그레이션

처음에 신규 클라에서는 구/신 토큰을 모두 쓸 수 있도록 하고 배포

• 기존 클라 요청을 istio-proxy에서 받으면, envoyauth에 오도록하여 기존 토큰 인증 API 호출 → 커스텀 헤더(user_id)를 반환
• 신규 클라 요청은 istio-proxy에서 받으면, envoyauth가 신규 API를 호출하도록 함 → 커스텀 헤더(user_id)를 반환
• MSA에 있는 서비스 로직을 바꿈 → 인증 미들웨어 를 걷어내기 위해서 , 마이그레이션 미들웨어로 바꿔줌 커스텀 헤더가 있는지 여부로 판단.
• 신규 api만 있는 클라 만들어서 배포
• 이후 사용자 점유율에 따라서 앞에서부터, 닫아버림

해결 사례

• 인증 서비스 하나만 수정하면 되도록 바뀜
• 메타정보 취합이 어려운점 해결
• 인증에 대한 가시성 확보(얼마나 성공하는지)
• istio-proxy로 복잡한 라우팅 설정이 가능한데, namespace를 잘 명시해줘야한다.

 

발표2 - 어느 날, 이미지 CDN이 터졌습니다: 킬 스위치

김수빈님께서 발표해주신 내용이다. 그동안 당근에서 어떤걸 개발 하시는지 정확히 알지는 못했었는데, 이번 기회에 알게되었다. 제목 그대로 클라우드 제공사의 CDN이 동작하지 않아서 이미지가 노출되지 않는 상황을 겪고, 새로운 아키텍처를 설계하신 이야기를 해주셨다.

특히 이 발표는 더욱더 인상 깊게 봤던게, 이때와 동일한 이슈인지는 모르겠지만 당근마켓에 이미지가 되지 않을 때 내가 유저로서 당근을 썼던 것이다. 발표를 보다가 생각나서 채팅을 찾아보니, 올해 6월에 한창 야구에 미쳐서 카드 모을 때 있었던 일이었다.

아ㅋㅋ

더욱 집중해서 들을 수 있었고, 최근에 있었던 AWS DDB DNS 이슈와도 맞물려서 인상 깊은 발표였다.

 

Edge Node(PoP) 배치하고, 콘텐츠 제공 → 장애 발생시 해당 PoP만 비활성화하면됨

왜 터졌는가

• Signed URL을 Cloud Run에서 검증 ← 민감한 이미지 signed를 위해서
• GCP에서 갑자기 cloud run에 넘어갈 때 header가 없어짐
  • x-client-request-url
• 킬 스위치 아키텍처를 도입함

외부 요인으로 부터의 장애 발생 대응

• DNS → LB → CDN → Serverless → Origin
• 업로드 시 스토리지 이중화
  • dual write는 어려운 상황 → presigned url 이용하기 때문
  • 스토리지 동기화 생각해봄
    • 비용과 작업 공수 많이듬, 이미 겹치는 object-key 변경도 어려움
  • 버킷에 없는 object라면 반대편 클라우드 Bucket도 조회 시도
    • 비용 지연 증가
  • 특정 도메인으로 요청시 고정적으로 반대편 클라우드의 Bucket 사용
  • 도메인을 합치고 DNS 스위칭
    • ID 대신 이미지 URL을 저장하여 사용하거나 캐시하여 사용하는 경우
    • 스토리지 이중화 등 선행작업 필요
    • TTL도 300초 필요

킬스위치 아키텍처

• CDN이랑 lambda@edge를 GCS를 바라보도록 유지
• CDN이랑 cloud run을 S3를 바라보도록 유지
• 어떤 CDN을 볼지 어떻게 결정?
  • 장애가 발생시 Feature Flag만 변경하여, 클라가 사용할 이미지 url의 호스트만 변경

파편화된 장애 모니터링 대시보드 합치기 ← datadog, grafana, cw 등등

• 다양한 리전, 환경에서 검증
• 전면 장애 방지
• 장애 중 flag 활성시 지연이 늘어나는 한계점

발표3 - 10x 빠르게 10x 싸게: Quickwit 기반 신규 로그 파이프라인

이승훈님께서 발표해주셨다. Quickwit 이라는 오픈소스를 이용해서 로그 파이프라인을 구축하신 이야기를 발표해주셨다. 대규모 시스템에서 어떤식으로 로깅이 돌아가는지 이해할 수 있었다. 재미있었던 건 예전에 소마에서 서비스 개발할 때 로깅을 Opensearch에 다 넣었다가, 프리티어 끝나자마자 요금이 어마무시하게 나가서 바로 때버렸던 기억이 났는데, 당근 같은 큰 규모 서비스에서도 로깅 비용까지 고려해서 설계를 하는 부분이 인상깊었다.

 

로그시스템

• 기존 시스템
  • Loki
    • 컨테이너 로그 저장
    • 로그를 객체 저장소에 저장 비용 효율적
    • 로그 양이 많아지면 검색 속도가 늘어나는 문제
    • Loki는 label만 인덱싱 ← 인덱싱이 빠르고, 용량 감소 가능
    • 같은 label 묶음끼리 stream이 되고, chunk로 나눠서 저장됨
    • label이 늘어날 수록 기하급수적으로 stream 늘어남
    • Shared Disk Arch. → 스토리지 컴퓨팅 분리(S3 싸다!)
  • OpenSearch - Access Log 수집, 빠름 ← 비용 4~5배 비쌈 == 짧은 보관 기간, 일부 서비스만
    • 역인덱스 사용 - 문장을 단어 단위로 저장해서 단어 단위로 인덱스 ← 필요한 문서 위치를 인덱스로 만들어 둠
    • Shared Nothing 아키텍처 - 각 노드마다 독립적으로 CPU Memory 유지
    • 노드 실패시 유실을 막기 위해 복제본 유지 x3배 비용
• Quickwit
  • loki보다 빠르고, opensearch보다 싸다
  • 빠른 검색, 낮은 비용, 손쉬운 운영
  • 클라우드 스토리지 기반 분산 검색 시스템
  • 로그 저장 및 저빈도 검색에 최적화
  • 역인덱스 사용, 객체 저장소에 로그 저장, 스토리지 컴퓨팅 분리
  • 낮은 성숙도 - 2021년산
  • 실시간성 부족 (1분 이상 걸림)
  • 레이턴시에 민감한 서비스 트래픽에는 적합하지 않음
  • 인덱스의 여러개 split으로 구성 ← 퀵윗 최소단위
    • 수백 MB~수GB
    • 불변 구조
    • 객체 저장소 하나의 파일
  • Log → Indexer - S3, MetaStore(Postgres) - Searcher
    • Upload Split
    • Insert Split metadata
    • Searcher는 root - leaf로 구성, 요청 받은놈이 Root가 됨
      • Root → Metadata 검색, Leaf한테 검색 요청
      • Leaf → HotCache 메모리에 올림, 빠르게 DocList읽기 → DocStore에서 최종 결과 얻기
• 신규 로그 파이프라인
  • 도입전 PoC 진행 ← 로그가 가장 많은 팀을 대상으로 사용성 평가
    • 신규 파이프라인으로 듀얼 write를 통해 사용성 확인
  • Datadog의 Quickwit 인수
  • 로그 콘솔로 찍으면, Pod Log → Collector(백터?)가 카프카(다른 컨슈머 붙일 수 있도록)로 던짐 → 카프카에서 Quickwith Index Cluster로 넘김
• 성과 → 로그비용 감소, 저장기간 증가
  • MCP 붙여서 Quickwit 조회도 가능
  • 카프카로 파이프라인 더 붙이기도 가능

 

발표4 - 로컬 스크립트에서 하루에 한 번 돌아가는 파이프라인이 되기까지: 당근지도의 여정

박소희님께서 발표해주셨다. 당근지도를 만드는 과정에 대해서 발표해주셨는데, 그간 지도는 여러 서비스에서 SDK로 받아와서 사용해본적은 있지만, 한번도 이 지도가 어떻게 만들어질까에 대해서 생각해본적 없었던 것 같다. 이 발표로 지도 생성 시스템이 어떻게 돌아가는지 엿볼 수 있었고, 그간 내가 알지 못했던 새로운 분야에 대한 고민이어서 신선하게 들을 수 있었다.

 

지도 만드는 과정

• WMTS: 웹 환경에서 지구 전체를 표현하기 위한 표준 프로토콜
  • Map tile이라는 최종 단위로 나뉨 (z,x,y) → zoom-index, x,y 로 정의할 수 있음
    • z+1마다 2^n으로 tile 수 증가
  • 미리 만들어놓은 조각을 불러오기만하면됨 → 조각 합쳐서 랜더링해주면됨
• 한국 기준 8M 조각필요

1. 제작, 서빙 프로세스 PoC
   • RabbitMQ 써서 메시징 파이프라인 사용
   • 재귀적으로 처리
     • 하이브서빙으로 z-level < 15까지는 cloudfront에 박고, 나머지는 동적으로 가져오기
       • 근데 NW/CPU 부하 증가, DB 부하 증가
     • 버전관리의 부재
2. 시스템 구축 및 운영 전환 - 확장성, 신뢰성, 운영성

• RabbitMQ → Kafka
  • topic 단위 파티션으로 병렬 처리 가능
  • 재처리 보장 가능, 메시지 offset 기반
  • gRPC 요청 받기
• 공간복잡도로 인해 DB 부하
  • 쿼리 결과를 캐싱하여 재사용
  • vertex 많은 부분 더 작게 쪼개기

3. 시스템 가시화 모니터링

• 하루에 한번, 작업을해서 안정적인 배포
• 실패시 그 작업만 재시도 가능하도록
• DB기반 작업 큐 관리

후기

블로그에 담지못한 나머지 발표들도 재미있는 포인트들이 있고, 인상깊었는데 발표해주신 분들 모두 개발 난이도나 성과를 떠나서, 발표력에 감탄했다. 30분 동안 한 주제로 이야기를 풀어가기가 쉽지 않은데 한 분도 절지않고 발표하시는 걸 보고 발표 스킬에 대해서도 많이 배우고 생각해볼 수 있던 하루였다.

 

네트워킹 시간에도 발표자분들께 자유롭게 질의응답을 할 수 있었는데, 발표에 대한 질문도 할 수 있었고, 당근 내에 개발 문화에 대해서도 궁금했던 부분들 많이 여쭤보고 좋은 말씀 많이 들을 수 있었다. 

 

그리고 나눠주신 굿즈?도 마음에 들었는데, 특히 AWS 로고가 같이 들어간 파우치와 안경닦기가 아주 마음에 들었다. 책도 한권 같이 들어있었는데, 최근에 트랜드가 AI를 이용한 개발이 핫한데, 당근에서 어떻게 사용하는지를 다루고 있는 책인듯하다. 최근에 Q 해커톤 다녀온 이후로 신경을 많이 쓰고 있는 분야인데, 틈틈이 읽어봐야겠다.

 

https://www.ticketa.co/events/32

2025 당근 플랫폼 밋업 | 티켓타코