Message Queue (Kafka) 도입을 통해 서버 성능 개선

[iamabear09]

기존 단일 모듈 프로젝트 구조

기존 구조의 문제점

쉽게 장애가 발생하는 구조

Database와 동기 통신 방식의 문제로 많은 동시 요청이 몰리는 경우, 서버가 쉽게 견디지 못하는 구조이다.

테스트 환경

먼저 테스트 진행 시 Tomcat의 Thread Pool의 Thread는 200으로 설정되어있었고 DB Connection Pool의 Connection 수는 10개로 설정 했었다. 또한 Local Docker Container DB에서 테스트를 진행했다. (DB 성능이 좋지 못하다)

장애 발생 원인

서버가 견디지 못하는 이유는 내가 Local의 Docker Container환경에서 테스트를 진행해서 DB 서버의 성능이 좋지 못해 하나의 요청이 DB Connection을 잡게 되는 경우, DB의 성능이 좋지 못해 요청이 DB Connection을 오랜 시간 잡고 있게 되기 때문에 발생한다.

해결 시도

DB Connection 수를 증가 시켜서 해결 할 수 도 있지만 DB Connection 수가 25 정도가 넘어가는 순간 CPU 사용률이 100%에 도달해 버리는 문제가 있다. (Local 이라 어쩔 수 없긴 하다..)

해결책으로는 돈을 더 많이 들여서 DB 서버 성능을 증가 시키고 DB Connection 수를 올리면 된다. 돈으로 해결하는 쉽게 적용할 수 있지만, 한계가 있다.

그 전에 이 문제를 구조적으로 해결하는 것이 더 중요하다고 생각했다.

[iamabear09]

Message Queue 를 도입한 Multi Module 프로젝트 구조

기존 구조의 해결책

Message Queue 도입 장점

기존 구조의 해결책을 공부하던 중 Message Queue 에 대해서 알게 되었다.

[iamabear09]

해결 해야 하는 문제

MQ 도입 시 Api에서 MQ에 Event 를 발행하고 응답을 바로 내려준다. 따라서, Client는 완료 결과를 바로 받아보지는 못한다. 또한 언제 완료되었는지 알지 못한다.

문제 - 단순 ID 값을 내려주는 경우

• Create의 경우 조회를 통해 완료되었는지 아닌지 파악할 수 있다
• Update의 경우 완료되었는지 완료되지 않았는지 파악할 수 없다. Data를 비교해야 해서 파악해야 한다.
• 내 비지니스의 Put Update의 경우 기존에는 요청 처리의 결과로 좀 더 복잡한 응답을 내려주었었지만, 요청 처리의 결과로 발생하는 복잡한 응답을 내려줄 수 없다.