cs roadmap
overview
CS는 많이 보는 게 아니라 순서가 중요함. 백엔드 기준 핵심 축은 4개.
- 운영체제
- 네트워크
- 데이터베이스
- 분산시스템
이 4개가 성능/장애 원인을 설명하는 기본 틀.
1) 운영체제
CPU, 메모리, 스레드 실행을 관리. 스레드 과다하면 컨텍스트 스위칭 늘고 p99 튐. 메모리 압박 오면 GC/페이지폴트로 지연 커짐.
운영체제 = 코드가 실제로 도는 바닥 조건.
예시
- 증상: CPU 50%인데 API 느림
- 실제: 스레드 500개라 run queue 길어짐, 스위칭 비용으로 p99 악화됨
- 조치: 스레드풀 축소 + 작업 분리(CPU/I-O)
2) 네트워크
요청은 코드만 빠르다고 끝 아님. DNS, TCP, TLS, HTTP 비용이 계속 붙음. RTT 크면 같은 로직도 체감 느림.
네트워크 = 요청 이동 비용.
예시
- 증상: 로직 20ms인데 사용자 체감 400ms
- 실제: DNS 지연 + TLS 재수립 + 원거리 RTT 누적
- 조치: keep-alive, connection reuse, DNS 캐시 점검
3) 데이터베이스
대부분 병목은 결국 DB에서 터짐. 인덱스/실행계획/락/트랜잭션 모르면 성능 급락. DB 풀 설정도 처리량에 직접 영향 줌.
DB = 정확성과 성능의 타협점.
예시
- 증상: 특정 API만 갑자기 2초대
- 실제: 인덱스 미스 + 풀스캔 + 락 대기
- 조치: 실행계획 확인, 인덱스 보강, 트랜잭션 범위 축소
4) 분산시스템
스케일아웃하면 처리량은 늘지만 복잡도도 같이 늘어남. 캐시 정합성, 재시도 폭증, 장애 전파가 대표 이슈.
분산 = 확장성과 복잡성의 교환.
예시
- 증상: 한 서비스 장애가 전체 장애로 번짐
- 실제: timeout 길고 retry 무제한이라 재시도 폭풍 발생
- 조치: timeout 단축, 지수 백오프, 서킷브레이커 적용
연결해서 보기
“API 느림” 하나도 보통 복합 원인.
- OS: run queue 증가, 스레드 경합
- Network: RTT 증가, 연결 재수립
- DB: 슬로우쿼리, 락 대기
- Distributed: 재시도 폭증, 캐시 스탬피드
단일 원인 찾는 습관 버리고 계층별로 같이 봐야 함.