Published 2023. 4. 2. 13:13

DB I/O bound 애플리케이션 + Message Queue

728x90

0. DB I/O bound 애플리케이션 성능 향상 방법

하드디스크를 많이 사용하는 파일 I/O bound 애플리케이션이라면 서버를 늘려서 성능 향상이 가능하다

하지만 보통은 DB를 사용하는 경우가 많고,

DB I/O bound 애플리케이션의 경우 DB 성능에 의존적이기 때문에 애플리케이션의 서버를 늘려도

DB 병목현상을 해결 할 수 없어서 성능향상이 되지 않을 것 이다

요청이 많이 발생하게 될 경우 즉, 트래픽이 크게 증가하는 경우

서버가 다운되는 현상을 경험하게 된다

이를 막기 위한 방법 중 하나가 Message Queue를 활용하는 방법이다

요청이 들어올 경우 우선 큐에 적재 (톰캣 기본 설정 - 큐 사이즈: 100, 스레드 사이즈: 200)
큐에 들어간 요청이 놀고 있는(Idle) 스레드가 있다면 그 스레드에 할당되어 처리
(모든 스레드가 사용 중인데 새로운 요청이 들어오면 그 요청은 큐에서 대기)
큐 사이즈를 모두 채우고 나서도 계속 요청이 들어오면 해당 요청들은 버려지게 된다 (에러 발생!)
그리고 큐에 들어온 요청도 30초를 넘으면 타임아웃 처리 (톰캣 기본 설정 - 타임아웃: 30s)
큐 사이즈, 스레드 사이즈, 타임아웃 시간 모두 늘리면 요청에 실패하는 시간은 늦출 수 있겠지만 결과적으로 해결 방법이 되지 않음
실제 처리 속도를 올리지 않으면 결국 요청은 큐에 쌓이고 언젠간 실패하게 됨

톰캣(그림에선 Nginx로 표현)에서 큐에 적재되어 있는 요청을 처리할 때 DB에 집어넣기 전 요청들을 모두 Message Queue에 한번 더 적재
실제 처리 요청은 Message Queue에서 관리하기 때문에 톰캣에 부담을 줄일 수 있음

Tomcat Queue의 경우 저장 했다가 처리하는데 특화되어있지 않음.

메모리에 저장된 데이터로 애플리케이션 강제 종료 시 전부 날아가 버릴 수 있다

반면 Message 큐를 별도로 사용하면 디스크에 저장하는 등 여러 가지 옵션을 제공한다.

그 외에도 여러 가지 특징, 옵션이 있다

비동기성
- 요청이 몰릴 때 저장 후 처리가 가능하다
- 애플리케이션은 실제 로직이 수행되는 것과 무관하게 단순히 큐에 넣고 다음 요청을 받을 수 있는 상태가 된다
애플리케이션 간 의존성 제거
- API를 직접 호출하는 것은 애플리케이션이 중단되었을 경우 메시지(요청)가 유실된다
- 하지만 중간에 큐가 있을 경우 애플리케이션이 중단되었을 때에도 메시지가 유실되지 않는다
  물론 절대적으로 유실 방지를 보장하는 것은 아니다 :(
이중화
- Message Queue도 결국 애플리케이션이므로 결국 죽을 수 있으나 이중화가 가능하다
- Queue 끼리 서로 동기화하기 때문에 하나의 큐인 것처럼 사용이 가능하다
신뢰성
- 실패한 메시지는 Queue로 Ack를 하지 않기 때문에 그 메시지는 큐에서 빠져나가지 않는다
  위에서 언급했듯이 메시지가 절대 유실되지 않는다고는 보장할 수 없음...
- 유실되면 안 되는 메시지의 경우 꼭 로깅을 철저히 하여 유실되더라도 복구할 수 있게 준비가 필요함
확장성
- 애플리케이션이 스케일 아웃 하더라도 메시지큐에서 따로 처리해 줄 필요가 없다
- 사용하던 Queue를 그대로 사용 가능

728x90