애플리케이션들을 AWS 클라우드로 이관하고 Pub/Sub 체계를 구축하는데 있어서 우리는 이미 온프레미스 환경에서 Kafka를 사용한 경험이 있었기에 AWS에서 SaaS형태로 제공하는 MSK와 SQS를 놓고 검토를 하게 되었는데 두 솔루션의 장단점이 명확하므로 여기에 정리를 해본다.
Amazon MSK (Managed Streaming for Apache Kafka)
.png)
- AWS에서 제공하는 완전 관리형 Apache Kafka 서비스
- 기존에 On-Promise에서 사용하던 혹은 EC2로 관리하던 Apache Kafka를 SaaS형태로 사용할 수 있음
- Apache Kafka의 특정 버젼을 그대로 사용할 수 있기 때문에 Vanila Apache Kafka의 버젼별 Api spec을 따라서 사용 가능
- MSK 모니터링 제공
- Apache Kafka의 특징을 그대로 활용
- 같은 partition 내에서만 순서 보장이 됨. → partition이 다르면 순서를 보장하지 못한다는 의미.
- Pub/Sub 아키텍처 구축에 많이 사용되어 레퍼런스 자료가 풍부.
- 컨슈머 그룹을 분리하여 운영한다면 같은 메시지를 서로 다른 컨슈머에서 각각 수신하여 사용할 수 있다.
- 컨슈머가 어떤 방식으로 각 인스턴스에 메시지를 Assign 하는지는 이 문서 참고. → https://velog.io/@hyun6ik/Apache-Kafka-Partition-Assignment-Strategy
- 장점
- 아키텍처 구성이 간편하고 구축 시간을 줄일 수 있음.
- AWS에서 관리툴 제공하므로 모니터링이 용이할 듯함.
- 자동복구 및 패치 기능이 있어 애플리케이션 지속성 향상, 안정적임.
- 단점
- 쓰는 만큼 비용이 나가고 그 비용이 다소 비쌈, 강제로 VPC/AZ에 broker 들이 할당되어서 제약사항이 많음.
- 로컬 개발환경에서 MSK 접속이 안됨.
Amazon SQS (Simple Queue Service)
.png)
- 지속적이고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리
- 이미 만들어지고 운영 중인 AWS 서비스에서 Queue 채널만 추가 생성하는 개념으로 이해
- 일반적인 Queue는 순서 보장을 하지 않으며, FIFO Queue는 순서 보장이 됨.
- 단 FIFO Queue는 초당 3,000개 메시지까지만 처리 가능
- 256KB 용량 제한
- 256KB를 초과하는 메시지는 S3에 업로드하는 방식으로 우회하여 처리하는 방법이 있고, AWS에서도 해당 기능을 가진 라이브러리를 제공 중
- https://github.com/awslabs/amazon-sqs-java-extended-client-lib
- 장점
- 관리와 사용이 매우 쉽고 간편 단점 256KB의 용량 제한, 초당 처리량 제한 등의 성능 이슈
- 기능이 Kafka만큼 High Level로 제공되지 않음
- 하나의 메시지를 여러 개의 컨슈머가 동시에 수신할 수 없음
Note: With Amazon SQS, multiple consumers can’t receive the same message simultaneously. A message can only be received from a queue by one consumer that’s ready to process and then delete the message received. A message can be retained in queues for 14 days maximum.
댓글 없음:
댓글 쓰기