ASP.NET 마스터하기 #3 - ASP.NET의 아키텍처

Written by안재우(Jaewoo Ahn),닷넷엑스퍼트(.netXpert)

 

지난시간에우리는ASP.NET의설치에대해서알아봤습니다.여러분들중에는이미이전에ASP.NET을설치해두신분들도계실것이고,행여나제글을읽고무작정설치하신분들도계실겁니다.

자,그럼일단우리가생각해봐야질문은...

“ASP.NET이대체뭘까요?”

“내가ASP.NET을설치한이유는뭘까요?어디다써먹으려고설치하셨습니까?”

 

어떤개발자들은자신이설치하는녀석이뭔지도모르고일단설치부터하고보는사람들이많습니다.왜?남들이다하니깐.좋은거라고하니깐.새로나온거라고하니깐.

ASP.NET아키텍처가르쳐준다면서왜이런질문을하냐구요?성격이랑정체도모르면서얘가왜이런아키텍처로만들어졌는지를이해할수있겠습니까?

 

ASP.NET을한줄로정의하자면,‘.NET프레임워크를기반으로한웹애플리케이션개발모델,프레임워크,관련기술을총칭해서부르는것’이라고하겠습니다. MSDN의정의로는‘엔터프라이즈수준의웹응용프로그램을최소한의코딩으로구축하는데필요한서비스를포함하는통합웹개발모델’이라고합니다.

 

이정의는간단한내용이지만,상당히중요한사항을담고있습니다.

첫째, ASP.NET은.NET프레임워크를기반으로한다는점입니다.따라서.NET에서제공하는클래스라이브러리를사용할수있으며,프로그래밍언어로는.NET이제공하는모든언어를사용할수있고, .NET프레임워크기반의애플리케이션에적용되는모든요소들이ASP.NET에도적용된다는것입니다.그얘기는.NET에대해서잘알지못하면서ASP.NET을잘안다는것은불가능하다는의미도됩니다.

둘째, ASP.NET은웹애플리케이션을만들기위한것이라는점입니다.따라서일반적인웹애플리케이션의특성을그대로가지며,웹애플리케이션이수행가능한범위내에서만능력을발휘할수있다는점입니다.

셋째, ASP.NET은‘엔터프라이즈수준’의애플리케이션을맞추는데가장큰초점을맞추고있다는점입니다.따라서간단한애플리케이션등을만드는데는최적의개발모델이아닐수도있다는점을염두에두어야하며,엔터프라이즈애플리케이션을개발할때고려해야할사항들에대해서도알필요가있다는점입니다.

 

이세가지가별거아닌거같지만,이후에ASP.NET을이해하면서이3가지사항을잘염두에두고있느냐아니냐에따라서많은차이가나게됩니다.

 

절대변하지않는진리,웹의동작방식

두번째항목, ASP.NET이웹애플리케이션이라는것은ASP.NET이웹이라는한계를벗어나지는못한다는것은이미강조된사실입니다.마찬가지로웹의동작방식은적어도당분간은절대변하지않을특성들을다음과같이가지고있습니다.

n       Request(요청) & Response(응답)의구조를취한다.

n       기본적으로전송시에HTTP프로토콜을사용한다. HTTP프로토콜은기본적으로상태를가지지않는다(Stateless).

n       Request를보내고, Response를처리하는웹클라이언트가있어야한다.

n       Request를처리하고, Response를보내는웹서버가있어야한다.

n       기본적으로Request에는Get방식과Post방식이존재한다.

n       기본적으로Response의최종형태는정적HTML이다.

 

위의내용을포함해서보다순차적으로이내용을도식화하면다음과같습니다.

 

뻔한내용입니다만,위그림내에지금까지의웹기술들이발전해오면서이루고자했던목표들이다존재합니다.예를몇가지들어볼까요?대용량바이너리데이터를전송하기위해HTTP업로드컴포넌트가나왔고HTTP이어받기기능이등장합니다.주고받는프로토콜의전송수준에서의보안(Transport Level Security)을위해SSL(Secured Socket Layer)가등장합니다.최대한많은요청을,가장빨리처리하기위해웹서버기술이발전합니다.요청에따라동적으로응답을생성해내기위해웹서버애플리케이션기술(CGI, ISAPI, ASP, ASP.NET, PHP등)이나왔습니다.정적컨텐츠인HTML에동적인측면과상호작용성(Interactivity),재사용성을부여하기위해DHTML, JavaScript, CSS, ActiveX,애플릿등이나오게됩니다.효율적으로요청을처리하고,응답속도를보다빠르게하고,응답결과를렌더링해서보여주기위해브라우저기술이발전합니다.전세계는저그림속의내용을보다효율적으로개선하기위해그오랜시간을투자한셈입니다.

 

그럼위그림에서ASP.NET에해당하는부분은어디일까요? (이거에대한답이아직도안떠오르신다면별로이글을성의있게읽지않으셨거나,관심이없으시거나,빨리이길을접고리니지게임머니작업장을차리시는게개인과사회를위한도움이되실지도…)

 

위그림처럼웹서버단의영역입니다.다시한번정리하자면요청을받아서응답을만들어내는역할을하는부분입니다.이미잘아실역사적인얘기를간단히해보자면,초기의웹서버는HTML(*.htm, *.html),그림파일(.gif, .jpg)와같은정적컨텐츠에대한요청을받아서이를그대로전달할뿐이었습니다.초기의웹은FTP나Gopher와같이뭔가‘통신’을한다는의미보다는단순히‘전송’을한다는의미가강했습니다.웹이진화되면서정적컨텐츠가아닌동적컨텐츠를전달할방법이없을까를궁리하게되었고,동적요청을위한매개변수를어떻게전달할것인가와이를받아서어떻게처리해야하는가라는문제가대두되게됩니다.

매개변수의전달은웹프로그래밍을해봤으면들어봤음직한Get방식과Post방식이존재합니다. Get방식은URL뒤에?이후에키-값쌍으로이루어진Query String을붙여서매개변수를전달하는방법입니다.이에비해Post방식은<Form>태그를사용하며,키-값쌍을HTTP헤더내에집어넣어서전달하는방법입니다.

정적컨텐츠에대한요청과동적컨텐츠에대한요청을구분하기위해편의상동적컨텐츠를구분하기위한확장자를사용하게됩니다.즉, .html이나.htm대신에.cgi, .asp, .php, .jsp, .aspx등을사용하게된것입니다.이렇게동적컨텐츠로구분되는확장자로요청이들어올경우,웹서버는이를가로채서동적컨텐츠처리모듈에던져주게됩니다.

동적컨텐츠를처리하는모듈,즉웹애플리케이션은최초에는CGI형태가사용되었지만,시간이흐름에따라ISAPI방식과Script기반방식등으로진화되어나갔습니다.현재우리가사용하고있는대부분의방식은Script기반방식으로보면되겠습니다. ASP.NET역시여기에속한다고보면되겠습니다. (사실이런얘기들은옛날ASP책들을보면서두에자세하게잘설명되어있습니다.)

 

그런데, CGI -> ISAPI -> Script기반방식등으로변경되어온이유는무엇일까요?

우선첫째는복잡한것에서간단한것으로의이동입니다.간혹예외도있긴하지만,모든IT기술은복잡한것이간단해질때성공하는경우가많습니다.물론복잡도의감소와해당기술보유자의월급은반비례합니다만.. ^^ CGI시절까지만해도일단C나C++를알아야하는것은기본이었습니다.이당시유명했던게시판중에CrazyBoard가있었던걸로기억하는데게시판소스의양도엄청난데다분석하려면상당한시간을투자해야했습니다.현재우리가쓰고있는ASP게시판소스는그시절과는비교할수없을정도로분량도적은데다이해하기쉽습니다.게시판소스만있으면초등학생도직접게시판을올릴수있을정도이니까요.

둘째로보다적은리소스를소모하면서보다많은요청에대응해야한다는목적을달성하기위한것입니다.해묵은얘기입니다만, CGI시절에는요청당하나씩의프로세스가만들어져서사용자수가적을때는괜찮지만사용자수가늘어날경우엄청난리소스소모와함께성능이떨어지기시작했습니다. ISAPI방식은이를보완하여,요청수와관계없이프로세스는하나만만들고,처리모듈은DLL형태로만드는것이라고생각하면이해가쉬울겁니다. ASP의예를들면, asp.dll이.asp확장자에대해처리하는ISAPI모듈입니다.

 

ASP.NET역시이러한ISAPI방식을동일하게사용합니다만기존ASP에서발생되는문제점을해결하기위해서아키텍처가변경되었습니다.앗,감이오셨습니까?지금까지의글은이번글의핵심내용을유도하기위한설명이고,우리가알아봐야할건대체기존ASP아키텍처에서어떤문제가있었고, ASP.NET의아키텍처는이를극복하기위해어떤형태를취하고있는가입니다.

 

ASP의아키텍처와문제점

사실ASP의아키텍처에대해자세히알고싶다면이글이아니라다른ASP글이나서적을참고하십시오.저는어디까지나간단하게설명을하도록하겠습니다.

ASP는기본적으로IIS웹서버상에서사용될목적으로만들어졌습니다. ASP가처음등장한건훨씬이전이긴하지만,널리사용된것이NT 4.0의옵션팩에탑재된IIS 4.0부터이니깐이때를기준으로설명을하도록하겠습니다.

IIS 4.0시절, ASP가구동되는기본아키텍처는다음과같은In-Process모델입니다.

inetinfo.exe는System계정으로구동되는IIS의메인프로세스입니다.이프로세스는.asp확장자에대한요청이올때asp.dll을자신의프로세스내에로딩해서요청을처리하게됩니다.

In-Process모델의문제는asp.dll내에서문제가발생해서asp.dll이죽어버린경우,메인프로세스인inetinfo.exe마저죽어버린다는겁니다.쉽게말해서무한루프를도는.asp페이지가있는경우,그페이지하나때문에웹서버전체가먹통이되어버린다는겁니다.

Windows 2000과Windows XP의IIS 5.x에서는이를방지하기위해COM+서비스와IIS를결합하여다음과같은옵션을가지게됩니다.

IIS를다뤄본분이시라면한번쯤은본적이있을겁니다만,구체적으로이게뭐하는건지모르시는분들도많더군요.우선‘낮음(IIS프로세스)’은IIS 4.0의In Process모드와동일한것입니다.따라서성능은가장좋지만,안정성은가장떨어집니다.

 

보통(풀링됨)과높음(격리됨)은웹애플리케이션을inetinfo.exe내에서구동하는게아니라별도의프로세스(dllhost.exe)에서구동하는Out-of-Process모델입니다.둘다기본개념은유사하지만약간의차이점이있는데,먼저‘보통(풀링됨)’으로지정된웹애플리케이션들은하나의dllhost.exe내에서풀링되어동작하게됩니다.

쉽게설명하면inetinfo.exe가아닌별도의dllhost.exe안에서In Process모드처럼동작한다고보면됩니다.풀링된애플리케이션들은모두단일한dllhost.exe내에서동작됩니다.

이와관련하여구성요소서비스에서는Out-of-Process Pooled Applications라는COM+애플리케이션을찾아볼수있습니다.

풀링은성능(리소스)과안정성이라는양쪽을나름대로절충한것이라볼수있습니다.일단inetinfo.exe와dllhost.exe라는두개의프로세스로분리함으로써안정성은어느정도확보됩니다만,역시풀링되어있는애플리케이션이죽었을경우에는같은dllhost.exe내의다른애플리케이션도같이죽는다는단점이있습니다.

 

높음(격리됨)은각웹애플리케이션을별도의dllhost.exe에서동작시키는방법입니다.

완전히격리를시키는것이기때문에안정성측면에서는가장우수하겠지만, inetinfo.exe입장에서는n개의dllhost.exe와Out-Of-Process통신을해야하며, n개의dllhost.exe가돌게되므로사용되는리소스가더많아져서성능이다소떨어지게됩니다.

 

IIS 5.x에서는이러한형태로ASP애플리케이션에대해나름대로의안정성을확보했습니다만,역시여기서도제기되는단점들은존재합니다. dllhost.exe는한번구동되면명시적으로종료를시켜주기전까지는계속해서구동하게됩니다.물론잘동작한다면상관이없지만,문제(데드락상황과같은)가발생했을때는반드시수동으로재시작을해줘야한다는단점이존재합니다.즉,자신이죽는다고해서웹서버전체나다른웹애플리케이션에영향을미치는건해결했지만,자기자신이죽었을때처리할수있는방법이모호하다는것입니다.또한버그등으로인해리소스의누수가발생하는경우애플리케이션을재시작함으로써리소스의클린업을할수있는데(시스템을재부팅하는걸생각해보세요),이러한과정(통상Recycling이라고합니다)을지원하지않는다는것입니다.또한dllhost.exe는웹애플리케이션만을위한전용이아닌COM+서버활성화모드(Out-of-Process)에서사용되는범용호스팅프로세스입니다.그렇기때문에웹애플리케이션을위한구성정보를설정해서동작특성을변경하는것을지원하지않는다는것입니다.

IIS에서COM+애플리케이션을구동할때도동일한문제가발생했습니다.예전에는VB 6.0이나ATL로비즈니스로직컴포넌트를만들어서COM+에올려구동하곤했는데, COM+가라이브러리활성화(In Process)일때는컴포넌트가죽을경우호스팅프로세스인IIS가죽게되므로, IIS안정성을위해서버활성화(Out-Of-Process)로돌리는경우가많았습니다.

 

웹서버가죽는다는것이얼마나큰문제인지는다들알고계실겁니다.당연히죽게되면서비스를못하게되니깐문제가되죠.죽은웹서버를살리려면재시작을하면되는데,재시작을해도해결이되지않는문제도역시존재합니다.대표적인것으로ASP시절에는상태정보,즉세션을IIS프로세스내에서In Process모드로관리합니다.즉IIS를재시작하게되면세션정보가날아가버린다는것입니다.

IIS가죽을때상태정보가손실되는것도문제지만,웹팜(Web Farm)환경처럼웹서버를여러대두고로드밸런싱하는경우역시문제가됩니다.이경우서버간의상태정보를어떻게공유해야할지방법이막연해집니다.결국은L4를Dedicated모드(Per Session)로설정해서세션을고정시켜버리거나상태정보를DB와같은제3의저장소로돌려서우회해야합니다.전자는로드밸런싱의취지를저하시키게될테고,후자는이를지원하기위한코드를직접다작성해야한다는단점이있습니다.

 

ASP.NET의아키텍처와개선사항

지금까지진정한이번글의주제를위해기나긴여정을왔습니다.지금까지언급된문제점들을극복하기위해ASP.NET은다음과같은구조를가지고있습니다.

지난번ASP.NET의설치시에aspnet_isapi.dll이라는ISAPI처리기가등록되는것을봤을겁니다.이놈은.aspx와같이ASP.NET관련확장자를가로채서실제로처리하는작업자프로세스(Worker Process)인aspnet_wp.exe에게전달합니다.

aspnet_wp.exe는내부에요청의전후에개입하기위한HttpModule과개별요청을처리하기위한HttpHandler로구성됩니다. HttpModule이나HttpHandler는기본으로제공되는것외에사용자가정의해서확장하는것이가능합니다. aspnet_wp.exe내에서실제로일어나는일들은다음번에좀더자세하게알아보도록하겠습니다.일단여기서는aspnet_wp.exe가실제요청을처리해서응답을만들어내는녀석이라고만생각해둡시다.

 

일단여기까지만봤을때, ASP.NET은별도의전용프로세스인aspnet_wp.exe에서구동되므로자신이죽더라도inetinfo.exe에는영향을미치지않습니다.따라서이전dllhost.exe에서구동될때처럼안정성측면에서는확보가된셈이죠. aspnet_isapi.dll은실행중인aspnet_wp.exe가없을때는바로이프로세스를다시실행하며,구성정보에따라서aspnet_wp.exe의동작을제어할수도있습니다.이전글에서machine.config의<processModel>내용을보면이를제어하기위한내용들이존재합니다.예를들어timeout을지정해서일정시간동안요청이없으면종료시켜버릴수도있고,일정시간이상데드락이걸렸을때는재시작하는기능도존재합니다.다양한구성정보에따라서동작특성을제어하는것역시가능해졌다는의미입니다.

 

위그림의우측에보면aspnet_state.exe라는프로세스가있습니다. ASP.NET역시기본적으로는세션을In Process모드로관리하지만,설정에따라서그림과같이세션을별도의프로세스(aspnet_state.exe)에서관리할수있습니다.따라서aspnet_wp.exe가죽는다고하더라도세션정보자체는여전히살아있게되는거죠.상태정보관리에대한자세한내용역시다음에다루도록하겠습니다.

 

이리하여대략ASP.NET의아키텍처가왜,무엇을개선하기위해어떻게구성되었는지에대해다뤄보았습니다.사실몇가지빠진부분도있긴한데여기에서설명해야할지다음글에서설명해야할지약간애매한데다,너무글이길어지는것같아서다음으로넘기도록하겠습니다.

 

p.s.행여나틀린내용이있으면과감하게지적해주세요. ^^