들어가며사이드 프로젝트로 마이크로서비스 기반 루틴 인증 플랫폼을 개발하면서 가장 먼저 부딪힌 고민은 "서비스 내부를 어떻게 구성할 것인가"였다. 검색하면 늘 나오는 답은 클린 아키텍처(Clean Architecture)다. 도메인 계층과 인프라 계층을 철저히 분리하고, 의존성은 반드시 안쪽을 향해야 한다는 원칙. 이론은 명쾌하다. 그런데 막상 5개의 마이크로서비스에 적용하려 하자 의문이 생겼다."이걸 전부 따라야 할가? 아니면 더 현실적인 방법이 없을까?"이 글은 그 고민의 기록이다. 클린 아키텍처란 무엇인가Robert C. Martin(Uncle Bob)이 제시한 클린 아키텍처의 핵심은 하나다. 안쪽 계층은 바깥 계층을 절대 알면 안 된다. 이를 실현하기 위해 일반적으로 4개의 계층으로 나눈다.pres..
전체 글
0. 들어가며마이크로서비스 아키텍처에서 API Gateway는 모든 클라이언트 요청이 통과하는 단일 진입점이다.이 위치는 Rate Limiting을 적용하기에 가장 이상적인 지점이기도 하다.이 글에서는 Routinely 프로젝트의 gateway-service에 Redis 기반 Rate Limiting을 구현한 과정을 정리한다. 1. 개발 환경 구성항목버전 / 기술Java21Spring Boot4.0.5Spring Cloud GatewayWebFlux 기반 (spring-cloud-starter-gateway-server-webflux)RedisReactive (ReactiveStringRedisTemplate)빌드 도구Gradle build.gradle 의존성 implementation 'org.spr..
마이크로서비스 환경에서 SAGA 패턴을 도입하는 순간, 자연스럽게 하나의 질문과 마주하게 된다. "Orchestration으로 구현할 것인가, Choreography를 선택할 것인가?" 두 방식 모두 여러 서비스가 하나의 비즈니스 프로세스를 협력해 처리한다는 공통점을 갖지만, 흐름을 어떻게 제어하느냐와 운영 전략을 어떻게 가져가느냐에 따라 분명한 차이가 드러난다. Orchestration vs Choreography 비교 분석1. 트랜잭션 흐름 관리 방식두 패턴의 가장 큰 차이는 트랜잭션의 흐름을 누가 통제하는가이다.패턴제어 방식Orchestration중앙 Orchestrator가 전체 흐름을 직접 제어한다."다음 단계 실행"과 같은 명령(Command) 형태로 서비스에 지시한다.Choreography각..
Orchestration 방식이란?SAGA Orchestration은 중앙 조정자(Saga Orchestrator)가 모든 트랜잭션 단계를 직접 관리하는 방식이다.Orchestrator는 각 마이크로서비스에 "명령(Command)"을 보내고, 서비스는 해당 명령을 처리한 뒤 "결과(Reply)"를 Orchestrator에게 알려준다. 즉, Choreography가 이벤트를 구독하며 자율적으로 움직이는 방식이라면,Orchestration은 중앙 조정자가 전체 흐름을 명시적으로 통제하는 방식이다. 👉 오케스트라 지휘자처럼 각 서비스를 순서대로 지휘하는 구조 Orchestration 기반 주문 처리의 핵심 특징 정리SAGA Orchestration 방식의 핵심은 전체 Saga 생명주기를 중앙에서 명시적으로 ..
MSA 환경에서 하나의 사용자 요청은 여러 서비스에 걸쳐 수행된다.주문 -> 재고 -> 결제 -> 배송처럼 독립된 서비스들이 순차적으로 연결되며 전체 프로세스가 완성된다. 문제는, 이 과정이 하나의 트랜잭션처럼 보이지만 실제로는 분산된 여러 로컬 트랜잭션으로 구성된다는 점이다.이때 전통적인 ACID 트랜잭션으로는 데이터 일관성을 유지할 수 없기 때문에 등장한 해결책이 SAGA 패턴이다. Choreography 방식이란?이러한 SAGA를 구현하는 방식은 두 가지가 있다.오케스트레이션(Orchestration): 중앙 조정자가 전체 흐름을 통제코레오그래피(Choreography): 중앙 조정자 없이 이벤트 기반으로 처리 Choreography 방식은 서비스들이 이벤트를 통해 "너 다음!" 식으로 자연스럽게 ..
MSA, SAGA 얘기를 하다 보면 대부분 일관성(Consistency)과 보상 트랜잭션에 집중한다.하지만 실제로 대규모 분산 시스템을 설계할 때 더 골치 아프게 만드는 문제는 따로 있다. 바로 격리성(Isolation)이다. 다음과 같은 의문을 가질 수 있다.“SAGA를 쓰면 일관성은 어떻게든 맞출 수 있을 것 같은데…그 사이에 다른 요청이 끼어들면 상태가 꼬이지 않을까?” 전통적인 ACID가 제공하던 "격리성"을 SAGA는 제공하지 않기에 그렇다. 꼬일 수 있다. ACID에서의 격리성(Isolation)이란?ACID의 I, Isolation(격리성) 은 다음과 같이 정의할 수 있다.여러 트랜잭션이 동시에 실행되어도 서로의 "중간 상태"를 보지 못하게 하여, 결과적으로 순차 실행과 동일한 결과를 보장하..
MSA 환경에서 트랜잭션을 다루다 보면 반드시 마주치는 키워드 두 개가 있다.분산 트랜잭션을 “비즈니스적으로” 풀어내기 위한 SAGA 패턴같은 작업이 여러 번 실행되어도 안전하게 만들기 위한 멱등성(Idempotency)이 둘은 별도로 존재하는 개념이지만, 실제 서비스에서는 서로를 전제로 돌아간다. SAGA 패턴SAGA 패턴은 MSA 환경에서 분산 트랜잭션을 강한 ACID 트랜잭션으로 묶지 않고, 각 서비스의 로컬 트랜잭션 + 보상 트랜잭션을 통해 최종 일관성(Eventual Consistency) 을 맞추는 패턴이다. 예를 들어, 쇼핑몰 주문을 생각해보자.주문 서비스 → 주문 생성결제 서비스 → 결제 승인재고 서비스 → 재고 차감배송 서비스 → 배송 준비 여기서 중간에 실패가 나면? 결제 실패 → 주문..
왜 트랜잭션이 어려워졌을까?모놀로식 아키텍처에서는 하나의 데이터베이스 내에서 모든 트랜잭션이 수행된다.이때는 ACID(Atomicity, Consistency, Isolation, Durability) 원칙을 지키며 손쉽게 데이터 일관성을 유지할 수 있다. 하지만, MSA(Microservices Architecture)로 전환하면서 상황이 완전히 달라졌다.서비스가 분리되고, 각 서비스는 자체 데이터베이스를 가지게 되었다.이제 하나의 요청이 여러 서비스(DB)를 거치며 실행되기 때문에, 기존의 단일 트랜잭션 개념으로는 일관성을 보장하기가 어려워졌다. 분산 트랜잭션의 문제점1. 서비스 간 데이터 일관성 붕괴한 서비스의 작업은 성공했지만 다른 서비스의 작업이 실패하면, 데이터의 일관성이 쉽게 깨진다.예를 ..
마이크로서비스 아키텍처와 다양한 클라이언트 환경이 보편화되면서, 클라이언트 중심의 백엔드 설계 방식이 중요해졌다.이때 유용하게 활용되는 아키텍처 패턴이 BFF(Backend For Frontend)이다. BFF 패턴이란? BFF(Backend For Frontend)는 클라이언트(Web, Mobile, Wearable 등)의 특성에 맞춰 전용 백엔드 API를 제공하는 아키텍처 패턴이다. 즉, 하나의 백엔드가 모든 클라이언트를 처리하는 대신, 클라이언트별로 별도의 백엔드 계층(BFF)을 둬서 맞춤형 API를 제공하는 방식이다. BFF 패턴의 등장 배경1️⃣ 다양한 클라이언트 요구사항웹, 모바일, 웨어러블, IoT 등 클라이언트의 종류가 다양해지면서 각기 다른 UI/UX 요구가 발생한다.👉 동일한 데이터를..