#Backend

천만 MAU를 지탱하는 커뮤니티 시스템을 소개해요

Summary

천만 사용자가 쓰는 당근 커뮤니티, 어떻게 단 하나의 서버앱으로 2만 RPS를 견딜까?

모듈형 모놀리스와 Streaming SSR로 완성한 당근 커뮤니티실의 영리한 생존기

당근의 눈부신 성장 이면에는 1,000만 MAU와 20,000 RPS라는 엄청난 트래픽 폭풍을 유연하게 받아내고 있는 숨은 시스템이 있습니다. 당근 커뮤니티실은 무분별하게 마이크로서비스로 찢는 대신, 코드 경계를 극한으로 관리하는 '모듈형 모놀리스'와 프론트엔드의 성능 체감을 혁신하는 'Streaming SSR'을 선택했습니다. 소수의 엔지니어로도 대규모 트래픽 속에서 복잡한 정책을 안정적으로 유지할 수 있었던 비결과 아키텍처 원칙을 가감 없이 공유합니다.

01루비온레일즈 모놀리스에서 시작해 20,000 RPS를 지탱하는 모듈형 모놀리스 구조로의 성공적 전환 과정
02웹뷰 기동의 고질적인 느린 초기 렌더링을 획기적으로 개선한 Streaming SSR 및 CSR 예외 처리(Fallback) 전략
03동일 코드베이스 안에서 실행 목적에 맞춰 api, worker, batch, console로 프로세스를 완벽 격리한 배포 아키텍처
04OpenAPI 스펙 중심의 Design-First 방식을 통해 웹과 서버 간의 통신 계약을 자동화하고 호환성을 확보한 개발 방식
05ArchUnit 등 아키텍처 테스트를 통한 모듈 간 의존성 방향 및 트랜잭션 규칙 자동 검사 기법 도입

RECOMMENDATION

단순히 유행을 쫓아 MSA(마이크로서비스 아키텍처)를 도입하기 전에, 제한된 인적 자원으로 대규모 트래픽과 도메인 확장성을 잡고 싶은 백엔드 및 풀스택 엔지니어들에게 적극 추천합니다.

The Problem

당근 커뮤니티 서비스는 1,000만 MAU 달성과 최대 20,000 RPS에 달하는 트래픽 급증을 겪으며 시스템 복잡성이 임계점에 도달했습니다. 또한 동네생활, 모임, 카페 등 각 서비스별로 상이한 지역성 및 인증 정책을 처리하면서 중복 코드와 결합도를 제어해야 하는 과제가 있었습니다.

The Solution

여러 서비스의 백엔드 기능을 단일 코드베이스로 묶되 도메인 간 경계를 모듈화하여 제어하는 '모듈형 모놀리스(Modular Monolith)' 아키텍처를 채택하고, 웹앱 영역에는 초기 기동 성능 개선을 위해 Streaming SSR을 구현했습니다. 서버앱은 하나의 릴리스 단위로 배포하되 런타임 환경에서 api, worker, batch, console의 4개 프로세스로 실행 격리하였으며, OpenAPI 스펙 기반의 API Design-First 기법 및 자동화된 아키텍처 테스트를 통해 결합도와 호환성을 지속적으로 검증했습니다.

The Result

초기 100 RPS 수준에서 출발하여 대형 이벤트 및 지속적인 서비스 성장에도 무리 없이 최대 20,000 RPS를 안정적으로 처리하는 성과를 거두었습니다. 아울러 중앙화된 계약 관리와 모듈 간 분리를 통해 소수의 인원으로도 다수의 커뮤니티 서비스를 안정적이고 효율적으로 유지보수할 수 있는 개발 및 운영 환경을 구축했습니다.

Trade-off

모든 기능을 단일 릴리스로 통합 배포하기 때문에 아무리 사소한 변경 사항이더라도 4개의 실행 단위를 포함한 서버앱 전체의 빌드 및 통합 검증 프로세스를 감수해야 합니다. 또한 논리적으로는 데이터 경계를 구분하였으나 일부 물리 데이터베이스 공유 상태가 지속되고 있고, 추천 피드 정렬이나 세부 조립 로직이 백엔드에 다소 쏠려 있어 역할 조정이 필요하다는 한계가 있습니다.

Key Concepts

Concept · 01

모듈형 모놀리스 (Modular Monolith)

단일 애플리케이션 및 하나의 배포 단위를 유지하면서도, 코드베이스 내부에서 도메인 및 관심사를 비즈니스 경계별 모듈로 명확하게 나누어 결합도를 낮추는 아키텍처 스타일입니다.

동네생활, 모임, 카페 등 성격이 다른 서비스를 하나의 서버앱 안에 담되, 서비스별 전용 도메인 모듈과 공통 컴포넌트로 수평/수직 분리했습니다.
각 모듈 간 직접적인 데이터 테이블 참조를 금지하고 오직 제공되는 내부 인터페이스와 소유 모듈을 통해서만 접근하도록 강제했습니다.

Concept · 02

스트리밍 서버 사이드 렌더링 (Streaming SSR)

화면을 그릴 때 필요한 전체 데이터 조회가 끝날 때까지 렌더링을 미루지 않고, 기본 구조(뼈대)를 먼저 클라이언트로 흘려보낸(Streaming) 뒤 동적 데이터가 채워지는 대로 점진적으로 전송하는 최적화 기법입니다.

사용자가 당근 커뮤니티 탭이나 개별 서비스를 방문할 때 발생하는 초기 렌더링 지연 현상을 획기적으로 낮췄습니다.
스트리밍 처리가 제한 시간을 초과하거나 장애가 생길 경우, 즉시 CSR(클라이언트 사이드 렌더링) 방식으로 우회하는 안정장치를 부합시켰습니다.

Concept · 03

API 설계 우선 접근방식 (API Design-First)

코드 구현에 앞서 프론트엔드와 백엔드 개발자가 API 명세서(계약)를 먼저 정립하고 검토한 뒤, 이를 토대로 양측의 코드를 자동으로 제너레이션하여 병렬 개발을 진행하는 기법입니다.

OpenAPI 스키마 형식으로 작성된 계약 문서를 중앙 저장소에서 병합 관리하고 코틀린 서버 스텁 및 타입스크립트 클라이언트를 자동 생성했습니다.
CI 파이프라인과 통합하여 스키마가 깨지거나 하위 호환성을 무너뜨리는 변경이 발생하는 것을 사전에 자동 차단했습니다.

Continue reading · same source

More from 당근

View all posts from 당근

천만 MAU를 지탱하는 커뮤니티 시스템을 소개해요

Summary