Task Parallel Library
 
Parallel Extension 은 PLINQ 와 더불어 확장 가능한 Task Parallel Library 를 제공합니다. Task Parallel Library 는 PLINQ 를 이용하지 않고 개별적이고 수동적인 병렬 처리 작업을 위해 사용할 수 있습니다.
 
Task Parallel Library 는 크게 세 가지 방법으로 병렬 처리를 위한 Library 를 제공합니다.
 
Loops
 
 
 

 

[그림1] Parallel.For 를 이용한 병렬 처리
 
 


[그림2] Parallel.Foreach 를 이용한 병렬 처리
 
Task Parallel Extension 으로 병렬 처리를 쉽게 처리할 수 있으며, 병렬 처리로 인자값을 넘기거나 하는 작업을 쉽게 할 수 있습니다.
 
Statements
 

 


[그림3] Parallel.Invoke 를 이용한 병렬 처리
 
 
Task
 
특히 Parallel Extension Library 에서 Task 는 수동적으로 병렬 처리를 하기 위해 다양한 기능을 지원합니다. 정교하게 스레드(Thread) 를 처리했던 것에 비하면 심플하고도 직관적으로 병렬 작업을 처리할 수 있습니다.
 
Task 는 보다 정교하게 병렬 처리 작업을 할 수 있습니다.
l 대기
l 취소
l 연장
l 상하(부모/자식) 간의 관계
l 디버그 지원
 
아래는 ThreadPool.QueueUserWorkItem 처럼 바로 작업을 시작하도록 합니다.
 

Task.StartNew(…);

 
아래는 Task 에 대해 대기 및 취소 작업을 진행하도록 합니다.
 

Task t1 = Task.StartNew(…);
t1.Wait();
t1.Cancel();
Task t2 = t1.ContinueWith(…);

 
아래는 작업에 대해 지속적인 병렬 처리를 가능하도록 합니다.
 

var p = Task.StartNew(() => {
    var c = Task.StartNew(…);
}

 
아래는 특정 작업의 결과를 받아 올 수 있습니다.
 

var p =
 Future.StartNew(() => C());
int result = p.Value;
 

 
 
Coordination Data Structures
 
병렬 처리 작업은 PLINQ 와 TPL(Task Parallel Library) 를 지원하기 위해 기존의 데이터 컬렉션 등이 등장하였습니다. 내부적으로 동기화를 지원하지 않았던 문제들을 지원하게 되었고, 특히 오늘날 멀티 코어(Multi Core) 프로세스를 위해 많은 동기적인 문제를 고민해야 했습니다. .NET Framework 4.0 은 이러한 공통적인 문제들을 해결하기 할 수 있습니다.
 
l Thread-safe collections
       ConcurrentStack<T>
       ConcurrentQueue<T>
       ConcurrentDictionary<TKey,TValue>
      
l Work exchange
       BlockingCollection<T>
       IProducerConsumerCollection<T>
l Phased Operation
       CountdownEvent
       Barrier
l Locks
       ManualResetEventSlim
       SemaphoreSlim
       SpinLock
       SpinWait
l Initialization
       LazyInit<T>
       WriteOnce<T>

지난 포스트에서 Parallel Extension 과 LINQ 를 이용한 PLINQ 에 대해서 살펴보았습니다. 지난번에 얘기했듯이 Manual Parallelism 는 Parallel Extension 의 성능을 절대 따라올 수 없다고 하였습니다. 왜냐하면, Parallel Extension 은 Manual Parallelism 의 병렬 처리 방식보다 더 복잡하고 정밀한 병렬 처리 알고리즘으로 처리하기 때문입니다.
 
Parallel Extension 이란?
 
Parallel Extension 은 전혀 새로운 것이 아닙니다. C# 3.0 의 LINQ 는 LINQ 쿼리식을 제공하기 위해 새로운 컴파일러(Compiler) 가 필요했습니다. 정확히 말하자면 C# 의 Language Service 의 버전이 업그레이드 되었고, LINQ 쿼리식을 편하게 쓸 수 있도록 Visual Studio 2008 을 사용해야 했습니다. 다시 말하자면, LINQ 쿼리식이 아닌 확장 메서드(Extension Methods) 만으로 쿼리가 가능했다는 것이 이것을 증명해 줍니다. 확장 메서드(Extension Methods) 는 결국 IL 레벨에서는 정적(Static) 인 인스턴스(Instance) 에 불과하니까요.
 
Parallel Extension 은 새로운 컴파일러(Compiler) 가 필요하지 않습니다. .NET 의 기본적인 코어(Core) 인 mscorelib.dll, System.dll, System.Core.dll 만을 사용하여 구현이 되었습니다. 그리고, 기존의 ThreadPool 을 개선하였고, LINQ 와 통합하여 선언적으로 Parallel Extension 을 사용할 수도 있게 되었죠.
 
Task Parallel Library 를 통해 데이터 처리와 어떤 작업(Task)에 대해서도 병렬 처리도 가능해 졌습니다. 이제는 데이터의 병렬 처리뿐만 아니라, 작업(Task) 단위로서도 Task Parallel Library 로 병렬 처리가 가능합니다.
 
이제는 병렬 처리가 된다는 것이 중요한 게 아니라, 병렬 처리의 내부적인 예외 핸들링이나 Visual Studio 에서 디버깅(Debugging) 이 가능합니다. 이러한 새로운 매커니즘으로 내부적으로는 새로운 예외 핸들링 모델(Exception Handling Model)이 필요했습니다.
 
또한 .NET Framework 4.0 의 Parallel Extension 은 다양한 언어를 지원합니다. C#, VB.NET, C++, F# 그리고 .NET 컴파일러(Compiler) 로 컴파일(Compile) 되는 언어라면 상관없습니다. RoR/PHP 라도 .NET 컴파일러(Compiler)에 의해 컴파일(Compile) 된다면 Parallel Extension 을 사용하는데 전혀 문제가 없습니다.
 
 
Parallel Extension 아키텍처
 
 
[그림1] Parallel Extension 아키텍처 (클릭하면 확대)
 
Parallel Extension 의 병렬 처리는 .NET 컴파일러(Compiler) 로 컴파일(Compile) 되는 어떤 언어든 차별을 두지 않고, 병렬 처리 기능을 사용할 수 있습니다. PLINQ 로 작성된 쿼리(Query)는 별도의 PLINQ Provider 의 엔진(Engine) 에서 쿼리를 분석하는 과정을 거치게 됩니다. 쿼리 분석(Query Analysis) 에 의해 선언된 LINQ 쿼리식을 분석하여 최적의 알고리즘으로 각각의 작업을 배치하게 됩니다.
 

[그림2] Parallel Extension 작업 분할
 
각각 분배되는 작업은 쓰레드 큐(Thread Queue) 에 쌓이고, 이 큐에 쌓이는 작업(Task) 는 실제 작업자 쓰레드(Worker Thread) 에 할당이 됩니다. 하지만, Parallel Extension 은 단지 쓰레드에 할당하는 것으로 작업이 마치기를 기다리지 않습니다. 만약, 작업을 분배하는 것은 Manual Parallel 과 크게 다르지 않기 때문이죠.
 

[그림3] Parallel Extension 작업 분할
 
Parallel Extension Library 는 병렬 처리의 작업을 지속적으로 최적의 상태를 감시합니다. 예를 들어, A 의 작업이 Task 1, Task 2, Task 3 인데, B 의 작업은 모두 마친 상태라고 할 때, Parallel Extension Library 는 A 의 작업을 놀고 있는 B 에게 또 다시 분배합니다. 이러한 반복적으로 병렬 처리의 작업이 최적화 될 수 있도록 하여, 병렬 처리의 성능을 극한으로 끌어올립니다.
 
LINQ 만 알면 난 병렬 처리 개발자
 
Parallel Extension 은 LINQ 와 통합하기 위한 프로바이더(Provider) 를 제공합니다. 아직 LINQ 잘 모르신다구요? 30분만 투자하시면 LINQ 를 사용하는데 큰 지장이 없습니다. 그리고 그만큼 쉽습니다. LINQ 를 이해하기 위해 제네릭(Generic), 확장 메서드(Extension Methods), 익명 타입(Anonymous Methods) 도 함께 공부하시면 좋습니다.
 
예전에 이런 광고도 있었죠.
“비트 박스를 잘하려면?” “북치기, 박치기만 잘하면 됩니다”
 
“그럼 PLINQ 개발자가 되기 위해서는?” “AsParallel() 만 잘하면 됩니다.”
 
맞습니다. Parallel Extension Library 의 AsParallel() 확장 메서드(Extension Methods) 만 알면 당신도 이제 병렬 처리 개발자입니다. 이전 포스트의 PLINQ 예제에서 처럼 AsParallel() 만 붙이면 그것을 PLINQ 라고 부릅니다^^ (병렬 처리를 위한 확장 메서드와 옵션은 더 많이 존재합니다 )
 
아래는 AsParallel() 의 예 입니다.
private static void ParallelSort(List<Person> people)
{
       var resultPerson = from person in people.AsParallel()
                                    where person.Age >= 50
                                    orderby person.Age ascending
                                    select person;
 
       foreach (var item in resultPeople) { }
}
 
하지만, 무조건적인 병렬 처리는 오히려 성능을 저하시킬 수 있습니다. 특히 PLINQ 를 사용하는 병렬 처리는 .NET Framework 내부적으로 쿼리 분석(Query Analysis) 과정을 거치게 됩니다. 각각 프로세서(Processor) 에 분배된 데이터는 또 분배되고, 최적화가 가능할 때까지 계속적으로 분배됩니다. 마치 세포 분할이 일어나는 것처럼 말이죠.
 
최소한 병렬 처리를 위해서 데이터에 대한 이해와 추측이 가능해야 합니다.
 
1.     추측 가능한 데이터의 양
2.     추측 가능한 데이터의 내용
3.     추측 가능한 데이터 처리 시간
 
이러한 최소한의 예측 작업을 하지 않는다면, 오히려 PLINQ 를 이용할 때 성능은 저하될 수 있습니다. 예를 들어, 평균 데이터의 양이 2개라고 가정한다면, PLINQ 의 쿼리 분석(Query Analysis) 작업은 오히려 성능 저하의 요인이 됩니다. PLINQ 쿼리 분석(Query Analysis) 에 의해 두 번째 프로세서(Processor) 의 사용량이 많다고 판단된다면, 병렬 작업은 의미가 없어지고 오히려 성능을 저하시킬 테니까요. ‘쿼리 분석(Query Analysis) 작업이 눈 깜빡 거리는 시간(1/40(0.025)초) 이라고 가정한다면, 만 건의 쿼리 분석(Query Analysis) 작업 시간은 250초’가 될 테니까요.
 

Visual Studio 2010 에게 바란다 - SharePoint 14 Development

SharePoint 2010 2009. 2. 15. 21:37 Posted by 알 수 없는 사용자

VSTS 2010 팀 블로그가 생긴지도 어느덧 한달이 되었군요. 얼마나 많은 활동을 했는가 보다는 얼마나 알찬 내용들을 담아내려고 했는지가 중요한 것 같습니다. 개인적으로 뭐가 되었든 간에 저는 처음 블로깅이군요. ^^; 저는 SharePoint MVP로서 팀블로그에도 SharePoint의 차기 버전을 담으려는 욕심이 있었습니다. 새버전의 Object Model 에서 향상된 점이라던가 UI 측면에서의 변경된 사항등에 말이죠. 헌데 SharePoint 차기 버전 및 이에 대한 VS 2010의 정보도 Microsoft 내부에서도 이는 극비인 모양인 것 같습니다. 짧은 인맥과 정보가 있을만한 곳을 아무리 뒤져보아도 아는 사람이 없군요. 아무래도 하루가 다르게 치솟아 오르는 SharePoint 의 인기탓인 듯 싶습니다.(국내는 예외로 해두죠 ^^;) 여튼 이런저런 이유로 새로운 버전에 대한 내용은 아쉬움을 뒤로하기로 하였습니다.

대신 ’ Visual Studio 2010 에게 바란다 - SharePoint 14 Development’ 라는 주제로 현재 SharePoint 개발에 있어서의 문제점과 아쉬운 부분들을 살펴보고 이에대한 개선점을 살펴 보도록 하겠습니다.

 

 

오늘은 간만에 대학 도서관을 찾았습니다. 졸업시즌 이기도 한 요즘이라 한번 찾아오고 싶더군요. 여튼 학창시절 생각도 나고 사회생활을 시작한 초기 미친듯 일만 하던 시절 토요일이나 일요일에 새로운 닷넷기술을 공부하던 것 생각나서 겸사겸사 찾아왔습니다. 학교를 찾아오는 길이 낫설지 않았지만 새로운 몇몇 가지들이 눈에 띄더군요. 첫번째로 학교에 올라가기가 쉬워졌습니다. 버스가 다니더군요. 높은 곳에 위치한 탓에 운동을 따로 하지 않아도 되었던 그 시절과는 다르게 버스가 수시로 다니고 있었습니다. 학교 정문을 통과하고 도서관 앞에 다다랐는데 에스컬레이터가 있습니다. 와우~ 4층까지 되는 높이를 숨한번 차지않고 올라오다닛!!! 이런 눈부신 발전이!!!

이래저래 도서관에서 새로운 자리를 잡고 오늘은 무슨 공부를 해볼까 하는 중에 급 배가아파오기 시작하더군요. (이놈의 쾌변욕구는 때와 장소를 가리지 않습니다.) 재빠르게 노트북을 덮고 화장실에 갔는데 화장실이 광이나더군요~ 개다가 히터까지 나옵니다. 예전에는 창문이 바로 옆에 있어서 추위에 떨면서 볼일을 보았던 것이 기억나는데…. ~ 매우 편안합니다. ^^; 이런것들을 누리고 있는 재학생들이 얼마나 부럽던지~ 그리고 또 한편으로는 발전하고 있는 학교가 뿌듯하기도 하더군요.

 

현 시국에 대학생을 부러워 한다는 것이 어쩌면 그들에게 맞아 죽을지도 모르는 말들이겠죠. 하지만 학교에서 당연히 해줘야 하는것들에 대해서 내가 누리지 못했던 것들을 이제는 그들이 누릴 수 있게 된다는 사실은 부러움과 함께 뿌듯한 무언가를 몰고 옵니다.

 

그럼 현재의 SharePoint 개발은 어떤가요?

 

SharePoint 의 개발영역은 크게 6가지 정도로 나눌 수 있습니다.

l  리스트나 문서라이브러리에 추가할 수 있는 커스텀 어셈블리(Event Handler, Web Part)

l  리스트 정의나 사이트 정의 같은 Custom XM

l  마스터 페이지나 레이아웃 페이지 및 컨트롤

l  문서라이브러리의 문서템플릿 혹은 폼 템플릿

l  배포 패키지

l  아웃룩에서 클라이언트 연결을 위한 Client Integration

 

그리고 현재시점에서 위와 같은 것들을 개발하려면 최소한 아래의 툴들이 필요합니다.

l  Visual Studio 2008 (2005 도 가능)

l  Windows SharePoint Services 3.0 도구: Visual Studio 2008 Extensions, 버전 1.2

l  WSS 3.0 or MOSS 2007

 

위에 나열한 요소들 개발하려고 보면 SharePoint 개발는 지원받아야 하는 당연한 것들을 지원받지 못하고 있다는 것을 알게 됩니다. 아래 예를 살펴보도록 하죠.

 

만약 제가 SharePoint 에서 리스트를 만들고 이 리스트에 대한 사용자 워크플로우를 생성한 후 바인딩하고 이를 테스트 및 적용하려고 한다면 과연 몇가지의 일들을 해야할까요?

 

1.     WSS 3.0 MOSS 2007 을 설치 - 만약 위의 서비스 및 제품이 설치되어 있지 않다면 디버깅이 불가능 하죠. ,.

2.     (Vissual Studio 가 설치되어 있다는 전제하에)Windows SharePoint Services 3.0 도구: Visual Studio 2008 Extensions, 버전 1.2 를 설치 - 이로써 개발환경 세팅이 끝납니다.

3.     리스트 정의를 생성 여기에서는 GUID, Title 등의 값을 입력하고 이벤트 핸들러등을 작성합니다.

4.     워크 플로우템플릿 정의 생성 - 3에서의 작업과 유사

5.     실제 워크플로우를 디자인하고 비하인드 코드를 작성합니다.

6.     VS 2008 에서 빌드하고 어셈블리를 등록

7.     로컬 서버 개발 환경에서 실제 소스 디버깅

8.     DDF 파일을 생성하고 이를 WSP 형태로 수정

9.     WSP 파일을 실 서버에 복사

10.   STSADM 툴을 사용하여 서버에 설치

11.   동작 테스트

 

위에 나열한 바와 같이 많은 작업들을 우리는 알게 모르게 하고 있습니다.

실제로 하나하나 따져보면 간단한 일들이 아닌 것 많습니다. 위의 1번의 WSS MOSS 2007 설치만 보더라도 간단한 일이 아니죠. WSS 혹은 MOSS 2007d을 설치하려면 반드시 Windows ServerSQL 서버(혹은 SQL Express) 를 설치해야 한다는 의미입니다. (Vista 에서는 WSS를 설치할 수 있는 방법이 있긴 합니다. ^^;)

또한 리스트 정의등을 생성할때는 VS Extension 툴을 이용하면 됩니다. 헌데 이것도 혼자 개발하고 테스트 할때는 매우 편리 합니다만, 대규모 프로젝트에서는 이에대 한 관리가 매우 난감해 집니다. 예를 들어 GUID 관리라던가 리스트의 Static Name 에 대한 네이밍룰 정의 등이죠. 여기서 파생되는 문제는 또 한가지가 있습니다. 팀 개발이 어렵다는 문제죠. 즉 팀 개발에 있어서의 정형화된 Rule 등을 세팅할 수 있는 것이 부재한 상황이죠.

마지막으로 Visual 한 개발 환경을 지원하지 못하고 있습니다. 현재의 Visual Studio 2008 만 살펴보더라도 만은 것들을 Visual 한 환경에서 개발 할 수 있도록 지원을 하고 있죠. SharePoint 도 이를 위하여 SharePoint Designer 를 사용하고 있지만 커스텀 코드를 추가할 수 없다는 단점이 여전히 존재합니다.

 

Visual Studio 2010 에서 SharePoint 14 개발은...

 

위에서 나열한 이러한 단점들이 Visual Studio 2010 에서는 이루어 졌으면 하는 작은 소망이 있습니다. 허나 앞에서도 언급하였지만 현재 WSS Vista 에서 설치가 가능하며 이를 설치하면 로컬 PC 환경에서도 SharePoint 모듈을 개발 할 수 있습니다. 사실 이것만 해결되어도 안그래도 어려운 SharePoint 개발 진입이 조금은 쉬워지지 않을까 하는 생각입니다. ! 그리고 리스트 정의나 사이트 정의같이 CAML 을 직접 생성하려고 할 때 Code Intelligence 등을 지원하면 리스트나 사이트 정의를 생성하는 것이 한결 수월할 것 같군요.

여튼 SharePoint 툴이 VS 2010 에서 통합된다는 얘기가 여기저기서 들려오는 현재 입장에서는 일단 희망을 걸어봅니다.

Written by 송재두(짜두)