[order101] 최적화 및 시나리오 - 12일차

.env파일 생성하고 로컬에서 잘 작동하는지 확인하고 

 

이 프로젝트의 업데이트 포인트는 2-3가지있다. 
* 분산 트랙잭션
* 대량의 거래 내역시 -> 락관련해서? / 쿼리 ? / 
* 조금 백엔드에서 딥한걸로 test필요
아마 정산쪽에 뭔가 생기지 않을까그리고 LLM과 RAG는 한번 써봤으니 이제 강화학습같은걸 써보면 좋겠다.

 

1. stock101에서 순정 db?에 test를 했을때 최대 500명이 가능하긴하나 2-3초 머무는 경우가 생겼다. 이걸 order101에서 해결해보자.

 

먼저, 왜 이런 문제가 생길까 고민해보자.

1. 내 pc의 성능이 좋지않다.<- 아직 렘이 널널하다.

2. DB쪽에 뭔가 있다. 일단 i/o가 무거운것도 아닌데 왜 그럴까? 이것에 대해 공부했다. 

1. Connection Pool (커넥션 풀): DB와 연결된 통로의 개수입니다. 통로가 10개뿐이라면 아무리 CPU가 좋아도 동시에 처리할 수 있는 DB 작업은 제한됩니다.
2. Database I/O: 백엔드에서 가장 느린 구간입니다. 쿼리가 비효율적이면 한 번의 요청이 오래 걸리게 되고, 이는 전체 TPS 하락으로 직결됩니다.
3. Concurrency Model (동시성 모델): * Thread-per-request (Spring MVC 등): 스레드 생성 비용과 컨텍스트 스위칭 비용 때문에 특정 시점에 한계가 옵니다.
   • Event-loop (Node.js, WebFlux): 적은 자원으로 많은 연결을 유지하지만, CPU 집약적인 작업에는 취약합니다.

DB의 커넥션풀은 기본설정이 10개라고함. 

 

1. 내 쿼리문의 explain을 측정하면 1번 요청이 얼마나 걸리는지 볼 수 있다. -> 이를 곱해서 얼추 예측하면 이정도되겠구나 각이보임2. 커넥션풀이 문이라고봐도되는데 최대 100개까지가능하다고함. 3. 스레드풀 기본 스레드 풀이 200개 -> 2000명이 동시에 요청을 보내면 1800명은 대기열에서 기다림. 응답지연 증가.

 

그러면 커넥션풀 max로 땡기고 쓰레드 풀 max로 땡기면안되냐? - 내생각에서 대기 안하고 접수 쌉가능하니까 무조건 그렇게 해야하는거아니냐?

1. 스레드 풀(Thread Pool)을 늘리면?

보통 Spring Boot(Tomcat) 기준 기본 200개인 스레드를 1,000개, 2,000개로 늘리는 경우입니다.

• 긍정적 효과: 더 많은 요청을 '대기'시키지 않고 일단 접수할 수 있습니다. VUs 2,000명이 몰려올 때 "연결 거부"가 일어날 확률이 줄어듭니다.
• 부작용 (Context Switching): CPU 코어 수는 한정되어 있는데 스레드만 많아지면, CPU가 스레드를 갈아 끼우는 데 에너지를 다 써버리는 컨텍스트 스위칭(Context Switching) 오버헤드가 발생합니다. 결국 전체적인 처리 속도(Latency)는 오히려 느려질 수 있습니다.
• 메모리 점유: 스레드 하나당 보통 1MB 내외의 스택 메모리를 사용합니다. 2,000개면 스레드 관리용으로만 약 2GB의 RAM이 추가로 소모됩니다.

2. 커넥션 풀(Connection Pool)을 100개로 늘리면?

DB와 연결된 통로인 HikariCP 등을 100개로 늘리는 경우입니다.

• 긍정적 효과: 동시에 DB 쿼리를 실행할 수 있는 "통로"가 넓어집니다. 스레드가 2,000개여도 커넥션 풀이 10개뿐이면, 나머지 1,990개 스레드는 DB 차례를 기다리느라 놀게 됩니다. 100개로 늘리면 이 병목이 완화됩니다.
• 부작용 (DB 서버 부하): DB 입장에서는 동시에 100개의 쿼리를 쏟아내는 클라이언트를 상대해야 합니다. 개인 PC의 로컬 DB(MySQL 등)가 받아낼 수 있는 디스크 I/O와 CPU 범위를 넘어서면, DB 자체가 뻗거나 쿼리 응답 시간이 수십 배로 늘어납니다.

 

공식적인 가이드: HikariCP 라이브러리 제작자는 커넥션 풀의 개수를 (CPU 코어 수 * 2) + 디스크 숫자 정도로 설정하는 것을 권장합니다. (예: 8코어 PC라면 17~20개 내외) 내 PC는 8코어 이므로 17개정도 추천한다고함. 

 

그럼 도대체 왜 max로 하면안되는데 느려도 결국 수용하는게 중요한거 아닌가 싶은데 

1. 스레드 풀을 Max(2,000개 이상)로 할 때의 문제

메모리가 넉넉해서 스레드 2,000개를 생성하는 것 자체는 문제가 없습니다. 하지만 **CPU 코어(보통 8~16개)**가 이 2,000개를 처리해야 한다는 점이 핵심입니다.

• 컨텍스트 스위칭 오버헤드: CPU는 한 번에 하나의 스레드만 처리할 수 있습니다. 2,000개의 스레드를 번갈아 가며 처리하려면 CPU는 '실제 업무'보다 '어떤 스레드 차례인지 교체하는 작업(Context Switching)'에 더 많은 에너지를 쓰게 됩니다.
• 응답 시간(Latency)의 폭발: 모든 요청을 수락은 하겠지만, 각 요청이 처리되는 시간은 훨씬 길어집니다. 2,000명이 동시에 식당에 들어왔는데 요리사(CPU 코어)는 8명뿐인 상황과 같습니다. 모두가 자리에 앉긴 했지만(Thread 할당), 음식은 한참 뒤에 나오는 것과 비슷하죠.

2. 커넥션 풀(DBCP)을 늘릴 때의 임계점

커넥션 풀을 100개, 혹은 그 이상으로 늘리는 것은 메모리보다는 DB 서버의 사양에 전적으로 의존합니다.

• DB CPU와 I/O 병목: 로컬 DB(MySQL 등)가 사용하는 CPU 코어도 결국 내 PC의 자원입니다. 커넥션이 100개라는 건 DB가 동시에 100개의 쿼리를 연산하고 디스크에서 데이터를 찾아야 한다는 뜻입니다.
• 데드락(Deadlock) 위험: 커넥션이 너무 많으면 여러 스레드가 서로의 자원을 점유하려고 대기하다가 시스템 전체가 멈추는 데드락 발생 확률이 높아집니다.

3. 커넥션 자체의 유지 비용

커넥션을 100개 '연결해 두는 것'만으로도 자원이 소모됩니다.

• 메모리 할당: 각 커넥션은 연결을 유지하기 위한 버퍼 메모리를 점유합니다.
• DB 엔진의 스케줄링: MySQL 같은 DB 엔진도 내부적으로 스레드를 돌립니다. 커넥션이 많아질수록 DB 엔진 자체가 어떤 커넥션의 쿼리를 먼저 처리할지 결정하는 스케줄링 부하가 늘어납니다.

스위칭비용이 더 들어가는 경우가 생겨서 하던일도 못한다고한다. 제한이있다면 스위칭 비용이 적은데 내 성능대비 과도하면? 일처리를 못하고 스위칭 비용만 늘어나는것. 

 

그럼 커넥션을 늘리고 스레드 풀을 늘려 적정인원을 찾았다.

이러면 끝은아닐것이다. 

여전히 문제가 존재한다. 

너무 느리다, 여러 시나리오에서 조회때문에 주문 발주 승인을 못한다, 동시성은 확보가 되긴한건가? 극한으로 진짜 비슷하면 해결된걸까? 100만건의 주문목록이 생기면 어쩔 수 있을까 100건정도 주문이면 explain이 빠르기야하겠지 그런데 100만건이라면? 

 

 

일단 커넥션 풀과 스레드풀을 늘려서 k6 test 돌리고
100만건정도 주문을 생성해서 저장하고 k6 test 돌리고

동시성을 의심해서 해결한다.