'2008/01'에 해당되는 글 17건

이 자료는 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 서버 재 인덱싱 작업과 같은)
그리고 가끔 하는 작업(컨텐츠를 복원하거나, 원격 사이트 서비스 중단 복구 작업)으로 나누어 보다 편하게 작업 할 수 있도록 구성한다.

다른 곳에서 구한 것은 아니고, MSDN 내의 Subscription을 통해 받은 RC1 입니다.이미 Vista가 나온 상태이기 때문에, 전체적인 UI 구성이나, 배치 등은 Vista에서 보여준 형태 거의그대로여서 큰 문제점은 없더군요.

우려 했던 드라이버 문제들도, 이미 나온 Vista 드라이버로 거의 설치가 되었습니다.(최소한 제 개인 개발 PC내의 드라이버에서는 문제가 없더군요)

Vista가 가지고 있던 클라이언트의 UI가 깨끗히 걷히고, 딱 필요한 부분만 적용된 것 같습니다.그리고 2003에서 처음 제시했던 서버 Role에 대한 페이지도 더 다양하게 제시되어 있어

훨씬 접근성도 좋더군요.
게다가, 2003에서 .NET 1.1이 미리 들어가 있던 것 처럼 이번 2008에는 2.0이 미리 들어가 있었습니다. 또한 3.0도 추가 옵션을 통해 더할 수 있었으며, WPF(Windows Presentation Framewrok) 및 WWF(Windows Workflow Framework)도 있더군요.

게다가 이번에 가장 놀라게 한 것은 IIS 7.0.
일단 기능 추가 부분에서 훨씬 다양한 조건들과 옵션들의 압박도 대단했지만,
iismgr ( IIS Manager )는 정말이지 걸작이다 싶습니다.
거의 완벽하게 UI 스럽게 뜯어 고쳐서, 자주 만져주지 않으면 정말이지 딴세상 가버릴듯 하더군요.

일단, Vista 기반의 드라이버와 프로그램들이라면, 2008을 쓰는데는 무리가 없어보입니다.
이제 MOSS 2007을 설치해 보고, 무엇이 부족한지 무엇이 좋은지를 차츰 확인해 보도록 하겠습니다.

* update
  Vista나 XP에 설치하고 나면 C:\program files\Common files\WindowsLiveInstaller\MsiSources 위치에 MSI 파일들이 위치해 있군요. 그 파일들만 있으면 MSI 설정만 변경하여 설치가 가능하다고 하군요.
자세한 내용은 http://extremeperformance.blogspot.com/2007/12/windows-live-writer-xp-x64.html 를 참조하세요~

* update
 위의 버전을 설치하게 되면 사용하는데는 문제 없었지만, 문제가 있었다. 특히 플러그 인과 같은 것이 제대로 설치되지 않았다. 게다가 이 프로그램의 버전업은 새로운 버전을 받아 설치하는 것인데, 이 후버전은 설치가 안되니, 업그레이드는 안되는 것이라고 보면 될 것 같다. 게다가 묘하게 자주 깜빡 거리는게 좀 거슬린다.

Windows 2003에서는 이상하게 공식 Windows Live Writer가 설치되지 않는다.

그래서 언제나 다운로드를 받아 놓고서는 집에서는 설치도 못해보고 발을 뺐다.

그렇다고 기껏 설치한 Windows 2003을 버리고 XP를 설치하기엔 왠지 억울 했다.

(개인적으로 성능은 2003이 더 낫다고 생각됨)

그래서 Microsoft 에서 제공되는 Application Verifier 라는 도구까지 동원해서 운영체제

호환성까지 속여 보려 했는데... 실패 했다.

그러던 어느날.. 브라우징 끝에, Google에서 Windows Live Writer install to windows 2003 이라는

검색어로 찾던 도중, 포스팅 된 좋은 글을 하나 발견, 그 링크를 따라 들어가다가,

마침 Windows Live Writer 개발 팀 블로그로 보이는 곳 까지 갔다.

( 근데, 이 웹페이지는 독일에서 만들었는지 .de 로 끝난다. )

그 곳에서 MSI 파일로 된 설치 본이 있었고, 난 그것을 낼름 받아 설치했다.

WLinstaller.exe 라는 파일을 받아 설치하면 영원하게 설치할 수 없고, 최신 버전인 MSI를 받아 설치하면,
아무런 호환성 테스트 없이 즉시 설치 들어가 준다.

일단, 그 덕에 설치했고 간단하게 세팅 완료~

다양한 Blogging desktop tool 들이 있긴 하지만, 유료거나, 한글 미숙지원 뿐인데,
이건 꽤 잘 만들어진 것 같다.

저녁에 퇴근하면서 조금씩 포스팅을 해야 겠다.

지지 난주에는 거의 매일 포스팅을 했었는데, 근좌 묘하게 바쁘고, 혼잡하게 지내다 보니,

포스팅은 커녕 일조차 제대로 하지 못한 느낌이다.

조금씩 정리하듯 글쓰면서 생각의 정리라는 것을 해봐야 겠다.

MOSS 2007 기술에 대한 정리가 이제 시작된듯 싶고, 그에 관련된 수많은 글들이

포스팅 되고 있어, 읽고만 있어도 할 것이 너무 많아 보인다.

일단, 그들의 글들을 읽고 나만의 생각들을 정리해서 담아봐야 겠다.

SPUser를 등록하는 방법은 사실 간단하다.

SPWeb.SiteUsers.Add("계정ID", "이메일주소", "보여줄 이름", "기타 메모")

위의 방법으로 사용하게 되면, 사용자 목록에 등록이 된다. 그러나 이렇게 등록하는 것으로는 해당 사용자가 사이트 내에서 제대로 활용할 수 없을 뿐더러 로그인 해봐야, 액세스 거부 창이나 팍팍 뜬다.

그러면 그 즈음 되서 권한 부분을 체크해 보게 된다.

게임은 지금 부터다.
그렇다면 이 권한 등록하는 방법들이 어떻게 있을까?

하나는 MOSS 2007에서 제공되는 그룹에 추가하는 방법이 있고, 다른 하나는 한사람 자체에 따로 권한을 주는 방식이다.

1. MOSS 2007에서 제공되는 그룹에 추가하는 방법
보통 그룹은 기본적으로 "사이트이름"+" 구성원", "사이트이름" + " 관리자" 형식으로 생성되어 진다.
그래서 보통 아래와 같은 형태로 짜기도 한다.

    SPGroup group = web.Groups["Members"];
    SPUser user = web.SiteUsers["KNOIE\\neohind"];
    group.AddUser(user);

그런데 그 그룹 이름이라는게 로컬라이즈 된 이름이라서 만일 "테스트 사이트" 라는 이름의 사이트에는 "테스트 사이트 구성원" 이런 식의 이름이 그룹이름이 된다. 객관적으로 좀 너무한 이름이지 않을까 싶다. 예제와 같은 이름이라면 위의 코드가 아래처럼 되어야 할 것이다.

   SPGroup group = web.Groups["테스트 사이트 구성원"];
   SPUser user = web.SiteUsers["KNOIE\\neohind"];
   group.AddUser(user);

좀... 너무 하지 않을까? 왠지 하드 코딩하는 기분을 지울 수 없고, 만일 어디에 포팅된다면.. 왠지 대박이지 않을까?
(저 같이 유지보수나 남아서 X 치우다 보면, 우울해집니다.)

그렇다면 어떻게 하면 좋을까?
이를 위해서 SPWeb에는 아래와 같이 관련 그룹에 대한 개체를 바로 꺼내 쓸 수 있는 부분이 있다

SPWeb.AssociatedOwnderGroup // ( 관리자 )

SPWeb.AssociatedMemberGroup  // ( 구성원 )

SPWeb.AssociatedVistorGroup // ( 방문자 )

즉 위의 예를 기준으로 변경해 보면 아래와 같은 코드가 된다.

  SPGroup group = web.AssociatedMemberGroup;
  SPUser user = web.SiteUsers["KNOIE\\neohind"];
  group.AddUser(user);

그 외 그룹(디자이너, 계층 구조 관리자)들은 알아서....

여튼 저 그룹에 Users 항목에 SPUser 형태로 더해 주면 된다. 그러면 자동으로 해당 권한을 할당해 줄 수 있다.

2. 개별 계정별 개별로 권한 매기기.

여기서 부터는 조금 복잡하게 돌아간다. 아마도 SPGroup에 특정 권한 쎄우려고 할 떄 사용하곤하는데, 이 또한 개별적으로 처리할 수 있다.

SPUser user = web.SiteUsers["KNOIE\\neohind"];
// 만일 관리자, 구성원, 방문자 단위가 아닌 기능별로 Roledefinition을 만드는 방법을 별도로 더 파악해야 함.
// 범위를 넘어가므로 여기서는 Contributor 즉, 구성원으로 권한을 설정.
SPRoleDefinition defContribute = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
SPRoleAssignment roleContribute = new SPRoleAssignment(user as SPPrincipal);
roleContribute.RoleDefinitionBinding.Add(defContribute);
Web.RoleAssignments.Add(roleContribute);

위의  순서대로 보면 먼저 SPRoleDefinition을 생성 한다.
그리고 난 뒤 SPRoleAssignment를 생성한다. 여기서 생성할 때는 권한을 설정하려는 대상(보통 SPUser나 SPGroup)을 넣는다.
그리고 SPRoleAssgignment 내에 RoleDefinitionBinding에 앞서 만든 SPRoleDefinition을 추가한다.
맨 마지막으로 만들어진 SPRoleAssignment를 실제 권한을 설정하려는 Web, List, ListItem에 추가한다.

대부분의 MOSS 2007 개발자들은 이 사이트와 웹 간의 차이를 명확히 모르거나 어렴풋이 알아도 그게 그거가 아닌가 라는 어조로 표현하곤 한다.
하지만 개념적으로 명확히 틀린 구조이며 그 차이는 명확히 틀리다.

다음 그림을 보면 대략적으로 왜 사이트와 웹이 틀린지 알 수 있다.

즉 사이트 여기서는 SPSite인데, 최상위의 일종의 거대한 상자라고 보면 될 것이다. 이 안에 무수한 SPWeb을 붙여서 하나의 사이트를 만드는 것이다. 즉 사용자들은 SPWeb을 보는 것이지 SPSite를 보는 것은 아니다. 실제 사용자가 보기 위한 페이지, 리스트들의 모든 정보들은 바로 저 SPWeb에서 나오고, 그 외에 전체 검색이나, 차이점 분석 결과 등 전체 사이트에 대한 설정, 구성, 정보들은 SPSite에서 다루게 된다.
우리가 보통 새끼까기 하듯이 사이트 아래에 사이트를 만든다고 하는데, 그건 SPSite를 만든 것이 아니고 바로 저 SPWeb을 만드는 작업이라고 보면 된다.

보통 개발자들이 혼돈을 느끼는 부분이 바로 여긴데, MOSS 관리자 페이지에 가면 사이트 만드는 부분의 명칭이 "사이트 모음 만들기" 라고 적혀 있고, 해당 사이트의 페이지에 가서 사이트 관리 도구에 들어가면 하위 사이트 만들기 라고 적혀 있으니, 사이트 모음 = SPSiteCollection, 사이트 = SPSite 라고 생각하는 우리의 입장에서는 이 또한 무슨 망발이냐!!! 라는 의문을 바로 제기할 수 있다. 

그.러.나. SDK를 보면 우리를 또 한번 더 햇갈리게 한다. 양키 말을 들어보면 Web, Site 구분없이 막지껄이고 떠든다. 뭐가 Web이냐, Site냐.. 최소한 난 이것 때문에 상당한 혼란을 일으켰다. 그러면 저 SPSite와 SPWeb은 1:1로 하나씩 묶여서 구성된 건가... 했다.

그러나 진실은 SPSite는 무조건 한개, 그 하위의 모든 사이트들은 SPWeb이다. 그를 증명하는 부분은 바로 컨텐츠 DB. 만일 사이트 모음을 한개 만들어 놓고, 그 안에 새끼 까듯이 계속 사이트들을 만들어 99개를 만들었다고 하자. 그 때 컨텐츠 DB안에 사이트는 몇개 일까?
    1개다.
궁금하신 분은 테스트 해보시면 알 수 있다.
즉 사이트 모음은 SPSite를 의미하기 때문에, 그 SPSite 갯수인 1개가 들어가고 그 이후에는 어차피 SPSite 내에 포함된 하위 SPWeb들이기 때문에, 컨텐츠 DB 입장에서는 사이트 갯수에 포함 안되고, 단지 1개의 SPSite가 좀 커졌구나... 정도로 인식할 뿐이다.
(즉 늘어나는건 컨텐츠 DB의 사이즈 뿐이다.)

이런 개체들의 관계를 따라, 각 개체를 참조 할 때는 아래와 같이 찾아 들어가면 된다.

Microsoft.SharePoint.Administrator.SPWebApplication 로 가는 방법

  [SPSite 개체].WebApplication

Microsoft.SharePoint.SPWeb로 가는 방법

  [SPSite 개체].OpenWeb("url")

그리고 만일 위의 그림에서 1번 사이트를 연 뒤 (new SPSite("1번 사이트 URL")) 한 뒤, 저 OpenWeb을 써서 2번 사이트 아래의 웹을 찾으려면 당연하게 오류를 뿜는다. 저렇게 그림으로 보면 당연하거 아녀? 라고 되묻겠지만, 간혹 어떤 분들이 1번 사이트 열어놓고, 2번 사이트 내의 웹이 안 열린다고 투덜 댄다. MOSS 2007 버그니 뭐니.. 하는데... 한번 즈음 소스 검사 해보심이 ...

그리고 만일 특정 SPSite 및의 모든 하위 사이트(절대 SPSite가 아니다, SPWeb 이다.)에 대해 세팅을 동일하게 적용한다고 했을 때는 해당 SPSite를 열고 RootWeb을 연 뒤, 그 RootWeb에서 Webs를 이용하여 트리 탐색하듯이 찾아 들어가야 한다. 1번 사이트를 보면 그 아래의 SPWeb 아래 SPWeb들을 뒤져야 된다.
그 검색로직은 트리를 찾는 방법대로 진행되어야 할 것이다.

아침을 좀 빠르게 일어나 앉았다.
사실 MP3 찾는 거라든가, 어제밤에 챙겨 놓지 않은 노트북등 정리안된 부분을아침으로 미루었기에 당연히 일찍 일어나야 하는데, 문제는 내가 보통 때 그 시간에 잘 일어나지 못한다는게 핵심이다. 어쨌던 일찍 일어난 아침 덕에, 그간 찾지 못해 못들었던 모차르트 K183 알레그로 콘 브리오를 다시 듣기 위해 뒤적였고, 못챙겼던 출근 가방 챙겼다. 그리고 여유 있는 아침과 함께 너무 일찍 일어나 생긴 현기증을 동시에 느끼면서 따듯한 방바닥을 바로 비비며 미묘한 유혹에 져볼까 말까 하는 아슬아슬한 도전도 즐겼다.

그리고 옷 챙겨 입고 나서는 순간 온 세상은 잿빛 속 흰색으로 가득찼다.
우중충한 하늘에서 무수하게 떨어지는 눈은 한가득 내려 우리집 앞쪽의 모든 지붕들을 감싸버렸다.
길가에는 덩어리 진 흰 눈덩이들이 나돌아 다니고, 사람들은 우산 챙겨 들고 이리저리 바쁘게 지나가고 했다.
나도 그 속에 파묻혀 회사로 향하다, 문득 이른 아침의 시간을 보고 사진기를 꺼내들었다.

집 앞쪽에 위치한 공원도 아닌 조그만한 휴식처에 소복히 쌓인 눈이 이뻐보였다고나 할까.
가끔은 이런 여유도 즐겨 볼만 한 것 같다.

예전에 매일 매일 포스팅을 목적으로 잡글들을 올리고, 또 올리고 올리다가,

까먹고 한참 동안 안올리고.

바빠서 안올리고.

핑계의 핑계를 계속 하다가, 일주일에 한번? 심지어는 한달에 2~3번 포스팅에 마치는 경우도 있었다.

(대표적인 예로 10월달, 11월 달? 그 때 한창 프로젝트 말기에 치닫다 보니....)

이번에 한번 내가 생각난 것들에 대해 조금이라도 짬을 내서 포스팅에 포스팅을 계속해온 결과,

근 한주 연속 포스팅을 기록했다. 스스로 축하(自祝)

아마도 오늘 이후에도 계속 포스팅이 이어질지는 모르겠지만,

가급적 자주 포스팅을 해야 겠다.