SharePoint Server 2010의 용량 관리

아티클
03/03/2017

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 문서에서는 Microsoft SharePoint Server 2010 팜의 용량을 계획하는 방법에 대해 설명합니다. 용량 계획 및 관리에 대해 충분히 이해하고 있으면 시스템 크기 조정 시 관련 지식을 적용할 수 있습니다. 크기 조정이란 솔루션 플랫폼에 적합한 데이터 아키텍처, 논리 및 물리적 토폴로지, 하드웨어를 선택하고 구성하는 작업을 의미합니다. 최적의 하드웨어 및 구성 옵션을 결정하는 방법에 영향을 주는 용량 관리 및 사용 고려 사항은 다양합니다.

이 문서를 읽기 전에 SharePoint Server 2010의 용량 관리 및 크기 조정 개요를 살펴보아야 합니다.

이 문서에서는 사용자 환경의 용량 관리 업무를 효율적으로 처리하기 위해 수행해야 하는 단계에 대해 설명합니다. 각 단계를 성공적으로 수행하려면 단계별로 특정 정보가 요청됩니다. 또한 각 단계를 수행하면 결과물이 발생하는데 이 결과물은 이후 단계에서 사용됩니다. 이러한 각 단계별 요구 사항과 결과물은 표로 요약되어 있습니다.

이 문서의 내용:

1단계: 모델링
2단계: 디자인
3단계: 파일럿, 테스트 및 최적화
4단계: 배포
5단계: 모니터링 및 유지 관리

1단계: 모델링

SharePoint Server 2010 기반 환경의 모델링을 구축하려면 먼저 기존 솔루션을 분석하고 설정할 배포의 예상 수요 및 목표를 예측해야 합니다. 이를 위해 먼저 사용자층, 데이터 요구 사항, 대기 시간 및 처리량 목표에 대한 정보를 수집하고 배포할 SharePoint Server 기능을 문서화합니다. 이 섹션을 활용하여 수집할 데이터, 데이터 수집 방법 및 이후 단계에서 이러한 데이터를 활용하는 방법을 파악하십시오.

예상 작업량 및 데이터 집합 파악

SharePoint Server 2010 구현의 크기를 올바르게 조정하려면 솔루션을 통해 처리할 예상 수요 특성을 파악하여 이해해야 합니다. 수요를 파악하려면 사용자 수 및 가장 많이 사용되는 작업 같은 작업량 특성과 콘텐츠 크기 및 콘텐츠 분포 같은 데이터 집합 특성을 모두 설명할 수 있어야 합니다.

이 섹션을 살펴보면 수집해야 하는 일부 특정 메트릭 및 매개 변수와 이러한 요소를 수집하는 데 사용되는 메커니즘을 손쉽게 이해할 수 있습니다.

작업량

작업량은 시스템에서 유지해야 하는 수요, 사용자층 및 사용 현황 특성을 설명합니다. 다음 표에는 작업량을 결정하는 데 도움이 되는 몇 가지 주요 메트릭이 나와 있습니다. 이 표는 이러한 메트릭을 수집하면서 기록하는 데 활용할 수 있습니다.

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

동시 사용자 수 – 서버 팜에서 실행되는 작업의 동시성은 일정 시간 동안 요청을 생성하는 개별 사용자 수로 측정하는 것이 가장 일반적입니다. 주요 메트릭은 일별 평균 및 부하가 높은 시간대의 동시 사용자 수입니다.
RPS(초당 요청 수) – RPS는 서버 팜에서 발생한 수요를 설명하는 데 일반적으로 사용되는 지표로, 요청의 유형 또는 크기 구분 없이 초당 팜에서 처리되는 요청 수로 나타냅니다. 모든 조직의 사용자층에서 시스템 부하를 발생시키는 속도는 조직 고유의 사용 현황 특성에 따라 달라집니다. 이 용어에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요의 용어집 섹션을 참조하십시오.
일별 총 요청 수 – 일별 총 요청 수는 시스템에서 처리해야 하는 전체 부하를 효과적으로 나타내는 지표입니다. 인증 핸드셰이크 요청(HTTP 상태 401)을 제외한 모든 요청을 24시간 동안 측정하는 것이 가장 일반적입니다.
일별 총 사용자 수 - 총 사용자 수는 시스템에서 처리해야 하는 전체 부하를 나타내는 또 다른 주요 지표입니다. 이 측정값은 조직의 총 직원 수가 아닌 24시간 동안의 실제 고유 사용자 수에 해당합니다.

참고

일별 총 사용자 수는 팜에 발생하는 부하의 잠재적 증가율을 나타낼 수 있습니다. 예를 들어 잠재 사용자 수가 100,000명인 경우 일별 사용자 수가 15,000명이면 시간이 지나면서 사용자의 채택이 증가함에 따라 부하가 대폭 증가할 수 있음을 나타냅니다.
작업량 분포 – 팜과 상호 작용하는 클라이언트 응용 프로그램을 토대로 요청의 분포를 파악하면 SharePoint Server 2010으로 마이그레이션한 후 예상되는 추세 및 부하 변화량을 손쉽게 예측할 수 있습니다. 사용자가 Office 2010 같은 최신 클라이언트 버전으로 전환하고 새로운 기능을 사용하기 시작하게 되면 새로운 부하 패턴, RPS 및 총 요청 수가 증가하게 됩니다. 각 클라이언트에 대해 하루 동안 해당 클라이언트를 사용하는 고유 사용자 수와 클라이언트나 기능이 서버에 발생시키는 총 요청의 양을 설명할 수 있습니다.

예를 들어 아래 차트에서는 일반적인 공유 솔루션을 처리하는 실제 Microsoft 환경 내부에 대한 스냅숏을 보여 줍니다. 이 예에서는 대부분의 부하가 검색 크롤러 및 일반적인 최종 사용자의 웹 검색을 통해 발생함을 확인할 수 있습니다. 또한 새로운 Outlook Social Connector 기능을 통해서도 많은 양의 부하(요청의 6.2%)가 발생하는 것을 알 수 있습니다.

요청에 대한 일반적인 일일 부하 분산

프로덕션 작업량 예측

팜에서 유지해야 하는 필수 처리량을 예측하려면 먼저 팜에 사용될 다양한 트랜잭션을 예측해야 합니다. 이 단계에서는 시스템을 통해 처리할 가장 많이 사용되는 트랜잭션을 분석하고 이러한 트랜잭션이 사용되는 빈도 그리고 이러한 트랜잭션의 사용자 수를 파악하는 데 중점을 둡니다. 이렇게 하면 나중에 프로덕션 이전 테스트를 통해 팜에서 이러한 부하를 감당할 수 있는지 여부를 쉽게 알 수 있습니다.

다음 다이어그램에서는 시스템에 발생하는 작업량과 부하의 관계를 설명합니다.

용량 - 작업량 다이어그램

예상 작업량을 예측하려면 다음 정보를 수집합니다.

사용자 상호 작용을 파악합니다. 사용자 상호 작용에는 일반적인 웹 페이지 검색, 파일 다운로드 및 업로드, 브라우저에서 Office Web Application 보기 및 편집, 공동 작성 상호 작용, SharePoint Workspace 사이트 동기화, Outlook 공유 연결, RSS 동기화(Outlook이나 다른 뷰어), PowerPoint 브로드캐스트, OneNote 공유 전자 필기장, Excel Service 공유 통합 문서, Access Service 공유 응용 프로그램 등이 있습니다. 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요 문서의 서비스 및 기능 섹션을 참조하십시오. 사용자 환경에서 고유하게 발생할 수 있는 상호 작용을 식별하는 데 중점을 두고 이러한 부하로 인해 예상되는 영향을 파악합니다. 이러한 상호 작용의 예로는 InfoPath 양식, Excel Service 계산 및 이와 비슷한 전용 솔루션의 과도한 사용을 들 수 있습니다.
시스템 작업을 파악합니다. 시스템 작업으로는 검색의 증분 크롤링, 일별 백업, 프로필 동기화 타이머 작업, Web Analytics 처리, 타이머 작업 로깅 등이 있습니다.
각 기능을 사용할 것으로 예상되는 일별 총 사용자 수를 예측하고, 여기서 예상되는 동시 사용자 수와 상위 수준의 초당 요청 수를 추론합니다. 이 과정에서 기능별로 각기 다른 동시 사용자당 RPS 요소 및 현재 동시성 같은 몇 가지 가정을 세웁니다. 예측 시에는 이 섹션의 앞부분에 나와 있는 작업량 표를 사용해야 합니다. 또한 평균 처리량보다는 사용량이 많은 시간대에 중점을 두는 것이 중요합니다. 사용량이 많은 작업에 대한 계획을 세워두면 SharePoint Server 2010 기반 솔루션의 크기를 적절히 조정할 수 있습니다.

기존 Office SharePoint Server 2007 솔루션이 있는 경우 IIS 로그 파일을 마이닝하거나 보유한 다른 웹 모니터링 도구를 사용하여 기존 솔루션의 일부 예상 동작을 보다 효과적으로 파악할 수도 있고 아래 섹션의 지침에서 자세한 내용을 확인할 수도 있습니다. 기존 솔루션에서 마이그레이션하는 경우가 아니면 대략적인 예상치를 사용하여 표를 채워야 합니다. 이후 단계에서는 가정의 유효성을 검사하고 시스템을 조정해야 합니다.

SharePoint Server 2010 IIS 로그 분석

활성 사용자 수, 해당 사용자의 시스템 사용 정도, 들어오는 요청의 유형, 요청이 생성되는 클라이언트의 유형 같은 기존 SharePoint Server 2010 배포에 대한 주요 메트릭을 확인하려면 ULS 및 IIS 로그에서 데이터를 추출해야 합니다. 이러한 데이터를 얻는 가장 쉬운 방법 중 하나는 Microsoft에서 무료로 다운로드하여 사용할 수 있는 강력한 도구인 Log Parser를 사용하는 것입니다. Log Parser를 사용하면 모든 IIS 형식을 포함하여 수많은 텍스트 및 이진 형식을 읽고 쓸 수 있습니다.

Log Parser를 사용하여 SharePoint Server 2010 사용 현황을 분석하는 방법에 대한 자세한 내용은 Microsoft SharePoint 제품 및 기술 사용 현황 분석(영문일 수 있음)(https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en)을 참조하십시오.

Log Parser 2.2는 https://www.microsoft.com/download/en/details.aspx?id=24659(영문일 수 있음)에서 다운로드할 수 있습니다.

데이터 집합

데이터 집합은 시스템에 저장된 콘텐츠의 양과 이러한 콘텐츠를 데이터 저장소에 배포하는 방법을 설명합니다. 다음 표에는 데이터 집합을 결정하는 데 도움이 되는 몇 가지 주요 메트릭이 나와 있습니다. 이 표는 이러한 메트릭을 수집하면서 기록하는 데 활용할 수 있습니다.

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

콘텐츠 크기 – SharePoint Server 2010 시스템에 저장할 콘텐츠의 크기를 파악하는 일은 시스템 저장소를 계획 및 설계하는 데는 물론 이러한 콘텐츠를 크롤링 및 인덱싱할 검색 솔루션의 크기를 올바르게 조정하는 데에도 중요한 역할을 합니다. 콘텐츠 크기는 총 디스크 공간으로 설명됩니다. 기존 배포 환경에서 콘텐츠를 마이그레이션하는 경우에는 옮길 총 크기를 손쉽게 파악할 수 있으므로 계획 과정에서, 예측한 추세를 바탕으로 시간에 따른 증가분을 고려하여 공간을 남겨 두어야 합니다.
총 문서 수 – 데이터 모음 크기 외에도 전체 항목 수를 추적하는 것이 중요합니다. 시스템은 100GB의 데이터가 각각 2GB인 50개의 파일로 구성된 경우와 각각 1KB인 100,000개의 파일로 구성된 경우에 대해 각기 다르게 반응합니다. 대규모 배포 환경에서는 단일 항목, 문서 또는 문서 영역에 발생하는 부하가 적을수록 성능이 높아집니다. 많은 사이트 및 사이트 모음에 걸쳐 여러 개의 작은 파일이 있는 경우처럼 광범위하게 배포된 콘텐츠는 매우 큰 파일이 포함된 대규모 단일 문서 라이브러리보다 처리하기가 용이합니다.
최대 사이트 모음 크기 – SharePoint Server 2010에 저장되는 가장 큰 콘텐츠 단위를 파악해야 합니다. 보통 조직에서는 해당 콘텐츠 단위를 분할하지 않도록 요구합니다. 모든 사이트 모음의 평균 크기 및 예상되는 총 사이트 모음 수는 기본 데이터 아키텍처를 파악하는 데 도움이 되는 추가적인 지표입니다.
서비스 응용 프로그램 데이터 특성 – 콘텐츠 저장을 위한 저장소 요구 사항을 분석하는 것 외에도 다음과 같은 다른 SharePoint Server 2010 저장소의 크기를 분석 및 예측해야 합니다.
검색 인덱스의 총 크기
프로필 저장소의 사용자 수를 토대로 한 프로필 데이터베이스의 총 크기
예상되는 태그, 동료 및 작업 수를 토대로 한 공유 데이터베이스의 총 크기
메타데이터 저장소 크기
사용 현황 데이터베이스 크기
Web Analytics 데이터베이스 크기

데이터베이스 크기를 예측하는 방법에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)을 참조하십시오.

팜 성능 및 안정성 목표 설정

1단계: 모델링을 수행하여 얻게 되는 결과 중 하나는 해당 조직의 요구 사항에 가장 적합한 성능 및 안정성 목표를 확실히 파악할 수 있다는 것입니다. 올바르게 디자인된 SharePoint Server 솔루션에서는 초 단위 미만의 서버 응답 속도로 "네 개의 9"(99.99%)에 이르는 가동 시간 비율을 달성할 수 있어야 합니다.

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

서버 가용성 – 일반적으로 시스템의 전체 가동 시간 비율로 설명됩니다. 예기치 못한 모든 가동 중지 시간을 추적하고 설정한 조직의 목표에 대해 전체 가용성을 비교해야 합니다. 이러한 목표는 대개 9의 개수(즉, 99%, 99.9%, 99.99%)로 설명됩니다.
서버 응답 성능 – 팜에서 요청을 처리하는 데 소요되는 시간은 팜의 상태를 효과적으로 추적할 수 있는 지표입니다. 이 지표는 대개 서버측 대기 시간이라고 하며 하루 동안 처리되는 요청의 평균 또는 중간(50번째 백분위수) 대기 시간을 사용하는 것이 일반적입니다. 목표는 대개 초 단위 미만 또는 초 단위로 설명됩니다. 조직에서 SharePoint Server 2010의 페이지를 2초 이내에 처리한다는 목표를 세워 놓고 있으면 페이지가 네트워크를 통해 클라이언트에 도달하기 위한 시간과 브라우저에서 렌더링되는 시간에 대비하여 서버측 목표는 초 단위 미만으로 설정해야 합니다. 또한 일반적으로 서버의 응답 시간이 길수록 팜의 상태가 좋지 않음을 나타내므로 서버에서 대부분의 요청을 처리하는 데 소요되는 시간이 1초를 초과하게 되면 대개 처리량에 영향이 발생하며 RPS를 좀처럼 유지할 수 없게 됩니다.
서버 스파이크 – 추적할 만한 또 다른 유용한 서버측 대기 시간 지표는 모든 요청 중 가장 느린 5% 요청의 동작입니다. 속도가 느린 요청은 대개 높은 부하 발생 시 시스템의 성능을 떨어뜨리거나 이보다 일반적으로는 사용자가 시스템과 상호 작용하는 동안 발생하는 사용 빈도가 낮은 작업에 의해 영향을 받습니다. 상태가 양호한 시스템은 최저 속도의 요청까지 제어할 수 있는 시스템입니다. 여기서의 목표는 서버 응답 성능과 비슷하지만 서버 스파이크에 대해 초 단위 미만의 응답 성능을 얻으려면 갑작스럽게 증가한 부하를 처리하기 위한 여분의 리소스가 충분하도록 시스템을 구축해야 합니다.
시스템 리소스 사용률 – 시스템의 상태를 추적하는 데 일반적으로 사용되는 그 밖의 지표로는 팜 토폴로지에 있는 각 서버의 상태를 나타내는 시스템 카운터 모음이 있습니다. 추적에 가장 많이 사용되는 지표는 CPU 사용률(%) 및 사용 가능한 메모리지만 이 외에도 상태가 양호하지 않은 시스템을 식별하는 데 도움이 될 수 있는 여러 가지 카운터가 있습니다. 자세한 내용은 5단계: 모니터링 및 유지 관리에서 확인할 수 있습니다.

2단계: 디자인

지금까지 제공해야 하는 솔루션에 대한 몇 가지 사실 또는 예측치를 수집했으므로 이제 예상 수요를 감당할 수 있을 것으로 예측되는 제안된 아키텍처를 디자인하는 다음 단계를 시작할 수 있습니다.

이 단계를 마치면 물리적 토폴로지에 대한 디자인과 논리적 토폴로지에 대한 레이아웃을 얻게 되므로 필요한 모든 구매 주문을 진행할 수 있게 됩니다.

레이아웃에 지정하는 하드웨어 사양 및 컴퓨터의 수는 밀접한 관련이 있으며 특정 부하를 처리하기 위해 여러 가지 솔루션 중에서 선택하여 배포할 수 있습니다. 강력한 성능의 컴퓨터를 소규모(수직 확장)로 사용하거나 소형 컴퓨터를 대규모(수평 확장)로 사용하는 것이 일반적입니다. 각각의 솔루션은 용량, 중복성, 전력, 비용, 공간 및 기타 고려 사항과 관련하여 저마다 장단점이 있습니다.

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

다음 표를 사용하여 디자인 매개 변수를 기록합니다. 여기에 포함된 데이터는 예제 데이터이므로 실제로 팜의 크기를 조정하는 데 사용해서는 안 됩니다. 이러한 데이터는 사용자 환경의 데이터에 맞게 이 표를 사용하는 방법을 보여 주기 위한 것입니다.

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

시작 지점으로 사용할 아키텍처 결정

이 섹션에서는 시작 지점으로 사용할 아키텍처를 선택하는 방법에 대해 설명합니다.

SharePoint Server 2010을 배포할 때는 여러 토폴로지 가운데 솔루션 구현에 필요한 토폴로지를 선택할 수 있습니다. 단일 서버를 배포할 수도 있고, 클러스터링 또는 미러링된 데이터베이스 서버 및 다양한 서비스를 위한 이산 응용 프로그램 서버를 사용하여 많은 수의 서버를 SharePoint Server 팜으로 수평 확장할 수도 있습니다. 나중에 각 역할의 요구 사항을 비롯하여 용량, 가용성 및 중복성 요구 사항을 토대로 하드웨어 구성을 선택하게 됩니다.

먼저 각기 다른 참조 아키텍처를 검토하고 팜 구조를 이해한 다음 솔루션을 여러 팜 간에 분할해야 하는지 아니면 전용 팜에서 검색 등의 일부 서비스를 연결해야 하는지를 결정합니다. 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요의 참조 아키텍처 섹션을 참조하십시오.

SharePoint Server 2010 기술 사례 연구

SharePoint Server 2010에 대한 용량 관리 지침에는 기존 SharePoint Server 기반 프로덕션 환경을 자세히 살펴보는 기존 프로덕션 환경에 대한 다양한 기술 사례 연구가 포함되어 있습니다. 향후 추가 기술 사례 연구가 계속 게시될 예정이며 이러한 기술 사례 연구는 SharePoint Server 기반 환경을 특정 용도에 맞게 디자인하는 방법에 대한 참고 자료로 활용할 수 있습니다.

이러한 사례 연구는 특히 설계하는 솔루션의 수요 및 목표와 비슷한 배포 관련 핵심 차별화 요소를 확인하는 경우 등에 SharePoint Server 솔루션 아키텍처 디자인을 수행하면서 참고 자료로 사용할 수 있습니다.

이러한 문서에서는 문서화된 각 사례 연구와 관련하여 다음과 같은 정보를 설명합니다.

사양 - 하드웨어, 팜 토폴로지 및 구성 등
작업량 - 사용자층 및 사용 현황 특성 등
데이터 집합 - 콘텐츠 크기, 콘텐츠 특성 및 콘텐츠 분포 등
상태 및 성능 - 팜의 안정성 및 성능 특성을 설명하는 일련의 기록된 지표

자세한 내용을 보려면 성능 및 용량 기술 사례 연구 페이지(https://technet.microsoft.com/ko-kr/library/cc261716.aspx)에서 관련 문서를 다운로드하십시오.

하드웨어 선택

팜의 컴퓨터에 적합한 사양을 선택하는 작업은 배포 환경의 안정성 및 성능을 적절하게 유지하기 위해 중요한 단계입니다. 여기서 최대 부하 및 사용량이 많은 시간대에 대한 계획을 세워야 한다는 점에 유의하십시오. 다시 말해, 팜이 평균적인 부하 조건에서 작동하는 경우 대기 시간 및 처리량 목표를 달성하면서 예상되는 최대 수요를 처리하기에 충분한 리소스를 사용할 수 있어야 합니다.

서버의 핵심 용량 및 성능 하드웨어 기능은 네 가지 주요 범주, 즉 시스템의 메모리 용량, 네트워크 용량, 디스크 성능 및 처리 능력을 나타냅니다.

고려해야 할 또 다른 사항은 가상화된 컴퓨터를 사용하는 부분입니다. SharePoint Server 팜은 가상 컴퓨터를 사용하여 배포할 수 있습니다. 이렇게 할 경우 아직 성능상의 혜택이 있는지는 확인되지 않았지만 관리 용이성 측면에서 이점을 얻게 됩니다. SQL Server 기반 컴퓨터는 일반적으로 가상화하지 않는 것이 좋지만 웹 서버 및 응용 프로그램 서버 계층을 가상화하면 확실한 이점을 얻을 수 있습니다. 자세한 내용은 가상화 계획(SharePoint Server 2010)(https://technet.microsoft.com/ko-kr/library/ff607968.aspx)을 참조하십시오.

하드웨어 선택 지침

프로세서 선택

SharePoint Server 2010은 64비트 프로세서에 대해서만 사용할 수 있습니다. 일반적으로 프로세서의 수가 많을수록 더 많은 수요를 처리할 수 있게 됩니다.

SharePoint Server 2010에서는 코어를 추가함에 따라 개별 웹 서버가 확장되며 테스트 결과 최대 24개까지 추가할 수 있는 것으로 확인되었습니다. 코어의 수가 많을수록 서버에서 더 많은 부하를 감당할 수 있지만 나머지 모든 요소에는 아무런 변화가 없습니다. 대규모 SharePoint Server 배포 환경에서는 가상화가 가능한 4코어 웹 서버를 여러 대 할당하거나, 더 강력하지만 더 적은 수의 웹 서버(8/16/24코어)를 할당하는 것이 좋습니다.

응용 프로그램 서버의 프로세서 용량 요구 사항은 서버의 역할 및 서버가 실행되는 서비스에 따라 달라집니다. 일부 SharePoint Server 기능은 다른 기능보다 더 높은 처리 능력이 필요합니다. 예를 들어 SharePoint Search Service는 응용 프로그램 서버의 처리 능력에 크게 의존합니다. SharePoint Server 기능 및 서비스의 리소스 요구 사항에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요 문서의 서비스 및 기능 섹션을 참조하십시오.

SQL Server의 프로세서 용량 요구 사항은 SQL Server 기반 컴퓨터에서 호스팅하는 서비스 데이터베이스에 따라서도 달라집니다. 각 데이터베이스의 일반적인 동작 및 요구 사항에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)을 참조하십시오.

메모리 선택

서버에는 서버의 기능 및 역할에 따라 다양한 양의 메모리가 필요하게 됩니다. 예를 들어 검색 크롤링 구성 요소를 실행하는 서버의 경우 문서를 메모리로 읽어 들여 처리하므로 대용량 메모리가 있으면 데이터를 보다 신속하게 처리하게 됩니다. SharePoint Server 2010의 많은 캐시 기능을 활용하는 웹 서버에도 많은 메모리가 필요할 수 있습니다.

일반적으로 웹 서버의 메모리 요구 사항은 팜에서 사용하도록 설정된 응용 프로그램 풀의 수와 처리되는 동시 요청 수에 따라 크게 달라집니다. 대부분의 프로덕션 SharePoint Server 배포 환경에서는 웹 서버마다 8GB 이상의 RAM을 할당하는 것이 좋으며 트래픽의 양이 많은 서버나 여러 응용 프로그램 풀을 격리하여 설정한 배포 환경의 경우에는 16GB를 사용하는 것이 좋습니다.

응용 프로그램 서버의 메모리 요구 사항도 경우에 따라 다릅니다. 즉, 일부 SharePoint Server 기능의 경우 다른 기능보다 응용 프로그램 계층에 더 많은 메모리를 필요로 합니다. 대부분의 프로덕션 SharePoint Server 배포 환경에서는 응용 프로그램 서버마다 8GB 이상의 RAM을 할당하는 것이 좋습니다. 동일한 서버에서 많은 응용 프로그램 서비스를 사용하는 경우 또는 Excel Calculation Service 및 SharePoint Server Search Service 같은 메모리를 많이 활용하는 서비스를 사용하는 경우에는 16GB, 32GB 및 64GB 응용 프로그램 서버를 고려하는 것이 일반적입니다.

데이터베이스 서버의 메모리 요구 사항은 데이터베이스의 크기와 밀접한 관련이 있습니다. SQL Server 기반 컴퓨터를 위한 메모리를 선택하는 방법에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)을 참조하십시오.

네트워크 선택

클라이언트에서 네트워크를 통해 데이터에 빠른 속도로 액세스할 수 있으면 사용자에게 유용합니다. 한편 분산된 팜에서도 서버 간 통신을 위해 빠른 액세스 속도를 유지해야 합니다. 이는 특히 서비스를 여러 서버 간에 배포하거나 일부 서비스를 다른 팜에 연결하는 경우에 중요한 역할을 합니다. 웹 서버 계층, 응용 프로그램 서버 계층 및 데이터베이스 서버 계층 간의 팜에는 많은 양의 트래픽이 발생하며, 매우 큰 파일이나 높은 부하를 처리하는 등의 특정 조건에서는 네트워크에 손쉽게 병목 현상이 발생할 수 있습니다.

웹 서버와 응용 프로그램 서버를 구성할 때는 NIC(네트워크 인터페이스 카드)를 두 개 이상 사용해야 하는데, NIC 하나에서는 최종 사용자 트래픽을 처리하고 다른 하나에서는 서버 간 통신을 담당하게 됩니다. 서버 간에 발생하는 네트워크 대기 시간은 성능에 많은 영향을 줄 수 있으므로 콘텐츠 데이터베이스를 호스팅하는 SQL Server 기반 컴퓨터와 웹 서버 간에는 네트워크 대기 시간을 1밀리초 미만으로 유지하는 것이 중요합니다. 각 서비스 응용 프로그램 데이터베이스를 호스팅하는 SQL Server 기반 컴퓨터는 사용하는 응용 프로그램 서버와도 가능한 한 가까이 있는 것이 좋습니다. 또한 팜 서버 간 네트워크의 대역폭은 1Gbps 이상이어야 합니다.

디스크 및 저장소 선택

디스크 관리는 데이터를 위한 적절한 공간을 제공하는 것으로 그치는 것이 아닙니다. 지속적인 수요 및 증가분을 평가하고 저장소 아키텍처로 인해 시스템의 속도가 느려지지 않도록 해야 합니다. 또한 항상 필요한 최대 데이터 예상치보다 높게 디스크마다 30% 이상의 추가 용량을 확보하여 향후 증가분을 위한 공간을 남겨 두어야 합니다. 그뿐만 아니라 대부분의 프로덕션 환경에서 서버의 저장 수요를 충족하기에 충분한 처리량을 제공하는 데는 디스크 속도(IOPS)가 중요한 역할을 합니다. 배포 환경에서 주 데이터베이스에 필요할 것으로 예상되는 트래픽의 양(IOPS)을 예측하고 이러한 트래픽을 처리하기에 충분한 디스크를 할당해야 합니다.

데이터베이스 서버를 위한 디스크를 선택하는 방법에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)을 참조하십시오.

웹 서버 및 응용 프로그램 서버의 저장소 요구 사항도 마찬가지입니다. 대부분의 프로덕션 환경에서는 OS 및 임시 파일에 대해서는 200GB의 공간, 로그에 대해서는 150GB의 디스크 공간을 각각 할당하는 것이 좋습니다.

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

테스트 및 최적화 단계는 효과적인 용량 관리를 위한 핵심적인 단계입니다. 새로운 아키텍처는 프로덕션 환경에 배포하기 전에 테스트를 거쳐야 하며, 디자인한 아키텍처가 성능 및 용량 목표를 달성하도록 하려면 다음과 같은 모니터링 관련 모범 사례와 함께 승인 테스트를 수행해야 합니다. 이렇게 하면 잠재적인 병목 현상이 실제 환경의 사용자에게 영향을 미치기 전에 식별하고 최적화할 수 있습니다. Office SharePoint Server 2007 환경에서 업그레이드하는 상황에서 아키텍처를 변경하려는 경우나 SharePoint Server의 새 기능으로 인해 발생하는 사용자 부하를 예측하는 경우에는 새 SharePoint Server 기반 환경이 성능 및 용량 목표를 충족하도록 하는 과정에 테스트가 매우 중요한 역할을 합니다.

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

다음은 프로덕션 이전 환경에 대해 수행하도록 권장되는 하위 단계입니다.

2단계: 디자인에서 디자인한 초기 아키텍처를 모방한 테스트 환경을 만듭니다.
1단계: 모델링에서 식별한 데이터 집합의 전부 또는 일부로 저장소를 채웁니다.
1단계: 모델링에서 식별한 작업량을 나타내는 가상 부하를 사용하여 시스템에 부하를 발생시킵니다.
테스트를 실행하고 결과를 분석하고 아키텍처를 최적화합니다.
최적화된 아키텍처를 데이터 센터에 배포하고 일부 사용자를 대상으로 하는 파일럿 환경을 배포합니다.
파일럿 결과를 분석하고 잠재적인 병목 현상을 식별하고 아키텍처를 최적화한 다음 필요한 경우 다시 테스트합니다.
프로덕션 환경에 배포합니다.

테스트

시스템 디자인에서 작업량 및 사용 현황 특성을 지원할 수 있는지 확인하는 데 테스트는 필수적입니다. SharePoint Server 2010 배포를 테스트하는 방법에 대한 자세한 내용은 SharePoint Server 2010 성능 테스트를 참조하십시오.

테스트 계획 만들기
테스트 환경 만들기
테스트 및 도구 만들기

파일럿 환경 배포

SharePoint Server 2010을 프로덕션 환경에 배포하기 전에 먼저 파일럿 환경을 배포하고 팜을 철저하게 테스트하여 해당 환경이 예상되는 최대 부하에 대해 용량 및 성능 목표를 충족할 수 있는지 확인하는 것이 중요합니다. 먼저 가상 부하(특히, 대규모 배포의 경우)를 사용하여 파일럿 환경을 테스트한 다음 소규모 실제 사용자 및 콘텐츠 집합을 사용하여 이러한 환경에 부하를 적용해 보는 것이 좋습니다. 소규모 실제 사용자 집합으로 파일럿 환경을 분석하면 프로덕션 환경으로 완전히 옮겨가기 전에 사용 현황 특성 및 콘텐츠 증가분과 관련하여 세운 일부 가정의 유효성을 검사할 수 있습니다.

최적화

팜 하드웨어를 확장하거나 토폴로지를 변경하는 방식으로는 용량 및 성능 목표를 충족할 수 없는 경우 솔루션을 수정해야 할 수도 있습니다. 예를 들어 초기 요구 사항이 검색 및 공유 같은 공동 작업을 위한 단일 팜과 관련된 것일 경우 검색 등의 일부 서비스를 전용 서비스 팜에 연결하거나 작업량을 더 많은 팜에 분할해야 할 수 있습니다. 이를 위한 한 가지 대안으로 공유를 위한 전용 팜과 팀 공동 작업을 위한 전용 팜을 각각 하나씩 배포하는 방법을 활용할 수도 있습니다.

4단계: 배포

테스트의 마지막 단계를 실행하고 선택한 아키텍처가 1단계: 모델링에서 정한 성능 및 용량 목표를 달성할 수 있는 것으로 확인되었으면 SharePoint Server 2010 기반 환경을 프로덕션 환경에 배포할 수 있습니다.

적절한 배포 전략은 사용 환경 및 상황에 따라 달라집니다. SharePoint Server의 일반적인 배포는 이 문서의 범위를 벗어나지만 용량 계획 실습 과정에서 얻을 수 있는 몇 가지 제안 작업이 있습니다. 다음은 몇 가지 예입니다.

새 SharePoint Server 팜 배포: 이 용량 계획 실습에서는 SharePoint Server 2010의 디자인 및 배포 계획을 살펴보고 확인했습니다. 여기서의 배포는 SharePoint Server 2010을 처음으로 광범위하게 배포하는 상황입니다. 이를 위해 용량 계획 실습 과정에 사용한 서버 및 서비스를 프로덕션 환경으로 옮기거나 다시 구축하게 됩니다. 이는 기존 팜을 업그레이드하거나 수정할 필요가 없기 때문에 가장 수월한 시나리오입니다.
SharePoint Server 2010으로 Office SharePoint Server 2007 팜 업그레이드: 이 용량 계획 실습에서는 기존 수요를 충족하고 SharePoint Server 2010 팜의 늘어난 수요 및 사용량을 충족하도록 수직으로 확장할 수 있는 팜의 디자인에 대해 유효성 검사를 수행했습니다. 일부 용량 계획 실습에는 업그레이드 프로세스의 소요 시간, 사용자 지정 코드의 수정 또는 교체 여부, 타사 도구 업데이트 여부 등을 확인하도록 테스트 마이그레이션이 포함되었습니다. 용량 계획을 마무리하면 유효성 검사를 마친 디자인을 얻고 업그레이드에 소요되는 시간을 파악하게 되는 것은 물론 전체 업그레이드 또는 새 팜으로 콘텐츠 데이터베이스 마이그레이션 등의 가장 적합한 업그레이드 방법에 대한 계획을 수립하게 됩니다. 전체 업그레이드를 수행하는 경우 용량 계획 과정을 통해 추가 또는 업그레이드된 하드웨어가 필요하며 가동 중지 시간에 대해서도 고려해야 한다는 것을 알 수 있습니다. 계획 실습 결과물의 일부로 필요한 하드웨어 변경 사항 목록과 하드웨어 변경 사항을 팜에 먼저 배포하기 위한 세부 계획도 얻게 됩니다. 용량 계획 과정에서 유효성을 검사한 하드웨어 플랫폼을 배치한 후에는 SharePoint Server 2010으로의 업그레이드 프로세스를 진행할 수 있습니다.
기존 SharePoint Server 2010 팜 성능 개선: 이 용량 계획 실습에서는 현재 구현의 병목 현상을 식별하고, 이러한 병목 현상을 줄이거나 없애는 방법을 고안하고, SharePoint Server 서비스의 비즈니스 요구 사항을 충족하는 향상된 구현의 유효성을 검사하는 과정을 안내했습니다. 기존 하드웨어 간에 서비스를 다시 할당하는 간단한 방법부터 기존 하드웨어를 업그레이드하거나, 하드웨어 및 서비스를 추가하는 등의 방법에 이르기까지 다양한 방법을 통해 성능 문제를 해결할 수 있었습니다. 이 용량 계획 실습에서는 다양한 접근 방식을 테스트하고 유효성을 검사해야 하며 해당 테스트 결과에 따라 배포 계획을 체계적으로 수립해야 합니다.

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

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

초기 단계에 환경을 모니터링하도록 수정할 수 있는 설정 목록을 확인하려면 SharePoint Server 2010 모니터링 및 유지 관리를 참조하십시오. 이 문서는 변경이 필요한 경우를 파악하는 데 도움이 됩니다. 이때 모니터링 기능을 늘리면 사용 데이터베이스에 필요한 디스크 공간의 양에 영향을 미치게 된다는 점을 염두에 두십시오. 환경이 안정적으로 작동하고 이러한 세부적인 모니터링이 더 이상 필요 없게 되면 아래 설정을 기본값으로 되돌릴 수도 있습니다.

SharePoint Server 중앙 관리 인터페이스에 기본 제공되는 상태 모니터링 도구를 사용하여 상태를 모니터링하고 문제를 해결하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.

상태 모니터링(SharePoint Server 2010)

문제 해결(SharePoint Server 2010)(https://technet.microsoft.com/ko-kr/library/ee748639.aspx)