17강 / 20강

워커를 몇 개 띄울까 — CPU 튜닝

문맥 교환 · 처리량 곡선 · cgroup 제한

gunicorn 설정 파일에 이렇게 적혀 있습니다.

gunicorn -w 3 -b 127.0.0.1:5000 shop:app

-w 3, 워커 3개. 이 숫자는 어떻게 정해야 할까요? 인터넷에는 (2 × 코어) + 1 이라고 나와 있지만, 왜 그럴까요? 그리고 그게 여러분 쇼핑몰에도 맞을까요?

고등학생많을수록 좋은 게 아니다

가장 실전적인 물음 — 워커를 몇 개 띄울까?

늘리면 어느 지점까지 좋아지다가 나빠진다

왜 나빠지나

워커가 늘면	비용
메모리	워커마다 씀 (16강)
문맥 교환	번갈아 하느라 낭비
캐시 경쟁	서로 밀어낸다 (8강)
DB 연결	DB 가 먼저 터진다

코어보다 훨씬 많으면 일보다 관리가 많아진다

비유 — 좁은 부엌의 요리사

인원	결과
1명	느리다
4명	최적
20명	부딪히느라 더 느리다

공간과 도구가 한정돼 있으니까

그래서 곡선이 이렇게 생깁니다

처리량이 올라가다가 평평해지고 내려갑니다.

구간	무슨 일
상승	노는 자원을 쓴다
평평	병목에 도달
하강	관리 비용이 이긴다

평평해지는 직전이 최적점

고등학생문맥 교환이 왜 비싼가

워커가 코어보다 많으면 번갈아 실행합니다. 그 전환이 문맥 교환이에요.

한 번에 1~10 마이크로초 — 작아 보이지만

무엇을 하나

지금 작업의 레지스터를 전부 저장
다음 작업의 레지스터를 복원
TLB · 캐시가 무효화된다 (9·8강)

직접 비용보다 캐시가 깨지는 대가가 크다

숫자로

비용	크기
레지스터 저장/복원	~1μs
캐시 재적재	10~100μs ⚠

초당 10만 번 교환하면? 1~10초 어치 CPU 가 사라집니다.

vmstat 의 cs 열이 그 횟수다

비유 — 여러 과목 동시에 공부하기

방식	결과
수학 1시간 → 영어 1시간	효율적
5분마다 과목 바꾸기	아무것도 못 한다

바꿀 때마다 머리를 다시 채워야 한다 — 그게 캐시 재적재

13강의 인터럽트와 같은 이야기입니다

방해의 비용은 방해 자체가 아니라 복귀에 있습니다. 컴퓨터도 사람도요.

워커를 늘리면 생기는 두 가지 힘

📈

좋은 힘

동시에 더 많은 요청
기다리는 동안 다른 걸 처리

📉

나쁜 힘

문맥 교환 · 캐시 경쟁 · 메모리
일꾼끼리 서로 방해

이 둘이 만나는 지점이 최적입니다. 그리고 그 지점은 작업의 성격에 따라 완전히 다릅니다.

최적 워커 수는 '얼마나 기다리는 작업이냐'가 정합니다.

Python 브라우저에서 실행

물리코어 = 6
논리CPU  = 12

def 처리량(워커, ms당요청, 대기비율):
    """대기비율 = 요청 시간 중 '기다리는' 비율 (DB·외부API·디스크)"""
    # 기다리는 동안은 CPU를 안 쓰므로 워커를 더 띄울 수 있다
    유효 = min(워커, 논리CPU if 대기비율 < 0.3 else 논리CPU * (1 + 대기비율 * 4))
    if 워커 > 물리코어:
        유효 = min(유효, 물리코어 + (워커 - 물리코어) * 0.3)
    # 문맥 교환 손실
    손실 = max(0.5, 1 - max(0, 워커 - 논리CPU) * 0.018)
    return 유효 * 손실 * (1000 / ms당요청)

print("① CPU를 빡빡하게 쓰는 요청 (대기 10%) — 이미지 리사이즈 같은 것")
print(f"{'워커':>6}{'초당 처리':>12}")
for w in [1, 3, 6, 12, 24, 48]:
    print(f"{w:>6}{처리량(w, 45, 0.10):>11.0f}건")

print()
print("② 대기가 많은 요청 (대기 70%) — DB·외부 결제 API를 기다리는 것")
print(f"{'워커':>6}{'초당 처리':>12}")
for w in [1, 3, 6, 12, 24, 48]:
    print(f"{w:>6}{처리량(w, 45, 0.70):>11.0f}건")

print()
print("→ 같은 서버인데 최적 워커 수가 완전히 다릅니다.")
print("  '(2×코어)+1' 은 ② 같은 웹 워크로드를 가정한 경험칙이에요.")

고등학생워커 수를 정하는 실전 순서

note 의 순서를 왜 그런지와 함께.

1단계 — 작업 성격을 판단

성격	기준	공식
CPU 중심	계산이 대부분	코어 수 +1
I/O 중심	DB · API 대기	코어 × 2~4

기다리는 시간이 많으면 더 많이 띄울 수 있다

왜 I/O 는 더 띄우나

워커가 DB 를 기다리는 동안 CPU 는 놉니다. 그때 다른 워커가 일할 수 있죠.

대기 비율	적정 배수
50%	×2
75%	×4

쇼핑몰 웹 서버는 대개 I/O 중심이다

2단계 — 메모리로 상한을 잡는다

워커 수 ≤ (가용 메모리 − 여유) ÷ 워커당 고유 메모리

9강의 PSS 이야기예요. RES 로 계산하면 너무 적게 잡습니다.

3단계 — DB 연결 수를 확인

확인	왜
워커 × 연결 풀 크기	DB max_connections 를 넘으면 안 된다

워커를 늘렸다가 DB 가 연결을 거절하는 사고가 흔하다

4단계 — 실제로 재 본다

공식은 출발점일 뿐입니다. 워커 수를 바꿔 가며 처리량 곡선을 그려요.

15강의 원칙 — 추측 말고 측정

문맥 교환 — 일꾼이 많아질수록 커지는 세금

CPU 하나에 프로세스가 여럿이면 커널이 번갈아 가며 시켜야 합니다. 바꿀 때마다 레지스터를 저장하고, 캐시가 밀려나고, TLB가 무효화돼요. 한 번에 1~10마이크로초씩 사라집니다.

평상시 값을 기억해 두세요. 나중에 비교 기준이 됩니다.

bash 브라우저에서 실행

# cs 칸이 문맥 교환 횟수입니다
vmstat 1 3

cs 와 sy 가 함께 치솟는 걸 보세요. 이게 '너무 많다'의 신호입니다.

bash 브라우저에서 실행

# 워커를 코어보다 훨씬 많이 띄운 상황을 만들어 본다
stress-ng --cpu 48 --timeout 8s

클라우드의 함정 — 내 코어가 내 것이 아니다

클라우드 VM이나 컨테이너에서는 nproc이 12라고 나와도 실제로 12개를 다 쓸 수 있는 게 아닐 수 있습니다.

cgroup 제한 — 컨테이너에 CPU 할당량(quota)이 걸려 있으면 그만큼만 씀
버스트 인스턴스(t 계열) — 크레딧이 떨어지면 성능이 20%로 떨어집니다
스틸 타임 — top의 %st. 같은 물리 서버의 다른 손님이 내 몫을 가져간 시간

물리 서버라 %st 는 0입니다. 클라우드에서는 확인해야 해요.

bash 브라우저에서 실행

# %st(steal) 확인 — 0이 아니면 이웃이 내 CPU 를 쓰고 있다
top | head -6
echo "=== 이 서버가 실제로 쓸 수 있는 CPU ==="
nproc
getconf _NPROCESSORS_ONLN

고등학생버스트 인스턴스로 쇼핑몰을 돌리면

note 의 이 경고가 클라우드에서 가장 흔한 사고입니다.

t 계열 인스턴스는 평소 성능이 낮고 잠깐만 빠르다

어떻게 동작하나

크레딧을 모았다가 씁니다. 17강 시작에서 본 토큰 버킷과 같은 구조예요.

상태	성능
크레딧 있음	100%
크레딧 소진	20~40% ⚠

평소엔 빠른데 바쁠 때 느려진다 — 최악의 조합

왜 최악인가

부하가 없을 땐 크레딧이 쌓입니다. 그래서 시험할 땐 잘 돕니다.

그런데 실제 트래픽이 오면 크레딧을 태우고 바로 그때 성능이 떨어져요.

테스트에서 안 잡히고 실전에서 터진다

비유 — 휴대폰 배터리 절약 모드

배터리가 넉넉할 땐 빠릅니다. 20% 밑으로 떨어지면 느려져요.

그런데 하필 많이 쓰는 날에 배터리가 빨리 닳죠. 필요할 때 느려지는 구조입니다.

여유는 필요 없을 때 쌓이고, 바쁠 때 사라진다

어떻게 대응하나

방법	설명
크레딧 지표 감시	CPUCreditBalance 를 본다
Unlimited 모드	추가 요금으로 계속 빠르게
고정 성능 인스턴스	c · m 계열로 바꾼다

개발·테스트는 t 계열, 운영은 고정 성능 — 일반적인 원칙

15강의 %st(도둑맞은 시간)가 여기서 크게 뜁니다. 진단의 실마리예요.

워커 종류도 골라야 합니다

방식	동시성	언제 쓰나
sync (기본)	워커 수만큼	CPU 위주. 단순하고 안전. 대기가 길면 낭비
gthread	워커 × 스레드	DB·API 대기가 많을 때. 메모리 효율이 좋다
gevent/async	수천	대기가 압도적일 때. 코드가 그걸 지원해야 함

쇼핑몰 대부분은 DB를 기다리는 시간이 절반 이상입니다. 그래서 -w 4 --threads 4 처럼 스레드를 섞는 게 -w 16 보다 메모리를 4분의 1만 쓰면서 비슷한 동시성을 냅니다.

대기가 많은 워크로드에서는 스레드가 메모리를 아껴 줍니다.

Python 브라우저에서 실행

# sync 워커 16개 vs 워커4×스레드4 — 메모리 비교
워커메모리 = 340
스레드추가 = 12      # 스레드 하나 추가 비용은 훨씬 작다

sync16 = 16 * 워커메모리
gthread = 4 * (워커메모리 + 3 * 스레드추가)

print(f"sync 워커 16개        : {sync16:>6,} MiB")
print(f"워커 4 × 스레드 4     : {gthread:>6,} MiB")
print(f"→ 동시성은 비슷한데 메모리는 {sync16/gthread:.1f}배 차이")
print()
print("단, 스레드는 파이썬 GIL 때문에 '계산'은 동시에 못 합니다.")
print("'기다리기'만 동시에 됩니다 — 그래서 DB 대기가 많을 때만 이득이에요.")

🤔 확인 문제

워커를 12개에서 24개로 늘렸더니 처리량이 오히려 줄고 %sy와 cs가 급증했습니다. 무엇이 문제인가요?

해설 sy(커널 시간)와 cs(문맥 교환)가 함께 뛰는 건 커널이 프로세스를 바꿔 끼우느라 바쁘다는 신호입니다. 일꾼이 많아진 게 아니라 교대 비용이 커진 거예요. 되돌리는 게 답입니다.

🤔 확인 문제

DB 조회를 기다리는 데 요청 시간의 70%를 쓰는 쇼핑몰입니다. 6코어 서버에서 어떤 설정이 가장 합리적일까요?

해설 기다리는 동안 CPU는 놉니다. 그 틈에 다른 요청을 처리하게 해야 코어가 쉬지 않아요. 다만 메모리 상한(16강)과 문맥 교환 비용이 있으니 100개는 지나칩니다. -w 4 --threads 4 같은 조합이 메모리 대비 효율이 좋습니다.