Master-slave pattern

1. POSA1 Study 발표자 : (javajigi) Sw-Design, 장회수 Master-slave pattern

2. 선호하는 작업 방식

5. 작업지시의 안티 패턴

6. 체계적인 작업 지시

7. 서비스? 시키면 오는… ?

8. 협력 ( Collaboration )

9. 조직적으로 목표를 달성하자

10. 조직화의 원칙 • 역할의 분리 • 정책과 구현의 분리 • 분할 정복

11. 조직화 패턴 • Master-Slave 패턴 • 장애 허용성 • 병렬 계산 • 계산 정확도

12. Master-Slave? Master 는 Slave 에게 일을 분할한다. Master Slaves

13. Sample, TSP, traveling salesman problem ( 순회판매원 ) 상당히 복잡한 계산이 필요 6.0828*10^62 의 가짓수 NP – 완전 문제 – 고수준의 복잡성

14. Context (정황) • 의미적으로 동일한 여러 서브 테스크 들로 분할 • 서비스의 조직화

15. Problem • 분할정복의 원칙을 따라야 한다. • 독립적으로 처리되는 여러 개의 동등한 서브 태스크 들로 작업을 분할 • Forces • 클라이언트는 분할정복? 알 필요 없음 • 클라이언트, 서브 태스크의 처리는 알고리즘에 의해 좌우 되지 않는다. • 서브 태스크들은 간혹 조정이 필요하기도 하다. • 서브 태스크를 처리하기 위해 의미적으로 동일한 구현들을 사용하는 것이 좋다. 잉? 어떻게요?그냥 일 시작하면 되려나? 이 집처럼… 지어주세요…

16. Solution • 조정인터페이스 도입  마스터 컴포넌트 • 마스터 컴포넌트 • 여러 개의 동일한 서브태스크들로 작업을 분할 • 독립적이지만 의미적으로는 동일한 여러 개의 슬레이브 컴포넌트들에 위임 • 각 슬레이브가 반환하는 결과로부터 최종 결과 계산 Master Slaves 장애 허용성 병렬 컴퓨팅 계산 정확도

17. Master-Slave Structure 협력자 Slave 협력자 - 클래스 Master 클래스 Slave • 책임 • 여러 슬레이브 컴포넌트들에게 작업을 분할해준다. • 슬레이브들의 실행을 개시한다. • 슬레이브가 변환한 결과를 계산한다. • 책임 • 마스터를 대신해 작업할 서브서비스를 구현한다.

18. Master splitWork callSlaves combineResults service Slave subService Master-SlaveClassDiagram +2 delegates

19. 서비스 호출 시나리오 Client Master Slave 1 Slave 2 Service splitWork callSlaves subService Result Slave-1 subService Result Slave-1 combineResult result

20. 서비스 호출 시나리오 • 클라이언트가 마스터에게 서비스를 요청한다 • 마스터는 동등한 서브태스크들 몇 개로 태스크를 분할한다. • 마스터는 이 서브태스크들의 실행을 몇 개의 슬레이브인스턴스들에 위임하고, 실행을 시작한 다음 이 인스턴스들이 결과를 반환할 때까지 대기한다. • 슬레이브들은 각 서브태스크들의 프로세싱을 수행하고, 그 계산 결과들을 마스터에 반환한다. • 마스터는 슬레이브로부터 받은 분할된 결과들을 모아 전체 태스크에 대한 최종결과를 계산한다. • 마스터가 클라이언트에 이 결과를 반환한다.

21. 구현 • 클라이언트가 마스터에게 서비스를 요청한다 • 마스터는 동등한 서브태스크들 몇 개로 태스크를 분할한다. • 마스터는 이 서브태스크들의 실행을 몇 개의 슬레이브인스턴스들에 위임하고, 실행을 시작한 다음 이 인스턴스들이 결과를 반환할 때까지 대기한다. • 슬레이브들은 각 서브태스크들의 프로세싱을 수행하고, 그 계산 결과들을 마스터에 반환한다. • 마스터는 슬레이브로부터 받은 분할된 결과들을 모아 전체 태스크에 대한 최종결과를 계산한다. • 마스터가 클라이언트에 이 결과를 반환한다.

22. 스폰지가 말한다

23. TSP 의 경우 어떻게 처리 할 것인가? 51! 가지의 다른 방법이 존재 Master 모든 순회경로의 개수 / 사용가능한 프로세서의 개수 Slaves

24. 1. 작업을 분할한다. 동등한 서브 태스크들로 나눌 수 있는지 정의 한다. 서브 태스크 하나에서 처리될 필요가 있는 서브 서비스들을 파악 Master Slaves

25. 2. 서브태스크의 결과를 조합 TSP 의 예에서는 비교를 거친 모든 경로들의 하위 집합중에 가장 짧은 경로만 반환 Master Slaves

26. 3. 마스터와 슬레이브 간의 협력을 정의 • 1단계에서 파악한 서브서비스의 인터페이스를 정의 • 이 인터페이스는 슬레이브에 의해 구현됨 • 마스터는 이 인터페이스를 사용해 개별 서브 태스크들의 처리를 위임 서비스실행( 파라미터 리스트) Master Repository Slaves

27. 4. 이전 단계에서 개발된 명세에 따라 슬레이브 컴포넌트를 구현한다.

28. 5. Implementaion Master (Cont’d) • 1~3단계에서 개발된 명세에 따라 마스터 컴포넌트를 구현한다. • 태스크를 서브태스크들로 분할하는 두가지 방식 • 작업을 일정한 개수의 서브태스크들로 나누는 것 • 마스터가 슬레이브들에 태스크 전체의 실행을 위임하는 경우에 가장 적합 • 장애 허용성이나 계산 정확도를 지원하기 위해 Master-Slave 패턴을 적용할 때, 혹인 병렬작업의 전체 개수가 미리 확정되어 있거나 알고 있을 때, 전형적으로 이 방식을 사용한다. • 필요한 개수만큼의 서브태스크들, 혹은 가능한 개수만큼의 서브태스크들로 나누는 것 • 예) TSP 에서 마스터 컴포넌트는 지원가능한 프로세서들의 개수만큼 서브 태스크를 정의 할 수 있다. • Strategy 패턴을 적용하면 태스크를 분할하기 위한 알고리즘 교체시 유용하다.

29. 5. Implementaion Master • 슬레이브를시작시키고 실행을 제어하며 결과를 모으는 코드는 여러가지 요인에 의해 좌우된다. • 슬레이브들이 일정한 순서에 따라 실행되는가? • 독립적인 프로세스나 스레드에서 동시에 실행되는가? • 슬레이브들이 서로 독립적인가? 아니면 서로 조정되어야 하는가? • 마스터는 슬레이브들로부터 모은 결과에 근거하여 최종결과를 계산한다. • 알고리즘은 어떤 전략을 쓰느냐에 따라 달라지는데 알고리즘의 동적교체와 변형을 지원하기 위해서 Strategy pattern 을 적용해야 한다. • Master-Slave 구조 내에는 오직 하나의 마스터 컴포넌트가 있다. 이런 특징의 보장을 위해 Singleton pattern 을 적용가능하다.

30. 변형 • 장애 허용성을 위한 Master-Slave 패턴 • 병렬 계산을 위한 Master-Slave 패턴 • 계산 정확도를 위한 Master-Slave 패턴 • Slaves as Process 변형 • Slaves as Threads 변형 • 슬레이브를 조정하는 Master-Slave 패턴

31. 장애 허용성을 위한 Master-Slave 패턴 • 마스터는 정해진 개수의 복제된 구현물에 서비스의 실행을 단지 위임 • 구현물은슬레이브 • 첫 슬레이브의 실행이 끝나자마자, 결과는 마스터의 클라이언트에 반환 • 장애 허용성이란, 최소한 하나의 슬레이브는 장애가 발생하지 않고 제대로 동작시켜서 항상 클라이언트에 유효한 결과를 제공할 수있는 상황을 지원하는 것

32. 병렬 계산을 위한 Master-Slave 패턴 • 가장 일반적으로 적용되는 경우 • 마스터는 복잡한 태스크를 여러 개의 동일한 서브 태스크로 분할 • 각 서브태스크는 독립적인 슬레이브에 의해 병렬적으로 실행 • 마스터는 슬레이브로부터 얻어온 결과들에 근거해 최종 결과를 계산 • 마스터는 전체 태스크를 분할하는 전략과 최종 결과를 계산하는 전략으로 구성됨 • Barrier 개념을도입하여 슬레이브를개별적으로 동기화하는 태스크로부터 마스터가 영향 받지 않도록 한 경우도 있음

33. AbstractSlave ConcreteSlaveA ConcreteSlaveB subService subService subService Master mySlaves splitWork callSlaves combineResults service 계산 정확도를 위한 Master-Slave 패턴 • 서비스의 실행은 최소한 세 개의 서로 다른 구현물(독립된 슬레이브)에 위임됨. • 마스터는 모든슬레이브가 작업을 마칠 때까지 기다리며 부정확도를 탐지해 처리하기 위해 결과를 판별한다. 서브 태스크 실행 위임

34. Slaves as Process 변형 • 슬레이브들을 독립적인 프로세스들에서 실행시키기 위해, 본래의 Master-Slave 구조에 두 개의 컴포넌트를 추가함 • 마스터를 위해 동작하는 모든 슬레이브들을 추적하기 위한 상위 컴포넌트를 마스터에 구현 • 마스터와 상위 컴포넌트를 분산 슬레이브들의 물리적인 위치로부터 독립되도록 유지 • Remote Proxy 변형( 슬레이브 역할 ) 을 적용한다. • IPC(Interprocess communication)를 구현할 수 있다. • Forwarder-Receiver 패턴 • Client-Dispatcher-Server 패턴 을 적용

35. Slaves as Thread 변형 • 모든슬레이브는 자체 스레드 내에서 구현된다. • ActiveObject 패턴을 적용하면 이런 구조를 구현하기에 유용하다. • 마스터가 처리해야 할 문제 • “스레드가 생성될 수 없을 경우 어떻게 해야하는가?” • “얼마나 많은 스레드를 생성할 수 있는가?”

36. 슬레이브를 조정하는 Master-Slave 패턴 • 한 슬레이브의 계산이 다른 슬레이브의 계산 상태에 따라 좌우되는 경우가 있다. • 각 슬레이브를 자체 안에 슬레이브 조정을 위한 제어로직을 포함하는 것 • 마스터가 슬레이브들 간의 종속성을 관할함으로써 슬레이브 조정을 제어하는 것

37. 용례 • 행렬 곱셈 • 이미지 변환 코드 • 두 신호의 상호상관 계산 • 워크 풀 모델 • 개글 ( gaggle )

38. 결과 • 장점 • 교환가능성과 확장성이 도입된다. • 역할의 분리 ( separation of concerns ) 가 가능 • 효율이 향상된다. • 단점 • 실행가능성이 떨어진다. • 머신 종속성의 제약을 받는다. • 구현이 어렵다 • 이식성이 떨어진다.

39. See Also • Proxy Pattern • Singleton Pattern • Forwarder-Receiver Pattern • Client-Dispatcher-Server Pattern • Broker Pattern • Coordinator Pattern • Active Object • 자바 병렬 프로그래밍 :멀티코어를 100% 활용하는

40. References • Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma, R.Helm, R. Johnson, J. Vlissides, Addison-Wesley, 1995 • Pattern Oriented Software Architecture: A System of Patterns, F. Buschmann, R.Meunier, H. Rohnert, P. Sommerlad, M. Stal, Wiley, 1996 • 패턴지향 소프트웨어 아키텍처 ( 번역판 ) , 김지선 역 • Devpia ( Architecture 마을 , POSA1 스터디: Master-Slave)손영수님 발표자료