ASP Tuning Point와 죽는 Web Server(2)

튜닝 포인트라는 개념은, 실제로 웹 서버의 아주 특수한 부분에 의해 생긴 문제가 전체적으로 확대되어 발생하다는 것이다. 이것은 고속도로에서 흔히 보는 병목 현상과 마찬가지다. 도로 중간에서 사고가 났을 경우, 해당 도로는 마비되지만, 실제로 도로 전 구간이 마비된 것은 아니다.

이런 병목 지점에서 외부의 급격한 리퀘스트를 받게 될 때, 웹 서버는 자기가 처리할 수 있는 양 이상의 값을 받게 된다. 일단 시스템 구조상 이 값은 큐에 삽입된다. 그리고, 큐보다 많이 들어오는 값들은 튕겨 나간다. 이 튕겨 나갈때 나타나는 에러는 Server Too Busy 라는 메시지이다.

그런데, 이 병목 지점이 형성되는 것은 사용 상황과 보조 서버들의 상황, 혹은 여타 외부적인 변수를 매우 많이 받는다. 따라서, ASP Tuning 을 한다고 해서 무조건 커넥션 스트링의 건전성과 CreateObject 구문의 단속만 하는 것은 경우에 따라서 별다른 도움이 되지 못할 수 있다. 물론, CreateObject 구문을 단속하면, 개체의 효율성이 증가하기 때문에 다소간 빠르게 전체적인 처리를 할 수 있겠지만, 웹 서버가 죽을 정도의 병목을 해결할 만한 근원적인 해결책은 되지 못한다.

큐를 넘어서서 서버가 응답 불능으로 들어가는 것은, 보편적으로 입출력을 받는 프로그램이면 동일하게 나타나는 것이다. 가령, 포그라운드에 돌아가는 프로그램이 입력값을 받아 처리하는 것인데, 무작위로 계속 입력값을 주면 결국 프로그램이 이상하게 작동하는 가능성이 높아짐을 볼 수 있다. 멀티쓰레딩을 완벽하게 쓰는 프로그램들은 이런 문제로 인해 중단될 가능성이 더욱 높다.

따라서, 튜닝의 가장 근본적인 해결책은, 전체 프로그램의 플로우차트나 비즈니스 로직이 된다.

자 그렇다면 튜닝의 목적은 병목을 잡는 것이며, 병목은 큐가 쌓이는 지점이라고 이야기했다. 그리고 추가로 이야기하는 몇 가지 팁은 큐가 쌓이더라도 곧바로 시스템이 응답없음 상황으로 빠지는 것은 아니다. 시스템에 따라서 약간의 지연 효과가 발생되며(즉 큐를 처리하기 위해서 시스템이 좀 고생을 하며) 이후 시스템이 다운된다. 이런 메커니즘은 일반적인 OS와 시스템들이 모두 겪는 현상이기는 하지만, 이론적으로 왜 그런 문제들이 발생하는지 체계적으로 설명되지는 않는다.

여기서부터는 실제로 이론적 측면보다는 관리자의 노련함이 필요하다. 이단 관리자는 다음 중 무엇이 이러한 병목을 일으키는지 원인을 파악해 보아야 한다.

1. 정말 접속이 많아서
솔직히, 이 해결책은 돈 들이라는 신호라고 생각할 수밖에 없다.
하드웨어적 한계를 벗어난 경우가 많다. 특정 시점에만.
예를 들어, 밤 10시마다 이벤트를 하는 사이트를 생각할 수 있다.

2. 메모리 누수, 혹은 메모리 침범 에러
Component 의 문제이다. Third-Party Component등이 이 문제를 종종 발생하게 한다.

3. 데이터베이스 병목
쿼리하러 간 쓰레드들이 돌아오지 않을 때 발생한다.

4. 네트워크 병목
혼잡시간 때 DB로 들어가는 선을 끊어 보면 웹서버는 곧 다운된다.

5. 기타.
관계 컴포넌트들의 응답 없음 등이 문제가 될수도 있고, 악의적인 DDOS 공격일 수 있다. 만일 사이트가 죽는 원인이 사이트가 주기적으로 과도한 패킷에 의한 공격이라면, 이는 적절한 보안 대책을 수립하여야 한다. 해당 시간 전후로의 네트워크 모니터링으로 확인이 가능하다.