마이크로서비스를 위한 이벤트 기반 데이터 관리

Chris Richardson

편집자 – 총 7부로 구성된 이 연재 기사가 이제 완결되었습니다:

1. 마이크로서비스 소개
2. 마이크로서비스 구축: API 게이트웨이 사용
3. 마이크로서비스 구축: 마이크로서비스 아키텍처의 프로세스 간 통신
4. 마이크로서비스 아키텍처의 서비스 디스커버리
5. 마이크로서비스를 위한 이벤트 기반 데이터 관리(이 글)
6. 마이크로서비스 배포 전략 선택
7. 모놀리스를 마이크로서비스로 리팩터링하기

전체 아티클과 NGINX Plus를 사용한 마이크로서비스 구현 정보를 전자책으로도 다운로드할 수 있습니다. 전자책 제목은 마이크로서비스: 설계부터 배포까지입니다. 또한 마이크로서비스 참조 아키텍처 시리즈와 마이크로서비스 솔루션 페이지도 확인해 보세요.

마이크로서비스를 사용한 애플리케이션 구축을 다루는 시리즈의 다섯 번째 글입니다. 첫 번째 글에서는 마이크로서비스 아키텍처 패턴을 소개하고 마이크로서비스 사용의 장단점을 살펴봅니다. 이 시리즈의 두 번째<.htmla> 및 세 번째 글에서는 마이크로서비스 아키텍처 내 통신의 다양한 측면을 설명합니다. 네 번째 글에서는 이와 밀접하게 관련된 서비스 디스커버리 문제를 살펴봅니다. 이번 글에서는 주제를 전환하여 마이크로서비스 아키텍처에서 발생하는 분산 데이터 관리 문제를 살펴보겠습니다.

마이크로서비스와 분산 데이터 관리 문제

모놀리식 애플리케이션은 일반적으로 단일 관계형 데이터베이스를 사용합니다. 관계형 데이터베이스를 사용할 때의 주요 이점은 애플리케이션에서 ACID 트랜잭션을 사용할 수 있다는 점이며, 이를 통해 다음과 같은 중요한 사항이 보장됩니다:

• 원자성 – 변경 사항은 원자적으로 적용됩니다
• 일관성 – 데이터베이스의 상태는 항상 일관되게 유지됩니다
• 격리성 – 트랜잭션이 동시에 실행되더라도 순차적으로 실행되는 것처럼 보입니다
• 지속성 – 트랜잭션이 커밋되면 취소되지 않습니다

따라서 애플리케이션에서는 트랜잭션을 시작하고 여러 행을 변경(삽입, 업데이트 및 삭제)한 다음 트랜잭션을 커밋하기만 하면 됩니다.

관계형 데이터베이스를 사용할 때 얻을 수 있는 또 다른 큰 이점은 풍부한 표현력을 갖춘 선언적 표준 쿼리 언어인 SQL을 제공한다는 것입니다. 여러 테이블의 데이터를 결합하는 쿼리도 쉽게 작성할 수 있습니다. 그러면 RDBMS 쿼리 플래너가 해당 쿼리를 실행하는 가장 효율적인 방법을 결정합니다. 데이터베이스에 접근하는 방법과 같은 저수준의 세부 사항은 신경 쓰지 않아도 됩니다. 또한 애플리케이션의 모든 데이터가 하나의 데이터베이스에 있으므로 쉽게 쿼리할 수 있습니다.

안타깝게도 마이크로서비스 아키텍처로 전환하면 데이터 액세스가 훨씬 더 복잡해집니다. 각 마이크로서비스가 소유한 데이터는 해당 마이크로서비스 전용이며 해당 API를 통해서만 액세스할 수 있기 때문입니다. 데이터를 캡슐화하면 마이크로서비스 간의 결합도를 낮게 유지하고 각 서비스를 서로 독립적으로 발전시킬 수 있습니다. 여러 서비스가 동일한 데이터에 액세스하는 경우 스키마를 업데이트하려면 모든 서비스를 대상으로 시간이 많이 소요되는 조율된 업데이트를 수행해야 합니다.

설상가상으로, 서로 다른 마이크로서비스는 각기 다른 종류의 데이터베이스를 사용하는 경우가 많습니다. 현대적인 애플리케이션은 다양한 종류의 데이터를 저장하고 처리하므로 관계형 데이터베이스가 항상 최선의 선택인 것은 아닙니다. 일부 사용 사례에서는 특정 NoSQL 데이터베이스가 더 편리한 데이터 모델을 제공하고 성능과 확장성도 훨씬 뛰어날 수 있습니다. 예를 들어 텍스트를 저장하고 쿼리하는 서비스라면 Elasticsearch와 같은 텍스트 검색 엔진을 사용하는 것이 적합합니다. 마찬가지로 소셜 그래프 데이터를 저장하는 서비스라면 Neo4j와 같은 그래프 데이터베이스를 사용하는 것이 좋습니다. 따라서 마이크로서비스 기반 애플리케이션은 흔히 SQL과 NoSQL 데이터베이스를 함께 사용하는, 이른바 폴리글랏 퍼시스턴스 방식을 채택합니다.

데이터 저장소를 분할하고 여러 종류의 데이터베이스를 함께 사용하는 폴리글랏 퍼시스턴스 아키텍처는 서비스 간 결합도를 낮추고 성능과 확장성을 향상시키는 등 많은 이점을 제공합니다. 하지만 분산 데이터 관리와 관련된 몇 가지 과제도 발생합니다.

첫 번째 과제는 여러 서비스에 걸쳐 일관성을 유지하는 비즈니스 트랜잭션을 구현하는 것입니다. 이것이 왜 문제가 되는지 알아보기 위해 온라인 B2B 스토어의 예를 살펴보겠습니다. 고객 서비스는 신용 한도를 비롯한 고객 정보를 관리합니다. 주문 서비스는 주문을 관리하며, 새 주문이 고객의 신용 한도를 초과하지 않는지 확인해야 합니다. 이 애플리케이션의 모놀리식 버전에서는 주문 서비스가 ACID 트랜잭션을 사용하여 가용 신용을 확인하고 주문을 생성하기만 하면 됩니다.

반면 마이크로서비스 아키텍처에서는 다음 다이어그램과 같이 ORDER 테이블과 CUSTOMER 테이블이 각각 해당 서비스에서만 사용됩니다.

주문 서비스는 CUSTOMER 테이블에 직접 액세스할 수 없습니다. 고객 서비스에서 제공하는 API만 사용할 수 있습니다. 주문 서비스는 분산 트랜잭션(2단계 커밋(2PC)이라고도 함)을 사용할 수도 있습니다. 하지만 일반적으로 2PC는 최신 애플리케이션에서 실용적인 선택지가 아닙니다. CAP 정리에 따르면 가용성과 ACID 방식의 일관성 중 하나를 선택해야 하며, 일반적으로는 가용성을 선택하는 편이 낫습니다. 또한 대부분의 NoSQL 데이터베이스를 비롯한 많은 최신 기술은 2PC를 지원하지 않습니다. 서비스와 데이터베이스 전반에서 데이터 일관성을 유지하는 것은 필수적이므로 다른 해결책이 필요합니다.

두 번째 과제는 여러 서비스에서 데이터를 가져오는 쿼리를 구현하는 방법입니다. 예를 들어 애플리케이션에서 고객과 해당 고객의 최근 주문을 표시해야 한다고 가정해 보겠습니다. 주문 서비스가 고객의 주문을 조회하는 API를 제공한다면 애플리케이션 측 조인을 사용하여 이 데이터를 가져올 수 있습니다. 애플리케이션은 고객 서비스에서 고객 정보를 가져오고 주문 서비스에서 해당 고객의 주문을 가져옵니다. 하지만 주문 서비스가 기본 키를 통한 주문 조회만 지원한다고 가정해 보겠습니다(예를 들어 기본 키 기반 조회만 지원하는 NoSQL 데이터베이스를 사용할 수 있습니다). 이 경우 필요한 데이터를 가져올 뚜렷한 방법이 없습니다.

이벤트 기반 아키텍처

많은 애플리케이션에서는 이벤트 기반 아키텍처를 사용하는 것이 해결책입니다. 이 아키텍처에서는 비즈니스 엔터티를 업데이트하는 경우처럼 주목할 만한 일이 발생하면 마이크로서비스가 이벤트를 게시합니다. 다른 마이크로서비스는 이러한 이벤트를 구독합니다. 마이크로서비스는 이벤트를 수신하면 자체 비즈니스 엔터티를 업데이트할 수 있으며, 이로 인해 더 많은 이벤트가 게시될 수 있습니다.

이벤트를 사용하여 여러 서비스에 걸친 비즈니스 트랜잭션을 구현할 수 있습니다. 트랜잭션은 일련의 단계로 구성됩니다. 각 단계에서는 마이크로서비스가 비즈니스 엔터티를 업데이트하고 다음 단계를 트리거하는 이벤트를 게시합니다. 다음 다이어그램 시퀀스는 주문을 생성할 때 사용 가능한 신용 한도를 확인하기 위해 이벤트 기반 접근 방식을 사용하는 방법을 보여 줍니다. 마이크로서비스는 메시지 브로커를 통해 이벤트를 교환합니다.

1. 주문 서비스는 상태가 NEW인 주문을 생성하고 주문 생성 이벤트를 발행합니다.
   
2. 고객 서비스는 주문 생성 이벤트를 수신하고 주문에 필요한 신용 한도를 확보한 후, 신용 한도 확보 이벤트를 발행합니다.
   
3. 주문 서비스는 Credit Reserved 이벤트를 수신하고 주문 상태를 OPEN으로 변경합니다.
   

더 복잡한 시나리오에서는 고객의 신용을 확인하는 동시에 재고를 확보하는 등의 추가 단계가 포함될 수 있습니다.

(a) 각 서비스가 데이터베이스를 원자적으로 업데이트하고 이벤트를 게시하며(이에 대해서는 나중에 자세히 설명합니다), (b) 메시지 브로커가 이벤트를 최소 한 번 이상 전달하도록 보장한다면 여러 서비스에 걸친 비즈니스 트랜잭션을 구현할 수 있습니다. 단, 이러한 트랜잭션은 ACID 트랜잭션이 아니라는 점에 유의해야 합니다. 이 트랜잭션은 최종적 일관성과 같이 훨씬 약한 수준의 보장만 제공합니다. 이러한 트랜잭션 모델을 BASE 모델이라고 합니다.

이벤트를 사용하여 여러 마이크로서비스가 소유한 데이터를 미리 조인한 구체화된 뷰를 유지할 수도 있습니다. 뷰를 유지 관리하는 서비스는 관련 이벤트를 구독하고 뷰를 업데이트합니다. 예를 들어 고객 주문 뷰를 유지 관리하는 고객 주문 뷰 업데이트 서비스는 고객 서비스와 주문 서비스가 게시하는 이벤트를 구독합니다.

고객 주문 뷰 업데이트 서비스는 고객 또는 주문 이벤트를 수신하면 고객 주문 뷰 데이터 저장소를 업데이트합니다. 고객 주문 뷰는 MongoDB와 같은 문서 데이터베이스를 사용해 구현하고 고객별로 하나의 문서를 저장할 수 있습니다. 고객 주문 뷰 쿼리 서비스는 고객 주문 뷰 데이터 저장소를 조회하여 고객 및 최근 주문에 대한 요청을 처리합니다.

이벤트 기반 아키텍처에는 여러 장단점이 있습니다. 이 아키텍처를 사용하면 여러 서비스에 걸쳐 있으면서 최종 일관성을 제공하는 트랜잭션을 구현할 수 있습니다. 또한 애플리케이션이 구체화된 뷰를 유지할 수 있다는 장점도 있습니다. 단점은 ACID 트랜잭션을 사용할 때보다 프로그래밍 모델이 더 복잡하다는 것입니다. 애플리케이션 수준의 장애를 복구하려면 보상 트랜잭션을 구현해야 하는 경우가 많습니다. 예를 들어 신용 확인에 실패하면 주문을 취소해야 합니다. 또한 애플리케이션은 일관되지 않은 데이터를 처리해야 합니다. 진행 중인 트랜잭션에서 변경된 내용이 노출되기 때문입니다. 아직 업데이트되지 않은 구체화된 뷰에서 데이터를 읽는 경우에도 애플리케이션에 불일치가 나타날 수 있습니다. 또 다른 단점은 구독자가 중복 이벤트를 감지하고 무시해야 한다는 것입니다.

원자성 달성

이벤트 기반 아키텍처에서는 데이터베이스 업데이트와 이벤트 발행을 원자적으로 처리해야 하는 문제도 있습니다. 예를 들어 주문 서비스는 ORDER 테이블에 행을 삽입하고 Order Created 이벤트를 발행해야 합니다. 이 두 작업은 반드시 원자적으로 수행되어야 합니다. 서비스가 데이터베이스를 업데이트한 후 이벤트를 발행하기 전에 중단되면 시스템의 일관성이 깨집니다. 원자성을 보장하는 일반적인 방법은 데이터베이스와 메시지 브로커가 참여하는 분산 트랜잭션을 사용하는 것입니다. 하지만 CAP 정리 등 앞서 설명한 이유로 인해 이는 바로 우리가 피하고자 하는 방식입니다.

로컬 트랜잭션을 사용한 이벤트 발행

원자성을 달성하는 한 가지 방법은 애플리케이션이 로컬 트랜잭션만 사용하는 다단계 프로세스를 통해 이벤트를 게시하는 것입니다. 핵심은 비즈니스 엔터티의 상태를 저장하는 데이터베이스에 메시지 큐 역할을 하는 EVENT 테이블을 두는 것입니다. 애플리케이션은 (로컬) 데이터베이스 트랜잭션을 시작하고, 비즈니스 엔터티의 상태를 업데이트하고, EVENT 테이블에 이벤트를 삽입한 다음 트랜잭션을 커밋합니다. 별도의 애플리케이션 스레드나 프로세스가 EVENT 테이블을 조회하고 이벤트를 메시지 브로커에 게시한 후, 로컬 트랜잭션을 사용하여 해당 이벤트를 게시된 것으로 표시합니다. 다음 다이어그램은 이 설계를 보여 줍니다.

주문 서비스는 ORDER 테이블에 행을 삽입하고 EVENT 테이블에 주문 생성 이벤트를 삽입합니다. 이벤트 게시자 스레드 또는 프로세스는 EVENT 테이블에서 게시되지 않은 이벤트를 조회하여 게시한 다음, 해당 이벤트가 게시되었음을 표시하도록 EVENT 테이블을 업데이트합니다.

이 접근 방식에는 몇 가지 장단점이 있습니다. 장점 중 하나는 2PC에 의존하지 않고도 각 업데이트에 대해 이벤트가 게시되도록 보장한다는 것입니다. 또한 애플리케이션이 비즈니스 수준의 이벤트를 게시하므로 이벤트를 추론할 필요가 없습니다. 단점은 개발자가 이벤트 게시를 잊지 않아야 하므로 오류가 발생할 가능성이 있다는 것입니다. 또한 일부 NoSQL 데이터베이스는 트랜잭션 및 쿼리 기능이 제한적이기 때문에 이 접근 방식을 구현하기 어렵다는 한계가 있습니다.

이 접근 방식에서는 애플리케이션이 로컬 트랜잭션을 사용해 상태를 업데이트하고 이벤트를 발행하므로 2PC가 필요하지 않습니다. 이제 애플리케이션이 단순히 상태를 업데이트하는 것만으로 원자성을 보장하는 접근 방식을 살펴보겠습니다.

데이터베이스 트랜잭션 로그 마이닝

2PC 없이 원자성을 달성하는 또 다른 방법은 데이터베이스의 트랜잭션 로그 또는 커밋 로그를 분석하는 스레드나 프로세스가 이벤트를 게시하도록 하는 것입니다. 애플리케이션이 데이터베이스를 업데이트하면 변경 사항이 데이터베이스의 트랜잭션 로그에 기록됩니다. 트랜잭션 로그 마이너 스레드 또는 프로세스는 트랜잭션 로그를 읽고 메시지 브로커에 이벤트를 게시합니다. 다음 다이어그램은 이 설계를 보여 줍니다.

이 접근 방식의 한 가지 예는 오픈 소스 LinkedIn Databus 프로젝트입니다. Databus는 Oracle 트랜잭션 로그를 분석하여 변경 사항에 해당하는 이벤트를 게시합니다. LinkedIn은 Databus를 사용해 다양한 파생 데이터 저장소를 기준 시스템과 일관되게 유지합니다.

또 다른 예로는 관리형 NoSQL 데이터베이스인 AWS DynamoDB의 스트림 메커니즘이 있습니다. DynamoDB 스트림에는 지난 24시간 동안 DynamoDB 테이블의 항목에 적용된 변경 사항(생성, 업데이트 및 삭제 작업)이 시간순으로 기록됩니다. 애플리케이션은 스트림에서 이러한 변경 사항을 읽어 이벤트로 게시하는 등의 작업을 수행할 수 있습니다.

트랜잭션 로그 마이닝에는 여러 장단점이 있습니다. 장점 중 하나는 2PC를 사용하지 않고도 각 업데이트에 대해 이벤트가 게시되도록 보장한다는 것입니다. 또한 이벤트 게시를 애플리케이션의 비즈니스 로직과 분리하여 애플리케이션을 단순화할 수 있습니다. 주요 단점은 트랜잭션 로그 형식이 데이터베이스마다 고유하며 데이터베이스 버전에 따라 변경될 수도 있다는 것입니다. 또한 트랜잭션 로그에 기록된 저수준 업데이트로부터 고수준 비즈니스 이벤트를 역으로 추론하기가 어려울 수 있습니다.

트랜잭션 로그 마이닝은 애플리케이션이 데이터베이스 업데이트라는 한 가지 작업만 수행하도록 함으로써 2PC의 필요성을 없앱니다. 이제 업데이트를 없애고 이벤트에만 의존하는 다른 접근 방식을 살펴보겠습니다.

이벤트 소싱 사용

이벤트 소싱은 비즈니스 엔터티를 영속화하는 방식으로 기존과는 완전히 다른 이벤트 중심 접근 방식을 사용하여 2PC 없이 원자성을 보장합니다. 애플리케이션은 엔터티의 현재 상태를 저장하는 대신 상태 변경 이벤트의 시퀀스를 저장합니다. 그리고 이벤트를 재생하여 엔터티의 현재 상태를 재구성합니다. 비즈니스 엔터티의 상태가 변경될 때마다 이벤트 목록에 새 이벤트가 추가됩니다. 이벤트 저장은 단일 작업이므로 본질적으로 원자적입니다.

이벤트 소싱의 작동 방식을 알아보기 위해 Order 엔터티를 예로 들어보겠습니다. 전통적인 접근 방식에서는 각 주문이 ORDER 테이블의 한 행과, 예를 들어 ORDER_LINE_ITEM 테이블의 여러 행에 매핑됩니다. 하지만 이벤트 소싱을 사용하면 Order Service는 Order를 상태 변경 이벤트인 Created, Approved, Shipped, Cancelled의 형태로 저장합니다. 각 이벤트에는 Order의 상태를 재구성하는 데 충분한 데이터가 포함됩니다.

이벤트는 이벤트 데이터베이스인 이벤트 스토어에 영구 저장됩니다. 이벤트 스토어는 엔터티의 이벤트를 추가하고 조회할 수 있는 API를 제공합니다. 또한 앞서 설명한 아키텍처의 메시지 브로커와 같은 역할도 합니다. 서비스가 이벤트를 구독할 수 있도록 API를 제공하며, 모든 이벤트를 해당 이벤트에 관심 있는 모든 구독자에게 전달합니다. 이벤트 스토어는 이벤트 기반 마이크로서비스 아키텍처의 중추입니다.

이벤트 소싱에는 여러 가지 이점이 있습니다. 이벤트 기반 아키텍처를 구현할 때 발생하는 핵심 문제 중 하나를 해결하며, 상태가 변경될 때마다 이벤트를 안정적으로 발행할 수 있게 해 줍니다. 따라서 마이크로서비스 아키텍처의 데이터 일관성 문제를 해결합니다. 또한 도메인 객체가 아닌 이벤트를 영속화하므로 대부분의 객체-관계형 임피던스 불일치 문제를 피할 수 있습니다. 이벤트 소싱은 비즈니스 엔터티에 적용된 변경 사항에 대해 100% 신뢰할 수 있는 감사 로그도 제공하며, 특정 시점의 엔터티 상태를 확인하는 시간 기반 쿼리를 구현할 수 있게 해 줍니다. 이벤트 소싱의 또 다른 주요 이점은 비즈니스 로직이 이벤트를 교환하는 느슨하게 결합된 비즈니스 엔터티로 구성된다는 점입니다. 따라서 모놀리식 애플리케이션에서 마이크로서비스 아키텍처로 훨씬 쉽게 마이그레이션할 수 있습니다.

이벤트 소싱에도 몇 가지 단점이 있습니다. 기존과는 다른 생소한 프로그래밍 방식이므로 익히는 데 시간이 필요합니다. 이벤트 저장소는 기본 키를 통한 비즈니스 엔터티 조회만 직접 지원합니다. 쿼리를 구현하려면 명령과 조회의 책임 분리(CQRS)를 사용해야 합니다. 따라서 애플리케이션은 최종적 일관성을 갖는 데이터를 처리해야 합니다.

요약

마이크로서비스 아키텍처에서는 각 마이크로서비스가 자체 전용 데이터 저장소를 갖습니다. 마이크로서비스마다 서로 다른 SQL 및 NoSQL 데이터베이스를 사용할 수 있습니다. 이러한 데이터베이스 아키텍처는 상당한 이점을 제공하지만, 분산 데이터 관리와 관련된 몇 가지 과제를 야기합니다. 첫 번째 과제는 여러 서비스에 걸쳐 일관성을 유지하는 비즈니스 트랜잭션을 구현하는 방법입니다. 두 번째 과제는 여러 서비스에서 데이터를 가져오는 쿼리를 구현하는 방법입니다.

많은 애플리케이션에서는 이벤트 기반 아키텍처를 사용하는 것이 해결책입니다. 이벤트 기반 아키텍처를 구현할 때의 과제 중 하나는 상태 업데이트와 이벤트 발행을 원자적으로 처리하는 방법입니다. 이를 구현하는 방법에는 데이터베이스를 메시지 큐로 사용하는 방식, 트랜잭션 로그 마이닝, 이벤트 소싱 등이 있습니다.

향후 블로그 게시물에서는 마이크로서비스의 다른 측면도 계속해서 자세히 살펴보겠습니다.

편집자 – 총 7부로 구성된 이 연재 기사가 이제 완결되었습니다:

1. 마이크로서비스 소개
2. 마이크로서비스 구축: API 게이트웨이 사용
3. 마이크로서비스 구축: 마이크로서비스 아키텍처의 프로세스 간 통신
4. 마이크로서비스 아키텍처의 서비스 디스커버리
5. 마이크로서비스를 위한 이벤트 기반 데이터 관리(이 글)
6. 마이크로서비스 배포 전략 선택
7. 모놀리스를 마이크로서비스로 리팩터링하기

전체 기사 모음과 NGINX Plus를 사용한 마이크로서비스 구현 정보를 전자책으로 다운로드할 수도 있습니다. 전자책 제목은 마이크로서비스: 설계부터 배포까지입니다. 또한 마이크로서비스 참조 아키텍처 시리즈와 마이크로서비스 솔루션 페이지도 확인해 보세요.

게스트 블로거 Chris Richardson은 최초의 CloudFoundry.com을 설립했습니다. 이 서비스는 Amazon EC2용 초기 Java PaaS(서비스형 플랫폼)였습니다. 현재 그는 여러 조직을 대상으로 애플리케이션 개발 및 배포 방식을 개선할 수 있도록 컨설팅하고 있습니다. 또한 http://microservices.io에서 마이크로서비스에 관한 글을 정기적으로 게시합니다.

작성자 소개

Chris Richardson

Chris Richardson의 다른 블로그 게시물