기술 컨퍼런스, 기술 블로그, 아티클, 강의 등 다양한 자료로 학습한 내용과 인사이트를 기록하는 시리즈입니다.
배민서비스 역사
2015
- 히루 주문수 5만 이하
- MS SQL + PHP, ASP
- 대부분 루비DB(MS SQL) 스토어드 프로시저 방식 사용
- 루비DB 장애시 전체 서비스 장애
- 테이블 700개, stored procedure 4000개😮 - 굉장히 거대한 모놀리틱 시스템
2015 - 단일 서비스
⇒ 리뷰가 장애가 나더라도 고객이 주문하는 데 아무런 영향이 없어야 하는데, 당시에는 루비 데이터베이스가 죽는 순간, 전체 데이터 마비되는 구조
2016
- 하루 주문수 10만 돌파
- PHP → 자바 언어
- 자바 언어를 선택한 이유
1) 자바가 안정적으로 대용량 트래픽에 대응 가능
2) 개발자 수급 (국내에 자바 언어로 대용량 트래픽 처리 경험있는 개발자 많이 있기 때문)
- 자바 언어를 선택한 이유
- 마이크로서비스 도전 시작
- 결제, 주문중계 독립
- IDC → AWS 클라우드 인프라로 이전 시작
⇒ DB(마리아 DB)까지 분리!
결제가 장애가 나도, 배달의민족은 최악의 경우에 전화 주문을 할 수 있다
주문중계: 사장님들이 PC, 앱, 단말기로도 주문 접수를 받을 수 있다. 중간 Gateway 서비스
⇒ 가볍게 node js로 만들면 좋겠다 판단
⇒ 메인 기술은 자바지만 다른 기술들도 비즈니스 상황에 맞게 만들면 사용할 수 있다고 판단
⇒ 서비스가 성장함에 따라 지금은 자바로 변경한 상태
2017
- 하루 주문수 20만 돌파
- 대 장애의 시대: 트래픽은 계속 느는데, 시스템은 레거시. 스케일할 수 있는 구조가 아니다
- 메뉴, 정산, 가게 목록 시스템 독립
장애가 한번 나면 전국민의 역적이 된다. 생존을 위해 마이크로서비스로 전환해야 한다
가게 목록 + 검색을 루비에서 분리해서 엘라스틱서치로 떼어냄
⇒ 루비 DB로 가는 부하 줄어들게
2018 상반기
- 전사적으로 의사결정: 배달의민족의 1순위 과제는 시스템 안전성
- N 광고 폭파 → 장애대응 TF 창설
- 기존에는 하나의 가게가 하나의 광고만 할 수 있었음
- 가게상세 재개발(주요 장애 포인트)
- 쿠폰, 포인트 탈루비
- 오프라인 모드 적용
2018 하반기
- 주문 탈루비
- 주문은 모든 시스템과 다 엮인다. 결제, 포인트, 쿠폰 등
- 리뷰 탈루비
프로젝트 먼데이
-
기술적으로 마이크로 서비스로 가려면 프로젝트를 3~4달 중단시켜야 한다
-
회사는 비즈니스를 해야 함
-
하나의 가게가 여러 개의 광고를 하려면 이 프로젝트를 해야 한다. 시스템 기반 안정화가 필요하니 이 프로젝트에만 집중할 수 있게 개발팀을 도와주기로 의사결정
- 가게노출 시스템: 서비스 조회용 가게 데이터를 가지고 있는 쿼리 모델
- 광고용 시스템
- 검색용 시스템
먼데이 아키텍처
고려 사항
1. 성능
- 대용량 트래픽 대응
- 메인, 가게 리스트, 가게 상세 API는 초당 15,000회 호출
- 모든 시스템이 대용량 트래픽을 감당하기는 어려움
- 장애 격리
- 가게, 광고 같은 내부 서비스나 DB에 장애가 발생해도
- 고객 서비스를 유지하고 주문도 가능 해야 함
- 데이터 동기화
- 데이터가 분산되어 있음
대안) API 조회 형식
⇒ 장애 문제가 있다. 광고 시스템 장애가 생기면, 광고 시스템 API를 호출하는 모든 시스템에 연쇄적 장애 발생
⇒ 고성능 조회-트래픽 전파. 대량의 트래픽이 순간적으로 몰려오는데, API 호출 방식을 사용하면 이 트래픽이 모든 시스템에 다 퍼진다.
광고, 가게/업주의 경우에는 트래픽을 잘 해결하는 것보다, 정확하고 안정적인 시스템 운영이 훨씬 중요하다
배우고 느낀 점, 인사이트
- 서비스 안정화
- 아키텍처 설계의 중요성
- 기능 추가 하나가 왜 쉬운 일이 아닌지
출처
