Ch17. 분산 소프트웨어 공학

Ch17. 분산 소프트웨어 공학

📌 [교재] 소프트웨어 공학 10판

[분산 시스템] : Distributes systems

최근 대부분의 컴퓨터 기반 시스템이 분산 시스템

✅분산 시스템의 장점

▷자원 공유(resource sharing)

• 하드웨어 및 소프트웨어 자원을 공유

▷개방성(openness)

• 표준 인터넷 프로토콜을 준수, 여러 공급업체의 장비와 소프트웨어 사용

▷동시성(concurrency)

• 여러 프로세스들이 동시에 수행

▷확장성(scalability)

• 새로운 자원을 추가하여 처리 능력(throughput)을 올림

▷결함 내성(fault tolerance)

• 결함이 발생하였을 때에도 서비스를 제공할 수 있는 능력

✅분산 시스템은 중앙 집중 시스템보다 더 복잡

• 설계, 구현, 테스트가 어려움
• 복잡성으로 인해 생기는 특성

✅전체 시스템의 성능은 네트워크의 영향을 많이 받음

• 네트워크 대역폭, 네트워크 부하

✅분산 시스템의 응답 시간 예측이 어려움

• 전체 시스템의 부하, 시스템 아키텍처, 네트워크 부하 등에 영향을 받음

17.1 분산 시스템

[분산 시스템 설계 시 고려할 사항] : Design issues

투명성(transparency)

• 사용자에게 어느 수준까지 단일 시스템으로 보여야 하는지

개방성(openness)

• 상호운용성(interoperability) 있는 표준 프로토콜, 특화 프로토콜 사용

확장성(scalability)

• 확장 가능하도록 어떻게 설계

보안(security)

• 보안 정책의 정의와 구현

서비스 품질(quality of service) : QoS

• 서비스 품질의 정의와 구현

고장 관리(failure management)

• 고장의 감지, 컴포넌트 고장 시 운영, 수리

[투명성과 개방성] : Transparency & Openness

투명성

• 시스템이 분산되었따는 것이 사용자에게 감추어짐
• 추상화를 통해 시스템 자원을 숨기면 애플리케이션 변경 없이 자원을 이동시키거나 추가할 수 있음

개방성

• 표준을 준수하여 컴포넌트를 개발하면 서로 다른 프로그래밍 언어로 구현해도 상호 연동이 가능함
• CORBA(Common Object Request Broker Architecture) 표준, EJB(Enterprise Java Beans) 표준
• 웹 서비스 표준, RESTful 프로토콜

[확장성과 보안] : Scalability & Security - 그냥 넘어감

✅확장성

• 시스템에 대한 요구 증가에도 고품질의 서비스를 제공할 수 있는 능력
• 크기(size) : 사용자 증가에 따른 추가 자원 할당이 가능해야 함
• 분산(distribution) ;컴포넌트의 성능을 저하시키지 않고 지리적으로 시스템을 분산시킬 수 있어야 함
• 관리성(manageability)

:시스템의 일부가 독립적인 조직에 위치한 경우라도 시스템의 크기가 증가함에 따라 관리가 가능해야 함

▷수직 확장(scaling-up): 기존 자원의 성능을 향상

▷수평 확장(scaling-out): 자원을 추가배치

✅보안

• 가로채기(interception), 차단(interruption), 수정(modification), 위조(fabrication) 공격 유형

[서비스 품질과 고장 관리] : Quality of service & Failure management

✅서비스 품질

• 확실성 있는 서비스를 제공하여 납득할 수 있는 응답시간과 처리능력을 가짐
• 피크타임에 높은 품질의 서비스를 제공할 수 있는 시스템은 비용 효율적이지 않음
• → 클라우드 컴퓨팅 사용
• 서비스 품질 요소들의 상충 가능

✅ 고장 관리

• 분산 시스템에서 장애의 발생은 불가피
• 장애 발생 시 회복이 가능하도록 설계해야 함

[1. 모델의 상호작용]

[모델의 상호작용] : Models of interaction

✅분산 시스템의 컴포넌트 간 상호작용

• 절차적 상호 작용 (procedural interaction)
• 메시지 기반 상호작용 (message-based interaction)

✅절차적 상호작용 (procedural interaction) : ‘동기’

• 다르 커뮤터에 의해 제공되는 서비스를 호출
• 호출에 대한 응답이 올 때까지 기다림(동기)

✅메시지 기반 상호작용(message-based interaction) : ‘비동기’

• 필요한 정보를 메시지 형태로 다른 컴퓨터에 전송
• 응답을 기다리지 않음(비동기)

[원격 프로시저 호출] : RPC (Remote Procedure Calls)

✅절차적 통신

• 원격 프로시저 호출로 구현, Java RMI 등
• 다른 컴포넌트가 제공하는 서비스를 로컬 프로시저나 메소드처럼 호출
• 미들웨어가 호출을 원격 컴포넌트에 전달하고 호출한 컴포넌트에 결과를 반환
• 스텁(stub)은 원격 프로시저의 인터페이스를 정의
• 호출/피호출 측이 동시에 가용해야 함

✅통신 순서

• 로컬 컴포넌트가 스텁을 호출하면 매개변수들을 전송 표준 표현으로 변환하여 미들웨어를 통해 원격 프로시저에 요청을 보냄
• 원격 프로시저는 매개변수들을 필요한 형식으로 변환하여 계산을 수행하고 미들웨어를 통해 결과를 반환
• 로컬 컴포넌트는 스텁을 통해 반환값을 받음

[메시지 전달] : Message passing

✅메시지 전달

• 수신자가 메시지를 받을 수 없으면 미들웨어의 큐에 메시지를 보관
• 송신자가 수신자의 위치나 이름을 알 필요가 없음
• 미들웨어가 메시지의 전달을 보장

✅통신 순서

• 서비스에 필요한 상세한 메시지를 생성하여 미들웨어로 전달
• 미들웨어가 수신 컴포넌트로 메시지를 전송
• 수신자는 메시지를 해석하여 계산을 수행하고 결과 메시지를 생성
• 수신 컴포넌트가 결과 메시지를 미들웨어에 전달하면 송신 컴포넌트로 전송됨

[2. 미들웨어]

[미들웨어] : Midddleware

✅ 미들웨어

• 운영체제와 애플리케이션 사이에서 공통 서비스를 제공
• 트랜잭션 관리자, 데이터 변환기 등

✅ 분산 시스템의 미들웨어

• 상호작용 지원

: 위치 투명성(location transparency)

: 언어, 플랫폼 독립성

• 공통 서비스의 제공

: 여러 컴포넌트에서 재사용 가능한 서비스를 제공

: 보안, 알림, 네이밍, 트랜잭션 관리 서비스 등

17.2 클라이언트-서버 컴퓨팅

[클라이언트-서버 컴퓨팅] Client-server computing

✅ 인터넷을 이용하는 분산 시스템

• 클라이언트 : 웹브라우저, 모바일앱, 사용자와 상호작용하는 프로그램
• 서버 : 웹서버 등 서비스를 제공하는 프로그램(프로세스)

✅ 클라이언트-서버 아키텍처

• 서버가 제공하는 서비스의 집합
• 클라이언트는 서버가 어디에 있는지 알아야 함

✅ 대부분 서버는 멀티 프로세서 시스템

• 하나의 서버 프로세스는 여러 프로세서 중 하나에서 실행
• 부하균형(load balancing) 소프트웨어가 필요할 수 있음
• 서버 프로세스의 인스턴스를 관리

[클라이언트/서버 시스템의 4가지 계층*] Layers in a client/server system**

✅ 표현(presentation) 계층 = Gui라고 생각

• 사용자에게 정보 표현, 사용자 상호작용 관리

✅ 데이터 처리(data-handling) 계층 = 통신처럼 생각

• 클라이언트로부터 전송되는 데이터를 관리, 웹 페이지 생성 등
• Web server

✅ 애플리케이션 처리(application processing) 계층

• 애플리케이션 논리의 구현
• Application server

✅ 데이터베이스(database) 계층

• 데이터를 저장하고 쿼리 서비스를 제공
• DBMS

17.3 분산 시스템을 위한 아키텍처 패턴

[아키텍처 스타일] (5가지) : Architectural patterns

시스템에서 요구하는 중요한 비기능적인 요구사항을 지원하는 아키텍처 스타일을 선택해야 함

✅ 분산 시스템의 아키텍처 스타일 예시

(1) 마스터-슬레이브 아키텍처

• 최소한의 응답시간을 보장해야 하는 실시간 시스템에 주로 사용

(2) 2단 클라이언트-서버 아키텍처

(3) 다단 클라이언트-서버 아키텍처

• 대량의 트랜잭션을 처리

(4) 분산 컴포넌트 아키텍처

• 다양한 시스템의 자원을 동적으로 결합하여 사용

(5) 피어-투-피어 아키텍처

• 클라이언트와 서버의 구분이 없음

[1. 마스터-슬래이브 아키텍처] : 그냥 넘김

[2. 2단 클라이언트-서버 아키텍처] : Two-tier client server architectures

✅ Thin 클라이언트 모델

• 표현 계층만 클라이언트에서 구현. 나머지 계층은 서버에서 구현
• 클라이언트는 웹 브라우저 or 모바일 앱

✅ Fat 클라이언트 모델

• 표현과 애플리케이션 처리(의 일부)를 클라이언트에서 구현, 데이터베이스 기능을 서버에서 구현
• 클라이언트는 전용 프로그램

Thin 클라이언트 모델 • 클라이언트 관리가 간단 • 서버와 네트워크에 부하 Fat 클라이언트 모델 • 클라이언트 컴퓨터의 자원(처리능력)을 활용 • 클라이언트 프로그램을 배포하고 유지하기 위한 관리 필요 Thin 클라이언트오 Fat 클라이언트의 구분 무의미해짐

 

[3. 다단 클라이언트-서버 아키텍처] : Multi-tier client-server architectures

✅ 2단 클라이언트-서버 모델

• thin 클라이언트는 확장성과 성능 문제, fat 클라이언트는 시스템 관리 문제

✅ 3단 클라이언트-서버 모델

• 웹 브라우저
• 웹 서버
• 데이터베이스 서버

✅ 다단 클라이언트-서버 모델

• 웹서버, 애플리케이션 서버
• 확장성이 좋음
• 수많은 클라이언트가 있는 애플리케이션에 적합

[4. 분산 컴포넌트 아키텍처] : Distributed component architectures

✅ 분산 컴포넌트 아키텍처

• 상호작용(서비스 제공/사용)하는 컴포넌트들의 집합으로 구성
• 각 컴포넌트는 제공하는 서비스에 대한 인터페이스를 제공
• 미들웨어를 통해 서비스를 호출(Remote Procedure Call)

✅ 분산 컴포넌트 미들웨어

• 컴포넌트 간 상호작용을 관리하고 공통 서비스 집합을 제공
• CORBA (Common Object Request Broker Architecture)

✅ 분산 컴포넌트 모델의 장점

• 서비스가 어디서 제공되어야 하는지 결정을 실행 시까지 연기 가능
• 새로운 자원을 추가하는 것이 쉬움
• 유연하고 확장성이 좋음
• 시스템을 동적으로 재구성할 수 있음

✅ 분산 컴포넌트 모델의 단점

• 복잡성 : 클라이언트-서버 시스템보다 복잡
• 미들웨어 : 표준 분산 컴포넌트 모델이나 미들웨어가 없음

✅ 서비스 지향 아키텍처(Service-Oriented Architecture: SOA)

• 분산 컴포넌트의 개념을 이용, 더 큰 단위의 서비스를 제공
• 메시지 기반 상호작용

[5. 피어-투-피어 아키텍처] :Peer-to-peer architectures

✅ 피어-투-피어 아키텍처

• 네트워크 상의 어떤 노드도 주어진 연산을 수행할 수 있는 비중앙집중적(decentralized) 시스템
• 서버와 클라이언트의 구분이 없음
• 네트워크 상에 존재하는 수많은 컴퓨터의 자원(저장공간, 연산능력)을 활용

✅ 피어-투-피어 시스템

• Bitcoin, BitTorrent 등
• SETI@Home은 grid computing 의 일종

17.4 서비스로서의 소프트웨어 ( SOA 와는 다름)

[서비스로서의 소프트웨어] : Software as a service

✅ 서비스로서의 소프트웨어 (SaaS)

• SW는 서버에 설치되어 실행되고 웹 브라우저를 통해 접근
• SW는 소프트웨어 제공자가 소유하고 관리
• 사용량이나 구독에 의해 소프트웨어 비용을 지불
• ex) Google Docs, Office365 등

✅ 클라우드 컴퓨팅의 발전으로 SaaS 보급이 증가

✅ SaaS와 SOA 차이 구분

• SaaS는 웹 브라우저를 통해 접근하는 클라이언트에게 원격 서버가 기능을 제공,

문서 편집과 같은 긴 트랜잭션

: 애플리케이션 기능을 사용자에게 제공

• SOA는 서비스의 집합으로 시스템을 구성, 서비스는 다중 제공자에 의해 제공될 수 있음

서비스 호출-작업 수행-결과반환의 짧은 트랜잭션

: 애플리케이션 시스템을 구현하는 기술