해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.
1. 톰캣 구조 살펴보기
- Message Queue를 이해하기 위해서는 우선 톰캣이 요청을 어떻게 처리하는지 알아야한다.
-
요청이 들어오면 톰캣 내에 있는 큐에 들어가게 되고, 먼저 들어온 요청대로 각 스레드들이 요청을 처리한다.
-
따로 설정하지 않았다면, 디폴트로 설정된 값들은 큐는 100개의 요청을 담고, 쓰레드는 200개가 존재한다. (디폴트가 있다는것은 변경 가능하다는 이야기며 보통 톰캣 튜닝이라고 하면 이러한 부분을 변경하는 것이다.)
-
이 때 큐에 요청이 다 차게된 후, 들어오는 요청들은 실패하게 된다. 또한 큐에 들어온 요청들도 30초가 넘어가면 타임아웃이 발생한다.
2. 서버가 죽는 상황 해결하기(Message Queue 탄생 이유)
2-1. 톰캣을 튜닝
-
타임아웃 시간을 늘리면 되지 않을까?
- 요청이 실패하고 버려져야 할 요청들이 계속 큐에 남아있으면서 오히려 역효과가 날 수 있다.
-
쓰레드 수를 늘리면 되지 않을까?
- 모든 쓰레드는 cpu자원을 공유한다. 즉 한 쓰레드가 cpu를 사용중이라면 나머지 쓰레드들은 기다려야하기 때문에 해결책이 될 수 없다.
-
큐 사이즈를 늘리면 되지 않을까?
- 더 많은 요청을 받을 수는 있겠지만 결국 스레드가 요청을 빠르게 처리할 수 없다면
해결책이 될 수 없다.
- 더 많은 요청을 받을 수는 있겠지만 결국 스레드가 요청을 빠르게 처리할 수 없다면
-
세 방법 모두 요청을 빠르게 처리할 수 있는 방법이 아니다.
2-2. Message Queue 도입
-
Message Queue를 도입해 위와 같은 형태로 구현할 것이다.
-
앞서 얘기한 톰캣의 큐가 아닌 별도의 Message Queue를 사용한다.
- 자세히 들어가면 위와 같은 구조가 될 것이다.
-
글 작성하는 요청이 들어오면 컨트롤러에서 바로 Message Queue에 넣는다.
-
요청을 받은 스레드는 Message Queue에 넣기만 하면 다음 요청을 받을 수 있다.
-
애플리케이션의 다른부분 예로 서비스에서는 Message Queue에 있는 요청을 가져와 DB에 넣는 작업을 수행한다.
그렇다면 톰캣의 큐와 Message Queue에 요청을 넣어서 처리하는건 어떤 차이가 있을까?
톰캣에 저장되어있는 요청은 메모리에 저장되어 있는 데이터이기 때문에 톰캣이 종료되면 모두 사라진다. 반면 Message Queue는 디스크에 저장하는 등 여러 옵션을 제공한다.
3. Message Queue의 장점
3-1. 비동기성
-
요청을 Message Queue에 저장했다가 처리하기 때문에 DB속도와는 무관하게
요청을 누락없이 처리 가능하다. -
DB에 요청을 처리하는 시간보다, Message Queue에 요청을 넣는 시간이 훨씬 짧다.
3-2. 애플리케이션간 의존성 제거
- 위 그림에서 A는 B에게 의존성이 생긴다. 즉 B서버에 장애가 발생한다면 A가 B로 보내는 데이터는 유실된다.
- 중간에 Message Queue가 들어가게 되면 B 서버가 죽더라도 A가 보내는 데이터는 Message Queue에 저장되기 때문에, 추후에 B서버가 정상화 됐을 때 요청을 처리 할 수 있다.
3-3. 확장성
-
서버를 스케일 아웃 해도 하나의 Message Queue만 바라보도록 할 수 있다.
-
하지만 Message Queue도 결국 소프트웨어이기 때문에 장애가 발생할 수 있다.
따라서 아래그림처럼 Message Queue 또한 이중화, 삼중화를 해야한다.
4. 마무리
Message Queue로 사용하는 소프트웨어는 보통 RabbitMQ와 Kafka로 나뉜다.
범용적으로 사용되는건 RabbitMQ 이며 트래픽이 많다면 속도면에서 장점이 있는 Kafka를 쓴다. 무조건 어느게 더 좋아! 라기 보다는 각 장단점이 존재하기 때문에 상황에 맞는 Message Queue를 선택해야 한다.
