안정성 안티패턴 - 2

4. 사용자

• 사용자는 메모리를 소비한다. - 사용자의세션마다 메모리가 필요하다 용량을 향상시키기 위해 세션 메모리를 최소화하자. 메모리가 부족하다면 세션 콘텐트를 정리할 수 있도록 세션은 캐싱 용도로만 사용하자.

• 사용자들은 이상하고도 제멋대로 행동한다. - 현실의 사용자들은 예측할 수 없는 행동을 한다. 어플리케이션에 약점이 있다면, 사용자들은 엄청나게 많은 방법으로 약점을 발견할 것이다.

• 악의적인 사용자는 저 너머에 있다. - 네트워크에 익숙해지자, 시스템을 패치하기 쉽게 만들자. 프레임워크르르 최신으로 유지하라.

• 사용자들은 떼지어 공격할 것이다. - 실제로 사용자는 자주 엄청나게 큰 폭도들이 된다. URL들을 공격하는 특별한 부하 테스트를 실행하자.

5. 블록된 스레드

연결 풀에서 자원을 체크 아웃하거나, 캐시 혹은 객체 등록을 다루거나, 외부 시스템을 호출하는 경우 블록된 스레드가 언제든지 발생할 수 있다.

• 블로킹 지점을 찾아라. - 어떤 메서드에서 "synchronized" 키워드를 볼 때 마음 속의 경고를 들어야 한다. 스레드가 이 메서드를 실행하는 동안, 이 메서드의 다른 호출자들이 블록될 것이기 때문이다.

• 서드파티 라이브러리 - 서드파티 라이브러리는 스레드를 블로킹하는 악명 높은 원인이다. 엔터프라이즈 급 소프트웨어에 사용되는 클라이언트 라이브러리는 이런 라이브러리 안에서 자신만의 리소스 풀링을 한다. 문제가 발생하면 이런 리소스 풀링은 요청하는 스레드를 영원히 블록시킨다.

블록된 슬드는 통합 지점 근처에서 자주 발견된다. 블록된 스레드는 연쇄 반응으로 급속하게 번질수 있다.

• 블록된 스레드 안티패턴은 모든 고장의 지접적인 원인이다.

• 리소프 풀을 철저하게 검사하자. - 블록된 스레드 안티패턴은 리소프 풀에서 일반적으로 일어나는데, 특히 데이터베이스 연결 풀에서 일어난다.

• 입증된 프리미티브를 사용하자. - 안전한 프리미티브를 학습하고 적용하자.

• 제한시간으로 방어하자. - 영원히 지속되는 교착 상태가 없도록 대책을 강구하라. 제한시간이 없는 자바 wait()을 삼가하자.

• 확인할 수 없는 코드를 경계하자. - 스스로 서드파티 코드를 테스트하자.

6. 자기부정 공격

• 대화 통로를 열어두자. - 자기부정 공격은 여러분의 조직 안에서 유래한다. 똑똑한 마케터가 트래픽 급증을 생성하여 스스로 상처를 자초할 수도 있다. 이런 마케팅 노력을 돕거나 이끌면서 시스템을 보호할 수 있다.

• 공유되는 자원을 보호하자. - 트래픽이 급증하면, 프로그래밍 에러, 예상치 못한 확장 효과 그리고 공유되는 자원 모두가 위험을 초래한다. 앞단에서 층가되는 부하는 기하급수적으로 뒷단의 프로세싱을 증가시킨다.

• 멋지고 매력적이고 가치 있는 제안은 매우 빠른 속도로 퍼질 거라고 예상하자.

7. 확장효과

• 확장효과를 발견하기 위해 QA 환경과 실전 환경을 검사하자. - 작은 환경이나 일대일 환경에서 잘 작동하던 패턴들이 실전 규모로 옮겨갈 때 느려지거나 고장날 지도 모른다.

• 일대일 통신을 경계하자. - 일대일 통신은 잘 확장되지 않는다. 일대일 통신을 상요하면서도 시스템이 어느 정도 크게 성장 할 수 있는지 생각해 보라. 수십 대의 서버를 다룬다면 일대일 통신을 일대다 통신으로 교체할 필요가 있을 것이다.

• 공유된 자원을 경계하자. - 공유된 자원은 병목 구간이나 용량 제한, 안정성에 위협이 될 수 있다. 시스템이 일종의 공유된 자원을 반드시 사용해야 한다면, 부하 테스트를 강력하게 실시하자.