공동 작업 사이트용 논리 아키텍처 디자인

  • 아티클

업데이트 날짜: 2009년 4월

적용 대상: Office SharePoint Server 2007

 

마지막으로 수정된 항목: 2015-03-09

이 문서의 내용

  • 인트라넷 환경 내의 팀 사이트 정보

  • 팀 사이트 디자인 권장 사항

  • 전용 웹 응용 프로그램에서 팀 사이트 호스팅

  • 웹 응용 프로그램 일반 설정 계획

  • 사용자가 사이트 모음을 만들 수 있도록 지정할지 여부 선택

  • 팀 사이트의 콘텐츠 데이터베이스 설정 디자인

  • 사용하지 않는 사이트 자동 삭제

  • 경로를 사용하여 팀 사이트 URL 구성

  • 사용자 지정 요소 계획

  • 팀 사이트에 적용할 사용 권한 계획

Microsoft Office SharePoint Portal Server 2003에서는 팀 사이트의 기능이 포털 사이트에 비해 제한되어 있지만, Microsoft Office SharePoint Server 2007에서는 그렇지 않습니다. Office SharePoint Server 2007에서는 인트라넷 환경에서 기능을 사용할 수 있으면 인트라넷 환경 내의 공동 작업 사이트가 게시된 인트라넷 포털 사이트와 동일한 기능을 활용할 수 있습니다. 이 문서에서는 이러한 사이트를 앞서 언급한 것과 같이 "팀 사이트"라고 지칭합니다. 그러나 이러한 사이트에서는 이전 버전 소프트웨어에 포함되어 있던 것보다 훨씬 다양한 기능을 제공합니다. 따라서 여기서 "팀 사이트"라는 명칭은 게시되어 있으며 제어되는 인트라넷 포털 사이트와는 달리 소규모 그룹이나 특별 공동 작업에 사용되는 사이트를 의미합니다.

팀 사이트는 대부분의 Office SharePoint Server 2007 배포에서 중요한 부분이며, 인트라넷 배포의 경우 특히 중요합니다. 팀 사이트가 활성화하는 공동 작업과 제공하는 저장 공간은 장기 프로젝트와 단기 프로젝트, 통신 및 그룹 간 공동 작업에 유용합니다. 배포의 일부분으로 팀 사이트를 제공하려는 경우에는 초기 아키텍처 디자인에 팀 사이트를 포함해야 사이트 호스팅 및 관리를 계획할 수 있습니다. 예를 들어 팀 사이트 콘텐츠 호스팅에 필요한 콘텐츠 데이터베이스를 계획해야 하고, 보다 많은 프로젝트를 포함하기 위한 단기 프로젝트 팀 사이트 보관 및 삭제를 계획해야 하며, 팀 통신 사이트의 크기가 백업 및 복구용으로 관리하기에 적합하도록 모니터링해야 합니다.

이 문서에서는 서버 팜 내에서 팀 사이트를 배포하기 위한 논리 아키텍처 디자인 권장 사항을 제공합니다. 그러나 팀 사이트의 정보 아키텍처(내부 구조)에 대해서는 설명하지 않습니다. 정보 아키텍처 디자인에 대한 자세한 내용은 웹 사이트 구조 및 게시 계획(Office SharePoint Server)을 참조하고, 팀 사이트에 대한 자세한 내용은 공동 작업 사이트 계획을 참조하십시오.

인트라넷 환경 내의 팀 사이트 정보

Office SharePoint Server 2007 인트라넷 환경에서는 팀 사이트를 사이트 디렉터리에 나열하여 게시된 인트라넷 포털 사이트에 연결할 수 있습니다. 게시된 사이트의 사이트 디렉터리를 통해 팀 사이트를 만들어 사이트가 동일한 호스트 이름을 공유하도록 할 수도 있고, 이미 있는 사이트를 사이트 디렉터리에 추가하여 모든 관련 팀 사이트를 단일 위치에서 집계할 수도 있습니다. 이 방식을 사용하면 URL에 관계없이 모든 사이트를 게시된 인트라넷 포털의 일부분으로 표시할 수 있습니다.

팀 사이트는 작업 환경의 게시된 사이트와 동일한 기능 집합을 포함하는 SharePoint 사이트이므로 작업 환경에서 사용 가능한 비즈니스 인텔리전스, 양식 및 기타 기능도 사용할 수 있습니다. 이러한 기능은 팀 사이트 아키텍처에 영향을 줄 수 있습니다. 예를 들어 팀 사이트에 비즈니스 데이터 카탈로그의 비즈니스 데이터를 표시해야 하는 경우에는 해당 팀 사이트의 구성원에게 데이터 보기 권한이 있는지 확인해야 합니다. 비즈니스 인텔리전스 기능 및 보안은 SSP(공유 서비스 공급자) 수준에서 구성되므로 동일한 비즈니스 데이터에 연결하는 모든 팀 사이트는 동일한 SSP를 사용해야 하며 해당 SSP에 연결된 웹 응용 프로그램에 있어야 합니다.

작업 환경에서 비즈니스 인텔리전스 및 양식을 계획하는 방법에 대한 자세한 내용은 다음 리소스를 참조하십시오.

팀 사이트 디자인 권장 사항

대부분의 조직에서는 시간에 따라 팀 사이트 수가 증가하며 개별 팀 사이트의 크기도 빠르게 커집니다. 팀이 개편되거나 프로젝트가 완료되고 새 프로젝트가 시작되면 팀에서는 새 팀 사이트를 만들고 이전 사이트를 삭제하거나, 현재 팀 사이트를 확장하여 점점 더 많은 데이터를 포함하게 됩니다. 이러한 사이트 증가를 관리 또는 제어하려면 팀 사이트 지원을 주의 깊게 계획해야 합니다.

팀 사이트 디자인 목표는 다음과 같습니다.

  • 전체 서버 팜의 성능 최적화

  • 예정된 유지 관리 작업(예: 백업, 복구, 업그레이드)을 위해 팀 사이트 데이터베이스의 논리적인 분할 작성

  • 인트라넷 내의 다른 사이트 형식에는 영향을 주지 않고 팀 사이트에 적합한 정책 및 설정 적용

팀 사이트 디자인 지침을 결정할 때는 다음 권장 사항을 고려해야 합니다. 각 권장 사항에 대해서는 이어지는 섹션에서 설명합니다.

  • 전용 웹 응용 프로그램에서 팀 사이트 호스팅

  • 할당량 및 수명 주기 관리 설정 등의 일반 웹 응용 프로그램 설정을 웹 응용 프로그램 수준에서 적용하여 팀 사이트 확장을 관리하고 콘텐츠를 최신 상태로 유지

  • 적절한 저장소 및 범위를 선택하고 지정된 크기로 데이터베이스를 백업 및 복원할 수 있도록 콘텐츠 데이터베이스 설정 디자인

  • 사용하지 않는 사이트 자동 삭제

  • 경로를 사용하여 팀 사이트 URL 구성

  • 적절한 정책 및 사용 권한 계획

전용 웹 응용 프로그램에서 팀 사이트 호스팅

팀 사이트는 전용 웹 응용 프로그램 또는 내 사이트와 공유하는 웹 응용 프로그램에서 호스팅합니다. 게시된 인트라넷 포털 사이트와 같은 웹 응용 프로그램에서는 팀 사이트를 호스팅하지 않는 것이 좋습니다. 팀 사이트를 인트라넷 포털 사이트와 분리하면 데이터를 보다 쉽게 복구 및 유지 관리할 수 있습니다. 이는 콘텐츠 데이터베이스 크기를 관리하는 경우에는 그다지 문제가 되지 않습니다. 다음 그림에는 인트라넷 솔루션의 팀 사이트가 포함된 웹 응용 프로그램이 나와 있습니다.

공동 작업 사이트용 논리적 아키텍처

팀 사이트를 호스팅하는 데 여러 전용 웹 응용 프로그램을 사용할 수 있습니다. 다음 예제를 살펴보십시오.

  • 미국의 한 투자 금융 및 자산 조사 회사에서 미국 증권 거래 위원회 규정을 준수하기 위해 투자 금융부 사이트와 자산 조사부 사이트를 완전히 분리하고자 합니다. 이 경우 회사에서는 각 부서에 대해 분리된 팀 사이트 모음 집합이 포함된 두 가지 웹 응용 프로그램을 사용해야 합니다. 또한 웹 응용 프로그램 정책과 별도의 SSP를 사용하여 각 부서의 사용자가 다른 부서에서 생성하는 콘텐츠를 볼 수 없도록 해야 합니다.

  • 한 조사 및 제조 회사에서 지적 재산 및 조사 결과를 엄격하게 통제하고자 합니다. 이 경우 회사에서는 별도의 웹 응용 프로그램에서 조사 팀 사이트를 호스팅하고, 웹 응용 프로그램 정책을 통해 사용 권한을 적용하는 동시에 조사 담당 직원만이 조사 팀 사이트의 콘텐츠를 보도록 할 수 있습니다.

  • 내부(인트라넷) 및 외부(익스트라넷) 팀 사이트를 모두 호스팅하는 한 조직에서 이 두 사이트를 각각 다르게 구현 및 관리하고자 합니다. 이 경우 조직에서는 두 웹 응용 프로그램을 별도로 계획 및 구현하여 두 팀 사이트 집합을 호스팅합니다. 이렇게 하면 문제가 발생하는 경우를 대비해 각 환경에 서로 다른 인증 방법, 데이터베이스 및 IIS 로그를 사용할 수 있습니다. 익스트라넷을 계획하는 방법에 대한 자세한 내용은 익스트라넷 팜 토폴로지 디자인(Office SharePoint Server)을 참조하십시오.

일반적으로 전용 웹 응용 프로그램을 사용하여 다음을 수행할 수 있습니다.

  • 익명 콘텐츠와 인증된 콘텐츠 분리

  • 사용자 격리

  • 사용 권한 적용

  • 성능 최적화

  • 관리 용이성 최적화

공유 웹 응용 프로그램과 전용 웹 응용 프로그램 중 어느 쪽을 사용할지 결정하는 방법에 대한 자세한 내용은 논리 아키텍처 모델: 기업 배포를 참조하십시오.

성능 고려

전용 웹 응용 프로그램에서 팀 사이트를 호스팅하는 경우에는 팀 사이트 모음만을 포함하는 콘텐츠 데이터베이스가 여러 개 있습니다. 여러 콘텐츠 데이터베이스가 데이터 특성이 유사한 사이트를 호스팅하는 경우 Microsoft SQL Server 데이터베이스 소프트웨어가 보다 효율적으로 작동하는데, SQL Server는 데이터베이스 특성을 기반으로 쿼리 계획을 선택하기 때문입니다. 반면, 단일 데이터베이스가 데이터 특성이 크게 다른 여러 사이트를 호스팅하는 경우 SQL Server가 사용하는 쿼리 계획이 데이터베이스의 모든 콘텐츠에 대해 가장 효율적인 방법이 아닐 수도 있습니다. 예를 들어 단일 데이터베이스가 팀 사이트(중간 크기 사이트 여러 개)와 포털 사이트(많은 요청이 포함된 매우 큰 사이트 몇 개)를 호스팅하는 경우 선택하는 쿼리 계획은 두 사이트 형식 중 하나에는 효율적이지 못합니다. 따라서 팀 사이트의 콘텐츠를 전용 데이터베이스에 배치하면 SQL Server의 성능을 최적화함으로써 전체 서버 팜의 성능을 높일 수 있습니다.

관리 용이성 고려

전용 웹 응용 프로그램에서 팀 사이트를 호스팅하면 다음과 같은 방식으로 관리 용이성을 높일 수 있습니다.

  • 다음 항목을 별도로 관리할 수 있습니다.

    • 데이터베이스 설정

    • 할당량 지정 서식 파일

    • 휴지통 설정

    • 사용되지 않는 사이트에 대한 자동화된 동작

    • 인증

    • 정책

  • 팀 사이트를 다른 형식의 사이트와 별도로 관리하면 팀 사이트 확장을 효율적으로 관리할 수 있습니다.

  • 특정 서비스 수준 계약을 협상할 수 있습니다. 예를 들어 콘텐츠 데이터베이스에 대해 매주 전체 백업 및 매일 차등 백업을 저장하는 서비스 수준 계약을 제공함과 동시에, 2단계 휴지통을 사용하는 개별 콘텐츠 항목 복구를 보다 빠르게 수행할 수 있습니다.

응용 프로그램 풀 선택

기업 환경에서 팀 사이트는 공동 작업 및 격리 요구 사항이 유사한 웹 응용 프로그램과 응용 프로그램 풀을 공유할 수 있습니다. 예를 들어 팀 사이트와 내 사이트는 모두 공동 작업과 문서 및 정보 저장에 사용되며 보통 격리용으로 유사한 범위가 지정되므로(두 사이트 모두 전체 조직에 사용 가능) 응용 프로그램 풀을 공유할 수 있습니다.

일반적으로 다음 작업을 수행할 때는 전용 응용 프로그램 풀이 필요합니다.

  • 인증된 콘텐츠와 익명 콘텐츠 분리

  • 비즈니스 데이터 카탈로그 연결과 같은 외부 비즈니스 응용 프로그램에 대한 암호를 저장하고 이러한 응용 프로그램과 상호 작용하는 응용 프로그램 격리

  • 사용자가 자유롭게 사이트를 만들거나 관리하고 콘텐츠에 대해 공동으로 작업할 수 있는 응용 프로그램 격리

전용 응용 프로그램 풀을 사용해야 하는 경우에 대한 자세한 내용은 논리 아키텍처 모델: 기업 배포를 참조하십시오.

여러 조직의 콘텐츠가 단일 서버 팜에서 호스팅되는 호스팅 환경에서는 단일 조직의 모든 콘텐츠를 같은 응용 프로그램 풀에서 호스팅하는 것이 좋습니다. 이렇게 하면 응용 프로그램 풀 수가 적어 실행되는 프로세스 수도 적어지므로 확장성이 향상될 뿐 아니라, 응용 프로그램 풀 간의 프로세스가 격리됩니다. 즉, 고객 A의 응용 프로그램 풀이 중지되어도 고객 B의 사이트에는 아무런 영향이 없습니다. 물론 이러한 사항은 환경에 포함된 조직 수, 성능 계획의 권장 사항, 격리 요구 사항 등에 따라 달라집니다.

웹 응용 프로그램 일반 설정 계획

웹 응용 프로그램 일반 설정 페이지에는 데이터 증가와 환경 내의 팀 사이트에서 콘텐츠의 현재 상태를 관리할 수 있는 다양한 설정이 있습니다. 이러한 설정은 웹 응용 프로그램 내의 모든 사이트에 적용됩니다. 따라서 최소한 다음과 같은 설정을 구현하도록 계획하십시오. 각 설정에 대해서는 이 섹션 뒷부분에서 설명합니다.

  • 최대 팀 사이트 크기를 제한하는 할당량 지정 서식 파일 정의 및 적용

  • 최대 업로드 크기 설정. 사용자가 쉽게 공동 작업을 수행할 수 있도록 비즈니스 요구 사항을 기준으로 크기를 여유 있게 선택합니다.

  • 사이트 휴지통 설정 및 2단계 휴지통 사용

위에 나와 있는 설정 외에도 웹 응용 프로그램 일반 설정 페이지의 모든 기능 설정을 평가하여 기능이 조직의 팀 사이트에 적합한지를 확인하십시오. 기본적으로 다음과 같은 기능이 사용하도록 설정됩니다.

  • 사용자 이름 스마트 태그 및 온라인 상태(온라인 상태 정보가 표시됨)

  • 알림(사용자는 기본적으로 최대 500개의 알림을 만들 수 있음)

  • RSS(Really Simple Syndication) 피드

  • 블로그 API(응용 프로그램 프로그래밍 인터페이스, 블로그 작성을 위한 링크)

할당량 지정 서식 파일 설정 결정

Office SharePoint Server 2007 환경에는 팀 사이트에 대한 기본 할당량 지정 서식 파일이 없습니다. 그러나 다음과 같은 설정을 기준으로 사용하는 것이 좋습니다.

  • 사이트 크기가 450MB에 도달하면 사이트 소유자에게 자동 전자 메일이 발송됩니다.

  • 사이트 크기가 500MB에 도달하면 사용자는 문서를 더 업로드할 수 없습니다.

이러한 설정이 조직에서 제대로 작동할 수도 있지만, 사용자가 팀 사이트에 저장할 것으로 예상되는 항목의 크기 및 수를 평가하여 이러한 설정을 적절하게 조정하면 조직에서 팀 사이트를 원하는 대로 사용할 수 있습니다.

예를 들어 조직의 조사 또는 디자인 팀이 공동 작업을 통해 생성하는 많은 양의 콘텐츠를 저장 및 보관해야 하는 경우에는 사이트 제한을 5-10GB로 높이는 등 할당량 제한을 늘려 보십시오. 이러한 경우 팀 사이트에서 콘텐츠를 호스팅하면 콘텐츠가 정기적으로 백업되며 모든 사용자가 언제든지 콘텐츠를 추가할 수 있습니다. 또한 크기가 5-10GB인 사이트 모음(특히 사이트 모음 크기가 빠르게 증가하는 경우)을 자체 콘텐츠 데이터베이스에 포함할 수도 있습니다.

반면 팀 사이트가 대부분 단기 프로젝트나 팀 통신 사이트에 사용되는 경우에는 할당량 제한을 낮출 수 있습니다. 그러면 팀이 필요한 정보만 저장함으로써 단기 프로젝트를 빠르게 진행할 수 있습니다. 그러나 할당량 제한이 너무 낮으면 지원 요청과 관련된 비용이 증가하여 결국에는 할당량이 높아진다는 점을 기억해야 합니다. 이 경우에는 팀에서 일반 팀 콘텐츠나 새 프로젝트 콘텐츠를 별도의 팀 사이트에 저장하도록 해야 합니다.

조직의 특정 팀이나 그룹이 업무상 많은 양의 콘텐츠를 해당 팀 사이트에 저장해야 하는 경우에는 개별 사이트 모음의 할당량 제한을 조정할 수 있습니다. 할당량 제한을 조정하려면 사이트 모음 할당량 및 잠금 페이지에서 팀 또는 그룹에 해당하는 사이트 모음을 선택합니다. 그런 다음 현재 할당량 지정 서식 파일을 개별 할당량으로 변경하고 적절한 제한을 지정합니다.

할당량 지정 서식 파일을 계획할 때는 대부분의 조직 팀 사이트에 적합한 제한을 선택합니다. 관리 용이성을 높이려면 업무상 필요한 경우에만 사용자별로 할당량을 조정하십시오.

최대 업로드 크기 설정

기본 최대 업로드 크기는 50MB입니다. 50MB는 사용자가 성능을 저하시키지 않고 다양한 형식 및 크기의 문서를 자유롭게 업로드할 수 있는 여유 있는 제한 수치입니다. 조직의 사용자가 팀 사이트에 더 큰 파일을 저장해야 하는 경우에는 이 설정을 조정할 수 있습니다. 이 경우 연결 속도가 느린 사용자가 있으면 IIS 시간 제한 설정을 모니터링해야 합니다.

휴지통 설정 결정

휴지통을 사용하도록 설정하면 팀 사이트의 관리 용이성을 간편하게 향상시킬 수 있습니다. 사이트 소유자는 휴지통을 사용하여 중앙 관리자의 승인 없이 삭제한 항목을 가져올 수 있습니다(백업 테이프에서 복원).

다음 목록에서는 대부분의 조직에 적합한 기본 휴지통 설정에 대해 설명합니다.

  • 휴지통 상태: 사용

  • 휴지통에서 항목 삭제: 30일 후

  • 2단계 휴지통: 2단계 삭제 항목에 대한 라이브 사이트 할당량의 50% 추가

2단계 휴지통에는 사용자가 자신의 휴지통에서 삭제한 항목이 저장됩니다. 사이트 모음 관리자만이 2단계 휴지통에서 항목을 복원할 수 있습니다. 2단계 휴지통에 대해 지정하는 크기는 전체 팀 사이트 크기에 추가됩니다. 예를 들어 팀 사이트 제한이 500MB인데 2단계 휴지통 크기를 50%로 설정하면 사이트에서 사용할 수 있는 전체 용량은 750MB가 됩니다. 이 공식에 따라 데이터베이스 용량을 계획하십시오.

휴지통과 마찬가지로 2단계 휴지통에 있는 항목도 삭제된 항목의 보관 기간(기본적으로 30일)에 도달하면 자동으로 삭제됩니다. 그러나 2단계 휴지통의 경우에는 크기 제한에 도달하면 항목이 가장 오래된 것부터 순서대로 자동 삭제됩니다. 사이트 모음 관리자가 2단계 휴지통을 수동으로 비울 수도 있습니다.

휴지통 기능을 사용할 때 고려해야 하는 가장 중요한 사항은 2단계 휴지통 사용 여부와 할당할 공간의 양입니다. 사용자가 중요한 문서, 문서 라이브러리의 폴더 또는 목록의 열을 실수로 삭제하는 경우에 대비하여 2단계 휴지통에 10% 정도로 약간의 공간을 할당하는 것을 고려해 보십시오.

사이트 만들기 방법 계획

팀 사이트의 사이트 모음을 중앙에서 만들 것인지 아니면 사용자가 셀프 서비스 사이트 관리를 통해 사이트 모음을 직접 만들도록 할 것인지를 결정할 수 있습니다. 이 두 방식에는 각각 장단점이 있습니다.

팀에서 셀프 서비스 사이트 관리를 통해 사이트 모음을 만들도록 허용하면 팀이 필요할 때 관리자의 지원 없이도 쉽게 사이트를 만들 수 있습니다. 그러나 이 방식에는 다음과 같은 여러 가지 단점이 있습니다.

  • 자세한 분류를 구현할 수 없습니다.

  • 응용 프로그램을 관리하기가 어려워질 수 있습니다.

  • 사이트가 사용되지 않는 경우가 많습니다.

  • 다른 방법을 사용하면 사이트 모음을 공유할 수도 있는 프로젝트나 팀 사이에서 서식 파일 및 탐색을 공유할 수 없습니다.

참고

셀프 서비스 사이트 관리를 사용하되 이 방법으로 만든 사이트에 대해 사용할 수 있는 서식 파일을 제한하려면 %programfiles%\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\1033\XML 경로에 있는 webtempsps.XML 파일을 편집하여 셀프 서비스 사이트 관리 프로세스에서 서식 파일을 숨길 수 있습니다.

조직의 운영 방식에 따라 사이트 모음을 중앙에서 만드는 경우에는 팀 사이트를 관리 및 확장하는 방식에 대한 구조를 제공하는 자세한 분류를 구현할 수 있습니다. 뿐만 아니라 사이트 모음을 공유하는 여러 프로젝트 및 팀에서 서식 파일 및 탐색을 공유할 수 있습니다. 이 방식을 사용하는 경우 초기 사이트 모음을 만든 후에 팀이 필요에 따라 사이트 모음 내에서 사이트를 만들 수 있지만, 사용자가 사이트를 만들 때마다 IT 리소스를 사용해야 합니다.

각 방법을 사용해야 하는 경우의 예제를 보려면 논리 아키텍처 모델: 기업 배포를 참조하고, 사이트 생성을 계획하는 방법에 대한 자세한 내용은 사이트 만들기 프로세스 계획(Office SharePoint Server)을 참조하십시오.

조직에서 사용자가 직접 팀 사이트 모음을 만들도록 허용하지 않고 팀 사이트에 대해 사이트 모음을 만들도록 선택한 경우 사이트 경로 워크시트 (영문)(https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x412)를 사용하여 팀 사이트를 만드는 수준(자체 사이트 모음의 최상위 사이트 또는 여러 하위 사이트가 포함된 큰 사이트 모음 하나)을 결정합니다. 사이트 모음을 여러 개 만들지 아니면 하위 사이트가 많이 포함된 사이트 모음을 몇 개만 만들지 결정하는 방법에 대한 자세한 내용은 Windows SharePoint Services 3.0 기술 라이브러리에서 필요한 사이트 및 하위 사이트 결정(Windows SharePoint Services)을 참조하십시오. Office SharePoint Server 2007에서 사용할 수 있는 사이트 형식에 대한 자세한 내용은 사이트 및 하위 사이트 결정을 참조하십시오.

팀 사이트의 콘텐츠 데이터베이스 설정 디자인

논리 아키텍처 모델: 기업 배포에서 팀 사이트는 전용 데이터베이스(각 사이트 모음당 데이터베이스 하나)에 저장됩니다. 이 방식을 사용하면 백업, 복구 및 마이그레이션을 위해 각 사이트 모음 데이터베이스를 독립적으로 관리할 수 있습니다. 또한 프로젝트가 완료되면 해당 프로젝트와 연결된 데이터베이스를 쉽게 보관할 수 있습니다. 이 방식을 사용하는 경우 많은 데이터베이스가 만들어지지만, 각 사이트 모음에 대해 데이터베이스를 개별적으로 제어할 수 있습니다.

그러나 각 SQL Server 인스턴스당 데이터베이스 수가 많으면 SQL Server 성능에 영향을 줄 수 있습니다. 즉, 팀 사이트 모음이 300개 이상인 경우 각 사이트 모음을 전용 데이터베이스에 저장하면 SQL Server 성능이 저하될 수 있습니다. 각 데이터베이스는 응용 프로그램 풀과 SQL Server 간의 연결을 나타내기 때문입니다. 웹 서버와 데이터베이스를 추가하면 활성 연결 수가 늘어나며, 연결을 너무 많이 추가하면 SQL Server가 응답하지 않을 수 있습니다.

따라서 팀 사이트 모음의 수가 300개가 넘으면 전용 데이터베이스를 사용하는 대신 각 데이터베이스에 여러 사이트 모음을 저장해야 합니다. 데이터베이스 300개는 Microsoft IT 부서에서 사용하는 수치로, 오류 지점이 아니라 SharePoint Portal Server 2003 데이터를 기준으로 하는 예상치입니다. 즉, 데이터베이스 300개라는 숫자는 Microsoft IT 부서에서 각 서버에 안전하게 호스팅할 수 있는 사이트 모음 수라고 생각하는 수준을 나타냅니다. 실제 수치는 데이터베이스 수를 비롯한 여러 가지 매개 변수에 따라 달라질 수 있습니다. 예를 들어 전용 데이터베이스 사용 여부는 다음과 같은 요인에 따라서도 달라질 수 있습니다.

  • 각 팀의 서비스 수준 계약이 서로 다른지 여부(백업 요구 사항 등이 서로 다름)

  • 팀에 필요한 저장소 크기가 8GB를 넘는지 여부

  • 각 팀의 프로젝트 일정이 서로 다른지 여부. 단기 프로젝트를 진행하는 팀과 장기 프로젝트를 진행하는 팀이 동일한 데이터베이스를 공유할 경우 두 팀을 통합하면 사이트를 보관하기가 어려워지며 사이트를 프로덕션 환경 외부로 이동하기도 어렵습니다.

  • 데이터베이스 수준에서 수행되는 작업에 대해 팀에 필요한 자동화 및 독립성 수준이 높은지 여부

위에서 해당하는 항목이 하나라도 있으면 사이트 모음에 전용 데이터베이스를 사용하는 것을 고려해야 합니다.

각 데이터베이스에 여러 사이트 모음을 저장하는 경우에는, 할당량 지정 서식 파일의 저장 용량 제한 값과 휴지통 할당량을 기준으로 단일 데이터베이스의 최대 크기와 각 사이트 모음의 최대 크기를 결정하여 각 데이터베이스에 저장할 사이트 모음을 계산할 수 있습니다. 모든 사용자에게 500MB의 할당량을 지정한다 해도 모든 사용자가 전체 할당량을 사용하는 것은 아니므로, 결과적으로는 콘텐츠 데이터베이스가 너무 많이 만들어지게 됩니다. 데이터베이스를 계획할 때는 할당량 예상치를 고려해야 하지만, 실제 사용량 및 조정 내용도 추적해야 합니다. 이전 환경에서 SharePoint Portal Server 2003 또는 Windows SharePoint Services 2.0을 설치한 경우에는 이들 사이트 모음의 크기를 확인하여 할당량 예상치가 아닌 실제 사이트 모음 크기를 기준으로 데이터베이스를 만들 수도 있습니다.

관리되는 환경에서 데이터베이스 크기 제한은 보통 다음의 두 요인에 의해 결정됩니다.

  • 데이터베이스 백업에 필요한 시간. 특정 데이터베이스 크기를 초과하면 백업 작업의 효율성이 떨어지고 정상적인 경우보다 시간이 오래 걸리며 기타 원인으로 인해 작업이 중단될 수 있습니다. 이러한 경우에는 환경에 데이터베이스 서버를 더 추가할 수 있습니다.

  • 서비스 수준 계약에 따라 콘텐츠 복원을 위해 허용되는 서비스 윈도(시간). 예를 들어 콘텐츠 복원을 위한 서비스 윈도가 4시간이면 데이터베이스 크기는 이 시간 내에 복원할 수 있는 양으로 제한됩니다.

팀 사이트 모음에 대해 관리 가능한 최대 데이터베이스 크기를 결정하려면 다음 표에 나와 있는 값을 확인하십시오.

항목 요인 값

A

콘텐츠 복원을 위한 서비스 윈도

시간

B

선택한 복구 방법 및 도구를 사용할 수 있는 경우 서비스 윈도 내에서 복원할 수 있는 콘텐츠의 양

GB

C

데이터베이스 백업을 위한 목표 기간

시간

D

선택한 백업 방법 및 도구를 사용할 수 있는 경우 목표 기간 내에 백업할 수 있는 콘텐츠의 양

GB

콘텐츠 양에 대해 두 개의 값(B와 D)이 제공되는 경우 조직에서 관리할 수 있는 최대 데이터베이스 크기는 두 값 중 더 작은 쪽입니다.

콘텐츠 데이터베이스의 목표 크기를 결정한 후에는 각 데이터베이스에서 지원할 수 있는 사이트 모음 수를 계산할 수 있습니다. 다음 표에는 데이터베이스 크기 및 사이트 모음 크기 제한을 기준으로 하는 데이터베이스당 사이트 모음 수가 나와 있습니다. 사이트 모음 크기 제한에는 2단계 휴지통에 할당되는 공간이 포함됩니다.

데이터베이스 크기 500MB 사이트 모음 크기 제한 750MB 사이트 모음 크기 제한 1GB 사이트 모음 크기 제한 2GB 사이트 모음 크기 제한 5GB 사이트 모음 크기 제한 10GB 사이트 모음 크기 제한

25GB

50

33

25

12

5

2

50GB

100

66

50

25

10

5

100GB

200

133

100

50

20

10

200GB

400

266

200

100

40

20

500GB

800

533

500

250

100

50

1TB

1,600

1,066

1,000

500

200

100

참고

사이트 모음의 크기가 10GB보다 커지면 빠른 백업 및 복구를 설정하는 등 쉽게 관리할 수 있도록 전용 데이터베이스로 이동하는 것을 고려해 보십시오.

팀 사이트에 대해 웹 응용 프로그램을 만들 때는 데이터베이스 크기 목표 및 사이트 모음 크기 제한에 해당하는 최대 사이트 모음 수(최대 사이트 수)가 포함된 첫 번째 콘텐츠 데이터베이스에 대해 콘텐츠 데이터베이스 관리 페이지에서 설정을 수정합니다. 또한 경고를 트리거하는 사이트 수 임계값(경고 전 사이트 수)도 지정합니다. 경고 전 사이트 수에 도달하면 동일한 설정으로 새 데이터베이스를 만듭니다. 최대 사이트 모음 수에 도달하면 데이터베이스 내에 새 사이트 모음이 만들어지지 않습니다. 다른 데이터베이스를 만들지 않은 경우 사이트 만들기가 실패합니다.

사용하지 않는 사이트 자동 삭제

사용되지 않는 사이트를 자동으로 삭제하면 팀 사이트의 콘텐츠를 최신 상태로 유지할 수 있으며 팀 사이트의 전체 크기 증가도 제어할 수 있습니다. 팀 사이트를 별도의 웹 응용 프로그램에서 호스팅하는 경우에는 사용되지 않는 웹 사이트를 쿼리하기 전에 이러한 사이트의 수명을 보다 길게 설정하는 등의 작업을 통해 개인 사이트와는 다른 방식으로 관리할 수 있습니다.

기본적으로 사이트 자동 삭제 설정은 사용하도록 설정되지 않습니다. 사이트 삭제 설정을 관리하려면 응용 프로그램 관리 페이지의 SharePoint 사이트 관리 섹션에서 사이트 사용 확인 및 삭제를 클릭합니다.

이 기능을 사용하도록 설정하면 기본 설정에 다음이 포함됩니다.

  • 사이트 모음을 만들거나 사용을 확인한 후 90일이 지나면 사이트 모음 소유자에게 전자 메일 알림이 발송됩니다. 즉, 90일 동안 사이트 사용을 확인하지 않으면 사이트 소유자가 알림을 받게 됩니다.

  • 시스템에서 확인되지 않은 사이트 모음을 확인하여 매일 자정에 알림을 보냅니다.

  • 확인되지 않은 사이트 모음을 자동으로 삭제하는 옵션은 선택되지 않습니다. 이 설정을 선택하면 28회의 알림을 보낸 후에 사이트가 자동으로 삭제됩니다. 알림 수는 직접 지정할 수 있습니다.

기본 설정을 사용하는 경우 90일 동안 사용하지 않은 사이트 모음은 28회의 알림을 발송한 후에 또는 마지막으로 사이트를 확인하고 118일 후에 삭제됩니다. 조직에 적합한 설정을 지정할 수 있습니다. 이 기능은 실제 사이트 사용을 추적하는 것이 아니라 확인을 통해 작동하기 때문에 사이트 소유자가 갑자기 자리를 비워 일정 기간 동안 사이트 만료 및 삭제 시간을 설정하지 못하는 경우를 고려하여 계획을 세워야 합니다. 또한 기본 사이트 모음 관리자가 장기간 자리를 비우는 경우에는 백업 관리자가 사이트를 확인할 수 있도록 항상 사이트 모음 관리자를 여러 명 지정해야 합니다.

자동 사이트 삭제 기능을 사용하면 환경을 제어할 수 있지만, 자동으로 삭제된 사이트에 업무상 중요한 데이터가 저장되어 있는 등의 위험이 있습니다. 이러한 위험을 완화하려면 다음을 수행하는 것이 좋습니다.

  • 모든 사이트에 보조 연락처를 지정합니다. 이렇게 하면 사이트 소유자가 없거나 조직을 떠나도 사이트 사용을 확인할 수 있는 연락처가 있습니다. 보조 연락처를 지정하지 않은 상태에서 사용되지 않는 사이트를 삭제할 때까지의 날짜 수나 발송되는 알림 수를 줄이면 필요한 사이트가 실수로 삭제될 수 있습니다. 이 권장 사항은 셀프 서비스 사이트 관리를 설정하는 경우나 중앙 관리에서 사이트 모음을 만들기 위한 비즈니스 프로세스로 구현하십시오.

  • 사이트를 자동으로 삭제하기 전에 보관합니다. 사용되지 않는 사이트의 자동 삭제 기능을 구현하는 대부분의 조직에서는 모든 사이트를 자동 삭제 전에 보관하는 도구 개발에도 비용을 투자하고 있습니다. 이렇게 하면 삭제된 사이트에 업무상 중요한 정보가 들어 있는 경우 쉽게 복원할 수 있습니다. 또는 삭제된 사이트를 나중에 복원해야 하는 경우에 대비하여 콘텐츠 데이터베이스를 오랫동안 저장해 둘 수도 있습니다.

경로 또는 호스트 이름을 사용하여 팀 사이트 URL 구성

조직 및 팀 사이트를 사용하는 방법에 따라서는 경로를 사용하여 팀 사이트에 대해 URL을 구성할 수 있습니다. 예를 들어 서로 다른 부서에 연결된 팀 사이트에 대해 각각 다른 URL을 사용하려는 경우, http://회사_이름/부서_이름/sites 또는 http://회사_이름/research/sites 등의 URL을 사용할 수 있습니다. 마찬가지로 http://인트라넷_이름/teamsites를 사용하여 게시된 인트라넷 사이트에 연결할 수도 있습니다. 셀프 서비스 사이트 관리를 사용하는 경우 팀 사이트의 기본 URL은 http://서버_이름/sites지만, http://서버_이름/team에 대해 와일드카드 포함을 만들거나 팀 사이트에 사용할 접두사를 만들 수도 있습니다.

참고

기본(/sites) 이외의 다른 와일드카드 포함을 사용하려는 경우에는 재해 복구 계획에 대한 사용자 지정으로 이 와일드카드 포함을 추적해야 합니다. 이 정보는 구성 데이터베이스에 저장되므로 자동으로 복원되지 않으며, 전체 환경을 복원해야 하는 경우에는 와일드카드 포함을 다시 만들어야 합니다.

경로에 대한 자세한 내용은 다음 리소스를 참조하십시오.

조직에서 중요한 역할을 하는 팀 사이트에 대해서는 호스트 이름이 지정된 사이트를 만들 수도 있습니다. 예를 들어 인사 웹 사이트가 팀 사이트이며 게시된 인트라넷 사이트에 포함되지 않은 경우에는 해당 사이트에 대해 http://hrsite 또는 http://humanresources라는 호스트 이름이 지정된 팀 사이트를 만들 수 있습니다.

참고

대체 호스트 이름 등의 일부 기능은 호스트 이름이 지정된 사이트 모음에서 작동하지 않습니다.

사용자 지정 요소 계획

사용자 지정을 수행하면 특히 모든 솔루션 팩을 여러 번(배포 전, 업데이트를 적용해야 할 때, 환경 업데이트 시) 테스트하려는 경우 환경이 복잡해질 수 있습니다. 사용자 지정 기능, 서식 파일, 웹 파트 등의 사용에 대한 조직의 정책을 결정하고, 환경에서 이러한 요소를 사용하는 경우의 관리 용이성, 지원 가능성, 사용 가능성을 계획해야 합니다.

  • 관리 용이성   재해 복구 시나리오에서 또는 하드웨어를 이동하는 경우 등과 같이 전체 환경을 백업 및 복원해야 하는 경우에는 환경에 대해 개발된 사용자 지정 웹 파트 또는 사용자 지정 사이트 정의 등 모든 사용자 지정 요소에 대해 백업을 만들어야 하며, 복원 시 해당 요소를 환경에 다시 추가해야 합니다. 사용자 지정 요소에 대한 모든 참조가 포함된 구성 데이터베이스는 복원할 수 없기 때문에 복원된 환경에 다시 추가해야 합니다. 예를 들어 사용자 지정 사이트 정의를 다시 추가하고 사용자 지정 웹 파트를 설치해야 합니다. 새 서버로 이동하거나 서버를 복원할 때 사용자 지정 요소를 다시 추가하지 않으면 사용자 팀 사이트에서 오류가 발생하며, 필요한 코드를 추적하는 동안 사용자는 대기해야 합니다.

  • 지원 가능성   환경에 사용자 지정 요소가 있으면 문제 발생 시 해결 시간이 길어질 수 있습니다. 각각의 사용자 지정 코드 조각은 고유하고, 복잡하거나 간단할 수 있으며, 실행을 위해 메모리를 추가로 소비할 수 있습니다. 사용자 지정 코드가 사용되는 위치의 수와 사용자 지정 코드가 시스템에 주는 영향을 고려하십시오. 또한 문제 해결 시 문제의 근본 원인에서 사용자 지정 내용은 제외할 수 있는지도 고려해야 합니다. 사용자 지정 코드를 직접 만드는 경우에는 사용자 지정으로 인한 오류가 MOM(Microsoft Operations Manager) 이벤트의 오류 로그와 조직에서 문제 해결에 사용하는 다른 위치에 모두 기록되도록 디자인해야 문제를 해결할 수 있습니다.

  • 사용 가능성   솔루션, 웹 파트 및 서식 파일의 사용 가능성을 고려하십시오. 예를 들어 환경의 팀 사이트에 사용자 지정 서식 파일이 너무 많아 서식 파일 또는 웹 파트 목록이 여러 화면에 걸쳐 스크롤되는 경우(예: 서식 파일이 50개인 경우 읽거나 구분하기에 너무 많음)에는 이러한 사용자 지정 서식 파일이 모두 필요한지, 목록을 분할할 수 있는지 또는 보다 쉽게 탐색 및 추적할 수 있도록 이들 요소를 일반 기능 팩으로 롤업해야 하는지 등을 고려해야 합니다.

사용자 지정에 대해 여러 정책을 사용하는 조직도 있습니다. 예를 들어 2계층 또는 3계층 시스템에서 수준 1은 일반 사이트(표준 서식 파일만 사용), 수준 2는 일부 사용자 지정이 허용되는 사이트(다른 서비스 수준 계약 사용)를 저장하고 수준 3에서는 하드웨어를 호스팅할 수 있습니다. 그러나 팀 사이트를 소유한 팀은 해당 하드웨어에서 사용자 지정된 환경을 관리 및 실행해야 합니다. 이러한 경우에도 여러 웹 응용 프로그램에서 팀 사이트를 호스팅하며 각 웹 응용 프로그램에 대해 서로 다른 서비스 수준 계약을 적용합니다.

팀 사이트에 적용할 사용 권한 계획

팀 사이트에 적용하는 사용 권한 및 정책에 따라 다음이 결정됩니다.

  • 팀 사이트를 만들 수 있는 사람

  • 팀 사이트를 보고 내용을 추가할 수 있는 사람

  • 팀 사이트 콘텐츠에 액세스하지 못하도록 차단되는 사람

보안 그룹을 사용하여 권한을 관리하는 것이 좋습니다. 다음 표에는 사용 권한 구성을 위한 지침과 사용 권한이 구성되는 위치가 나와 있습니다.

사용 권한 지침 구성

팀 사이트 모음 만들기

기본적으로 Farm Administrators 그룹 구성원만이 팀 사이트의 사이트 모음을 만들 수 있습니다.

더 많은 사용자가 팀 사이트 모음을 만들 수 있도록 하려면 중앙 관리의 셀프 서비스 사이트 관리 기능을 사용합니다. 자세한 내용은 사이트 만들기 프로세스 계획(Office SharePoint Server)을 참조하십시오.

셀프 서비스 사이트 관리 기능을 설정하되 셀프 서비스 사이트 만들기 권한을 하나 이상의 보안 그룹에 제한하거나, 특정 보안 그룹만 셀프 서비스 사이트 만들기의 새 SharePoint 사이트 페이지에 액세스할 수 있도록 제한하여 조직의 일부 사용자에 대해서만 셀프 서비스 사이트 관리 기능을 사용하도록 설정할 수 있습니다.

중앙 관리 사이트의 응용 프로그램 관리 페이지에 있는 응용 프로그램 보안 섹션에서 셀프 서비스 사이트 관리를 클릭합니다.

셀프 서비스 사이트 관리를 설정하면 셀프 서비스 사이트 만들기 사용 권한이 있는 사용자 및 그룹은 사이트 모음을 만들 수 있습니다.

사이트 모음 내에서 하위 사이트 만들기

기본적으로 하위 사이트 만들기 권한이 있는 팀 사이트 구성원(모든 권한 사용 권한 수준에 속한 구성원)은 사이트 모음 내에 하위 사이트를 만들 수 있습니다. 사용자가 하위 사이트를 만들지 못하도록 전체적으로 제한하기보다는 사이트 소유자가 하위 사이트 만들기 권한을 관리하도록 하는 것이 좋습니다.

사이트 설정 페이지에서 Owners그룹에 속한 구성원을 추가하거나 삭제합니다.

팀 사이트 보기 및 내용 추가

직원은 팀 사이트를 만들 수는 없지만 사이트 소유자가 적용하는 사용 권한에 따라 다른 팀 사이트의 문서를 보고 해당 문서에 내용을 추가할 수 있습니다. 사용자가 이러한 유형의 공동 작업에 참여하지 못하도록 전체적으로 제한하기보다는 사이트 소유자가 사이트의 콘텐츠에 대한 사용 권한을 관리하도록 하는 것이 좋습니다.

사이트 설정 페이지에서 Visitors 그룹에 속한 구성원을 추가하거나 삭제합니다.

팀 사이트 콘텐츠 액세스 차단

웹 응용 프로그램에 대해 정책을 만들어 조직의 사용자가 모든 팀 사이트 콘텐츠에 액세스하지 못하도록 차단할 수 있습니다. 이렇게 하면 차단된 사용자는 팀 사이트에서 어떤 공동 작업도 수행할 수 없게 되므로, 이 옵션은 주의해서 사용해야 합니다. 웹 응용 프로그램에 대한 정책은 웹 응용 프로그램 내에서 구성한 다른 모든 사용 권한보다 우선합니다.

응용 프로그램 관리 페이지의 응용 프로그램 보안 섹션에서 웹 응용 프로그램 정책을 클릭합니다. 웹 응용 프로그램 정책 페이지에서 차단할 사용자를 선택하고 선택한 사용자의 사용 권한 편집을 클릭한 다음 사용자 편집 페이지의 권한 정책 수준 섹션에서 모두 거부를 선택합니다.

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

사용 가능한 문서의 전체 목록은 다운로드 가능한 Office SharePoint Server 2007 관련 콘텐츠 (영문)를 참조하십시오.