배달의민족 광고데이터 이관기

출처: https://techblog.woowahan.com/14041/

배달의민족 광고데이터 이관기 | 우아한형제들 기술블로그

 

 

광고데이터가 활용되는 곳 

광고 노출시, 가게들이 어떠한 순서로 보여질지를 데이터를 통해 결정됨 

 

 

위와 같은 도식으로 되어있음

응답시 사용되는 데이터는 가게가 적절하게 노출될 수 있도록 하는 핵심 데이터 

{가게 번호, 가게이름, 사용자 거리 등등}

이러한 데이터는 ElasticSearch에 저장이 되어 서빙되고 있음 

 

ElasticSearch

- text 검색이 매우 뛰어난 검색엔진 

- 대량의 데이터를 저장,검색,분석 가능

 

작업배경

대규모 이벤트 기간에는 평소보다 높은 트래픽을 처리하기위해 Elasticsearch data node와 client node를 미리 scale-out 하는 등의 선조치가 필요 

이벤트가 끝난이후에는 scale-in을 다시 해야됨

 

하지만 scale-in 시에는 직접 서버를 detach해야됨 이에 실수를 유발할 수 있고, 이러한 실수는 회사와 가맹점에

금전적 손해 및 최악의 고객 경험을 초래

 

이에 AWS 클라우드 서비스로 전환을 결정 

 

이관시 장점 

• 잦은 scale in/out에도 버튼 클릭 한 번으로 수월하게 진행하여 휴먼에러 발생 가능성 차단
• 구축형 클러스터 관리 리소스 및 비용 절감
• Elasticsearch 클러스터의 편리한 업데이트
• AWS의 기술지원

 

작업 목표 

• 절대 시스템 다운타임이 발생하면 안됨
• 기존 코드 변경의 최소화 

기존 아키텍처 

기존의 광고데이터가 어떻게 적재되고 활용되고 있는 지 간단히 살펴보겠습니다.

1번을 보시면 jenkins로 batch job을 만들어 내일 송출할 광고를 위한 index(prepare 인덱스)를 미리 전날 생성합니다. 

3번 실시간으로 광고데이터 변경이 일어나기 때문에 각 도메인 담당팀으로 SQS를 통해 데이터를 받고 있음

받은 새로운 광고데이터를 prepare 인덱스에 인덱싱

full 인덱싱 과정에서 수정된 데이터를 current와 prepare index 모두에 반영

2번 다음날 0시가 되면 current인덱스의 alias가 전날 만들어놓은 index(prepare인덱스)로 변경

 

 

마이그레이션 아키텍쳐 

 

2가지 마이그레이션 방법

1. 적재를 2번 수행하여 기존 Elasticsearch와 신규 Elasticsearch에 적재 
2. 기존 Elasticsearch의 인덱스 적재 작업이 끝나면 remote reindex로 신규 Elasticsearch에 복사 

 

둘 다 이론상 문제는 없지만 최대한 보수적으로 절대 다운타임이 없어야 되기 때문에 1번 수행 

구축된 환경은 아래 도식과 같음 

 

 

기존 아키텍쳐(왼쪽)를 그대로 하나더 생성(오른쪽) 하였음

문제시 바로 롤백 할 수 있어야 되기때문에 기존 리소스는 그대로 존재하고 있어야함

 

위 아키텍쳐의 요구사항은 아래와 같다.

• 매일 적재되는 광고데이터를 두 Elasticsearch에 동일하게 적재해야됨 
• 실시간으로 변경되는 광고데이터를 두 Elasticsearch에 동일하게 반영해야 함 

 

첫번째 요구사항을 만족시키기 위해 

광고데이터를 풀 임포트할 때 두 개의 인덱스에 저장해야함

해당 정보를 다른 팀을 호출하면서 진행되어 평소 트래픽에 2배를 타팀에서 받아도 되는 지를 확인해봐야됨

 

Full Import 

먼저, 캠페인 색인이라는 광고데이터 인덱싱작업을 진행

캠페인 색인 도중 광고데이터 변경을 막기위해 

변경사항을 메세지 큐로 만들어두고 인덱싱이 끝난후 차례로 반영 

신규 Elasticsearch에 풀 임포트하는 과정도 동일하게 구성 

 

 

성능 테스트

 

신규 elasticsearch에 대해 최소 운영환경만큼의 트래픽을 받아낼 수 있는 지 확인하는 테스트 

 

  현재 피크 시간대 API별 요청량 비율을 확인 

      요청량 비율로 하는 이유는 ngrinder에서 성능테스트시 api별로 호출비율을 동일하게 진행하기 위

 

 

릴리즈 시나리오 

 

배포준비

• 주요 변경사항 기록
• 사전준비
  • 배포전에 준비해야할 것들 기록 
• 베타환경 릴리즈 플랜 재현
• 운영배포
  • 배포 순서를 정확한 시간과 함께 작성 
• 롤백시나리오 작성

 

모니터링

신규 elasticsearch와 기존 elasticsearch가 sync가 맞는 지 계속해서 모니터링 

매분 모니터링할 수 있게 배치를 구성, sync가 안 맞으면 slack으로 알람

 

결과

2가지 성과 존재

• 개발자 운영 리소스 절감 및 운영환경 리스크 감소
  • aws 기술지원으로 수동 scale in/out에 대한 부담 사라짐 
• 서버 비용 축소 
  • master, data 노드만 사용하도록 축소
  • 성능 테스트를 통해 장비스펙 최적
  • 비용 40% 감소