RabbitMQ를 사용하여서 모델 처리하기
짧은 기간 동안에 돈을 받으면서 연구와 서비스를 동시에 맡은 경험을 글로 남깁니다. 정말 좋은 경험을 하게 직장 임원 분들에게 감사한 글을 남깁니다.
처음은 코드와 현황을 분석하고 이를 바탕으로 어떠한 요구조건이 있었는지를 파악하면서 저에게 내려진 업무는 다음과 같았습니다.
수학적 처리가 있는 알고리즘 코드를 통해서 값을 삽입/추출하는 코드를 공통으로 사용할 수 있는 API 서비스에 녹여내는 과업이었습니다. (덤으로 알고리즘 최적화도 하였습니다.)
보통 웹 API는 대부분 I/O-Bound의 작업이다 보니 특성이 다르고 어떻게 처리해야 할지에 대한 고민을 간단히 담아보았습니다.
현황파악
기존에 작업했던 개발자가 한 작업과 히스토리와 생각 그리고 해결한 방법에 대해서 정리를 하는 것이 우선이라고 판단했습니다.
기존의 개발자는 알고리즘 코드 자체가 오래 걸리는 작업이라는 작업이라고 인지하고 이를 그냥 Queue를 무작정 사용하면 된다고 판단했습니다. 자기가 아는 지식에 한해서 찾아보니 RabbitMQ를 사용했다고 이야기해 주었습니다.
저는 아이디어와 설계 자체에서는 나쁘지 않은 판단이라고 생각했지만, 구현단계에서 아쉬운 점이 있었습니다.
어떤 점이 아쉬운 구현 방법이었냐고 하면, Queue를 사용해서 비동기 통신을 사용하는 구성을 하였지만, API를 호출하고 결과가 나올때 까지 Polling을 하는 방식으로 구현을 했다는 점 입니다.
이러한 방법은 비동기 처리를 하여서 CPU-Bound의 수학적 알고리즘이 끝날때 까지 다른 작업을 처리하지 못하고 컴퓨터 자원을 사용하며 막아두는 문제점이 해결되지 않습니다. 몰론 수학적 처리를 하는 서버에 CPU와 Ram을 더 좋게 해서 처리 속도를 조금 더 올릴 수는 있으나 근본적으로 좋은 설계라고 생각하지 않습니다.
아무튼 이러한 코드를 보며 저도 많이 배우게 되었습니다. 구현한 개발자와 서로 논의를 나누면서 더 좋은 코드와 인프라에 대해서 논의할 수 있었습니다.
개선한 방법
데이터에 대해서 자세히 설명하지 않겠습니다.
잠시 환경을 정리해보겠습니다. RabbitMQ를 사용하고 있는 Queue 캐시가 있는 구조, 컴퓨터 자원을 많이 사용하는 알고리즘 코드와 웹 서비스로 만들어야하는 서비스입니다.
첫번째, 이벤트 개념으로 진행하고 이에 상태값을 부여했습니다. . 알고리즘 진행 전, 진행 오류, 진행 완료 이런식으로 로직이 돌아가면서 데이터 값이 바뀌도록 작업했습니다.
두번째, RabbitMQ 서버와 알고리즘 서버, API 서버를 따로 두었습니다. 처음에는 하나의 서버에 다 소프트웨어로 나눠서 처리 되어있었데, 이는 똑같은 서버 자원을 사용하기때 차라리 비싼 서버를 내리고 싼 서버를 3개 정도 두어서 처리했습니다.
마지막으로, python으로 되어 있는 알고리즘 코드 최적화 했습니다. 이 부분은 반복적으로 호출하는 인스턴스만 하나를 쓰도록 만들던가 수학적으로 필요없는 부분을 검토해서 최적화 하고 테스트 했습니다.(자세한건 비밀 ㅎㅎ)
결론
전보다 비용도 어느 정도 줄이면서 성능도 훨씬 좋아져서 다행이라고 생각합니다. RabbitMQ에 대해서 많이 배웠고, 정말 다양한 기능들이 있었던 점을 배웠습니다. 러브콜을 너무 좋게 받아서 다음 회사로 남기면서 핵심 공통 API를 만들고 사라졌습니다.
