논리 아키텍처 구성 요소(SharePoint Server 2010)
적용 대상: SharePoint Foundation 2010, SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
논리 아키텍처 디자인에서 구성 요소를 배치할 수 있는 방법은 다양합니다. 각 구성 요소는 서로 다른 공유 및 격리 기회를 제공합니다. 논리 아키텍처 디자인을 시작하기 전에 다음 작업을 수행해야 합니다.
공유 및 격리 목표를 파악합니다.
각 선택의 장단점을 평가합니다.
이 문서의 각 섹션에서는 특정 논리 아키텍처 구성 요소를 소개하고 용량, 공유 및 격리, 구성 가능한 항목, 관리, 계획 권장 사항의 측면에서 각 구성 요소에 대한 고려 사항을 설명합니다.
이 문서의 내용
서버 팜
서비스 응용 프로그램
IIS 응용 프로그램 풀
웹 응용 프로그램
영역
웹 응용 프로그램 정책
콘텐츠 데이터베이스
사이트 모음
사이트
호스트 이름이 지정된 사이트 모음
내 사이트
서버 팜
서버 팜은 디자인의 최상위 요소를 나타냅니다. 개별 서버 팜은 실제 격리 기능을 제공합니다.
다음을 비롯하여 조직에서 결정하는 다양한 기준이 필요한 서버 팜 수에 영향을 줄 수 있습니다.
서비스를 많이 사용할 경우에는 하나 이상의 전용 서비스 팜을 사용하는 것이 좋습니다.
책임에 따라 구분된 여러 운영 사업부
전용 자금원
여러 데이터 센터 위치
사이트 간 실제 격리에 대한 업계 요구 사항
그러나 단일 서버 팜에서 다양한 격리 요구 사항을 충족할 수 있습니다. 예를 들어 프로세스 ID가 서로 다른 여러 IIS(인터넷 정보 서비스) 응용 프로그램 풀을 사용하여 사이트 및 서비스 응용 프로그램 모두에 대해 프로세스 수준에서 격리를 구현할 수 있습니다.
둘 이상의 서버 팜이 필요할 수 있는 격리 요구 사항 이외에 성능 및 확장 목표, 라이선스 요구 사항 또는 게시 환경을 충족시키기 위해 조직에서 여러 서버 팜을 구현할 수도 있습니다.
서비스 응용 프로그램
서비스 응용 프로그램은 팜 내의 사이트 간에 또는 경우에 따라 여러 팜 간에 공유할 수 있는 리소스를 제공합니다.
SharePoint Server 2010에서는 서비스가 더 이상 SSP(공유 서비스 공급자) 내에 포함되지 않습니다. 대신 서비스를 호스팅하기 위한 인프라가 Microsoft SharePoint Foundation 2010으로 이동되어 서비스 제공을 훨씬 더 유연하게 구성할 수 있습니다. 즉, 개별 서비스를 독립적으로 구성할 수 있으며 타사에서 서비스를 해당 플랫폼에 추가할 수 있습니다.
팜에 필요한 서비스만 배포할 수 있습니다. 이때 배포되는 서비스를 서비스 응용 프로그램이라고 합니다.
서비스 응용 프로그램은 웹 응용 프로그램과 연결되며 각 서비스 응용 프로그램을 서로 다르게 구성할 수 있습니다.
배포되는 전체 서비스 집합이 아닌 필요한 서비스만 사용하도록 웹 응용 프로그램을 구성할 수 있습니다.
팜에서 같은 서비스의 여러 인스턴스를 배포하고 결과로 생성되는 서비스 응용 프로그램에 고유한 이름을 할당할 수 있습니다.
같은 팜 내 여러 웹 응용 프로그램 간에 서비스 응용 프로그램을 공유할 수 있습니다.
일부 서비스 응용 프로그램은 여러 팜 간에 공유할 수 있습니다.
용량
단일 팜에서 권장되는 서비스 응용 프로그램 개수 제한은 없습니다.
공유 및 격리
서비스 응용 프로그램은 다음 두 가지 방법으로 공유할 수 있습니다.
서비스 응용 프로그램 및 서비스 데이터 공유. 웹 응용 프로그램 간에 공유되는 서비스의 기본 동작입니다. 예를 들어 같은 검색 응용 프로그램을 사용하는 웹 응용 프로그램 간에 검색 결과가 공유됩니다.
서비스 응용 프로그램만 공유하고 해당 서비스를 분할 모드에서 배포하여 데이터 격리. 호스팅 환경에서는 Windows PowerShell을 사용하여 분할 모드에서 서비스 응용 프로그램을 배포할 수 있습니다. 각 테넌트의 데이터는 해당 서비스에 사용되는 데이터베이스에서 별도의 파티션에 저장됩니다. 테넌트의 서비스 데이터를 해당 사이트에 매핑하는 데 테넌트의 구독 ID가 사용됩니다. 예를 들어 Search Service를 분할 모드에서 배포하는 경우 각 테넌트에는 해당하는 고유 콘텐츠에 대한 검색 결과만 표시됩니다.
참고
일부 서비스 응용 프로그램의 경우 분할이 지원되지 않습니다.
반대로, 서비스 응용 프로그램은 다음 두 가지 방법으로 격리할 수 있습니다.
여러 서비스 응용 프로그램을 별도의 응용 프로그램 풀에 배포하여 서비스 및 서비스 데이터에 대한 프로세스 격리 구현. 예를 들어 재무 팀에서 별도의 전용 Business Data Connectivity 응용 프로그램을 사용하는 것이 좋습니다.
분할 모드에서 서비스 배포. 이 방법은 테넌트가 서비스 데이터를 공유하지 않는 호스팅 환경에 적절합니다. 하지만 서비스 데이터 공유 요구와 격리 요구가 혼합된 환경에서는 실행할 수 없습니다.
필요한 경우 서비스 응용 프로그램을 서로 다른 응용 프로그램 풀에 배포하여 프로세스 격리를 구현하면 서비스 응용 프로그램을 추가로 격리할 수 있습니다. 하지만 응용 프로그램 풀은 제한된 리소스이므로 응용 프로그램 풀을 너무 많이 사용할 경우 팜 성능에 영향을 줄 수 있습니다. 자세한 내용은 이 문서의 응용 프로그램 풀을 참조하십시오.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
기본 그룹 |
기본적으로 모든 서비스 응용 프로그램은 기본 그룹에 포함됩니다. 서비스 응용 프로그램을 만들 때를 비롯하여 언제든지 서비스 응용 프로그램을 기본 프로그렘에서 추가 및 제거할 수 있습니다. 웹 응용 프로그램을 만들 때 기본 그룹을 선택하거나 사용자 지정 서비스 그룹을 만들 수 있습니다. 웹 응용 프로그램에서 사용할 서비스 응용 프로그램만 선택하여 사용자 지정 서비스 그룹을 만들면 됩니다. |
연결(프록시) |
서비스 응용 프로그램을 만들 때 해당 서비스 응용 프로그램에 대한 연결도 동시에 만들어집니다. 연결은 웹 응용 프로그램을 서비스 응용 프로그램에 연결하는 가상 항목입니다. Managed Metadata Service 같은 일부 서비스 응용 프로그램의 경우 연결에 설정을 저장합니다. Windows PowerShell에서는 연결을 프록시라고 합니다. |
서비스 응용 프로그램 사용 권한 |
하나 이상의 서비스 응용 프로그램에 대한 사용 권한을 부여하여 서비스 응용 프로그램의 관리를 다른 사용자에게 위임할 수 있습니다. |
신뢰할 수 있는 내 사이트 호스트 위치 |
여러 User Profile Service 응용 프로그램이 배포된 조직에서 이 기능을 사용하면 사용자가 자신의 프로필이 의도된 위치에 내 사이트를 만들 수 있으며 조직 전체에서 내 사이트를 여러 개 만들 수 없습니다. |
관리
서비스 응용 프로그램의 구성과 관리는 검색, 사용자 프로필, 관리되는 메타데이터 등의 개별 서비스 관리를 전문적으로 담당하는 관리자에게 위임할 수 있습니다.
호스팅 환경에서 테넌트는 해당 조직에 대한 서비스 설정 중 일부를 관리할 수 있습니다.
계획 권장 사항
여러 웹 응용 프로그램 간에 리소스를 공유하거나 콘텐츠를 격리하도록 서비스 응용 프로그램을 구성합니다.
예를 들어 기본 프록시 그룹에서 서비스를 공유하여 여러 웹 응용 프로그램 및 응용 프로그램 풀에 있는 여러 사이트를 통합하면 인트라넷 전체에서 분류, 콘텐츠 형식 및 프로필 공유를 제공할 수 있습니다. 이와 같은 공유는 여러 사이트와 응용 프로그램에서 개인 설정 및 엔터프라이즈 수준 표준화를 위해 제공됩니다. 이러한 선택은 여러 웹 응용 프로그램과 응용 프로그램 풀을 구현하여 얻을 수 있는 프로세스 격리와 여러 응용 프로그램에서 정보를 공유하고 프로필 데이터를 활용하려는 비즈니스 요구 간의 균형을 맞추는 예를 제공합니다.
전체적인 격리 목표를 향상시키도록 서비스 응용 프로그램을 구성할 수도 있습니다. 예를 들어 파트너 공동 작업에 전용 서비스 집합을 사용하면 파트너 사용자가 인트라넷 환경에 있는 중요한 정보를 검색하거나 이러한 정보에 액세스할 수 없습니다. 다음과 같은 방법으로 개별 서비스를 구성하여 사이트 모음 간에 콘텐츠를 추가로 격리할 수 있습니다.
검색 범위를 개별 사이트 모음으로 제한합니다.
AD DS(Active Directory 도메인 서비스)에서 같은 조직 구성 단위에 속한 사용자만 표시하도록 User Profile Service를 구성합니다.
Stsadm 명령줄 도구를 사용하여 사이트 모음의 구성원인 사용자만 표시되도록 사용자 선택을 구성합니다.
조직의 서비스 전략을 설계할 때 전체적인 콘텐츠 공유 또는 격리 목표를 향상시키도록 개별 서비스를 구성하는 방법을 고려하십시오.
호스팅 환경의 서비스 전략을 설계할 때 사용 가능하고 분할할 서비스를 결정하십시오.
응용 프로그램 풀
IIS(인터넷 정보 서비스) 7.0에서 응용 프로그램 풀은 작업자 프로세스 하나 또는 작업자 프로세스 집합에서 처리하는 하나 이상의 URL 그룹입니다.
SharePoint 2010 제품에서 사이트 모음 및 서비스를 만들 때 사용할 응용 프로그램 풀을 선택하거나 새 응용 프로그램 풀을 만들 수 있습니다. 각 응용 프로그램 풀은 자체의 고유한 작업자 프로세스를 포함하며 두 프로세스가 상호 작용하지 못하도록 서로 다른 ID 보안 계정을 가질 수 있습니다.
용량
응용 프로그램 풀의 메모리 오버헤드는 30-50MB에 응용 프로그램 풀 프로세스 공간에서 실행되는 응용 프로그램에 필요한 메모리를 더한 값입니다. 다양한 응용 프로그램 요구로 인해 응용 프로그램 풀의 메모리 사용량은 대부분 빠르게 800MB 이상에 도달합니다. 응용 프로그램 풀 수의 제한은 시스템에서 사용 가능한 메모리의 영향을 받습니다. 즉, 응용 프로그램 풀 수는 다음 두 요인에 따라 결정됩니다.
주소 지정이 가능한 가용 메모리
응용 프로그램 풀에서 실행되는 응용 프로그램에서 소모하는 메모리의 양
적절한 성능을 보장하려면 일반적으로 8개 이하의 응용 프로그램 풀을 사용하는 것이 좋습니다.
공유 및 격리
IIS 응용 프로그램 풀을 사용하면 여러 사이트가 같은 서버 컴퓨터에서 실행되면서도 자체 작업자 프로세스와 ID를 유지할 수 있습니다. 이를 통해 공격자가 한 사이트에서 악성 코드를 주입하여 다른 응용 프로그램 풀의 사이트를 공격할 수 있는 문제를 방지할 수 있습니다. 가장 중요한 점은 이 전략에서는 메모리 문자나 기타 문제를 유발하는 코드를 격리하므로 문제가 있는 코드가 전체 응용 프로그램에 영향을 주지 않는다는 것입니다.
구성 가능한 항목
필요한 경우 각 응용 프로그램 풀에 서로 다른 응용 프로그램 풀 ID를 사용하는 것이 보안이나 격리 측면에서 좋습니다.
관리
각 응용 프로그램 풀에 서로 다른 ID를 사용하는 경우 각 ID를 유지 관리해야 합니다.
계획 권장 사항
다음과 같은 경우에는 전용 응용 프로그램 풀을 사용하는 것이 좋습니다.
주로 익명인 콘텐츠에서 인증된 콘텐츠를 분리하려는 경우
Business Data Connectivity 같은 외부 비즈니스 응용 프로그램에 대한 암호를 저장하고 이러한 응용 프로그램과 상호 작용하는 응용 프로그램을 격리하려는 경우
웹 응용 프로그램
웹 응용 프로그램은 SharePoint 2010 제품에서 만들고 사용하는 IIS 웹 사이트입니다. 웹 응용 프로그램을 최대 4번 확장하여 SharePoint 2010 제품에서 4개의 추가 영역을 만들 수 있으며, 결과적으로 각각 다른 영역에서 단일 웹 응용 프로그램과 연결되는 최대 5개의 IIS 웹 사이트를 만들 수 있습니다. 또한 각 웹 응용 프로그램에 고유한 도메인 이름을 할당할 수 있습니다. 자세한 내용은 이 문서에서 영역을 참조하십시오.
공유 및 격리
각 웹 응용 프로그램에는 고유 도메인 이름이 있으며, 이 이름을 통해 사이트 간 스크립트 공격을 막을 수 있습니다.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
서비스 응용 프로그램 |
서비스 응용 프로그램은 웹 응용 프로그램과 연결됩니다. 웹 응용 프로그램을 만들 때 기본 프록시 그룹(서비스 응용 프로그램의 기본 집합)을 선택하거나 웹 응용 프로그램에 대한 사용자 지정 서비스 응용 프로그램 집합을 지정할 수 있습니다. 웹 응용 프로그램 내 모든 사이트는 같은 서비스 응용 프로그램의 서비스를 사용합니다. 서비스 응용 프로그램에서는 둘 이상의 웹 응용 프로그램에 서비스를 제공할 수 있으므로 웹 응용 프로그램 간에 콘텐츠 및 프로필 데이터를 공유할 수 있습니다. |
영역 |
웹 응용 프로그램 내에서 최대 5개의 영역을 만들 수 있습니다. 많은 사용자 그룹에 대해 서로 다른 액세스 및 정책 조건을 적용하려면 영역을 사용합니다. |
웹 응용 프로그램 정책 |
정책을 만들어 웹 응용 프로그램 내 하나 이상의 영역에서 사용 권한을 적용합니다. 특정 사용자나 사용자 그룹에 대한 정책을 만들 수 있습니다. 자세한 내용은 이 문서에서 웹 응용 프로그램 정책을 참조하십시오. |
관리
웹 응용 프로그램의 지속적인 관리가 중요하지 않습니다.
계획 권장 사항
일반적으로 전용 웹 응용 프로그램을 사용하여 다음을 수행할 수 있습니다.
익명 사용자가 사용할 수 있는 콘텐츠와 인증된 사용자가 사용할 수 있는 콘텐츠 분리
사용자 격리. 예를 들어 파트너 사이트를 별도의 웹 응용 프로그램에 배치하여 파트너가 인트라넷 콘텐츠에 액세스하지 못하도록 할 수 있습니다.
정책을 통해 사용 권한 적용. 예를 들어 하나 이상의 사용자 그룹에 대해 쓰기 액세스 권한을 명시적으로 거부하는 정책을 만들 수 있습니다. 웹 응용 프로그램 정책은 웹 응용 프로그램 내에서 개별 사이트나 문서에 대해 구성된 사용 권한에 관계없이 적용됩니다.
데이터베이스 성능 최적화. 응용 프로그램은 데이터 특성이 유사한 다른 응용 프로그램과 함께 콘텐츠 데이터베이스에 배치되는 경우 성능이 향상됩니다. 예를 들어 내 사이트의 데이터 특성에는 일반적으로 크기가 작은 다수의 사이트가 포함됩니다. 반면에 팀 사이트에는 대개 적은 수의 매우 큰 사이트가 포함됩니다. 이러한 두 가지 유형의 사이트를 별도의 웹 응용 프로그램에 배치하면 생성되는 데이터베이스가 유사한 특성을 가진 데이터로 구성되므로 데이터베이스 성능이 최적화됩니다.
관리 효율성 최적화. 별도의 웹 응용 프로그램을 만들면 별도의 사이트 및 데이터베이스가 만들어지므로 각 사이트의 휴지통, 만료 및 크기에 대한 서로 다른 제한을 구현하고 서비스 수준 계약을 서로 다르게 조정할 수 있습니다. 예를 들어 비즈니스에 중요하지 않은 사이트의 복원에 시간을 더 많이 허용할 수 있습니다.
영역
영역은 동일한 웹 응용 프로그램에 액세스하는 여러 가지 논리적 경로(URL)를 나타냅니다. 각 웹 응용 프로그램 내에서 사용 가능한 영역 이름(기본, 인트라넷, 인터넷, 사용자 지정 또는 익스트라넷) 중 하나를 사용하여 최대 5개의 영역을 만들 수 있습니다. 각 이름은 웹 응용 프로그램별로 한 번만 선택할 수 있고 각 영역은 IIS에서 서로 다른 웹 사이트로 나타납니다.
기본 영역은 웹 응용 프로그램을 만들 때 가장 먼저 만들어지는 영역입니다. 나머지 영역은 웹 응용 프로그램을 확장하여 만들어집니다.
용량
웹 응용 프로그램 내에 최대 5개의 영역을 만들 수 있습니다. 일반적으로 동일한 이름의 영역이 동일한 사용자에 대해 구성되도록 전체 웹 응용 프로그램에서 영역이 조정됩니다.
공유 및 격리
영역을 사용하여 다음을 기준으로 사용자를 분할할 수 있습니다.
인증 유형: 서로 다른 인증 공급자를 사용하도록 각 영역을 구성할 수 있으므로 여러 파트너 회사에서 동일한 콘텐츠를 공유할 수 있습니다.
네트워크 영역: 익스트라넷이나 인터넷 등의 다른 네트워크 영역에서 들어오는 사용자를 수용하도록 각 영역을 구성할 수 있습니다.
정책 사용 권한: 사용자 계정이나 그룹 계정에 따라 영역별로 콘텐츠에 대한 읽기 또는 쓰기 권한을 명시적으로 허용하거나 거부할 수 있습니다.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
인증 공급자 |
서로 다른 인증 공급자를 사용하도록 각 영역을 구성할 수 있습니다. |
익명 액세스 |
인명 액세스를 영역별로 설정하거나 해제합니다. |
SSL(Secure Sockets Layer) |
영역별로 SSL을 설정하거나 해제합니다. |
공용 URL 및 대체 액세스 매핑 |
사용자가 웹 응용 프로그램의 콘텐츠에 액세스하기 위해 입력할 도메인 이름을 지정합니다. 또는 대체 액세스 매핑을 사용하여 사용자에게 친숙하거나 영역에 적합한 URL을 각 영역의 URL(서버 이름 및 포트)에 매핑합니다. 대체 액세스 매핑은 오프 박스 SSL 종료를 지원합니다. 오프 박스 SSL 종료는 프록시 서버가 SSL 요청을 종료한 다음 HTTP를 사용하여 웹 서버에 요청을 전달하는 것을 의미합니다. 이 경우에 대체 액세스 매핑은 SSL을 사용하여 이러한 요청을 반환하도록 구성될 수 있으므로 클라이언트와 프록시 서버 간의 보안 통신을 유지할 수 있습니다. |
웹 응용 프로그램 정책 |
웹 응용 프로그램 내의 각 영역에 대한 고유한 정책 집합을 만듭니다. 전체적인 보안 정책에 대한 예외가 필요한 특수한 사용자 그룹이 있는 경우 별도의 영역을 사용하여 이러한 사용자를 수용하는 것이 좋습니다. |
관리
대체 액세스 매핑을 사용하는 경우 공용 URL을 팜에 사용되는 부하 분산 장치의 IP 주소에 매핑하기 위해 모든 공용 URL에 DNS(Domain Name System) 항목이 필요하다는 사실을 고려합니다.
계획 권장 사항
영역을 디자인할 때는 성공적인 배포를 위해 몇 가지 주요 사항을 결정해야 합니다. 이러한 사항에는 다음 영역에 대한 디자인 및 구성 결정 사항이 포함됩니다.
기본 영역
외부 액세스용 영역
다음 섹션에서는 기본 영역을 비롯한 영역에 대한 몇 가지 계획 권장 사항과 요구 사항에 대해 설명합니다.
관리 전자 메일은 기본 영역의 링크와 함께 전송됩니다. 여기에는 할당량 제한에 도달한 사이트 소유자에게 전송되는 전자 메일이 포함됩니다. 따라서 관리 전자 메일 메시지와 경고를 받는 사용자는 기본 영역을 통해 링크에 액세스할 수 있어야 합니다. 이는 사이트 소유자에게 특히 중요합니다.
호스트 이름이 지정된 사이트 모음은 기본 영역을 통해서만 사용할 수 있습니다. 호스트 이름이 지정된 사이트 모음에 액세스하려는 모든 사용자는 기본 영역을 통해 액세스할 수 있어야 합니다.
기본 영역은 가장 보안이 강화된 영역이어야 합니다. 이는 사용자 요청을 영역에 연결할 수 없는 경우 기본 영역의 인증과 정책이 적용되기 때문입니다.
익스트라넷 환경에서는 다음 두 가지 이유로 인해 영역 디자인이 중요합니다.
사용자 요청이 내부 네트워크, 파트너 회사 네트워크 또는 인터넷과 같은 몇 가지 네트워크에서 시작될 수 있습니다.
사용자는 여러 웹 응용 프로그램의 콘텐츠를 사용합니다. 예를 들어 인트라넷 환경에 몇 가지 웹 응용 프로그램에서 호스팅되는 사이트가 포함될 수 있습니다. 또한 직원이 인트라넷 콘텐츠와 파트너 공동 작업 콘텐츠에 모두 액세스할 수도 있습니다.
익스트라넷 환경에서는 다음과 같은 디자인 원칙을 따라야 합니다.
여러 웹 응용 프로그램에서 영역을 서로 동일하게 구성합니다. 인증 구성과 의도한 사용자가 같아야 합니다. 그러나 영역에 연결된 정책은 웹 응용 프로그램에 따라 다를 수 있습니다. 예를 들어 인트라넷 영역은 모든 웹 응용 프로그램에서 동일한 직원용으로 사용되어야 합니다. 즉, 인트라넷 영역을 특정 웹 응용 프로그램에서는 내부 직원용으로 구성하고 다른 웹 응용 프로그램에서는 원격 직원용으로 구성하면 안 됩니다.
각 영역과 각 리소스에 대해 대체 액세스 매핑을 적절하고 정확하게 구성합니다.
웹 응용 프로그램 정책
웹 응용 프로그램 정책은 웹 응용 프로그램 내의 모든 콘텐츠에 사용 권한을 적용하여 웹 응용 프로그램 수준에서 사용자에 대한 보안 정책을 설정할 수 있도록 합니다. 정책의 사용 권한은 사이트와 콘텐츠에 대해 구성된 다른 모든 보안 설정보다 우선합니다.
AD DS의 사용자나 사용자 그룹을 기준으로 정책을 구성할 수 있지만 SharePoint 그룹은 기준으로 사용할 수 없습니다. 정책을 웹 응용 프로그램에 대해 일반적으로 정의하거나 특정 영역에 대해서만 정의할 수 있습니다.
용량
웹 응용 프로그램 정책에 적용되는 용량 제한은 없습니다.
공유 및 격리
웹 응용 프로그램 정책을 통해 사용자와 사용자가 콘텐츠에 액세스하는 데 사용하는 영역에 따라 사용 권한을 설정할 수 있습니다.
예를 들어 정책을 사용하여 다음 작업을 수행할 수 있습니다.
지원 센터 직원이 모든 콘텐츠에 액세스할 수 있도록 허용합니다.
파트너나 공급업체에 대한 쓰기 권한을 거부합니다.
사이트 소유자가 사용 권한을 구성하는 방법에 관계없이 특정 사용자 그룹에 대한 보안 데이터 액세스 권한을 거부합니다.
크롤링 계정이 모든 콘텐츠를 크롤링할 수 있는 권한을 갖도록 합니다.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
사용자 정책 |
사용자 또는 사용자 그룹에 적용되는 정책을 만듭니다.
중앙 관리에서 정책을 만들 때 권한 정책을 클릭하여 기본 권한 수준을 수정하거나 새 권한 수준을 만들 수 있습니다. |
익명 정책 |
웹 응용 프로그램 또는 하나 이상의 영역에 대해 익명 액세스를 사용하도록 설정한 경우 모든 익명 사용자에게 적용되는 정책을 만들 수 있습니다. 기본 정책 설정은 다음과 같습니다.
익명 사용자 정책 수준은 수정할 수 없습니다. |
권한 정책 |
기본 권한 수준 중 하나와 연결된 특정 권한을 편집하거나 새 권한 정책 수준을 만듭니다. 또는 사이트 모음 및 사이트에 대해 허용하거나 거부하는 특정 권한을 지정할 수 있습니다. 새 권한 정책 수준을 만든 후에는 해당 권한 정책을 사용하는 사용자 정책을 만들 수 있습니다. |
관리
웹 응용 프로그램 정책의 지속적인 관리가 중요하지 않습니다.
계획 권장 사항
정책이 중앙에서 관리되므로 개별 사용자보다는 많은 사용자 그룹을 관리하는 데 정책을 사용하는 것이 좋습니다.
콘텐츠 데이터베이스
기본적으로 웹 응용 프로그램의 모든 콘텐츠는 하나의 콘텐츠 데이터베이스에 저장됩니다. 사이트 모음 수준에서 콘텐츠를 여러 콘텐츠 데이터베이스로 분리할 수 있습니다. 콘텐츠 데이터베이스에는 하나 이상의 사이트 모음이 포함될 수 있지만 한 사이트 모음이 여러 데이터베이스에 포함될 수는 없습니다. 사이트의 백업과 복원은 콘텐츠 데이터베이스 수준에서 수행됩니다.
용량
적절한 성능을 보장하려면 웹 응용 프로그램당 100개 이하의 콘텐츠 데이터베이스를 구현하는 것이 좋습니다.
공유 및 격리
데이터베이스에 대한 계획을 수립하여 효율성(데이터베이스를 공유하는 여러 사이트 모음)이나 격리(사이트 모음당 하나의 데이터베이스)를 위해 최적화할 수 있습니다.
데이터베이스를 최대 대상 크기까지 관리하여 규모의 효율성을 달성합니다. 이 경우에 최대 사이트 모음 수에 도달할 때까지 새 사이트 모음을 기존 데이터베이스에 추가하도록 데이터베이스 설정을 구성합니다. 최대 사이트 모음 크기를 데이터베이스의 최대 대상 크기로 나누거나 평균을 추정하여 최대 사이트 모음 수를 계산합니다. 이 방법은 내 사이트와 같이 많은 수의 작은 사이트 모음이 예상되는 경우에 효과적입니다.
데이터베이스를 한 사이트 모음으로 제한하여 팀이나 프로젝트 간의 콘텐츠 격리를 달성합니다. 이 방법을 사용하면 개별 팀의 콘텐츠를 독립적으로 관리할 수 있습니다. 예를 들어 각 팀의 데이터베이스에 대한 백업, 복구 및 마이그레이션을 독립적으로 관리할 수 있습니다. 이 방법을 통해 팀이나 프로젝트마다 서로 다른 서비스 수준 계약을 구현할 수 있습니다. 또한 프로젝트의 수명 주기에 맞게 콘텐츠를 관리할 수도 있습니다. 예를 들어 프로젝트가 완료될 때 데이터베이스를 보관할 수 있습니다.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
데이터베이스 서버 |
콘텐츠 데이터베이스가 만들어지는 SQL Server 컴퓨터를 지정합니다. |
장애 조치(failover) 서버 |
콘텐츠 데이터베이스를 SQL Server 데이터베이스 미러링과 함께 사용되는 특정 장애 조치(failover) 서버와 연결할 수도 있습니다. |
용량 설정 |
경고 이벤트가 생성되기 전에 만들 수 있는 사이트 수와 각 데이터베이스에서 만들 수 있는 최대 사이트 수를 지정할 수 있습니다. |
관리
관리하기 쉬운 데이터베이스 관리 계획에서는 데이터베이스 수와 데이터베이스 관리에 필요한 리소스 간의 균형을 맞춥니다.
데이터베이스 관리에는 다음이 포함됩니다.
전용 데이터베이스가 필요한 새 팀 사이트나 사이트 모음에 대한 새 데이터베이스 만들기
데이터베이스 크기 모니터링 및 대상 크기 도달 시 새 데이터베이스 만들기
데이터베이스 백업 및 복원
계획 권장 사항
다음 두 방법 중 하나를 선택합니다.
적절한 크기 경고 임계값을 사용하여 콘텐츠 데이터베이스의 대상 크기를 설정합니다. 크기 경고 임계값에 도달하면 새 데이터베이스를 만듭니다. 이 방법을 사용하면 대상 크기만을 기준으로, 사용 가능한 하나 이상의 데이터베이스에 사이트 모음이 자동으로 추가됩니다.
사이트 모음을 특정 콘텐츠 데이터베이스에 연결합니다. 이 방법을 사용하면 다른 데이터베이스와 독립적으로 관리할 수 있는 전용 데이터베이스에 하나 이상의 사이트 모음을 배치할 수 있습니다.
사이트 모음을 특정 콘텐츠 데이터베이스에 연결하려는 경우 다음과 같은 방법을 사용할 수 있습니다.
Windows PowerShell을 사용하여 새 데이터베이스에 사이트 모음을 만듭니다.
SharePoint 중앙 관리 웹 사이트의 콘텐츠 데이터베이스 설정 관리 페이지에서 다음 데이터베이스 용량 설정을 적용합니다.
경고 이벤트가 생성되기 전 사이트 수 = 0
이 데이터베이스에서 만들 수 있는 최대 사이트 개수 = 1
다음 단계를 수행하여 전용 데이터베이스에 사이트 모음 그룹을 추가합니다.
웹 응용 프로그램에 대한 콘텐츠 데이터베이스를 추가하고 데이터베이스 상태를 "준비"로 설정합니다.
다른 모든 데이터베이스의 상태를 "오프라인"으로 설정합니다. 콘텐츠 데이터베이스가 오프라인 상태이면 새 사이트 모음을 만들 수 없지만, 오프라인 데이터베이스의 기존 사이트 모음에는 계속 액세스하여 읽기 및 쓰기 작업을 수행할 수 있습니다.
사이트 모음을 만듭니다. 사이트 모음이 온라인 데이터베이스에 자동으로 추가됩니다.
다른 모든 데이터베이스의 상태를 다시 "준비"로 설정합니다.
사이트 모음
사이트 모음은 소유자가 같고 관리 설정을 공유하는 웹 사이트 집합입니다. 각 사이트 모음에는 하나의 최상위 웹 사이트가 있고 하나 이상의 하위 사이트를 포함할 수 있습니다.
용량
적절한 성능을 보장하려면 콘텐츠 데이터베이스당 50,000개 미만의 사이트 모음을 구현하는 것이 좋지만 사이트 모음이 약 10,000개가 되면 성능에 영향을 줄 수 있습니다. 사이트 모음을 여러 데이터베이스 서버에 분산하여 수평 확장하면 저장소 용량과 처리량이 늘어납니다.
공유 및 격리
사이트 모음은 사용 권한, 탐색 및 기능 배포에 영향을 미치는 몇 가지 공유 및 격리 기회를 제공합니다.
다음 항목은 한 사이트 모음 내에서 공유할 수 있으며 여러 사이트 모음에서는 공유할 수 없습니다. 단, layouts 디렉터리의 기능과 같이 파일 시스템에 저장되는 항목은 예외입니다.
마스터 페이지
페이지 레이아웃
이미지
사이트 서식 파일
또한 사용 권한과 탐색은 다음과 같이 사이트 모음 수준에서 격리됩니다.
사이트 모음 내의 하위 사이트는 최상위 사이트에서 사용 권한을 상속할 수 있습니다.
사이트 모음은 다른 사이트 모음에서 사용 권한을 상속할 수 없습니다.
사이트 모음 간 탐색 기능은 기본 제공되지 않습니다.
마지막으로, SharePoint Server 2010은 검색 범위에 따라 사이트 모음이나 데이터베이스의 수에 관계없이 사용자의 사용 권한을 바탕으로 여러 사이트 모음에서 검색 결과를 집계합니다.
사용 권한이 개별 사이트에 적용되지만 사이트가 도메인에 있는 다른 사이트에서의 사이트 간 스크립트 공격에 여전히 취약하다는 사실을 명심해야 합니다.
구성 가능한 항목
다음 표에는 격리와 공유에 도움이 되는 구성 가능한 항목이 나와 있습니다.
항목 |
설명 |
사이트 모음 관리자 |
한 사용자를 주 사이트 모음 관리자로 지정하고 한 사용자를 보조 사이트 모음 관리자로 지정할 수 있습니다. 중앙 관리에서 이러한 역할에 둘 이상의 계정을 입력할 수 없으며 이러한 역할에 그룹 계정을 입력할 수 없습니다. |
사이트 서식 파일 |
사이트 서식 파일은 새로운 사이트에서 사용 가능한 목록 및 기능을 결정합니다. 사이트를 만든 후에는 사이트의 많은 측면을 사용자 지정할 수 있지만 사이트 서식 파일은 사이트를 만들고 나면 변경할 수 없습니다. |
할당량 지정 서식 파일 |
할당량 지정 서식 파일을 적용하여 사이트 모음에 사용되는 리소스를 제한할 수 있습니다. 다음과 같은 서식 파일이 제공됩니다.
|
다음 표에는 격리와 공유에 도움이 되는 사이트 모음 내의 구성 가능한 항목이 나와 있습니다. 이러한 설정은 앞의 표에 나온 설정을 사용하여 사이트 모음을 만든 후 사용할 수 있습니다.
항목 |
설명 |
사이트 모음 관리자 |
여러 사용자 계정을 사이트 모음 관리자로 지정할 수 있습니다. 그룹 계정은 추가할 수 없습니다. |
권한 수준 |
사용자 및 그룹 계정을 사이트 모음에 추가하고 각각에 대한 권한 수준을 지정합니다. |
관리
사이트 모음을 만드는 작업은 호스트 이름이 지정된 사이트 모음을 만드는 경우를 제외하고 DNS 항목을 필요로 하지 않으며 쉽게 자동화하거나 사용자에게 위임할 수 있습니다. 팀 사이트의 사이트 모음을 중앙에서 만들거나 사용자가 셀프 서비스 사이트 관리를 통해 사이트 모음을 직접 만들게 할 수 있습니다.
사이트 모음에 전용 데이터베이스를 사용하면 사이트 모음 수준에서 백업 및 복구를 수행할 수 있습니다.
계획 권장 사항
사이트 모음은 논리 아키텍처와 정보 아키텍처를 서로 연결합니다. 사이트 모음을 디자인할 때 다음 두 디자인 작업을 고려하십시오.
조직 전반에서 일관성 있는 URL 디자인
논리적으로 콘텐츠 분할
호스트 이름이 지정된 사이트 모음을 사용하지 않는 경우 각 웹 응용 프로그램에 루트 수준 사이트 모음이 하나 있어야 합니다. 이 경우 웹 응용 프로그램에 있는 해당 사이트에 대한 URL 경로가 하나 제공됩니다. 이는 웹 응용 프로그램 내에 여러 영역을 구현하는 경우에도 해당하는 요구 사항입니다. 자세한 내용은 이 문서에서 호스트 이름이 지정된 사이트 모음을 참조하십시오.
많은 조직이 조직 내의 여러 팀이나 사업부가 사용할 여러 사이트 모음을 웹 응용 프로그램 내에서 구현하려고 합니다. 일반적인 디자인 목표는 다음과 같습니다.
각 팀의 개별적이고 독립적인 사이트 모음을 유지 관리합니다.
각 팀의 고유 URL을 만듭니다.
팀 간에 콘텐츠를 격리합니다.
이러한 목표를 충족하기 위해 관리 경로를 사용하여 여러 최상위 사이트 모음을 웹 응용 프로그램 내에 통합할 수 있습니다. 관리 경로를 정의하면 웹 응용 프로그램의 URL 네임스페이스에서 사이트 모음에 사용되는 경로를 지정할 수 있습니다. 한 사이트 모음이나 둘 이상의 사이트 모음이 루트 사이트 아래에 있는 별도의 경로에 있도록 지정할 수 있습니다. 관리 경로를 사용하지 않는 경우에는 루트 사이트 모음 아래에 만드는 모든 사이트가 루트 사이트 모음의 일부가 됩니다.
다음과 같은 두 가지 유형의 관리 경로를 만들 수 있습니다.
명시적 포함 명시적으로 할당된 URL이 적용된 사이트 모음입니다. 명시적 포함은 사이트 모음 하나에만 적용됩니다. 확장을 관리하고 이러한 사이트를 개별적으로 백업 및 복원하는 기회를 제공하려는 경우 이러한 각 사이트 모음을 서로 다른 콘텐츠 데이터베이스에 연결할 수 있습니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://fabrikam/hr입니다. 명시적 포함으로 만드는 사이트 모음 수는 대략 100개로 제한되지만 원활한 작동을 위해 사이트 모음 수는 최대 20개가 적절합니다. 조직에서 더 많은 수의 사이트 모음이 필요한 경우 와일드카드 포함을 대신 사용하십시오.
와일드카드 포함: URL에 추가되는 경로입니다. 이 경로는 경로 이름 바로 뒤에 지정된 모든 사이트가 고유 사이트 모음임을 나타냅니다. 이 방법은 일반적으로 내 사이트나 파트너 공동 작업용으로 만든 사이트와 같은 셀프 서비스 사이트 관리를 지원하는 데 사용됩니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://partnerweb/sites/project1과 http://partnerweb/sites/project2입니다. 이러한 예에서 "http://partnerweb"은 루트 수준 사이트 모음을 나타내고 "/sites"는 와일드카드 포함을 나타냅니다.
사이트
사이트는 하나 이상의 관련 웹 페이지와 사이트 모음 안에서 호스팅되는 기타 항목(예: 목록, 라이브러리 및 문서)으로 구성됩니다.
용량
적절한 성능을 보장하려면 사이트 모음당 250,000개 미만의 사이트를 구현하는 것이 좋습니다. 하위 사이트를 중첩하여 매우 많은 수의 웹 사이트를 만들 수 있습니다. 하지만 하위 사이트를 너무 많이 중첩하면 사이트를 업그레이드하는 시간에 크게 영향을 줄 수 있으므로 원활한 작동을 위해 한 사이트 모음 내 사이트 수는 5,000개가 적절합니다.
공유 및 격리
사이트에는 사이트 모음 내의 한 하위 사이트에서 다른 하위 사이트로의 기본 제공 탐색 기능이 포함되어 있습니다. 사이트 모음 간 탐색 기능은 기본 제공되지 않습니다.
사이트 모음의 경우와 마찬가지로 개별 사이트는 도메인에 있는 다른 사이트에서의 사이트 간 스크립트 공격에 취약합니다.
구성 가능한 요소
각 사이트에서 해당 사이트의 Owners 그룹에 사용자 또는 그룹 계정을 추가할 수 있습니다.
관리
다양한 도구를 사용하여 개별 사이트를 백업하고 복원할 수 있습니다.
호스트 이름이 지정된 사이트 모음
호스트 이름이 지정된 사이트 모음은 웹 응용 프로그램 내에 여러 루트 수준 사이트 모음을 만들려는 경우에 사용할 수 있습니다. 예를 들어 호스팅 조직의 관리자는 호스트 이름이 지정된 사이트 모음을 사용하여 도메인 이름이 지정된 사이트를 여러 개 만듭니다.
호스트 이름이 지정된 사이트 모음을 만드는 데 필요한 특수 모드(예: 호스트 헤더 모드)는 없습니다. Windows PowerShell을 사용하여 호스트 이름이 지정된 사이트 모음을 만듭니다. 또는 Windows PowerShell에서 호스트 이름이 지정된 사이트 모음에 대해 관리 경로(New-SPManagedPath –HostHeader)를 사용할 수도 있습니다.
호스트 이름이 지정된 사이트 모음을 사용하면 URL을 더욱 효과적으로 제어할 수 있지만 이러한 사이트 모음은 기본 영역을 통해서만 사용할 수 있습니다. 다른 영역을 통해 인증하도록 구성된 사용자 계정은 호스트 이름이 지정된 사이트 모음에 액세스할 수 없습니다.
SharePoint 2010 제품에서 호스트 이름이 지정된 사이트 모음은 오프 박스 SSL 종료를 지원하지만 프로토콜 스키마만 오프 박스(http:// 또는 https://)로 변경할 수 있습니다. 역방향 프록시 서버는 기본 SSL 포트에서 기본 HTTP 포트로 전환하는 경우를 제외하고는 호스트 이름 또는 포트 번호를 변경할 수 없습니다.
용량
한 IIS 웹 사이트에 최대 100,000개의 호스트 이름이 지정된 사이트 모음을 만들 수 있습니다.
공유 및 격리
호스트 이름이 지정된 사이트 모음에서 생성되는 독립적인 도메인 이름은 두 사이트 간의 사이트 간 스크립트 공격을 방지하는 데 도움이 됩니다.
관리
호스트 이름이 지정된 사이트 모음에 대한 관리 작업은 다음과 같습니다.
Windows PowerShell을 사용하여 호스트 이름이 지정된 사이트 모음을 추가합니다.
호스트 이름이 지정된 사이트 모음마다 별도의 DNS 항목이 필요합니다.
내 사이트
내 사이트는 각 사용자에 따라 개인 설정되는 특수한 SharePoint 사이트입니다. 내 사이트는 User Profile Service의 일환으로 사용할 수 있도록 기본 설정되며 조직의 모든 사용자는 고유한 내 사이트를 만들 수 있습니다. 용량, 공유 및 격리, 관리에 대한 자세한 내용은 이 문서 앞부분의 사이트를 참조하십시오.