배달의민족 API Gateway #우아콘2024 #우아한형제들

우아한테크·woowacon-2024 ·2024년·

#microservices#cross-cutting-concerns#jwt-authentication#resilience-patterns#spring-cloud-gateway#api-gateway

AI 요약

MSA에서 API Gateway가 왜 필요한지를 routing과 인증·보안·관측·탄력성 같은 횡단 관심사의 중앙화로 설명하고, client별 business 조합을 맡는 API Gateway Pattern(frontend server)과의 책임 경계를 명확히 구분한다. 배달의민족의 실제 Spring Cloud Gateway 구성으로 마무리한다.

핵심 포인트

Zuul·AWS API Gateway·Kong·Spring Cloud Gateway를 비교해 공통 역할을 추출 — API Gateway는 요청을 알맞은 service로 routing하고 여러 service가 반복 구현할 인증·보안·monitoring·resilience를 한곳에서 처리하는 계층
마이배민처럼 회원·쿠폰·포인트·결제를 조합하는 문제는 client 요구에 맞춘 API를 주는 frontend server(API Gateway Pattern)가 해결하며, domain 분할 자체가 아니라 Conway 법칙으로 frontend server가 늘고 공통 policy를 공유하는 service 수가 커져 변경 비용이 선형 증가할 때 중앙 Gateway가 필요 — Gateway로 frontend server를 대체하면 business가 공통 layer에 섞이는 문제가 재발
배민은 단일 실패점을 피해 영향도별 다중 server group에 service를 배치하고 동일 codebase 공유로 DNS 전환·event 전용 group 분리를 가능케 했으며, Spring Cloud Gateway를 database 설정·filter chain으로 확장해 JWT 검증 결과를 passport로 전달하고 host·token·IP routing, abuse 차단, rate limiting·circuit breaker·retry를 요청별 적용

왜 읽나MSA에서 Gateway와 BFF의 책임을 헷갈리기 쉬운 개발자에게 개념적 경계와 대규모 운영 구성을 함께 짚어주는 정리.

챕터별 상세

011:53 – 6:11

API Gateway를 정의하는 routing과 횡단 관심사

Netflix Zuul, AWS API Gateway, Kong과 Spring Cloud Gateway의 설명을 비교해 제품 이름에 가려진 공통 역할을 추출한다. API Gateway는 client와 backend 사이에서 요청을 적절한 service로 routing하고, 여러 service가 반복해서 구현할 인증·보안·monitoring·resilience 같은 횡단 관심사를 한곳에서 처리하는 계층으로 정의된다.

마이배민 화면처럼 회원·쿠폰·포인트·결제 domain을 조합해야 할 때 client가 microservice를 직접 호출하면 의존성이 커지고 불필요한 정보와 핵심 business policy가 client에 노출된다. 이를 해결하는 API Gateway Pattern의 본질은 client 요구에 맞춘 API를 제공하는 frontend server이며, domain 분할 자체가 API Gateway를 필요하게 만드는 이유는 아니라고 구분한다.

조직의 communication 구조를 반영해 주문·회원·가게 목록별 frontend server도 나뉘면 각 팀은 독립적으로 business를 발전시킬 수 있지만, 인증·보안·관측·탄력성 policy는 모든 server를 가로지르게 된다. 동일 policy를 공유하는 service 수가 늘수록 배포와 변경 비용이 선형으로 커지므로, 성장하는 MSA에서 이 공통 문제를 중앙에서 해결할 API Gateway가 필요해진다.

API Gateway Pattern은 client와 분산 domain 사이의 business 조합을 frontend server에서 해결하고, API Gateway는 그 frontend server들 앞에서 business와 무관한 공통 policy를 처리한다. Gateway로 frontend server를 대체하면 business가 공통 layer에 섞이거나 client가 domain을 직접 호출하는 문제가 되살아나므로, Gateway는 BFF 등 client 전담 책임이 이미 분리된 server와 연결해야 한다.

단일 실패 지점을 피하려고 traffic에 따라 scale-out 가능한 다중 server group에 service를 영향도별로 배치하고, 동일 codebase를 공유해 DNS 전환이나 event 전용 group 분리가 가능하게 구성했다. Spring Cloud Gateway를 database 설정과 별도 filter chain으로 확장해 JWT 검증 결과를 passport로 backend에 전달하며, host·token·IP 기반 routing, abuse 차단, rate limiting·circuit breaker·retry·정적 응답을 요청별로 적용한다.