개요
IT-hermes 프로젝트 개발과정에서, Batch서버에서 이슈가 발생했습니다.
이슈를 본 결과 크롤링 서버의 API를 요청 중에 오류가 발생한 것이었습니다.
이런 오류가 발생하면, 보통 우리는 어떻게 해결하는 편일까요..?
일단 저의 경우, Batch서버에서 보내는 과정에 문제가 있는지를 먼저 확인을 할 거같습니다. 그리고, 정상적으로 된거같음에도 안될 경우는 크롤링 서버를 확인하고요..
구성도를 보면 다음과 같습니다.
크롤링 Insert 트랜잭션은 15분에 한 번씩 최신 크롤링 데이터를 갱신하는 과정을 거치는 구조입니다.
문제상황
문제가 발생한 이유는 이 중 5번 혹은 6번 과정에서 이슈가 발생한 점이 원인이었습니다.
즉, Youtube 및 기타 서비스의 DOM구조의 변경으로 인해 데이터를 크롤링 하는 과정에서 이슈가 발생하였고, 해당 이슈로 인해 배치서버에서도 문제가 발생한 것이었습니다.
문제1 : 크롤링 서버 이슈인데..
크롤링 서버의 최대 단점은, 유튜브 등의 서비스를 강하게 의존하고 있다는 점입니다. 특히 프론트의 DOM 구조와 같이 구체적인 데이터를 가져오기 때문에, 변할 가능성이 높고, 크롤링할 서비스가 많을수록 UI 등의 변경으로 인한 이 오류가 날 확률이 높다고 판단했습니다. 또한, 배치에 오류가 나면, 저 역시 여러 서버를 확인해야 된다는 측면에서 이슈를 해결하는데 많은 시간을 쓸 가능성이 높다고 봤습니다.
문제2 : 배치서버의 트랜잭션 처리시간이...
배치서버의 트랜잭션의 경우 처리를 하는데 많은 시간이 발생합니다. 지금의 경우 서비스를 크롤링하는 것이 적은편이라, 문제가 없을 수도 있지만, 수십만 건이상의 데이터를 크롤링을 통해 가져와서 처리를 하게 될 때, CPU, 메모리의 한정 된 자원으로 인해 다른 Batch처리를 할 경우(텔레그램 구독조회 API 등)에서 Request를 못할 수 있는 이슈가 발생할 수도 있다고 보았습니다. 따라서 배치서버 역시 처음엔 당연히 하나만 있어도 된다고 생각했지만, scale-out으로 분산처리를 할 필요성을 느꼈습니다.
위의 그림은 채용관련 IT정보를 Insert하는 프로세스입니다. 트랜잭션 실행시간의 경우 한번 메소드 호출 시 약 14초 정도 발생합니다.
당면과제
정상적으로 작동하는 배치서버에 크롤링 서버의 문제로 인해 오류가 나는 것은 잘못 되었다고 생각 했고, scale-out 상황을 고려해서 개발을 하는게 중요하다 보았습니다. 이때 저에 눈에 들어온 툴이 있었습니다. 바로 메시지 큐인 RabbitMQ 였습니다.
RabbitMQ?
저는 이 2가지 문제를 해결하는데 가장 적합하다고 판단한 툴이 RabbitMQ였습니다. 이유는 다음과 같습니다.
- 문제1의 이슈를 해결하기 위해선, 배치서버와 크롤링서버의 의존성을 낮춰야 된다고 보았습니다. 따라서 중간에 RabbitMQ를 두고, 두개의 서버를 메시지큐에 의존하면 해당 트러블슈팅을 해결할 거라 판단했습니다.
- 문제2의 경우 크롤링을 한 데이터를 한 건씩 메시지큐에 저장을 하고, 이후 배치서버에서 consume하는 식으로 진행을 하면, 기존에 발생했던 insert로 인한 처리속도 이슈를 개선할거라 봤습니다.
RabbitMQ를 적용한 프로세스 변경
이렇게 구성하게 된다면, Insert를 위한 트랜잭션을 분산시킬 수 있고, 많은 크롤링 데이터를 가져와서 처리하는 상황에서도 처리속도 이슈 등의 트러블슈팅을 해결할 수 있다고 보았습니다.
주의할 점
결론만 말씀드리면, 전체 트랜잭션의 처리속도는 오히려 네트워크 비용이 추가되기 때문에 RabbitMQ 도입으로 인해 더 느려질 수 있다고 보았습니다. 따라서, 저와 같은 이런 이슈가 발생하지 않게 된다면, 무조건 RabbitMQ를 도입하려고 시도하진 않을거 같습니다.
또한 RabbitMQ 역시 하나의 서버이기 때문에 문제가 발생하지 않는다는 보장을 할 수 없다고 보았습니다. 만약 구축 시스템이 커지게 된다면, RabbitMQ를 2개를 만들어서 하나의 서버에 이슈가 발생해도 바로 대응할 수 있도록 처리할 거 같네요..!
결국 RabbitMQ 역시 상황에 맞게 적절하게 사용하는게 맞다고 보여집니다.
