일반 배포

Windows Server AppFabric 서버 배포 토폴로지의 요구 사항은 비즈니스 요구 사항과 호스트할 응용 프로그램의 요구 사항에 따라 크게 달라집니다. 단일 배포를 일반적인 배포로 간주하고 이 배포에 대한 규범 지침을 제공하기는 어렵지만 이 섹션에서는 사용자 환경에 AppFabric을 배포하기 위한 지침과 권장 사항을 제공합니다.

여기에서 설명하는 배포 항목은 다음과 같습니다.

• AppFabric 단일 서버 배포

• AppFabric 서버 팜 배포

• AppFabric 캐싱 기능 배포 보안 고려 사항

• AppFabric 캐싱 기능 배포 시나리오

AppFabric 단일 서버 배포

단일 서버 배포는 단일 컴퓨터에 AppFabric을 설치할 때 수행됩니다. 이 배포는 모든 응용 프로그램 배포가 단일 컴퓨터에서 수행되는 개발 환경에서 종종 사용됩니다.

SQL Server

스케일 아웃은 개발 환경에 대한 문제가 아니므로 AppFabric의 이 배포에서는 모니터링 및 지속성 데이터베이스에 대해 SQL Server Express의 로컬 설치를 사용하도록 구성할 수 있습니다.

응용 프로그램 배포

MSDeploy를 사용하여 응용 프로그램을 패키징하고 AppFabric에 배포하면 응용 프로그램 배포를 수행할 수 있지만, 이 작업에는 테스트 환경에서 응용 프로그램을 호스트하기 위한 최소한의 단계가 포함되므로 개발자는 응용 프로그램을 호스트하는 수단으로 IIS를 실행하는 로컬 서버를 직접 사용하도록 프로젝트를 구성할 수 있습니다. 그러나 개발자는 스테이징 또는 프로덕션 환경으로 마이그레이션하기 전에 응용 프로그램의 패키징 및 배포를 테스트하여 패키징된 응용 프로그램이 올바르게 배포되는지 확인하는 것이 좋습니다.

응용 프로그램 배포에 대한 자세한 내용은 응용 프로그램 배포를 참조하십시오.

AppFabric 서버 팜 배포

AppFabric 및 SQL Server를 둘 다 한 컴퓨터에 설치해도 개발 환경으로 충분하지만 프로덕션 환경은 종종 서버 팜에 있는 여러 컴퓨터와 하나 이상의 전용 SQL Server 서버로 구성됩니다. 이 환경에서는 부하 분산 장치와 큐를 사용하여 응용 프로그램으로 들어오는 메시지 및 고가용성을 위한 SQL Server의 클러스터링을 관리할 수도 있습니다.

AppFabric의 소규모 배포는 단일 컴퓨터에 설치된 AppFabric으로 시작할 수 있지만 고도로 분산된 응용 프로그램을 만들기 위해 응용 프로그램이 여러 서버에 걸쳐 배포되는 서버 팜으로 확장될 수 있습니다. 스케일 아웃을 사용하면 들어오는 메시지 처리가 여러 서버에 걸쳐 분산되고 지속성을 사용하는 워크플로에 대해 강화된 내결함성을 제공하도록 부하 분산 솔루션을 구현할 수 있습니다.

SQL Server 클러스터링

이 섹션에서 자세히 설명되지는 않지만 페일오버 보호를 위해 데이터베이스를 클러스터링해야 합니다. SQL Server 페일오버 클러스터링에 대한 자세한 내용은 재해 복구 계획(영문)(https://go.microsoft.com/fwlink/?LinkId=131016)을 참조하십시오.

지속적 응용 프로그램 스케일 아웃

장기 실행 프로세스를 처리할 때, 응용 프로그램은 시스템 다시 시작, 하드웨어 오류 또는 기타 예측할 수 없는 서버 중단에도 정상적인 업무 수행이 가능해야 합니다. AppFabric은 워크플로 응용 프로그램이 장기 실행 응용 프로그램에 대한 지속성을 제공하는 데 사용할 수 있는 기본 지속성 공급자를 제공합니다.

단일 서버 배포에서는 워크플로 인스턴스를 호스트하는 서버가 정상 상태로 되돌아갈 때 지속성을 통해 워크플로 인스턴스가 실행을 다시 시작할 수 있지만, 서버 팜 배포에서는 서버 팜의 모든 해당하는 컴퓨터에서 응용 프로그램이 다시 시작될 수 있습니다. 또한 워크플로 인스턴스가 한 서버에서 실행되고 있고 해당 인스턴스로 전달되는 메시지가 다른 서버에 도착할 경우 워크플로에서 인스턴스를 처리할 수 있도록 지속성을 통해 실행 인스턴스를 보류 중인 메시지가 있는 컴퓨터로 이동할 수 있습니다.

자세한 내용은 워크플로 지속성 구성을 참조하십시오.

데이터 격리

AppFabric은 기본적으로 지속성 및 모니터링 정보를 둘 다 하나의 데이터베이스 저장하도록 구성됩니다. 개발 환경의 경우 이 구성으로 충분하지만 프로덕션 환경에서는 일반적으로 데이터 저장소에 대해 더 강력한 리소스 집합이 필요합니다. AppFabric을 사용하면 여러 개의 개별 지속성 및 모니터링 데이터베이스를 만들어 SQL Server를 실행하는 여러 컴퓨터 전체에서 데이터 격리를 지원할 수 있습니다.

AppFabric에서는 여러 데이터베이스를 만들 수 있으므로 데이터를 기능(지속성 및 모니터링)별 및 응용 프로그램별로 구분할 수 있습니다. 강력한 데이터 저장소 요구 사항이 포함된 응용 프로그램이 있는 경우 특히 이 응용 프로그램이나 서비스와 연결된 지속성 및 모니터링 데이터베이스를 만들 수 있습니다.

추가 데이터베이스 생성에 대한 자세한 내용은 데이터베이스 관리를 참조하십시오.

응용 프로그램 배포

응용 프로그램을 여러 컴퓨터에 배포할 때 배포를 지속적이고 반복 가능한 방식으로 수행할 수 있어야 합니다. 이 목표를 달성하기 위해 AppFabric은 MSDeploy를 사용하여 웹 응용 프로그램, 웹 사이트 또는 웹 서버 내용 및 구성을 패키징하고 배포합니다. MSDeploy를 사용하여 웹 사이트나 웹 서버 간 데이터를 서버 팜 내의 로컬 컴퓨터나 원격 컴퓨터로 동기화할 수도 있습니다.

응용 프로그램 배포에 대한 자세한 내용은 응용 프로그램 배포를 참조하십시오. MSDeploy에 대한 자세한 내용은 웹 배포 도구(영문)(https://go.microsoft.com/fwlink/?LinkId=151481)를 참조하십시오.

AppFabric 캐싱 기능 배포 보안 고려 사항

AppFabric 분산 캐시 시스템은 방화벽 경계 내의 데이터 센터에서 작동하도록 디자인되어 있습니다. 이 섹션에서 설명되는 서버는 캐시 구성 저장소 위치를 호스트하는 서버, 캐시 서버, 캐시 사용 응용 프로그램 서버, 개발 서버 및 주 데이터 원본 서버입니다. 모든 서버는 동일한 도메인에 배치되어야 합니다.

캐시된 데이터와 캐시 서버 간 TCP/IP 통신은 암호화되지 않으므로 분산 캐시 시스템은 네트워크 트래픽을 로깅하거나 수정하는 악의적인 공격에 취약합니다.

캐시 서버를 서비스 해제하면 AppFabric 설치 프로그램이 모든 방화벽 포트 예외를 제거할 수 있습니다. AppFabric이 제거된 후에 표준 방화벽 구성을 다시 적용하는 것이 좋습니다.

AppFabric 캐싱 기능 배포 시나리오

배포 옵션에 대해 쉽게 설명하기 위해 이 섹션에서는 다음 세 개의 예제를 중점적으로 설명합니다.

• 개발자 배포. 캐시 사용 응용 프로그램을 개발하는 데 사용되는 단일 컴퓨터 배포입니다.

• 중간 규모 배포. SQL Server를 사용하지 않고 리드 호스트가 클러스터 관리 역할을 수행하는 복수 컴퓨터 설치입니다.

• 엔터프라이즈 배포. 클러스터 구성 설정을 저장하고 클러스터 관리 역할을 수행하는 데 SQL Server를 사용하는 복수 컴퓨터 설치입니다.

다음 표에는 AppFabric 캐싱 기능이 설치되는 위치와 클러스터 관리 역할이 수행되는 방식이 요약되어 있습니다.

캐시 클러스터 구성 설정은 공유 네트워크 폴더나 SQL Server 데이터베이스에 저장할 수 있습니다. 이러한 각 옵션에 대한 자세한 내용은 클러스터 구성 저장소 옵션(Windows Server AppFabric 캐싱)을 참조하십시오.

클러스터 관리 역할은 리드 호스트나 SQL Server가 수행할 수 있습니다. 캐시 클러스터 가용성 측면에서는 SQL Server를 사용하는 것이 가장 좋습니다. 자세한 내용은 리드 호스트 및 클러스터 관리(Windows Server AppFabric 캐싱)를 참조하십시오.

개발자 배포

개발자 배포에서는 캐시 클러스터 자체를 포함하여 캐시 사용 응용 프로그램을 만드는 데 필요한 모든 구성 요소가 개발자 워크스테이션 내에 포함됩니다. AppFabric 캐싱 기능을 시작할 때 가장 편리한 옵션입니다.

중간 규모 배포

중간 규모 배포에서는 응용 프로그램이 분산 캐시 클러스터의 이점을 가져올 수 있습니다. 응용 프로그램 계층의 증가하는 수요에 맞게 응용 프로그램 크기를 쉽게 조절할 수 있습니다.

이 배포 시나리오에서는 클러스터 구성 설정을 저장하는 데 SQL Server를 사용하지 않으므로 약간의 단점이 있습니다. 일부 운영 체제에서 지원할 수 있는 공유 폴더에 대한 동시 연결 수가 제한되므로 분산 캐시 클러스터에 포함할 수 있는 최대 캐시 호스트 수에 직접적으로 영향을 미칩니다. Windows XP, Windows Server 2003 및 Windows Vista 32비트 버전에서는 공유 네트워크 폴더에 대한 동시 연결 수가 10개를 초과할 수 없습니다. 대규모 클러스터에 대한 캐시 구성 설정을 저장할 경우 이러한 운영 체제를 사용하지 않는 것이 좋습니다.

병렬 캐시 서버 설치를 자동화하거나 수행하려고 시도할 경우 클러스터 구성 파일에 대한 경합이 있을 수 있습니다. 이 시나리오에서 가장 안정적인 캐시 서버 설치 전략은 캐시 서버 설치를 한 번에 하나만 수행하는 것입니다.

이 시나리오에서는 SQL Server를 사용하지 않으므로 설치 과정에서 SQL Server를 확보 및 설치하고 응용 프로그램에 대한 클러스터 구성 데이터베이스를 만들 필요가 없습니다. 시간 및 비용 측면에서 이 시나리오는 이미 응용 프로그램에 사용할 수 있는 항목에 따라 비용 절감 요소가 되거나 그렇지 않을 수 있습니다. 공유 폴더 클러스터 구성 저장소 옵션을 사용할 경우 캐시 클러스터의 모든 캐시 서버는 공유 네트워크 폴더에 대해 지속적으로 네트워크로 연결되어 있어야 합니다.

SQL Server를 사용하지 않고 리드 호스트만 클러스터 관리 역할을 수행할 수 있습니다. 캐시 클러스터를 사용할 수 있으려면 대부분의 리드 호스트가 항상 실행되고 있어야 하므로 이 시나리오의 캐시 클러스터는 서버 오류에 더 취약합니다. 또한 이 시나리오는 응용 프로그램의 가용성 측면에서 서버 유지 관리를 복잡하게 합니다. 자세한 내용은 리드 호스트 및 클러스터 관리(Windows Server AppFabric 캐싱)를 참조하십시오.

엔터프라이즈 배포

다른 배포 시나리오에 비해 엔터프라이즈 배포는 최상의 가용성 및 지원 가능성 환경을 제공합니다. 이 시나리오에는 일부 응용 프로그램에 대한 옵션이 될 수 없는 SQL Server 데이터베이스가 필요합니다.

SQL Server가 클러스터 관리 역할을 수행할 경우 클러스터에서 하나를 제외한 모든 캐시 서버가 손실되는 경우에도 클러스터는 실행을 유지할 수 있습니다. 공유 폴더 클러스터 구성 저장소 옵션을 사용할 경우와 같이 캐시 서버는 SQL Server 데이터베이스에 대해 지속적으로 네트워크로 연결되어 있어야 합니다.

이 시나리오의 캐시 서버는 클러스터 관리 역할을 수행하지 않으므로 가용성이 높은 응용 프로그램에 대한 서버 유지 관리가 크게 간소화됩니다. 서버를 다시 시작하는 복잡한 순서가 필요하지 않습니다. 자세한 내용은 리드 호스트 및 클러스터 관리(Windows Server AppFabric 캐싱)를 참조하십시오.

동시 연결이 필요한 상황에서는 SQL Server를 사용하는 것이 좋습니다. 이 방법을 사용하면 중간 규모 배포의 클러스터 크기 제한 없이 자동화된 병렬 캐시 서버 설치를 원활하게 진행할 수 있습니다. 자세한 내용은 .NET 4용 응용 프로그램 서버 확장 설치(영문)(https://go.microsoft.com/fwlink/?LinkId=169172)를 참조하십시오.

참고 항목

개념

아키텍처 개요
클러스터 구성 저장소 옵션(Windows Server AppFabric 캐싱)
공유 폴더 기반 클러스터 구성(Windows Server AppFabric 캐싱)
SQL Server 기반 클러스터 구성(Windows Server AppFabric 캐싱)
Windows PowerShell을 사용하여 Windows Server AppFabric 캐싱 기능 관리
리드 호스트 및 클러스터 관리(Windows Server AppFabric 캐싱)

  2011-12-05