안녕하세요, 오늘은 좋은 정보를 하나 제공해 드리려고 합니다.
최신 기술을 습득할 수 있는 방법은 오프라인 교육에 참가하거나 온라인 교육을 받으실 겁니다.
그런데, 엔지니어가 오프라인 교육에 참가하기 위해 1일 ~ 3일 동안 자리를 비우는 것은 쉬운 일이 아닙니다.
따라서 온라인 교육이 좋은 대안이 되는데, 원하는 교육을 찾는 것도 쉬운 일은 아니죠.
아래 Microsoft Partner Network에 무료 회원으로 가입하시면 웹 관련 전문 교육 과정을 수강하실 수 있습니다. 또한, 일부 오프라인 강의도 있습니다. 일정이 허락한다면 오프라인, 안되시면 온라인 강의를 들으시면 되는 거죠.
웹 개발 해야지, 하고 마음먹으신 후 해야할 일들을 나열해 볼까요?
PC에 윈도우는 깔려있다고 가정해보죠. IIS 웹서버, DBMS, .NET Framework, 개발툴 등을 별도의 사이트를 찾아다니면서 다운로드 받아서 설치하셔야 하는데, 쉽게 말해 번거롭죠. 시간도 많이 걸리고.
결국 microsoft.com, download 사이트, codeplex.com 등 여기 저기 찾으셨어야 하죠.
마이크로소프트 웹 플랫폼 설치기 2.0 하나면 이런 고민이 다 해결됩니다.
Web Platform Installer 2.0
http://www.microsoft.com/web/downloads/platform.aspx
이런 웹 플랫폼 위에서 구동되는 다양한 애플리케이션들을 사용하실 수 있습니다.
http://www.microsoft.com/web/gallery/Categories.aspx
바로 위의 링크를 클릭하시면 찾아 보실 수 있죠.
제로보드, TextCube 등 우리나라에서 인기있는 애플리케이션은 어디 있냐고요?
http://www.windowslovephp.co.kr 에 가시면 매뉴얼을 확인하실 수 있습니다.
PHP on Windows, ASP, ASP.NET on Windows가 이제는 모두 가능하게 된거죠.
웹에서 비디오를 서비스하는 것은 가장 일반적인 시나리오 중의 하나가 되었습니다. 상품에 대한 설명 비디오, 동영상 교육 비디오, 광고, UCC 동영상, 뮤지비디오 등 정말 다양합니다.
그런데 한가지 이슈가 있죠. 네트웍 대역폭은 IT에서 가장 비용이 많이 드는 항목 입니다. 또한, 고화질을 원한다면 그 비용은 훨씬 더 비싸지죠.
그렇다면, 위와 같은 동영상을 호스팅 하는 방법과 그 비용을 줄일 수 있는 방법에 관심이 갈 수 밖에 없을텐데요, 그 부분을 오늘 설명드리도록 하겠습니다.
1. 무료 미디어 호스팅 서비스를 사용하는 방법
- YouTube, 마이크로소프트 Silverlight 스트리밍 서비스, NHN의 블로그에 연계하는 방법 등 다양하죠. 즉, 비디오 컨텐츠를 다른 회사의 네트웍을 이용해서, 그 회사가 대역폭 비용을 내도록 하는 방법이죠. 그 회사는 광고등으로 수익을 얻게 되는 방식 입니다. 마이크로소프트의 Silverlight 스트리밍 서비스는 10G의 컨텐츠까지 업로드할 수 있고, 한달에 5TB까지는 무료로 다운로드 가능하도록 제공 되는 서비스 입니다. (최대 1.4 Mbps Bit-rate 제공)
2. 자체 서버에서 미디어를 호스팅 하는 방법
- 미디어에 인증을 부여하고 싶거나, 큰 동영상을 서비스하는 경우, 또는 비디오에 광고를 넣고 싶은 경우에는 직접 호스팅을 하고 싶어질 겁니다. 컨트롤을 해야 하기 때문이죠.
이때는 두가지 옵션이 있습니다.
1) 스트리밍 서버 시나리오
. 스트리밍 시나리오에서는 클라이언트 (Silverlight, 윈도우 미디어 플레이어, 플래쉬 등)가 스트리밍 서버에 연결을 하게 됩니다. 스트리밍 서버가 비디오 스트림을 내려 보내고, 사용자는 앞으로 가거나 뒤로 돌려보기, 정지, 멈춤 등을 자유롭게 할 수 있습니다. 사용자가 브라우저를 닫거나, 다른 페이지로 이동하면 비디오 스트림이 자동적으로 데이터 보내는 것을 멈추게 되죠.
Windows Media Services (WMS)는 윈도우에서 무료로 다운받아 사용할 수 있는 스트리밍 서버이고, 윈도우 미디어 플레이어나 크로스 플랫폼 기능이 제공되는 Silverlight 등의 클라이언트를 사용할 수 있습니다. 웹에서 비디오 스트리밍을 제공할 때 가장 확장성이 뛰어나고 비용 효율적인 방식이며, 온디맨드 스트리밍, 또는 실시간 스트리밍 등의 방식으로도 사용될 수 있습니다. 또한, Windows Server 2008 Web Server 에디션에서도 구동 가능합니다.
2) 프로그레시브 다운로드 시나리오
. 프로그레시브 다운로드 시나리오에서 클라이언트 (플래쉬, Silverlight)는 웹서버에 직접 연결되어 비디오를 다운로드 받기 시작하며, 충분한 양이 다운로드 되면 바로 플레이가 가능합니다. 이 방식의 장점은 웹서버에 설정하는 것이 정말 쉽습니다. 웹서버에 해당 미디어를 복사한 후, URL 주소만 정해지면 클라이언트 비디오 플레이어가 플래이 합니다. 웹서버에 설정이 필요없고, 스트리밍 서버 셋업등의 과정이 불필요합니다.
프로그레시브 방식의 단점은 웹서버가 최대한 빨리 파일이 다운로드 한다는 것입니다. 사용자가 사이트에서 비디오 보기를 클릭하면 웹서버가 클라이언트로 해당 파일을 최대한 빠르게 보내기 시작합니다. 사용자가 처음부터 끝까지 비디오를 본다면 별 문제가 없지만, 비디오를 보다가 중간에 멈추거나, 다른 페이지로 옮겨 가면 보지도 않는 파일이 다운로드가 된다는 불합리한 부분이 있습니다. 보지도 않는데 다운로드 되는 내용이 수 메가바이트나 된다면, 그 만큼의 돈을 낭비하고 있는 셈이 되는거죠.
3. 그래서, IIS7.0 비트 레이트 Throttling 모듈 (Bit Rate Throttling Module)이 있습니다.
- 해당 모듈은 미디어 유형에 관계없이 Bandwidth, 즉 대역폭의 낭비를 막아줍니다. 최초로 마임타입 확인 후, 파일에 대해 Bit-rate 인코딩을 한 후 최초 20초간 플레이 할 수 있는 양의 미디어를 최대한 빠르게 전송합니다. 일단 20초 만큼의 미디어가 다운된 이후 부터는 Bit Rate Throttling 모듈이 전송되는 양을 제어하기 시작합니다. 그러면서, 클라이언트가 플레이어를 멈추거나 다른 페이지로 옮겨가는 것을 모니터링 하다가 사용자가 시청을 멈추는 순간 자동적으로 파일 보내기를 멈추게 하는 역할을 합니다.
예를들면, 35MB짜리 비디오 파일이 500Kbps의 속도로 인코딩되어 상영되면, IIS는 20초에 해당하는 만큼의 파일을 즉시 내려보낸 후 (20초 * 500Kbps, 1.25MB), 이후에는 초당 500Kbps의 컨텐츠를 내려보냅니다. (20초 만큼의 버퍼만 갖도록 유지, 사용자가 보다가 버퍼링이 일어나지 않도록 하기 위함)
만약, 1분 후에 사용자가 비디오 보기를 멈추거나 다른 페이지로 옮겨 가면, IIS가 상황을 인지하고 컨텐츠 전송을 멈추게 됩니다. IIS는 단지 80초에 해당하는 비디오만 다운로드 했기 때문에 전체 35MB 중 (5M, 즉 80초 * 500kbps)의 대역폭만 사용한 셈이 되는 것이죠. 이 30MB가 수백번 반복 된다면 대역폭, 즉 비용을 엄청나게 절약할 수 있게 되는 것입니다.
ScottGu's의 블로그를 참고하여 글을 정리하였습니다.
감사합니다.
앞의 글에서 PHP 관련하여 적어보았습니다. FastCGI 설정하는 법과 PHP를 설정하는 법을 살펴보겠습니다.
서버관리자 - 롤 서비스에서 CGI를 선택하세요. CGI와 FastCGI 서비스를 모두 설치합니다.
이제 PHP 엔진이 필요하죠. http://www.php.net/downloads.php를 클릭하셔서 non-Thread safe 버전의 PHP를 다운 받으세요. non-Thread safe와 FastCGI를 함께 사용하셔야 최적의 성능을 보장받을 수 있습니다. Thread safety check를 할 필요가 없기에 시간이 단축되는 것이죠.
1. 파일을 압축해제하세요. C:\PHP 디렉토리를 만드시는 것이 좋습니다. 또한, php.ini-recommended를 php.ini로 파일명을 바꾸세요
2. php.ini 파일을 오픈 한 후 몇 가지 파라미터의 주석을 해제하세요.
- fastcgi.impersonate = 1
- cgi.fix_pathinfo = 1
- cgi.force_redirect = 0
- open_basedir 설정 (웹 사이트 컨텐츠가 있는 폴더나 네트웍 경로)
3. PHP가 제대로 설치되었는지 확인을 위해 명령문에 아래와 같이 입력
C:\PHP> php -info
IIS가 PHP 어플리케이션을 처리하기 위해 처리기 매핑(Handler Mapping)을 설정해야 합니다. 주요 목적은 PHP 파일의 요청을 FastCGI를 통해 PHP 엔진으로 보내는 것입니다.
요청 Path: *.php
모듈: FastCGIModule
실행파일: C:\php-cgi.exe
이름: PHP via FastCGi (원하는데로 설정)
대화상자에서 OK를 선택하시면 됩니다.
이후에 c:\inetpub\wwwroot 폴더에 phpinfo.php 파일을 하나 생성합니다.
내용: <?php phpinfo(); ?>
브라우저를 연다음 http://localhost/phpinfo.php를 입력하면 설정이 제대로 되었다면 php에 대한 정보를 보여주는 화면이 나옵니다.
이제 다 끝났습니다. 마지막으로 PHP와 FastCGI 리사이클링을 위한 설정을 해보죠
FastCGI는 native PHP 리사이클링이 이루어지기 전에 php-cgi.exe 프로세스들을 리사이클링 시킵니다. 바로 이 리사이클링은 설정 프로퍼티, instanceMaxRequests에 의해 조절됩니다. 이 값은 FastCGI가 리사이클링 되기 전에 몇개의 요청을 처리할 것인지를 정하는 것이죠. PHP 역시 비슷한 설정값을 가지고 있는데, PHP_FCGI_MAX_REQUESTS가 바로 그것입니다. 만약 instanceMaxRequests의 값을 PHP_FCGI_MAX_REQUESTS의 값보다 작거나 같게 설정하면 PHP의 리사이클은 절대 발생하지 않을 것입니다.
만약, 파라미터 값이 설정되지 않으면 디폴트 값을 사용하게 됩니다.
instanceMaxRequests: 200, PHP_FCGI_MAX_REQUESTS: 500 (대부분의 PHP 빌드에서)
파라미터 값을 설정하려면 아래와 같은 명령문을 사용하시면 됩니다.
c:\>%windir%\system32\inersrv\appcmd set config -section:system.webServer/fastCGI /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000
c:\>%windir%\system32\inersrv\appcmd set config -section:system.webServer/fastCGI /
[fullPath='c:\{php_folder}\php-cgi.exe'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']
www.iis.net에서 참조
IIS는 CGI(Common Gateway Interface)를 지원했죠. CGI는 IIS가 외부 어플리케이션과 의사소통할 수 있는 표준 기반의 프로토콜입니다. ISAPI도 비슷하게 사용될 수 있죠. 그러나 이 두가지 방식은 약간의 제약이 있었고 이를 해결하기 위해 FastCGI 라는 모듈이 개발되었습니다. 조금 자세하게 살펴보기로 하죠.
CGI
CGI는 IIS가 외부 어플리케이션과 인터페이스하기 위한 프로토콜 입니다. 그런데, HTTP는 stateless(상태를 가지고 있지 않음)이기 때문에 HTTP를 통해 들어오는 요청을 처리하기 위해 운영체제에서 새로운 프로세스를 구동하여 외부 어플리케이션의 인스턴스를 만들어야 합니다.
바로 이 프로세스 내부에는 stdin(스탠다드 입력)이 클라이언트의 요청 데이터를 받고, stdout(스탠다드 출력)은 해당 응답 데이터를 클라이언트로 내보내며 커맨드라인과 운영체제의 환경 변수들이 다른 서버 및 요청들을 CGI 프로세스에 보내기 위해 사용됩니다. IIS에서 CGI를 사용할 때의 단점은 윈도우 운영체제가 프로세스를 만들 때 비교적 자원 소모량이 크다는 것이죠. 모든 HTTP 요청이 새로운 프로세스를 띄우고 CGI 어플리케이션 내부에서 해당 작업을 수행하고, 작업 완료 후 프로세스를 종료하게 됩니다. 따라서, 웹에서의 응답속도가 느려질 수 밖에 없습니다. 쉽게 풀이하면 10개의 요청에 10개의 프로세스가 생성, 종료된다는 것이지요.
ISAPI
PHP를 IIS에서 구동될 수 있도록 하기 위해 다양한 시도가 이루어졌고, 그 중 나름대로 성공한 모델이 바로 ISAPI 입니다. ISAPI(Internet Server Application Programming Interface)는 CGI와는 다르게 웹서버 프로세스 내부에서 작업이 이루어집니다. 클라이언트의 요청이 있을 때 새로운 프로세스가 생성되지 않고, 웹서버 프로세스에 로딩된 DLL의 초입 포인트를 Call 하는 방식으로 이루어집니다. 만약, ISAPI 어플리케이션이 운영체제가 Thread를 어떻게 처리하는지를 고려하여 만들어져 있다면 성능이 놀라울 정도로 뛰어납니다. 수년동안 PHP는 CGI와 ISAPI 방식을 통해 구동이 되고 있지만, 두가지 방식은 단점이 있습니다.
앞에서 말했듯 CGI 방식은 속도가 느리고 ISAPI 방식은 Thread 이슈가 있습니다. 예를들면 PHP가 ISAPI 방식으로 구동될 때 웹서버 프로세스 내에서 멀티 Thread 환경에서 처리가 됩니다. PHP가 Thread-safe 방식으로 구현되었지만, 많은 인기있는 PHP 어플리케이션들은 non Thread-safe 방식으로 이루어져 있습니다. 만약 ISAPI 방식의 PHP 환경에서 non Thread-safe 방식으로 개발된 어플리케이션을 구동하면, 서버가 불안정해지는 위험이 있습니다.
FastCGI
FastCGI는 성능과 안정성 모두를 보장합니다. FastCGI 방식을 사용하면 프로세스가 해당 요청을 완료한 이후에도 종료되지 않고 그대로 살아서 다른 요청을 처리합니다. 기존 CGI 방식의 단점인 프로세스 생성 및 종료할 때의 응답 속도 지연이 사라지는 것이죠.
CGI 방식과 FastCGI 방식의 기술적인 차이는 FastCGI는 stdin, stdout과 CGI 사용하던 자원들에 매핑하는 작업을 수행하는 Layer가 존재한다는 것입니다. 현재 사용되고 있는 CGI 소스코드들은 아주 적은 수정만으로도 FastCGI에서 사용될 수 있습니다. 웹서버가 여러개의 동시 요청을 처리하기 때문에 가용한 프로세스 풀을 가져야 하고, 들어오는 요청들을 처리할 준비를 하고 있어야 합니다. FastCGI 처리기에서는 이 프로세스 풀을 application이라고 부릅니다. (일명 "프로세스 풀") 프로세스 풀의 프로세스의 갯수, 하나의 프로세스가 처리할 요청의 수 등을 설정할 수 있습니다.
FastCGI 처리기는 여러개의 프로세스 풀을 지원합니다. 하나의 웹서버에서 여러 종류의 FastCGI를 구동할 수 있기 때문이지요. PHP와 Ruby를 동시에 지원하기 원할 경우가 해당 될 것입니다.
PHP
PHP에 관해 몇 가지 설명을 해보겠습니다. PHP는 두가지 버전이 있죠, Thred-safe와 non Thread-safe가 바로 그것입니다. Thread-safe 버전은 thread 들이 서로 경쟁하지 않도록 하는 작업이 이루어지므로 반응속도가 느린 반면, non Thread-safe 버전은 응답속도가 빠른 것이 특징입니다. non Thread-safe PHP를 사용하는 경우 php5ts.dll을 디렉토리에서 보실 수 있고, Thread-safe PHP를 사용하신다면 php5.dll을 찾으실 수 있을 겁니다. Apache의 mod_php 또는 IIS 웹서버로 ISAPI를 사용하시려면 thread-safe PHP 버전을 사용하셔야 합니다.
IIS 웹서버에서 PHP를 사용하시려면 non Thread-safe 방식을 사용하시는 것이 가장 최적의 성능을 제공합니다. www.php.net/download 사이트에 가셔서 PHP5.2.X 버전의 non-Thread safe 바이너리를 다운받으셔서 사용하시면 최적의 환경에서 PHP를 구동하실 수 있습니다.
이전 글을 보시면 FastCGI 설정에 대해 확인하실 수 있지만, 몇 가지 추가된 내용을 포함하여 다시 글을 써보도록 하겠습니다.
|
