마이크로서비스를 공부하면 메시지 기반의 느슨한 결합이라는 키워드를 확인할 수 있습니다.
메시지 큐와 메시지 브로커라는 개념이 사용되며 그 유명한 "아파치 카프카"가 등장합니다.
아파치 카프카는 왜 쓰는지 궁금하여 MSA 통신 패턴에 대해서 공부해보려고 합니다.
마이크로서비스 통신 패턴
동기 통신 방식
동기(synchronous) 방식은 요청(request)하면 바로 응답(response)이 오는 방식을 말한다.
바로 요청하면 응답이 오는 직관적인 방식이기 때문에 가장 많이 쓰이고 구현하기 쉽다. 그렇지만 호출을 받은 마이크로서비스에 장애가 생긴다면 어떻게 될까? 요청을 보낸 서비스는 반응이 올 때까지 기다리게 되고, 반응이 오지 않으면 계속 기다리면서 재호출하게 된다.
여러 서비스 간의 연계를 통해 업무를 처리하는 마이크로서비스 구조에서는 이 같은 상황에서 장애가 연쇄적으로 발생할 수 있다.
또 서비스가 다른 서비스를 호출해서 얻은 정보를 이용해 기능을 제공한다는 의미는 해당 서비스 간의 의존관계가 높다는 것을 의미한다.
이러한 방식의 서비스 제공은 독자적인 마이크로서비스별로 비즈니스 기능 처리를 어렵게 만든다. 따라서 장애의 파급 효과 및 의존 관계를 낮추기 위한 다른 통신 방법이 필요하다.
비동기 통신 방식
메시지 기반의 비동기(asynchronous) 호출이며 동기 호출처럼 응답을 기다리지 않고 다음 일을 처리한다.
물론 보낸 결과가 어떻게 됐는지 응답을 받지 않으므로 동기식처럼 완결성을 보장할 수는 없다.
이를 보장하기 위한 메커니즘으로 아파치 카프카(Apache Kafka), 래빗엠큐(RabbitMQ), 액티브엠큐(ActiveMQ) 같은 메시지 브로커(Message broker)를 활용한다.
메시지를 보내는 생산자(producer)와 메시지를 가져다가 처리하는 소비자(consumer)가 서로 직접 접속하지 않고 메시지 브로커에 연결된다. 메시지 브로커에 메시지를 전달하고 자신의 일을 처리하면 메시지 브로커가 전송을 보장하게 된다.
그런데 여러 서비스에서 전달한 메시지를 처리하는 메시지 브로커 자체에 부하가 생길 수가 있다. 이 경우 메시지 브로커는 메시지 처리 규모에 따라 확장이 가능하다.
이 방식은 메시지 브로커에 의해 중계되기 때문에 서로 통신하는 서비스들이 물리적으로 동일한 시스템에 위치할 필요도 없고 서로 프로세스를 공유할 필요도 없으며, 심지어 동일한 시간대에 동시에 동작하지 않아도 된다. 따라서 서비스 요구에 따라 늘어나거나 줄어들 수 있는 탄력성이 높은 클라우드 플랫폼 환경에서 서비스가 다운됐을 때 또는 시스템을 더 확장해야 할 때 사용할 수 있는 매우 효과적인 방법이다.
비동기 방식의 이벤트 기반 아키텍처
비동기 통신 방식을 이용해 느슨한 연계를 지향하는 아키텍처가 있다. 이벤트에 반응한다는 의미로 이벤트 기반 아키텍처(event driven architecture)라고 부르는데, 이벤트 기반 아키텍처는 예전부터 사용된 개념으로서 분산 시스템 간에 발신자가 이벤트를 생성 및 발행(publish)하고, 해당 이벤트를 필요로 하는 수신자에게 전송하면 이벤트를 구독하고(subscribe) 있던 수신자가 이벤트를 받아 처리하는 형태의 시스템 아키텍처이다.
여기서 이벤트는 '상태의 변화'를 의미하며, 기존의 순차적 방식의 아키텍처와 달리 특정 행동이 자동으로 순서에 따라 발생하는 것이 아닌 어떤 상태의 변경에 대한 반응으로 동작한다는 점이 차이점이다.
이벤트 기반 아키텍처는 이벤트를 생산하는 모듈과 이벤트에 대응하는 모듈을 분리하고 상호 독립적으로 동작하게 함으로써 병렬 처리를 촉진한다. 또한 이러한 이벤트 기반 아키텍처의 전달 메커니즘으로 앞에서 논의한 비동기 메시지 메커니즘을 선택하면 더욱더 효과적이다.
이벤트 기반의 아키텍처와 비동기 통신 메커니즘을 함께 사용하는 마이크로서비스를 이벤트 기반 마이크로서비스(event-driven microservice)라고도 한다. 이벤트 메시지를 사용하면 발신자와 수신자를 장소와 시간에서 쉽게 분리할 수 있으며, 마이크로서비스가 추구하는 느슨한 결합으로 확장성, 탄력성 측면세어 이점이 많다.
아파치 카프카
Apache Kafka는 빠르고 확장 가능한 작업을 위해 데이터 피드의 분산 스트리밍, 파이프 라이닝 및 재생을 위한 실시간 스트리밍 데이터를 처리하기 위한 목적으로 설계된 오픈 소스 분산형 게시-구독 메시징 플랫폼입니다.
Kafka는 서버 클러스터 내에서 데이터 스트림을 레코드로 유지하는 방식으로 작동하는 브로커 기반 솔루션입니다.
Kafka 서버는 여러 데이터 센터에 분산되어 있을 수 있으며 여러 서버 인스턴스에 걸쳐 레코드 스트림(메시지)을 토픽으로 저장하여 데이터 지속성을 제공할 수 있습니다. 토픽은 레코드 또는 메시지를 키, 값 및 타임 스탬프로 구성된 일련의 튜플, 변경 불가능한 Python 객체 시퀀스로 저장합니다.
Apache Kafka의 사용 사례
Apache Kafka는 오늘날 시장에서 가장 빠르게 성장하는 오픈 소스 메시징 솔루션 중 하나입니다. 이는 주로 분산 시스템에 우수한 로깅 메커니즘을 제공하는 아키텍처 기반 설계 패턴 때문입니다.
실시간 로그 스트리밍을 위해 특별히 제작된 Apache Kafka는 다음 사항을 필요로 하는 애플리케이션에 적합합니다.
- 서로 다른 구성 요소 간의 안정적인 데이터 교환
- 애플리케이션 요구 사항 변경에 따라 메시징 워크로드를 분할하는 기능
- 데이터 처리를 위한 실시간 스트리밍
- 데이터/메시지 재생에 대한 기본 지원
Apache Kafka의 개념
토픽(Topic)
- 게시/구독 메시징에서 상당히 보편적인 개념
- Apache Kafka및 기타 메시징 솔루션에서 토픽은 지정된 데이터 스트림(일련의 레코드/메시지)에 대한
관심을 표시하는 데 사용되는 주소 지정 가능한 추상화 - 게시 및 구독할 수 있으며 애플리케이션에서 주어진 데이터 스트림에 대한 관심을 표시하는 데
사용하는 추상화 계층
파티션(Partition)
- Apache Kafka에서 토픽은 파티션이라는 일련의 순서 대기열로 세분화될 수 있음
- 파티션은 연속적으로 추가되어 순차적 커밋 로그를 형성
- Kafka 시스템에서 각 레코드/메시지에는 지정된 파티션의 메시지 또는 레코드를 식별하는 데 사용되는
오프셋이라는 순차 ID가 할당됨
영속성(Persistence)
- Apache Kafka는 레코드/메시지가 게시될 때 지속적으로 유지하는 서버 클러스터를 유지 관리하여 작동
- Kafka 클러스터는 구성 가능한 보존 시간 제한을 사용하여 소비에 관계없이 주어진 레코드가 지속되는
기간을 결정 - 레코드/메시지가 보존 시간 제한 내에 있는 동안 레코드/메시지를 사용할 수 있음
- 레코드/메시지가 이 보존 시간 제한을 초과하면 레코드/메시지가 삭제되고 공간이 확보됨
토픽/파티션 확장
- Apache Kafka는 서버 클러스터로 작동하기 때문에 주어진 토픽/파티션에서 각 서버에 부하를 공유하여
토픽/파티션을 확장할 수 있음 - 부하 공유를 통해 Kafka 클러스터의 각 서버는 주어진 토픽/파티션에 대한 레코드/메시지의 배포 및 영속성을
처리할 수 있음 - 개별 서버가 모든 배포 및 영속성을 처리하는 동안 모든 서버는 서버가 실패할 경우 내결함성과 고가용성을
제공하는 데이터를 복제 - 파티션은 파티션 리더로 선택된 한개 서버와 팔로워 역할을 하는 다른 모든 서버들로 분할됨
- 파티션 리더인 서버는 데이터의 모든 배포 및 영속성(읽기/쓰기)을 처리하고 팔로워 서버는 내결함성을 위한
복제 서비스를 제공
프로듀서(Producer)
- Apache Kafka에서 프로듀서 개념은 대부분의 메시징 시스템과 다르지 않음
- 데이터(레코드/메시지) 프로듀서는 주어진 레코드/메시지가 게시되어야 하는 토픽(데이터 스트림)을 정의
- 파티션은 추가 확장성을 제공하는 데 사용되므로 프로듀서는 주어진 레코드/메시지가 게시되는
파티션도 정의할 수 있음 - 프로듀서는 주어진 파티션을 정의할 필요가 없으며 파티션을 정의하지 않음으로써 토픽 파티션에서
순차 순환 대기 방식의 로드 밸런싱을 달성할 수 있음.
컨슈머(Consumer)
- 대부분의 메시징 시스템과 마찬가지로 Kafka의 컨슈머는 레코드/메시지를 처리하는 엔티티
- 컨슈머는 개별 워크로드에서 독립적으로 작업하거나 지정된 워크로드에서 다른 컨슈머와 협력하여
작업하도록 구성할 수 있음(로드 밸런싱) - 컨슈머는 컨슈머 그룹 이름을 기반으로 워크로드를 처리하는 방법을 관리함
- 컨슈머 그룹 이름을 사용하면 컨슈머를 단일 프로세스 내, 여러 프로세스, 심지어 여러 시스템에 분산 가능
- 컨슈머 그룹 이름을 사용하여 컨슈머는 컨슈머 집합 전체에서 레코드/메시지 소비를
로드 밸런싱(동일한 컨슈머 그룹 이름을 가진 여러 컨슈머)하거나 토픽/파티션을 구독하는 각 컨슈머가
처리 메시지를 받도록 각 레코드/메시지를 고유하게 (고유한 컨슈머 그룹 이름을 가진 여러 컨슈머)
처리할 수 있음
아파치 주키퍼
주키퍼는(Zookeeper)는 분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트입니다.
이러한 애플리케이션의 목적은 개발자가 코디네이션 로직보다는 비즈니스 핵심 로직에 집중하게끔 지원하는
역할을 합니다.
주키퍼는 Leader Follower로 구성되는 Master-Slave 아키텍처를 기반으로 구성되어 있습니다.
이것을 기반으로 여러 주키퍼 서버로 이루어진 앙상블(Ensemble), 앙상블 데이터의 불일치를 방지하고자 하는
쿼럼(Quorum) 그리고 분산 데이터 시스템인 znode로 이루어진 주키퍼 데이터 모델(zookeeper data model)이
주키퍼를 구성하게 됩니다.
주키퍼는 znode로 이루어진 분산 데이터 모델을 지원하는 시스템이라고 해도 과언이 아닙니다.
이 데이터 모델은 리눅스(linux) 파일시스템과 유사한 시스템을 제공하고 이것이 주키퍼의 핵심입니다.
주키퍼에 채택된 아키텍처와 기법들은 이 데이터 모델을 안정적으로 제공하고자 하기 위함입니다.
이 시스템을 통해 주키퍼는 글로벌락, 클러스터 정보, Leader 선출 등을 구현해야 하는 곳에 활용할 수 있습니다.
이러한 목적으로 Hbase, Kafka, Hadoop, Kubernetes와 같은 인기 오픈소스 프로젝트에서도 분산 코디네이션 시스템을
구현하기 위해 주키퍼를 채택했습니다.
실습
목적
- 스프링 프로젝트를 이용하여 카프카에 메시지 생산(Produce) 및 소비(Consume) 테스트
개발환경
- java 1.8, spring boot, gradle
- docker / image: bitnami/kafka, bitnami/zookeeper
결과
- 샘플 코드를 작성하여 Consumer와 Producer를 Bean으로 만들고, Runnable을 구현한 Consumer는 Threaed로 생성하여 애플리케이션이 종료될 때까지 consumer.poll()메소드를 통해 ConsumerRecord를 소비
- 기존 스프링 MVC와 RDS를 연동하여 사용을 하면 데이터베이스에 테이블 별로 Repository클래스를 생성하여 비즈니스 로직을 구현하였는데, 마찬가지로 Producer와 Consumer도 토픽별로 생성을 해야 비동기 통신을 구현할 때 원하는 데이터를 소비하여 비즈니스 로직을 처리할 것으로 보임
개선점
- Producer에서 생산한 메시지는 한 개인데 Consumer에서 복수의 메시지를 수신하는 경우가 있었음
- 해당 문제가 이전에 보낸 모든 메시지를 다 소비해서 나타난 문제인지는 확인이 필요하지만 설정이 문제라면
고쳐야 함. 그리고 설정 문제인 것이라 생각이 됨
참고
도서
- 도메인 주도 설계로 시작하는 마이크로서비스 개발
URI
- https://www.tibco.com/ko/reference-center/what-is-apache-kafka
Apache Kafka 란 무엇인가요?
홈 Reference Center 관련 용어 Apache Kafka 란 무엇인가요? Apache Kafka는 빠르고 확장 가능한 작업을 위해 데이터 피드의 분산 스트리밍, 파이프 라이닝 및 재생을 위한 실시간 스트리밍 데이터를 처리하
www.tibco.com
- https://engkimbs.tistory.com/660
[주키퍼, Zookeeper] 아파치 주키퍼(Apache Zookeeper) 소개 및 아키텍처
| 대규모 분산 시스템과 코디네이션 시스템의 필요성? 과거에는 한 대의 컴퓨터에서 동작하는 단일 프로그램이 대다수였지만, 현재 빅데이터와 클라우드 환경에서 대규모의 시스템들이 동작
engkimbs.tistory.com
'[개발] Infrastructure > Deployment' 카테고리의 다른 글
| Hystrix (0) | 2023.11.30 |
|---|---|
| 사가 패턴 (0) | 2023.11.27 |
| 카나리아 배포 (0) | 2023.11.17 |
| Docker 블루-그린 배포 (0) | 2023.11.17 |
| MSA(Micro Service Architecture) 기본 개념 (0) | 2022.02.26 |
