SharePoint 20102012.07.04 18:13

이번 두번째 포스트에서는 “Best Practices for Building your Website for Scale with Microsoft SharePoint 2010” 라는 제목의 세션의 내용을 요약하여 소개해 보겠습니다.

이 세션은 역시 개발자와 어드민이 같이 주목해야 할 내용이 소개되고 있습니다. 코드로만 성능향상을 이루는 것이 아니라, 인프라적인 요소도 중요하게 다루어 지고 있기 때문입니다.

그리고 지금까지 저조차도 한번도 보지도, 생각지도 못했던 Content Deployment라는 선진(^^) 기법이 소개되고 있습니다. 관심을 가지고 살펴보면 좋을 주제라고 생각됩니다.

image

짜잔. 이제 시작합니다.

 

image

이번 세션에서 소개되는 내용은 위의 사이트에서 실제로 구현/적용된 내용입니다. 아쉽게도 현재는 이 사이트에 접속이 안되는 것 같습니다. 현재는 Metro UI 로 꾸며진 새로운 사이트가 뜨고 있습니다.

 

image

쉐어포인트 개발을 해 보셨다면 한번쯤을 보았을 만한 에러 화면입니다. 이 에러는 사용량이 초과되었다는 에러인데요. 샌드박스 솔루션으로 개발 했을 때 각각 할당받는 자원량을 초과하는 상황이 오면 위 에러가 나옵니다. 인터넷에 개방된 퍼블릭 웹사이트에 쉐어포인트의 샌드박스 솔루션으로 개발한 웹파트를 올려 놓으면 바로 위의 에러가 나올 겁니다.

마이크로소프트에서는 어떻게 이 상황을 처리하는지 같이 보시죠.

 

image

마이크로소프트가 주목하고 있는 WCM 환경의 특징은 Read-Heavy 라는 것입니다. 인터넷 웹사이트 특징으로 생성/업데이트 하는 것보다 읽기 수준의 작업이 많으며, 그 성능을 높이기 위해서 캐싱 기술이 효과적이다 라고 말하는 것입니다.

사실 새로울 것은 없는 내용입니다. 지금까지 수행해온 쉐어포인트 튜닝과 크게 다르지 않습니다.

 image

캐싱과 관련해서 위와 같은 도표를 보여줍니다. 아웃풋 캐싱을 활용하는 정도에 따라 웹서버의 최대 Throughput 의 수치를 보여주는 것인데요. 캐싱을 적게 쓰면 웹서버의 갯수가 늘어나도 최대 성능의 향상 폭이 적습니다. 반면 캐싱을 많이 쓰면 웹서버의 수가 늘어남에 따라 처리속도의 향상도 그대로 반영이 되는 것을 볼 수 있습니다.

 

image

이것은 저도 약간 의외 였습니다만 웹서버의 CPU 가 보틀넥의 주요요소로 꼽히는 군요. 아무래도 캐싱을 쓰면 메모리 읽기/쓰기 가 활성화 되고 그렇게 되면 CPU 성능에 따라 모든 성능지표가 좌지우지 되긴 할 것 같습니다.

 

image

쉐어포인트에서 사용할 수 있는 캐싱은 세가지 입니다.

 

image

아웃풋 캐싱은 이렇게 설정합니다. 날 따라 해봐여.

 

image

추천 캐싱 설정입니다. 한가지 주의 할 점은 이 것은 WCM 즉 인터넷 사이트를 위한 설정이구요. 대부분의 사용자가 authors 인 인트라넷에서는 이렇게 설정하면 하나 마나 지요.

 

image

이건 아주 좋은 팁인 듯 합니다. 실제로 캐싱된 페이지는 소스보기를 하면 위와 같이 html 끝에 꼬리가 붙어 있다고 합니다. 캐싱이 잘 동작하는지 알아볼 수 있지요.

 

image

메모리가 딸리면 캐쉬된 내용이 trimm 되면서 문제가 발생합니다. 서버를 업그레이드 하든지 캐쉬 주기를 조정하든지 해야 합니다.

 

image

그래프가 좀 보기 어려운데요.

파란색 RPS 가 증가함에 따라 CPU 사용율이 증가합니다. 그런데 빨간색 줄을 보면 CPU 80% 를 넘게 되면 latency 가 급증합니다. 아… 그래서 CPU 100 치면 서버 응답이 느린 거죠.. CPU 80%을 임계치로 봐야 겠습니다.

 

image

다이나믹 한 정보를 담고 있는 페이지의 캐싱에 관련한 내용입니다. PT 에서는 위 그림에서 로그인 하면 빨간 점선 부분이 “안녕하세요 000씨” 로 변합니다.

 

image

이런 경우 통상적인 Webcontrol 을 사용하지 말고, System.Web.UI.Webcontrols.Substitution 클래스를 상속받아서 컨트롤을 만들면 된다고 합니다. 전체 페이지는 아웃풋 캐쉬에 담기고 이 컨트롤만 별도로 렌더링 시에 호출된다고 합니다. 이것도 처음보는 기법이네요.

 

image

다음은 쉐어포인트 오브젝트 캐쉬입니다. 쉐어포인트 쿼리의 결과가 캐쉬되는 것입니다. 개발자가 의도하지 않아도 서버가 알아서 캐싱을 해 주는 것이죠

 

image

이건 읽어보시면 되고…

 

image

파워쉘을 이용해 두개의 슈퍼계정을 지정해야 합니다.

 

image

이 그림은 맨처음에 소개된 그 에러화면입니다. 바로 오브젝트 캐쉬를 쓰지 않아서 벌어진 상황입니다.

해결법은 바로 아래에.!!

 

image

통상적인 SPList.GetItems 는 오브젝트 캐쉬를 쓰지 않습니다. 그러니까 모든 사용자의 대응에 실제 쿼리를 수행하지요. 위와 같이 명시적으로 캐시데이터를 사용하는 쿼리를 써야 합니다. 서버의 메모리와 CPU 가 중요한 이유를 이제 알겠습니다. ^^

이거 오늘 포스팅의 가장 중요한 내용 중의 하나 입니다.!!

 

image

클라이언트 사이드 코드를 사용할 때에도 오브젝트 캐쉬를 사용할 수 있습니다. 그런데 사실 오브젝트 캐쉬를 이용하는 전용 웹서비스를 개발해서 그 웹서비스를 이용하라는 것입니다. 쉐어포인트 클라이언트 오브젝트 모델은 캐싱이 안됩니다.

뭐야.. 이거…

 

image

이번에는 블랍 캐쉬 입니다. 사이트의 정적요소 즉 이미지, JS, CSS 등을 캐싱 할 수 있는 것입니다.

 

image

이렇게 설정하구요.

 

image

마이크로소프트는 큰 파일이나 공통적인 JS 파일들은 CND 서비스를 이용한다고 합니다.

 

image

IIS 설정에서 정적 압축 전송 옵션을 활성화 하는 것을 챙겨달라고 합니다.

 

image

자 이제 Content-Deployment 를 시작합니다. 저도 한두번 아이디어 정도는 있었는데 정말 이렇게 하는 줄은 몰랐습니다.

요점은 두개의 팜을 구성해서 작성자가 작성하면 자동으로 다른 팜으로 컨텐츠가 복사됩니다. 그 쪽 팜은 오로지 인터넷 방문자들만을 위한 읽기 기능만을 제공하는 것이지요. 고속의 퍼포먼스를 위해 고심한 결과라고 생각합니다.

 

image

이렇게 구성되는 것이지요.

 

image

컨텐츠 디플로이먼트는 운영환경에 누구도 작성자 권한을 가지면 안되는 업무상/규정상/법률상 요구사항이 있는 경우 유용합니다. 실제로 모든 컨텐츠가 공표되기 전에 리뷰나 스테이징이 가능하지요.

 

image

이런 경우는 적절치 않타 !!

 

image

SQL 서버의 스냅샷 기능을 이용해서 Content Delpoyment 하는 예를 소개합니다.

쉐어포인트의 컨텐츠를 복제하는 툴이나 기능을 개발하는 것이 아니라, SQL 복제를 통해서 하는 군요..

 

image

기본기능이군요… 참… 쉐어포인트는 대단한 제품입니다.

우리말로는 중앙관리 > 일반 응용 프로그램 설정 > 콘텐츠 배포 경로 및 작업구성 에 위치하고 있습니다. 제 테스트 환경에서는 위와 같은 화면이 안나오는 걸로 봐서 SQL 2008 엔터프라이즈 에디션이 있어야만 사용할 수 있는 것 같습니다.

제 환경에서는 단순한 타이머 잡에 의한 배포 내용만 존재합니다. SQL 이 스탠다드라서 그런 듯 합니다.

 

image

개발을 통해서 구현이 가능하다고 합니다. 그런데 사실 이런 API 가 있는 줄은 저도 이제 알았습니다.. ㅠㅠ

 

image

image

API 코드 예와 그에 따른 필요한 설정도 같이 소개하고 있습니다.

 

image

진정 Level 400  수준인 TechED  에 걸맞는 심도있는 내용의 세션이었습니다. 세션 마지막에 다중언어 에 대한 Variations 에 대한 내용도 이야기를 하고 있는데, 그 내용은 생략 하도록 합니다.

이 세션의 두 가지 키포인트는 캐싱 과 컨텐츠 배포 입니다.

Posted by 랜스 lanslote