아주 오래 전에 아래와 같은 글을 포스팅 한 적이 있었습니다.

http://nice19.net/blog/index.php/archives/335

시간이 다소 지났지만, 그래도 마무리는 해야겠다는 생각에 계속 끄적여 보려고 합니다. 다음편을 올려달라고 독촉하셨던 분들은 없었지만 그래도 보잘 것 없는 글을 참고해 주셨던 분들께 다음 글이 너무 늦어져서 죄송하다는 말씀부터 드리고 싶습니다는 사실 훼이크고 제 마음이니 그냥 그려러니 양해해 주십시오…

그럼, 거두절미하고 바로 본문으로 들어 가겠습니다.

웹호스팅 서버와 같이 한 서버에서 구동되고 있는 웹사이트가 다수일 경우, 문제가 되는(사용량이 많은) 웹사이트를 찾아내기란 솔직히 생각 만큼 쉬운 일이 아닙니다. 그래도 좌절하지 마세요. 윈도우즈 서버 2003에서 기본적으로 제공하는 '성능' 이라는 기능이 있으니까요.

그 전에 한 가지 집고 넘어갈 것이 있습니다. 특정 웹사이트의 사용량이 많아지는 경우에는 크게 두 가지가 있습니다.

첫째, 웹사이트가 무겁다. 그래서 H/W 자원이 많이 필요하다.
둘째, 방문자가 많다. 그래서 H/W 자원도 네트워크 자원도 많이 필요하다.

이렇게 정의만 해 드리면 선뜻 이해가 되지 않으실 수 있으므로 제 경험담을 곁들여 보겠습니다. 제가 경험해 본 것 중에  첫째에 해당 되는 경우는 네비게이션 및 지리 정보를 Activex를 통해 제공하는 웹사이트 입니다. CPU와 RAM에 아주 빨대 꼽고 쭉쭉 빨아 드셔서 처리하는데 굉장히 곤란했던 기억이 납니다.

'웹사이트가 무겁다.' 라는 얘기는 위와 같이 Activex 등을 통해 무언가 응용프로그램 서비스를 제공하는 웹사이트들에 통용되는 경우가 많습니다.

제가 경험해 본 것 중에 둘째에 해당 되는 경우는 네이버 실시간검색순위 1위에 등극되었던 모 쇼핑몰 사이트 입니다. 트래픽 빼느냐고 아주 죽는 줄 알았습니다… 지금도 다시 떠올리고 싶지 않네요…-_-;; 후우~

방문자가 많아서 서버에 부하가 걸리는 경우는 우리가 쉽게 접할 수 있는 온라인게임에서 '렉'이라는 용어로 불리우고 있습니다. 한번쯤은 들어보신 적 있으시죠? 서버가 처리할 수 있는 량이 100개인데 1000개의 요청이 들어오면 서버에 부하가 걸리게 되고, 끝내 서비스 불능 상태가 되어 버립니다. 뿐만 아니라 네트워크 자원에도 문제가 생기겠죠. 보통 서버에는 100m/bps 또는 1g/bps의 회선이 연결됩니다. 이것은 말 그대로 회선의 대역폭을 의미합니다. 초당 100m 또는 1g의 데이터가 소통될 수 있는 일종의 '고속도로'인셈이죠. 그런데 그 이상의 데이터가 중첩되어 쌓인다면? 네, 그렇습니다. 길이 막혀 버리는 겁니다.(high traffic)

그럼, 지금 이 난감한 상황이 첫째의 경우인지 둘째의 경우인지 어떻게 구분할 수 있을까요. 쉽게는 '작업관리자'의 '네트워킹' 탭을 통해 확인할 수 있습니다.

# 평화로운 서버의 모습…

방문자가 폭주하여 네트워크 자원이 심하게 소실되고 있다면 당연한 얘기겠지만, '네트워킹' 탭의 '네트워크 이용율'이 대단히 높은 수치를 기록하고 있을 것입니다.(물론, 100%를 기록하는 경우도 허다합니다.)

첫째의 경우, 단순히 H/W 자원의 사용량이 많은 것이기 때문에 네트워크 자원에까지 영향을 미치는 경우는 극히 드뭅니다. 따라서 '작업관리자'의 '네트워킹' 탭을 확인함으로써 정확하게 어떤 원인으로 인해 웹사이트의 사용량이 과다하게 발생하고 있는지 구분할 수 있습니다.

'성능' 기능을 통해 본격적인 색출 작업에 나서기 앞서 한 가지만 더! 지난 글에서 문제가 되는 응용프로그램풀을 색출하는 방법을 설명해 드린 바 있습니다. 현재는 서버에서 구동되고 있는 웹사이트가 너무 많다보니 정확하게 어떤 웹사이트가 문제가 되고 있는지 확인하기 전입니다. 하지만, 이대로 서버를 방치할 수는 없는 일입니다. 따라서 약간의 리스크를 감수하더라도 문제가 되는 응용프로그램풀에 조치를 취해 주도록 합니다. 같은 응용프로그램풀에 속해 있는 죄 없는 다른 웹사이트들은 어쩔 수 없습니다. 지못미…

해당 응용프로그램풀의 속성 메뉴로 진입합니다. 3가지 정도를 수정하게 될 것입니다. 우선 위의 그림파일을 참고해 주세요. '사용된 최대 메모리'라는 항목은 응용프로그램풀의 메모리 사용량을 제어해서 관리자가 설정해 놓은 메모리 사용량을 초과하면 자동으로 응용프로그램풀을 재생시키는 것입니다. 서버 사양과 응용프로그램풀에 속해 있는 웹사이트의 총 개수를 고려해서 설정해 주세요. 보통 150~300 이내로 설정해 주면 무난하다고 생각합니다.

다음으로 '성능' 탭으로 이동해 주세요. 여기서 2가지 항목을 설정해 줄 것입니다. 우선 '요청 큐 제한' 항목입니다. IIS 기본 설정이 1000으로 되어 있는데 이것을 혹시 상향 조정하셨다면 다시 1000으로 롤백해 주십시오. 그리고 'CPU 모니터링 사용' 항목입니다. 관리자가 설정해 높은 CPU 사용량을 초과하면 그 이후의 요청에는 응답을 하지 않는 것입니다. 단순히 웹 서버로만 사용하고 계시다면 70~80으로 설정해 주시면 무난하겠으나 만일 DB 서버와 겸용으로 사용하고 계시다면 40~60 정도가 무난하다고 생각합니다.

마지막으로 '상태' 탭으로 이동해 주세요. 그리고 '오류 급증 시 보호 기능 사용'을 비활성화 하여 H/W 자원 부족으로 해당 응용프로그램풀의 오류가 급증하여 자동으로 중지되는 것을 방지합니다.

여기까지 완료되셨다면 확인 버튼을 눌러 저장하고 빠져 나오시기 바랍니다.

저도 아직 능숙하지 않지만, 서버에 부하가 발생했을 때 얼마나 단 시간 내에 그리고 얼마나 리스크 없이 처리하는가는 순수하게 서버관리자의 상황 판단에 의해서 좌지우지 됩니다. 왜냐하면 이미 본격적으로 서버에 부하가 발생한 상태라면 제 아무리 마크 미나시 할아버지가 와도 아무것도 할 수 없습니다. 네트워크 자원이 전부 소진되었다면 원격터미널로도 접속되지 않을테고, H/W 자원이 전부 소진되었다면 이건 뭐 386 컴퓨터도 아니고…

'설마 아닐꺼야. 조금만 지켜보자.' 라는 마음가짐으로 서버를 잠시 방치해 두었다가는 서비스 불능 상태가 되어 버릴 수 있습니다. 판단 미스 하나로 리스크가 몇 배로 커져 버리는 것이죠.

제 말씀의 요지는 낌새가 이상하다면 무조건 의심부터 해 보시기 바랍니다.

그럼, 본격적인 '성능' 모니터링은 다음 포스트에서 이어서 해볼까요? -_-;; 시간이 벌써 이렇게… 너무 늦었습니다. 다음 포스트에서 '1. 작업관리자' 부분은 비로서 종결되겠군요.

서버 관리자와는 떼려야 뗄 수 없는 관계인 '서버 점검'. 하지만 막상 서버 점검이라 하면 무엇을 해야 할지 막막한 게 사실이다. 이번 포스트의 주제는 나의 서버 점검 노하우라고 하긴 좀 민망하고…-_-;; 그냥 참고하시라는 의미에서 몇 자 끄적여 보겠다.

필자의 경우, 매일 또는 일정한 주기로 서버 점검을 실시하고 있는데 사실 매일매일 서버의 모든 부분을 점검하기란 솔직히 귀찮기도 하고…-_- 불가능한 부분이기도 하다. 그래서! 다음과 같이 중요한 부분들만 정리해서 확인하고 있다.(아, 참고로 이번 포스트에서는 윈도우즈 서버의 대부분을 차지하고 있는 웹 서비스 용도의 윈도우즈 서버 -OS는 윈도우즈 서버 2003 스탠다드 SP2- 를 예로 들겠다.)

1. 작업관리자
2. 이벤트뷰어
3. 서비스 목록
4. 웹방화벽 로그
5. WWW 로그
6. DB서버 상태
7. 그외

자, 그럼 친절한(?) 부연 설명과 함께 하나하나 파해쳐 볼까…? 너무 기대는 하지마시고~ 저번에도 귀찮아서 SQL 파일 안 올렸던 전적이 있음.

1. 작업관리자

---

작업관리자는 서버 점검 때 뿐만 아니라 서버에 접속할 때마다 수시로 확인해 주는 것이 좋다. 작업관리자에서 확인해 주어야 할 항목은 '성능'과 '네트워킹' 그리고 '프로세스' 탭이다.(뭐, 사실 이 부분은 굳이 부연 설명을 드리지 않아도 다들 알고 계시지 않을까 싶긴 한데…)

'성능'  탭에서는 현재 서버의 CPU 사용량과 메모리 사용량을 직관적으로 확인할 수 있다. '서버에 부하가 있다? 없다?'는 사실 '서버의 CPU와 메모리에 여유 자원이 있다? 없다?'와 같은 말이라 해도 무방하다. 따라서 비교적 간단한 확인 작업만으로도 서버에 부하를 미리 확인하고 서비스가 중지되는 사태를 미련에 방지할 수 있다.

일반적으로 CPU 사용량이 80% 이상인 상태로 일정 시간 유지될 경우, 서버에 부하가 있다고 판단한다. 우리가 흔히 말하는 피크타임(오전 10시~오후 2시, 오후 6시~오전 0시) 때 CPU 사용량이 100%로 상승할 가능성이 있기 때문이다.

# 평화로운 서버의 모습. 작업관리자를 실행시킬 때 일시적으로 대량의 정보를 수집하므로 갑자기 CPU 사용량이 치솓는데 이것은 무시한다.

서버에 부하가 있다면 바로 '프로세스' 탭으로 이동하여 도대체 어떤 프로세스가 서버의 자원을 쏙쏙~ 뽑아 드시고 계신지 확인한다. 웹 서비스 용도로 사용되고 있는 윈도우즈 서버라면 서버의 자원을 강탈하는 주요 프로세스는 크게 3가지다. 첫째, 웹 서비스 프로세스인 'w3wp'. 둘째, MSSQL 서버 프로세스인 'sqlservr', 셋째, '해킹툴' 따위가 각각 그것이다.(MSSQL 서비스의 경우, 버전에 따라 프로세스 명이 다를 수 있다.)

# '프로세스' 탭에서 CPU나 메모리로 정렬하면 좀 더 손쉽게 부하의 원인이 되는 프로세스를 확인할 수 있다. 참고로 'System Idle Process'는 말 그대로 할 게 없어서 놀고 있는 여유 CPU 자원이다.

만일 이미 CPU 사용량이 100%까지 치솓은 상태라면 서버 제어 자체가 어려울 것이다. 일단 부하를 해결하는 것이 급선무이기 때문에 큰 리스크가 없다면 해당 프로세스를 강제 종료시키고 문제를 해결하는 것이 결과적으로 서비스 장애 시간을 단축시키는데 도움이 된다.(상황에 따라서는 재부팅도 감수해야 한다. 그만큼 서버 관리자의 상황 판단력이 중요하다.)

프로세스를 강제 종료를 시킬 때는 '프로세스' 탭의 종료 기능보다는 되도록이면 커맨드 창에서 net 명령어를 통해 서비스를 종료시켜 주는 것을 추천한다. 참고로 웹 서비스 또는 MSSQL 서비스를 중지시키는 net 명령어는 다음과 같다.

- 웹 서비스 중지: net stop w3svc
- MSSQL 서비스 중지: net stop mssqlserver (* 역시 MSSQL 버전에 따라 서비스 명이 다를 수 있다.)

해킹툴이 감지되었을 경우에는 일단 해당 프로세스 명을 기억해 두고, 고민할 필요도 없이 바로 프로세스를 강제 종료시킨다.(고민고민하지마~ -_-) 그리고 윈도우즈 검색 기능을 통해 프로세스 명으로 색인하여 해킹툴을 색출해내고, 삭제한다. 그 후, 해커가 어떤 경로를 통해 서버에 성공적으로 로그인을 했고, 해킹툴을 업로드 했는지 확인해야 하는데 본 포스트에서 그 부분까지 설명하자면 자칫 배보다 배꼽이 더 커질 수 있으므로 다음에 좀 더 자세히 다루기로 한다. (귀찮아서 그러는 게 절대 아니라는 거~)

다음으로 'w3wp'. 즉 웹 서비스에 의해 부하가 발생했을 경우다. 가장 빈번한 상황이라 할 수 있으며 상황에 따라 제일 골치 아플 수도 있다. 서버에서 서비스되고 있는 웹사이트 수가 적다면 큰 문제 없이 부하의 원인이 되는 웹사이트를 찾아낼 수 있지만, 만일 서버에서 서비스되고 있는 웹사이트 수가 많다면 자칫 지루한 레이스가 될 수 있다.

본격적인 처리 작업에 앞서 각 프로세스에 발급된 PID(Process ID)를 확인할 필요가 있기 때문에 '작업관리자'부터 손을 보도록 한다. '작업관리자'의 '프로세스' 탭에서 '보기' 메뉴의 '열 선택'을 선택하면 새 창이 하나 뜨는데 해당 새 창에서 'PID(프로세스 식별자)' 항목을 활성화시키고 확인 버튼을 클릭한다.

# '열 선택'을 찾아 가는 길… 말로 설명하는 게 솔직히 좀 복잡한 관계로…

# PID 열이 추가된 '프로세스' 탭의 모습

PID를 확인해야 하는 이유는 w3wp 프로세스가 응용프로그램풀 단위로 생성 및 구동되기 때문이다.(쉽게 말하자면 w3wp = 응용프로그램풀) 즉, 응용프로그램풀이 3개라며 w3wp 프로세스도 동일하게 3개가 생성되고 구동된다. 문제는 그 3개의 w3wp 프로세스들 중 하나가 서버의 자원을 쏙쏙~ 빨아 들이고 있는데 프로세스 명이 동일하다보니 서버 관리자 입장에서는 도대체 어떤 응용프로그램풀이 문제가 되는지 확인할 길이 없다는 것이다. 급한대로 응용프로그램풀을 하나씩 중지시켜 보는 방법도 있겠으나 비효율적이기 때문에 대단히 급한 경우가 아니라며 자제하는 것이 좋다.

'작업관리자' 창에서 PID가 정상적으로 출력되고 있다면 커맨드 창에 iisapp 명령어를 기입하여 PID를 토대로 각 w3wp 프로세스에 매칭되는 응용프로그램풀이 무엇인지 확인한다.

# iisapp 명령어를 실행시켰을 때 확인할 수 있는 결과물… 참고로 처음 iisapp 명령을 실행시키면 cscript가 등록되지 않았다는 내용에 알림창이 뜨는데 그냥 '예' 또는 '확인'을 클릭하여 넘어간다.

위의 그림을 토대로 한가지 예를 들어 보겠다. A라는 서버 관리자가 자신이 관리하고 있는 웹 서버에 접속하여 '작업관리자' 창을 확인해 본 결과, PID 4316번의 w3wp 프로세스가 장시간 동안 80%의 CPU 자원을 점유하고 있었다. 커맨드 창에서 iisapp 명령어를 통해 확인해 보니 PID 4316번의 w3wp 프로세스는 'AppPool #2'라는 이름의 응용프로그램풀이었고, 문제를 발생시키는 웹사이트는 이 응용프로그램풀에 소속되어 있는 웹사이트들 중 하나라는 결론이 나왔다.

위와 같이 서버에서 서비스되고 있는 웹사이트 수가 적을 경우, 각 웹사이트 별로 응용프로그램풀을 독립시켜 문제가 되는 웹사이트를 색출해 내는 방법이 있다.

자, 그럼, 웹사이트 수가 많다면 어떻게 해야할까? 그리고 문제가 되는 웹사이트는 어떻게 조치를 취해야 할까? '네트워킹' 탭에서는 무엇을 확인해야 할까? 흠, 귀찮은 관계로 다음 포스트에서 '1. 작업관리자' 편의 마지막을 다루기로 하겠다.(제목에서도 확인하실 수 있겠지만 얼마나 길어질지 모르겠…)

IIS와 밀접한 관계를 맺고, 연동되는 특정 모듈 내지는 컴퍼넌트가 64비트 OS를 지원하지 않는 까닭에 울며 격자먹기 식으로 IIS를 32비트 호환 모드로 설정해야 할 때가 있다.

IIS를 32비트 호환 모드로 설정하는 방법은 아래와 같다.

1. 커맨드(cmd)창에서 cd c:\inetpub\adminscripts 명령어를 기입하여 경로를 이동한다.

2. 경로를 이동한 상태에서 cscript adsutil.vbs set w3svc/apppools/enable32bitapponwin64 "true" 명령어를 기입한다.

3. iisreset 명령어로 IIS를 재시작한다.

위 작업이 정상적으로 완료되었다면 작업관리자 화면에서 아래 그림과 같이 w3wp 프로세스가 32비트 호환모드로 작동하고 있는 것을 확인할 수 있다.

# 위의 명령어를 통해 반대로 32비트 호환모드를 해제할 수도 있다.

참고로 32비트 호환모드로 IIS를 동작시킨다 하더라도 64비트 OS에서 동작하는 것이기 때문에 메모리 할당 부분에 있어서는 자유롭다. 기존에 32비트 OS에서는 IIS에 할당될 수 있는 최대 메모리 용량이 2GB인 것으로 알고 있다.(확실치는 않으나… 아마 맞을 것이다.) 이를 초과하게 되면 메모리 용량이 부족하다며 클라이언트 요청에 응답하지 않는다. 64비트 OS에서는 물리적 메모리 용량만 충분하다면 이런 메시지는 보기 힘들다.