미리보기

• 푸드주문시스템 개발팀장 (22.07~23.07, 24.09~현재)

• 이벤트 기반 아키텍처, RDS 샤딩, CQRS, 조회모델 등 비즈니스 성장과 함께 시스템 개선

• 여러 서비스에서 사용할 수 있는 주문서플랫폼 개발

• 일 300만건 주문시스템 운영 및 다양한 비즈니스 요구사항 개발

• 안드로이드 개발

• 주문접수앱,

  배달의민족 앱 개편, 개발

문제정의

• 배경

  • 배달의민족 앱 내 서비스가 다양해지면서 주문서-결제 처리과정이 각 팀에서 개발되어 고객경험 불일치 및 개발 효율성이 저하됨

• 목표

  • 주문서~결제 처리 과정을 공통으로 제공할 수 있는 주문서플랫폼을 개발하여 일관된 고객경험을 제공하고 개발/운영 리소스 효율성을 확보한다

문제해결

• 플랫폼과 서비스 간 의존성을 줄이기 위해 플랫폼 관심사/비관심사 분리 및 정형/비정형 데이터로 모델링

• 메시지 처리량 확보를 위해 기존 메시지 브로커 SNS에서 Kafka로 전환

• 병렬 프로젝트 요구사항 수용을 위해 브랜치 전략을 TBD(Trunk-Based Development)로 변경

성과

• 푸드, 비마트, 배민스토어 3개 서비스를 연동하여 통합된 주문서-결제 경험 제공

• 신규 서비스 추가에 유연하게 대응할 수 있는 플랫폼화 기반 마련

역할 및 책임

• 주문서 플랫폼 서버 개발 리드

• 플랫폼화 목표에 맞춘 도메인 설계 및 핵심 도메인 로직 개발

배경

• RDS에서 간헐적으로 발생하는 Commit Latency 스파이크 현상에 대해 DBA로부터 커맨드 처리가 한계에 도달했다는 피드백을 받음.

• 당시 RDS는 최고 사양(db.r5.16xlarge)으로 구성되어 있어 더 이상의 스케일업이 불가능했으며, 서비스 성장을 위해 수평 확장이 필요하다고 판단함.

목표

• RDS의 커맨드 부하를 분산하기 위한 샤딩 구현

• 시스템 확장성과 안정성을 보장하는 샤딩 전략 수립

문제 해결

1. 샤딩 전략 수립

   • 서비스 안정성을 유지하기 위해 단일 실패 지점을 제거하는 Hash Function Sharding을 선택 (vs Directory Based Sharding)

   • 주문번호의 특성(날짜와 시퀀스 추출 가능)을 활용하여 주문번호를 샤드 키로 선정하고, 리밸런싱 없이도 샤드 확장이 가능하도록 설계

2. 샤딩 적용 방식

   • 어노테이션과 AOP 기반으로 필요한 JPA Entity에 쉽게 샤딩을 적용할 수 있도록 개발하여 유지보수를 용이하게 함

3. 다양한 조회 요청에 대한 대응 방안

   • 이벤트 기반으로 MongoDB에 주문 데이터를 Sync하여 조회용 DB로 사용

   • 주문 조회에서 최신 데이터 일관성이 보장되어야 하는 경우에는 RDB를 조회하도록 전략 수립

   • 다양한 DB 조회 전환을 쉽게 하기 위해 조회용 모델과 DB 모델을 분리하고 인터페이스로 추상화함

성과

• RDS 샤딩을 통해 Commit Latency 스파이크 제거 및 시스템 확장성 확보

• 인프라와 데이터 모델 수준에서 CQRS 패턴 적용을 통해 주문의 핵심 비즈니스와 기타 기능 간의 영향도를 분리하여 시스템 안정성 증대

• MongoDB 전환을 통한 조회 성능 개선 (특정 API의 조회 속도 200ms → 80ms로 개선)

역할 및 책임

• 전체 구현 전략 수립 및 개발 주도

• 개발 리드로서 프로젝트 전반을 관리하고 성과 달성