앞의 글에서 클라우드 컴퓨팅에 대해 설명을 드렸습니다. 조금 이해가 되셨나요?
SaaS, SOA, RIA, Web2.0, 클라우드 컴퓨팅, 이런 IT Trend 중의 중요한 개념을 한 회사가 소유한다? 어떻게 생각하세요. "클라우드 컴퓨팅" 이란 용어가 Dell이 Trademark를 소유할 뻔 한 일이 미국에서 있었네요.
미국 특허청에 요청한 "클라우드 컴퓨팅"에 대한 Trademark 요청이 "Notice of Allowance", 즉 받아들여지기 바로 전단계에서 "Returned to Examination" (조사가 필요함) 단계로 내려간 일이 최근에 있었습니다.
2007년 3월 Dell이 가지고 있는 클라우드 컴퓨팅 솔루션, 서버 및 서비스 등의 기술을 소개하면서 Trademark 신청을 했고 잘 받아들여지고 있었죠.
문제는 2008년이 되면서 클라우드 컴퓨팅이라는 말이 일반적인 고유명사 처럼 시장에서 받아들여지고, 많은 사람들의 관심을 받으면서 이슈가 되기 시작한거죠. 네티즌들이 엄청 흥분한 건 당연한 일이겠죠? 중요한 트렌드로 많이 사용하는 개념을 한 회사가 소유하게 되면 사용할 때 마다 어떤 법적인 분쟁이 일어날 지 두려워해야 될테니 개인적인 입장에서도 맞지 않다고 생각합니다.
어쨌든, 여론의 압력에 의해 "클라우드 컴퓨팅" 이란 용어는 아직은 마음대로 사용할 수 있는 단어가 됐다니 다행스러운 일입니다.
'신현석'에 해당되는 글 298건
- 2008.09.02 클라우드 컴퓨팅, 델이 Trademark를 소유한 단어?
- 2008.08.22 클라우드 컴퓨팅(Cloud Computing) 이란?
- 2008.08.19 SQL Server Data Services (SSDS)에 대한 이해
- 2008.08.19 마이크로소프트의 유틸리티 컴퓨팅의 시작, SQL Server Data Services (SSDS)
- 2008.08.19 서버가상화 아키텍처 비교 5
- 2008.08.14 마이크로소프트 서버가상화, Hyper-V의 장점
- 2008.08.13 MSSQL Server 2005를 Hyper-V 기반 가상머신(VM)에서 구동하기
- 2008.08.11 David Chappell 세미나 이후 사진 한 장, 좋네요
- 2008.07.31 Hyper-V의 통합 컴포넌트(Integrated Components) 설치 방법 9
- 2008.07.27 Windows에서 PHP를 구동하기 위한 FastCGI 베스트 프랙티스 2
현재의 IT 주요 트렌드가 무엇일까요? SOA(Service Oriented Architecture), Web2.0, SaaS(Software as a Service), RIA(Rich Internet Application), 그리고 클라우드 컴퓨팅 (Cloud Computing) 이라고 생각합니다.
한마디로 간단히 정의하면
SOA는 "Reuse & Agility, 재사용과 민첩합"을 목적으로 나온 개념입니다.
Web2.0은 "Network Effect, 네트웍 효과, 소셜 네트웍" 으로 설명할 수 있을 것 같구요,
SaaS는 "Flexbile Pricing & Delivery, 유연한 가격 정책과 서비스의 새로운 Delivery 방식" 이구요,
RIA는 "Experience, 사용자 경험"이 주요 개념입니다.
그렇다면, Cloud Computing은 "Service Utility, 즉 유틸리티, 수도 및 전기와 같은 컴퓨팅"이라고 설명할 수 있을 것입니다.
위와 같은 다른 용어로 시장에서는 설명을 하고 나름대로의 정의를 내리기는 하지만, 사실 SOA, SaaS, Web2.0, RIA, Cloud Computing은 어떻게 보면 다르지 않습니다. 모두 현재까지 나와있는 표준들, 다양한 기술들을 이용하여 조금씩 다른 방식으로 사용하고 있다라고 이야기할 수 있습니다.
마이크로소프트는 이러한 5가지 개념을 소프트웨어 플러스 서비스 라고 하는 Umbrella로 설명하고 있습니다. 어떤 개념을 사용하더라도 결국에는 소프트웨어, 서비스가 공존하는 환경이 펼쳐진다는 것이죠.
모든 기업은 두가지를 고려하게 됩니다. 데이터 및 어플리케이션을 통제하는데 우선순위를 둘 것인지, 아니면 규모의 경제에 우선순위를 둘 것인지를 결정해야 하는 거죠. 이러한 기준에 맞추어 시장에는 현재 4가지의 IT 모델이 존재합니다.
첫째, On-Premise. 하드웨어, 소프트웨어를 모두 관리 및 소유 하는 개념
둘째, Hosting. 호스팅 업체 및 IDC를 통해 내가 개발한 어플리케이션 및 패키지를 내가 지정한 하드웨어에서 구동하고 비용을 지불하는 방식
셋째, SaaS. 다른 누군가가 개발해 놓은 어플리케이션을 사용하고, 나는 하드웨어, 소프트웨어 등의 운영등은 전혀 고민하지 않는 방식. CRM 등의 솔루션이 요즘 많이 이용되고 있죠
넷째, 클라우드컴퓨팅. 어플리케이션이 클라우드 플랫폼에서 구동되는 것, 즉 내가 어플리케이션을 개발할 때 필요한 스토리지, 컴퓨팅 자원을 클라우드 플랫폼 제공자의 것을 사용하는 데, 접속량이 아무리 많아져도 문제없이 서비스 가용성을 보장하는 서비스 방식. (즉, Scalability, 확장성이 보장되는 것이죠) 1,2주 정도 올림픽 프로모션 사이트를 구축하려고 할 때, 대박이 나면 몇 명 정도가 접속할 지 알기 어렵죠. 1만명, 10만명, 100만명에 맞추어 서버 인프라를 구축해야 할지, 아니면 1,000명 수준으로 구축할 지 정말 판단하기 어렵고, 또 2주만 사용하는 사이트 인프라에 많은 비용을 쓰기 어렵겠죠. 한 번 쓰고 나중에 6개월 후에나 다시 쓸지 모르는데 큰 투자가 가능하겠어요? 이럴때 클라우드 컴퓨팅이 아주 적절한 개념이 되겠죠.
즉, On-Premise, Hosting, SaaS, 클라우드 컴퓨팅은 다른 것을 대체하는 개념이 아닌 서로 보완하는 개념으로 IT의 진보와 발맞추어 함께 갈 것이 분명합니다.
그렇다면, 내가 지금은 클라우드컴퓨팅 방식으로 개발해서 비용을 지불했는데, 정책이나 상황이 변해서 On-Premise 방식 또는 Hosting 방식, SaaS 방식으로 바꾸려고 할 때 어느정도 유연하게 바꿀 수 있느냐가 중요한 의사결정 포인트가 될 것인데요, 이와 같은 유연함을 제공할 수 있는 플랫폼을 고민하는 것이 필요한 시점입니다.
SQL Server Data Services에 대해서는 앞의 글에 간략히 설명을 드렸기에 개요는 더이상 말하지 않겠습니다. 오늘은 SSDS에 대해 조금 더 자세히 설명해 보겠습니다.
SSDS의 이해
비즈니스 로직 Layer | 정의 | 목적 | 예 |
Authority | 컨테이너의 집합 | 계정, 보안등을 위해 컨테이너들을 조직화 |
"서울", "부산" |
Container (컨테이너) | 엔티티의 집합 | 컨텐츠, 쿼리의 목적으로 엔티티 조직화 | "판매될 자동차들" "제공된 서비스들" |
Entity (엔티티) | 단위 데이터 | 스토리지 단위 | "판매될 자동차"로 필드명, 타입, 값으로 구성됨 |
Authority, Container, Entity의 체계로 데이터를 저장, 관리합니다.
1. 데이터 모델
- 특정한 스키마를 필요로 하지 않고, 유연한 데이터 모델을 지원합니다. 엔티티가 최소의 단위 입니다. 엔티티는 프로퍼티를 통해 실제 데이터 값을 가지고 있습니다. 모든 엔티티는 서비스 메타데이타 프로퍼티와 사용자 지정 프로퍼티를 함께 가지고 있습니다. 고정형 엔티티는 없습니다. 서비스 형태로 사용되어져야 하는 특성 상 엔티티와 엔티티간에의 속성은 독립적으로 서로 영향을 미치지 않습니다. 특정 프로퍼티의 값의 데이터 유형은 엔티티 별로 서로 달라집니다. 프로퍼티의 표준화 및 엔티티간의 프로퍼티 유형은 어플리케이션 개발자에 의해 결정되기 때문입니다. 프로퍼티의 데이터 타입의 종류는 스트링, 바이너리, Boolean, Number, 날짜 등입니다.
2. 데이터 조작
- Authority, 컨테이너, 엔티티에 생성/수정/삭제 등의 데이터 조작이 가능합니다. SSDS는 웹 사이트 인터페이스를 통해 SSDS의 계정 및 authority의 생성 및 삭제 기능을 지원합니다.
. 컨테이너의 생성 및 삭제 조작 가능 (수정 기능은 제공되지 않습니다)
. 엔티티의 생성, 대체 및 삭제 가능
. 직렬화 포맷의 단일 컨테이너의 검색/조회 가능
. 직렬화 포맷의 단일 엔티티 검색/조회 가능
3. Query 언어
- SSDS는 텍스트기반의 쿼리 언어를 지원하는데, C#을 이용한 LINQ 패턴도 가능합니다. 쿼리 언어는 간단한 필터링 시나리오가 가능하도록 해주는데, 단일 authority나 컨테이너를 아래와 같은 규칙에 의해 조회 가능합니다.
. 특정 조건을 만족하는 컨테이너 값을 가져오기 위해 authority를 조회할 수 있음
(이 경우 쿼리의 범위는 쿼리가 적용되는 단일 authority로 한정됨)
. 특정 조건을 만족하는 엔티티 값을 가져오기 위해 컨테이너를 조회 할 수 있음
(이 경우 쿼리의 범위는 쿼리가 적용되는 단일 컨테이너로 한정됨)
쿼리는 Boolean(AND, OR, NOT) 및 비교 연산자(<, >, <=, >=, !=, ==)를 사용할 수 있음.
모든 비교는 특정 형태로 이루어 져야 하는데, "프로퍼티 OP(연산자) 상수/파라미터"의 형태여야 함. 예를들면, SELECT e FROM e IN 엔티티 WHERE e["도시"] == "서울";
4. 리소스 기반의 쿼리
- SSDS는 리소스 기반의 쿼리를 지원하는데, 리소스 쿼리는 엔티티, 컨테이너 등의 경로를 경유하여 값을 가져오는 것을 의미합니다. 예를들면, 다음의 REST URI는 특정 컨테이너를 의미하죠.
ChildrensBooksContainer1 beneath the authority:
mydomain.ssds.microsoft.com
만약 http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1 이라는 URI를 입력했다면 해당 컨테이너에 들어있는 모든 엔티티값이 리턴값으로 돌아올 것입니다.
또, 한단계 더 나아가서 http://http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1/SomeBook 이라는 REST URI 를 입력한다면 해당 컨테이너에서 일치하는 SomeBook, 즉 특정 엔티티가 리턴값으로 돌아오게 되는 거죠.
5. 보안
- 보안은 계정, authority, 컨테이너 레벨에 적용됩니다. 계정은 Windows Live ID를 통해 보호되고, 각 authority는 "Secret Key"를 통해 read/write 접근 권한을 부여하며, 컨테이너 역시 "Secret Key"를 통해 read/write 권한을 부여합니다. 선택적으로 컨테이너는 외부에 읽기 권한을 부여하는 것이 가능합니다.
6. API
- SSDS 서비스의 런타임은 웹서비스를 통해 이용 가능한데, 가장 중요한 방식은 RESTful 서비스 입니다. Authrity, 컨테이너, 엔티티는 모두 URI 주소를 통해 접근 가능합니다. 또한, SOAP 기반의 endpoint도 지원되는데, SOAP endpoint는 authority 까지만 지원됩니다.
현재까지는 XML이 주로 사용되는 문서 포맷인데, 이후에 AtomPub 등의 다양한 프로토콜이 추가 지원될 것으로 예정되어 있습니다. Visual C#, Visual Basic 등을 통해 LINQ Qurty 역시 사용 가능합니다.
특징은 크기에 제한없이 무한으로 사용할 수 있고 원할 때마다 확장 및 축소 가능하다는 점, 고객이 직접 인프라(서버, DBMS 등), 운영인력을 통한 관리 및 운영비를 감당할 필요가 없다는 점, SOAP과 REST 같은 웹 프로그래밍 인터페이스를 통해 웹 어플리케이션을 빠르게 프로비저닝(실제 쓸수 있게 적용)할 수 있다는 점과 사용이 쉽고 표준 기반의 인터페이스를 이용하여 개발하기 때문에 개발자들의 업무 부담이 줄어든다는 장점이 있습니다.
다음과 같은 고객에게 유용할 것 같은데요,
첫째, 대용량 데이터베이스가 필요한데, 초기에 큰 투자 없이 업무 시스템을 개발하려고 하는 고객
둘째, 데이터 사용량이 많고, 매쉬업 유형의 어플리케이션을 최소의 인프라 투자로 보안, 가용성, 관리용이성이
필요한 개발자 및 파트너사
셋째, 규모가 크거나 공유가 필요한 협업 어플리케이션을 구축하려고 하는 고객
빠른 배포를 위한 어플리케이션 신속한 개발, 온디맨드 확장, 비즈니스에 사용가능한 정도의 SLA(Service Level Agreement) 등의 이점을 강조할 수 있겠네요. 아래 사이트를 통해 무료 베타 서비스가 가능합니다.
http://www.microsoft.com/sql/dataservices/default.mspx
이후에는 SSDS를 이용한 어플리케이션 개발에 대한 글을 적어 보겠습니다.
서버가상화에 대한 시장의 관심은 대단히 뜨거운데요, 각 기술의 아키텍처 측면에서 설명을 해보려고 합니다.
1. VMWare ESX
2. Microsoft Hyper-V
3. Xen
위의 3가지가 바로 가상화 삼국지의 주인공 들입니다. 오늘은 그 중 ESX와 Hyper-V에 대해서만 언급하려고 합니다. 그렇다면 어느 회사의 어떤 기술을 사용하는 것이 훨씬 효과적일까요? TCO, Feature 등 다양한 각도에서 이유를 찾아볼 수 있겠지만 저는 순수하게 아키텍처 측면으로 살펴보는 것임을 다시한 번 강조합니다.
주로 2가지의 내용이 주로 많이 언급됩니다.
1. 하이퍼바이저의 아키텍처 구현 방식
- 우리 회사의 방식이 더 선진화된 방식이고, 사이즈가 작고 가볍다
2. 하드웨어 지원 방식 vs 소프트웨어 방식, 내가 더 빠르다
첫번째 내용을 먼저 살펴볼까요?
1. 하이퍼바이저의 아키텍처 구현 방식
1) VMWare ESX
2) 마이크로소프트 Hyper-V
VMWare의 ESX에서는 VMKernel이 핵심적인 역할을 하는데, 하드웨어를 지원하기 위한
Device Driver들과 함께 번들링 되어 있습니다. 약 200,000 라인 정도의 코드로 개발되었고
VMWare Console OS가 바로 그 윗단을 구성하고 있고, VMKernel, http, Virtual Center Service
등을 포함한 관리 업무를 수행하는데, 가상 머신의 업무들을 지원하는 역할을 VMKernel이 대부분 처리합니다.
(약 32M Byte)
마이크로소프트의 Hyper-V(Viridian)은 조금 다르게 만들어졌는데, Console OS의 역할을 Parent Partion이 수행합니다.
하이퍼바이저의 크기가 훨씬 더 작게 만들어져 있고 실제로 약 800K Byte 밖에 되지 않습니다.
VMWare에 비해 훨씬 더 크기가 작기에 오류 코드가 포함될 확률이 작고, 큰 특징중의 하나가 Device Driver가
하이퍼바이저가 아닌 Parent Partition에 올라가 있다는 것입니다.
하드웨어 드라이버에 문제가 생겼을 시 VMWare 아키텍처는 전체 가상화에 문제가 발생하지만 Hyper-V
아키텍처에서는 문제가 있는 드라이버를 사용하는 가상머신에만 문제가 발생하기에 위험요인이 더 적습니다.
두번째 내용을 살펴보겠습니다. 인텔에서는 Intel-VT, AMD V x64 비트 칩을 개발했죠.
마이크로소프트는 바로 이 하드웨어, 즉 칩이 지원하는 가상화 아키텍처를 이용하고 VMWare는 "바이너리 변환",
즉 가상머신이 발생시킨 명령어를 하이퍼바이저가 받아서 재작업을 하여 가상환경에서 잘 구동되도록 변환하는 방식을 사용합니다.
이런 소프트웨어 변환 방식을 사용하면 "가상화환경에서 구동되도록 수정되지 않는 게스트 OS"가 가상머신에서 잘 동작하도록
할 수 있게되기에 실제로 큰 의미가 있습니다. Xen에서도 이런 유사한 형태를 구현하기 위해 Paravirtualization을 구현했습니다.
Paravirtualization은 하이퍼바이저가 표준 게스트 OS의 명령어를 처리하도록 하는 방식이 아니고, 게스트 OS가 가상 환경에서
잘 동작하도록 변경 (Paravirtualized)되는 방식을 의미합니다. 결국 게스트 OS의 커널을 변경할 필요하여 Xen 기반의 하이퍼바이저에서는
Linux 기반의 OS만 동작가능할 수 밖에 없었던 이유이기도 합니다. (즉, 다른 운영체제 커널의 코드에 접근할 수 없었기 때문이죠)
그런데, 앞에 언급한 Intel-VT, AMD-V 칩의 등장으로 큰 변화가 이루어집니다. 이제는 하이퍼바이저가 "가상머신이 발생한 명령어를
소프트웨어적으로 에뮬레이션 하지 않고 최적화" 해주는 역할을 하게 된거죠.
이제는 VMWare는 기존과 동일하게 "바이너리 변환"하는 방식을 취하고 마이크로소프트와 Xen은 하드웨어,
즉 칩이 지원하는 하이퍼바이저 방식을 취하게 된 것입니다. VMWare는 소프트웨어 방식이 빠르다고 주장하고,
마이크로소프트와 Xen은 하드웨어 지원 방식이 빠르다고 주장을 하고 있는 것이죠.
해당 상황에 따라 벤치마크 결과가 조금씩 다르지만, 거의 차이가 없다는 것이 시장의 설득력을 얻고 있습니다.
하지만, 여기서 VMWare는 Intel-VT, AMD V x64비트 칩을 장착한 하드웨어가 없어도 가상화를 구현할 수 있다는 장점을 갖게 되는 것은 분명하죠.
위와 같은 장,단점이 아키텍처 상에 내재하고 있음을 이해할 필요가 있다고 생각합니다.
성능 최적화는 여러 부분에서 다루어질 수 있겠지만 운영체제, 드라이버 최적화가 가장 큰 영향을 주게 되는데, 마이크로소프트의 Hyper-V는 바로 이곳에 초점을 맞추어서 개발되었습니다. 또한 64 bit 아키텍처로 Host, Guest 머신에 64 bit 운영체제 설치가 가능하고 Guest(가상)머신에 최대 4개 까지의 CPU를 사용 가능하며, 메모리 역시 Enterprise, Data Center Edition은 64G, Standard는 32G 까지 지원 가능하게 설계가 되어 있습니다. 또한, synthetic IO (즉, 가상 머신이 Input/Output 채널에 이전 같은 에뮬레이션 방식이 아닌, Windows 드라이버에 대해 Native하게 빠르게 접근할 수 있도록 구성된) 방식을 통한 빠른 성능이 가능해 졌습니다.
- Synthetic I/O 구조에서 Hyper-V는 클라이언트 서버 방식의 아키텍처를 사용하는데, Kernel Level에서 Root 영역에서는 Virtual Service Provider의 역할, 클라이언트
영역에서는 Virtual Service Client가 I/O를 주고 받으므로 훨씬 효과적인 I/O가 가능해졌습니다.
또한, Hyper-V는 Bare Metal (즉, 순수 하드웨어 장비) 위에서 구동이 되는데 최적의 속도와 확장성을 가지는 아주 가벼운 소프트웨어 Layer로 이루어져 있습니다. 실제 크기가 800K 바이트 밖에 되지 않죠. 경쟁사 제품이 32M 바이트인 것에 비하면 훨씬 가볍고, 또한 Windows Server 2008 Server Core 버전에서 구동될 경우 훨씬 더 적은 자원을 사용하며 운영될 수 있습니다. (Server Core 버전은 그래픽 인터페이스를 사용하지 않는 커맨드라인으로 제어가 가능한 아주 가벼운 운영체제 입니다)
동일한 문제가 발생하는지 여부를 확인하여, 가상머신과 물리적 서버 환경에서 똑같은 오류가 발생하면 SQL Server 프로덕트 그룹에
- | Microsoft SQL Server 2005 Workgroup Edition |
- | Microsoft SQL Server 2005 Standard Edition |
- | Microsoft SQL Server 2005 Developer Edition |
- | Microsoft SQL Server 2005 Enterprise Edition |
개인적으로 Transaction이 빈번한 DB서버는 가상화 환경으로 구축하지 않는 것을 권고합니다. 성능상의 이슈가 있을 수 있습니다. 어느 가상화 제품을 이용하든 말이지요.
참고하세요.
그분의 강연을 듣고 있자면 빨려 들어가는 느낌이 들어요, 청중의 집중을 유도하며 자연스럽에 이끌어 가는 기술의 비밀이 궁금했는데, "Giving Technical Presentation" 이라는 주제를 통해 나름대로 그 비법을 깨달았습니다.
가장 중요한 비밀은 청중에 대한 이해였습니다. 모든 PT는 청중이 있고, 그 청중의 규모, 해당 주제에 대한 이해도를 사전에 파악하고 준비하는 것이 성공, 실패의 가장 중요한 요인이라는 것이죠.
제 영문 이름이 David 인데, 저와 같은 이름이라 더 좋네요. 함께 찍은 사진 첨부합니다.
Hyper-V를 설치하는 것 까지는 하셨다고 하셨기에 가상머신을 생성하는 방법부터 올리도록 하겠습니다.
단계1: 가상머신 생성 (이미 완료하신 경우 단계2로 넘어갑니다)
CD/DVD 또는, ISO 파일 있죠?
1) Hyper-V 관리자를 엽니다. (시작 - 관리도구 - Hyper-V 관리자 선택)
2) Action 메뉴에서 새로만들기를 선택 후 가상머신(VM)을 클릭합니다.
3) 메모리에 충분한 크기를 할당합니다.
4) 네트워크 설정은 리스트 중에서 원하는 어댑터를 선택합니다.
5) 원격지의 이미지 서버를 통해 가상머신을 설정하려면 외부 네트웍을 선택해야 합니다.
6) 가상 하드 디스크(VHD) 연결에서 이름, 위치, 디스크의 크기를 정합니다.
7) 설정 옵션에서 CD/DVD-ROM, .iso 파일 중 선택합니다.
8) 완료되면 끝내기를 클릭합니다.
9) 가상머신을 생성한 후 새로 시작하면 운영체제를 설치합니다.
단계2: 통합 컴포넌트 설치
통합 컴포넌트를 설치하는 것이 마지막 단계입니다. 설치하지 않으시면 가상머신에 마우스가 넘어가지 않는
현상이 나타날 수 있습니다.
셋업 단계 중에 통합 컴포넌트 설치는 가상서버와 가상머신(클라이언트)간의 통합이 원활히 이루어지도록
소프트웨어 패키지를 선택하게 됩니다.
1) 가상머신의 이름을 오른쪽 마우스 버튼 클릭 후 연결을 클릭합니다.
2) 가상머신 연결도구가 열립니다.
3) 작업 메뉴에서 통합서비스 설치 디스크 삽입을 클릭합니다. 이때 가상 DVD드라이브에 설치 디스크가 삽입
됩니다.
4) 자동 설치가 이루어지는데, 운영체제의 종류에 따라 수동시작이 필요할 수 있습니다.
만약, 자동설치가 안되면 가상머신의 운영체제 CD/DVD 드라이브로 이동하여 설치 디스크를 수동 시작
합니다.
감사합니다. (WS2008 Hyper-V Step By Step 가이드 첨부합니다. 영문)
첫째, PHP 웹사이트의 보안을 위해 다른 사이트와 격리 시켜야 합니다.
. 웹사이트 마다 어플리케이션 풀을 각자 할당
. 어플리케이션 풀 아이덴티티에 사용자 계정 사용
. 어플리케이션 풀 아이덴티티를 사용하기 위해 Anonymous 사용자 설정
. FastCGI의 impersonation 설정 확인 (fastcgi.impersonate = 1)
둘째, PHP 프로세스를 재활용 하세요
. 네이티브 PHP 리사이클링이 시작되기 전에, php-cgi.exe가 항상 리사이클 되도록 하는 것이 좋습니다.
FastCGI의 프로세스 리사이클링은 instanceMaxRequests라는 파라미터에 의해 결정됩니다.
리사이클 되기 전에 몇개의 FastCGI 프로세스를 처리할 것인지를 설정하는 역할을 하죠. 이 파라미터 이외에도
PHP 자체적으로 프로세스 리사이클링을 담당하는 파라미터가 있는데, PHP_FCGI_MAX_REQUESTS가 바로
그거죠. instanceMaxRequest 값을 PHP_FCGI_MAX_REQUESTS 값보다 작거나 같게 하면 PHP의 네이티브
리사이클링은 절대 발생하지 않겠죠? 아래와 같이 설정하면 됩니다.
C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000
C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /+[fullPath='c:\{php_folder}\php-cgi.exe'].environmentVariables.[name=’PHP_FCGI_MAX_REQUESTS’, value='10000']
※ 미리 값을 설정하지 않으면 기본 설정값은 instanceMaxRequest=200, PHP_FCGI_MAX_REQUESTS=500 으로 할당됩니다.
셋째, PHP의 버전
. PHP 어플리케이션은 주로 특정 버전의 PHP의 기능 및 특징을 이용하여 개발되죠. 웹호스팅 환경에서, 또는 기업에서 사용하는 PHP 어플리케이션이 다양한 버전의 PHP를 사용한다면, 한대의 서버에서 여러개의 PHP를 지원하는 것은 필수겠지요. IIS7의 FastCGI 핸들러는 여러 버전의 PHP를 지원합니다. PHP4.4.8, PHP5.2.1, PHP5.2.5 non thread-safe 버전이 모두 필요하다면 PHP컴파일러를 파일 시스템에 각각 다운 받아야 합니다. (c:\php4.4.8, c:\php5.2.1, c:\php525nts)를 설치한 후 각 버전의 어플리케이션 풀을 생성합니다.
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php448\php.exe']
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php521\php-cgi.exe']
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php525nts\php-cgi.exe']
site1, site2, site3의 3개의 웹사이트가 있고 각 사이트가 별도의 버전 PHP를 사용한다면 아래와 같이 설정할 수 있을 겁니다.
C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]
넷째, PHP 보안강화를 위한 추천 항목
- Disable remote URL's for file handling functions:
- Set allow_url_fopen=Off
- Set allow_url_include=Off
- Disable register_globals:
- register_globals=Off
- Restrict where PHP can read and write on a file system, e.g.:
- open_basedir="c:\inetpub\"
- Disable safe mode:
- safe_mode=Off
- safe_mode_gid=Off
- Limit script execution time:
- max_execution_time=30
- max_input_time=60
- Limit memory usage and file sizes:
- memory_limit=16M
- upload_max_filesize=2M
- post_max_size=8M
- max_input_nesting_levels=64
- Configure error messages and logging:
- display_errors=Off
- log_errors=On
- error_log="C:\path\of\your\choice"
- Hide presence of PHP:
- expose_php=Off
감사합니다.