처리량이 서버에 미치는 영향 (+ 비동기, CQRS)
최근 CQRS를 공부해보면서 처리량이 서버에 미치는 영향을 알게 되었다.
우아한 형제들의 강연을 보면 아래와 같은 CQRS 아키텍처를 많이 사용함을 알 수 있다.
하지만 우아한 형제들에 다니시는 전 동료분께 여쭤보니 모든 시스템이 해당 아키텍처를 적용하는 것은 아니라고 했다.
- 전사 Default는 Slave DB를 활용하는 정도의 느낌..?
- 프론트 서버나, 상품 노출, 가게 노출 등 도메인에서는 활발하게 적용
그래서 해당 아키텍처를 적용하는 기준(?) 같은 것이 있냐고 묻자, 중요한 힌트를 얻었다..!
- 앱쪽과 가깝게 위치한 서버에서는 1ms의 latency에도 매우 민감하다
- Thread가 요청을 처리하지 못하고 쌓일 때 생기는 문제들 때문
비동기와 CQRS로 인한 처리량 개선
아래는 배달의 민족의 가게 노출 시스템을 정리한 크게 도움되는 글이다.
https://techblog.woowahan.com/2667
해당 글을 보면 가게 노출 시스템에서는 비동기(Webflux)를 사용하여 최대한 빠른 시간 내에 많은 Thread를 처리한다.
추가로 아래 그림과 같이 조회 저장소를 별도로 사용하고, 레이어링으로 캐시 저장소를 충분히 활용하고 있다.
이 역시도 빠르게 Thread를 처리하는 데에 목적이 있다.
- Redis는 In-memory와 Key-Value 데이터의 특징을 가짐으로써 조회 속도가 매우 빠름
- 외부 API를 call해서 사용자 요청을 처리하는 방식이 아니라, 미리 타 시스템에서 제공받은 데이터로 만든 조회 모델을 시스템 내부 DB에 저장하고 꺼내어 사용하는 방식을 사용
- 처리량이 높은 DB 선택이 가능하다(-> 처리 속도가 빠르거나, Secondary Index 사용이 가능한 DB 등)
- 외부 시스템의 Performance에 영향을 받지 않는다.
그렇다면 Thread가 요청을 최대한 빠르게 처리해야 하는 이유는 무엇이 있을까..?!
- 첫 번째로 서버의 성능 이슈이다.
- 두 번째로 사용자 경험(UX)이다.
- 이 역시도 성능 이슈에 의한 것이라 볼 수 있다.
처리량이 미치는 영향
Thread를 빠르게 처리하지 못하면 다음의 현상이 생긴다.
- CPU 사용량이 높아진다.
- Multi-Thread로 동작하기 때문
- Heap 메모리 사용량이 높아진다.
- (각 Thread마다 Heap 공간을 활용하기 때문)
- Storage I/O가 증가될 수 있음
- 웹 서버에 요청이 병목될 수 있다.
위 현상들은 서버 처리량을 감소 시킨다.
즉, 요청을 빠르게 처리하지 못하면 위 현상들로 인해 서버 처리량을 더 감소 시키고, 더 요청이 쌓이게 되는 악순환이 되는 것이다.
그래서 해당 Thread가 요청을 최대한 빨리 처리해서 응답을 던지는 것이 대규모 웹서비스 환경에서 매우 중요하다.
- 요청을 비동기로 처리하는 부분이나, DB를 분리하는 CQRS도 해당과 같은 문제에 대한 대응이기도 한 것이다.
참고
'Operation > System Architecture' 카테고리의 다른 글
| 선착순 자원을 사용하기 위한 방법! (동시성, Lock, Isolation, ...) (0) | 2023.03.08 |
|---|---|
| MSA 간 동기로 API 호출 시 문제점 (feat. Read Timeout, ..) (0) | 2023.02.25 |
| 이벤트 기반 아키텍처 구축하기! (feat. 배민 회원 시스템) (0) | 2022.12.06 |
| 배민 B마트 CQRS 적용기를 보면서 (+ 조회 모델 설계, 변경된 데이터 동기화 방법, ...) (0) | 2022.11.28 |
| '배민 프론트 서버의 사실과 오해' 정리! (MSA, SAP, DIP, 도메인 설계, ... 등) (0) | 2022.11.19 |