미리보기

# Transmission Squard | RPS Part & ThirdParty Logistics Part

- RPS Part : 요기요 주문 고객과 가게간 주문 접수 이후 Flow 담당
- ThirdParty Logistics Part : 요기요와 ThirdParty Logistics Flow 담당
- 시스템 안정화 / 개선

개발 스택

• Java, Spring Framework, RDS, MyBatis, JSP, SVN

주요 업무

• 시험 접수 유지보수

  • 시험 접수란 : 컴퓨터 활용 능력, 워드 프로세서

목표

• 라이더들이 기피하는 지역/주문을 커버할 수 있는 공급 유형을 제공하여 배달 서비스의 안정성을 높임.

• 로봇 배달을 통해 기존 배달 방식의 한계를 극복하고, 고객에게 새로운 배달 경험을 제공.

주요 역할 및 실행

• Backend 개발 / 서버 개발 2명 주문전달 영역 담당자로 참여.

• 주문 전달 영역 개발 (주문 전달, 주문 상태 관리, 앱 푸시, 영수증 처리)

• 요기요 앱과 로봇 배달 대행사 간의 통합 플로우 설계 및 구현

  • 요기요 앱에서 로봇 배달 대행사까지의 전반적인 데이터 플로우를 구성

  • 로봇 배달 대행사, 요기요 앱, 주문 전달 수단 마이크로서비스(MS) 간의 스펙 설계 및 통합

  • 로봇 배달 대행사와의 API 스펙 설계 및 연동을 통해 안정적인 통신 체계 구축

• 주문 전달 수단과 배달 대행사 통신 MS 사이의 API 및 이벤트 스키마 설계

결과

• 라이더들이 기피하던 지역의 주문도 안정적으로 처리하여, 고객 만족도 향상과 함께 새로운 수익 모델 창출

문제 및 해결 방안

• 로봇 수요를 컨트롤할 수 있는 선점 프로세스 필요성

  • 배차 이후에 주문을 전달하는 방식으로 변경하여, 불필요한 선점 문제를 제거하고 주문 흐름을 최적화

• 로봇 배달에서 정확한 시간 관리의 중요성: 사장님과 고객이 직접 로봇과 상호작용하므로, 예상 배달 시간과 픽업 시간의 정확도가 중요

  • 실시간으로 가게 도착 및 고객 도착 이벤트를 추가하여 예상 시간을 정확히 업데이트하고, 도착지 변경 시에도 즉시 반영하여 신뢰성을 높임.

• 외부사와의 협업 시 기술적/비기술적 정보 전달이 어려움.

  • Gitbook을 활용하여 개발자와 비개발자 모두 수정 가능한 문서화 체계를 구축.

요기 배달 서비스 뿐만 아니라 가게 배달까지 연동 가능한 배달대행사 확장

목표

• 가게배달 또한 표준 API로 전환하여, 기존 시스템의 단점을 개선하고 신규 배달대행사 추가에 소요되는 시간을 줄임.

주요 역할 및 실행

• Backend 개발 / 서버 개발 3명 팀의 일원으로 참여.

• 비동기 이벤트의 동시성 이슈 해소

• 무중단 배포 및 롤백 프로세스 전략 구성

• 가게 배달(가게 기반) 표준 API 스펙 설계, 데이터베이스 모델 및 이벤트 메시지 스키마 설계

• 일몰 대상 마이크로서비스(MS)의 기능 분석 및 필요 개발 사항 파악

• 외부 배달대행사와의 협업 및 커뮤니케이션 진행

결과

• 도메인 및 역할이 충돌되는 MS 일몰로 리소스 비용 감소

• 기능 개발에 소요되는 공수를 기능 수 x 3PL사 수 가 아닌, 단일 기능 개발로 감소하여, 신규 배달대행사 추가 시간 단축

문제 및 해결 방안

• 비동기 상태 변경 이벤트 수신 시 발생하는 이벤트 순서 문제(동시성 이슈) 해결 필요

  • 1차 리트라이: 낙관적 락과 Spring Retry로 순서 일관성 확보.

  • 2차 리트라이: SQS Visibility Timeout 설정으로 실패 시 다른 Pod에서 재시도.

  • 최종 리트라이 실패: SQS DLQ로 메시지 이동 및 알럿 발생으로 모니터링 및 추가 조치.

• 배달 대행사별로 상이한 배포일정으로 특정 배달대행사에 맞춰 신규 마이크로서비스로 전환 필요

  • 빠른 롤백과 기능 전환을 위해 피쳐 토글을 도입하여 실시간 전환이 가능하도록 구성.

  • 피쳐 토글 조회 성능을 위해, Redis를 저장소로 사용하여 빠른 조회 및 업데이트를 보장.

• 신규 마이크로서비스로 전환 시, 진행 중이던 배달에 영향을 주지 않도록 무중단 배포가 필요

  • 배달 생성 및 주요 이벤트에, 타겟 서비스를 식별할 수 있는 메타데이터를 추가 : 모든 이벤트가 정확한 마이크로서비스로 라우팅되도록 구성.

  • 일몰 대상 서비스와 신규 서비스간 양방향 데이터 싱크를 통해, 롤백 시에도 데이터 무결성을 유지.

요기 배달 서비스 가능 지역 확장으로 배달 수행률 향상

목표

• 요기 배달 서비스 가능 지역 확장으로 배달 수행율 향상 및 연동 표준 제공으로 신규 기능과 3PL 연동 과정의 효율성 증대

주요 역할 및 실행

• Backend 개발 / 핵심 기여자로서 전체 커밋 중 58% 담당

• Spring StateMachine을 활용한 배달 상태 관리

• Snowflake 기반의 배달 아이디 채번 로직 개발

• Kubernetes 환경에서의 트래픽 증가 대응

• 신규 프로젝트 셋업

  • Java, Spring Framework, Code Formatting(Spotless), Test Coverage(Jacoco), CI/CD

  • DB, Server Layout 설계/구성 (RDB, No SQL(Redis, MongoDB), SNS/SQS)

  • 데이터독 모니터링 알럿 및 대시보드 작성

• 요기 배달 (좌표 기반) 표준 API 스펙 설계, 가이드 코드 작성

결과

• 요기 배달 주문건 2배 증가

• 요기 배달 가능 지역 확장으로 기존에 게약이 불가능했던 케이스 커버, 여러 배달 대행사에 연동 표준 제공

• 위대한상상(요기요) R&D 본부 우수상 수상

문제 및 해결 방안

• 다양한 배달 상태 전이를 유연하고 효과적으로 관리할 수 있는 시스템 개발 필요

  • Spring StateMachine 사용 : 복잡한 상태 전이를 명확히 정의하고, 이벤트 기반으로 상태를 변경. 상태 관리의 가시성과 새로운 상태나 전이를 쉽게 추가하도록 확장성 확보

  • 낙관적 락 사용 : Spring JPA의 @Version을 활용하여 데이터베이스 동시 접근으로 인한 충돌을 방지하고 경쟁 조건을 최소화

  • 리트라이로 동시성 이슈 해결 : 낙관적 락 예외 발생 시 리트라이 매커니즘을 통해 일시적인 충돌 문제를 해결하고, 배달 상태 업데이트의 성공 확률을 높힘

• 쿠버네티스 분산 시스템에서 효율적으로 Unique ID를 생성하는 로직 개발 필요

  • Snowflake 기반의 배달 아이디 채번 로직 개발 : 타임스탬프 + Machine ID + Sequence ID

    • Machine ID 채번 시 App과 DB 동작시간 최소화: Application 기동 시, 채번 후 Redis 캐시에 저장

    • Machine ID 채번 시 Redis 장애에 영향을 받지 않도록 기본 값인 0을 반환

    • Sequence ID 채번 시 멀티 스레드 안전성을 위해 Atomic Integer 사용

  • 결과 : 일주일 기준 : 1.4M 유니크 아이디 생성

• Kubernetes 환경에서의 트래픽 증가 대응 필요

  • HPA(Horizontal Pod Autoscaler)를 활용하여 Replica 수를 자동으로 조정, 트래픽 증가 시에도 안정적으로 서비스를 제공

  • 데이터베이스 커넥션 풀 대응 필요

    • 앱의 최대 연결 수(Max Connection) = C, Kubernetes의 최대 Replica 수 = R, 배포 시 2배로 증가하는 상황을 고려하여, 최소 DB 커넥션 수 = C * R * 2로 설정.

    • 이러한 설정을 통해 트래픽 급증 시에도 데이터베이스 연결 병목을 방지

• 외부 협업사 연동사의 서비스 품질 이슈

  • 주기적인 미팅과 모니터링 지표 설정을 통해 SLA를 모니터링하고, 지속적으로 싱크업하여 협업사 서비스의 응답 지연 및 가용성 문제를 관리.

  • Swagger 파일을 Redoc으로 배포하여 API 문서의 가독성을 개선하고, 정적 HTML로 제공하여 문서 접근성을 향상

주문접수수단 신규 알림 및 기능 개선을 통해 사장님 부정 사용 경험 감소 및 서비스 관리 비용 감소

주문접수수단이란?

• 주문접수PC : PC, POS

• 사장님앱 : 휴대폰

목표

• 사장님 편의성 개선 및 주문 취소율 감소를 통해 사용자 경험 향상.

• 독일에서 이관 받은 시스템의 내재화를 통해 서비스 관리 비용 절감.

주요 역할 및 실행

• Backend 개발 / 서버 개발 4명 팀의 일원으로 참여.

• 독일로부터 이관 받은 서비스의 전반적인 분석 및 개발 요구사항 정의.

• 주문 전달 영역 개발

• 사장님 앱 푸시 알림의 주문 유형에 따른 메시지 포맷 설계 및 구현.

• 도메인 및 목적이 비슷한 기능을 가진 마이크로서비스(MS)를 통합하여 관리 포인트 최소화.

결과

• 독일에서 이관 받은 주문 접수 수단 시스템의 내재화.

• 중복되는 도메인의 MS를 하나로 통합하여, 주문 상태 관리를 한 곳에서 관리함으로써 서비스 관리 포인트 감소

• R&D 본부 최우수상 수상

문제 및 해결 방안

• 독일에서 이관 받은 한국 서비스를 내재화하면서 서비스 이해 및 관리 포인트 축소에 어려움 발생

  • 각 MS별 System Diagram, API, Data Model, Message 등을 분석하고 위키화하여 체계적인 이해도를 높임.

• 독일에 주문을 전달하기 위해 존재하였던 도메인이 겹치는 중복 MS 문제

  • 중복된 MS의 기능을 독일에서 이관 받은 주요 MS로 통합하여 관리 포인트 감소.

  • 각 MS에서 개별적으로 관리되던 주문 상태를 하나의 MS에서 통합 관리하도록 조정하여, 주문 상태 불일치 케이스 감소.

• 베트남 외주 협업사와의 커뮤니케이션 문제

  • 주기적인 싱크업 회의 도입과 위키를 활용한 정보 공유로, 시차 문제를 해결하고 협업의 일관성을 유지.

주요 업무

• 교육앱의 백엔드 개발을 맡아 교육 정보 및 결제 기능 개발 및 유지보수

• 인앱 및 PG사 결제 시스템 연동 경험, 고객센터 관리자 페이지 갭라 경험