SharePoint Server 2013의 용량 관리 및 크기 조정 개요
**적용 대상:**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard
**마지막으로 수정된 항목:**2016-12-16
**요약:**성능 데이터를 사용하여 SharePoint Server 2013 환경의 용량을 계획 및 관리하는 방법을 설명합니다.
이 문서에서는 SharePoint Server 2013 환경에서 용량을 효과적으로 계획하고 관리하는 방법을 간략히 살펴봅니다. 성능 및 데이터의 양을 분석해 배포에 필요한 용량과 기능을 정확하게 파악하는 방법과 콘텐츠의 특성 및 용도를 포함하여 용량에 영향을 주는 응용 프로그램의 주요 요인에 대해서도 검토합니다.
중요
이 문서의 일부 값은 테스트 결과 및 SharePoint 2010 제품과 관련된 기타 정보일 수 있으며 SharePoint Server 2013의 최종 값을 나타내지 않을 수 있습니다. 이 문서는 SharePoint Server 2013 관련 데이터를 사용할 수 있게 될 때 해당 값, 콘텐츠 및 기타 정보와 관련된 링크로 업데이트된 후 다시 게시될 예정입니다.
콘텐츠와 용도가 변하지 않는 구현은 없으므로 용량 관리는 지속적으로 이루어져야 하는 프로세스입니다. 따라서 SharePoint Server 2013 기반 환경에서 효과적인 비즈니스 솔루션을 지속적으로 제공할 수 있도록 향후의 규모 증가 및 변경에 대한 계획을 세워야 합니다.
용량 계획은 용량 관리 주기에 포함되는 하나의 요소이며 용량 관리 주기의 초기에 이루어지는 일련의 작업입니다. 이 단계에서 디자인 설계자는 SharePoint Server 2013 배포에 가장 적합한 초기 아키텍처를 구상합니다. 용량 관리 모델에는 초기 아키텍처를 검증하고 조정하는 데 사용할 수 있는 추가 단계가 포함되어 있으며 최적의 하드웨어, 토폴로지 및 구성으로 디자인 목표를 충족할 때까지 프로덕션 환경을 다시 계획하고 최적화할 수 있도록 피드백 순환 고리를 제공합니다.
이 문서의 내용
용어
용량 관리 문서 제공 대상
성능과 관련된 네 가지 기본 사항
용량 관리와 용량 계획
오버사이징과 언더사이징
소프트웨어 제한 및 경계
SharePoint Server 2013 배포의 주요 차이점
참조 아키텍처
용어
다음은 SharePoint Server 2013 용량 관리 설명서에서 사용되는 전문 용어입니다.
RPS 초당 요청 수를 나타냅니다. 팜이나 서버에서 1초 동안 받은 요청의 수로, 일반적으로 서버와 팜의 부하를 측정하는 데 사용되는 측정 단위입니다. 팜에서 처리하는 요청의 수는 페이지 로드 횟수 및 최종 사용자 상호 작용 횟수보다 많은데 이는 페이지마다 몇 가지 구성 요소를 포함하며 이러한 구성 요소로 인해 페이지를 로드할 때 요청이 하나 이상 만들어지기 때문입니다. 트랜잭션 비용의 측면에서 볼 때 일부 요청은 다른 요청보다 저렴합니다. 실험 테스트 및 사례 연구 문서에서 401 요청 및 응답(인증 핸드셰이크)은 RPS를 계산하는 데 사용된 요청의 수에서 제외되었는데 이러한 요청은 팜 리소스에 별다른 영향을 주지 않기 때문입니다.
사용량이 많은 시간 하루 중 팜의 부하가 최대치에 이르는 시간 또는 시간대입니다.
최대 부하 RPS 단위로 측정된, 팜의 일일 평균 최대 부하입니다.
부하 급증 평상시 사용량이 많은 시간이 아닌 다른 시간에 일시적으로 부하가 높아지는 현상을 말합니다. 계획되지 않은 사용자 트래픽 증가, 관리 작업으로 인한 팜 처리량 감소 또는 이러한 요인이 복합적으로 작용한 결과일 수 있습니다.
수직 확장 수직 확장이란 프로세서나 메모리와 같은 리소스를 서버에 추가하는 것을 말합니다.
수평 확장 수평 확장이란 팜에 서버를 추가하는 것을 말합니다.
용량 관리 문서 제공 대상
이 문서의 내용을 확인해야 할지 확실치 않으면 다음과 같은 사항에 해당하는지 검토해 보십시오.
SharePoint Server 2013 평가
중요
이 섹션의 일부 링크는 SharePoint Server 2010 및 기타 이전 제품 버전을 참조하며 이 콘텐츠의 SharePoint Server 2013 버전을 사용할 수 있게 되면 업데이트될 예정입니다.
IT 전문가이거나 비즈니스 의사 결정권자이고 특정 비즈니스 문제를 해결할 솔루션을 찾고 있으며 배포에 SharePoint Server 2013을 사용할 수 있는데*,* 특정 요구 사항을 충족하는 데 필요한 기능과 확장성이 제공되는지 여부
SharePoint Server 2013이 특정 솔루션의 요구 사항에 맞게 확장되는 방식 및 요구 사항을 지원하는 데 필요한 하드웨어를 결정하는 방법에 대한 자세한 내용은 이 문서 뒷부분에서 다음 섹션을 참조하십시오.
SharePoint Server 2013이 특정 비즈니스 요구 사항에 맞는지 평가하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.
Office SharePoint Server 2010에서 업그레이드
현재 SharePoint Server 2010을 사용하고 있습니다. SharePoint Server 2013에서는 어떤 부분이 달라졌으며 업그레이드할 경우 어떤 점을 고려해야 합니까? 업그레이드할 경우 토폴로지의 성능과 규모에는 어떤 영향을 미치게 됩니까?
일반적인 업그레이드 고려 사항과 Office SharePoint Server 2007에서의 업그레이드를 계획하고 실행하는 방법에 대한 지침은 다음 문서를 참조하세요.
실시간 SharePoint 기반 환경 조정 및 최적화
SharePoint Server 2013을 배포했으며 적절한 하드웨어 및 토폴로지가 배치되었는지 확인하려고 합니다. 아키텍처의 유효성을 검사하고 적절히 유지 관리하려면 어떻게 해야 합니까?
SharePoint Server 2013 팜에 대 한 모니터링 및 성능 카운터에 대 한 정보를 확인 하려면 다음 문서를 참조 하십시오.
중앙 관리 인터페이스에 기본적으로 제공되는 상태 모니터링 도구의 사용 방법에 대해서는 다음 문서를 참조하세요.
SharePoint Server 2013을 배포했으나 성능 문제가 있습니다. 문제를 해결하고 환경을 최적화하려면 어떻게 해야 합니까?
에 SharePoint Server 2013 팜의 모니터링 및 성능 카운터에 대 한 내용은 다음 문서를 참조 합니다.
SharePoint Server 2013 팜 최적화 도구 및 기법에 대한 자세한 내용은 다음 문서를 참조하세요.
중앙 관리 인터페이스에 기본적으로 제공되는 상태 모니터링 도구를 사용한 문제 해결에 대해서는 다음 문서를 참조하세요.
특정 SharePoint Server 2010 서비스 및 기능에 대해 사용할 수 있는 용량 관리 문서 목록(사용 가능해지면 문서가 더 추가될 예정임)에 대해서는 다음 문서를 참조하세요.
데이터베이스 크기 조정 및 성능에 대한 자세한 내용은 다음 문서를 참조하세요.
RBS(원격 BLOB 저장소)에 대한 자세한 내용은 다음 문서를 참조하세요.
전반적인 모든 정보
SharePoint Server 2013 용량 관리에 대한 모든 것을 알고 싶습니다. 어디에서 시작해야 할까요?
용량 관리의 기본 개념과 추가 설명서 및 리소스에 대한 링크를 보려면 다음 문서를 참조하세요.
용량 관리에 대한 자세한 내용은 이 개요 문서와 맥락을 같이하는 다음 문서를 참조하세요.
이제 개념이 어느 정도 이해되었을 것입니다. SharePoint Server 2013의 제한 및 경계에 대한 자세한 내용은 다음 문서를 참조하세요.
SharePoint Server 2013 기반 환경에 대한 시작점 토폴로지를 확인할 준비가 되면 사용 가능한 기술 사례 연구 라이브러리를 검토하여 요구에 가장 근접한 토폴로지를 찾아볼 수 있습니다. SharePoint Server 2010 사례 연구(SharePoint Server 2013 사례 연구는 사용 가능해지면 게시될 예정임)에 대해서는 다음 문서를 참조하세요.
중앙 관리 인터페이스에 기본적으로 제공된 상태 모니터링 도구를 사용한 상태 모니터링 및 문제 해결에 대한 자세한 내용은 다음 문서를 참조하세요.
SharePoint Server 2013 기반 서버 가상화 방법에 대한 자세한 내용은 다음 문서를 참조하세요.
고가용성 및 재해 복구에 대한 자세한 내용은 다음 문서를 참조하세요.
성능과 관련된 네 가지 기본 사항
용량 관리는 솔루션의 크기 조정과 관련된 다음 네 가지 주요 측면에 중점을 둡니다.
대기 시간 용량 관리에서 대기 시간이란 사용자가 하이퍼링크 클릭과 같은 작업을 시작한 시간과 마지막 바이트가 클라이언트 응용 프로그램이나 웹 브라우저로 전송된 시간 사이의 간격으로 정의됩니다.
처리량 처리량은 서버나 서버 팜에서 처리할 수 있는 동시 요청 수로 정의됩니다.
데이터 단위 데이터 단위는 시스템에서 호스팅할 수 있는 콘텐츠 크기 및 데이터 모음으로 정의됩니다. 콘텐츠 데이터베이스의 구조와 배포 방식은 시스템에서 요청을 처리하는 데 필요한 시간(대기 시간) 및 서버에서 처리할 수 있는 동시 요청 수(처리량)에 많은 영향을 줍니다.
안정성 안정성은 시간이 경과함에 따라 시스템에서 설정된 대기 시간 및 처리량 목표를 충족할 수 있는지를 나타내는 측정 결과입니다.
환경의 용량을 관리하는 주요 목적은 조직의 대기 시간, 처리량, 데이터 단위 및 안정성 목표를 충족하도록 시스템을 설정하고 유지 관리하는 데 있습니다.
대기 시간
대기 시간 또는 최종 사용자가 인지하는 대기 시간은 크게 세 가지 구성 요소로 이루어져 있습니다.
서버에서 요청을 받아서 처리하는 데 소요되는 시간
요청을 받고 네트워크를 통해 서버 응답을 전송하는 데 소요되는 시간
클라이언트 응용 프로그램에서 응답이 렌더링되는 데 소요되는 시간
조직마다 비즈니스 요구 사항 및 사용자 기대치에 맞는 고유의 대기 시간 목표가 있습니다. 대기 시간이 몇 초인 조직이 있는가 하면 매우 빠른 트랜잭션을 요구하는 조직도 있습니다. 매우 빠른 트랜잭션에 맞게 최적화하는 데는 일반적으로 비용이 더 많이 듭니다. 예를 들어 더 강력한 클라이언트와 서버, 최신 버전의 브라우저와 클라이언트 응용 프로그램, 높은 대역폭의 네트워크 솔루션이 필요하며 개발 부문에 대한 투자와 페이지 조정이 필요할 수도 있습니다.
아래에 나오는 몇 가지 일반적인 문제는 최종 사용자가 인지하는 대기 시간이 길어지게 하는 주요 요인으로 작용합니다. 이러한 요인은 특히 클라이언트가 서버 팜과 지리적으로 떨어져 있거나 낮은 대역폭의 네트워크 연결을 통해 팜에 액세스하는 시나리오와 관련이 깊습니다.
최적화되지 않은 기능, 서비스 또는 구성 매개 변수. 이러한 요소가 있으면 요청의 처리가 지연되고 원격 및 로컬 클라이언트 모두에서 대기 시간에 영향을 줄 수 있습니다. 자세한 내용은 이 문서 뒷부분에서 처리량 및 안정성을 참조하십시오.
서버에 대해 필요한 데이터 및 리소스를 다운로드하라는 불필요한 요청을 생성하는 웹 페이지. 이러한 경우 페이지를 렌더링하는 데 필요한 최소한의 리소스만 다운로드하거나, 이미지 크기를 줄이거나, 익명 액세스를 지원하는 폴더에 정적 리소스를 저장하거나, 서버에서 비동기로 리소스를 다운로드하는 동안 요청을 클러스터링하고 페이지 대화형 작업을 사용하는 등의 최적화를 수행할 수 있습니다. 이러한 최적화 작업은 최초 방문 시 적절한 수준의 검색 환경을 제공하는 데 매우 중요한 역할을 합니다.
네트워크를 통해 대용량 데이터 전송. 이 경우 대기 시간이 길어지고 처리량이 줄어듭니다. 예를 들어 페이지의 이미지와 기타 이진 개체는 가능하면 비트맵 대신 .png나 .jpg와 같은 압축된 형식으로 포함해야 합니다.
두 번째 액세스하는 페이지 로드에 맞게 최적화되지 않은 웹 페이지. 두 번째 액세스하는 페이지는 로드할 때 PTL(페이지 로드 시간)이 개선되는데 일부 페이지 리소스가 클라이언트에 캐시되어 있으며 그에 따라 브라우저에서는 캐시되지 않은 동적 콘텐츠만 다운로드하면 되기 때문입니다. 종종 잘못된 BLOB(Binary Large Object) 캐시 구성으로 인해 또는 클라이언트 컴퓨터에서 로컬 브라우저 캐싱이 비활성화되어 있어서 두 번째 액세스하는 페이지의 로드 대기 시간이 적절한 수준 이상으로 길어질 수 있습니다. 최적화에는 클라이언트에서 리소스를 올바르게 캐시하는 작업이 포함됩니다.
최적화되지 않은 사용자 지정 JavaScript 코드를 포함하는 웹 페이지. 이 경우 클라이언트에서 페이지 렌더링 속도가 느려질 수 있습니다. 코드를 최적화하면 페이지의 나머지 부분이 로드될 때까지 클라이언트에서 JavaScript 처리가 지연되며 JavaScript를 인라인으로 추가하는 대신 스크립트를 호출합니다.
처리량
처리량은 서버 팜에서 특정 시간 단위 동안 처리할 수 있는 요청의 수로 설명할 수 있습니다. 처리량은 조직의 규모 및 사용 특성을 기반으로 시스템에서 감당할 수 있을 것으로 예상되는 작업량을 측정하는 데 흔히 사용됩니다. 모든 작업에서는 서버 팜의 리소스를 사용합니다. 요구 사항을 이해하고 이러한 요구 사항을 일관되게 충족하는 팜 아키텍처를 배포하려면 예상되는 부하를 예측하고 이러한 부하에서 아키텍처를 테스트하여 동시성이 높고 시스템에 부하가 발생하는 상황에서도 대기 시간이 목표값 아래로 떨어지지 않는지 확인해야 합니다.
처리량이 낮은 상태를 야기하는 몇 가지 일반적인 예는 다음과 같습니다.
부적절한 하드웨어 리소스 팜에서 동시에 처리할 수 있는 것보다 많은 요청을 받으면 일부 요청이 큐에 대기하게 되고 이 경우 요청이 줄어들어 큐가 완전히 정리될 때까지 각각의 이후 요청에 대한 처리가 누적되어 지연됩니다. 다음은 보다 큰 처리량을 감당하도록 팜을 최적화하는 몇 가지 예입니다.
팜 서버의 프로세서가 과도하게 사용되고 있지 않은지 확인합니다. 예를 들어 사용량이 많은 시간이나 부하가 급증할 때 CPU 사용량이 지속적으로 80%를 초과하면 서버를 추가하거나 다른 팜 서버에 서비스를 다시 배포합니다.
응용 프로그램 서버 및 웹 서버에 전체 캐시를 포함하기에 충분한 메모리를 할당합니다. 이렇게 하면 캐시되지 않은 콘텐츠에 대한 요청을 처리하기 위한 데이터베이스 호출이 방지됩니다.
사용 가능한 총 디스크 IOPS가 최대 수요를 지원하기에 부족하면 디스크를 추가하거나 사용률이 낮은 디스크에 데이터베이스를 다시 배포합니다. 자세한 내용은 SharePoint Server 2013 모니터링 및 유지 관리의 병목 현상 제거 섹션을 참조하세요.
기존 컴퓨터에 리소스를 추가하는 것만으로는 처리량 문제를 해결하기에 부족한 경우 서버를 추가하고 영향을 받은 기능 및 서비스를 새 서버에 다시 배포합니다.
최적화되지 않은 사용자 지정 웹 페이지 처리량 문제는 대개 프로덕션 환경에서 자주 사용되는 페이지에 사용자 지정 코드를 추가하는 것으로 인해 발생합니다. 사용자 지정 코드를 추가하면 데이터 요청을 처리하기 위해 데이터베이스 서버나 웹 서비스로의 추가 왕복이 생성될 수 있습니다. 자주 사용되지 않는 페이지를 사용자 지정하면 처리량에 크게 영향을 주지 않지만 적절하게 최적화된 코드라도 하루에 수천 번 요청하면 팜의 처리량을 저하시킬 수 있습니다. SharePoint Server 2013 관리자는 개발자 대시보드를 활성화하여 최적화가 필요한 사용자 지정 코드를 식별할 수 있습니다. 다음은 사용자 지정 코드를 최적화하는 몇 가지 예입니다.
웹 서비스 요청 및 SQL 쿼리의 수를 최소화합니다.
데이터베이스 서버에 대한 각 왕복에서 필요한 최소한의 데이터만 가져오고 필요한 왕복 횟수를 제한합니다.
자주 사용되는 페이지에 사용자 지정 코드를 추가하지 않습니다.
필터링된 데이터를 검색할 때 인덱스를 사용합니다.
신뢰할 수 없는 솔루션 bin 폴더에 사용자 지정 코드를 배포하면 서버 성능이 느려질 수 있습니다. 신뢰할 수 없는 코드가 포함된 페이지가 요청될 때마다 SharePoint Server 2013에서 페이지를 로드하기 전에 보안 검사를 수행해야 합니다. 신뢰할 수 없는 코드를 배포해야 하는 특별한 이유가 없으면 사용자 지정 어셈블리를 GAC에 설치하여 불필요한 보안 검사가 수행되지 않도록 해야 합니다.
데이터 단위
데이터 단위는 서버나 서버 팜에서 대기 시간 및 처리량 목표를 충족하는 한도 내에서 저장할 수 있는 데이터의 양입니다. 일반적으로 팜의 데이터 양이 많을수록 전반적인 처리량과 사용자 환경에 미치는 영향도 큽니다. 디스크와 데이터베이스 서버 간에 데이터를 분산하는 데 사용된 방법도 팜 대기 시간 및 처리량에 영향을 줄 수 있습니다.
데이터베이스 크기 조정, 데이터 아키텍처 및 충분한 데이터베이스 서버 하드웨어는 모두 최적의 데이터베이스 솔루션을 구현하는 데 중요한 역할을 합니다. 이상적인 배포에서는 제한 지침에 따라 콘텐츠 데이터베이스 크기를 조정하고, 여러 물리적 디스크에 콘텐츠 데이터베이스를 분산함으로써 과도한 디스크 사용으로 인해 요청이 큐에서 대기하지 않도록 하며, 데이터베이스 서버에서는 리소스 사용률 임계값을 초과하지 않고도 사용량이 많은 시간과 예기치 않은 사용량 급증을 감당할 수 있습니다.
또한 특정 작업은 작업 중 일부 테이블을 잠글 수 있습니다. 큰 사이트를 삭제하는 경우를 예로 들 수 있습니다. 이 경우 삭제 작업이 완료될 때까지 해당 사이트가 상주하는 콘텐츠 데이터베이스에서 관련 테이블이 잠깁니다.
다음은 데이터 및 저장소 성능에 맞게 팜을 최적화하는 몇 가지 예입니다.
데이터베이스를 여러 데이터베이스 서버에 적절히 분산하고 데이터의 양과 배포 방식을 지원하기에 충분한 데이터베이스 서버 리소스를 할당합니다.
데이터베이스 볼륨을 고유한 물리적 디스크 스핀들로 이루어진 고유한 LUN(논리 단위)으로 나눕니다. 검색 시간이 짧고 적절한 RAID 구성을 가진 디스크를 여러 개 사용하여 데이터베이스 서버 저장소 요구 사항을 충족합니다.
데이터 모음에 BLOB(Binary Large Object)가 다수 포함된 경우 RBS(원격 BLOB 저장소)를 사용할 수 있습니다. RBS는 다음과 같은 이점을 제공합니다.
BLOB 데이터를 단순 저장소를 처리하도록 구성된 보다 저렴한 저장 장치에 저장할 수 있습니다.
BLOB 저장소의 관리는 BLOB 데이터로 작업하도록 특별히 디자인된 시스템을 통해 제어됩니다.
데이터베이스 작업에 데이터베이스 서버 리소스를 자유롭게 사용할 수 있습니다.
이러한 이점은 그냥 얻어지는 것이 아닙니다. SharePoint Server 2013에 대해 RBS를 구현하려면 이러한 잠재적인 이점이 RBS의 구현 및 유지 관리에 따른 비용과 제한 사항보다 우위에 있는지 평가해야 합니다.
데이터 확장을 계획하는 방법에 대한 자세한 내용은 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2013)을 참조하세요.
안정성
안정성은 시간이 경과함에 따라 서버 팜의 용량이 설정된 대기 시간, 처리량 및 데이터 용량 목표를 충족할 수 있는지를 종합적으로 측정하는 지표입니다. 안정적인 팜이란 가동 시간, 응답성, 오류 비율, 대기 시간 급증 빈도와 폭이 설정된 목표 및 운영 요구 사항을 벗어나지 않는 팜을 말합니다. 최대 부하 및 사용량이 많은 시간 동안이나 크롤링 또는 일일 백업과 같은 시스템 작업이 수행되는 동안에도 대기 시간 및 처리량 목표를 일관되게 충족할 수 있는 팜도 안정적인 팜입니다.
안정성을 유지하는 주요 요인은 성능 목표를 충족하기 위한 일반적인 관리 작업의 결과에서 나옵니다. 데이터베이스 인덱스 다시 작성, 타이머 작업 유지 관리 또는 대량의 콘텐츠가 있는 여러 사이트 삭제와 같은 특정 작업이 수행되는 동안에는 시스템에서 사용자 요청을 신속하게 처리할 수 없을 수도 있으며 최종 사용자의 대기 시간 및 처리량에 영향을 줄 수 있습니다. 팜에서 받는 영향은 일상적이지 않은 이러한 작업이 수행되는 빈도와 트랜잭션 비용에 따라 달라지며 이러한 작업이 일반적인 작업 시간대에 실행되는지 여부에 따라서도 달라집니다.
다음은 시스템을 안정적으로 유지하기 위한 몇 가지 예입니다.
리소스를 많이 사용하는 타이머 작업 및 관리 작업은 사용량이 적은 시간에 수행되도록 예약합니다.
기존 팜 서버에서 하드웨어의 수를 늘려 수직 확장하거나 웹 서버, 응용 프로그램 서버 또는 데이터베이스 서버를 추가하여 수평 확장합니다.
리소스를 많이 사용하는 서비스 및 기능을 전용 서버에 배포합니다. 하드웨어 부하 분산 장치를 사용하여 특정 기능과 관련된 트래픽을 해당 기능 또는 서비스 전용의 웹 서버에서 처리하도록 합니다.
용량 관리와 용량 계획
용량 관리는 용량 계획의 개념을 확장하여 변화하는 조건 및 요구 사항을 수용하도록 SharePoint Server 2013 배포의 용량을 지속적으로 모니터링 및 최적화하는 순환적 접근 방식을 나타냅니다.
SharePoint Server 2013에서는 융통성이 더욱 개선되어 이전보다 다양한 규모의 사용 시나리오를 지원하도록 제품을 구성할 수 있습니다. 단일화된 배포 아키텍처가 없으므로 시스템 디자이너와 관리자는 특정 환경의 요구 사항을 정확하게 파악해야 합니다.
SharePoint Server 2013 용량 관리 모델
.png "용량 관리 모델")
1단계: 모델링 모델링이란 환경에서 지원하려는 주요 솔루션을 결정하고 중요한 모든 메트릭 및 매개 변수를 설정하는 프로세스입니다. 모델링 작업의 결과는 환경을 디자인하는 데 필요한 모든 핵심 데이터의 목록입니다.
예상 작업량 및 데이터 집합 파악
팜 성능 및 안정성 목표 설정
SharePoint Server 2013 IIS 로그를 분석합니다.
2단계: 디자인 1단계에서 데이터를 수집했으면 팜을 디자인할 수 있습니다. 디자인 작업의 결과는 자세한 데이터 아키텍처 및 물리적/논리적 토폴로지입니다.
시작 지점 아키텍처 결정
하드웨어 선택
3단계: 파일럿, 테스트 및 최적화 새 배포를 디자인했으면 해당 배포가 작업량 및 예상 사용 특성에 맞는지 테스트할 수 있도록 파일럿 환경을 배포해야 합니다. 기존 팜의 경우 인프라가 크게 변경되었으면 테스트가 권장되지만 성능 목표를 유지하려면 모니터링 결과에 바탕을 둔 정기적인 최적화가 필요할 수도 있습니다. 이 단계의 결과는 목표를 충족하는지 알아보기 위해 수행한 테스트 결과에 대한 분석과 설정된 성능 및 용량 목표를 유지할 수 있는 최적화된 아키텍처입니다.
파일럿 파일럿 환경 배포
테스트 대기 시간 및 처리량 목표를 충족하는지 테스트
최적화 테스트 결과 수집 및 팜 리소스와 토폴로지에 필요한 변경 수행
4단계: 배포 이 단계에서는 팜을 구현하거나 기존 팜에 변경 내용을 배포하는 것에 대해 설명합니다. 이 단계의 결과는 새 디자인의 경우 모든 콘텐츠 및 사용자 마이그레이션을 포함하여 운영 중인 프로덕션 환경에 대한 완전한 배포이고, 기존 팜의 경우 수정된 팜 맵과 유지 관리 계획에 대한 업데이트입니다.
5단계: 모니터링 및 유지 관리 이 단계에서는 모니터링을 설정하는 방법과 병목 현상을 예측 및 식별하고 정기적인 유지 관리 및 병목 현상 완화 작업을 수행하는 방법에 대해 설명합니다.
오버사이징과 언더사이징
오버사이징은 하드웨어를 100% 모두 사용하지 않고 목표를 달성하는 팜 디자인 접근 방식으로, 이 접근 방식에서는 SharePoint Server 2013 팜의 리소스가 꾸준하면서도 현저히 적게 사용됩니다. 오버사이징 배포에서는 메모리나 CPU 또는 팜의 리소스와 관련된 기타 표시기에서 현재보다 적은 리소스로도 요구 사항을 충족할 수 있음을 보여 줍니다. 오버사이징의 단점은 하드웨어 및 유지 관리 비용이 증가하고 전력 및 공간 수요량이 늘어날 수 있다는 점입니다.
언더사이징은 SharePoint Server 2013 팜의 하드웨어 리소스가 지나치게 많이 사용되어 성능 및 용량 목표를 달성할 수 없는 팜 디자인 접근 방식입니다. 팜 언더사이징은 하드웨어 비용을 절감할 목적으로 이따금씩 수행하지만, 일반적으로 대기 시간이 길어져 사용자 경험의 질이 저하되고 만족도가 낮아지며, 에스컬레이션 횟수가 잦아지고, 지원 비용이 늘어나며, 문제 해결 및 환경을 조정하는 데 불필요하게 추가 비용을 들여야 하는 결과가 야기됩니다.
팜을 디자인할 때는 정규적인 최대 부하 및 예기치 않은 사용량 급증 상태에서도 설정된 성능 및 용량 목표를 충족하도록 해야 합니다. 이를 위해 디자인, 테스트 및 최적화를 통해 팜의 하드웨어가 적절한지 확인할 수 있습니다.
성능 목표를 유지하고 늘어난 규모를 수용하려면 항상 목표를 충족하는 데 필요한 것보다 많은 리소스를 할당하는 것이 좋습니다. 일반적으로 하드웨어 과잉 투자로 야기되는 비용은 언더사이징으로 인한 문제 해결에 들어가는 누적 비용보다 훨씬 저렴합니다.
리소스 수요가 많은 시간대에 적절한 응답을 제공하도록 항상 시스템 크기를 조정해야 하며 이러한 리소스 수요는 시간대 또는 서비스마다 다를 수 있습니다. 용량 요구 사항을 효과적으로 예측하려면 모든 리소스에 대해 리소스 수요가 가장 많은 시간대를 파악해야 합니다. 오전에 근무 시간이 시작될 때 또는 점심 식사 후와 같은 하루 중 특정 시간대에 다양한 기능 및 서비스의 부하가 늘어날 수 있습니다.
팜은 조직 차원의 공지 사항이 발표되거나 평상시와 달리 다수의 사용자가 동시에 사이트에 액세스하는 경우 등의 계획되지 않은 사용량 급증도 지원할 수 있어야 합니다. 리소스 수요가 많은 시간대에 팜의 늘어난 부하를 감당하기에 충분한 팜 리소스가 없으면 사용자의 대기 시간이 길어지거나 팜으로부터 전혀 응답을 받지 못하게 됩니다.
조직에 사용자가 추가될 경우 팜 용량을 다시 검토해야 합니다. 인수, 합병 등으로 인해 새로운 직원이나 구성원이 팜에 액세스하게 되는 경우 이러한 상황을 사전에 예측하고 그에 대한 계획을 세우지 않으면 성능에 좋지 않은 영향을 줄 수 있습니다.
운영 상태: 안전 영역 및 위험 영역
프로덕션 시스템의 부하에 대해 설명할 때는 두 가지 주요 운영 상태를 언급하지 않을 수 없습니다. 하나는 정상적이고 예상되는 부하 범위에서 시스템이 운영되는 "안전 영역" 상태이고 다른 하나는 팜의 리소스 수요가 일시적으로 매우 높아 얼마 지나지 않아 오류와 기타 성능 및 안정성 문제가 발생하게 되는 "위험 영역" 상태입니다.
안전 영역 팜이나 서버가 정상적인 부하 상태에서 예상 일일 최대 부하 한도 내로 운영되는 상태입니다. 이 범위에서 운영되는 팜은 응답 시간 및 대기 시간을 허용 가능한 매개 변수 내에서 유지할 수 있습니다.
위험 영역 부하가 정상적인 최대 부하보다 높지만 제한된 기간 동안 요청을 처리할 수 있는 운영 범위입니다. 이 상태는 대기 시간이 정상적인 대기 시간보다 길고 시스템 병목 현상의 영향으로 오류가 발생하는 것이 특징입니다.
팜 디자인의 궁극적인 목표는 서비스 오류 없이 적절한 대기 시간 및 처리량 목표 내에서 위험 영역 부하를 일관되게 지원할 수 있는 환경을 배포하는 것입니다.
소프트웨어 제한 및 경계
SharePoint Server 2013에는 원래부터 초과할 수 없도록 만들어진 특정 제한과 기본값으로 설정되어 있지만 관리자가 변경할 수 있는 제한이 있습니다. 또한 웹 응용 프로그램당 사이트 모음 수 같은 구성 가능한 값으로 나타나지 않는 특정 제한도 있습니다.
경계는 원래부터 초과할 수 없는 절대 제한입니다. 팜을 디자인할 때 잘못된 가정을 세우지 않으려면 이러한 제한을 반드시 이해하고 있어야 합니다.
경계의 예로는 2GB의 문서 크기 제한을 들 수 있습니다. 용량이 2GB가 넘는 문서를 저장하도록 SharePoint Server 2013을 구성할 수는 없습니다. 이는 기본적으로 설정되는 절대값이며 원래부터 초과할 수 없도록 만들어졌습니다.
임계값은 해당 값을 변경할 때까지는 초과할 수 없는 기본값이 지정된 제한입니다. 특정한 상황에서는 팜 디자인의 변동을 수용하도록 임계값을 초과할 수도 있지만 이렇게 하면 다른 제한의 유효 값을 포함하여 팜의 성능에 영향을 줄 수 있다는 점에 유의해야 합니다.
특정 임계값의 기본값은 절대 최대값까지만 초과할 수 있습니다. 이에 대한 좋은 예로는 문서 크기 제한이 있습니다. 문서 크기 제한은 기본적으로 50MB로 설정되지만 최대값인 2GB로 변경할 수 있습니다.
지원되는 제한은 지정된 매개 변수에 대해 테스트된 값을 정의합니다. 테스트를 통해 정해진 이러한 제한의 기본값은 제품의 알려진 제한을 나타냅니다. 지원되는 제한을 초과하면 예기치 못한 결과, 대폭적인 성능 저하 또는 그 밖의 좋지 않은 영향이 발생할 수 있습니다.
지원되는 제한 중 일부는 권장되는 값으로 기본 설정된 구성 가능한 매개 변수지만 일부는 구성 가능한 값으로 나타나지 않는 매개 변수와 관련이 있습니다.
지원되는 제한의 예로는 웹 응용 프로그램당 사이트 모음 수가 있습니다. 지원되는 제한은 테스트 시 성능 벤치마크를 충족한 가장 큰 웹 응용 프로그램당 사이트 모음 수입니다.
이 문서에 나와 있는 많은 제한 값은 해당 값이 증가함에 따라 늘어나는 리소스 부하와 그에 따른 성능 저하를 설명하는 전체의 한 요소를 나타낸다는 점을 이해해야 합니다. 따라서 웹 응용 프로그램당 사이트 모음 수 같은 특정 제한을 초과하더라도 팜 성능은 일부만 저하될 수 있습니다. 하지만 대부분의 경우 팜의 디자인에서 제한 값이 적당한 균형을 이루고 있어야 적절한 성능 및 안정성 목표를 가장 효과적으로 달성하게 되므로 설정된 제한으로 또는 이러한 제한 가까이로 작동하는 것은 최상의 방법이 아닙니다.
임계값 및 지원되는 제한에 대한 지침은 성능에 따라 결정됩니다. 즉, 제한의 기본값을 초과할 수 있지만 제한 값을 늘림에 따라 팜 성능 및 다른 제한의 유효 값이 영향을 받을 수 있습니다. SharePoint Server 2013의 많은 제한은 변경할 수 있지만 특정 제한을 변경할 경우 팜의 다른 부분에 어떤 영향이 발생하는지를 이해하고 있어야 합니다.
SharePoint 2013의 하드웨어 및 소프트웨어 요구 사항에 설명된 대로 게시된 최소 하드웨어 사양을 충족하지 않는 프로덕션 시스템에 관해 Microsoft 고객 지원 서비스에 문의할 경우 최소 요구 사항을 충족하도록 시스템을 업그레이드할 때까지 지원이 제한됩니다.
제한 설정 방법
SharePoint Server 2013의 경우 팜 서비스 및 작동이 해당 유효 작동 제한에 도달하는 지점까지 부하를 늘리면서 팜의 동작을 테스트 및 관찰하는 방식으로 임계값 및 지원되는 제한이 설정됩니다. 일부 팜 서비스 및 구성 요소는 다른 팜 서비스 및 구성 요소보다 큰 부하를 지원할 수 있으므로 경우에 따라 여러 요소의 평균을 토대로 제한 값을 할당해야 합니다.
예를 들어 사이트 모음이 추가될 때 부하가 발생하는 상황에서 팜의 동작을 관찰하면 일부 기능은 대기 시간이 너무 길어지는 반면 일부 기능은 여전히 적절한 매개 변수 범위 내에서 작동하는 것으로 나타납니다. 따라서 사이트 모음 수에 할당되는 최대값은 절대적인 수치는 아니며 대부분의 상황에서 지정된 제한으로 전체 팜 성능이 적절하게 유지되는 일련의 예상 사용 특성을 토대로 계산됩니다.
일부 서비스가 제한 테스트에 사용된 것보다 큰 매개 변수로 작동하는 경우에는 다른 서비스의 최대 유효 제한이 줄어들게 됩니다. 따라서 해당 환경에 실제로 적용되는 제한을 설정하려면 특정 배포에 맞게 용량 관리 및 규모 테스트를 엄격하게 실행해야 합니다.
경계 및 제한에 대한 자세한 내용과 이러한 두 요소가 용량 관리 프로세스에 어떤 영향을 주는지에 대한 자세한 내용은 SharePoint 2013의 소프트웨어 경계 및 제한 사항을 참조하십시오.
SharePoint Server 2013 배포의 주요 차이점
각 SharePoint Server 2013 배포에는 다른 팜과는 고유하게 구별되는 몇 가지 두드러진 특성이 있습니다. 이러한 차이점은 다음과 같은 네 가지 주요 범주로 나눌 수 있습니다.
사양 팜의 하드웨어, 팜 토폴로지 및 구성을 설명합니다.
작업량 사용자 수 및 사용 특성을 포함하여 팜에 대한 수요를 설명합니다.
데이터 집합 콘텐츠 크기 및 배포를 설명합니다.
상태 및 성능 대기 시간 및 처리량 목표 대비 팜의 성능을 설명합니다.
사양
하드웨어
하드웨어는 프로세서, 메모리, 하드 디스크 등 컴퓨터의 물리적 리소스입니다. NIC(네트워크 인터페이스 카드), 케이블, 스위치, 라우터 및 하드웨어 부하 분산 장치와 같은 물리적 네트워크 구성 요소도 하드웨어에 포함됩니다. 대부분의 성능 및 용량 문제는 적절한 하드웨어를 사용하면 해결할 수 있지만 서버의 메모리 부족과 같이 한 가지 하드웨어 리소스라도 잘못 적용된 경우에는 전체 팜의 성능에 영향을 줄 수 있습니다.
토폴로지
토폴로지는 팜의 하드웨어 및 구성 요소가 배포된 방식 및 이들 간의 상호 관계입니다. 토폴로지의 유형에는 다음과 같은 두 가지가 있습니다.
논리적 토폴로지 팜의 서비스 및 기능과 같은 소프트웨어 구성 요소의 맵입니다.
물리적 토폴로지 서버 및 물리적 리소스의 맵입니다.
일반적으로 사용자 수 및 사용 특성에 따라 팜의 물리적 토폴로지가 결정되고, 예상되는 부하를 감당하기 위해 특정 기능을 지원할 필요가 있는지와 같은 비즈니스 요구 사항에 따라 논리적 토폴로지가 결정됩니다.
구성
구성은 소프트웨어 설정 및 매개 변수 설정 방식을 설명하는 데 사용됩니다. 또한 구성은 캐싱, RBS, 구성 가능한 제한을 설정하는 방식, 특정 요구 사항을 충족하도록 설정 또는 수정할 수 있는 소프트웨어 환경의 일부를 나타내기도 합니다.
작업량
작업량은 사용자층, 동시성, 사용 중인 기능, 팜에 연결하는 데 사용되는 사용자 에이전트 또는 클라이언트 응용 프로그램을 포함하여 팜의 주요 운영 특성을 정의합니다.
SharePoint Server 2013 기능마다 팜의 리소스에 주는 영향은 제각기 다릅니다. 리소스를 많이 사용하는 기능이 많을수록 시스템의 성능과 상태에 많은 영향을 줄 수 있습니다. 예상되는 수요 및 사용 특성을 올바르게 이해하면 구현의 적절한 규모를 결정할 수 있으며 지속적으로 불안정한 상태에서 시스템을 실행하는 위험을 줄일 수 있습니다.
사용자층
SharePoint Server 2013 기반 응용 프로그램의 사용자층은 총 사용자 수와 이들 사용자가 지리적으로 분산되어 있는 방식을 의미합니다. 또한 총 사용자층 내에는 특정 기능이나 서비스를 다른 그룹보다 많이 사용할 수 있는 하위 사용자 그룹이 있습니다. 사용자 동시성은 특정 시간에 시스템을 사용 중인 사용자의 총 비율로 정의할 수 있습니다. 사용자층을 정의하는 표시기로는 총 고유 사용자 수와 동시 사용자 수가 있습니다.
사용 특성
팜의 성능은 시스템과 상호 작용하는 사용자의 수뿐만 아니라 사용자의 사용 특성에 따라서도 영향을 받을 수 있습니다. 두 조직의 사용자 수가 같더라도 사용자가 팜 리소스에 액세스하는 횟수, 리소스를 많이 사용하는 기능이나 서비스가 팜에서 활성화되어 있는지 여부 등에 따라 요구 사항은 크게 달라질 수 있습니다. 사용 특성을 설명하는 표시기로는 고유 작업의 빈도, 전반적인 운영 작업 혼합률(읽기/쓰기 작업과 관리 작업의 비율), 사용 패턴, 팜에서 활성화되어 있는 새 기능(예: 내 사이트, 검색, 워크플로 및 Office Web Apps)으로 인한 부하가 있습니다.
데이터 집합
시스템에 저장된 콘텐츠의 양과 콘텐츠가 저장되는 아키텍처의 특성은 시스템의 전반적인 상태 및 성능에 많은 영향을 줄 수 있습니다. 데이터의 크기나 데이터 액세스 빈도 및 데이터가 배포된 방식을 올바르게 이해하면 시스템의 저장소 크기를 적절히 조정하고 병목 현상으로 인한 팜 서비스와의 사용자 상호 작용이 느려지지 않도록 하고 최종 사용자 환경의 질이 저하되지 않도록 할 수 있습니다.
SharePoint Server 2013 기반 솔루션의 저장소 아키텍처를 올바르게 예상하고 디자인하려면 시스템에 저장할 데이터의 양과 다양한 데이터 원본에서 데이터를 요청하는 사용자의 수를 알고 있어야 합니다. 콘텐츠의 양은 다른 기능에 영향을 줄 수 있으며 네트워크 대기 시간 및 가용 대역폭에도 영향을 줄 수 있으므로 디스크 용량을 결정하는 데 매우 중요한 요소입니다. 데이터 집합을 정의하는 표시기로는 총 콘텐츠 크기, 총 문서 수, 총 사이트 모음 수, 평균 및 최대 사이트 모음 크기가 있습니다.
상태 및 성능
SharePoint Server 2013 팜의 상태는 기본적으로 시스템의 안정성과 성능을 측정하거나 점수로 매겨 놓은 단순한 측정치입니다. 팜의 성능이 목표에 얼마나 근접해 있는지는 기본적으로 앞의 세 가지 차이점에 따라 결정됩니다. 상태 및 성능 점수는 선별된 일련의 표시기를 통해 추적하고 설명할 수 있습니다. 자세한 내용은 SharePoint Server 2013 모니터링 및 유지 관리 및 SharePoint 2013의 모니터링 계획을 참조하세요. 이러한 표시기로는 시스템 가동 시간, 최종 사용자가 인지하는 대기 시간, 페이지 오류 비율 및 리소스 사용률 표시기(CPU, RAM)가 있습니다.
하드웨어, 토폴로지, 구성, 작업량 또는 데이터 집합이 크게 변경되면 시스템의 안정성과 응답 성능이 대폭 달라질 수 있습니다. 상태 점수를 사용하여 시간의 경과에 따른 성능을 추적하고 변화하는 운영 조건이나 시스템 수정 사항이 팜의 안정성에 어떤 영향을 주는지 평가할 수 있습니다.
참조 아키텍처
SharePoint Server 2013은 복잡하고 강력한 제품이지만 모든 요구 사항을 해결하는 완벽한 아키텍처 솔루션은 없습니다. 각 SharePoint Server 2013 배포는 저마다 고유하며 배포의 사용 특성 및 데이터 특성으로 정의됩니다. 모든 조직은 철저한 용량 관리 프로세스를 수행하고 SharePoint Server 2013 시스템에서 제공하는 유연함을 효과적으로 활용하여 조직의 요구 사항을 가장 잘 충족하는 적절한 크기의 솔루션을 사용자 지정해야 합니다.
참조 아키텍처라는 개념은 다양한 주요 SharePoint Server 2013 배포 범주를 보여 주고 이에 대해 설명하기 위해 제공된 것일 뿐 설계자가 솔루션을 디자인하는 데 반드시 따라야 할 지침을 제공하는 것은 아닙니다. 이 섹션에서는 SharePoint Server 2013 배포에서 일반적으로 확장하는 벡터에 대해 중점적으로 설명합니다.
여기에 나오는 아키텍처는 이러한 일반 범주 간의 보편적인 차이점을 손쉽게 이해하고 일반 비용 요소와 작업 범위를 기준으로 각 아키텍처를 간편하게 구별할 수 있도록 제공된 것입니다.
단일 서버 배포
단일 서버 배포 아키텍처는 SharePoint Server 2013을 실행하는 서버 한 대와 지원되는 SQL Server 버전 하나로 이루어집니다. 이 아키텍처는 평가용으로나 개발자에게 적합하며 사용자가 소수이고 중요한 업무를 맡고 있지 않은 격리된 부서를 구현하는 경우에도 적합합니다. 하지만 프로덕션 환경에는 사용하지 않는 것이 좋습니다.
.gif "단일 서버 배포 모델")
소규모 팜 배포
소규모 팜 배포는 데이터베이스 서버 한 대와 SharePoint Server 2013 기반 컴퓨터 한 대 이상으로 이루어집니다. 이 아키텍처의 주요 특성으로는 제한된 중복과 장애 조치 및 최소한의 SharePoint Server 2013 기능 사용이 있습니다.
소규모 팜은 최소한의 서비스 응용 프로그램만 사용하고 사용자층이 상대적으로 작으며 사용 부하가 비교적 낮고(분당 요청 수가 적거나 초당 요청 수가 매우 적음) 데이터의 양이 상대적으로 적은(10GB 이상) 제한된 배포에 유용합니다.
.gif "소규모 팜 배포 모델")
중간 규모 팜 배포
이 아키텍처에서는 토폴로지를 전용 웹 서버, 전용 응용 프로그램 서버, 하나 이상의 데이터베이스 서버 클러스터라는 세 개의 계층으로 나눕니다. 프런트 엔드 서버 계층을 응용 프로그램 서버 계층과 분리함으로써 서비스를 더 유연하게 격리하고 시스템 간에 부하를 고르게 분산합니다.
가장 일반적인 아키텍처이며 광범위한 서비스 토폴로지 및 팜 크기가 포함됩니다. 중간 규모 팜 배포는 다음 요소를 포함하는 환경에 유용합니다.
여러 서버에 배포된 여러 서비스 응용 프로그램. 일반적인 기능으로는 Office Web Apps 서비스, User Profile Service, Managed Metadata Service 및 Excel Calculation Service가 있습니다.
수만 명의 사용자층과 초당 10~50개의 요청에 해당하는 부하
1~2TB의 데이터 저장소
.gif "용량 - 중간 규모 팜 배포 모델")
대규모 팜 배포
대규모 팜 배포에서는 서비스와 솔루션을 여러 팜에 나누고 단일 팜에서 계층을 추가로 수평 확장합니다. 여러 SharePoint Server 2013 서비스를 전용 서비스 팜에 배포하여 해당 서비스를 사용하는 여러 팜의 요청을 처리할 수 있습니다. 이러한 대규모 아키텍처에는 일반적으로 각 로컬(비공유) 서비스의 사용 특성에 따라 웹 서버와 응용 프로그램 서버가 여러 대 있으며, 팜에서 사용하는 응용 프로그램 서비스 데이터베이스 및 콘텐츠 크기에 따라 SQL Server 기반 서버 또는 SQL Server 클러스터가 여러 개 있습니다. 대규모 팜 아키텍처는 다음 요소를 포함하는 배포에 적합합니다.
연결되어 전용 서비스 팜에서 사용되는 몇 가지 서비스 응용 프로그램. 일반적으로 User Profile Service, Search Service, Managed Metadata Service 및 Web Analytics 등의 서비스 응용 프로그램이 여기에 해당합니다.
대부분의 다른 서비스 응용 프로그램은 로컬에서 사용됩니다.
사용자층 수십만 명
초당 수백 개의 요청에 해당하는 사용 부하
10TB 이상의 데이터 집합
.gif "용량 - 대규모 팜 배포 모델")
참고 항목
SharePoint Server 2013에 대한 용량 계획
SharePoint Server 2013의 성능 테스트
SharePoint Server 2013 모니터링 및 유지 관리
SharePoint 2013의 모니터링 계획
SharePoint 2013의 소프트웨어 경계 및 제한 사항
성능 및 용량 테스트 결과 및 권장 사항(SharePoint Server 2013)
SharePoint 2013의 하드웨어 및 소프트웨어 요구 사항
성능 및 용량 기술 사례 연구 (SharePoint Server 2010)
https://msdn.microsoft.com/ko-kr/library/cc262485(v=office.15)