Capacity Anti-Patterns(용량 안티패턴) -1

리소스 풀 경쟁

리소스 풀은 잘 사용한다면, 모든 연결 풀은 작업량을 향상시킴으로써 용량을 개선할 수 있다. 그렇지만 방치해 버린다면, 순식간에 리소스 풀은 어플리케이션에서 가장 큰 병목구간이 될 수 있다.

자원에 대한 경쟁이 있을 때 병목현상이 일어난다. 더 많은 쓰레드가 가용한 것 이상으로 하나의 자원을 요구한다. 이런 경우, 대부분의 연결 풀은 자원이 가용할 때 까지 요청하는 쓰레드를 무한정 블록 할 것이다.

이상적으로, 모든 쓰레드는 필요한 자원을 즉시 얻어야 한다. 이것이 보장되려면, 쓰레드의 개수와 리소스 풀의 크기를 동일하게 해야 한다. 이것이 어플리케이션 서버에서 경쟁을 완화시키지만, 문제는 데이터베이스 서버로 옮겨갈 수 있다.

자원이 고갈되었을 때 막연히 블록 되는 것은 확실히 안정성 문제를 일으킨다. 리소스 풀이 제한된 시간 동안만 블록 되게 설정된다면 시스템은 더 잘 동작할 것이다. 가용한 자원이 없기 때문에 시간이 만료되면, 풀은 null을 돌려주거나 예외를 던져야 하며, 어플리케이션 코드는 이런 일이 일어날 것에 대비해야 한다.

• 정상적인 부하상태에서 경쟁을 제거하자.

• 가능하다면, 요청 쓰레드 풀 수준으로 리소스 풀의 크기를 맞추자.

• 요청을 처리하는 쓰레드가 리소스를 필요로 할 때 항상 자원이 준비되어 있다면, 오버헤드에 따른 효율 손실이 없다. 데이터베이스 연결의 경우, 추가되는 연결은 주로 데이터베이스 서버에 있는 램을 소비하는데, 이것은 비싸기는 하지만 수익을 잃어버리는 것보다는 비용이 적다. 데이터베이스가 처리할 수 있는 최대 개수가 있음에 주의하자. 페일오버 상황 동안, 데이터 베이스 클러스터 가운데 하나의 노드는 모든 쿼리와 모든 연결을 처리해야 한다.

• 악순환을 예방하자.

• 자원 경쟁은 트랜잭션이 오래 걸리게 한다. 또 느려진 트랜잭션은 자원 경쟁을 더욱 심하게 일으킨다. 리소스 풀이 하나 이상이라면, 응답 시간이 상승하면서 이런 사이클은 처리량을 기하급수적으로 감소시킬 수 있다.

• 블록된 쓰레드 패턴에 주의하자.

• 가용 자원이 없을 때 쓰레드가 영원히 블록 된다면, 리소스 풀 경쟁에서 생기는 용량 문제는 안성정 문제로 돌변할 수 있다.

지나친 JSP fragment

JSP 파일들은 두 단계로 컴파일 된다. 우선, 어플리케이션 서버는 어플리케이션 서버에 맞는 서블릿 코드를 넣어 .java 파일을 생성한다. 다음으로 어플리케이션 서버는 바이트 코드로 소스 파일을 컴파일 한다. 두 단계 컴파일 후 새로운 클래스 파일은 JVM의 Permanent Generation(객체들의 클래스, 메서드 정의 영역)로 로드 된다. 문제는 어플리케이션 서버가 한번 실행되면서 JSP 클래스가 무척 많이 로드 될 때 발생한다. Permanent Generation의 기본 크기는 충분히 크지 않을 것이며, JVM이 로드 해야 하는 JSP의 개수의 제한이 없다면 Permanent Generation은 가득 차게 될 것이다. “-noclassgc”옵션을 제거하여 가비지 콜렉터를 활성화하여 여유 공간을 확보할 수 있게 해야 한다.

AJAX 대량살상

AJAX 어플리케이션은 브라우저에서 웹 서버로 많은 요청을 보낸다. 보통 사용자는 일반적인 사이트에서 페이지 클릭 사이에 5~10초 사이를 보낸다. AJAX 기반이라면 1~3초 정도 이다. 대신 개별 요청은 더욱 작아지는 경향이 있다. 요청은 일반적으로 전체 페이지 대신에 일부 페이지로 구성되기 때문이다. AJAX을 잘 적용하였다면, 대역폭 비용을 줄일 수 있다. 하지만 어설프게 적용했다면, AJAX 기술은 웹 서버와 어플리케이션 서버 계층에 더 많은 짐을 지게 할 것이다.

• 상호작용 설계.

• AJAX는 기술이지, 목적이 아니다. 사용자 경험이 너무나 중요하며, 실제로 AJAX가 사용자 상호작용을 휠씬 부드럽게 만드는 경우에만 AJAX를 적용하자. AJAX를 적용하기 가장 적당한 장소는 사용자의 마음 속에서 하나의 작업으로 표현되는 상호작용들이다.

• 응답의 크기를 최소화하자.

• HTML 페이지나 프라그먼트를 돌려주지 마라. HTML은 쓸데없이 장황하다. 그래서 대역폭을 낭비한다. 이렇게 하는 대신, 페이지에 있는 요소들을 동적으로 갱신하기 위해 클라이언트가 사용할 수 있는 데이터만을 넘겨주자. 데이터를 전달하기 위해 XML보다는 JSON을 사용하자.

• 세션 아키텍처를 존중하자.

• AJAX 요청에 세션 ID 쿠키를 꼭 포함시키자. 포함하지 않으면, 어플리케이션 서버는 모든 AJAX 요청에 대해 쓸데 없는 새로운 세션을 생성할 것이다.

• 웹 서버의 크기를 늘이자.

• 웹 서버는 요청을 더 많이 처리할 것이다. 웹 티어가 처리할 수 있는 최대 연결 개수를 늘이자.

너무 오래 머무는 세션

최초의 자바 서블릿 명세서가 작성되었을 초기에, 기본 세션 제한시간은 30분으로 정해졌다. 이 시간은 사용자의 마지막 요청이 있은 후 세션이 메모리에 상주하게 될 시간이다. 세션이 활성화되어 있는 동안 세션은 자원, 주로 메모리를 소비한다. 자바 어플리케이션 서버는 끊임없이 메모리의 제한을 받는다. 메모리는 자바기반 어플리케이션의 안정성과 성능에 결정적이다. 가장 이른 기회에 이런 세션을 삭제하는 것이 시스템의 목표여야 한다. 이를 위해 페이지 요청 사이의 시간의 평균과 표준편차를 알아내기 위해 트래픽 패턴을 조사하자. 이런 지연의 평균값에 표준편차를 더해 세션 제한시간을 설정하는 것이다.

• 세션 보유를 줄이자.

• 합리적일 만큼 짧은 시간 동안만 메모리 안에서 세션을 유지하자. 이런 시간은 도메인마다 달라질 것이다.

• 사용자는 세션을 이해하지 못한다는 것을 명심하자.

• 사용자들이 잠시 사라졌기 때문에 무언가 사라져서는 안 된다.

• 전체 객체가 아니라 ID를 보관하자.

• 세션 안에 전체 객체를 보관한다면, 소프트 레퍼런스를 사용하자.

HTML 안에 낭비되는 공간

어떤 페이지를 200KB에서 150KB로 줄 일수 있다고 가정할 때 50KB의 차이는 아래와 같다.

- 어플리케이션 서버는 낭비된 50KB 공간을 생성하느라고 CPU을 사용한다.

- 웹 서버는 사용자 요청을 처리하기 위해 메모리에 50KB의 공간을 더 사용한다.

- 페이지가 커질수록 브라우저와 웹 서버는 더 오래 동안 연결된다. 이 연결이 열여 있으면, 다른 요청이 연결을 사용할 수 없다. 최종 사용자들은 웹 서버 연결을 두고 경쟁 할 수 있다.

• 쓸데없는 문자를 삼가하자.

• HTML 안에 있는 쓸데없는 문자들을 삼가하자. 이런 문자를 만들면 어플리케이션 서버는 CPU 사이클을 소비한다. 쓸데없는 문자는 대역폭을 소비한다.

• 공백문자를 제거하자.

• 페이지를 만드는 루프, 조건절, 인클루드 근처에 공백문자가 슬그머니 끼어든다.

• 스페이서 이미지를 제거하자.

• 스페이서 이미지를 묻는 요청들은 짧은 시간동안 웹 서버 연결을 소비한다. 웹 서버는 스페이서 이미지를 셀 수 없이 보내지만, 그 시간에 수익을 창출하는 다른 사용자의 트랜잭션을 처리 할 수 도 있다.

• HTML 테이블을 CSS 레이아웃으로 바꾸자.

• 테이블 구조는 서비스 되는 모든 페이지에 대해 서비스될 때마다 전송되어야 한다. 그러나 스타일 시트는 오직 한번만 내려 받으면 된다.