[컨퍼런스 후기] 우아콘 2023

우리나라에서 우아한 형제들은 몰라도 ‘배달의 민족’ 앱을 모르는 사람은 거의 없습니다.

몇년 전만 해도 대부분 책자로 배달 주문을 시켜먹었는데, 현재는 배달 플랫폼 애플리케이션을 대부분 사용합니다.

요즘 오히려 전화 주문이 불편하고, 휴대전화 앱을 사용해 주문하는게 훨씬 편합니다.

배달 플랫폼에서도 대표격인 배달의 민족에서 여는 컨퍼런스 우아콘을 다녀왔습니다.

 

배달의 민족도 지난 몇 년간 크게 성장했습니다. 현재에 이르러 매일 평균 주문량이 300만 건 가까이 된다고 합니다. 또한, 월드컵이나 아시안게임 등의 이벤트가 발생하면 주문량이 훨씬 증가한다고 합니다.

우아콘은 배달의 민족이 성장하면서 겪은 성장통을 얘기해 주는 자리였습니다.

 

우아콘 오프닝 대기중

 

일 평균 300만 건의 주문이 발생하면서 주로 발생했던 문제들, 문제의 해결법 등을 각 분야별로 발표를 진행하였습니다.

저는 백엔드 개발자로 백엔드 섹션에 참여하게되었습니다.

 

앞으로 회사에 닥칠 수 있는 문제가 될 수도 있는 것이고, 이를 해결하는 사람 중 내가 포함되어 있을 것 이다 라는 마음 가짐으로 들었습니다.

 

우아한 형제들 CEO님은 모든 일의 궁극적인 목적은 ‘고객 창출’과 ‘고객 만족’ 이라는 슬로건으로 배달의 민족을 운영한다고 합니다.

 

인상 깊었던 세션을 간단하게 정리하였습니다.

 

대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화

배달의 민족 주문 시스템

• 장바구니, 주문하기, 주문 내역 등 여러 영역이 존재
• 배민에서는 특히 점심, 저녁 시간에 주문 수가 엄청나게 증가

1. MSA
   배민은 수 많은 시스템 들로 이루어짐(가게, 메뉴, 주문, 결제, 배달 등)
   또한 해당 시스템들은 통신하여 최종적으로 고객에게 음식을 배달 시킨다.
   다른 시스템에 문제가 생겨도 주문이 가능하게 하는 방법
2. 대용량 데이터
   일 평균 300 만 건의 주문을 저장하고, 수년 간의 데이터를 보관하고 관리
   즉, 방대한 데이터를 저장
   방대한 데이터의 정합성을 보장하고, 조회 성능을 향상 시키는 방법
3. 대규모 트랜잭션
   일 평균 300 만 건의 주문 발생 → 이는 대규모 트래픽 → 대규모 트랜잭션을 안정적으로 처리하는 방법
4. 여러 시스템과 연계
   배민은 이벤트 기반으로 통신
   300 만 건의 주문이 발생되면서 이벤트 발행의 일관성을 보장하는 방법과 이벤트 아키텍처를 단순화 하는 방법

 

성장하는 배민 주문 시스템

기존 배민 아키텍처는 많은 주문수를 처리하지 못함

1. 단일 장애 포인트 → 하나의 시스템 장애 = 전체 시스템 장애
2. 대용량 데이터 → RDBMS 조인 연산으로 조회 성능이 매우 안좋아짐
3. 대규모 트랜잭션 → 저장소의 쓰기 처리량이 한계에 도달
4. 복잡한 이벤트 아키텍처 → 규칙 없는 이벤트 발행으로 서비스 복잡도 상승

단일 장애 포인트

한개 라도 고장나면 중앙 DB(루비) 부하 → 전체 시스템 부하 → 전체 시스템 장애 로 이어짐

배민은 시스템을 분리하는 프로젝트를 진행

중앙 DB를 제거하고, 시스템 간 통신은 Message Queue를 사용

만약 해당 시스템이 장애가 생기면? → 단순 이벤트 메시지 발행의 실패로 끝남 → 시스템이 복구되면 이벤트가 재발행

즉, 중앙 집중 DB의 장애에서 전체 시스템 장애로 이어지는 문제를, 단순 메시지 발행 실패로 변경 → MessageQueue를 사용한 이벤트 기반 통신으로 시스템 간 영향도를 분리

 

이것을 MSA라고 한다.

 

대용량 데이터, 조회 성능 저하

쿼리의 종류에는 Command(CUD), Query(R)이 있다.

과거 배민은 저장과 조회 쿼리가 한 DB에서 일어났다.

또한 한번 정보를 가져올 때 많은 정보가 필요에 애그리거트 기반으로 조인 연산이 많이 발생하였고, 이는 성능 저하로 이어진다.

 

조회 성능을 높이기 위해 단일 도큐먼트 방식으로 역 정규화를 진행 → Mongo DB 사용

아이디 기반으로 조회 성능 매우 향상시킴

 

주문 도메인 생명 주기는 주문 도메인 생성 → 주문 접수 → 완료, 취소 로 이뤄지며, 라이프 사이클 내에서만 도메인 변경이 발생

주문 도메인 생명 주기에 발생되는 도메인 이벤트를 통해 데이터를 동기화

—> CQRS 적용 : 저장과 조회를 분리한 아키텍처

 

커맨드 모델과 쿼리 모델을 분리, 즉 쿼리 모델은 NoSQL 사용

 

대규모 트랜잭션

주문 DB의 분당 쓰기 처리량이 한계치에 도달

쓰기 요청은 Primary 주문 DB에, 조회는 Replica DB로 구성

 

쓰기 요청이 많아진다면? 조회 DB로 가는 처리량 감당 불가

 

이를 해결하는 방법은? → 주문 DB 샤딩

하지만, AWS 오로라는 샤딩을 지원하지 않음

 

이를 해결하기 위해 애플리케이션 내부에서 샤딩 구현

 

샤드 클러스터 내 어느 샤드에 접근할지 결정하는 샤딩 전략을 결정하기 위해 먼저, 구현할 수 있는 전략 나열

• 키 베이스 샤딩 : 샤드 키를 통해 데이터 소스 결정
• 레인지 베이스 샤딩 : 값의 범위를 기반으로 데이터를 분산
• 디렉터리 베이스 샤딩 : 샤드가 어떤 데이터를 가질 지 Look up Table 을 유지하는 방식

키 베이스 샤딩 = 해쉬 베이스 샤딩이며, 주문 번호에 대해 hash 함수를 돌려 해시 값이 나오고 이를 MOD 연산하여 샤드 번호에 맞게 매핑하는 방식

구현이 간단하며, 골구루 분배 가능, 하지만 장비를 동적으로 추가하거나 제거할 때 데이터 재배치를 해야함

 

레인지 베이스 샤딩은 가격 기반으로 범위를 나눠 샤딩하는 것인데, 이는 데이터가 균등하게 배분되지 않아 Hotspot이 생길 수 있어 성능 저하가 발생할 수 있음

 

디렉터리 베이스 샤딩은 룩업 테이블을 통해 샤드키에 대해 어디 샤드로 보낼지 정해놓는 것인데, 샤드 결정 로직이 분리되어 동적으로 샤드를 추가하는데 유리하나, 룩업 테이블이 단일 장애 포인트가 될 수도 있다.

 

배민 주문 시스템은 아래와 같은 특징이 존재

주문이 정상 동작하지 않으면, 배민 서비스 전체에 UX 영향을 미친다. → 단일 장애 포인트는 생기면 안된다.

동적 주문 데이터는 최대 30일만 저장한다 → 샤드 추가 이후 30일이 지나면 데이터는 다시 균등하게 분배된다.

이를 통해 키베이스 샤딩으로 결정

 

샤드키 = 주문 번호

주문 순번 % 샤드 수 = 샤드 번호

샤드 키를 이용한 해싱을 통해 주문 순번 순으로 샤드에 고르게 분배

Aob와 AbstractRoutingDataSource를 이용해 구현

 

복잡한 이벤트 아키텍처

여러 시스템이 존재하여 규칙 없는 무분별한 이벤트를 발행하는 문제

 

이벤트 기반으로 관심사를 분리 = 알림 전송, 현금 영수정, 분석 로그 등 서비스 로직 단위로

 

이벤트는 수행하는 주체를 파악하기 어렵고, 유실이 발생할 경우 재처리가 어려움

 

주문 도메인 이벤트는 내부 이벤트, 나머지 서비스 로직은 외부 이벤트로 정의

제로 페이로드 전략 사용

네트워크 비용보다 이벤트 처리 주체의 단일화 비용 감소가 더 크다

 

이벤트 발행 실패 유형

트랜잭션 내부, 외부에서 발행 실패 유무에 따라 처리가 달라짐

내부에서 실패하면 도메인 로직 전체가 실패하므로 일관성을 가져가서 큰 이슈가 없음

외부에서 실패하면 도메인 로직과 서비스 로직의 일관성을 보장할 수 없고, 재발행이 불가

 

이벤트 발생 실패와 서비스 실패를 완전히 격리시켜 재발행 수단을 보장하기 위해 이벤트 로직을 단일 애플리케이션에 위임 → 관리 포인트를 집중

유실 발생 시 배치 애플리케이션을 통해 이벤트 재발행

 

• 요약
  • MSA 적용
    • MQ를 이용한 이벤트 기반 통신으로 시스템 간 영향도를 분리
  • CQRS 적용
    • 커맨드 모델과 조회 모델을 분리하고 조회 모델 역 정규화를 통해 조회 성능을 높임
  • 주문 DB 샤딩
    • 샤딩을 이용해 쓰기 요청을 분산시켜 처리량을 늘림
  • 이벤트 구조 개선
    • 이벤트 로직을 단일 애플리케이션에 위임하여 관리 포인트를 한 곳으로 집중

 

모놀리식에서 점진적 서비스 분리 : 사업 과제와 병행하여 시스템 개선하기

배민 상회 : 택배 커머스 중심의 서비스

 

기존 배민 상회는 거대한 모놀리식 서비스 → 500K 라인

이에 따라 발생하는 단점은

1. 복잡도가 너무 커서 시스템을 다루기 어렵다.
2. 특정 도메인의 변화가 다른 도메인에 영향을 미친다.
3. 애플리케이션 부팅 시간이 오래걸린다 → 빌드 시간이 오래 걸린다 → 간단한 테스트 코드도 오래 걸린다 → 개발자의 생산성 하락

즉, 위의 단점으로 개발자의 생산성이 감소하고, 비즈니스에도 영향이 생김

 

사업 과제는 항상 1순위이고, 이를 병행하며 시스템 개선하도록 결정

 

빌드/개발 단위 작게 만들기

큰 단위 : 도메인간 결합이 크다.

작은 단위 : 도메인간 결합이 작다.

큰 단위의 빌드 : 빌드 시간이 길다.

작은 단위 빌드 : 빌드 시간이 짧다.

 

모놀로식 아키텍처 → 작은 단위의 컴포넌트로 분리

각 컴포넌트는 각 서버가 될 수 있고, 모듈이 될 수도 있다.

 

컴포넌트를 분리

어떤 기준으로 분리할 것인가?

→ 도메인 별로 팀을 나눠서 일을 하였는데, 이를 통해 도메인 별로 컴포넌트를 분리하기로 결정

 

콘웨이 법칙

소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게된다.

 

컴포넌트 분리는 갑자기 진행이 불가하다. 다른 팀도 리소스가 한정되어 있고 사업 과제가 있다.

점진적 분리로 결정

기존 컴포넌트에서 한번에 서비스로 분리 하면 → 많은 코드에 영향을 미침 → 사업 과제 병행 불가 → 모듈로 선 분리

 

도메인 모듈 : 여러 도메인 로직이 존재하는 모듈

모듈을 분리할 때 양방향 의존성을 제거해야 한다.

의존성을 한 방향으로 흐르게 만들어야 한다.

 

이를 해결하는 방법은 DIP

상위 수준 모듈과 하위 수준의 모듈은 둘 다 추상화에 의존해야 한다. 추상화는 세부 사항에 의존하면 안되며, 세부사항은 추상화에 따라 달라진다.

 

서로 결합된 부분을 추상화 시키자 → 인터페이스로 분리

 

인터페이스를 어느 모듈에 둘지에 따라 의존성이 다르게 흐를 수 있다.

 

인터페이스의 위치가 분리되는 모듈과 함께 위치한다면? 비즈니스 과제와 함께 존재하게 됨

인터페이스의 위치가 도메인 모듈에 위치한다면? 분리되는 모듈이 도메인 모듈을 의존하게 되고, 멤버 모듈이 도메인 모듈에 접근하기 위해선 인터페이스를 통해야만 함 → 멤버 모듈이 도메인 모듈을 의존하게 되며, 빌드 독립성을 지키지 못함

 

이를 해결하기 위해 인터페이스를 위한 모듈을 새로 만듦

인터페이스 모듈까지만 같이 빌드하면 된다.

빌드의 독립성을 지킨다.

 

즉, 가시성의 벽을 세운다. → 회원 코드는 인터페이스를 통해서만 접근할 수 있다.

 

또한 기존 도메인 모듈에서 의존하던 서비스들의 이름 그대로 인터페이스를 생성하고, 기존 서비스는 Impl 등 이름을 변경 → 기존 도메인 모듈은 패키지 명을 변경하지 않아도 된다. → 기존 코드의 변화가 없다. → 다른 도메인 작업과의 충돌이 없다.

 

상황에 따라서 모놀리식 → 독립적인 서비스로 나눌 수 있다.

서비스 분리는 트레이드 오프를 고려

비용, 개발 및 유지 보수, 복잡성, 네트워크 통신, 가용성 낮아짐 vs 서비스 트래픽

 

• 요약
  • 결합이 크고, 복잡한 소프트웨어 일수록 공개 인터페이스 및 사이클이 많다.
  • 응집도가 낮고 결합도가 높다.
  • 점진적으로 분리하면 사업 과제와 병행하며 분리할 수 있다. → 다른 도메인을 영향을 주지 않으면서
  • 분리를 한다면?
    • 도메인 내 응집도 향상
    • 결합도 낮아짐
    • 유지 보수성이 올라감
    • 코드 복잡성이 낮아짐

 

후기

이번에 운좋게도 우아콘 현장 참여에 선발되어 다녀왔습니다.

평일에 진행하는 컨퍼런스 참여를 도와주고, 적극적인 성장을 지원해주는 대표님과 구성원 모두에게 감사 합니다.

 

처음 참석하는 컨퍼런스 인데, 우리도 언젠간 저런 문제가 생길 것이다는 마인드로 들으니 더 적극적으로 듣게 된 것 같습니다.

과거 문제들을 보면 현재 운영하는 애플리케이션과 조금 닮은 부분도 있어, 문제 부분을 발표할 때 조금 공감은 되었습니다.

아직 우리는 배달의 민족처럼 대용량 트래픽이 발생하지는 않습니다. 물론 배달의 민족 초창기 때도 현재의 우리처럼 대용량 트래픽이 발생하지 않았습니다.

하지만 언제나 대용량 트래픽이 발생하지 않는다고 가정하고 개발을 진행한다면, 나중에 주문 건이 늘어 우리가 감당할 수 없는 큰 장애가 발생한다면, 이는 결국 고객의 이탈의 원인이 된다고 생각합니다.

 

결론적으로 우아콘에서 발표한 모든 기술을 우리한테 적용할 수는 없지만 적어도 조금씩은 대비했으면 좋겠습니다.

미래에 배달의 민족 처럼 저런 문제를 겪으며, 해결하는 과정을 발표하는 자리까지 크게 성장하면 좋겠습니다.