안정성 안티패턴 - 3

8. 용량 불균형

• 서버와 스레드 개수를 조사하자. - 분산환경에서 앞단과 뒷단 서버의비율을 검토하자. 각 영역이 처리할 수 있는 스레드 개수를 확인한다.

• 비슷한 확장 효과와 사용자를 관찰하자. - 불균형 용량은 확장 효과의 특별한 경우다. 관계 속에서 한편을 다른 편에 비해서 훨씬 크게 늘린 경우다. 계절적인 이유, 마케팅 효과나 광고 효과에 의한 트래픽 패턴에서의 변경 관찰하자.

• 인터페이스의 양쪽에 스트레스를 주자. - 각 단별로 평소보다 10배 높은 요청을 받는다면 무슨 일이 벌어지는지 살펴보자. 가장 비싼 트랜잭션을 실행하자.

9. 느린 응답

느린 응답을 일으키는 것은 연결을 거부하거나 에러를 돌려주는 것보다 더 나쁘며, 특히 SOA의 경우 중간 계층 서비스의 맥락에서 더욱 나쁘다. 느린 응답은 일반적으로 과도한 요청 때문에 발생한다. 이용 가능한 모든 요청 처리자가 이미 작업 중이라면, 새로운 요청들을 받아들일 요청 처리자가 존재하지 않는다. 느린 응답은 숨어있는 어떤 문제의 증상으로 발생할 수도 있다.

• 느린 응답은 연속적인 고장을 일으킨다. - 응답 시간이 사위 시스템의 제한 시간을 초과할 때 느린 응답을 경험하는 상위의 시스템들도 느려지며 안정성 문제에 취약해질지도 모른다.

• 웹 사이트 경우 느린 응답은 더 많은 트래픽을 일으킨다. - 페이지가 나타나기를 기다리는 사용자는 새로고침 버튼을 자주 클릭하며, 이미 과부하가 걸린 시스템에 트래픽을 더 많이 발생시킨다.

• 빠른 고장을 고려하자. - 평균 응답 시간이 시스템에 허용된 시간을 초과할 때 측각적인 에러 반응을 보내는 것을 고려하자.

• 메모리 누수나 자원 경쟁을 사냥하자. - 느린 응답은 경쟁을 악화시켜 악순환의 고리로 빠뜨린다. 메모리 누수 때문에 가비지 콜렉터가 과도한 작업을 하면 느린 응답이 일어난다.

10. SLA 역전

높은 가용성 SLA을 만족시켜야 하는 시스템이 더 낮은 가용성을 지닌 시스템에 의존하는 것.

• 공허한 약속을 하지 말자. - SLA 역전은 희망적인 관측으로 운영한다는 것을 뜻한다. 순전히 운에 의해서 달성할 수 있는 서비스 수준을 약속하지 말아야 한다.

• 모든 의존성을 검사하라. - SLA 역전은 예상하지 못한 곳에 숨어 있다. 특히 네트워크 인스라스트럭처 안에 숨어 있다.

• SLA를 분리하라. - 의존하는 서비스가 다운되어도 서비스를 유지하게 하자. 의존하는 서비스가 다운될 때마다 시스템도 고장 난다면 시스템의 가용성은 의존하는 서비스보다 낮다.

SLA (Service Level Agreement) - 서비스수준 계약서 SLA는 네트웍 서비스 공급업체와 고객간에 체결하는 계약으로서, 대개 어떤 서비스가 제공될 것인지를 측정이 가능한 조건으로 명시한 것이다. 많은 수의 인터넷 서비스 공급회사들이 SLA와 같은 형태의 계약을 고객들에게 제공한다. 최근에는, 대기업의 정보기술 관련 부서들이 자신들의 고객, 즉 사내 각 부서들에서 근무하는 사용자들에 대한 서비스를 측정하고, 근거를 제시하며, 그리고 외부 네트웍 제공업체와 비교하는 것이 가능하도록 SLA를 작성해 활용하는 방안을 채택하였다. 다음은 SLA에 포함되어야할 척도들 중의 일부이다. 서비스될 수 있는 시간 비율 (%) 동시에 서비스할 수 있는 사용자의 수 실제 성능을 주기적으로 비교할 수 있는 명확한 성능 기준 사용자들이 영향을 받을 수 있는 네트웍의 변경작업 등을 사전에 고지하기 위한 일정 다양한 종류의 문제에 대한 고객상담실의 응답시간 다이얼업 접속 가능성 제공될 사용량 통계

11. 끝없는 쿼리

데이터베이스가 백 개정도의 일반적인 쿼리 결과 대신 오백만 개의 열을 갑작스럽게 돌려준다면 어떤 일이 벌어질까? 어플리케이션이 명시적으로 처리하려는 결과의 개수를 제한하지 않는다면, 어플리케이션은 사용자가 흥미를 잃은 후에도 오랫동안 루프를 돌거나 메모리를 전부 써버릴 수 있다.

불완전한 해결책으로 전체 결과에 대해 쿼리를 하지만 최대 열의 개수에 도달한 다음에 루프를 빠져 나가는 것이 있다. 이 해결책은 어플리케이션 서버에서 추가적인 안정성을 제공하지만. 데이터베이스 용량을 낭비하는 폐를 끼친다.

끝없는 쿼리는 느린 응답의 일반적인 원인이다. 이들은 정상 상태를 위반하는데서 발생할 수 있다.

• 현실적인 데이터 양을 사용하자. - 일반적인 개발과 테스트 데이터셋은 너무 작아 어린 문제를 제시할 수 없다. 백만 개의 열을 돌려주는 쿼리를 할 때 무슨 일이 벌어지는지 살펴보려면 실전 규모의 데이터셋이 필요하다.

• 데이터 생산자에 의지하지 말자. - 어떤 쿼리가 몇 개 안되는 결과만을 돌려줄 것이라고 생각한다고 해도 조심하자. 시스템의 다른 부분 때문에 경고도 없이 바뀔 수 있기 때문이다.

• 어플리케이션 수준의 프로토콜에 제한을 두자. - 웹 서비스 호출, RMI, DCOM, XML-RPC 이들 모두는 엄청난 양의 객체를 돌려받는데 취약하기 때문에 메모리를 너무 많이 소비할 것이다.