20.6 관련 시스템 튜닝

성능의 80%는 애플리케이션 설계 시 결정되지만, 단순한 실수로 성능의 문제가 발생하는 경우도 있다. 문제가 발생하였을 때 논리적으로 어느 부분이 병목인지 조사해 볼 수 있는 몇 가지 예를 살펴보자.

웹 서버 튜닝

예를 들어 Apache 경우 대량의 접근이 급격하게 집중했을 경우, 많은 부하를 안정적으로 처리하기 위해 다음 파라미터를 조정한다.

현상

HTTP 서버의 큰 역할은 웹 브라우저에서 요청한 정적 파일을 브라우저로 다시 전송하는 것이다. 즉, 크기가 큰 이미지 파일이 많이 포함된 페이지가 많은 경우 자주 다운로드하기 때문에 웹 서버의 부하가 높다. HTTP 서버의 부하가 높아지면 당연히 Java 애플리케이션 서버로 중계하는 통신 프로세스가 느려져 전체적으로 성능이 감소할 수 있다.
조치

웹 서버의 하드웨어 성능 향상을 하는 것이 해결 방법이다. 즉 하드웨어 CPU 수, 메모리 등을 업그레이드한다. 또는 로드밸랜서(L4) 등을 통하여 웹 서버 시스템을 Scale-Out 한다.

현상

SSL을 사용하는 페이지가 많은 경우 성능이 감소 될 수 있다. SSL을 사용하면 약 CPU를 30% 정도 추가 요구한다.
조치

하드웨어 업그레이드나 웹 서버에 대한 Scale-Out을 통한 해결방법이 있다. SSL로 인해 성능 문제가 되는 경우 SSL을 사용하는 페이지 개수를 줄이는 것도 튜닝 방법의 하나다.

데이터베이스 성능 튜닝은 애플리케이션 서버와 관련성이 없다. 일반적인 데이터베이스 튜닝 작업을 진행한다.

애플리케이션 서버의 성능 문제 원인을 찾는 것은 어렵다. 사실, 문제의 원인을 찾는 것은 그렇게 단순하지 않고 개발한 코드가 성능을 감소시키는 원인일 경우가 많다. 이것을 어떻게 찾아가면 좋을까?

웹 시스템의 계층별 부하 상황 파악

HTTP 서버, 애플리케이션 서버, 데이터베이스 서버의 부하 데이터를 얻는다. 부하 테스트 도구를 이용하면 좋을 것이다. 만약 하나의 서버만 과부하 상태라면 위에서 설명한 것과 같은 항목을 의심하고 원인을 조사하자.
구간별 네트워크 부하 데이터를 파악

인터넷, HTTP 서버, 애플리케이션 서버, 데이터베이스 서버 사이의 네트워크 부하 상태를 확인한다. 네트워크 로드가 높은 경우는 부하를 주는 패킷이 무엇인지를 확인한다. 대부분은 애플리케이션을 실행하는 웹 애플리케이션 서버가 병목이 될 가능성이 가장 높다고 할 수 있다. 먼저 HTTP 서버를 시스템에서 분리하여 테스트한다. 일반적인 방법으로 웹 서버에 걸리는 부하를 애플리케이션 서버에 직접 걸어 테스트하여도 여전히 성능이 나오지 않는 경우엔 애플리케이션 서버 내에서 더 자세히 확인해야 한다.

부하 테스트 도구를 사용해도 애플리케이션 서버의 CPU 사용률이 오르지 않으면 어떤 리소스에 락이 걸려 그 락이 풀리기를 기다리고 있을 수 있다. 일반적인 원인으로 생각되는 것들은 다음과 같다.

커넥션 풀의 대기

우선 생각할 수 있는 것은 SQL 처리에 시간이 걸리는 경우이다. 커넥션 풀 수가 부족해서 여러 스레드가 데이터베이스 연결을 얻기 위해 대기한다.
동기화 객체 사용

동기화(synchronized)를 정의하는 클래스를 구현하는 경우에 발생한다. 특히 syncronized가 선언된 클래스나 메서드의 처리가 느린 경우 리소스가 해제될 때까지 다른 스레드가 기다리게 된다.
스레드 데드락

애플리케이션 서버 내에서 사용자 프로그램이 스레드를 생성하여 동기화 같은 경우는 많지 않다. 스레드를 사용할 때는 많은 주의가 필요하다. 스레드 데드락은 스레드 덤프를 출력하면 표시된다.

위 같은 경우는 부하가 높은 상태에서 교착 상태(여러 스레드가 서로 대기 있고, 락이 걸리는 현상, Dead Lock)가 되기 쉽다. 따라서 성능 감소와 함께 교착 상태에 빠져 있지 않은지도 확인하는 것이 좋다.