1. 개요
핵심 원칙과 실제 맥락에서 볼 때 마이크로 서비스 기반 애플리케이션은 분산 시스템입니다. 전체 시스템은 여러 개의 소규모 서비스로 구성되며 이러한 서비스가 함께 전체 애플리케이션 기능을 제공합니다.
이 아키텍처 스타일은 수많은 이점을 제공하지만 몇 가지 제한 사항도 있습니다. 마이크로서비스 아키텍처의 주요 문제 중 하나는 여러 서비스에 걸쳐 있는 트랜잭션을 처리하는 방법입니다 .
이 튜토리얼에서는 마이크로서비스 아키텍처에서 분산 트랜잭션을 관리할 수 있는 Saga 아키텍처 패턴을 살펴보겠습니다.
추가 자료:
2. 서비스 패턴별 데이터베이스
마이크로서비스 아키텍처의 장점 중 하나는 서비스별로 기술 스택을 선택할 수 있다는 것입니다.
예를 들어 서비스 A에는 관계형 데이터베이스를 사용하고 서비스 B에는 NoSQL 데이터베이스를 사용하기로 결정할 수 있습니다.
이 모델을 사용하면 서비스가 해당 데이터 유형 및 스키마에 가장 적합한 데이터 저장소에서 도메인 데이터를 독립적으로 관리할 수 있습니다. 또한 서비스는 필요에 따라 데이터 저장소를 확장하고 다른 서비스의 오류로부터 보호할 수 있습니다.
그러나 때로는 트랜잭션이 여러 서비스에 걸쳐 있을 수 있으므로 서비스 데이터베이스 전체에서 데이터 일관성을 보장하는 것이 어렵습니다. 다음 섹션에서는 예제를 통해 분산 트랜잭션 관리의 과제를 자세히 살펴보겠습니다.
3. 분산거래
분산 트랜잭션의 사용을 보여주기 위해 온라인 주문을 처리하고 마이크로서비스 아키텍처로 구현되는 전자상거래 애플리케이션의 예를 들어보겠습니다.
주문을 생성하는 마이크로서비스가 있는데, 하나는 결제를 처리하고, 다른 하나는 재고를 업데이트하고, 마지막으로 주문을 전달하는 것입니다.
이러한 각 마이크로서비스는 로컬 트랜잭션을 수행하여 개별 기능을 구현합니다.
이는 트랜잭션 경계가 여러 서비스와 데이터베이스를 교차하는 분산 트랜잭션의 예입니다.
성공적인 주문 처리 서비스를 보장하려면 4개의 마이크로서비스가 모두 개별 로컬 트랜잭션을 완료해야 합니다. 마이크로서비스 중 하나라도 로컬 트랜잭션을 완료하지 못하면 데이터 무결성을 보장하기 위해 완료된 모든 이전 트랜잭션을 롤백해야 합니다.
4. 분산거래의 과제
이전 섹션에서는 분산 트랜잭션의 실제 예를 제공했습니다. 마이크로서비스 아키텍처의 분산 트랜잭션에는 두 가지 주요 과제가 있습니다.
첫 번째 과제는 ACID를 유지하는 것입니다. 트랜잭션의 정확성을 보장하려면 ACID(원자성, 일관성, 격리성 및 내구성)가 있어야 합니다. 원자 성은 트랜잭션의 모든 단계가 완료되거나 완료되지 않도록 보장합니다. 일관성은 데이터를 하나의 유효한 상태에서 다른 유효한 상태로 가져옵니다. 격리는 동시 트랜잭션이 순차적 트랜잭션이 생성한 것과 동일한 결과를 생성하도록 보장합니다. 마지막으로 내구성은 모든 유형의 시스템 오류에 관계없이 커밋된 트랜잭션이 커밋된 상태로 유지됨을 의미합니다. 분산 트랜잭션 시나리오에서는 트랜잭션이 여러 서비스에 걸쳐 있으므로 ACID가 항상 핵심으로 유지되도록 해야 합니다.
두 번째 과제는 트랜잭션 격리 수준을 관리하는 것입니다. 다른 서비스가 동일한 데이터에 동시에 액세스할 때 트랜잭션에 표시되는 데이터의 양을 지정합니다. 즉, 다른 요청이 데이터를 읽는 동안 마이크로 서비스 중 하나의 개체가 데이터베이스에 유지되는 경우 서비스는 이전 데이터를 반환해야 합니까, 아니면 새 데이터를 반환해야 합니까?
5. 2단계 커밋 이해
2PC(Two-Phase Commit) 프로토콜은 분산 트랜잭션을 구현하는 데 널리 사용되는 패턴입니다. 마이크로서비스 아키텍처에서 이 패턴을 사용하여 분산 트랜잭션을 구현할 수 있습니다.
2단계 커밋 프로토콜에는 트랜잭션 제어를 담당하고 트랜잭션 관리 논리를 포함하는 코디네이터 구성 요소가 있습니다.
다른 구성 요소는 로컬 트랜잭션을 실행하는 참여 노드(예: 마이크로서비스)입니다.
이름에서 알 수 있듯이 2단계 커밋 프로토콜은 두 단계로 분산 트랜잭션을 실행합니다.
- 준비 단계 – 코디네이터는 참여 노드에게 트랜잭션을 커밋할 준비가 되었는지 묻습니다. 참가자들은 예 또는 아니오 로 대답했습니다 .
- 커밋 단계 – 참여하는 모든 노드가 1단계에서 긍정적으로 응답하면 코디네이터는 모든 노드에 커밋을 요청합니다. 하나 이상의 노드가 부정적인 결과를 반환하면 코디네이터는 모든 참가자에게 로컬 트랜잭션을 롤백하도록 요청합니다.
6. 2PC의 문제점
2PC는 분산 트랜잭션을 구현하는 데 유용하지만 다음과 같은 단점이 있습니다.
- 트랜잭션의 책임은 코디네이터 노드에 있으며 단일 실패 지점이 될 수 있습니다.
- 다른 모든 서비스는 가장 느린 서비스가 확인을 마칠 때까지 기다려야 합니다. 따라서 트랜잭션의 전체 성능은 가장 느린 서비스에 의해 제한됩니다.
- 2단계 커밋 프로토콜은 조정자에 대한 수다와 의존성으로 인해 설계상 속도가 느립니다. 따라서 여러 서비스가 포함된 마이크로서비스 기반 아키텍처에서는 확장성 및 성능 문제가 발생할 수 있습니다.
- NoSQL 데이터베이스에서는 2단계 커밋 프로토콜이 지원되지 않습니다. 따라서 하나 이상의 서비스가 NoSQL 데이터베이스를 사용하는 마이크로서비스 아키텍처에서는 2단계 커밋을 적용할 수 없습니다.
7. 사가 소개
7.1. Saga 아키텍처 패턴이란 무엇입니까?
Saga 아키텍처 패턴은 일련의 로컬 트랜잭션을 사용하여 트랜잭션 관리를 제공합니다.
로컬 트랜잭션은 Saga 참가자가 수행하는 작업 단위입니다. Saga의 일부인 모든 작업은 보상 트랜잭션을 통해 롤백될 수 있습니다. 또한 Saga 패턴은 모든 작업이 성공적으로 완료되거나 해당 보상 트랜잭션이 실행되어 이전에 완료된 작업을 취소하도록 보장합니다.
Saga 패턴에서 보상 트랜잭션은 멱등성이 있고 재시 도 가능해야 합니다 . 이 두 가지 원칙을 통해 수동 개입 없이 거래를 관리할 수 있습니다.
Saga 실행 코디네이터(SEC)는 다음 원칙을 보장합니다.
위 다이어그램은 앞서 논의한 온라인 주문 처리 시나리오에 대한 Saga 패턴을 시각화하는 방법을 보여줍니다.
7.2. Saga 실행 코디네이터
Saga 실행 코디네이터 는 Saga 흐름을 구현하는 핵심 구성 요소입니다. 여기에는 분산 트랜잭션의 이벤트 시퀀스를 캡처하는 Saga 로그가 포함되어 있습니다.
오류가 발생하면 SEC 구성 요소는 Saga 로그를 검사하여 영향을 받은 구성 요소와 보상 트랜잭션이 실행되어야 하는 순서를 식별합니다.
SEC 구성 요소에 오류가 발생하면 다시 복구된 후 Saga 로그를 읽을 수 있습니다.
그런 다음 성공적으로 롤백된 트랜잭션과 보류 중인 트랜잭션을 식별하고 적절한 조치를 취할 수 있습니다.
Saga 패턴을 구현하는 방법에는 안무와 오케스트레이션이라는 두 가지 접근 방식이 있습니다. 다음 섹션에서 이에 대해 논의하겠습니다.
7.3. 사가 안무 패턴 구현
Saga Choreography 패턴에서 트랜잭션의 일부인 각 마이크로 서비스는 다음 마이크로 서비스에서 처리되는 이벤트를 게시합니다.
이 패턴을 사용하려면 마이크로서비스가 Saga의 일부인지 결정해야 합니다. 따라서 마이크로서비스는 Saga를 구현하기 위해 적절한 프레임워크를 사용해야 합니다. 이 패턴에서 Saga Execution Coordinator는 마이크로서비스 내에 내장되거나 독립형 구성 요소가 될 수 있습니다.
Saga에서는 모든 마이크로서비스가 로컬 트랜잭션을 완료하고 어떤 마이크로서비스도 실패를 보고하지 않으면 안무 흐름이 성공한 것입니다.
다음 다이어그램은 온라인 주문 처리 애플리케이션의 성공적인 Saga 흐름을 보여줍니다.
오류가 발생하는 경우 마이크로서비스는 SEC에 오류를 보고하고 관련 보상 거래를 호출하는 것은 SEC의 책임입니다 .
이 예에서 결제 마이크로서비스는 실패를 보고하고 SEC는 좌석 차단을 해제하기 위해 보상 트랜잭션을 호출합니다. 보상 트랜잭션에 대한 호출이 실패하는 경우 성공적으로 완료될 때까지 이를 재시도하는 것은 SEC의 책임입니다. Saga에서 보상 트랜잭션은 멱등성이 있고 재시도 가능 해야 한다는 점을 기억하세요 .
안무 패턴은 그린필드 마이크로서비스 애플리케이션 개발에 적합합니다. 또한 이 패턴은 거래 참여자가 적을 때 적합합니다.
안무 패턴을 구현하는 데 사용할 수 있는 몇 가지 프레임워크는 다음과 같습니다.
- Axon Saga – Spring Boot 기반 마이크로서비스와 함께 널리 사용되는 경량 프레임워크
- Eclipse MicroProfile LRA – REST 원칙을 기반으로 하는 HTTP 전송을 위해 Saga에서 분산 트랜잭션 구현
- Eventuate Tram Saga – Spring Boot 및 Micronaut 기반 마이크로서비스를 위한 Saga 오케스트레이션 프레임워크
- Seata – 고성능의 사용하기 쉬운 분산 트랜잭션 서비스를 갖춘 오픈 소스 분산 트랜잭션 프레임워크
7.4. Saga 오케스트레이션 패턴 구현
오케스트레이션 패턴에서는 단일 오케스트레이터가 전체 트랜잭션 상태를 관리합니다.
마이크로서비스 중 하나라도 오류가 발생하면 오케스트레이터는 필요한 보상 트랜잭션을 호출할 책임이 있습니다.
Saga 오케스트레이션 패턴은 브라운필드 마이크로서비스 애플리케이션 개발 아키텍처에 유용합니다. 즉, 이 패턴은 이미 마이크로서비스 세트가 있고 애플리케이션에 Saga 패턴을 구현하려는 경우에 작동합니다. 이 패턴을 진행하려면 적절한 보상 거래를 정의해야 합니다.
오케스트레이터 패턴을 구현하는 데 사용할 수 있는 몇 가지 프레임워크는 다음과 같습니다.
- Camunda 는 워크플로 및 프로세스 자동화를 위한 BPMN(Business Process Model and Notation) 표준을 지원하는 Java 기반 프레임워크입니다.
- Apache Camel은 Saga Enterprise Integration Pattern(EIP) 구현을 제공합니다.
8. 결론
이 기사에서는 마이크로서비스 기반 애플리케이션에서 분산 트랜잭션을 구현하기 위한 Saga 아키텍처 패턴에 대해 논의했습니다.
먼저 이러한 구현의 과제를 소개했습니다.
그런 다음 Saga의 인기 있는 대안인 2단계 커밋 프로토콜을 살펴보고 마이크로서비스 기반 애플리케이션에서 분산 트랜잭션을 구현하는 데 한계가 있는지 조사했습니다.
마지막으로 Saga 아키텍처 패턴, 작동 방식 및 마이크로서비스 기반 애플리케이션에서 Saga 패턴을 구현하는 두 가지 주요 접근 방식에 대해 논의했습니다.
이 글에 대한 댓글은 닫혀있습니다!
