먼저 기존 질문에 대한 답변부터


쓰레드가 늘어나면 메모리점유율 과도해지고
ㄴ 쓰레드 늘린다고 처리량이 늘어나는게 아님, 쓰레드 경합과 다른 리소스들의 병목 때문에 메모리 점유율이 과도해질 정도로 쓰레드를 늘릴 일이 없음
ㄴ 최신 톰캣에서는 요청을 받아서 일단 큐에 넣어두고, 남는 워커스레드가 있으면 요청을 큐에서 꺼내 할당하는 식으로 처리함. 예전처럼 쓰레드 개수 = 동시 처리 가능한 요청 개수가 아님
적당히쓰자니 대기시간의 불편함..
ㄴ 위의 답변으로 해결됐을듯?
메모리 점유율 과해지면
ㄴ 위의 답변으로 해결됐을듯?
DB쪽이 캐싱밀리거나 어디손실될것같은데

ㄴ 서버 메모리 점유율이 과해졌는데, 왜 DB쪽 캐싱이 밀림?

이걸단순하게 스케일아웃이나 스케일업으로 돌리는건 흑우같고
ㄴ 이걸 단순하게 처리하는게 핵심이고, 스케일아웃으로 처리함


배민이 저녁시간에 특정시간에만 몰린다쳤을때
중복요청은 제거하고 특정데이터만 캐싱하고
로컬쪽으로 돌리거나 그렇게 해결하나?

ㄴ 특정 시간에만 스케일아웃 할 수 있도록, 증설이 간편한 클라우드를 사용함


---------------------------------------------------------------------------------


대규모 트래픽 처리를 현업에서 하는 방법은 이 글 하나로 정리할 수 있는게 아님

보통은 DB가 가장 문제라서 그거만 이야기할 생각

api 서버 같은건 가장 싸구려 자원으로, 필요하면 늘려버리면 그만임


가장 흔한 병목 해결(mysql 쓰는 경우)

ㄴ 읽기 요청이 늘어난다 -> DB 조회가 늘어난다 -> 커넥션풀이 부족해진다 -> redis나 로컬 메모리에 데이터를 캐시해서 DB 조회를 줄인다

ㄴ 대부분의 서비스는 읽기 비율이 훨씬 높음, 쓰기 요청 늘어나면 답 없음

ㄴ slave DB를 늘리는 것도 방법인데, 무한히 늘릴수는 없음. 복제 부하때문에 master DB가 터져버리기도 하고, 읽기가 그정도로 늘어나면 보통 쓰기도 어느정도는 늘어나버림. 이 외에도 여러가지 문제가 있음


트래픽이 아주 크고 쓰기가 많은 경우 병목 해결

ㄴ 이 경우에는 단순 slave만 늘려서 될 일이 아니고 분산 DB를 도입해야함

ㄴ 그 외에도 아주 많은 도구와 설계가 필요하지만 단순하게 DB만 보면 그렇다는 것이고, 이 DB는 자유로운 증설이 불가능함. 최대 트래픽에 대비해서 미리 늘려둬야함