대용량 트래픽을 받는 모놀리식 서비스에 Woowa하게 RPC 적용하기 #우아콘2023 #우아한형제들

우아한테크·우아콘 2023 2023·2023년

AI 요약

대용량 트래픽을 받던 배민 "가게 노출" 모놀리식 서비스가 20만 줄까지 비대해지자, 거대한 서버를 작은 서비스로 분리하면서 공통 코드를 RPC로 제공한 경험을 다룬다. 핵심은 IDL 파일 없이 기존 자바 클래스 그대로 통신하고 gRPC·Thrift 구현체를 자유롭게 바꿀 수 있는 사내 RPC 라이브러리 "우트(WooT)"다.

핵심 포인트

라이브러리·REST API·RPC 세 가지 분리 방식을 비교해, 레이턴시·버전 관리·클라이언트 코드 중복 문제를 보완하는 RPC를 택했다
우트는 자바 인터페이스를 IDL처럼 쓰고 스프링과 동일한 코드 스타일을 제공해, 하나의 빈이 HTTP와 RPC 양쪽에서 동작하며 주키퍼로 서비스 메시를 구성한다
라이브러리(standalone)와 RPC(remote)를 호환하는 단계적 전략으로 빈을 하나씩 넘기며 검증하고 문제 시 되돌릴 수 있게 했다

왜 읽나대용량 트래픽 모놀리식의 점진적 서비스 분리와 사내 RPC 도입을 고민하는 백엔드 개발자에게 실제 채택 근거와 마이그레이션 전략을 보여 준다.

챕터별 상세

010:00 – 4:44

가게 노출 서비스와 모놀리식 비대화

배민 푸드서비스 개발팀의 장재주가 "대용량 트래픽을 받는 모놀리식 서비스에 우아하게 RPC 적용하기"를 발표한다. 발표는 서비스 분리가 필요했던 배경, 검토 내용, RPC 적용 요구사항, 최종 산출물 순으로 진행되며 후반부는 박경태가 이어 맡는다.

그가 담당하는 "가게 노출"은 사용자가 앱을 켜는 순간부터 가게 탐색·상세·메뉴 노출, 외부 시스템 데이터 제공까지 전 과정에 개입하는 프론트 서버다. 2020년 우아콘에서 약 15,000 TPS로 소개됐던 이 시스템은 서비스가 성장하며 월드컵 같은 이벤트에 입사 이래 최대 약 3만 TPS를 넘겼다. 코드 규모도 2019년 약 5만 줄에서 배민1 오픈을 거쳐 2021년 6월 20만 줄을 넘어섰다.

코드가 늘면 파악이 어려워져 기존 개발자의 과제 진행은 물론 신규 합류자의 소프트 랜딩까지 힘들어진다. 당시 다섯 명의 파트원이 한 명당 3~4개 과제를 병렬 진행하며 그 어려움이 협업하는 기획·UX 팀에까지 전파됐고, 이를 타파하고자 거대한 시스템을 작은 단위로 분리하기로 결정한다.

분리의 핵심 고민은 "공통 코드를 어떻게 할 것인가"였다. 첫 검토안은 공통 코드를 라이브러리로 제공하는 것으로, 빠른 전환이 장점이었으나 결국 각 서비스 개발자가 20만 줄을 다 봐야 하고 러닝 타임이 길어지며 자원 관리 주체가 불명확했다. 두 번째는 저장소 앞단 서버를 두고 각 서비스가 REST API로 통신하는 안으로, 러닝 타임·자원 문제는 해소됐으나 통신 레이어 증가에 따른 레이턴시, 클라이언트 코드 중복, 버전 관리 불명확이 단점이었다. 그래서 두 번째 구조를 유지하되 통신을 RPC로 제공하는 세 번째 안을 택한다.

RPC는 Remote Procedure Call의 약자로, 다른 주소 공간의 함수·프로시저를 별도 원격 코딩 없이 호출하는 기술이다. 클라이언트와 서버가 갖는 약속을 IDL(Interface Definition Language)이라 부르며, 보통 IDL 파일을 각 언어로 컴파일해 구현한다. 발표자는 Apache Thrift IDL과 자바 스프링 예시를 들고, 구현체로 구글 gRPC, 페이스북 Thrift 등을 소개한다.

기존 가게 데이터를 IDL 파일로 만들려 하니 벌써 800개가 넘어, 유지보수 관점에서 어려움에 봉착할 것이라 봤다. 그래서 IDL 파일 대신 기존에 쓰던 자바 클래스와 인터페이스를 기반으로 제공해 유지보수를 편하게 하기로 한다.

두 번째 요구사항은 구현체 선택의 자유다. 운영 노하우가 있던 Thrift로 가려 했으나 여러 팀이 gRPC를 요구해, 구현체에 상관없이 RPC를 쓸 수 있게 했다. 세 번째는 허들 낮추기로, 개발자들이 스프링에 친숙했으므로 기존 스프링과 비슷한 형태로 제공하기로 했다. 정리하면 ① 자바 클래스 활용으로 유지보수 용이, ② RPC 구현체 선택 가능, ③ 스프링 사용성과 큰 차이 없음 세 가지를 요구사항으로 "우아한 RPC 모듈"을 만들었다.

배민 커머스서비스실의 박경태가 바통을 받아, 세 요구사항을 만족하는 RPC 라이브러리 "우트(WooT)"를 소개한다. 우트는 IDL 없이 자바 클래스 그대로 통신해 유지보수가 편하고, 코드 변경 없이 gRPC와 Thrift를 바꿔 기동할 수 있으며, 스프링과 같은 코드 스타일을 제공한다. 일반 스프링 부트가 `@RestController`를 HTTP에 매핑하듯, 동일한 코드에 우트 컨트롤러 어노테이션과 인터페이스만 입히면 하나의 빈이 싱글톤으로 HTTP와 RPC 두 영역에서 동작한다. IDL은 별도 파일 없이 자바 인터페이스가 그 역할을 하며, 다른 언어 접속 시 Thrift·gRPC IDL로 컨버팅된다.

호출은 URpcFactory에 접속 정보와 인터페이스를 넣어 인스턴스를 만들고 메서드를 호출하면 리모트 서버의 메서드가 실행된다. 서버 에러는 예외를 직렬화해 클라이언트로 가져와 다시 throw하므로 로컬과 똑같이 디버깅할 수 있다. 동일 기능 서버를 묶는 서비스 메시로는 DNS·VIP·IP 방식의 로드 밸런싱 쏠림 문제를 피해 주키퍼(ZooKeeper)를 택했다. RPC 서버가 등록·해지될 때 IP·프로토콜을 주키퍼에 등록하고, 클라이언트는 이를 조회하며 변경을 통지받아 목록을 재구성한다.

가게 노출 적용 전략은 세 단계다. 빈으로 추출할 코드를 서브 모듈·외부 라이브러리로 분리하되 인클루드해 동일 동작을 보장하고, 이를 RPC 서버로 추가 등록하며, 앞단 서버가 라이브러리(standalone)와 RPC(remote) 두 방식을 호환하게 해 빈을 하나씩 넘겨가며 검증하고 문제 시 되돌릴 수 있게 했다. 모든 메서드가 검증되면 RPC만으로 통신하고 인클루드 라이브러리는 제거한다. 우트는 사내 편의 사항이 많아 당장 오픈소스화는 어렵지만 분리하면 가능할 것이라 밝히며, gRPC·Thrift·HTTP에서 동일한 빈이 같은 결과를 내는 시연으로 발표를 마친다.