[SQL/캡스톤디자인] 데이터베이스 과제 5주차

데이터베이스5주차

지난주에 이어, 이벤트 기반 비동기 로그 처리 아키텍처의 성능 및 신뢰성 확보 방안으로서 메시지 큐 시스템의 도입 필요성을 확인하였다. 이번주엔, Flask 기반 백엔드에 도입 가능한 RQ와 kafka를 비교하고, 실무 적용 가능성과 장단점을 정리하였다.우선, RQ는 Python 기반의 단순한 작업 큐로, Flask와의 통합이 쉽고 redis만 있으면 손쉽게 구성할 수 있어 개발 초기 단계나 소규모 서비스에 매우 적합하다는 결론을 얻었다. 큐에 들어간 작업을 백그라운드 워커가 소비하며, 실패 시 간단한 재시도나 예외 처리도 가능하다. 특히 Flask 앱에서 로그 이벤트를 RQ 큐로 전송하고, 별도의 wk가 MongoDB에 로그를 기록하는 방식은 현재 시스템 구조와 잘 맞는다.반면에, Kafka는 분산 스트리밍 플랫폼으로, 훨씬 더 큰 규모의 서비스에 적합한 메시징 시스템이다. Kafka는 메시지를 여러 cs가 병렬로 처리할 수 있으며, 메시지의 보존성과 확장성, 안정성이 매우 우수하다는 장점을 가진다. 다만, 초기 설정이 복잡하고 zookeeper,브로커,토픽 설정 등 많은 구성이 필요하며, Flask 기반 백엔드에서는 별도 Producer/Consumer 구조를 구현해야 하는 부담이 있다.기술적 비교 결과, 개발 및 테스트 단계에서는 RQ를 우선 적용하는 것이 합리적이며, 실제 운영 서비스나 고부하 환경에서는 Kafka의 도입이 더 적합하다는 판단을 내렸다. 특히 로그 처리량이 많아질 경우 Kafka는 버퍼와 같은 역할을 하여 과부하를 방지할 수 있고, 모든 로그 기록을 중앙 집중적으로 관리할 수 있는 구조를 만들 수 있다는 점에서 강력한 확장성을 보여준다.실제 테스트에서는 RQ를 Flask 앱과 연결하여 로그 생성 이벤트를 큐로 전송하고, 백그라운드 워커가 Rdis 큐에서 메시지를 꺼내 MongoDB에 저장하는 구조를 완성하였다. Kafka는 docker 를 활용하여 로컬에 클러스터를 구성하고 간단한 토픽 발행/구독 실험을 마쳤다. 다만 프론트엔드와의 연동은 아직 구현되지 않아, 실제로 테스트가 어려워, 사용자기반으로 해보진 못하였다.두 큐 시스템의 메시지 중복 처리, 예외 상황 대응, 재처리 정책 등은 각각 특성이 다르며, 어떤 구조를 선택하든 로그 신뢰도 확보를 위한 설계가 필요하다는 것을 다시금 인지하게 되었다. 차주에는 실제 운영 환경에서 Kafka를 사용할 경우를 가정한 로그 구조 설계 시나리오와, 큐 실패 시 로컬 백업 방식과의 연계 방안까지 고려해볼 계획이다.