SharePoint 2010: SharePoint Workspace 저장소 최적화
오프라인 상태인 경우에도 SharePoint에서 작업할 수 있습니다. SharePoint Workspace 저장소 아키텍처를 최적화하는 방법을 알아봅니다.
Brien Posey
SharePoint에 항상 연결할 수 있는 것은 아닙니다. SharePoint Workspace 2010은 연결할 수 없는 경우를 위해 오프라인으로 작업하더라도 SharePoint 데이터를 사용할 수 있도록 해주고 있습니다. 그러나 기본 저장소 아키텍처에는 몇 가지 성능 문제가 있습니다. 이러한 문제가 발생하는 이유와 문제를 해결하는 방법을 알아보겠습니다.
SharePoint Workspace는 작업 영역 데이터를 저장하는 데 사용되는 저장소 공간입니다. 클라이언트 소프트웨어도 SharePoint Workspace라고 하는데 여기에서는 SPW 2010이라고 하겠습니다. 이러한 용어의 의미를 염두에 두면 SharePoint Workspace를 Microsoft Groove 작업 영역과 비슷한 개념으로 생각할 수 있습니다.
기본적인 개념은 전체 또는 부분 SharePoint 문서 라이브러리를 로컬 컴퓨터의 SharePoint Workspace로 동기화할 수 있도록 한다는 것입니다. 이 방법을 통해 오프라인으로 작업하는 동안에도 라이브러리의 내용을 이용할 수 있습니다. 실제 동기화는 라이브러리 콘텐츠에 대한 동기화를 설정하고 유지 관리하는 클라이언트 구성 요소인 SPW 2010을 사용하여 수행합니다.
최적화의 이유
SharePoint 문서를 동기화하면 문서 자체가 로컬 Office 문서 캐시에 저장됩니다. 연결된 목록, InfoPath 양식, 스키마 및 뷰는 실제 SharePoint Workspace에 저장됩니다. 동기화해야 하는 문서가 많지 않다면 이 아키텍처는 상당히 잘 작동합니다. 그러나 동기화하는 문서의 수가 증가하면 문제가 발생할 수 있습니다.
Microsoft에 따르면 SPW 2010은 동기화하는 문서가 500개 이하일 때 최적으로 작동합니다. 500개 이상의 문서를 동기화하려고 하면 문서 동기화 작업 부하가 증가함에 따라 SPW 2010 성능이 저하될 수 있다는 경고 메시지가 표시됩니다.
1,800개 이상의 문서를 동기화하려고 하면 SPW 2010은 모든 문서를 동기화하는 것을 포기합니다. 대신 문서 메타데이터만 SharePoint Workspace로 다운로드하고 이러한 문서 중 하나를 열려고 하면 즉석에서 해당 문서를 동기화합니다.
SPW 2010에서 전체 문서를 동기화하는 것보다 문서 메타데이터만 다운로드하는 것이 더 효율적이라면 SPW 2010에서 항상 이렇게 하지 않는 이유는 무엇일까요? SPW 2010을 사용하는 이유가 오프라인 중에도 SharePoint 데이터를 사용하기 위한 것이기 때문입니다. 메타데이터만 가지고는 문서를 대상으로 작업하기가 어렵습니다.
Workspace 저장소 최적화
현재로서 이러한 제한을 해결하는 방법은 두 가지 뿐입니다. 하나는 SharePoint Workspace 대신 Groove 작업 영역을 만드는 것입니다. Microsoft에 따르면 동기화에 대한 이러한 제한은 Office 문서 캐시에만 적용되며 Groove 작업 영역(SPW 2010에서 만들고 액세스 가능)에는 적용되지 않습니다.
SPW 2010 동기화에 대한 제한을 해결하는 다른 옵션은 동기화하는 문서의 수를 줄이는 것입니다. 이를 위한 몇 가지 다른 방법이 있습니다.
한 가지는 사용하지 않는 작업 영역을 제거하는 것입니다. 동기화 프로세스의 효율성은 모든 작업 영역에 있는 전체 문서 수에 따라 좌우됩니다. 각각 문서 100개를 포함하는 작업 영역 10개가 있다면 각 작업 영역이 500개 문서 임계값을 초과하지 않더라도 SPW 2010에서는 여전히 1,000개의 문서를 동기화해야 합니다.
SPW 2010은 라이브러리 또는 라이브러리 내의 폴더에 대한 각각의 연결에 대해 새로운 작업 영역을 만듭니다. 시간이 지나면 더 이상 사용하지 않는 작업 영역들이 누적됩니다. 이러한 작업 영역을 제거하는 것은 SPW 2010이 동기화해야 하는 문서 수를 줄이는 훌륭한 방법입니다.
모든 문서를 캐싱할 필요가 있는지도 고려해 보아야 합니다. 대부분의 모바일 사용자는 이동 중에 SharePoint 데이터를 오프라인으로 액세스할 수 있다는 것에 만족할 것입니다. 그러나 이들이 실제 필요로 하는 문서는 한정된 문서인 경우가 많습니다. 다른 문서들도 오프라인으로 이용할 수 있다면 좋겠지만 반드시 필요한 것은 아닙니다. 캐시되는 문서의 수를 줄임으로써 성능 문제를 해결할 수 있습니다.
사용자의 환경을 개선할 수 있는 다른 방법은 사용자에게 전체 SharePoint 문서 라이브러리 대신 개별 폴더를 동기화하는 방법을 알려주는 것입니다. SharePoint 작업 영역을 만들 때 SPW 2010은 동기화하려는 문서 라이브러리와 연결된 URL을 묻습니다. URL에 파일 경로를 추가할 수 있습니다.
예를 들어 서버의 공유 문서 라이브러리에 Finance, Marketing 및 HR이라는 폴더가 포함되어 있고, 사용자가 금융 관련 업무를 한다면 자신과 관련이 없는 전체 문서 라이브러리를 동기화할 필요가 없습니다. 실제로는 이러한 폴더에 액세스할 수도 없는 것이 보통입니다.
문서 라이브러리에 연결된 작업 영역을 만들려면 https://SharePoint/Shared%20Documents/Finance과 같은 URL을 사용하면 됩니다. 이렇게 하면 Finance 폴더와 하위 폴더에 있는 내용만 포함하는 작업 영역을 만들 수 있습니다. 다른 병렬 폴더(HR 및 Marketing)는 포함되지 않으며 Shared Documents 폴더에 있는 다른 문서들도 포함되지 않습니다.
문제를 해결할 때는 클라이언트 쪽부터 살펴보는 것이 좋습니다. SPW 2010 환경의 성능 저하는 500개 문서 임계값을 초과하면 발생하는 것이므로 클라이언트 쪽 저장소를 최적화하는 것이 문제 해결에 유리합니다. 그러나 클라이언트 쪽 최적화는 절반의 해결책에 불과합니다. 성능 문제를 경험하는 곳은 SPW 2010이 될 가능성이 훨씬 높지만, 과도한 동기화 요청 때문에 SharePoint 서버 성능이 저하될 수도 있습니다.
SQL Server 모니터링
SharePoint는 SQL Server 데이터베이스에 사이트 콘텐츠를 저장합니다. 따라서 SharePoint 저장소 아키텍처를 최적화하려면 SQL Server에 초점을 맞추어야 합니다. 고맙게도 Microsoft에서는 SQL Server에 사용할 수 있는 몇 가지 성능 모니터를 제공합니다.
이러한 목표 값은 SharePoint 2010에 의해 사용되는 SQL Server 2008 또는 SQL Server 2008 R2에 적용됩니다. 카운터 값은 다른 유형의 SQL 데이터베이스에 반드시 적용되는 것은 아닙니다.
Microsoft에서는 General Statistics \ User Connections 카운터를 주시할 것을 권장하고 있습니다. 이 카운터는 SQL Server에 대한 사용자 연결 수를 보여 줍니다. 이 값을 주시하도록 권장하는 이유는 카운터가 기준 값의 500%를 초과하기 시작하면 성능 문제가 발생할 수 있기 때문입니다.
다른 카운터로 Databases \ Transactions / Sec 카운터가 있습니다. 이 카운터에 대해서는 구체적으로 권장되는 값을 제시하고 있지 않지만 서버가 정상 상태일 때 값을 기록해 두기를 권장하고 있습니다. 그러면 성능 문제가 발생했을 때 초당 트랜잭션의 수를 이전에 기록한 기준 값과 비교할 수 있습니다.
서버 잠금을 모니터링하는 것도 SQL Server가 얼마나 잘 작동하고 있는지 알 수 있는 한 방법입니다. 모니터링을 고려할 만한 몇 가지 다른 잠금 관련 카운터가 있지만, 가장 유용한 것에는 Locks \ Lock Waits / Sec이 있습니다. 이 카운터는 즉시 수행할 수 없는 초당 잠금 요청의 수를 보여 줍니다.
잠금이 즉시 수행되지 않는 경우 Locks \ Average Wait Time (ms) 카운터를 모니터링하십시오. 이 값을 통해 잠금을 수행하기 위한 평균 대기 시간을 알 수 있습니다. 이 값이 지속적으로 상승한다면 SQL Server에 성능 문제가 발생하고 있는 것입니다.
잠금을 모니터링하여 SQL 데이터베이스가 잘 작동하는지 알 수 있는 것처럼, 래치를 모니터링해도 성능 상황을 파악할 수 있습니다. 주시해야 할 래치 관련 카운터로는 Latches \ Latch Waits / Sec 및 Latches \ Average Latch Wait Time이 있습니다. 초당 대기 횟수가 지속적으로 증가하는지 확인하면 됩니다.
대기 시간이 과도하지 않은지 여부도 주시해야 합니다. 서버가 정상적으로 작동할 때 기준 값을 기록해 두면 향후 문제가 발생할 때 비교할 수 있어 유용합니다.
마지막으로 확인할 사항은 SQL Server가 사용자 쿼리를 처리하는 속도입니다. SQL Statistics \ Compilations / Sec 및 SQL Statistics \ Re-Compilations / Sec 카운터에서 초당 컴파일 횟수 및 재컴파일 횟수를 확인하십시오.
이러한 마지막 두 카운터는 서버가 정상적으로 작동할 때의 기준 값을 설정하는 데 사용하는 경우가 아니라면 의미가 없습니다. 그 다음에는 컴파일 또는 재컴파일되는 쿼리 수를 모니터링할 수 있습니다. 해당하는 사용자 부하가 감소하지 않는 상태에서 이러한 값이 감소한다면 SQL Server가 사용자 요청을 수행하는 데 문제가 있다는 의미입니다.
성능 모니터는 SQL Server의 전체 성능을 측정하는 데 사용할 수 있는 모든 정규화된 SQL Server 카운터입니다. 성능 문제가 발견된 경우 하드웨어 관련 카운터를 사용하여 문제를 더 세부적으로 진단할 수 있습니다.
.jpg)
Brien Posey는 Microsoft MVP이며 수천 건의 기사와 수십 권의 서적을 집필한 기술 관련 프리랜서 작가입니다. 문의 사항이 있으면 Brien의 웹 사이트인 brienposey.com을 방문해 보십시오.