전체 글

마이크로서비스 환경에서 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 요구가 발생한다.👉 동일한 데이터를..

마이크로서비스 아키텍처에서는 수많은 서비스가 서로 통신하면서 요청을 처리한다. 이때 하나의 요청이 여러 서비스에 걸쳐 수행되기 때문에, 문제 발생 시 어디서 실패했는지 파악하기 어렵다. 이를 해결하기 위해 API Gateway는 분산 로깅과 추적 기능을 적극 활용한다. 분산 시스템에서 발생할 수 있는 일반적인 문제 유형지연 시간 증가: 네트워크 지연, 서비스 과부하, 비효율적인 쿼리로 인한 응답 지연서비스 가용성 문제: 서버 장애, 네트워크 오류, 소프트웨어 버그로 인한 서비스 다운잘못된 서비스 통신: API 명세 불일치, 데이터 포맷 오류, 호출 순서 오류 등으로 시스템 오작동➡️ 이러한 이유로 요청 흐름 추적과 문제 진단이 매우 중요하다. 분산 로깅과 추적이 필요한 이유문제 진단: 요청 경로를 정확히..

마이크로서비스 아키텍처 환경에서 API Gateway는 모든 외부 요청의 진입점 역할을 한다. 따라서 API Gateway 수준에서의 로깅(Log)과 모니터링(Monitoring)은 시스템의 전반적인 가시성을 확보하고, 장애를 빠르게 진단하는 데 매우 중요한 역할을 한다. 로깅(Logging)이란?로깅은 사용자의 요청, 응답, 에러, 인증 정보 등의 실제 동작을 기록하는 행위이다. 로깅 항목 예시요청 URL, HTTP 메서드요청 시간, 응답 시간응답 상태 코드사용자 ID, IP 주소라우팅된 마이크로서비스 이름인증/인가 결과오류 메시지 API Gateway에서 로깅의 중요성항목설명트랜잭션 추적API 호출의 전체 경로를 추적하여 성능 병목 및 장애 원인을 파악보안 감사불법적인 접근 시도 및 보안 위협을 식별..

마이크로서비스 아키텍처(MSA) 환경에서는 수많은 서비스가 동시에 동작하며, 클라이언트의 요청도 급격하게 증가할 수 있다. 모든 요청을 무작정 받아들이면, 서비스 전체에 과부하가 걸릴 수 있다. 이를 방지하기 위해 트래픽 제어(Traffic Control)가 필요하다. API Gateway는 단순히 요청을 라우팅하는 역할에 그치지 않고, 서비스 보호, 부하 분산, 응답 속도 최적화, 비용 절감 등 다양한 트래픽 제어 기능을 수행한다. 트래픽 제어란?트래픽 제어(Traffic Control)는 클라이언트로부터 오는 요청을 관리, 조절, 그리고 최적화하는 과정이다. 주요 목적서버 오버로드 방지서비스 안전성 확보효율적인 리소스 사용사용자 경험 향상 트래픽 제어의 중요성항목설명서비스 가용성 유지과도한 트래픽으로..