당근 인프라의 gcp 활용법

추천시스템 w/Dataflow 대규모 데이터 파이프라인 구성

Dataflow

  • 완전관리형 데이터 처리 서비스 (클러스터 관리 없이)
  • 실시간 스트리밍 배치 처리 모두 지원
  • 자동확장, 오류 복구, 리소스 최적화
아키텍쳐 / 동작방식
  • 입력 : bigQuery, kafka, Cloud Storage, Pub/Sub
  • 처리 : Apache beam 파이프라인 실행(ETL, 변환, 집계)
  • 출력 : Cloud Spanner, bigQuery, Cloud Storage, Pub/Sub → 파이프라인 단일 소스로 관리 가능
장점

코드 재사용 가능 운영 오버헤드 최소화 -> 개발자는 로직에만 다른 서비스(DB,DW Event Stream)와 손쉬운 연계

당근 활용 사례
  • 실시간 & 배치 게시글 임베딩 생성 파이프라인(GPU Inference)
  • 실시간 & 배치 카테고리 (텍소노미) 분류 파이프라인 *kafka에서 생성된 데이터도 1년치도 한 달치도 동일한 코드로 한 번에 배치 작업 가능
  • 전사 ML 훈련 데이터 가공 (bigQuery데이터 텀프, 데이터 가공)

대규모 데이터 파이프라인 구성

→ n대 이상의 워크로 Scale Out 하는

pcollection에 추가된 데이터 용량 - 1주일 통계 피크4PB 가량

당근 테크 밋업(2024) 글(https://tech-meetup.daangn.com/) 참고

Q&A

  1. 빔으로만 파이프 라인을 구성하는지? Spark 와 같은 백업 파이프라인도 가동이 되고 있는지? Apache beam 러닝커브는 어떻게 해결하고 있는지? → 텐서플로우를 쓰기 위해 Apache beam을 기존에 사용하고 있어서 가능했음. Spark는 ML, 추천시스템쪽에서는 사용하고 있지 않음.

  2. 실시간 파이프라인, 배치를 하는 이유는? 그리고 GCP에서 제공하는 임베딩 API를 쓰지 않고 별도의 임베딩 모델을 사용하는 이유는? → 마이크로 배치, 준 실시간도 있음. 임베딩 API, 자체 데이터에 맞춰 튜닝한 모델을 쓰기도 함

    ML Infrastructure with GCP

01 Service Growth in 2024

Kubeflow

파이썬 기반으로 컴포넌트 확장이 가능, 컴포넌트 개발의 자유도가 높음. → 컴포넌트 구현 방식이 제각각이라는 뜻.

TFX
Protobuf
  • 유사한 파이프라인 문서를 모아두고 실험을 쉽게 할 수 있도록 구조를 잡아줌.
  • 파이프라인은 증가하여도 구조화가 잘되어서 유지가 가능하나 인프라의 문제는 여전함
VertexAI 파이프라인
  • Kubeflow + TFX pipelines
  • 파이프라인 내 식별
Prompt Studio

당근의 LLM Router 와 결합하여 구축 사용중인 플랫폼

Q&A

멀티클라우드 환경에서 GCP를 keyless로 쓰는 방법

OIDC란?
  • OAuth 2.0 사용자 인증 프로토콜
  • RP 받는 쪽인 토큰의 클레임을 검증 받음
  • 이 앱이
당근에서의 GCP 리소스 접근방식
  • Service Account // GCP 내에서는 그대로 사용 외부에서 Service Account 를 이용할 때 key를 이용해서 접근
  • Kontrol? 당근의 사내 플랫폼. 배포 Menifesto를 작성하여 배포

대규모 이미지 서비스

S3, CloudFront
이미지 서비스의 중요도
  • 개발환경 3개 지역 운영환경 4개
  • 특정 이미지의 경우 유효기간 Signed URL 형태의 제공이 필요
  • 동적으로 이미지 조절 및 변경 필요 → 비즈니스 로직을 동시에 처리하면서 서빙이 필요
GCP를 사용하는 이유
  • BigQuery, 사용을 위해 이미지 원본 자체를 GCP에 있으면서 CDN도 사용

user -> cdn -캐시미스-> origin

user -> cloud cdn -동적 리사이징 및 포맷 변경작업(Cloud Run)-> cloud Storage

user -> cloud cdn -캐시 미스-> cloud load balancing -동적 리사이징 및 포맷 변경작업(Cloud Run)-> cloud Storage

cloud load balancing? 왜 ? GCP 권장사항 로드밸런서가 필요.

cloud cdn
  • 캐시 모드 캐시 키 : URL에 포함되에 있는 쿼리 매개변수가 조금이라도 바뀌면 캐싱 미스가 발생 그러면 Cloud Run에 가서 원본에 대한 동적 조절이 일어나도록 함.
  • 제한된 콘텐츠 : Signed URL 에 맞춰 만료된 경우 404
  • 원본 세부정보 / 연결된
  • cloud CDN 요청을 받기 위한 프런트엔드 구성 및 SSL 통신을 위한 TLS 인증서 연결
  • Signed URL 처리 : 요청이 서명되지 않은 경우?(서명 관련된 값이 쿼리 매개변수가 없으면 바이패스함),
Cloud Run
  • 캐시 미스로 원본 요청을 할 경우 애플리케이션 수준에서 서명 검증 요청 헤더값에서 x-client-request-url 사용
  • 라우팅 규칙 설정시 쿼리 매개변수도 함께 설정할 수 있음.
  • cloud Storage 간 데이터 전송 비용은 무료

GCP 모니터링

로그 탐색기

단순 문자열

Metricss Explorer에서 지표 시각화를 통한 대시보드 구축도 가능 그라파나나 Bigquery 연계 cdn을 통해서 들어온 Lb를 탄 요청을 BigQuery에 쌓는 플로우 CDN Latency 지표 알림 구축

배포방식

  • Github Actions 로 자동 배포
  • revision_tarffic 배포 버전에 따라서 트래픽 조정?
  • no_traffic 옵션을 활성화 해야 신규 배포 때 트래픽 전환 가능 최신 배포를 100% 만든 뒤에 트래픽을 조정할 것
  • 7개 인스턴스를 빠르게 배포해야 하고, 파이프라인을 재사용
  1. 캐시 키를 설정할 수 있음
  2. 유효기간이 있는 서명 검증 설정 가능
  3. Cloud CDN 원본으로 지정하려면 LB와 NEG가 필요
  4. x-client-request-url 요청 헤더로 서명 원본확인
  5. cloud Storage 간 데이터 전송 비용 절감 가능
  6. Log Router로 로그를 BigQuery로 적재 가능
  7. 배포 때 트래픽 분산 가능

Q&A cdn 캐싱 시간을 클라우드에서 정의하거나 원본이 바뀌 었을때 무조건 내려주도록 처리를 해야 할 필요가 있음

This line appears after every note.

Notes mentioning this note

There are no notes linking to this note.

Here are all the notes in this garden, along with their links, visualized as a graph.