IISRESET VS 응용프로그램 풀 재활용(Recycle)

아마도, 많은 IIS관리자들은  IISRESET 명령어를 이미 알고, 언제 사용할 필요가 있는지 알고 있을겁니다. 보통은 웹 응용프로그램을 재시작하고자 하거나, IIS설정들을 변경한 후 적용하기 위해 실행한다고 봅니다.

간단해 보이는 재시작 명령이지만, 그 내부를 자세히 보면 그다지 단순하지 않습니다. 아울러 효과적이지도 않은 명령어입니다. 이유는 이 문서를 통해 소개되겠지만, 일단 꼭 필요한 명령의 실행인지, 최선의 방법인지 의문을 가져볼 필요가 있습니다. 

아마, 명령(IISRESET 또는 재활용 - Recycling)들의 내부를 잘 살펴보면, IISRESET 보다는 앱풀 재활용(Recycling AppPool)기능을 활용하길 원할겁니다. 무엇보다도 각 명령어들의 실질적으로 수행하는 동작에 대한 정확한 정보를 이해하는 것이 큰 도움이 될 수 있습니다.  

참고로, 이 문서 내용은 IIS6(Windows 2003 Server)의 화면들을 사용해서 예를 들고 있지만, 개념적인 내용은 IIS7.x에도 적용가능합니다. IIS7.x 는 Windows 2008의 IIS7과 Windows2008R2의 IIS7.5를 포함합니다.

 

IISRESET을 자주 실행해야 하는가?

결론적으로 얘기하면 IISRESET을 실행해야만 하는 경우는 거의 없습니다. 웹서버의 변경사항을 적용하기 위해, 또는 질질 새어나간 메모리를 회복하기 위해서 IISRESET을 자주던 가끔이던 실행하는 것은 바람직하지 않습니다. IISRESET명령어는 단순히 위에 언급한 문제에 도움을 주는 조치 이외에도 훨씬 더 많은 작업들이 수행되며, 효과적이지도 않습니다. 관리자가 그저 뭔가를 조치했다는 위안 정도일 수 있습니다. 아울러 웹 서버에서는 더 많은 부작용이 생길 수 있습니다. 따라서, IISRESET 명령어가 실제로 무엇을 수행하고, 앱풀 재활용은 어떤 기능인지 이해해볼 필요가 있습니다.   

 

제안 - 앱풀 재활용

'Application Pool'은 'Worker Process'로도 같이 사용되는 용어이고, 실제로 IIS서버에서는 w3wp.exe 프로세스를 의미합니다. 앱풀(AppPool) 재활용이란, 이 작업자 프로세스들만 재시작하는 기능입니다. 이 기능은 IIS6 (Windows2003)에서 처음 소개된 기능입니다. 재활용은 IIS관리자와 명령창에서 스크립트 실행으로 가능합니다. 명령창에서 재활용 기능에 대한 자세한 정보는 'IISAPP /?'을 실행하면 도움말과 명령 옵션들을 확인할 수 있습니다. 아마 이 문서를 통해 이 재활용 기능을 적극적으로 활용하도록 제안할 것 같죠?

 

IISRESET은 어떤 작업인가.

IISRESET은 내부적으로 필요 이상의 많은 작업들이 수행됩니다. 명령어가 수행하는 작업들과 그 효과에 대해 이해하기 위해서는 IIS의 내부구조를 먼저 살펴볼 필요가 있습니다. IIS의 내부 구조는 더 복잡하게 표현될 방법이 많겠지만, 주요 구성요소를 위주로 살펴보면 아래와 같습니다. 

그리고, 아래 내용의 여러 구성요소 기능을 볼 때, 한가지를 더 생각하면서 살펴보면 좋겠습니다. 아래의 모든 기능들이 IISRESET명령어로 중단되었다가 시작된다는 점.

 

간단하게 IIS 구조 살펴보기

IISS는 세 가지 주요 구성요소들로 이루어져 있습니다. – http.sys, IIS admin Services, and 작업자 프로세스(worker processes =Application Pools).

1. HTTP.SYS

 이 놈은 커널 구성요소입니다. 확장자가 SYS인 것을 봐도 알겠지요. 아울러 이 구성요소는 W3WP.EXE와 같은 응용프로그램 프로세스의 일부가 아니라는 것도요. 사용하는 메모리 영역 자체가 다릅니다. IIS관리자와 응용프로그램 실행 프로세스들과 온전하게 격리되어 있습니다. HTTP.SYS는 또한 3가지 중요한 기능을 담당합니다. - 클라이언트 연결관리, 사용자 요청 라우팅, 응답캐시 관리. 여기서 사용자 요청 라우팅이란, 브라우저(인터넷 익스플러어같은)에서 웹서버로 들어온 요청을 처리할 작업자 프로세스(w3wp.exe)를 찾아서, 그 프로세스에 해당하는 대기열(Application Pool Queue)에 넣어 주는 역할을 의미합니다. 

 

2. 작업자 프로세스, Worker Processes (=Application Pools, w3wp.exe)

 작업자프로세스(W3WP.EXE, WWW Worker Process)는 모든 컨텐츠를 처리합니다. 예를 들면 정적컨텐츠 - HTML/GIF/JPG 파일 같은 것들이 될 수 있죠. 또한 ASP나 ASP.NET같은 응용프로그램을 구동합니다. 따라서 작업자 프로세스의 상태는 웹서비스의 성능과 안정성에 매우 중요한 요소입니다.

3. IIS Admin Services, 관리 서비스

위에 언급된 IIS 구성 요소들을 IIS설정값들을 바탕으로 관리해주는 윈도우즈 서비스의 한 부분입니다. (svcHost.exe) 

 

이제 IISRESET명령어를 살펴봅시다. 

IISRESET 명령어를 실행하면, 모든 IIS관련 서비스들과 거기에 속해있는 모든 구성요소들이 중단됩니다. 당연한 얘기처럼 들리고, 사실 이정도 정보로도 무슨일이 일어나는지 예상이 되는 부분이네요. 하지만 모든 구성요소들을 중단하는 과정을 자세히 이해해볼 필요가 있습니다. 중단을 시도하지만, 그 어떤 작업자 프로세스도, 실행중인 구성요소도 강제로 죽이진 않아요. 이 명령어는 중단 시킬 대상에게 메시지만 보냅니다. '넌(중단할 서비스) 최대한 빨리 내려가야해'라는 메시지. 왜냐면 IIS서비스를 정상적으로, 고상하게 중단 시키려고 하기 때문입니다.

 

예를 들어 실행시간이 50초 걸리는 웹 응용프로그램이, 작업자 프로세스 안에서 실행 중이라고 가정해보죠. 위에서 언급되었듯이, 서비스 중단 메시지만 받고, 실제로 작업자 프로세스는 현재 실행 중인 프로그램을 계속 실행합니다. 대신에 더이상 추가로 응용프로그램을 실행하도록 요청이 들어오지는 않죠. 이미 처리할 응용프로그램을 던져주는 HTTP.SYS 역할들도 중단된 상태니까요. 이젠 현재 실행중인 프로그램들만 처리하고 종료되면 됩니다. 만약 지금 실행 중인 프로그램을 끝내는데에 50초가 더 필요하다면, 그만큼 서비스 종료에 시간이 필요하게 됩니다. 다시 말하면, IISRESET은 강제 종료가 아니니까요. 그런데 문제는, IISRESET 명령어를 수행하는데 걸리는 시간 만큼이 웹서버가 다운된 시간이라는 겁니다. (참고로, IISRESET명령어 실행 시간이 긴 서버의 경우, 위와 같은 수행시간이 오래 걸리는 프로그램이 원인인 경우가 많습니다.)

  

일단 IIS가 실행중인 요청을 모두 완료하면, 이제 모든 서비스를 종료하고, 다시 시작할 준비가 된 겁니다. 서비스가 재시작 되고 나서 생성된 W3WP.EXE 프로세스들은 모두 초기화된 프로세스고요.

 

IISRESET은 어떤 부작용이 있을까.

기본적으로 모든 구성요소를 중지하고 시작하는 명령이기에, 

. HTTP.SYS 커널 구성 요소는 모든 클라이언트 네트워크 연결을 잃어버립니다. 

  : 이것은 서비스가 재시작되고 나서, 모든 클라이언트가 다시 웹서버에 연결부터 해야한다는 것과 같죠. 

. 웹 브라우저들은 IISRESET이 수행되는 동안 연결에 실패합니다. (서비스 다운) 

. 연결에 실패하므로, IISRESET이 수행되는 동안 들어온 요청들(User Requests)을 잃어 버립니다. (서비스 다운) 

. 작업자 프로세스 안에 저장된 모든 데이터를 잃어 버립니다. 

  : 예) 세션변수(In-Proc옵션), ASP, ASP.NET프로그램들의 컴파일된 프로세스 메모리 안의 모듈들, 응용프로그램 캐시 

 

응용프로그램 풀의 재활용(Recycling)

이제 재활용에 대해 어떻게 동작하는 명령인지 살펴보죠. IIS6, IIS7.x 버전에 같은 개념으로 적용되는 내용입니다.  

참고로 재활용은 앱풀 재활용/작업자 프로세스 재활용/응용프로그램 풀 재활용 등 여러 같은 뜻을 같는 용어들을 사용하고 있습니다. 이후로는 통칭해서 '재활용'이라고 하겠습니다.

재활용을 시작하게 되면, 일단 새로운 작업자 프로세스를 먼저 생성하고, 기존 프로세스를 정상 종료합니다. 이점이 매우 중요해요. 재활용 기능은 고가용성(High Availability)를 지원한다는 뜻이거든요. IIS관리자 입장에서 각 단계별로 재활용에 대해 아래와 같이 살펴보죠.

 

먼저 IIS서버에서, IISAPP 명령어를  실행하여, 현재 응용프로그램 풀과 프로세스 ID를 확인합니다. 화면에는 현재 1개의 프로세스가 있네요.

 

 

프로세스 ID가 884 로 확인되네요. 참고로 IISAPP명령어는 VB스크립트인데, IIS6에서 응용프로그램 풀의 이름과 PID를 확인하기에 유용한 명령어 입니다. 기업용 웹사이트의 경우, 여러 개의 W3WP.EXE프로세스를 사용하는 경우가 많습니다. 

이제 IIS관리자에서 아래 그림과 같이 재활용을 실행해봅니다.

 

재활용을 실행하자마자 IISAPP명령어를 쳐보면, 또는 작업관리자를 살펴보면 두 개의 W3WP 프로세스가 확인이 됩니다. 

즉 재활용은 새로운 프로세스를 먼저 생성한거죠. 아래에서는 프로세스ID가 3384로 보이는 프로세스가 새 프로세스입니다.

잠시 후에 IISAPP 명령어를 다시 실행해보면, 이젠 프로세스 ID가 3384인 응용프로그램 풀만 남았음을 확인할 수 있습니다.

이제 재활용이 어떻게 진행되는지 이해하기 쉬워질 수 있습니다. 재활용은 새로운 프로세스를 먼저 띄워 놓고, 기존 프로세스를 종료시킵니다. 위 내용 중에 HTTP.SYS의 기능들을 기억하신다면, 사용자 요청들을 라우팅하는 것은 커널에서 수행하는 기능인 점을 떠올릴 수 있겠죠. 다른 말로 표현하면, 재활용 시에, HTTP.SYS는 들어오는 요청들을 새로 생성된 프로세스가 처리하도록 해당 프로세스의 대기열에 요청을 넣습니다. 기존 작업자 프로세스는 이미 받아서 처리하고 있던 응용프로그램들만 끝내고, 종료 되게 됩니다.

이러한 동작으로 인해, 재활용이 수행되는 동안, IIS는 결국 한 개의 요청도 놓치지 않고, 모두 처리하게 됩니다. 서비스 가용성에 문제가 없다는 것과 같은 뜻입니다. 또한 HTTP.SYS는 재활용과 상관 없이, 자신의 역할 - 클라이언트 연결 관리와 라우팅을 수행합니다. 결국 물리적 네트워크 연결 손실도 발생하지 않으며, 모든 브라우저들은 서버에서 재활용을 수행하는 동안 웹서버로 연결하는 데에도 문제가 없습니다. 따라서, 끊어진 연결을 재설정 하는 노력(비용)도 발생하지 않습니다. 모든 브라우져 연결을 끊고 나서, 다시 모두 재연결해야할 경우에, 만일 HTTPS(SSL을 사용하는 사이트)의 경우에 더 큰 부담(system overhead)이 생길 수 있으므로, 재활용이 더욱 유용합니다.

결과적으로, 작업자 프로세스(w3wp.exe)는 서비스 가용성에 영향을 주지 않고, 재시작되었으며, 새로 생성된 프로세스가 역할을 교대했습니다.

 

IIS는 재활용 기능에 대해, 어떠한 처리 요청의 손실도 없을 것을 보장하나요? 

기본적으로는 손실이 없습니다. 그런데, 예외가 있어요.  

IISRESET명령어와, 재활용은 모두 시간초과 설정을 갖고 있습니다. 그래서, 재활용할 W3WP프로세스가 제한시간 안에 모든 실행 중인 응용프로그램을 종료한다면 문제가 없어요. 하지만 설정된 제한시간(90초) 안에 처리를 실패한다면, 재활용으로 종료되는 프로세스에서 실행중인 프로그램은 오류를 만날 수 있습니다.

 

위에서 보는 것처럼, 종료에 대한 제한시간은 어찌되었든 동작하며, 작업자프로세스는 종료되야만 하며, 종료됩니다. 만일, 이러한 종류의 시간 초과 오류가 서비스 가용성 문제와 별개의 문제라는 것을 이해한다면, 여전히 재활용은 고가용성을 지원한다라고, 결론을 내릴 수 있습니다.

 

재활용 기능의 장점들 

. 서비스 가용성을 헤치지 않고, 모든 클라이언트는 웹서버에 연결이 되며, 처리 요청의 손실이 발생하지 않습니다. 

. IISRESET보다 빠른 조치이며, 효과적으로 시스템 자원(메모리)을 반환할 수 있습니다. 

 

IISRESET과 재활용의 공통적인 문제점 

. 작업자 프로세스 안에 저장된 모든 데이터가 손실됩니다. 

  : 세션변수값(In-Proc 옵션), 컴파일된 ASP.ASP.NET 모듈들 (프로세스 안에 저장된), 응용프로그램 캐시

 

IISRESET과 재활용 중 무엇을 실행해야 할까.

일반적으로, IIS서비스를 재시작하고 싶은 경우가 발생한다면, 재활용을 하면 됩니다. 애매한 정보 처럼 보이네요.

먼저, IISRESET을 (또는 IIS서비스 재시작) 하게 되는 경우들을 보면서 확인해보는 것이 좋겠네요.

. 관리자가 웹서버 설정을 변경했고, 변경된 내용을 적용하고 싶다.

. 메모리 누수 문제가 있어서, 응용프로그램 풀(작업자프로세스) 메모리 사용량이 계속 증가한다.

. 경험적으로, IIS는 주직적으로 재시작 해주는 것이 좋다.

. 웹서버가 응답을 안하거나, 웹서버로부터의 응답이 지연된다.

 

혹시, IISRESET을 수행하는 이유 중에 하나가 위에 있나요? 위에 모든 이유에 대해, 재활용은 정확하게 필요충분한 조치가 될 수 있습니다. 아울러 모든 IIS관련 서비스를 중지하고 시작하는 것보다 효과적입니다.

(메모리 누수 문제의 경우, IISRESET이건 재활용이건 근본적인 문제를 해결하는 조치는 아니며, 증상을 완화시키기 위한 조치입니다. 재활용을 하게 되면 어쨌건 기존 프로세스 메모리는 해제되니까요. 다음에 메모리 문제에 대해 다룰 예정입니다.)

 

그런데, IISRESET은 장점이 없을까. 

기본적으로 재부팅을 하거나, 서비스를 재시작하는 것은, 문제 해결 없이 필요 이상의 조치가 되는 경우가 많습니다. 이 점은 위의 내용을 통해 이해되셨다면 좋겠네요.  몇몇 경우에는 여전히 IISRESET이 도움이 될 수 있습니다. 예를 들자면, 아래와 같은 경우가 있겠네요.

웹서버 팜(다중화된 웹서버들)을 운영하고 있으며, 웹 서버 앞단에 로드밸런서가 있고, 그러한 앞단의 네트워크 장비가, 서비스 재시작을 감지 했으면 하는 경우입니다. IISRESET은 일정 시간 웹서버의 연결(일반적으로 80, 443포트)이 중단됩니다. 따라서, 로드밸런서나 모니터링 도구는 이러한 경우를 감지하며, 해당 서버로 요청이 분배되는 것을 방지할 수 있습니다. 재활용의 경우 재활용을 실행하는 서버 내부에서만 확인이 되어서, 외부에 어떠한 장비나 도구들이, 특별한 도움 없이는, 감지할 수가 없습니다. (감지할 필요가 있는지는 다른 문제고요.)

 

그리고, 마스터 레벨에서의 IIS설정 변경을 적용하기 위해서는 IISRESET을 필요로 합니다. 마스터레벨의 속성은 'Web Sites' 노드를 선택하고, 속성창에서 [서비스] 탭을 열면 보입니다.

위의 설정을 변경하면 IISRESET을 실행해야 합니다. 하지만 대부분의 일반적인 개별 사이트 수준의 설정은 IISRESET은 물론이고, 재활용을 하지 않아도 변경사항이 적용됩니다. 다만, 응용프로그램 풀 설정과 관련하여 WEB.CONFIG, MACHINE.CONFIG 파일등의 설정 변경 등은, 재활용을 수행하는 것이 변경사항의 신속하고 확실한 반영을 위해 필요합니다.

 

고가용성을 지원하면서, 효과적인 방법

가능하다면, 그리고 필요하다면, 응용프로그램 풀 재활용 기능의 사용이 권장됩니다. IISRESET은 위에 언급된 것처럼 극히 일부 경우에만 필요한 조치입니다.

IIS6의 경우에는, IIS관리자에서 변경한 내용들이 즉시 반영되도록 설계되었습니다. 즉 IIS관리자에서 작업을 하면, 메모리에 있는 설정값을 변경하고, 나중에 설정 파일 값을 바꾸게 되는 겁니다.

IIS7.x의 경우에는 다소 설정 관리 방법이 다르지만, IISRESET은 여전히 불필요 합니다.

 

실행 환경이나, 설정 변경을 적용결과를 확실하게 하기 위해서, 그리고 IISRESET 없이 반영되었는지 확인하기 위해서, 테스트를 수행하는 것은 언제나 좋은 생각입니다. 무엇보다도, 서비스 다운시간을 유발하는 IISRESET을 실행할 때, 재활용을 다시 고려해 보는 것, 그리고, 무언가 작업을 수행할 때 서비스에 미치는 영향을 최소화 하는 것은 바람직한 운영 방안이 될 수 있습니다.

Reference

http://fullsocrates.wordpress.com/2012/07/25/iisreset-vs-recycling-application-pools/

http://blog.naver.com/PostView.nhn?blogId=fullsocrates&logNo=40164087790&redirect=Dlog&widgetTypeCall=true