Think Outside The Box

앞서 말한 4가지 중 어떤 것이 주된 원인이 되는지 정형화시키기는 사실 매우 어렵다. 그러나, 일반적으로 분류해 보면, 컴포넌트의 오류와 데이터베이스의 오류가 대부분이다. 혹은 이 둘의 복합적인 양상을 띠게 된다.

일반적으로 컴포넌트 오류로 인한 문제는, 주기적으로 이 컴포넌트와 관계된 오류 메시지가 웹 로그에 나타나므로 그 문제점의 발생 및 수정은 비교적 쉽다. 간혹, 컴포넌트 문제가 아니라 웹 서버 자체의 설치 문제와 관계된 사항들에 의해 시스템 에러를 받기도 한다.

이러한 문제들은 디버거를 사용하여 해결하는 경향이 크다. 웹 사이트 자체를 디버깅 모드로 운영하면서 생기는 여러 결함들을 잡아 낼 것을 일반적으로 권하고 있다.

컴포넌트 오류가 아닌 경우에는 정말 어딘가의 병목이 있어서이다. 이 경우가 가장 잡기 어려운 에러이며, 보통 데이터베이스 응답 지연으로 인해 문제가 야기된다. 단순한 예로, 데이터베이스 커넥션을 열기 위한 라이선스가 충분하지 않아 문제를 야기하기도 하며, 소통을 위한 프로토콜 정보가 맞지 않아(즉 보안 프로토콜을 사용할 때), 느려지면서 서버가 죽어버리기도 한다. 이런 문제로 인해 죽는 서비스는 CPU 사용량도, 메모리 사용량도, 심지어 웬만한 변수도 다 정상이다. ASP Queue만이 증가할 뿐, 서버는 아무런 이상 증상을 보이지 않는다.

이렇게 특히 ASP 병목이 있을 때, 쉽게 그 문제를 확인하는 방법은 HTML 파일에 대해서는 응답 지연이 오지 않으면서 ASP 파일만이 응답 지연이 발생하는지 여부를 알아보는 것이 가장 빠르다. 물론 최소한 풀링으로 동작하는 서로게이트를 사용하여야 하고(가급적 독립이 좋긴 하지만, 성능상의 희생이 따르기 때문에) Inetinfo.exe 자체의 상태와 dllhost.exe의 상태를 파악하는 것이다.


DLLHOST.EXE의 과부하와 시스템 문제.

DLLHOST.EXE는 COM(+) 서로게이트를 위한 파일이다. 서로게이트란 DLL을 사용할 수 있도록 베이스 프로세스를 형성해 주는 역할 정도로 이해하면 크게 다르지 않다.

서로게이트를 이용하는 까닭은, 동시에 여러 개의 웹 서버가 운영되는 시스템에서, 하나의 가상 서버에 과부하가 걸렸을 경우, 다른 웹 서버 시스템으로 이런 문제가 전이되지 않도록 하기 위해서이다.

일반적으로, 죽는 웹 서버들 중 일부는 DLLHOST의 과부하(CPU 50%이상 독점 점유)로 인해 발생되며, 이는 서로게이트되고 있는 웹 서비스를 중지한다고 해서 회복되지 않는다. 웹 서비스 전체를 다시 시작해도 그대로 CPU를 점유하는 경우가 많으며, 대부분의 해결책은 재부팅이다.

DLLHOST의 CPU 점유 원인은 생각보다 많다. 일반적으로 ASP Requests Queue 값과 정비례하는 수가 많은데, 이 역시 두 가지 부류로 나뉘게 된다. 가령 일시적 병목 현상이 걷잡을 수 없는 상황으로 발전하는 예를 들 수 있다. 즉, 어떤 이유에서 서버가 잠시 느려진 상황에, 처리용량보다 많은 요청이 들어와서, 큐잉이 생기는 경우 점점 처리용량은 줄어들고 큐잉은 길어지는 상황이 발생하는 것이다. 최악의 경우 Server Too Busy 메시지를 끝으로 죽어버린다. 그런데, 일반적인 경우는 프로그램 외적인 측면에서 찾는 것이 좋다.

최근 DLLHOST CPU 점유율을 가장 높인 일등공신은 웜이다. 웹 사이트 프로그램을 가장하여 해당 대역을 스캔하는 악성 코드 등이 CPU 점유율을 무지막지하게 높이는 수가 많으며, 주기적인 스캔 등으로 악성 코드의 잠입을 막는 방법을 생각해 볼 수 있다. 특히 주기적으로 시스템에 부하가 걸리거나, 네트워크 모니터 결과 ARP 신호가 엄청나게 증가하고 있으면 이는 필시 웜이 동작하는 것으로 볼 수 있다.

웜이 아니라면, DLLHOST CPU 점유율이 올라가는 까닭은 서버사이드의 과중한 프로그램 부하 때문일 수 있다. 가령, 암호화/복호화를 지속적으로 반복하거나, COM(+) 기반 서버 컴포넌트가 많은 경우 이런 문제를 생각해 볼 수 있다. 굳이 이 뿐만 아니라, ASP 등의 과중한 코드 등도 이러한 문제를 야기하게 된다. 이에 대한 해결책은 의외로 간단하다. 서버를 증설하면 된다. 혹은, 비즈니스 로직을 바꾸던가 프로그램을 재설계하는 것을 권한다.

만일 풀링이나 격리 모드로 시스템을 동작시킨다면 DLLHOST의 과부하는 원격에서도 탐지할 수 있다. HTML 파일의 응답 속도는 무척 빠르지만 ASP, ActiveX Server Component 의 호출은 무척 느려지는 현상이 발생하기 때문이다.

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

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

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

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

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

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

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

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

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

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

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

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

Server.CreateObject 구문을 단속하지 않으면 대용량 시스템에 문제가 많다는 사실은 오래 전부터 있어 온 이야기이다. 그러나, 실제 저 문제에 의해 죽는 시스템은 생각보다 많지 않다.

웹 사이트 성능을 측정하면서 많은 부분 간과하는 것이 바로 CPU와 메모리에 지나칠 정도로 집착하는 것이다. 실제로 죽는 웹 서버는 메모리 소요량이 많아서도 아니며, CPU 점유율이 많아서도 아니다. 간혹 CPU 점유율이 많은 서버가 존재할 수는 있겠지만, 이는 데이터베이스 등에서 병목을 일으키는 예가 된다.

따라서, 죽는 웹 서버는 일반적으로 성능 모니터링을 하지 않아도 죽는 것을 감을 잡는다. 노련한 엔지니어라면, 시스템이 돌아가는 상황을 조금만 보더라도 "이 시스템은 언제쯤 죽을 것인지" 판단이 서기 마련이다. 사실상, 시스템 성능 모니터를 필자도 거의 이용해 보지 않았으며, 시스템 성능 모니터가 제시하는 값이 사실이라 믿기도 어렵다. 일단 성능을 재는 것은 불확정성의 원리를 따르기 때문이다. 물론, 아주 미션크리티컬한 서버를 특수한 환경에서 시스템 성능을 측정하여, 해당 값을 항상 유지하도록 관리자에게 권고하려면 그나마 좋은 방편일 수 있겠다.

성능상의 문제로 죽는 웹 서버는 일반적으로 다음과 같은 현상을 지닌다.

1. 평소에는 멀쩡하다.
2. 어느날 좀 이상하다.
3. 새벽에 갑자기 죽어버린다.

혹은,

1. 아침에는 멀쩡했다.
2. 그러다 갑자기 죽었다.
3. 재부팅하니 몇시간 간다.
4. 그러다 또 죽었다.
5. CPU/메모리 점유율은 거의 없다.
6. 혹시 해킹이 아닐까? 하고 생각하기 시작한다.
7. 죽는 시간을 대충 감을 잡는다.
8. 죽기 전 재빨리 재시작하는 프로그램을 짜고 입 씻는다.

와 같은 프로세스를 처리하는 것이 일반적이다.

자 그럼 성능 문제로 인해 죽는 웹 서버가 왜 발생할까? 왜 이 서버들이 어느 순간 갑자기 죽게 되는 것일까.

실제로, 이러한 서버군은 평소에 아무리 값을 잰다고 해도 재어지지 않는다. 그러면 이런 서버들을 어떻게 다루어야 할까? 지금부터 말하는 튜닝 포인트라는 개념이 여기서 등장하게 된다.