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

편집자 – 이 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. 주문 서비스는 신용 예약 이벤트를 사용하고 주문 상태를 OPEN으로 변경합니다.

   

더 복잡한 시나리오에는 고객의 신용을 확인하는 동시에 재고를 예약하는 것과 같은 추가 단계가 포함될 수 있습니다.

(a) 각 서비스가 데이터베이스를 원자적으로 업데이트하고 이벤트를 게시하고(나중에 자세히 설명함) (b) 메시지 브로커가 이벤트가 최소한 한 번은 전달되도록 보장한다면 여러 서비스에 걸쳐 비즈니스 트랜잭션을 구현할 수 있습니다. 이것들이 ACID 거래가 아니라는 점을 알아두는 것이 중요합니다. 그들은 최종 일관성 과 같은 훨씬 약한 보장을 제공합니다. 이 거래 모델은 BASE 모델 이라고 불린다.

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

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

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

원자성 달성

이벤트 기반 아키텍처에서는 데이터베이스를 원자적으로 업데이트하고 이벤트를 게시하는 문제도 있습니다. 예를 들어, 주문 서비스는 ORDER 테이블에 행을 삽입하고 주문 생성 이벤트를 게시해야 합니다. 이 두 가지 작업은 원자적으로 수행되는 것이 중요합니다. 데이터베이스를 업데이트한 후 이벤트를 게시하기 전에 서비스가 중단되면 시스템이 일관성을 잃게 됩니다. 원자성을 보장하는 표준적인 방법은 데이터베이스와 메시지 브로커를 포함하는 분산 트랜잭션을 사용하는 것입니다. 하지만 위에서 설명한 CAP 정리 등의 이유로 우리는 이런 일을 하고 싶지 않습니다.

로컬 트랜잭션을 사용하여 이벤트 게시

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

주문 서비스는 ORDER 테이블에 행을 삽입하고 EVENT 테이블에 주문 생성 이벤트를 삽입합니다. 이벤트 게시자 스레드 또는 프로세스는 게시되지 않은 이벤트에 대한 EVENT 테이블을 쿼리하고, 이벤트를 게시한 다음, EVENT 테이블을 업데이트하여 이벤트를 게시된 것으로 표시합니다.

이런 접근 방식에는 여러 가지 장점과 단점이 있습니다. 한 가지 이점은 2PC에 의존하지 않고도 각 업데이트에 대한 이벤트가 게시된다는 것입니다. 또한, 애플리케이션은 비즈니스 수준 이벤트를 게시하므로 이를 추론할 필요가 없습니다. 이 접근 방식의 한 가지 단점은 개발자가 이벤트를 게시해야 한다는 점을 기억해야 하므로 오류가 발생하기 쉽다는 점입니다. 이 접근 방식의 한계는 제한된 트랜잭션 및 쿼리 기능으로 인해 일부 NoSQL 데이터베이스를 사용할 때 구현하기 어렵다는 것입니다.

이 접근 방식에서는 애플리케이션이 로컬 트랜잭션을 사용하여 상태를 업데이트하고 이벤트를 게시하므로 2PC가 필요 없습니다. 이제 애플리케이션이 간단히 상태를 업데이트하여 원자성을 달성하는 접근 방식을 살펴보겠습니다.

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

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

이러한 접근 방식의 한 예가 오픈소스 LinkedIn Databus 프로젝트입니다. 데이터버스는 Oracle 트랜잭션 로그를 마이닝하고 변경 사항에 해당하는 이벤트를 게시합니다. LinkedIn에서는 Databus를 사용하여 다양한 파생 데이터 저장소를 레코드 시스템과 일관성 있게 유지합니다.

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

거래 로그 마이닝에는 다양한 장점과 단점이 있습니다. 한 가지 이점은 2PC를 사용하지 않고도 각 업데이트에 대한 이벤트가 게시된다는 것을 보장한다는 것입니다. 트랜잭션 로그 마이닝은 이벤트 게시를 애플리케이션의 비즈니스 로직에서 분리하여 애플리케이션을 단순화할 수도 있습니다. 가장 큰 단점은 트랜잭션 로그의 형식이 각 데이터베이스마다 다르고 데이터베이스 버전 간에도 변경될 수 있다는 것입니다. 또한, 거래 로그에 기록된 저수준 업데이트에서 고수준 비즈니스 이벤트를 역공학하는 것은 어려울 수 있습니다.

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

이벤트 소싱 사용

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

이벤트 소싱이 어떻게 작동하는지 알아보려면 Order 엔터티를 예로 들어 보겠습니다. 기존 방식에서는 각 주문이 ORDER 테이블의 행에 매핑되고, 예를 들어 ORDER_LINE_ITEM 테이블의 행에 매핑됩니다. 하지만 이벤트 소싱을 사용하는 경우 주문 서비스는 상태 변경 이벤트의 형태로 주문을 저장합니다. 생성됨, 승인됨, 배송됨, 취소됨. 각 이벤트에는 Order의 상태를 재구성하는 데 충분한 데이터가 포함되어 있습니다.

이벤트는 이벤트 데이터베이스인 이벤트 저장소에 보관됩니다. 이 저장소에는 엔터티의 이벤트를 추가하고 검색하기 위한 API가 있습니다. 이벤트 저장소는 이전에 설명한 아키텍처의 메시지 브로커와 마찬가지로 동작합니다. 서비스가 이벤트를 구독할 수 있도록 하는 API를 제공합니다. 이벤트 스토어는 모든 이벤트를 관심 있는 모든 구독자에게 전달합니다. 이벤트 스토어는 이벤트 기반 마이크로서비스 아키텍처의 중추입니다.

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

이벤트 소싱에도 몇 가지 단점이 있습니다. 이것은 다르고 익숙하지 않은 프로그래밍 스타일이기 때문에 배우는 데 시간이 걸립니다. 이벤트 저장소는 기본 키를 사용하여 비즈니스 엔터티를 조회하는 것만 직접적으로 지원합니다. 쿼리를 구현하려면 CQRS( Command Query Responsibility Segregation )를 사용해야 합니다. 결과적으로 애플리케이션은 결과적으로 일관된 데이터를 처리해야 합니다.

요약

마이크로서비스 아키텍처에서 각 마이크로서비스는 자체 개인 데이터 저장소를 갖습니다. 다양한 마이크로서비스는 서로 다른 SQL 및 NoSQL 데이터베이스를 사용할 수 있습니다. 이 데이터베이스 아키텍처는 상당한 이점이 있지만, 분산 데이터 관리 측면에서 몇 가지 과제를 초래합니다. 첫 번째 과제는 여러 서비스에서 일관성을 유지하는 비즈니스 거래를 구현하는 방법입니다. 두 번째 과제는 여러 서비스에서 데이터를 검색하는 쿼리를 구현하는 방법입니다.

많은 애플리케이션의 경우, 이벤트 기반 아키텍처를 사용하는 것이 솔루션입니다. 이벤트 기반 아키텍처를 구현하는 데 있어 한 가지 과제는 상태를 원자적으로 업데이트하고 이벤트를 게시하는 방법입니다. 이를 달성하는 방법에는 데이터베이스를 메시지 큐로 사용하거나, 트랜잭션 로그 마이닝, 이벤트 소싱을 사용하는 것 등이 있습니다.

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

편집자 – 이 7부작 시리즈 기사는 이제 완료되었습니다.

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

NGINX Plus를 사용하여 마이크로서비스를 구현하는 것에 대한 정보와 더불어 전체 문서 세트를 전자책으로 다운로드할 수도 있습니다. – 마이크로서비스: 설계부터 배포까지 . 그리고 마이크로서비스 참조 아키텍처 와 마이크로서비스 솔루션 페이지 에 대한 시리즈를 확인하세요.

게스트 블로거 크리스 리처드슨은 Amazon EC2를 위한 초기 Java PaaS(서비스형 플랫폼)인 CloudFoundry.com 의 창립자입니다. 그는 현재 기업들과 협의해 애플리케이션을 개발하고 배포하는 방법을 개선하기 위해 노력하고 있습니다. 그는 또한 http://microservices.io 에서 마이크로서비스에 관해 정기적으로 블로그를 운영하고 있습니다.