회원시스템 이벤트기반 아키텍처 구축하기 #우아콘2022 #Day2_음식그이상의것을문앞으로

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

AI 요약

배달의민족 회원 시스템이 하나의 마이크로서비스 안에서 이벤트 기반 아키텍처를 어떻게 설계했는지를 "느슨한 결합"이라는 키워드로 풀어낸 우아콘2022 세션이다. 메시징 시스템을 쓴다고 자동으로 느슨해지지 않는다는 통찰이 핵심이다.

핵심 포인트

메시지가 대상에게 기대하는 목적을 담으면 비동기 요청일 뿐 — 발행할 것은 "너는 탈퇴해라"가 아니라 "본인인증이 해제됐다"는 도메인 이벤트 그 자체다
애플리케이션 이벤트·내부 이벤트·외부 이벤트와 세 구독자 계층으로 비관심사를 분리하고, 외부 이벤트는 "내부엔 열리고 외부엔 닫힌" 형태로 일반화·제로 페이로드 처리한다
다종 DB 분산 트랜잭션이 사실상 불가능하므로 DB를 공유하는 아웃박스 패턴으로 도메인 행위와 이벤트 발행의 정합성을 보장하고, 이벤트 저장소를 로그 추적과 통합한다

왜 읽나MSA에서 이벤트 기반 아키텍처를 "제대로" 설계하려는 백엔드 개발자에게 결합도·트랜잭션·유실 처리의 실전 설계 결정을 보여준다.

챕터별 상세

010:00 – 4:49

느슨한 결합 — 무엇을 이벤트로 발행할 것인가

회원플랫폼팀 권용근이 "회원시스템 이벤트 기반 아키텍처 구축하기"를 발표한다. 먼저 시스템 변천사를 회고한다. 2015년 모놀리식 단일 시스템으로 시작했으나 주문이 J커브로 성장하며 '장애의 시대'를 맞아 MSA로 전환, 2019년 모든 시스템이 분리됐고 자연스럽게 이벤트 기반 아키텍처를 쓰게 됐다. 다만 하나의 마이크로서비스 안에서 다루는 이벤트 기반 아키텍처 는 여전히 생소하다며, 회원 시스템이 그것을 어떻게 다루는지 소개한다. 핵심 키워드는 느슨한 결합 이다. '회원의 본인인증이 초기화되면 가족계정에서 탈퇴되어야 한다'는 정책을 예로, 가족계정 탈퇴 로직이 회원 본인인증 해제에 깊게 관여하면 강한 결합이 생긴다. 가족계정을 마이크로서비스로 분리해 동기 HTTP로 바꿔도, 비동기 HTTP로 바꿔도, 심지어 메시징 시스템으로 '가족계정 탈퇴 메시지'를 보내도 여전히 강한 결합 이다. 메시지가 대상에게 기대하는 목적을 담으면 그건 비동기 요청일 뿐 이벤트가 아니기 때문이다. 따라서 발행할 것은 '내가 밥을 먹었으니 너는 무엇을 해라'가 아니라 '밥을 먹었다'는 도메인 이벤트 그 자체 다. 회원은 '본인인증 해제 이벤트'만 발행하고 가족계정이 이를 구독해 스스로 탈퇴를 구현하면 결합이 느슨해진다.

회원 시스템은 세 가지 이벤트 종류와 세 구독자 계층을 정의했다. 첫째는 애플리케이션 이벤트 와 이를 구독하는 첫 번째 구독자 계층이다. 메시징 전, 단일 애플리케이션 안에서는 스프링의 애플리케이션 이벤트를 쓴다(트랜잭션 제외 가능). 단일 앱 안에서도 도메인의 주관심사와 거리가 먼 '메시징 시스템으로 이벤트 발행' 같은 비관심사를 이벤트로 분리하면, 발행 시스템에 영향 없이 확장·변경할 수 있다. 회원 시스템은 AWS SNS 를 쓰며, 첫 구독자 계층에 애플리케이션 이벤트를 메시징으로 전달하는 구독자를 뒀다. 이 구독자가 발행하는 것이 둘째 내부 이벤트 로, SNS를 SQS 와 함께 쓰면 1대다 구독과 메시지 유실에 대한 강한 신뢰를 얻는다. 내부 이벤트를 구독하는 시스템 내 이벤트 처리기가 두 번째 구독자 계층으로, 도메인 내 모든 비관심사를 처리한다. 예로 로그인은 주행위('로그인 상태로 변경') 외에 디바이스 기록·동일 계정 로그인 수 제한·다른 계정 로그아웃 같은 부가 정책이 도메인 로직과 섞여 주행위를 알기 어려운데, 이를 내부 이벤트로 분리 해 각각 강한 응집·높은 재사용성을 확보한다. 애플리케이션 이벤트와 내부 이벤트의 선택은 트레이드오프로, 주요 행위와 트랜잭션·성능을 공유해야 하면 전자를, 분리하려면 후자를 쓴다.

회원 시스템은 대부분 비관심사를 분리해 내부 이벤트를 택했다. 다만 MSA의 외부 시스템과 관심사를 분리하려면 외부 이벤트 발행이 필요하다. 외부 전파 또한 도메인 내 비관심사라, 두 번째 구독자 계층의 SNS 발행 구독자가 담당하며, 이것이 발행하는 셋째 외부 이벤트 를 타 시스템들(세 번째 구독자 계층)이 구독한다. 내부·외부 이벤트를 분리하는 이유는 '내부에는 열린, 외부에는 닫힌' 이벤트를 제공하기 위해서다. 내부 이벤트는 페이로드에서 나이 필드를 제거해도 발행자·구독자가 한 시스템 안이라 함께 수정·배포할 수 있지만, 외부 이벤트는 구독자가 시스템 밖에 있어 페이로드를 바꾸면 타 시스템에 오류가 나는데 그들을 관리할 수 없다. 이 닫힌 외부 이벤트를 안전·유연하게 제공하려 이벤트 일반화 가 필요했다. '언제, 누가, 무엇을 하여, 어떤 변화가 일어났는가'(식별자·행위·속성·시간)가 있으면 어떤 시스템도 이벤트를 인지할 수 있다. 다만 특정 구독자를 위한 데이터를 추가하면 결합이 강해지므로 제로 페이로드(zero-payload) 를 택했다. 제로 페이로드는 이벤트 순서 보장 문제 해소로 주로 소개되지만, 페이로드의 외부 의존을 제거해 느슨한 결합을 만드는 장점도 있다.

이벤트 계층을 분리하고 메시징으로 안정적으로 처리해도 문제점이 남아 이벤트 저장소 가 필요했다. SNS·SQS 구간은 높은 신뢰성·데드레터 큐를 제공하지만, 문제는 내부 이벤트를 '발행'하는 구간 이다. HTTP 통신이라 발행 과정에 문제가 생길 수 있는데, 스프링 애플리케이션 이벤트로 도메인 행위와 구독자를 트랜잭션으로 묶으면 메시징 장애가 시스템 전체 장애로 번질 위험이 있고, 트랜잭션을 안 묶으면 발행 실패 시 '도메인 행위는 됐는데 이벤트는 안 된' 불일치가 생긴다. 이벤트 저장소 선택의 핵심은 고속 처리보다 도메인 행위와 이벤트 간 트랜잭션 이다. 다종 데이터베이스 분산 트랜잭션은 사실상 불가능에 가까워(스프링 일부 분산 트랜잭션 매니저가 deprecated 됐을 정도), 신뢰성이 중요한 회원 시스템은 데이터베이스를 공유 하는 쪽을 택했다. 동일 저장소에 데이터를 저장하고 이벤트를 발행해 정합성을 보장하는 이 방식이 아웃박스 패턴(Outbox Pattern) 이다. 이벤트를 '발행 여부' false로 저장하고, 정상 발행되면 true로 바꾸며, 미발행 이벤트는 별도 배치가 주기적으로 검색해 복원·재발행한다. 또 회원의 행동 기록(개인정보 안전 관리 의무)을 이벤트 저장소로 통합해, '누가 언제 어떤 행위로 어떤 변경이 있었는지'와 발행 경로·사유까지 추적하게 했다. 회원은 모든 도메인이 의존하는 가장 중심적이고 개인정보를 다루는 치명적인 도메인이라며, 외부에 영향을 주고받지 않고 개인정보를 안전하게 다루기 위한 고민 끝에 이 아키텍처가 만들어졌다는 말로 마친다.