SharePoint Server 2013에 대한 용량 계획

적용 대상:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

이 문서에서는 SharePoint Server 2013 팜의 용량을 계획하는 방법을 설명합니다. 용량 계획 및 관리에 대한 이해와 이해가 좋은 경우 시스템 크기 조정에 지식을 적용할 수 있습니다. 크기 조정은 솔루션 플랫폼에 적합한 데이터 아키텍처, 논리 및 물리적 토폴로지 및 하드웨어의 선택 및 구성을 설명하는 데 사용되는 용어입니다. 가장 적절한 하드웨어 및 구성 옵션을 결정하는 방법에 영향을 주는 다양한 용량 관리 및 사용 고려 사항이 있습니다.

이 문서를 읽기 전에 SharePoint Server 2013에 대한 용량 관리 및 크기 조정 개요를 읽어야 합니다.

중요

이 문서의 일부 정보 및 값은 SharePoint 2010 제품과 관련된 테스트 결과 및 기타 정보를 기반으로 하며 SharePoint Server 2013의 최종 값을 나타내지 않을 수 있습니다.

이 문서에서는 사용자 환경에 대한 효과적인 용량 관리를 수행하기 위해 수행해야 하는 단계를 설명합니다. 각 단계에는 성공적인 실행을 위해 특정 정보가 필요하며 후속 단계에서 사용할 결과물 집합이 있습니다. 각 단계에 대해 이러한 요구 사항 및 결과물은 테이블에 설명되어 있습니다.

1단계: 모델

SharePoint Server 2013 기반 환경 모델링은 기존 솔루션을 분석하고 설정하려는 배포에 대한 예상 수요 및 대상을 예측하는 것으로 시작합니다. 먼저 사용자 기반, 데이터 요구 사항, 대기 시간 및 처리량 대상에 대한 정보를 수집하고 배포하려는 SharePoint Server 2013 기능을 문서화합니다. 이 섹션을 사용하여 수집해야 하는 데이터, 수집 방법 및 후속 단계에서 데이터를 사용하는 방법을 이해합니다.

예상 워크로드 및 데이터 세트 이해

SharePoint Server 2013 구현의 적절한 크기 조정을 위해서는 솔루션이 처리해야 하는 수요 특성을 연구하고 이해해야 합니다. 수요를 이해하려면 사용자 수와 가장 자주 사용되는 작업과 같은 워크로드 특성과 콘텐츠 크기 및 콘텐츠 배포와 같은 데이터 세트 특성을 모두 설명할 수 있어야 합니다.

이 섹션에서는 수집해야 하는 몇 가지 특정 메트릭 및 매개 변수 및 수집할 수 있는 메커니즘을 이해하는 데 도움이 될 수 있습니다.

워크로드

워크로드는 시스템이 유지해야 하는 요구, 사용자 기반 및 사용 특성을 설명합니다. 다음 표에서는 워크로드를 결정하는 데 도움이 되는 몇 가지 주요 메트릭을 제공합니다. 이 테이블을 사용하여 이러한 메트릭을 수집할 때 기록할 수 있습니다.

작업량 특성	값
평균 일일 RPS
사용량이 많은 평균 RPS
일별 총 고유 사용자 수
평균 일별 동시 사용자
최대 동시 사용자 사용 시간
일일 총 요청 수
예상 워크로드 배포
아니요. 일별 요청 수
웹 브라우저 - 검색 크롤링
웹 브라우저 - 일반 공동 작업 상호 작용
웹 브라우저 - 소셜 상호 작용
웹 브라우저 - 일반 상호 작용
웹 브라우저 - Office Web Apps
Office 클라이언트
OneNote 클라이언트
SharePoint Workspace
Outlook RSS 동기화
Outlook Social Connector
기타 상호 작용(사용자 지정 애플리케이션/웹 서비스)

• 동시 사용자 - 서버 팜에서 실행되는 작업의 동시성을 지정된 시간 프레임에서 요청을 생성하는 고유 사용자 수로 측정하는 것이 가장 일반적입니다. 주요 메트릭은 일일 평균 및 최대 부하의 동시 사용자입니다.

• RPS(초당 요청 수) - RPS는 초당 팜에서 처리되는 요청 수로 표현되는 서버 팜의 수요를 설명하는 데 일반적으로 사용되지만 요청의 유형이나 크기를 구분하지 않습니다. 모든 organization 사용자 기반은 organization 고유한 사용 특성에 따라 달라지는 속도로 시스템 부하를 생성합니다. 자세한 내용은 용어집을 참조하세요.

• 총 일일 요청 - 총 일일 요청은 시스템에서 처리해야 하는 전체 부하를 나타내는 좋은 지표입니다. 24시간 동안 인증 핸드셰이크 요청(HTTP 상태 401)을 제외한 모든 요청을 측정하는 것이 가장 일반적입니다.

• 일일 총 사용자 수 - 총 사용자는 시스템에서 처리해야 하는 전체 부하의 또 다른 주요 지표입니다. 이 측정값은 organization 총 직원 수가 아닌 24시간 동안의 실제 고유 사용자 수입니다.

  참고

  총 일일 사용자 수는 팜의 부하 증가 가능성을 나타낼 수 있습니다. 예를 들어 잠재적인 사용자 수가 100k 직원인 경우 15k 일일 사용자는 사용자 채택이 증가함에 따라 시간이 지남에 따라 부하가 크게 증가할 수 있음을 나타냅니다.

• 워크로드 배포 - 팜과 상호 작용하는 클라이언트의 애플리케이션을 기반으로 요청의 배포를 이해하면 SharePoint Server 2013으로 마이그레이션한 후 예상되는 추세 및 로드 변경을 예측하는 데 도움이 될 수 있습니다. 사용자가 Office 2013과 같은 최신 클라이언트 버전으로 전환하고 새로운 기능 사용을 시작하면 새로운 부하 패턴, RPS 및 총 요청이 증가할 것으로 예상됩니다. 각 클라이언트에 대해 하루의 시간 프레임에서 사용하는 고유 사용자 수와 클라이언트 또는 기능이 서버에서 생성하는 총 요청 수를 설명할 수 있습니다.

  예를 들어 아래 차트에는 일반적인 소셜 솔루션을 제공하는 라이브 내부 Microsoft 환경의 스냅샷 표시됩니다. 이 예제에서는 대부분의 부하가 검색 크롤러 및 일반적인 최종 사용자 웹 검색에 의해 생성되는 것을 볼 수 있습니다. Outlook 소셜 커넥터 기능(요청의 6.2%)에 의해 상당한 부하가 발생하는 것을 확인할 수도 있습니다.

  

프로덕션 워크로드 예측

팜에서 유지할 수 있어야 하는 필요한 처리량을 예측하려면 먼저 팜에서 사용할 트랜잭션의 혼합을 예측합니다. 시스템에서 제공하는 가장 자주 사용되는 트랜잭션을 분석하고, 얼마나 자주 사용되는지, 얼마나 많은 사용자가 사용되는지 이해하는 데 집중합니다. 이러한 이해는 나중에 팜이 사전 프로덕션 테스트에서 이러한 부하를 유지할 수 있는지 여부를 확인하는 데 도움이 됩니다.

다음 다이어그램에서는 워크로드와 시스템 부하의 관계를 설명합니다.

예상 워크로드를 예측하려면 다음 정보를 수집합니다.

• 사용자 상호 작용을 식별합니다. 예시:

  • 웹 페이지 찾아보기
  • 파일 다운로드 및 업로드.
  • 브라우저에서 Office 웹 애플리케이션 보기 및 편집
  • 공동 작성자 상호 작용.
  • SharePoint 작업 영역 사이트 동기화.
  • Outlook 소셜 Connections.
  • RSS 동기화(Outlook 또는 다른 뷰어).
  • PowerPoint 브로드캐스트.
  • OneNote 공유 전자 필기장.
  • Excel Service 공유 통합 문서.
  • Access Service 공유 애플리케이션

  자세한 내용은 서비스 및 기능을 참조하세요. 배포에 고유할 수 있는 상호 작용을 식별하는 데 집중합니다. 이러한 부하의 예상된 영향을 인식합니다. 예를 들어 InfoPath Forms, Excel 서비스 계산 및 유사한 전용 솔루션을 크게 사용합니다.

• 검색 증분 크롤링, 일일 백업, 프로필 동기화 타이머 작업, 웹 분석 처리, 로깅 타이머 작업 등과 같은 시스템 작업을 식별합니다.

• 다음 항목을 예측합니다.

  • 각 기능을 활용할 것으로 예상되는 일일 총 사용자 수입니다.
  • 예상 동시 사용자 및 초당 상위 수준 요청을 파생합니다.

  몇 가지 가정을 할 것입니다. 예시:

  • 동시성을 제공합니다.
  • 기능 간에 다른 동시 사용자당 RPS 요소

  이 섹션의 앞부분에 있는 워크로드 테이블을 예상하는 데 사용합니다. 평균 처리량보다는 피크 시간에 집중하는 것이 중요합니다. 최대 활동을 계획하면 SharePoint Server 2013 기반 솔루션의 크기를 적절하게 지정할 수 있습니다.

기존 Office SharePoint Server 2007 솔루션이 있는 경우 IIS 로그 파일을 마킹하거나 기존 솔루션의 예상 동작 중 일부를 더 잘 이해해야 하는 다른 웹 모니터링 도구를 찾을 수 있습니다. 그렇지 않은 경우 자세한 내용은 아래 섹션의 지침을 참조하세요. 기존 솔루션에서 마이그레이션하지 않는 경우 대략적인 예상을 사용하여 테이블을 작성해야 합니다. 이후 단계에서는 가정의 유효성을 검사하고 시스템을 조정해야 합니다.

SharePoint Server 2013 IIS 로그 분석

기존 SharePoint Server 2013 배포에 대한 주요 메트릭을 검색하려면 ULS 및 IIS 로그에서 데이터를 추출해야 합니다. 예시:

• 활성 상태인 사용자 수입니다.
• 시스템을 얼마나 많이 사용하고 있는지.
• 어떤 종류의 요청이 들어오는지.
• 요청이 시작되는 클라이언트의 종류입니다.

이 데이터를 찾는 가장 쉬운 방법 중 하나는 Microsoft에서 무료로 다운로드할 수 있는 강력한 도구인 Log Parser를 사용하는 것입니다. Log Parser는 모든 IIS 형식을 포함하여 많은 텍스트 및 이진 형식을 읽고 쓸 수 있습니다.

(https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07)에서 로그 파서 2.2를 다운로드할 수 있습니다.

데이터 집합

데이터 세트는 시스템에 저장된 콘텐츠의 볼륨과 데이터 저장소에 배포할 수 있는 방법을 설명합니다. 다음 표에서는 데이터 세트를 결정하는 데 도움이 되는 몇 가지 주요 메트릭을 제공합니다. 이 테이블을 사용하여 이러한 메트릭을 수집할 때 기록할 수 있습니다.

개체	값
DB 크기(GB)
콘텐츠 DB 수
사이트 모음 수
웹앱 수
사이트 수
검색 인덱스 크기(항목 수)
문서 수
목록 수
사이트 평균 크기
가장 큰 사이트 크기
사용자 프로필 수

• 콘텐츠 크기 - SharePoint Server 2013 시스템에 저장할 것으로 예상되는 콘텐츠의 크기를 이해하는 것은 시스템 스토리지를 계획하고 설계하는 데 중요하며, 이 콘텐츠를 크롤링하고 인덱싱할 Search 솔루션의 크기를 적절하게 조정하는 데도 중요합니다. 콘텐츠 크기는 총 디스크 공간에 설명되어 있습니다. 기존 배포에서 콘텐츠를 마이그레이션하는 경우 이동할 총 콘텐츠 크기를 간단하게 식별할 수 있습니다. 계획하는 동안 시간이 지남에 따라 성장의 여지를 두어야 합니다.

• 총 문서 수 - 데이터 모음 크기를 제외한 전체 항목 수를 추적하는 것이 중요합니다. 100GB의 데이터가 각각 2GB의 50개 파일과 각각 1KB의 100,000개 파일로 구성된 경우 시스템은 다르게 반응합니다. 대규모 배포에서는 단일 항목, 문서 또는 문서 영역에 대한 스트레스가 적을수록 성능이 향상됩니다. 여러 사이트 및 사이트 모음에서 여러 개의 작은 파일과 같이 널리 분산된 콘텐츠는 큰 파일이 있는 단일 큰 문서 라이브러리보다 더 쉽게 사용할 수 있습니다.

• 최대 사이트 모음 크기 - SharePoint Server 2013에 저장할 콘텐츠의 가장 큰 단위를 식별하는 것이 중요합니다. 일반적으로 해당 콘텐츠 단위를 분할하지 못하게 하는 것은 조직의 필요성입니다. 모든 사이트 모음의 평균 크기와 예상 총 사이트 모음 수는 선호하는 데이터 아키텍처를 식별하는 데 도움이 되는 다른 지표입니다.

• 서비스 애플리케이션 데이터 특성 - 콘텐츠 저장소에 대한 스토리지 요구 사항을 분석하는 것 외에도 다음을 포함한 다른 SharePoint Server 2013 저장소의 크기를 분석하고 예측해야 합니다.

• 검색 인덱스의 총 크기

• 프로필 저장소의 사용자 수에 따라 프로필 데이터베이스의 총 크기

• 예상되는 태그, 동료 및 활동 수에 따른 소셜 데이터베이스 총 크기

• 메타데이터 저장소 크기

• 사용 데이터베이스의 크기

• Web Analytics 데이터 베이스의 크기

팜 성능 및 안정성 목표 설정

1단계: 모델의 결과물 중 하나는 organization 요구에 가장 적합한 성능 및 안정성 목표를 잘 이해하는 것입니다. 올바르게 디자인된 SharePoint Server 2013 솔루션은 서버 응답이 1초 미만인 "4개의 9개"(99.99%)의 가동 시간을 달성할 수 있어야 합니다.

팜의 성능 및 안정성을 설명하는 데 사용되는 지표에는 다음이 포함될 수 있습니다.

• 서버 가용성: 시스템의 전체 가동 시간의 백분율로 설명합니다. 예기치 않은 가동 중지 시간을 추적하고 전체 가용성을 설정한 조직 대상과 비교해야 합니다. 대상은 일반적으로 9개(즉, 99%, 99.9%, 99.99%)로 설명됩니다.

• 서버 응답성: 팜이 요청을 수행하는 데 걸리는 시간은 팜의 상태를 추적하는 좋은 지표입니다. 이 표시기 이름은 서버 쪽 대기 시간입니다. Tt는 제공되는 일일 요청의 평균 또는 중앙값(50번째 백분위수) 대기 시간을 사용하는 것이 일반적입니다. 대상은 일반적으로 초 또는 초의 분수로 설명됩니다. 대상이 2초 이내에 페이지를 제공하는 경우 서버 쪽 목표는 1초 미만이어야 합니다. 이렇게 성능이 향상되어 페이지가 클라이언트에 도달하고 브라우저에서 렌더링할 수 있습니다. 또한 서버 응답 시간이 길어지면 일반적으로 비정상 팜을 나타냅니다. 대부분의 요청에 대해 서버에서 1초 이상을 소비하는 경우 RPS는 거의 유지하지 않습니다.

• 서버 급증: 추적할 가치가 있는 또 다른 좋은 서버 쪽 대기 시간 표시기는 모든 요청 중 가장 느린 5%의 동작입니다. 느린 요청은 일반적으로 더 높은 부하가 있거나 더 일반적으로 시스템에 충돌하는 요청이며, 사용자가 시스템과 상호 작용하는 동안 발생하는 덜 빈번한 작업의 영향을 받는 요청입니다. 정상 시스템은 가장 느린 요청도 제어하는 시스템입니다. 대상은 서버 응답성과 비슷하지만 서버 급증에 대한 하위 초 응답을 달성하려면 부하 급증을 처리하기 위해 수많은 예비 리소스로 시스템을 빌드해야 합니다.

• 시스템 리소스 사용률: 시스템의 상태를 추적하는 데 사용되는 다른 일반적인 지표는 팜 토폴로지에서 각 서버의 상태를 나타내는 시스템 카운터의 컬렉션입니다. 추적하기 위해 가장 자주 사용되는 지표는 % CPU 사용률 및 사용 가능한 메모리입니다. 그러나 비헤알티 시스템을 식별하는 데 도움이 되는 몇 가지 카운터가 더 있습니다. 자세한 내용은 5단계: 모니터링 및 유지 관리에서 찾을 수 있습니다.

2단계: 디자인

제공해야 하는 솔루션에 대한 몇 가지 사실이나 추정치 수집을 완료했으므로 예상 수요를 유지할 수 있을 것으로 예상하는 제안된 아키텍처를 설계하는 다음 단계를 시작할 준비가 되었습니다.

이 단계가 끝나면 물리적 토폴로지를 위한 디자인과 논리적 토폴로지의 레이아웃이 있어야 하므로 필요한 구매 주문을 진행할 수 있어야 합니다.

특정 부하를 처리하기 위해 하드웨어 사양 및 레이아웃이 긴밀하게 관련된 컴퓨터 수에는 배포하도록 선택할 수 있는 몇 가지 솔루션이 있습니다. 강력한 컴퓨터의 작은 집합(스케일 업) 또는 더 큰 작은 컴퓨터 집합(스케일 아웃)을 사용하는 것이 일반적입니다. 각 솔루션은 용량, 중복성, 전력, 비용, 공간 및 기타 고려 사항과 관련하여 장점과 단점이 있습니다.

아키텍처 및 토폴로지를 결정하여 이 단계를 시작하는 것이 좋습니다. 각 팜에서 다른 팜과 다양한 서비스를 배치하는 방법을 정의한 다음 디자인에서 각 개별 서버에 대한 하드웨어 사양을 선택합니다. 배포해야 하는 하드웨어 사양(많은 조직이 특정 회사 표준으로 제한됨)을 식별한 다음 아키텍처 및 토폴로지를 정의하여 이 프로세스를 실행할 수도 있습니다.

다음 표를 사용하여 디자인 매개 변수를 기록합니다. 포함된 데이터는 샘플 데이터이며 팜 크기를 조정하는 데 사용하지 않습니다. 이 테이블은 사용자 고유의 데이터에 이 테이블을 사용하는 방법을 보여 줍니다.

역할	형식(표준 또는 가상)	컴퓨터 수	Procs	RAM	IOPS 필요	디스크 크기 OS+로그	데이터 드라이브
웹 서버	사실상의	4	4개 코어	8	해당 없음	400GB	해당 없음
콘텐츠 데이터베이스 서버	표준	클러스터 1대	4 쿼드 코어 2.33(GHz)	48	2k	400GB	300GB 디스크 20개 @ 15K RPM
응용 프로그램 서버	사실상의	4	4개 코어	16	해당 없음	400GB	해당 없음
크롤링 대상 웹 서버 검색	사실상의	1	4개 코어	8	해당 없음	400GB	해당 없음
쿼리 서버 검색	표준	2	쿼드 코어 2.33(GHz) 2개	32	해당 없음	400GB	500GB
크롤러 서버 검색	표준	2	쿼드 코어 2.33(GHz) 2개	16	400	400GB	해당 없음
크롤링 데이터베이스 서버 검색	표준	클러스터 1대	4 쿼드 코어 2.33(GHz)	48	4k(읽기용으로 조정됨)	100GB	150GB @ 15K RPM의 16개 디스크
Search 속성 저장소 데이터베이스 + 관리 데이터베이스 서버	표준	클러스터 1대	4 쿼드 코어 2.33(GHz)	48	2k(쓰기에 맞게 조정됨)	100GB	150GB @ 15K RPM의 16개 디스크

시작점 아키텍처 확인

이 섹션에서는 시작점 아키텍처를 선택하는 방법을 설명합니다.

SharePoint Server 2013을 배포할 때 다양한 토폴로지 중에서 선택하여 솔루션을 구현할 수 있습니다. 클러스터형 또는 미러된 데이터베이스 서버와 다양한 서비스에 대해 신중한 애플리케이션 서버를 사용하여 단일 서버를 배포하거나 SharePoint Server 2013 팜에 여러 서버를 스케일 아웃할 수 있습니다. 나중에 용량, 가용성 및 중복성 요구 사항에 따라 각 역할의 요구 사항에 따라 하드웨어 구성을 선택합니다.

먼저 다양한 참조 아키텍처를 검토하고 팜 구조를 파악하거나, 솔루션을 여러 팜 간에 분할할지 또는 검색과 같은 일부 서비스를 전용 팜에서 페더레이션해야 하는지 결정합니다. 자세한 내용은 참조 아키텍처를 참조하세요.

SharePoint Server 2010 기술 사례 연구

SharePoint Server 2013에 대한 용량 관리 지침에는 기존 SharePoint Server 2013 기반 프로덕션 환경에 대한 자세한 설명을 제공하는 기존 프로덕션 환경에 대한 많은 기술 사례 연구가 포함되어 있습니다. SharePoint Server 2013과 관련된 기술 사례 연구가 제공되면 게시됩니다. 기존 SharePoint Server 2010 사례 연구는 특정 목적을 위해 SharePoint Server 2013 기반 환경을 디자인하는 방법에 대한 참조로 사용될 수 있습니다.

SharePoint Server 2013 솔루션의 아키텍처를 디자인하는 동안 이러한 사례 연구를 참조로 사용할 수 있습니다. 특히 설계 중인 솔루션의 요구 및 대상과 유사한 배포 관련 주요 차별화 요소에 대한 설명을 찾을 수 있습니다.

이러한 문서에서는 문서화된 각 사례 연구에 대해 다음 정보를 설명합니다.

• 하드웨어, 팜 토폴로지 및 구성과 같은 사양

• 사용자 기반 및 사용 특성을 포함한 워크로드;

• 콘텐츠 크기, 콘텐츠 특성 및 콘텐츠 배포를 포함한 데이터 세트

• 팜의 안정성 및 성능 특성을 설명하는 기록된 지표 집합을 포함한 상태 및 성능

자세한 내용은 성능 및 용량 기술 사례 연구(SharePoint Server 2010) 페이지에서 관련 문서를 다운로드합니다.

하드웨어 선택

팜의 머신에 적합한 사양을 선택하는 것은 배포의 적절한 안정성과 성능을 보장하는 중요한 단계입니다. 한 가지 주요 개념은 최대 부하 및 최대 시간을 계획해야 한다는 것입니다. 즉, 팜이 평균 부하 조건에서 작동하는 경우 대기 시간 및 처리량 목표에 도달하면서 예상되는 가장 큰 수요를 처리할 수 있는 충분한 리소스가 있어야 합니다.

서버의 핵심 용량 및 성능 하드웨어 기능은 시스템의 처리 능력, 디스크 성능, 네트워크 용량 및 메모리 기능의 네 가지 기본 범주를 반영합니다.

고려해야 할 또 다른 사항은 가상화된 머신을 사용하는 것입니다. 가상 머신을 사용하여 SharePoint Server 2013 팜을 배포할 수 있습니다. 가상화는 성능 이점을 추가하는 것으로 발견되지 않았지만 관리 효율성 이점을 제공합니다. SQL Server 기반 컴퓨터를 가상화하는 것은 권장되지 않지만 웹 서버 및 애플리케이션 서버 계층을 가상화하는 데는 특정 이점이 있을 수 있습니다. 자세한 내용은 가상화 계획 (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14))을 참조하세요.

하드웨어 요구 사항에 대한 자세한 내용은 SharePoint Server 2016의 하드웨어 및 소프트웨어 요구 사항을 참조하세요.

하드웨어 선택 지침

프로세서 선택

SharePoint Server 2013은 64비트 프로세서에만 사용할 수 있습니다. 일반적으로 더 많은 프로세서를 사용하면 더 많은 수요를 처리할 수 있습니다.

SharePoint Server 2013에서는 코어를 더 추가하면 개별 웹 서버가 확장됩니다. 서버의 코어가 많을수록 더 많은 부하를 유지할 수 있으며, 다른 모든 코어는 동일합니다. 대규모 SharePoint Server 2013 배포에서는 여러 개의 4코어 웹 서버(가상화 가능) 또는 더 강력한(8-/16-/24코어) 웹 서버를 할당하는 것이 좋습니다.

애플리케이션 서버의 프로세서 용량 요구 사항은 서버의 역할 및 실행 중인 서비스에 따라 다릅니다. 일부 SharePoint Server 2013 기능은 다른 기능보다 더 많은 처리 능력을 요구합니다. 예를 들어 SharePoint Search Service는 애플리케이션 서버의 처리 성능에 크게 의존합니다.

SQL Server 대한 프로세서 용량 요구 사항은 SQL Server 기반 컴퓨터가 호스팅하는 서비스 데이터베이스에 따라 달라집니다.

메모리 선택

서버에는 서버 함수 및 역할에 따라 다양한 양의 메모리가 필요합니다. 예를 들어 검색 크롤링 구성 요소를 실행하는 서버는 문서를 처리하기 위해 메모리로 읽기 때문에 많은 양의 메모리가 있는 경우 데이터를 더 빠르게 처리합니다. SharePoint Server 2013의 많은 캐싱 기능을 활용하는 웹 서버에도 더 많은 메모리가 필요할 수 있습니다.

일반적으로 웹 서버 메모리 요구 사항은 팜에서 사용하도록 설정된 애플리케이션 풀 수와 처리 중인 동시 요청 수에 따라 크게 달라집니다. 대부분의 프로덕션 SharePoint Server 2013 배포에서는 각 웹 서버에 최소 8GB RAM을 할당하는 것이 좋습니다. 격리를 위해 여러 애플리케이션 풀이 설정된 더 큰 트래픽 또는 배포가 있는 서버에는 16GB가 권장됩니다.

애플리케이션 서버의 메모리 요구 사항도 다릅니다. 일부 SharePoint Server 2013 기능은 애플리케이션 계층에서 다른 기능보다 메모리 요구 사항이 더 큽니다. 대부분의 프로덕션 SharePoint Server 2013 배포에서는 각 애플리케이션 서버에 8GB 이상의 RAM을 할당하는 것이 좋습니다. 16GB, 32GB 및 64GB 애플리케이션 서버는 동일한 서버에서 많은 애플리케이션 서비스를 사용하도록 설정하거나 Excel 계산 서비스 및 SharePoint Server 2013 Search Service와 같은 메모리에 크게 의존하는 서비스를 사용하는 경우에 일반적입니다.

데이터베이스 서버의 메모리 요구 사항은 데이터베이스 크기에 따라 크게 달라집니다. SQL Server 기반 컴퓨터의 메모리 선택에 대한 자세한 내용은 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server)을 참조하세요.

네트워크 선택

클라이언트가 네트워크를 통해 빠르게 데이터에 액세스할 수 있는 경우 사용자에게 제공되는 이점 외에도 분산 팜은 서버 간 통신에 빠르게 액세스할 수 있어야 합니다. 여러 서버에 서비스를 배포하거나 일부 서비스를 다른 팜에 페더레이션할 때 특히 그렇습니다. 웹 서버 계층, 애플리케이션 서버 계층 및 데이터베이스 서버 계층에 걸쳐 팜에 상당한 트래픽이 있으며, 네트워크는 대용량 파일 또는 높은 부하 처리와 같은 특정 조건에서 쉽게 병목 상태가 될 수 있습니다.

웹 서버와 애플리케이션 서버는 NIC(네트워크 인터페이스 카드)를 두 개 이상 사용하도록 구성해야 합니다. 한 NIC는 최종 사용자 트래픽을 처리하고 다른 하나는 서버 간 통신을 처리하도록 구성해야 합니다. 서버 간의 네트워크 대기 시간은 성능에 큰 영향을 미칠 수 있습니다. 따라서 웹 서버와 콘텐츠 데이터베이스를 호스트하는 SQL Server 기반 컴퓨터 간에 1밀리초 미만의 네트워크 대기 시간을 유지하는 것이 중요합니다. 각 서비스 애플리케이션 데이터베이스를 호스트하는 SQL Server 기반 컴퓨터도 사용 중인 애플리케이션 서버와 최대한 가까워야 합니다. 팜 서버 간의 네트워크에는 1Gbps 이상의 대역폭이 있어야 합니다.

디스크 및 스토리지 선택

디스크 관리는 단순히 데이터에 충분한 공간을 제공하는 함수가 아닙니다. 진행 중인 수요와 성장을 평가하고 스토리지 아키텍처가 시스템 속도를 늦추지 않는지 확인해야 합니다. 향후 성장을 위한 공간을 확보하기 위해 항상 각 디스크에 최소 30%의 추가 용량이 최고 데이터 요구 사항 추정치보다 높은지 확인해야 합니다. 또한 대부분의 프로덕션 환경에서 디스크 속도(IOps)는 서버의 스토리지 요구를 충족하기에 충분한 처리량을 제공하는 데 매우 중요합니다. 배포 시 주요 데이터베이스에 필요한 트래픽 양(IOps)을 예측하고 해당 트래픽을 충족하기에 충분한 디스크를 할당해야 합니다.

데이터베이스 서버용 디스크를 선택하는 방법에 대한 자세한 내용은 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server)을 참조하세요.

웹 및 애플리케이션 서버에는 스토리지 요구 사항도 있습니다. 대부분의 프로덕션 환경에서는 OS 및 임시에 대해 최소 200GB의 디스크 공간과 로그에 대해 150GB의 디스크 공간을 할당하는 것이 좋습니다.

3단계: 파일럿, 테스트 및 최적화

테스트 및 최적화 단계는 효과적인 용량 관리의 중요한 구성 요소입니다. 새 아키텍처를 프로덕션에 배포하기 전에 테스트해야 하며, 디자인하는 아키텍처가 성능 및 용량 목표를 달성할 수 있도록 다음 모니터링 모범 사례와 함께 수용 테스트를 수행해야 합니다. 이를 통해 잠재적인 병목 현상이 라이브 배포의 사용자에게 영향을 미치기 전에 식별하고 최적화할 수 있습니다. Office SharePoint Server 2007 환경에서 업그레이드하고 아키텍처를 변경하거나 새 SharePoint Server 2013 기능의 사용자 부하를 예측하는 경우 새 SharePoint Server 2013 기반 환경이 성능 및 용량 목표를 충족하는지 확인하는 것이 중요합니다.

환경을 테스트한 후에는 테스트 결과를 분석하여 1단계: 모델에서 설정한 성능 및 용량 목표를 달성하기 위해 변경해야 하는 사항을 결정할 수 있습니다.

다음은 사전 프로덕션에 대한 하위 단계입니다.

• 2단계: 디자인에서 디자인한 초기 아키텍처를 모방한 테스트 환경을 만듭니다.

• 1단계: 모델링에서 식별한 데이터 집합의 전부 또는 일부로 저장소를 채웁니다.

• 1단계: 모델링에서 식별한 작업량을 나타내는 가상 부하를 사용하여 시스템에 부하를 발생시킵니다.

• 테스트를 실행하고 결과를 분석하고 아키텍처를 최적화합니다.

• 최적화된 아키텍처를 데이터 센터에 배포하고 일부 사용자를 대상으로 하는 파일럿 환경을 배포합니다.

• 파일럿 결과를 분석하고, 잠재적인 병목 상태를 식별하고, 아키텍처를 최적화합니다. 필요한 경우 다시 테스트합니다.

• 프로덕션 환경에 배포합니다.

테스트

테스트는 워크로드 및 사용 특성을 지원하는 시스템 디자인 기능을 설정하는 데 중요한 요소입니다. SharePoint Server 2013 배포를 테스트하는 방법에 대한 자세한 내용은 SharePoint Server 2013 성능 테스트를 참조하세요.

• 테스트 계획 만들기

• 테스트 환경 만들기

• 테스트 및 도구 만들기

파일럿 환경 배포

SharePoint Server 2013을 프로덕션 환경에 배포하기 전에 먼저 파일럿 환경을 배포하고 팜을 철저히 테스트하여 예상 최대 부하에 대한 용량 및 성능 목표를 충족할 수 있는지 확인하는 것이 중요합니다. 파일럿 환경은 특히 대규모 배포에 대해 가상 부하를 테스트한 다음, 소규모 라이브 사용자 및 라이브 콘텐츠 집합으로 스트레스를 받는 것이 좋습니다. 소규모 라이브 사용자를 사용하여 파일럿 환경을 분석하는 이점은 프로덕션으로 완전히 전환하기 전에 사용 특성 및 콘텐츠 증가에 대한 몇 가지 가정의 유효성을 검사할 수 있는 기회입니다.

최적화

팜 하드웨어 크기를 조정하거나 토폴로지를 변경하여 용량 및 성능 목표를 충족할 수 없는 경우 솔루션 수정을 고려해야 할 수 있습니다. 예를 들어 협업, 검색 및 소셜을 위한 단일 팜에 대한 초기 요구 사항이 있는 경우 전용 서비스 팜 검색과 같은 일부 서비스를 페더레이션하거나 더 많은 팜에서 워크로드를 분할해야 할 수 있습니다. 한 가지 대안은 소셜용 전용 팜을 배포하고 다른 하나는 팀 협업을 위해 배포하는 것입니다.

4단계: 배포

최종 테스트를 실행하고 아키텍처가 1단계: 모델에서 설정한 성능 및 용량 목표를 달성할 수 있는지 확인한 후에는 SharePoint Server 2013 기반 환경을 프로덕션에 배포할 수 있습니다.

적절한 출시 전략은 환경 및 상황에 따라 달라집니다. SharePoint Server 2013 배포는 일반적으로 이 문서의 scope 외부에 있지만 용량 계획 연습에서 나올 수 있는 특정 제안된 활동이 있습니다. 다음은 몇 가지 예입니다.

• 새 SharePoint Server 2013 팜 배포: 용량 계획 연습에는 SharePoint Server 2016의 디자인 및 배포에 대한 안내 및 확인 계획이 있어야 합니다. 이 경우 출시는 SharePoint Server 2013의 첫 번째 광범위한 배포가 됩니다. 용량 계획 연습 중에 사용된 서버와 서비스를 프로덕션으로 이동하거나 다시 빌드해야 합니다. 이는 기존 팜에 필요한 업그레이드 또는 수정이 없기 때문에 가장 간단한 시나리오입니다.

• Office SharePoint Server 2007 팜을 SharePoint Server 2013으로 업그레이드: 용량 계획 연습에서는 SharePoint Server 2013 팜의 증가된 수요 및 사용량을 충족하기 위해 기존 요구를 충족하고 스케일 업할 수 있는 팜에 대한 디자인의 유효성을 검사해야 합니다. 용량 계획 연습의 일부에는 업그레이드 프로세스에 걸리는 시간, 사용자 지정 코드를 수정하거나 교체해야 하는지 여부, 타사 도구를 업데이트해야 하는지 여부 등을 확인하기 위한 테스트 마이그레이션이 포함되어 있어야 합니다. 용량 계획이 끝나면 유효성이 검사된 디자인과 업그레이드하는 데 걸리는 시간, 업그레이드 프로세스를 통해 작업하는 가장 좋은 방법(예: 현재 위치 업그레이드 또는 콘텐츠 데이터베이스를 새 팜으로 마이그레이션)에 대한 계획을 이해해야 합니다. 현재 위치 업그레이드를 수행하는 경우 용량 계획 중에 추가 또는 업그레이드된 하드웨어가 필요하고 가동 중지 시간에 대한 고려 사항이 있을 수 있습니다. 계획 연습의 출력 중 일부는 필요한 하드웨어 변경 내용 목록과 먼저 팜에 하드웨어 변경 내용을 배포하는 자세한 계획이어야 합니다. 용량 계획 중에 유효성을 검사한 하드웨어 플랫폼이 준비되면 SharePoint Server 2013으로 업그레이드하는 프로세스를 진행할 수 있습니다.

• 기존 SharePoint Server 2013 팜의 성능 향상: 용량 계획 연습을 통해 현재 구현에서 병목 상태를 식별하고, 이러한 병목 상태를 줄이거나 제거하는 방법을 계획하고, SharePoint Server 2013 서비스에 대한 비즈니스 요구 사항을 충족하는 향상된 구현의 유효성을 검사할 수 있어야 합니다. 기존 하드웨어에서 서비스를 다시 할당하거나, 기존 하드웨어를 업그레이드하거나, 하드웨어를 더 추가하고, 더 많은 서비스를 추가하는 등 성능 문제를 해결할 수 있는 다양한 방법이 있습니다. 용량 계획 연습 중에는 다양한 방법을 테스트하고 유효성을 검사한 다음, 해당 테스트 결과에 따라 설계된 배포 계획을 수행해야 합니다.

5단계: 모니터링 및 유지 관리

시스템 성능을 유지하려면 서버를 모니터링하여 잠재적인 병목 상태를 식별해야 합니다. 효과적으로 모니터링하려면 먼저 팜의 특정 부분에 주의를 기울여야 할지를 알려주는 핵심 지표를 이해하고 이러한 지표를 해석하는 방식을 알아야 합니다. 팜이 정의한 목표를 벗어나서 작동되는 경우에는 하드웨어 리소스를 추가 또는 제거하거나, 토폴로지를 변경하거나, 데이터가 저장되는 방식을 변경하여 팜을 조정할 수 있습니다.

초기 단계에서 환경을 모니터링하도록 변경할 수 있는 설정 목록은 SharePoint Server 2013 모니터링 및 유지 관리를 참조하세요. 그러면 변경이 필요한지 여부를 확인하는 데 도움이 됩니다. 모니터링 기능을 늘리면 사용 데이터베이스에 필요한 디스크 공간의 양에 영향을 줍니다. 환경이 안정되고 이 자세한 모니터링이 더 이상 필요하지 않으면 아래 설정을 기본 설정으로 되돌릴 수 있습니다.

SharePoint Server 2013 Central 관리 인터페이스에 기본 제공되는 상태 모니터링 도구를 사용한 상태 모니터링 및 문제 해결에 대한 자세한 내용은 다음을 참조하세요.

SharePoint Server 2016의 모니터링 및 보고

문제 해결

참고 항목

개념

SharePoint Server 2013의 성능 테스트

SharePoint Server 2013 모니터링 및 유지 관리

SharePoint Server 2016의 소프트웨어 경계 및 제한 사항

성능 및 용량 테스트 결과 및 권장 사항(SharePoint Server 2013)

기타 리소스

Capacity management and sizing overview for SharePoint Server 2013

성능 및 용량 기술 사례 연구(SharePoint Server 2010)