WAN 환경용으로 BLOB 캐싱 최적화(SharePoint Server 2010)

적용 대상: SharePoint Server 2010

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

이 문서에서는 WAN 환경에 대해 Microsoft SharePoint 2010 제품에서 BLOB 캐싱을 사용하는 방법에 대해 설명합니다.

캐싱은 보통 서버에서 요청을 수신한 시간부터 응답이 클라이언트 컴퓨터로 다시 스트리밍되는 시간까지 렌더링 파이프라인의 처리량을 높이기 위한 방법으로 수행됩니다. 이러한 캐싱의 용도도 전체 사이트 성능에 있어서 중요한 측면이기는 하지만, 이 섹션에서는 다음과 관련한 캐싱에 대해 중점적으로 설명합니다.

• 클라이언트 캐싱에 대한 서버 구성의 역할

• 서버에서 클라이언트로 네트워크를 통해 전송되는 항목의 크기 제어

BLOB 캐시

BLOB 캐시는 SharePoint Server 2010 게시 기능을 통해서만 사용 가능한 메커니즘입니다. 따라서 공동 작업 포털 사이트 서식 파일을 기반으로 하는 회사 포털 사이트와, 게시 포털 사이트 서식 파일을 기반으로 하는 인터넷 연결 사이트에 사용하기에 적합합니다. BLOB 캐시를 통해 게시 사이트 목록에서 제공되는 항목(예: 페이지 라이브러리 및 사이트 모음 이미지)에 연결된 캐싱 지시문을 구성할 수 있습니다. 클라이언트 컴퓨터의 브라우저는 캐싱 지시문을 발견하면 검색 중인 항목을 로컬로 저장할 수 있으며 캐싱 지시문이 만료될 때까지 해당 항목을 다시 요청할 필요가 없음을 인식합니다. 지리적으로 분산된 환경에서는 이 기능을 통해 요청하고 네트워크를 통해 보내는 항목의 수를 줄일 수 있으므로 유용합니다.

SharePoint Server 2010에서 BLOB 캐시를 설정하면 두 가지 작업이 수행됩니다. 먼저, 캐시 가능한 항목을 요청할 때마다 SharePoint Server 2010에서 요청을 수신한 웹 서버의 하드 디스크 드라이브를 검색하여 로컬에 복사본이 있는지를 확인합니다. 복사본이 있는 경우 파일이 로컬 디스크에서 사용자에게 직접 스트리밍됩니다. 로컬 디스크에 복사본이 없으면 항목이 있는 SQL 데이터베이스에서 항목 복사본이 작성된 다음 요청을 한 사용자에게 항목이 전송됩니다. 그 이후에는 항목의 캐시 가능성 값이 캐시가 만료되었음을 나타낼 때까지 해당 항목에 대한 모든 요청이 웹 서버에서 직접 처리됩니다. 따라서 데이터베이스 서버의 경합이 줄어들어 서버 팜의 성능이 향상됩니다.

BLOB 캐시를 설정하는 또 다른 이유는 항목을 클라이언트로 전송할 때 항목에 캐시 가능성 헤더를 추가하기 위해서입니다. 이 헤더는 항목을 캐시할 기간을 브라우저에 지시합니다. 예를 들어 사진의 캐시 가능성 값이 3일인 경우 브라우저에서는 다음 3일 이내에 해당 사진에 대한 요청을 다시 받는 경우 로컬 캐시의 이미지 복사본을 사용하며 서버에서 사진을 다시 요청하지 않습니다.

Fiddler를 사용하여 BLOB 캐시 관련 데이터 수집

사이트를 테스트하여 캐시되는 항목 및 항목을 캐시하는 방법을 확인할 때는 Fiddler(영문일 수 있음)(http://www.fiddlertool.com)라는 무료 디버깅 응용 프로그램을 사용할 수 있습니다. 아래 스크린샷은 게시에 사용되는 간단한 SharePoint 사이트의 Fiddler를 캡처한 것입니다. 이 사이트는 기본 공동 작업 포털 사이트 서식 파일을 사용하여 작성되었습니다. 페이지에는 일부 텍스트 콘텐츠가 더 추가되었으며 마스터 페이지에 여러 개의 이미지가 추가되었습니다.

Fiddler 응용 프로그램에는 다음과 같은 여러 가지 중요한 정보가 포함되어 있습니다.

• 왼쪽의 # 열은 페이지 렌더링을 위해 브라우저에서 서버로 수행된 HTTP 요청이 총 44개 있음을 나타냅니다.

• Result(결과) 열에는 항목에 대한 요청에서 반환된 HTTP 결과 코드가 표시됩니다. 결과가 200이면 항목이 성공적으로 검색된 것입니다.

• URL 열에는 요청했던 특정 항목이 나와 있습니다.

• Body(본문) 열에는 각 항목의 크기가 표시됩니다.

• Caching(캐싱) 열에는 각 항목에 연결된 캐싱 지시문이 표시됩니다. Caching(캐싱) 열의 데이터는 여러 항목에 캐싱 지시문이 연결되어 있음을 보여 줍니다(항목의 max-age 특성이 0보다 큼). 캐싱 지시문은 초 단위로 표현됩니다. 즉, 위에 표시된 페이지의 경우 여러 항목이 365일(1분=60초, 1시간=60분, 1일=24시간이므로 60x60x24=86,400x365=31,536,000초) 동안 캐시되도록 구성되어 있음을 보여 줍니다.

해당 캐시 지시문을 포함하는 항목은 모두 _layouts 디렉터리에 있습니다. 항목에 이러한 캐시 설정이 포함된 이유는 _layouts/images 가상 디렉터리가 IIS에서 구성되는 방식 때문입니다. 새 웹 응용 프로그램을 만들 때 SharePoint Server 2010에서는 웹 서버 실제 디스크의 폴더에 매핑되는 여러 가상 디렉터리를 자동으로 만들며, _layouts/images 가상 디렉터리를 만들 때는 전체 디렉터리에 적용되는 캐싱 지시문을 추가합니다. 아래 스크린샷에서 IIS 관리자 스냅인의 디렉터리에 대한 구성을 확인할 수 있습니다.

이러한 항목에 연결된 캐싱 지시문은 모두 0이 아니므로, 다음 번에 페이지를 요청하면 브라우저에서 해당 항목을 서버에 다시 요청하는 대신 로컬 브라우저 캐시의 항목 복사본을 사용합니다. 아래 스크린샷에서는 페이지를 두 번째로 요청했을 때의 Fiddler 스냅숏을 보여 줍니다.

위의 Fiddler 데이터에서 보시다시피, 요청된 항목 수가 44개에서 11개로 크게 줄었습니다. 여기서 기억해야 할 점은, 페이지를 요청하는 방법에 따라 요청 횟수가 달라질 수 있다는 것입니다. 브라우저에서 새로 고침 단추를 사용하는 경우에는 항목의 캐시된 로컬 버전 유무에 관계없이 모든 항목을 다시 요청할 가능성이 높습니다. 반대로, 링크나 바로 가기를 사용하여 페이지를 방문하는 방법으로 요청하는 경우에는 캐시되지 않은 항목만 요청합니다.

Fiddler 데이터에서 확인할 수 있는 또 다른 사항은, 브라우저가 이미 로컬 캐시에 있는 마스터 페이지의 다른 이미지에 대해서도 서버에 요청을 한다는 점입니다(304 응답 코드). 즉, 두 번째 요청에서 브라우저는 항목에 대해 조건부 요청을 수행했습니다. 304 응답은 서버에 있는 항목이 클라이언트에 있는 항목으로부터 수정되지 않아 다운로드할 필요가 없음을 의미합니다. 네트워크를 통해 파일을 다운로드하지는 않았지만, 서버로의 왕복이 생성되어 로컬 복사본이 최신 상태인지를 확인했습니다. 지리적으로 분산된 환경에서는 서버 왕복에 비용이 많이 들기 때문에 최대한 왕복 횟수를 줄여야 합니다. 이렇게 하려면 나머지 각 항목(항상 서버에서 반환되는 페이지를 제외한 항목)에 대해 0이 아닌 캐싱 지시문을 추가하면 됩니다. BLOB 캐시 기능을 통해 이 캐싱 지시문을 추가할 수 있습니다.

Web.config를 사용하여 BLOB 캐시 구성

캐시를 사용할 웹 응용 프로그램의 Web.config 파일을 사용하여 BLOB 캐시를 구성합니다. 이렇게 하려면 메모장 등의 텍스트 편집기에서 Web.config 파일을 열고 BlobCache 항목을 검색합니다. 이 항목은 기본적으로 다음과 같습니다.

<BlobCache location="" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />

BlobCache 요소에서 사용되는 특성의 의미는 다음과 같습니다.

• location    캐시된 항목을 저장할 웹 서버 하드 디스크의 위치를 가리킵니다.

• path   캐시할 파일의 종류에 대한 regex 식입니다.

• maxSize **   **캐시가 사용할 수 있는 크기(GB)입니다.

• enabled    BLOB 캐시를 사용하도록 설정하려면 true로 설정합니다.

개별 항목에 대해 캐싱 만료 값을 설정하려면 아래의 추가 특성(기본적으로 포함되지는 않음)이 필요합니다.

• max-age   클라이언트 컴퓨터에서 항목을 캐시해야 하는 시간(초)입니다.

max-age 특성을 0이 아닌 값으로 설정하면 캐시 가능한 항목에 캐시 만료 값이 연결되므로 브라우저에서 해당 항목을 다운로드하거나 항목이 최신 버전인지를 확인할 필요가 없습니다. 캐싱을 사용하도록 설정하고 웹 서버에서 항목 저장 공간을 최대 100MB까지 할당하려는 경우를 가정해 보겠습니다. 이들 항목은 매일 한 번씩 만료되어야 하며, 미리 정해진 캐시되는 유형 외에 .htc 파일도 캐시해야 합니다. 이러한 요구 사항을 지원하려면 다음 BlobCache 특성을 지정합니다.

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

팜의 모든 웹 서버에서 Web.config 파일을 이와 같이 변경해야 합니다. 대부분의 경우 BLOB 캐시는 즉시 작동하지만, 변경을 구현할 때는 iisreset 명령을 사용하는 것이 안전합니다. 아래 스크린샷에는 위에 나왔던 것과 같은 페이지 요청에 대한 Fiddler 데이터가 나와 있습니다. 단, 이번에는 위의 설명에 따라 BLOB 캐시가 사용하도록 설정된 상태입니다.

보시다시피, 이제 /SiteCollectionImages 라이브러리에 있는 모든 항목의 HTTP 상태 코드가 200입니다(항목이 정상적으로 다운로드됨). 또한 모든 항목에는 항목이 1일(86,400초) 동안 만료되지 않도록 지정하는 캐싱 지시문이 연결되어 있습니다. 페이지를 다시 요청하면 Fiddler에는 다시 요청한 이미지가 없다고 표시됩니다. 따라서 해당 페이지를 처리하기 위한 총 요청 수는 44개에서 3개로 줄었으며, 나머지 3개 요청 중 2개는 웹 서버와 클라이언트 응용 프로그램 간에 수행되는 NTLM 인증 협상일 뿐입니다. 아래 그림에는 페이지를 다시 요청할 때의 Fiddler 데이터가 나와 있습니다.

BLOB 캐시 사용 시의 추가 고려 사항

BLOB 캐시를 사용할 때는 다음 사항을 추가로 고려하십시오.

• BLOB 캐시를 구성할 때는 각 웹 서버에서 Web.config 파일을 업데이트해야 하므로 추가 작업이 필요합니다. 그러나 캐시를 사용하지 않는 경우에 비해 훨씬 많은 이점이 제공됩니다.

• 사이트 콘텐츠를 파악하여 역시 캐시에서 처리해야 하는 다른 파일 형식이 있는지를 확인합니다. .htc 파일을 좋은 예로 들 수 있습니다. .htc 파일은 대부분의 게시 사이트에서 사용되므로 캐시되는 파일 형식 목록에 추가해야 합니다.

• BLOB 캐시는 SharePoint 라이브러리에 저장된 항목에 대해서만 작동하며 다른 원본의 콘텐츠를 캐시하는 데는 사용할 수 없습니다.

• 일부 목록은 기본적으로 익명 사용자에 대해 작동하지 않습니다. 사이트에 익명 사용자가 액세스하는 경우에는 목록 내의 항목이 캐시되도록 다음 목록에 대해 사용 권한을 수동으로 구성해야 합니다.

  • 마스터 페이지 갤러리

  • 스타일 라이브러리

또한 BLOB 캐시를 사용할 때 주의해야 하는 기타 두 가지 구성 옵션이 있습니다. 그 중 첫 번째는 BLOB 캐시 지우기와 관련된 옵션입니다. 특정 사이트에 대해 캐시를 지워야 하는 경우 해당 사이트 모음을 찾은 다음 사이트 작업…사이트 설정…모든 사이트 설정 수정 메뉴를 클릭합니다. 그런 후에 사이트 모음 관리 작업 목록에서 사이트 모음 개체 캐시 링크를 클릭하고, 디스크 기반 캐시 다시 설정 섹션에서 이 서버에서 강제로 디스크 기반 캐시 다시 설정 확인란을 선택한 후에 확인을 클릭합니다.