개별 서비스를 어떻게 확장하고 성능 병목을 어떻게 찾나요?

Question

Accepted Answer

마이크로서비스의 핵심 이점은 전체 앱을 확장하는 대신 **각 서비스를 자체 부하에 맞춰 독립적으로 확장**하는 것입니다. 그러면 병목 찾기는 서비스별, 홉별로 측정하는 문제가 됩니다.

## 확장 기법

- **수평 확장** — 로드 밸런서 뒤에 무상태(stateless) 인스턴스 추가.
- **오토스케일링** — CPU, 메모리, 큐 깊이, 또는 커스텀 지표로 확장.
- **캐싱** — 반복 작업과 다운스트림 부하 절감.
- **비동기 + 큐** — 스파이크 흡수; 느린 작업 분리.
- **데이터 확장** — 읽기 복제본, 샤딩, 서비스별 저장소.

```yaml
# Kubernetes HPA: orders를 CPU로 확장
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # 평균 CPU > 70%일 때 파드 추가
```

## 병목 찾기

```text
1. 지표: 어떤 서비스가 높은 지연 / 포화 상태인가?(RED/USE)
2. 트레이스: 요청에서 어떤 SPAN이 느린가?
3. 파고들기: DB 쿼리? 락? N+1 호출? GC 일시정지?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 여기서 지연의 80%
                       Inventory ─┤
```

## 흔한 병목

```text
⚠️ 수다스러운 동기 호출(요청당 팬아웃)
⚠️ 공유/과부하된 데이터베이스
⚠️ 캐시 누락 또는 콜드 캐시
⚠️ 부하를 증폭하는 무제한 재시도
```

## 함정

병목이 **공유 데이터베이스**인 서비스를 확장하면 DB에 더 많은 부하만 옮겨갈 뿐입니다. 증상이 아니라 실제 제약을 확장하세요.

## 왜 중요한가

독립적 확장은 부하가 있는 곳에 정확히 용량을 쓸 수 있게 해주며, 이는 모놀리스를 통째로 확장하는 것보다 훨씬 저렴합니다.

하지만 맹목적 확장은 돈을 낭비하고 상황을 악화시킬 수 있습니다. 서비스별 지표와 홉별 트레이스를 측정하는 것이 고쳐야 할 실제 제약을 알려줍니다.