[MSA] Asynchronous Backing Service

본 포스팅에서는 서비스 간 비동기 통신, 이벤트 전달 등을 담당하는 Backing Service에 대해 알아보자.

Backing Service는 서비스 간 약 결합을 통해 각 서비스에서 발생한 이벤트를 다른 이벤트로 전파하지 않고자 등장한 MSA Component이다.

마이크로서비스가 각 서비스 간 독립성을 보장한다 하더라도 서비스간 요청은 발생할 수 있으며, 이로 인한 장애 전파는 여전히 발생할 수 있다. 이를 위해 우리는 중계 역할을 하는 Backing 서비스를 통해 비동기 방식으로 이벤트를 전달하여 각 서비스간 독립성을 여전히 유지할 수 있다.

Message Queue와 같은 Backing Service를 사용하지 않는 강한 결합 구조의 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때, 하나의 서비스가 죽어버린다면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없고 전체 서비스에 장애가 발생한다.

또한, REST 통신으로 트랜잭션 실패에 대한 처리를 구현하는 방법은 굉장히 복잡하다.
이로 인해 MSA에서 데이터 변경이나, 보상 트랜잭션과 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적이다.

이를 만족하기 위해 비동기식 Message-Driven 또는 Event-Driven Architecture를 사용할 필요가 있다. 이러한 통신을 위해 다음과 같은 메시지 브로커 또는 이벤트 브로커가 필요하다.

• Apache ActiveMQ, Apache Kafka, NSQ, RabbitMQ

상태가 없는 휘발성의 마이크로 서비스는 애플리케이션 상태를 관리하고 비동기 통신 지원을 제공하기 위해 데이터 지속성 및 메시징 서비스에 액세스해야 한다.

• 데이터 지속성 서비스는 서로 서비스 분리를 ​​지원하는 방식으로 제공되어야하므로 각 서비스 DevOps 팀은 데이터 지속성의 설계 및 구조에 대해 독립적인 결정을 내릴 수 있다.

• 메시징 브로커 서비스는 보다 전통적인 메시지 지향 통신뿐만 아니라 이벤트 중심의 Publish-Subscribe 통신 패턴에 필요한 메시지 내구성 및 분배 기능을 제공한다.

이러한 서비스는 백업을 위한 별도의 공간이 마련되어야 한다. 백업 서비스는 다음 세 가지 방법 중 하나로 제공 될 수 있다.

• 외부 서비스 — 마이크로 서비스 플랫폼과 독립적으로 호스팅되며 관리된다. 마이크로 서비스에서 백킹 서비스로의 연결은 다른 원격 연결과 마찬가지로 독립적인 프로비저닝, 보안 자격 증명 관리 및 네트워크 액세스가 필요하다.

   

• 중개 서비스 — 외부에서 호스팅되지만 플랫폼과 통합된다 (예 : Open Service Broker 인터페이스 사용). Service DevOps 팀은 사전 구성된 플랫폼 통합을 통해 이러한 서비스의 수명주기를 프로비저닝, 연결 및 관리 할 수 ​​있다. 응용 프로그램 코드는 백업 서비스를 외부에서 호스팅하는 것과 동일한 기술 또는 서비스로 취급한다.

   

• 호스팅 서비스 — 플랫폼 자체에서 호스팅되고 다른 서비스로 관리된다. 호스팅 서비스는 플랫폼 팀에서 공유 리소스로 또는 서비스 DevOps 팀에서 서비스 별 리소스로 관리 할 수 있다.

마이크로 서비스 플랫폼의 일부로 데이터 지속성 서비스를 제공하는 데 사용할 수있는 기술 및 서비스의 예는 다음과 같다.

• 관계형/NoSQL 데이터베이스 - Apache Cassandra, Apache CouchDB, Couchbase, IBM DB2, Microsoft SQL Server, MariaDB, MongoDB, Oracle MySQL, Oracle Database, PostgreSQL, Redis

   

• Database platform as a Service (dbPaaS) - Amazon Aurora, Amazon DynamoDB, Amazon RDS, Google Cloud SQL, Google Cloud Spanner, IBM Cloudant, Microsoft Azure Cosmos DB, Microsoft Zaure SQL Database, Oracle Database Cloud Service

마이크로 서비스 플랫폼의 일부로 이벤트 중심 및 메시지 중심 통신 서비스를 제공하는 데 사용할 수있는 기술 및 서비스의 예는 다음과 같다.

• 메시지 및 이벤트 브로커 소프트웨어 - Apache ActiveMQ, Apache Kafka, IBM MQ, Pivotal RabbitMQ, Nats, Red Hat JBoss AMQ

• 메시징 및 이벤트 브로커 서비스 - Amazon Kinesis, Amazon Simple Queue Service / Simple Notification Service, Microsoft Azure Event Hubs, Microsoft Azure Event Grid, Microsoft Azure Service Bus, Google Pub / Sub, IBM Message Hub, Oracle Event Hub Cloud Service

용도

Backing Service는 데이터의 지속성과 일관성 있는 처리를 위해 동작한다. Backing Service는 다음과 같은 용도로 사용될 수 있다.

• Service Mesh로서의 역할 : 빈번한 호출이 일어나는 두 서비스 간 매 호출 마다 REST API 호출이 발생할 경우 자원 낭비를 효율적으로 처리하고자 Backing Service를 구현하여 대체한다.

• 데이터 복제 : 서로 다른 서비스가 관리하는 Data Store 간의 데이터를 동기화 해야 할 경우 Backing Service를 구현한다.

• 비동기 : 마이크로서비스의 복잡한 흐름에서 상호간 비동기로 처리되어야 하는 서비스 간에 Backing Service를 구현하여 서비스 결합도를 낮추고 성능을 확보한다.(ex : Choreography - 물건을 구매하는 서비스와 결제를 위해 카드사로 요청하는 서비스를 구분하여 관리, 결제 시 결제가 완료되었다는 메시지를 전달 받음. 카드사 요청(연계) 중 장애가 발생하였을 경우 서비스 결제가 완료된 상태에서도 문제 알림메시지(확인 결과 잔액 부족으로 결제가 취소되었습니다.와 같은 형태)를 전달하고, 보상트랜잭션을 수행하여 이전 상태로 돌리는 로직)

• 반 정규화 데이터의 동기 처리 : 특정 이벤트를 발생 시킨 서비스는 Event Store(현재 데이터의 상태는 이벤트를 의미하며, 이벤트를 누적하는 것을 이벤트 로그라고 한다. 이때 이벤트 로그를 저장하는 공간을 이벤트 스토어라 한다.)를 통해 반 정규화 과정을 거쳐야 하는 데이터를 저장(이벤트를 발생 - Puclish)하고, 이와 같은 이벤트로 인해 반 정규화 과정을 진행해야 하는 또 다른 서비스를 이벤트를 구독(Subscribe)하여 변경사항을 반영한다.

• 트랜잭션 관리 : MSA에서는 서로 다른 서비스에 직접 접근이 불가능하다. 이는 이미 완료된 서비스가 포함된 트랜잭션에 장애가 발생했을 경우 기존 Legacy와 같이 Rollback을 수행할 수 없다는 의미이다. 이때 Backing Service는 이벤트 스토어를 통해 Rollback 또는 Retry를 진행할 수 있다. Rollback이 필요한 경우 Failed Event를 발생하고 이를 구독하는 서비스에서 해당 메시지 발생 시 일괄 Rollback을 진행하는 방식이다. Retry가 필요한 경우 MQ의 Requeue 또는 dead letter queue 기능을 사용해 retry 처리를 진행할 수 있다.

• Eventually Consistency(일관성) : 기존의 DBMS 활용한 ACID 트랜잭션에 따른 데이터 무결성 보장은 MSA에서 서비스, Database가 나눠짐으로써 더이상 달성할 수 없다. 대신 Event Driven Architecture를 사용해 데이터의 최종적인 일관성을 유지할 수 있다. (all commit or rollback - eventually consystency)

적용방식

A. Tightly Coupled System

위와 같이 강결합 상태의 서비스는 장애의 전파로 인해 전체적인 서비스 장애가 발생할 수 있다.

B. Loosely Coupled System

위와 같이 Message Broker를 기반으로 전송하는 서비스1과 수신하는 서비스2간의 결합도를 낮춰 한 시스템의 상태가 다른 시스템에 영향을 주지 않도록 하는 것이 좋다.

시스템의 직접 통신을 분리하여 서비스간 결합도가 낮아져 개별 확장성을 높이고, 장애를 격리시켜 안정성을 확보할 수 있다.

a. Message Queueing

Message Queue 패턴은 비동기식으로 단순한 메시지를 전송하기에 적합하다. Message Queue는 수신하는 마이크로서비스의 정보를 알고 있으며, 각 메시지는 수신자에게 1:1(point-to-point)로 전송된다.

b. Competing Consumers

Competing Consumers 패턴은 다수의 메시지를 분산처리하기에 적합하다. 다수의 메시지를 처리량에 따라 유연하게 분배할 수 있으며, 소비자의 확장성을 높여 높은 성능으로 처리할 수 있다. 다만 여전히 각 메시지는 수신자에게 1:1(point-to-point)로 전송된다.

c. publisher/subscriber

메시지를 게시하면(Publisher), 관심있는 모든 구독자가 메시지를 받는 방식이다. 가용성과 확장성이 좋으며, point-to-multipoint 방식으로 전송된다. Message Queue도 게시자와 수신자의 정보를 알 필요가 없으며, 메시지가 수신자에게 도착하면 게시자에게 알림이 전송되는 방식이다. 이때 메시지는 구독자에 의해 전송되지 않을 경우 메시지 큐에 무기한 대기할 수 있다.

C. AWS Message Queue

a. Amazon SQS (Simple Queue Service)

Amazon SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 Message Queue이다.

여러 az에 걸친 메시지 저장, 수백만의 메시지 저장 및 다수의 발신/수신 가능, 높은 성능, 값싼 비용등의 장점이 있다.

FIFO 대기열은 1번의 전달을 정확히 보장하며, 저장된 순서대로 메시지를 꺼낼 수는 있도록 보장한다.

또한 배치로 효율적인 메시지 송수신이 가능하다. 한번에 최대 10건까지 전송 가능하며 절대적인 요청이 줄어들어 비용 절감효과가 있다.

메시지가 수신측으로 Push 되지 않아 Consumer가 별도로 Pull하도록 처리해야 하며, 하나의 메시지가 여러 Consumer에게 전달 될 수 없다.

무제한의 Throughput과 Queue를 지원하지만 Pub/Sub(Topic)은 지원하지 않는다. 또한 Text 메시지만 지원 가능하며, 요청수 + 데이터 전송 기반 과금정책이 정해진다.

Application 통합, 분산 시스템을 연계하고, 개별 메시지 별로 확인/실패가 필요한 경우 적합하다.

b. Amazon SNS (Simple Notification Service)

Amazon SNS는 마이크로서비스 분산 시스템 및 서버리스 애플리케이션을 위한 Pub/Sub 메시징 및 모바일 알림 서비스이다.

SQS와 같이 높은 가용성과 모바일, HTTP/HTTPS, Email, SMS, SQS, Lambda 등으로 Push 할 수 있다.

거의 무한대의 처리량과 저비용으로 이용가능하다.

Push 형 서비스로 Consumer는 별도로 pull 또는 polling 할 필요가 없다. 또한 모든 메시지를 수신 받지 않도록 각 Consumer는 필터링을 구성하여 적용한다. 이는 즉 모든 메시지가 Consumer에게 전송 된 이후 수신자 측에서 메시지를 필터링 한다는 의미로 곧 모든 메시지가 모든 Consumer에게 전송되는 문제가 있다.

이를 해결하기 위해 Topic 기반 필터링을 적용하여 초기 전송 시 Amazon SNS Topic 을 구분하여 메시지를 전송하는 것이 효과적이다.

물론 이와 같은 방식도 Amazon SNS가 무한으로 늘어 날 수 없어 Attribute 기반 필터링을 적용하는 것이 좋다.

메시지가 수신측으로 자동 Push되며 하나의 메시지는 여러 수신자에게 전달 가능하다.

c. Amazon MQ

 

Amazon MQ는 클라우드에서 메시지 브로커를 쉽게 설정하고 운영할 수 있게 해주는 Apache ActiveMQ용 관리형 메시지 브로커이다.

JMS, NMS, MQTT, AMQP, STOMP, WebSocket 등의 표준과 호환되며, Active MQ 기반 JMS 스펙을 완전히 지원한다.

Queue, Topic을 모두 지원하고, FIFO를 완전히 지원한다. Legacy Active MQ와 완전히 호환 가능하여 on-premise와 Cloud를 연결하여 사용할 수 있다.

업계 표준, Protocol을 지원하며 Queue, Topic 모두 지원한다. 바이너리 메시지를 지원하고 사이즈 제약이 없다. 인스턴스, 스토리지, 데이터 전송 기반 과금정책이 정해진다.

d. Amazon Kinesis Data Stream

Amazon Kinesis Data Stream은 대규모 데이터의 실시간 처리를 위한 스트리밍 데이터 수집 서비스로 Partition key 값을 기준으로 Kinesis Data Stream 내 Shard를 결정한다.

Shard 내에서 순서를 보장하며, 각 Consumer 별 독자적인 Data를 읽고 처리할 수 있다. Data를 삭제 하는 API가 없어 보존 기간 단위로 자동 삭제된다.

Consumer는 별도의 설정 없이 자동으로 동작하여 확장성이 높으며 처리량을 증가 시키기 용이하다.

로그, 모바일, Click Stream 데이터 수집/분석 등 실시간 분석에 용이하다. 여러 애플리케이션이 하나의 스트림을 동시에 사용하며 처리된 메시지를 다른 애플리케이션 다시 처리해야 하는 경우 적용이 용이하다.

#정리

• SQS는 Pull 형 Queue 서비스이고, SNS는 Push 형 Topic 서비스
• 신규 애플리케이션은 Amazon SQS를 우선 고려, Migration은 Amazon MQ를 우선 고려
• Kinesis Data Streams는 빅데이터 스트림의 실시간 처리에 적합하고, SQS는 분산 시스템 간의 메시지 전송에 적합

결론

Backing Service는 데이터의 지속성과 일관성 있는 처리를 위해 동작한다. 앞서 살펴본 여러가지 이유 중 하나의 사유로 인해 우리는 Backing Service를 Cloud 또는 Microservices 환경에 적용할 수 있다. 마이크로서비스와 클라우드는 장점에 가려져 사실 커다란 문제점을 내포하고 있는 설계 방식이자 기술이다. 이러한 기술을 보완하고 보다 완벽한 기술로 거듭나게 하는 것이 Backing 서비스이며, 원하는 요건이 내가 설계하고 있는 시스템에 과연 적합한 방식인가? 를 고민해 보고 아키텍처 설계 및 구축 과정에 적용하는 것이 좋을 것이다.