주요 성능 병목 지점

병목이 발생하면?

• TPS 가 더 이상 증가되지 않음 -> 응답 속도가 증가

병목이 발생하면 해야 하는 절차

병목의 원인 발견 > 병목 개선 전(현재) 성능 측정 > 병목 원인을 제거하거나 성능 개선 > 병목 개선 후 성능 측정 > 적용 후 병목 제거 여부 확인

• 병목 개선 전 성능 측정
  • 생략하는 경우가 많지만, 의미가 있으므로 측정 단계를 가지자
• 병목은 존재할 수밖에 없다. 또한 하나의 병목을 없애면, 다른 병목이 발생하는 경우도 다반사
  - 지속적인 모니터링을 통해, 반복적으로 성능을 개선하는 자세를 가지자
  

성능 병목 지점들

• Database
  - 대부분의 웹 기반 서비스에서 성능 병목 지점 중 가장 큰 비중을 차지
• Server, 연계 서버, Network, Client, Data format

DB 문제

• 대부분의 서비스들은 DB에 의존하여 데이터를 제공하기 때문에 가장 큰 원인

• DB의 반복적인 접속 문제를 해결하기 위해 DB Connection Pool을 활용
  - 기본적인 값(보통 5~10)을 사용하기 보다는, TPS 를 체크하여 시스템에 맞는 설정이 필요

  WAS CPU 를 100프로 사용할 만큼 Active 유저 수를 늘렸을 때, Active 유저 수가 Connection 수와 유사

  가장 흔한 원인은 Index 문제

  • DB 의 질의를 할 때 WHERE 절에 자주 호출되는 컬럼에 Index가 잡혀 있지 않으면 테이블을 Full Scan 할 수도 있음
    • 데이터가 적을 때에는 문제가 되지 않지만 데이터가 쌓이게 되면 성능에 치명적으로, 서비스 의 데이터가 많아질수록 응답속도가 느려지는 것도 이러한 이유

  꼭 RDMS를 사용해야만 하는가?

  DB의 의존성을 줄이고 성능을 개선시키기 위해서 Cache, 분산 클러스터 컴퓨팅, 검색 서버 등을 많이 활용

  • Cache 를 활용하는 경우
    • 빈번하게 호출되지만 시간이 지나면 변경될 가능성이 높은 데이터를 처리할 때 자주 사용
  • 분산 클러스터 컴퓨팅을 활용하는 경우
    • DB로 처리하는데 제약이 있는 데이터를 처리하기 위해서
      MapReduce 기반의 분산 클러스터 컴퓨팅을 활용하는 경우도 있음
      : 보통 대용량 데이터의 경우 병렬 처리를 위해 사용
  • 검색 서버를 활용하는 경우
    • 문자열 기반의 로그나 검색할 데이터를 처리하기 위해서 활용

CPU 문제

• 애플리케이션 서버의 CPU 에 병목이 발생하는 경우는 크게 세 가지
  - 사용자가 많아서
  - 계산이 많아서
  - 사용자도 많고 계산도 많아서
• 사용자가 많은데 응답속도가 빠름 -> 수평 확장 추천
• 사용자가 많은데 응답속도가 느림 -> 튜닝 후 수직이나 수평 확장 추천
• 계산이 많고 응답속도가 느림 - > 튜닝 후 수직이나 수평 확장 추천
• 사용자도 많고 계산도 많음 -> 무조건 튜닝 후 수직이나 수평 확장 추천

Memory 문제

자바 기반의 애플리케이션은 JVM이 시작되면서 최대 메모리 사용량을 할당하기 때문에, 메모리가 병목일 경우는 많지 않음.
또한 자바 기반에서는 메모리를 늘릴수록 GC 시간이 오래 걸리기 때문에 무조건 늘린다고 좋은 것은 아니다.

용량이큰 파일을 읽어서 처리하는 작업이나, 많은 데이터를 분석해야 하는 작업 등 예외 케이스를 제외하고는 메모리는 2~4GB 추천

• 대용량 엑셀 파일 처리(백만 건, 천만건) 를 하려고 메모리를 늘리는 것보다.
  임시 파일을 만들어 chunk 형식으로 추가하는 방식으로 하는 것을 추천