이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.
서두
WSS 3.0 및 MOSS 2007의 성능은 Microsoft® SQL Server®의 설정, 데이터 입/출력(I/O)을 처리하는 서브 시스템의 성능에 따라 좌우 된다.( SharePoint 제품 군 및 기술에서 SharePoint란, Windows SharePoint Services 및 Office SharePoint Server 두 제품 모두를 의미한다.). 이 문서는 SharePoint 제품 군 및 기술과 관련된 각종 데이터 저장 관련 설정 및 감시 방법 중 권장하는 사항들을 기술한 내용이다.
SharePoint 제품 군 및 기술에서 가장 중요한 부분이라고 볼 수 있는 것은 바로 잘 만들어진 인프라 스트럭처 설계와 효과적인 감시 시스템, 그리고 잘 튜닝된 제품 환경이라고 볼 수 있다.
이를 위해 SharePoint 제품 군 및 기술 팀에서는 자체적인 투자를 하여 처음부터 끝까지 - 최초 SQL 서버 용량 산정에서부터 응용 프로그램 서버, 웹 프론트 엔드 서버 용량까지 - 가장 효율적인 용량에 대해 계산할 수 있도록 도와 줄 수 있도록 근거들을 마련 하였다.
이 근거를 마련하기 위해서 응용 프로그램 서버 및 웹 프론트 엔드 서버에 까지 부하를 주면서 다양한 사례로 부하를 주고, 동시에 SQL 서버 등 각 Farm을 감시하면서 가장 좋은 사례들을 추려 낸 것이다. 웹 프론트 엔드 서버에 요청 시 전체 응답에 소요되는 시간을 세세히 파악하여 보았으며, 웹 프론트 엔드 서버에서 일반 최종 사용자들을 최대 받아 들일 수 있는 용량, 웹 프론트 엔드 상에서 쌓이는 큐의 크기 및 용량 한도를 넘을 때 발생되는 각종 이벤트들을 파악할 수 있었다.
먼저 알아야 할 것과 준비 사항
하드웨어를 구매하기 전에, 제일 먼저 현실적인 정보 아키텍처를 구성할 필요가 있다( 정보들의 전체 논리적인 구조 및 대략적인 정보 사이즈). 그리고 SharePoint 제품 군 및 기술들과 SQL Server를 동작 시키기에 필요한 각종 요구사항에 따른 성능의 변화들을 판단해야 한다. 또한 이 배포 작업에는 반드시 관련된 자원 계획을 수립할 필요가 있다.
전체적인 배포 계획에 대한 자세한 지침 사항들은 아래의 내용들을 참고하도록 한다.
• Planning and architecture for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409)
• Planning and architecture for Windows SharePoint Services 3.0 technology (http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409)
만일 기존에 구축된 환경에서 업그레이드 하는 것이라면, WSS 3.0과 MOSS 2007로 업그레이드 되면서 더 다양해진 기능들 및 변경된 배경 기술들에 대해서 정확히 파악하고 있어야 한다. 특히 이전 버전에서 구축된 인프라 스트럭처 자원들에서 새로운 버전에서 추가적으로 요구되는 사항들에 대해 그 차이점들을 명확히 파악하고 대처할 수 있도록 준비하는 것이 중요하다.
설계에 고려되어야 할 사항
각 설계 중 주요한 사항을 나누면 아래의 3가지로 나눌 수 있다.
• 최적화된 성능
현재까지 대부분의 성능 향상의 작업은 하드웨어 외 적인 부분에서 찾을 수 있었다. 특히 자원의 병목현상과 같은 문제점 같은 경우, 대부분은 병목을 발생하는 원인을 정확히 파악할 수 있는 감시 시스템을 구축하고, 여유로운 자원 쪽으로 적절히 부하 분배를 할 수 있도록 구성하는 것이 중요하다. 대처가능 하도록 유연한 설계와 배포를 하면, 단순한 하드웨어 확장 같은 방법보다 훨씬 더 나은 결과를 가져올 수 있다.
• 규모 산정,
늘어나는 사용자 또는 사용자의 동선에 따른 변화 추이를 항상 파악할 수 있도록 한다. 이에 맞추어 별도 Farm을 재구성하지 않고도 추가적인 SQL 서버 구축, 저장 공간 추가, 및 사이트 와 SSP 추가 구축만으로 계속 확장 할 수 있도록 설계해야 한다. 또한 규모가 늘어나면서 서비스 중단 시간이 길어지는 문제에 대한 대처 방안에 대해서도 설계에 포함 시켜야 한다.
• 관리적인 측면
저장 장치에 대한 관리에 대해 설계 하도록 한다. 매일하는 관리 작업(백업을 수행하거나, SQL 서버 재 인덱싱 작업과 같은)
그리고 가끔 하는 작업(컨텐츠를 복원하거나, 원격 사이트 서비스 중단 복구 작업)으로 나누어 보다 편하게 작업 할 수 있도록 구성한다.