수직 확장, 수평 확장 뭐가 좋음? - 성능 개선(수직 확장, 수평 확장)

서비스를 운영하다 보면 사용자 수나 트래픽이 증가하면서 응답 시간이 점차 느려지는 문제가 발생할 수 있다.

• 전체 요청 응답 시간이 길어지고, 일부 요청은 10초 이상 걸리기도 함
• 간헐적으로 연결 시간 초과 오류가 발생
• 서버 재시작 시 일시적으로 해결되지만 곧 같은 현상이 반복

이러한 문제의 근본적인 원인은 TPS(Transaction Per Second), 즉 초당 처리 가능 요청 수를 초과하는 트래픽이 유입되기 때문이다. 모니터링 도구를 활용해 실행 시간을 추적하거나 모니터링 도구가 없다면 로그라도 남겨야 한다. 

 

 

수직 확장

 급한 불을 끌때는 수직확장을 고려해볼 필요가 있다. 수직 확장은 기존 서버의 성능 자체를 향상시키는 방식이다. 즉, 하나의 서버에 더 좋은 하드웨어(CPU, 메모리, 디스크 등)를 추가하는 것임.

• 빠르고 간단하게 적용 가능 (특히 클라우드 환경에서)
• 기존 구조나 네트워크 설정을 거의 바꾸지 않아도 됨

즉각적인 효과는 얻을 수 있지만, 트래픽이 지속해서 증가한다면 똑같이 성능 문제가 발생할 수 있다. 또한 하드웨어 한계가 존재해 무한이 늘릴 수 없으며, 리소스가 증가할 수록 비용이 기하급수적으로 늘어난다.

 

 

수평 확장

그렇다면 수평 확장을 고려해볼 필요가 있다. 수평 확장은 서버의 개수를 늘리는 방식이다. 같은 스펙의 서버를 여러 대 두고, 트래픽을 분산 처리하는 구조임.

• 트래픽이 증가해도 유연하게 대응 가능
• 서버 1대가 죽어도 나머지 서버가 서비스 지속 (고가용성)
• 클라우드 환경에서 자동 확장(Auto Scaling) 적용 가능

하지만 수평 확장도 무조건 좋은 것은 아니다. 구조 설계가 복잡해지거나(로드 밸런서, 세션 공유, DB 분산 처리 등 고려 필요), 초기 설정 비용이 높을 수 있다. 또한 서버 간 데이터 일관성, 동기화 문제 발생 가능성도 존재한다.

 

 

 

 

확장은 '무턱대고'가 아닌 '진단 후 설계'

 TPS를 높이기 위해 무턱대고 서버를 늘리면 안된다. 진짜 병목이 DB, 외부 API, 캐시 미스, 네트워크 대역폭에 있다면 서버 확장은 소용없다. APM(Application Performance Monitoring) 도구로 병목 지점 식별하거나, 로그 기반으로 평균 응답 시간, 쿼리 처리 시간 분석하는 등 전략적으로 접근해야 한다.