[대규모 시스템 설계 #5] 서비스 간의 데이터 통신 - Kafka를 활용한 이벤트 발생 및 처리

개요지난 글에서는 Config Server와 Spring Cloud Bus를 통해,분산된 마이크로서비스들의 설정을 중앙에서 관리하고 실시간으로 변경 사항을 전파하는 구조를 다뤘다.이제부터는 MSA 환경에서 빠질 수 없는 핵심 주제인 서비스 간 데이터 통신에 대해 살펴본다.REST API 기반의 동기식 호출만으로는 서비스 간 결합도가 높아지고 장애 전파 위험도 커진다.이를 해결하기 위해 이번 글에서는 Kafka를 활용한 이벤트 기반 아키텍처(Event-Driven Architecture)를 실습해본다.(해당 글에서는 주요 코드만 간결하게 정리하며, 전체 코드는 Gihub 링크를 참고하길 바란다) 시나리오간단한 주문 서비스와 상품(재고) 서비스가 있다고 가정해보자.사용자가 '주문'을 요청하면 주문 서비스는 ..

• format_list_bulleted 설계
• · 2025. 9. 14.

[대규모 시스템 설계 #4] Config 서버 구축기 — Spring Cloud Bus를 활용한 마이크로 서비스 설정 전파

개요지난 글에서는 Spring Cloud Gateway와 Eureka를 연동하여 각 서비스의 인스턴스가 동적으로 변하는 상황에서도서비스 이름을 기반으로 요청을 안정적으로 라우팅하고 로드밸런싱하는 방법을 실습했다.클라이언트가 각 서비스별 다수 인스턴스의 IP나 포트를 몰라도,Gateway라는 단일 진입점을 통해 마이크로서비스 아키텍처(MSA)와 통신할 수 있는 기반을 마련한 것이다.이번 글에서는 각 서비스에 흩어져 있는 어플리케이션 설정 파일들을 한 곳에서 관리하기 위해, Spring Cloud Config Server를 구축하고 연동하는 과정을 상세히 정리해보려한다.그후 단순히 Config Server 연동을 넘어, 설정이 변경됐을 때 어플리케이션을 재배포하지 않고 즉시 Reload하는 방법과이러한 설정..

• format_list_bulleted 설계
• · 2025. 8. 31.

[대규모 시스템 설계 #3] Spring Cloud Gateway 구축기 — Eureka 연동으로 서비스명 라우팅 & LB

개요지난 글에서는 Nginx로 단순 로드밸런싱을 실습했다. 이번에는 Spring Cloud Gateway를 직접 구축하고, Eureka Discovery와 연동해 서비스명 기반 라우팅과 로드밸런싱을 확인한 과정을 정리한다.(주 언어를 Kotlin으로 넘어가기 위해 이번 실습 과정부터 Kotlin를 활용한 신규 프로젝트로 진행하며, 대규모 시스템 설계에 대한 학습 이후 기존 호텔 예약 플랫폼 프로젝트를 고도화하려 한다.) 목표 & 범위핵심 목표: Gateway를 통해 Eureka에 등록된 서비스명을 기반으로 라우팅 & LB 확인하기범위: Eureka Server/Client 구축, Gateway 연동 및 로드밸런싱 검증 제외: 인증 필터, Config/Bus, Kafka 등은 후속 글에서 다룬다. 아키텍..

• format_list_bulleted 설계
• · 2025. 8. 17.

[대규모 시스템 설계 #2] Nginx로 트래픽 분산 실습해보기

개요이전 글에서는 단일 서버 구조의 한계를 짚으며, 확장 가능한 시스템 설계의 필요성을 이야기했다. 그렇다면, 실제로 트래픽이 늘어난 상황에서 우리는 어떤 방식으로 구조를 확장해나갈 수 있을까? 이번 글에서는 그 첫걸음으로, 여러 대의 서버에 트래픽을 분산하는 구조, 즉 로드밸런서에 대해 다뤄본다. 가장 널리 쓰이는 도구인 Nginx를 활용하여, 단순히 서버를 늘리는 것을 넘어 어떻게 요청이 분산되고 처리되는지를 실습을 통해 직접 확인해본다. 그리고 이 실습을 통해, 다음 단계인 정책 기반 라우팅의 필요성 또한 자연스럽게 드러날 것이다. 왜 Nginx 인가?단일 서버로는 더 이상 트래픽을 감당할 수 없는 시점이 왔다면, 가장 먼저 떠올려야 할 질문이 있다. "서버는 여러 대로 나눴는데, 클라이언트는 이걸..

• format_list_bulleted 설계
• · 2025. 8. 1.

[대규모 시스템 설계 #1] 대규모 시스템 설계에 앞서

개요호텔 예약 플랫폼 프로젝트를 기반으로, 대규모 시스템을 설계하는 과정에 대해 공유하는 시리즈를 시작한다.먼저, 이 글에서는 대규모 시스템이란 무엇인지, 왜 대규모 시스템을 학습하려 하는지,어떠한 상황을 가정하여 대규모 시스템으로 확장할 것인지에 대해 정리해보고자 한다.이 글이 앞으로 이어질 대규모 시스템 설계 이야기의 단단한 발판이 되길 바란다. 왜 대규모 시스템으로 설계하려 하는가?지금껏 실무에서 다뤄온 시스템은, 대부분 제한된 트래픽과 데이터를 기준으로 설계된 구조였다. 그 안에서도 병목을 줄이고 성능을 개선하려는 다양한 시도를 했지만, 데이터 규모가 커지는 순간에는 설계 자체를 다시 생각해야 한다는 점을 절실히 경험했다. 그래서 이번에는 단순히 ‘트래픽을 견디는 구조’를 점진적으로 개선하는 수준..

• format_list_bulleted 설계
• · 2025. 7. 17.

[Batch 시리즈 #8] 연박 정책 기반 집계 구조: 성능 병목을 해결하기 위한 데이터 리모델링

개요이번 글은 Batch로 저장되는 데이터 구조를 전면 리모델링하는 글이다.지금까지 객실 예약 가능 수량을 관리하기 위해 특정 날짜 기준, 객실별 예약 가능 수량 정보를 DB에 적재했다.(참고: [Batch 시리즈 #1] 매일 수백만 건의 예약 가능 객실, 어떻게 만들까? - 객실 가용성 배치 도입기)이 정보를 기반으로 특정 날짜에 예약 가능한 객실이 존재하는가 여부를 쉽게 확인할 수 있었다.그러나 문제는 한번에 단 1박만 예약하지 않는다는 것이다.몇몇 숙박 예약 플랫폼 서비스를 이용해본 결과 최대 30연박 조건으로 예약 가능한 호텔 조회가 가능했다.이번 글에서는 현재 구조에서 연박 가능한 숙박 조회 API를 개발하면서 생긴 성능 문제와이러한 성능 문제를 해결하기 위해 데이터 구조를 재설계한 과정을 공유..

• format_list_bulleted Batch
• · 2025. 6. 23.