전자계약서 시스템의 대용량 엑셀 파일 생성 작업에서 발생한 Kafka 기반의 문제를 해결하기 위해 RDB 기반의 태스크 큐 아키텍처로 변경한 경험을 공유합니다. 이 글에서는 새로운 아키텍처의 구현 과정을 상세히 설명하며, 장시간 비동기 작업의 안정성과 효율성을 향상시키는 방법을 제시합니다. 최종적으로, 이 전환이 조직에 미친 긍정적인 영향을 파악할 수 있을 것입니다.
장시간 비동기 작업 처리의 어려움
장시간 비동기 작업을 처리하는 과정에서는 여러 가지 도전 과제가 존재합니다. 기존의 Kafka 기반 시스템은 대량의 데이터를 처리하는 데 있어 비효율적이었고, 이로 인해 동일 메시지가 중복 처리되는 문제가 발생하였습니다. 특히, 엑셀 파일 생성과 같은 작업은 외부 API 호출로 인해 시간이 소요되기 때문에, 해당 프로세스가 타임아웃에 걸리는 상황이 빈번하게 발생했습니다.
이런 문제점을 해결하기 위해 RDB 기반의 태스크 큐 아키텍처로 전환하는 것이 논의되었습니다. 새로운 아키텍처에서는 요청한 작업을 RDB에 영구적으로 기록함으로써, 상태 관리의 단순화를 이루었습니다. 이제 작업이 진행되는 동안의 상태를 지속적으로 추적할 수 있으며, 비정상적인 종료 시에도 작업 복구가 가능해졌습니다. 이를 통해 각종 장애 상황에서도 데이터 유실이 방지되며, 사용자에게 보다 안정적인 서비스를 제공하게 된 것입니다.
더불어, 이 아키텍처는 작업의 재시도 메커니즘을 자동으로 처리하게 설계되었습니다. 도중에 발생하는 외부 API 오류나 네트워크 문제로 인한 중단이 있더라도 최대 3회까지 작업을 자동으로 재시도합니다. 이를 통해 사용자는 더욱 신뢰할 수 있는 서비스를 경험하게 됩니다. 장기간 소요되는 비동기 작업의 처리에서 이러한 혁신적인 변화는 고객 만족도를 높이는 데 기여할 수 있습니다.
RDB 기반 태스크 큐 아키텍처의 장점
RDB 기반의 태스크 큐 아키텍처 변경은 여러 장점을 가져왔습니다. 첫째, 시스템의 복잡성이 크게 감소했습니다. Kafka와 같은 메시지 스트리밍 시스템을 사용할 경우 디버깅 과정이 복잡해질 수 있습니다. 그러나 RDB를 활용한 단순한 데이터 소스에서는 상태 관리를 용이하게 할 수 있어 개발자들이 더욱 편리하게 시스템을 유지보수할 수 있게 되었습니다.
둘째, 복잡한 메시징 시스템과 달리, RDB는 모든 작업 정보를 한 곳에 모아 관리하므로, 문제 발생 시 정확한 원인 파악이 가능합니다. 이러한 안정성 향상은 시스템 운영에 있어 큰 이점으로 작용했습니다. 특히, Worker가 갑작스럽게 종료되더라도 Heartbeat 메커니즘을 통해 2분 이상 업데이트가 이루어지지 않은 작업을 자동으로 복구할 수 있도록 설계되어, 서비스 중단을 예방하는 데 효과적입니다.
셋째, 기존 시스템에서는 새로운 메시지 패턴에 맞춰 Consumer Group을 조정하는 과정에서 많은 리소스가 소요되었습니다. RDB 기반 아키텍처로의 전환 이후, Worker 수의 수평적 확장이 용이해졌고, 필요시 작업량을 조정할 수 있는 유연성이 생겼습니다. 이로 인해, 시스템의 효율성이 획기적으로 증대하였으며, 일관된 성능을 유지할 수 있게 되었습니다.
안정성을 고려한 소프트웨어 아키텍처 설계
소프트웨어 아키텍처 설계 시 안정성을 진지하게 고려해야 합니다. 전환 프로젝트에서 각 요소는 신뢰성을 보장하는 방향으로 디자인되었습니다. 예를 들어, Worker가 작업을 수행하는 동안 주기적으로 Heartbeat를 갱신하여 상태를 알리고, 만약 서버가 비정상 종료하더라도 작업이 중단되지 않도록 설계되었습니다.
또한, RDB에 영구적으로 저장된 작업 단위는 처리가 필요한 우선순위를 기반으로 적절히 선정되어 동시 다발적인 작업 수행이 가능합니다. 이와 동시에 Redis를 활용한 분산 락을 통해 동일한 작업이 중복해서 처리되는 것을 방지하였습니다. 이러한 메커니즘을 통해 시스템의 일관성과 안정성을 크게 향상시키는 데 기여할 수 있었습니다.
마무리하면, 장시간 비동기 작업 처리에서 RDB 기반 태스크 큐 아키텍처 전환은 시스템의 신뢰성을 크게 높이는 결과를 가져왔습니다. 데이터 유실 문제를 원천적으로 차단하고, 장애 복구 메커니즘을 통해 서비스의 안정성을 극대화하였습니다. 향후에도 이러한 설계를 바탕으로 서비스를 지속적으로 개선해 나가고, 사용자 경험을 한층 향상시키기 위한 노력을 이어갈 것입니다.
이번 변경을 통해 장시간 비동기 작업 관리의 방향성을 재조명할 수 있었습니다. 시스템 아키텍처 선택은 단순히 기술적 요소만 고려할 것이 아니라, 해당 시스템에서 처리하는 작업의 특성과 요구사항을 균형 있게 반영해야 한다는 점을 깨달았습니다. 앞으로도 이 경험을 바탕으로 더 나은 해결책을 모색해 나가고자 합니다.
.png)
