Kafka 하드웨어 제약

문제

1차 개발 당시, Spring Boot API Server와 Whisper, GPT API, Kiwi 등 고비용 작업들을 처리하는 Python 서버 간의 통신 및 공부 목적으로 Kafka를 사용하였습니다.

하지만, 2차 개발 당시, Kafka를 사용함에 따라 AWS EC2의 무료 티어에서는 메모리 부족 문제로 Kafka가 종료되는 문제가 발생했습니다.

AWS EC2 무료 티어는 1GB 메모리 제한이 있어, Kafka를 사용함에 따라 메모리 부족 문제가 발생했습니다.

또한, Kafka는 메모리 사용량이 많은 프로세스이기 때문에, EC2 무료 티어에서는 사용할 수 없습니다.

하드웨어 제약을 벗어나고, 두 서버 간의 통신을 위해 사용할 수 있는 방법을 찾아야 했습니다.

그 중 다음과 같은 방법을 찾아보았고, 각 방벙의 가능 여부를 확인하였습니다.

종류	교체 비용	장점	단점	하드웨어 제약	가능 여부
Database	중복 메시지 방지 DLQ 구현 Backoff 기능 구현 DB 장애 시 메시지 손실 방지	프리티어 무료	메시지 특성상 데이터가 많으며, 지속적인 조회로 인해, API 서버의 성능 저하 우려	없음 (사용자가 많지 않은 가정 하에)	가능
RabbitMQ	새로운 메시지 큐 시스템 도입으로 인해 러닝커브 발생	DLX, 메시지 보장 등 신뢰있는 메시지 큐 시스템	프리티어에서는 구동하기 어려운 메모리 사용량	있음	불가능
Redis Pub/Sub	메시지 유실 가능성 DLQ 구현 Backoff 기능 구현 ACK 기능 구현	JWT RTR 기법 및 캐싱 기능 구현을 위해 사용하고 있어, 통합 사용 가능	Redis 메모리 사용량이 많을 뿐더러, 구현해야할 기능이 많음	없음 (사용자가 많지 않은 가정 하에)	가능
AWS SQS	Backoff 기능 구현 Visibility 갱신 구현	하드웨어 제약이 없고, 프리티어에서는 하루 100만건 무료	Visibility 갱신 구현이 복잡함	없음	가능

위 4가지 방법 중 하드웨어 제약을 받지 않으며, 교체 비용이 적은 AWS SQS를 선택하였습니다.