20강 / 20강

블랙프라이데이 — 어디가 먼저 터질까

20강 전부를 한 판에 쏟아붓는 실전

드디어 마지막 강입니다. 지금까지 배운 걸 전부 써서 진짜 상황을 다뤄 봅시다.

오늘 밤 자정에 블랙프라이데이 세일이 시작됩니다.
평소 초당 30건이던 요청이 초당 300건으로 뜁니다.
서버는 6코어 16GB NVMe 한 대. 여러분은 무엇을 준비해야 할까요?

고등학생어디가 먼저 터질까

마지막 강은 실전 시뮬레이션입니다. 19강의 지식을 한 판에 쏟아붓죠.

평소의 10배 트래픽이 온다 — 어디가 먼저 무너지나

순서를 예측해 봅시다

순서	무너지는 곳	왜
1	DB 연결	연결 수가 먼저 찬다
2	DB 디스크	fsync 가 몰린다 (18강)
3	앱 메모리	워커가 붓는다 (16강)
4	CPU	대개 마지막

사람들이 걱정하는 CPU 는 대개 가장 나중에 터진다

왜 DB 가 먼저인가

19강에서 봤듯 DB 쓰기는 아웃이 안 됩니다. 앱 서버는 늘려도 DB 는 한 대예요.

나눌 수 없는 곳에 부하가 모인다

비유 — 콘서트장 출구

공연이 끝나면 수천 명이 한꺼번에 나갑니다.

곳	병목인가
객석 통로	여러 개 — 괜찮다
출구 문	몇 개뿐 — 여기서 막힌다

가장 좁은 곳이 전체 속도를 정한다

그리고 출구를 넓히면 다음 좁은 곳이 나타납니다. 그게 이 강의 마지막 교훈이에요.

고등학생부하가 오기 전에 해야 할 일

블랙프라이데이 당일에는 할 수 있는 게 별로 없습니다.

준비는 몇 주 전에 끝나 있어야 한다

준비 목록

시기	할 일
몇 주 전	부하 시험 — 한계를 안다
몇 주 전	병목 하나를 고친다
며칠 전	다시 부하 시험 — 병목이 옮겨졌나
당일	지켜보고 스위치를 내린다

당일에 할 일은 끄는 것뿐이다

무엇을 끄나 — 우아한 성능 저하

17강의 거절의 예의와 같은 발상입니다.

기능	부하 시
주문 · 결제	지킨다 — 매출
상품 조회	지킨다 (캐시로)
추천 · 개인화	끈다
실시간 통계	끈다
리뷰 작성	끈다

전부 지키려다 주문까지 잃는 것보다 낫다

비유 — 비행기의 무게 줄이기

연료가 모자라면 짐부터 버립니다. 승객을 버리지 않죠.

무엇이 승객이고 무엇이 짐인지 미리 정해 둔다

당일에 판단하려면 늦습니다. 끄는 스위치를 미리 만들어 두세요.

① 먼저 한계를 계산합니다

"터질 것 같다"가 아니라 "초당 몇 건에서 터진다"를 알아야 합니다.

자원마다 한계를 따로 계산하면 병목이 보입니다.

Python 브라우저에서 실행

물리코어   = 6
논리CPU    = 12
메모리MiB  = 16384
회선_Mbps  = 1000

요청당_ms    = 45
대기비율     = 0.65        # DB·외부 API 기다리는 비율
요청당_KB    = 850         # 응답 크기 (이미지 포함)
요청당_fsync = 0.4         # 요청 4건에 1건꼴로 쓰기가 있다
fsync_us     = 900
워커         = 13
워커MiB      = 340

# ── 한계를 자원별로 따로 계산한다 ─────────────────────
cpu_ms   = 요청당_ms * (1 - 대기비율)
한계_cpu = 물리코어 * 1000 / cpu_ms

한계_동시성 = 워커 / (요청당_ms / 1000)

한계_디스크 = 1_000_000 / fsync_us / 요청당_fsync

한계_회선 = (회선_Mbps * 1000 * 1000 / 8) / (요청당_KB * 1024)

메모리_필요 = 780 + 워커 * 워커MiB
메모리_여유 = 메모리MiB - 메모리_필요

print(f"{'자원':<14}{'한계 (초당 요청)':>20}")
print("-" * 36)
for 이름, v in [("CPU", 한계_cpu), ("워커 동시성", 한계_동시성),
                ("디스크(fsync)", 한계_디스크), ("네트워크 회선", 한계_회선)]:
    print(f"{이름:<14}{v:>17,.0f}건")

print()
병목 = min([("CPU", 한계_cpu), ("워커 동시성", 한계_동시성),
            ("디스크", 한계_디스크), ("네트워크", 한계_회선)], key=lambda x: x[1])
print(f"→ 가장 먼저 터지는 곳: {병목[0]}  (초당 {병목[1]:,.0f}건)")
print(f"   목표는 초당 300건 … {'✓ 버틴다' if 병목[1] >= 300 else '✗ 못 버틴다'}")
print()
print(f"메모리: {메모리_필요:,} / {메모리MiB:,} MiB  (여유 {메모리_여유:,} MiB)")

계산해 보면 네트워크 회선이 가장 먼저 막힙니다. 850KB짜리 페이지를 1Gbps로 뿌리면 초당 147건이 천장이거든요.

CPU를 아무리 늘려도 소용없습니다. 회선을 넓히거나, 보낼 양을 줄여야 해요.

② 대응책의 효과를 계산합니다

가장 싼 대응이 가장 효과가 큰 경우가 많습니다.

Python 브라우저에서 실행

회선_Mbps = 1000
초당_바이트 = 회선_Mbps * 1000 * 1000 / 8

대응 = [
    ("아무것도 안 함",                 850, 1.0),
    ("이미지를 CDN 으로",              180, 1.0),
    ("+ gzip/brotli 압축",             120, 1.0),
    ("+ 상품목록 캐시(DB 부하 -60%)",  120, 1.0),
]

print(f"{'대응':<34}{'페이지':>9}{'회선 한계':>13}")
print("-" * 58)
for 이름, kb, _ in 대응:
    한계 = 초당_바이트 / (kb * 1024)
    표시 = f"{한계:,.0f}건"
    print(f"{이름:<34}{kb:>7}KB{표시:>13}")

print()
print("→ CDN + 압축만으로 회선 한계가 147 → 1,041건이 됩니다.")
print("  서버는 한 대도 안 늘렸는데요. 비용도 CDN 요금뿐이에요.")
print()
print("이제 다음 병목이 무엇인지 다시 계산해야 합니다.")
print("병목을 하나 없애면 그다음 병목이 드러납니다 — 이게 튜닝의 본질입니다.")

고등학생튜닝의 규칙 — 병목은 옮겨 다닌다

note 의 이 문장이 이 강의 전체의 결론입니다.

병목을 고치면 병목이 사라지는 게 아니라 옮겨 간다

실제로 이렇게 흘러갑니다

회차	병목	조치	결과
1	디스크 (%wa 60%)	NVMe 로 교체	3배
2	DB 연결 고갈	풀 크기 조정	1.5배
3	CPU (%us 90%)	코어 증설	1.4배
4	네트워크	10G 로	1.2배

매번 다른 곳이 병목이 된다 — 그래서 매번 다시 잰다

왜 이런가

시스템은 가장 느린 곳에 맞춰 돕니다. 그곳을 고치면 두 번째로 느린 곳이 드러나요.

병목은 상대적이다 — 항상 어딘가는 가장 느리다

비유 — 물통의 가장 낮은 판자

나무판을 이어 만든 물통은 가장 낮은 판자까지만 물이 찹니다.

그 판자를 높이면? 다음으로 낮은 판자가 한계가 되죠.

한 판자만 높여도 조금씩은 올라간다 — 그래서 반복한다

언제 멈추나

기준	판단
목표 처리량 달성	멈춘다
비용 > 이득	멈춘다
병목이 코드로 옮겨감	하드웨어는 그만

"완벽하게 빠른" 시스템은 없다 — 충분히 빠른 것만 있다

③ 세일 당일 무슨 일이 벌어지나 — 직접 겪어 봅시다

평상시 상태를 먼저 기록해 둡니다.

bash 브라우저에서 실행

# 자정. 트래픽이 몰려들기 시작한다.
top | head -8

us 가 90%대로. load 가 코어 수를 넘어갑니다.

bash 브라우저에서 실행

# CPU 가 갈려 나가기 시작
stress-ng --cpu 12 --timeout 6s

메모리를 무리하게 쓰면 어떻게 되는지 봅니다.

bash 브라우저에서 실행

# 워커를 늘렸더니 메모리가 …
stress-ng --vm 1 --vm-bytes 13G --timeout 6s
free -h

wa 가 치솟고 b(블록된 프로세스)가 생깁니다.

bash 브라우저에서 실행

# 결제가 몰려 디스크가 비명을 지른다
stress-ng --io 6 --timeout 6s
vmstat 1 3

④ 실전 체크리스트

세일 전날에 해 둘 일들입니다. 당일에는 이미 늦어요.

언제	할 일	왜 (몇 강)
전날	평상시 지표를 기록해 둔다	비교 기준이 없으면 진단 불가 (15강)
	디스크 여유 20% 이상 확보	SSD는 꽉 차면 느려진다 (12강)
	이미지를 CDN으로, 압축 켜기	회선이 첫 병목 (13강)
	로그 로테이션·백업을 세일 시간 밖으로	디스크를 뺏기지 않기 (18강)
	워커 수를 부하 테스트로 정해 둔다	추측 금지 (17강)
당일	`vmstat 1` 을 띄워 둔다	si/so·wa·r 을 실시간 감시 (15강)
	느려지면 측정부터, 설정 변경은 그다음	오진이 가장 비싸다 (15강)
	최악의 경우 대기열로 전환	죽는 것보다 느린 게 낫다 (19강)
다음 날	지표와 로그를 저장해 둔다	내년의 기준선이 된다
다음 날	실제 병목이 어디였는지 기록	다음 투자를 정하는 근거

⑤ 마지막으로 — 20강을 한 장으로

느린 서버 앞에 앉았을 때, 이 순서로 생각하세요.

1. 무엇을 기다리는가?
   us 높음 → CPU가 계산 중        → 코드·코어      (5,10,11,17강)
   wa 높음 → 디스크를 기다림      → SSD·fsync·캐시 (7,12,18강)
   si/so   → 메모리 부족          → 증설·워커 감소 (9,16강)
   si 높음 → 패킷 폭주            → CDN·LB         (13강)
   전부 낮음 → 락·외부 API 대기   → 애플리케이션

2. 그 자원의 한계는 초당 몇 건인가?     (19,20강)
3. 가장 싼 대응부터 적용한다.           (CDN > 캐시 > 설정 > 하드웨어)
4. 다시 측정한다. 병목은 옮겨 다닌다.

이 네 줄이 컴퓨터 구조를 배운 이유입니다. 서버 안에서 무슨 일이 벌어지는지 알면, 어디에 돈과 시간을 쓸지 알 수 있습니다.

고등학생20강을 한 장으로

여기까지 오신 것을 축하합니다. 🎉 상자 안에 무엇이 있나 로 시작해 여기까지 왔어요.

배운 것을 한 표로

층	배운 것	강
표현	비트 · 2의 보수 · 실수 오차	2·3강
회로	게이트 · CPU · 기계어	4·5·6강
기억	계층 · 캐시 · 가상 메모리	7·8·9강
동시성	파이프라인 · 암달의 법칙	10·11강
입출력	IOPS · DMA · 인터럽트	12·13강
운영	진단 · 튜닝 · 구매 판단	14~20강

그런데 진짜 남는 것은 부품 이름이 아닙니다

배운 것은 기다림이 어디서 생기는지 보는 눈이다

다섯 가지 물음

지금 어디서 기다리고 있나 (15강)
이 숫자는 평소와 비교해 어떤가 (14강)
이 부분은 나눌 수 있나 (11강)
순차인가 랜덤인가 (12강)
돈을 쓰기 전에 측정했나 (15·19강)

이 다섯이면 대부분의 성능 문제가 보인다

그리고 반복해 나온 맞바꿈

얻는 것	내주는 것	어디서
속도	공간	캐시 (8강)
속도	안전	fsync (18강)
속도	보안	분기 예측 (10강)
격리	번역 비용	가상 메모리 (9강)

공짜는 없다 — 무엇을 내줄지 고르는 것이 설계다

이제 대학생 눈높이로 한 번 더 읽어 보세요. 숫자와 명령어가 훨씬 잘 읽힐 겁니다.

🤔 확인 문제

초당 300건 목표인데 계산 결과 CPU 한계 380건, 디스크 한계 2,500건, 회선 한계 147건이 나왔습니다. 무엇을 해야 할까요?

🤔 확인 문제

병목 하나를 해결했더니 이번엔 다른 곳이 느려졌습니다. 이건 실패인가요?