AI 시대의 소프트웨어 시스템 실험실
트래픽이 2배가 되면
응답시간은 왜 20배가 될까?
"파드를 늘리면 되지 않나?" — 스케일아웃으로 풀리지 않는 문제들이 있습니다. 겪어보지 않으면 있는지조차 모르는 종류의 문제들이에요. 여기서는 그걸 글로 읽는 대신, 브라우저에서 직접 터뜨려봅니다. 그리고 같은 문제가 TypeScript application, Kubernetes와 AWS에서 어떤 결정으로 이어지는지 연결합니다.
↓ 아래는 설명이 아니라 지금 돌아가고 있는 시뮬레이션입니다. 슬라이더를 움직이면 즉시
반응합니다.
커넥션 풀 실험실
감당 불가입니다. 들어오는 속도(300/초)가 처리 한계(200/초)보다 빠릅니다. 줄은 영원히 길어지고, 기다리다 지친 요청은 타임아웃 에러가 됩니다.
처리량
0.0/초
에러율
0.0%
응답시간 p50
—
응답시간 p99
—
대기줄
0명
실제 유입
0.0/초
필요한 창구 수 = 도착 300/초 × 처리 0.050초 = 15.0개
지금 있는 창구 = 10개 → 이용률 150% ← 100%를 넘으면 줄이 무한히 길어집니다
이 설정의 처리량 한계 = 창구 10개 ÷ 0.050초 = 200/초 (아무리 기다려도 이보다 많이는 못 나감)
1초에 몇 개의 요청이 들어오는지.
동시에 DB를 쓸 수 있는 요청의 최대 개수. 늘리면 DB가 부담을 집니다.
인덱스가 빠지면 이 값이 10배가 됩니다. 그때 무슨 일이 일어나는지 보세요.
이 시간을 넘게 기다리면 에러를 내고 나갑니다.
이 사이트가 다른 점
읽지 말고 만지세요
모든 개념에 실제로 돌아가는 시뮬레이터가 붙어 있습니다. 값을 바꾸면 결과가 바로 바뀝니다.
곱셈 하나면 됩니다
용어를 외우게 하지 않습니다. 중학교 수학으로 설명하고, 그 위에 용어를 나중에 붙입니다.
챌린지로 확인
각 주제 끝에 제약 조건이 있는 문제가 나옵니다. 배운 걸 써야만 통과합니다.
실험 목록
01 커넥션 풀 고갈 트래픽이 2배가 되면 왜 응답시간은 2배가 아니라 20배가 될까? 12분 → 02 Queue의 감각 이용률 70%와 95%는 뭐가 그렇게 다른가? 10분 → 03 p50과 p99 평균 응답시간은 멀쩡한데 왜 사용자는 느리다고 할까? 10분 →
나머지 59개는 로드맵에 순서대로 정리해 뒀습니다. 하나씩 채워 나가는 중입니다. 로드맵 →