DevOps/성능 테스트

병목현상이란? (원인과 대책)

chanstory 2023. 3. 3. 11:50
반응형

병목현상 이란?

- 시스템 내에서 전체적인 처리 속도를 떨어뜨리게 되는 특정한 부분을 가리키는 용어

- 시스템의 CPU나 메모리, 디스크 등의 자원 중 하나가 다른 자원들에 비해 처리 속도가 느려서, 전체적인 성능을 제한하는 경우를 말함

- 효율적인 자원분배 및 최적화를 고려해야함

 

 

 

응답성능에 대한 병목현상 원인

- 네트워크 대역폭 부족

- 하드웨어 자원 부족

- 어플리케이션 설계의 문제

- 데이터베이스 부하

 

 

 

Throughput 개선

- 시스템의 흐름을 고속도로에 비유해보자 

- 대구와 부산 사이에 병목현상이 발생하고 있다.

- 통행량을 늘려 병목현상을 해결한다.

- 처리량에 대해서 네트워크 대역폭이나 부족한 자원을 증가시켜 처리할 수 있다.

** Throughtput의 개선이 Latency 개선으로 이어진다. '대기 시간'에 문제가 있었기 때문

 

 

Latency 개선

어플이케이션 개선

- Latency 개선은 어플리케이션을 개선하는 것으로 시작

- 어플리케이션 성능 최적화는 현상을 파악 (Application Performance Monitoring) 하는 것으로 시작

- 알고리즘 개선, I/O 최소화 등의 개선 방안이 뒤따름

- DevOps가 이를 모니터링 할 수 있으나 개발자가 APM 도구와 프로파일러 등을 이용해 이를 개선

 

 

 

응답 성능의 병목 원인과 대책

1. 많은 사용자의 서비스 등록

2. 많은 데이터의 저장1,2번과 같은 경우 DB에 데이터가 증가합니다.
-> secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나, 검색에 최적화된 인덱스 사용을 고려할 수 있습니다.

3. 단기간 동안의 사용자 요청 증가(peak traffic)
-> Auto Scaling이 해결책이 될 수 있습니다. 다만 버스트 성능에 대해 이해해야 합니다.

4. 배치 작업을 진행하는 데이터베이스
-> DB가 주기적으로 스냅샷을 만들거나, 데이터 일관성을 위해 레플리카와의 sync 과정을 진행하는 등의 배치 작업이 이루어질 경우, primary DB는 성능 저하가 발생할 수 있습니다. 이 때 사용자들의 요청과 맞물려 서비스 수준을 맞추기 어려울 수 있습니다.

5. 많은 양의 로그 수집 처리
-> 애플리케이션이 잘 작동할 때에는 로그를 많이 남기지 않지만, 애플리케이션에 문제가 발생하면 추적을 위해 많은 로그를 남깁니다. 다만 이러한 상황이 반복적으로 진행될 경우, 에러 로그 수집 그 자체가 애플리케이션 병목을 일으킬 수 있습니다.

6. 시스템 재시작 후의 캐시 초기화
-> 큰 문제를 발생시키는 것은 아니지만, 캐시가 초기화되면서 시스템으로 직접적인 요청 횟수가 증가할 수 있습니다.

 

 

AWS 주요 병목 구간 & 부하 테스트 시 고려 할 부분

 

 

 

반응형