Message Queue 시스템 필요성

원문: https://blog.naver.com/qoxmfaktmxj/223515091417

패키지 유지보수를 진행하다 보니,

대부분이 프로시저로 진행되는 로직이 많은데, 사용자가 많아질수록, 프로시저를 호출하는 부분이 많아져 과부하가 많이 발생한다.

예를 들어, 10000명 에 대한 로직이 발생하면

그 인원에 대한 정보를 갱신하는 작업을 하게 되면 해당 프로시저에서 10000명 전체에 대해서 인원을 조회하고 특정 로직을 거쳐서 갱신이 된다.

전체 인원을 돌리게 되면 테이블 인덱스 전부 태울 수 없으니, 시간을 많이 잡아 먹게 된다.

전체 인원이 갱신되는 시간에, 다른 루트로 갱신건이 생기고, 인터페이스를 받아와 실시간으로 동기화 해야 하는 작업이 겹치게 되버리면 , 교착상태가 발생해 테이블 락이 걸리는 경우가 있는 것 같다.

이를 해결하기 위해 카프카 같은 Message Queue 서비스를 이용하면 어떨까 생각하여 개인적으로 적용해볼 준비를 하고 있다. 어차피 순차적으로 들어갈 것이고, 교착상태가 걸릴 정도로 트래픽 증가가 되어도 큐에 담겨지고 유실되지는 않으니 그 부분도 해결은 되지 않을까 싶다.

그런데 예를 들어, 근무 갱신을 위한 것이라면 첫 근무 타각을 하는 세콤이나 캡스 같은 곳에서 큐에 담기 위한 첫 데이터를 보내줘야 하는 것처럼, 타 시스템에서 호출이 되야 한다면…? 협조가 없이는 불가능해 보인다….ㅠㅠ

메세지 큐를 쓰는 이유에 대해서 정리해 놓은 부분이 있는데 그 중 내가 필요한 부분들에 대해서만 내가 기억하기 위해 간략하게 요약해 놓는다.

1.위에서 말한 것처럼 일단 큐에 메세지 읽는 프로세스를 통해서 트랜잭션이 완료되면 손실되지 않고 재처리할 수 있는 지속성이 있다는 장점이 있다. + 트래픽 폭주해도 손실되지 않으니 기다리면 해결된다.

2.웹앱 페이지 로딩 시간을 향상시킬 수 있는데, 백에서 복잡한 작업을 하게 될 때 메세지큐에서는 사용자에게 최소한의 성공 반환 작업에 대한 정보만 주고, 나머지는 백그라운드 스레드에서 진행시킬 수 있다. 비슷하게 효율적인 일괄처리도 가능하다. 1번씩 100번하는 것보다, 한번에 100개 레코드를 데이터베이스에 넣는 것이 훨씬 효율적이기 때문에 일괄처리로 트랜잭션 규모 조정을 해서 성능에 대해서 최적화 해볼 수 있다.

3.비동기 메세징을 통해서 당장 수행하지 않아도 되는 것들을 대기열에 넣어서 비동기 프로그래밍 패턴을 구현해볼 수 있다.

4.백엔드쪽 처리가 좀 지연되도 웹사이트는 계속 동작이 가능하고, 대기열에 일단 추가가 되면 다른 문제가 생겨도 해당 작업에 대해서는 처리를 진행해볼 수 있다.

5.모니터링을 통해 큐에 잇는 항목 수 , 메세지 처리 속도 및 기타 통계 등등을 주시해볼 수 있다.