AWS 완전관리형 서비스로 Kafka 서비스 이용하기

서론

앞서 마이크로서비스 아키텍처에서 비동기 서비스 / DB동기화 / CQRS 등의 요건등을 처리하기 위해 Kafka를 이용하는 방법에 대해 알아보았다. 해당 포스팅은 다음에서 확인할 수 있다.

[② 클라우드 마스터/ⓜ MSA] - Kafka(Zookeeper) 아키텍처

[② 클라우드 마스터/ⓜ MSA] - Kafka(Zookeeper) 구축

[② 클라우드 마스터/ⓜ MSA] - Kafka(Zookeeper) Pub/Sub SpringBoot Application 개발가이드

본 포스팅에서는 Kafka 서비스를 제공하는 AWS MSK에 대해 알아보자.

---

MSK Cluster 생성

우리는 마이크로서비스 환경에서 세분화된 서비스 호출흐름으로 인해 일부 성능 저하 및 심각한 병목 현상을 겪을수 있다. 이를 해소하기위해 수직적인 호출 흐름을 비동기로 수평된 호출을 가져갈 수 있도록 Kafka, RabbitMQ와 같은 Message Queue 서비스를 구축하고 운영한다. 다만, 오픈소스 버전의 Kafka를 구성하게 될 경우 운영관리, 보안, 가용성 등에 많은 노력을 기울여야한다. AWS에서는 Amazon MSK (Amazon Managed Streaming for Apache Kafka)로 몇분만에 이를 완벽히 지원하는 완전관리형 Kafka 서비스를 구성할 수 있다.

a. Create Cluster

 

 

b. Choose cluster creation method & General & Configuration

 

 

- Choose cluster creation method > Create cluster with custom settings (설정을 직접구성하기 위해 Custom Setting 선택)

- General > Cluster name (NRSON-MSK)

- General > Apache Kafka version (2.2.1 recommended)

- Configuration (Use the MSK default configuration)

c. Networking

 

 

- Networking > VPC (MSK가 설치되는 VPC와 VPC가 배치 된 AZ 수 지정)

d. Brokers & Tags & Storage

 

 

- Brokers (Kafka Broker로 등록될 인스턴스의 type과 각 az별로 배치 될 Broker의 수를 지정한다. az가 2개일 경우 Number of brokers per Availability Zone이 2이면 총 4개의 broker가 생성된다.)

e. Storage & Encryption

 

 

- Storage (Broker당 할당할 EBS 볼륨 사이즈를 지정한다. EBS 사이즈는 초기 할당량에서 줄일 수 없으며, 사용률에 따라 자동 확장하도록 구성할 수 있음)

- Encryption > Encrypt data in transit (TLS를 이용하여 클러스터 내 암복호화 여부 결정)

- Encryption > Encrypt data at rest (CMK를 이용하여 클러스터 외부 Client 데이터 암복호화 키 관리 방식)

 

 

- Authentication (TLS를 사용하지 않으면 None으로 선택됨)

f. Monitoring

 

 

- Amazon CloudWatch metrics for this cluster (CloudWatch를 통해 수집할 메트릭을 수준을 결정한다. Basic의 경우 무료로 지원되며 보다 향상된 정보를 표출하고자 할 경우 다른 선택조건을 선택한다.)

- Open monitoring with Prometheus (Prometheus 모니터링 사용 여부)

- Broker log delivery (MSK 로그 수집 여부 - CloudWatch, S3, Kinesis Data Firehose)

g. Advanced settings (Security Groups)

 

 

- NRSON-MSK-SG을 아래와 같이 생성한 후 적용한다.

 

 

Zookeeper 접속을 위한 2181 포트와 Broker에 접속하기 위한 9092 포트를 Pub/Sub Application에서 접근할 수 있도록 인바운드 규칙을 적용한 보안 그룹 NRSON-MSK-SG이다.

 

 

생성이 완료되면 위와 같이 NRSON-MSK를 확인할 수 있다. 생성이 완료되는데 까지 약 10여분의 시간이 소요되며, Status가 Creating에서 Active로 변경된다.

Amazon MSK > Cluster > NRSON-MSK 메인 화면에서 View client information을 클릭하면, 아래와 같이 Client 개발 시 참조할 endpoint 정보를 확인할 수 있다.

 

 

위와 같이 Bootstrap servers & Zookeeper connection 정보를 확인하고 이를 기반으로 KafkaTemplate에서 참조할 Config 정보를 생성하여 Pub/Sub 개발시 활용할 엔드포인트로 메시지를 주고받는다.

---

결론

이와같이 Amazon MSK는 손쉬운 구성으로도 안정성과 확장성을 갖춘 Kafka 서비스를 구축할 수 있다. 혹시 꼭 비동기를 써야 할까?라고 궁금해 한다면 답은 Yes이다. API는 동기적 호출로써 세분화된 서비스간 결합도가 높아지고 하나의 서비스로 인해 응답속도가 심각하게 저해 될수 있다. 이를 효율적으로 보장하기 위한 비동기 서비스를 구축하고 비즈니스를 도출해 내는 것이 MSA 아키텍처를 설계하는 주요 요건중 하나라 할 수 있다.
비동기 처리 요건을 파악하고 상황에 따라 CQRS 등의 Advanced Application 구조를 설계하여 MSA의 이점을 최대한 누릴수 있도록 설계해야 할 것이다.