1. 멀티프로세서 아키텍쳐(Multiprocessor architectures)
1) 분산 시스템(distributed system)의 개요
멀티프로세서 아키텍쳐(Multiprocessor architectures)에 대해 살펴보기 전에 ‘ 분산 시스템 (distributed system)’에 대해 좀 더 자세히 알아보도록 하겠습니다.
앞에서 정리한 특징 이외에 분산 시스템은 다음과 같은 4가지 단점을 가지고 있습니다.
복잡성 (Complexity) | 창발적 속성(emergent properties)을 이해하기 어렵고 시스템 검사가 어렵기 때 문에 중앙처리 시스템보다 훨씬 복잡하다. (예 : 성능이 네트워크 밴드위드나 다른 여러 컴퓨터 속도에 좌우됨, 어떤 프로세서에 어떤 자원을 둘 것인가도 성능에 영향을 줌.) |
보안 (Security) | 시스템은 다양한 컴퓨터로부터 접근 가능하며, 네트워크의 트래픽이 노출되기 쉬우므로 보안관리가 다른 시스템들에 비해 상대적으로 어렵다. |
관리 (Manageability) | ⬛ 다양한 컴퓨터들은 다양한 버전, 운영체제 등을 가지므로 이러한 다양한 환경에 대해 고려해주어야 한다. ⬛ 결함의 전이 가능성은 불확실성을 증대시킨다. |
예측불가능 (Unpredictability) | 분산 시스템의 반응(reponse)에 대해서는 예측불가능하다. 시스템을 둘러싸고 있는 다양한 환경때문인데, 예를 들어 시스템의 부하, 시스템의 구성 및 네트워 크의 트래픽 등을 예측하기 어렵기 때문이다. |
<분산 시스템의 설계 이슈>
Design Issue |
Description |
Resource identification |
여러 컴퓨터에 분산되어 있으므로 자원을 찾아 사용할 수 있게끔 naming scheme이 필요 (예 : URL) |
Communications |
성능이나 신뢰도와 같은 특별한 요구가 있다면 다른 통신 방법도 필 요 |
Quality of service |
성능, 이용성, 신뢰도를 의미하며 프로세스의 할당, 자원의 분산, 네 트워크와 시스템 하드웨어, 그리고 시스템의 적응성(adaptability)등 과 관련됨. |
Software architectures |
응용의 기능이 컴포넌트로 구성되어 어떻게 프로세서에 분산되는가 의 문제로 올바른 아키텍쳐를 선택해야 서비스의 질을 향상시킬 수 있음. |
<Issues in distributed systems design>
Design issue | Description |
Resource identification |
The resource in a distributed system are spread across different computers and a naming scheme has to be devised so that users can discover and refer to the resources that they need. An example of such a naming scheme is the URL (Uniform Resource Locator) that is used to identify WWW pages. If a meaningful and universally understood identification scheme is not used then many of these resources will be inaccessible to system users. |
Communications |
The universal availability of the Internet and the efficient implementation of Internet TCP/ IP communication protocols means that, for most distributed systems, these are the most effective way for the computers to communicate. However, where there are specific requirements for performance, reliability, etc, alternative approaches to communications may be used. |
Quality of service | The quality of service offered by a system reflects its performance, availability and reliability. It is affected by a number of factors such as the allocation of processes to processes in the system, the distribution of resources across the system, the network and the system hardware and the adaptability of the system. |
Software architectures | The software architercture describes how the applicatiion functionally is distribed over a number of logical components and how these components are distributed across processors. Choosing the right architecture for an application is essential to achieve the desired quality of service. |
2) 멀티프로세서 아키텍처 개요
- 가장 간단한 분산 시스템 모델
- 서로 다른 프로세서(processor)에서 실행되는 복수개의 프로세스(processes)로 구성된 시스템
- 큰 규모의 실시간 시스템(large real-time systems)에서 흔하다.
- 실시간 시스템은 11주차(13장)에서 다룹니다.
□ 멀티프로세서 아키텍쳐란?
① 가장 간단한 분산 시스템 모델
② 서로 다른 프로세서(processor)에서 실행되는 복수개의 프로세스(processes)로 구성된 시스템
③ 큰 규모의 실시간 시스템(large real-time systems)에서 흔함.
다중 프로세스라 하여 반드시 분산 시스템일 필요는 없으며, 설계 과정에서 distribution issues 를 항상 고려해야 하는 것은 아닙니다.
⊙ 특징
□ 서버(servers)에 의해 제공되는 서비스들(services)의 집합과 이러한 서비스를 이용하는 클라이언트(clients)들의 집합으로 구성된 모델이다.
□ 클라이언트는 서버를 알아야 하지만, 서버는 클라이언트에 대해 알 필요가 없다.
□ 클라이언트와 서버는 논리적인 프로세스이다.
□ 프로세서(processors)와 프로세스(processes)의 매핑이 꼭 1:1일 필요는 없다.
1) 개요
2) 계층 응용 아키텍쳐(Layered application architecture)
클라이언트 서버 시스템을 설계할 때는 application의 논리적 구조를 반영해야 하는데, 구조에서와 같이 3계층으로 나눕니다.
표현 계층 (Presentation layer) | 사용자에게 정보를 제시하고, 사용자와 상호작용하는 부분 |
응용 처리 계층 (Application processing layer) |
응용의 논리적인 내용을 구현한 부분 |
데이터 관리 계층 (Data management layer) |
데이터베이스 조작과 관련된 부분 |
3) Thin/Fat client
클라이언트-서버 모델 중 가장 간단한 것이 2-Tier 클라이언트-서버 아키텍쳐입니다.
2-Tier 클라이언트-서버 아키텍쳐는 다음과 같이 Thin/Fat client의 2가지 형태를 가지게 됩니다.
Thin client model | Fat client model |
⬛ 모든 응용 처리(application processing) 및 데이터 관리(data management)가 서버에서 수행되고, 클라이언트는 표현(presentation) 계층만 구현하게 된다. ⬛ 레거시 시스템(legacy systems)을 클라이언트-서버 아키텍쳐로 바꿀 때 사용 된다. ⬛ 단점 : 서버와 네트워크에 걸리는 부하가 크다. |
⬛ 서버는 데이터 관리(data management)에만 관여하고, 클라이언트상의 소프트웨어에 응용 로직(application logic)과 표현(presentation) 부분이 구현된다. ⬛ 응용 처리가 클라이언트에 넘겨져서 로컬 (local)에서 실행되기 때문에 클라이언트에 더 많은 부하가 걸린다. (서버의 부하가 클라이언 트에 넘겨진다.) ⬛ 클라이언트 컴퓨터의 사양이 응용 처리를 하기에 충분할 경우 많이 사용된다. ⬛ 단점 : 관리적인 면에 있어서는 thin client model 보다 복잡하다. 새로운 버전의 애플리 케이션이 출시된다면 모든 클라이언트에 배포 되어 설치되어야 한다. ⬛ 예 : Banking ATM 시스템, 여기서 ATM은 클라이언트이며 서버는 mainframe |
4) 3-Tier 아키텍쳐
2-Tier 클라이언트-서버의 문제점은 논리적인 3개의 계층을 2개의 컴퓨터 시스템에 분배했다는 것으로 이는 확장성(scalability)이나 성능(performance) 또는 관리상의 문제(fat client)를 일으킬 수 있습니다.
이에 대한 대안으로 3-Tier 클라이언트-서버 아키텍쳐를 사용하며, 3-Tier 클라이언트-서버 아키 텍쳐의 특징으로는 다음 3가지를 들 수 있습니다.
1. 각각의 응용 아키텍쳐 계층은 서로 다른 프로세서(processor)상에서 수행된다.
2. thin-client보다 높은 성능을 제공하며, fat-client의 경우보다 쉽게 관리할 수 있다.
3. 서버의 부하가 커지거나 요구가 증가할 경우, 여분의 서버를 추가하기만 하면 되므로 아키텍쳐 확장성이 우수하다. (예를 들어 사용자가 증가하면 웹 서버를 추가한다. 특히 애플 리케이션 처리 부분은 가장 자주 바뀌기 쉬운 부분이다.)
<3-Tier 클라이언트-서버 아키텍쳐>
<인터넷 뱅킹 시스템에서의 분산 아키텍쳐>
Web server 와 database server 간에는 internet standards가 필요 없으므로 faster & lower-level communication protocol을 사용하여 transfer를 optimize 할 수 있습니다. 데이터베이스 쿼리 처리 를 위한 efficient middleware인 SQL을 사용합니다.
5) 클라이언트-서버 아키텍쳐의 사용
Thin client를 이용한 2-Tier 클라이언트 서버 아키텍쳐 |
⬛ 응용 처리(application processing) 부분과 데이터 관리(data management) 부분을 분리시키는 것이 어려운 레거시 시스템 애플리케이션 ⬛ 데이터 관리(data management)가 거의 필요하지 않은 컴파일러 (compiler) 같은 계산 중심의 애플리케이션 ⬛ 응용 처리가 거의 필요하지 않은 데이터 중심(data-intensive)의 애플리케이션(웹 검색, 쿼리 등) |
Fat client를 이용한 2-Tier 클라이언트 서버 아키텍쳐 |
⬛ 응용 처리(application processing)가 클라이언트 상에서 COTS (예 : Microsoft Excel)로 제공되는 애플리케이션 ⬛ 데이터를 계산하거나 처리하는 것의 비중이 큰 애플리케이션 ⬛ 잘 구성된 시스템 환경에서 안정화 된 애플리케이션 |
3-Tier 클라이언트 서버 아키텍쳐 |
⬛ 클라이언트의 수가 많은 대규모 애플리케이션 ⬛ 데이터와 응용 로직이 자주 바뀌는 경우의 애플리케이션 ⬛ 다양한 소스로부터 구해진 데이터가 통합되어야 하는 애플리케이션 |
<Use of different client-server architectures>
Architecture | Applications |
Two-tier C/S architecture with thin cllients | Legacy system applications where separating application processing And data management is impractical Computationally intensive applications such as compilers with little or no data management Data-intensive applications (browsing and querying) with little or no application processing |
Two-tier C/S architecture with fat cllients | Applications where application processing is provided by COTS (e.g. Microsoft Excel) on the client Applications where computationally intensive processing of data (e.g. data visualisation) is required Applications with relatively stable end-user functionality used in an environment with well-established system management |
Two-tier or Multi-tier C/S architecture | Large-scale applications with hundreds or thousands of clients Applications where both the data and the application are volatile Applications where data from multiple sources are integrated |
3. 분산 객체 아키텍쳐(Distributed object architectures)
다음 내용 중, 분산 객체 아키텍처에 대해 올바르게 설명하고 있는 것을 모두 고르세요.
□ 분산 객체 아키텍쳐에서는 클라이언트와 서버간의 차이점이 거의 없다.
□ 각각의 분산 요소는 다른 객체들에게 서비스를 제공하기도 하고, 반대로 다른 객체들로부터 서비스를 받기도 한다.
□ 객체간의 통신은 ORB(Object request broker)라고 불리는 미들웨어(middleware) 시스템을 이용 하게 된다.
(software bus)
□ 클라이언트-서버 시스템보다 설계하기가 쉽다.
분산 객체 아키텍쳐(Distributed object architectures)의 특징은 다음과 같습니다.
⊙ 특징
분산 객체 아키텍쳐에서는 클라이언트와 서버간의 차이점이 거의 없다.
각각의 분산 요소는 다른 객체들에게 서비스를 제공하기도 하고, 반대로 다른 객체들로부터 서비스를 받기도 한다. 객체간의 통신은 ORB(Object request broker)라고 불리는 미들웨어(middleware) 시스템을 이용하게 된다. (software bus) 클라이언트-서버 시스템보다 설계하기가 어렵다.
1) 개요
클라이언트-서버 모델은 서버와 클라이언트를 미리 정해야 한다는 점에서 시스템 설계상 유연성 이 많이 떨어집니다. 클라이언트-서버 모델은 클라이언트와 서버간의 차이를 없애고, 동일하게 분산시킨 객체로써 아키텍쳐를 구성할 수 있습니다.
2) 장점
클라이언트-서버 모델의 장점으로는 다음 4가지를 들 수 있습니다. 앞서 살펴본 클라이언트-서버 모델의 특징을 떠올리면서 살펴봅시다.
1. 시스템 설계자가 어디서(where), 어떻게(how) 서비스가 제공되어야 하는지에 대한 판단을 뒤로 미룰 수 있다. 즉, 시스템 설계자에게 유연성을 제공한다.
2. 새로운 리소스(resource)가 추가되기 쉬운 열린 시스템(open system)이다. 예를 들어 다른 언 어로 작성된 객체끼리 통신할 수 있다.
3. 시스템이 유연하며(flexible), 확장성(scalable)이 좋다. 예를 들어 시스템 부하에 대비하기 위해 같은 서비스를 다른 객체가 제공할 수 있고 새로운 객체를 추가시킬 수도 있다.
4. 네트웍을 통해 객체를 주고 받으면서 시스템을 동적으로 재구성하는 것이 가능하다.예를 들어 성능 때문이라면 서비스 제공 객체를 서비스 요구 객체와 같이 둘 수 있다.
3) 사용
클라이언트-서버 모델은 다음과 같은 2가지 방식으로 사용 가능합니다.
1. 시스템을 구조화하고 조직할 수 있도록 논리적인 모델로 사용가능하다.
이 경우, 서비스나 서비스의 조합으로 어떻게 애플리케이션의 기능을 제공할지에 대해 생각하면 된다. 이 수준에서 객체들은 large-grain objects(domain-specific business objects)이다.
2. 클라이언트-서버 시스템의 구현을 위한 유연성 있는 접근법으로 사용가능하다. 논리적으로는 클라이언트-서버 시스템이지만 각각의 클라이언트와 서버가 분산 객체로 구현되어 소프트웨어 버스(software bus)위에서 통신하게 된다. 클라이언트나 서버를 하나가 아닌 많은 작은 객체들로 구성할 수 있다.
4) 데이터 마이닝 시스템의 분산 아키텍쳐
<그림 설명>
여러 데이터베이스에 저장된 데이터간의 관계를 찾아야 한다.
예를 들어 여러 종류 의 상점을 운영할 때, baby food를 사는 사람은 특정 wallpaper를 찾는다. 각각의 데이터베이스는 하나의 분산 객체이다. 통합 객체는 특정 관계를 의미한다. (예를 들어 다른 종류의 상품간의 관계, 상품의 계절적 변이)
⬛ 데이터 마이닝에 분산 객체가 적당한 이유
① 한 가지가 아닌 다양한 서비스가 존재
② 전체 시스템에 영향을 주지 않으면서 데이터베이스의 확장을 가능하게 함.
③ 다른 통합 객체에 대한 지식 없이 사업 부서별로 관심 있는 관계의 마이닝을 위해 새로운 통합
④ 객체를 추가하여 시스템을 확장할 수 있음.
[정리하기]
▣ 분산 시스템은 리소스 공유(resource sharing), 개방성(openness), 병행성(concurrency), 확장성(scalability), 결함 내구성(fault tolerance)과 투명성(transparency)을 지원한다.
▣ 클라이언트-서버 아키텍쳐는 클라이언트의 요청에 의해 서버가 서비스를 제공한다.
▣ 사용자 인터페이스(user interface) 소프트웨어는 항상 클라이언트에서 동작되고, 데이터 관리(data management) 부분은 항상 서버에서 실행된다.
▣ 분산 객체 아키텍쳐에서는 클라이언트와 서버를 구분하지 않는다.
▣ 분산 객체 시스템은 객체들간의 통신을 위해 미들웨어(middleware)를 사용한다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
재사용을 통한 설계 (1) | 2023.11.28 |
---|---|
실시간 소프트웨어 설계 (2) | 2023.11.26 |
아키텍쳐 설계 (1) | 2023.11.25 |
시스템 모델 (1) | 2023.11.25 |
요구 공학 프로세스 (2) | 2023.11.25 |