소프트웨어 공학 - Chpater 17. 분산 소프트웨어 공학

대학교 3학년 때 PaaS-TA 를 동기와 사용해보려고 한 적이 있다.

대학교 특강도 있었는데 듣고 싶었지만 과 전체로 하는 필수 1박2일 프로그램으로 인해 듣지 못했었는데 개발 가이드만 보고 이용해보기엔 어려웠다.

요즘들어 인생이 힘들다고 느끼지만 최선을 다하고자 꾸준히 배운걸 다시 기억하는 차원에서 포스팅한다.

분산 소프트웨어 공학 목차

• 분산 시스템
• 클라이언트 - 서버 컴퓨팅
• 분산 시스템을 위한 아키텍처 패턴
• 서비스로서의 소프트웨어

Distributed Systems [516p]

• 최근 대부분의 컴퓨터 기반 시스템이 분산 시스템
  • 사용자에게 하나의 시스템으로 보이는 독립적인 컴퓨터들의 집합
    
• 분산 시스템의 장점 5 가지
  • 자원 공유 (Resource Sharing)
    • 하드웨어 및 소프트웨어 자원을 공유할 수 있도록 한다.
  • 개방성 (Openness)
    • 표준 인터넷 프로토콜을 준수, 여러 공급업체의 장비와 소프트웨어 사용 가능하다
  • 동시성 (Concurrency)
    • 여러 프로세스들이 동시에 수행할 수 있다
  • 확장성 (Scalability)
    • 새로운 자원을 추가하여 처리 능력 (Throughput) 을 올림
  • 결함 내성 (Fault Tolerance)
    • 결함이 발생하였을 때에도 서비스를 제공할 수 있는 능력

Distributed Systems [517p]

• 분산 시스템은 중앙 집중 시스템보다 더 복잡
  • 설계, 구현, 테스트가 어려움
  • 복잡성으로 인해 생기는 특성
• 전체 시스템의 성능은 네트워크의 영향을 많이 받음
  • 네트워크 대역폭, 네트워크 부하
• 분산 시스템의 응답, 시간 예측이 어려움
  • 전체 시스템의 부하, 시스템 아키텍처, 네트워크 부하 등에 영향을 받음

Design Issues [517~518p]

• 투명성 (Transparency)
  • 사용자에게 어느 수준까지 단일 시스템으로 보여야 하는지
• 개방성 (Openness)
  • 상호운용성 (Interoperability) 있는 표준 프로토콜, 특화 프로토콜 사용
• 확장성 (Scalability)
  • 확장 가능하도록 어떻게 설계
• 보안 (Security)
  • 보안 정책의 정의와 구현
• 서비스 품질 (Quality of Service)
  • 서비스 품질의 정의와 구현
• 고장관리 (Failure Management)
  • 고장의 감지, 컴포넌트 고장 시 운영, 수리

Transparency & Openness [518~519p]

• 투명성
  • 시스템이 분산되었다는 것이 사용자에게 감추어짐
  • 추상화를 통해 시스템 자원을 숨기면 애플리케이션 변경 없이 자원을 이동시키거나 추가할 수 있음
    
• 개방성
  • 표준을 준수하여 컴포넌트를 개발하면 서로 다른 프로그래밍 언어로 구현해도 상호 연동이 가능
  • CORBA (Common Object Request Broker Architecture) 표준, EJB (Enterprise Java Beans) 표준
  • 웹서비스 표준, RESTful 프로토콜

Scalability & Security [519~520p]

• 확장성
  • 시스템에 대한 요구 증가에도 고품질의 서비스를 제공할 수 있는 능력
  • 크기 (Size) : 사용자 증가에 따른 추가 자원 할당이 가능해야 함
  • 분산 (Distribution) : 컴포넌트의 성능을 저하시키지 않고 지리적으로 시스템을 분산시킬 수 있어야 함
  • 관리성 (Manageability) : 시스템의 일부가 독립적인 조직에 위치한 경우라도 시스템의 크기가 증가함에 따라 관리가 가능해야 함
  • 수직 확장 (Scaling - up) : 기존 자원의 성능을 향상
  • 수평 확장 (Scailing - out) : 자원을 추가 배치
    
• 보안
  • 가로채기 (Interception)
  • 차단 (Interruption)
  • 수정 (Modification)
  • 위조 (Fabrication) 공격 유형

Quality of service & Failure Management [520~521p]

• 서비스 품질
  • 확실성 있는 서비스를 제공하며 납득할 수 있는 응답 시간과 처리 능력을 가짐
  • 피크 타임에 높은 품질의 서비스를 제공할 수 있는 시스템은 비용 효율적이지 않음, 클라우드 컴퓨팅 이용
  • 서비스 품질 요소들의 상충 가능
    
• 고장 관리
  • 분산 시스템에서 장애의 발생은 불가피
  • 장애 발생 시 회복이 가능하도록 설계해야 함

Models of Interaction [521p]

• 분산 시스템의 컴포넌트 간 상호 작용
  • 절차적 상호 작용 (Procedural Interaction)
  • 메시지 기반 상호 작용 (Message-based Interaction)
    
• 절차적 상호작용 (Procedural Interaction)
  • 다른 컴퓨터에 의해 제공되는 서비스를 호출
  • 호출에 대한 응답이 올 때 까지 기다림
    
• 메시지 기반 상호작용 (Message-based Interaction)
  • 필요한 정보를 메시지 형태로 다른 컴퓨터에 전송
  • 응답을 기다리지 않음

Remote Procedure calls [522~523p]

• 절차적 통신
  • 원격 프로시저 (Remote Procedure call) 호출 로 구현, Java RMI 등
  • 다른 컴포넌트가 제공하는서비스를 로컬 프로시저나 메서드처럼 호출
  • 미들웨어가 호출을 원격 컴포넌트에 전달하고 호출한 컴포넌트에 결과를 반환
  • 스텁 (Stub) 은 원격 프로시저의 인터페이스를 정의
  • 호출 / 피호출 측이 동시에 가용해야 함
    
• 통신 순서
  • 로컬 컴포넌트가 스텁을 호출하면 매개변수들을 전송 표준 표현으로 변환하여 미들웨어를 통해 원격 프로시저에 요청을 보냄
  • 원격 프로시저는 매개변수들을 필요한 형식으로 변환하여 계산을 수행하고 미들웨어를 통해 결과를 반환
  • 로컬 컴포넌트는 스텁을 통해 반환값을 받음

Message Passing [523p]

• 메시지 전달
  • 수신자가 메시지를 받을 수 없으면 미들웨어의 큐에 메시지를 보관
  • 송신자가 수신자의 위치나 이름을 알 필요가 없음
  • 미들웨어가 메시지의 전달을 보장
    
• 통신 순서
  • 서비스에 필요한 상세한 메시지를 생성하여 미들웨어로 전달
  • 미들웨어가 수신 컴포넌트로 메시지를 전송
  • 수신자는 메신저를 해석하여 계산을 수행하고 결과 메시지를 생성
  • 수신 컴포넌트가 결과 메시지를 미들웨어에 전달하면 송신 컴포넌트로 전송됨

Middleware [524p]

• 미들웨어
  • 운영체제와 애플리케이션 사이에서 공통 서비스를 제공
  • 트랜잭션 관지라, 데이터 변환기 등
    *분산 시스템의 미들웨어
  • 상호작용 지원
    • 위치 투명성 (Location Transparency)
    • 언어, 플랫폼 독립성
  • 공통 서비스의 제공
    • 여러 컴포넌트에서 재사용 가능한 서비스를 제공
    • 보안, 알림, 네이밍, 트랜잭션 관리 서비스 등

Client - server Computing [525p]

• 인터넷을 이용하는 분산 시스템
  • 클라이언트 :　웹브라우저, 모바일 앱, 사용자와 상호작용 하는 프로그램
  • 서버 : 웹 서버 등 서비스를 제공하는 프로그램 (프로세스)
    
• 클라이언트-서버 아키텍처 (클라이언트 서버 컴퓨팅)
  • 서버가 제공하는 서비스의 집합
  • 클라이언트는 서버가 어디에 있는지 알아야 한다
    
• 대부분 서버는 멀티 프로세서 시스템
  • 하나의 서버 프로세스는 여러 프로세서 중 하나에서 실행
  • 부하 균형 (Load Balancing) 소프트웨어가 필요할 수 있다
  • 서버 프로세스의 인스턴스를 관리

Layers in a client/server System 클라이언트 서버 시스템 계층 [526p]

• 표현 (Presentation) 계층
  • 사용자에게 정보 표현, 사용자 상호작용 관리
    
• 데이터 처리 (Data handling) 계층
  • 클라이언트로부터 전송되는 데이터를 관리, 웹 페이지 생성 등
  • Web server
    
• 애플리케이션 처리 (Application Processing) 계층
  • 애플리케이션 논리의 구현
  • Application server
• 데이터베이스 (Database) 계층
  • 데이터를 저장하고 쿼리 서비스를 제공
  • DBMS

Architectural Patterns [527p]

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

• 분산 시스템의 아키텍처 스타일 예시 5 가지

  • 마스터-슬레이브 아키텍처
    • 최소한의 응답시간을 보장해야 하는 실시간 시스템에 주로 사용
  • 2단 클라이언트-서버 아키텍처
  • 다단 클라이언트-서버 아키텍처
    • 대량의 트랜잭션을 처리
  • 분산 컴포넌트 아키텍처
    • 다양한 시스템의 자원을 동적으로 결합하여 사용
  • 피어-투-피어 아키텍처
    • 클라이언트와 서버의 구분이 없음

Two-tier client server Architectures 2단 클라이언트 서버 아키텍처 [529p]

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

Multi-tier Client-server Architectures 다단 클라이언트 서버 아키텍처 [531p]

• 2단 클라이언트-서버 모델
  • Thin 클라이언트는 확장성과 성능 문제, Fat 클라이언트는 시스템 관리 문제
    
• 3단 클라이언트-서버
  • 웹 브라우저
  • 웹 서버
  • 데이터베이스 서버
    
• 다단 클라이언트-서버
  • 웹 서버, 애플리케이션 서버
  • 확장성이 좋음
  • 수많은 클라이언트가 있는 애플리케이션에 적합

Distributed Component Architectures 분산 컴포넌트 아키텍처 [533p]

• 분산 컴포넌트 아키텍처
  • 상호 작용 (서비스 제공 / 사용) 하는 컴포넌트들의 집합으로 구성
  • 각 컴포넌트는 제공하는 서비스에 대한 인터페이스를 제공
  • 미들웨어를 통해 서비스를 호출 (Remote Procedure Call)
    
• 분산 컴포넌트 미들웨어
  • 컴포넌트 간 상호작용을 관리하고 공통 서비스 집합을 제공
  • CORBA (Common Object Request Broker Architecture)

Distributed Component Architectures [534~536p]

• 분산 컴포넌트 모델의 장점
  • 서비스가 어디서 제공되어야 하는지 결정을 실행 시까지 연기 가능
  • 새로운 자원을 추가하는 것이 쉬움
  • 유연하고 확장성이 좋음
  • 시스템을 동적으로 재구성할 수 있음
    
• 분산 컴포넌트 모델의 단점
  • 복잡성 : 클라이언트-서버 시스템보다 복잡
  • 미들웨어 : 표준 분산 컴포넌트 모델이나 미들웨어가 없음
• 서비스 지향 아키텍처 (Service-Oriented Architecture : SOA)
  • 분산 컴포넌트의 개념을 이용, 더 큰 단위의 서비스를 제공
  • 메시지 기반 상호작용

Peer-to-peer Architectures 피어 투 피어 아키텍처 [537p]

• 피어-투-피어 아키텍처
  • 네트워크 상의 어떤 노드도 주어진 연산을 수행할 수 있는 비중앙집중적 (Decentralized) 시스템
  • 서버와 클라이언트의 구분이 없음
  • 네트워크 상에 존재하는 수많은 컴퓨터의 자원 (저장 공간, 연산 능력)을 활용
    
• 피어-투-피어 시스템
  • Bitcoin, BitTorrent 등
  • SETI@Home 은 Grid Computing 의 일종

Peer-to-peer Architectures [538~539p]

• 비중앙 집중 아키텍처
  • 네트워크 연결 손실에 대한 내성, 결함 내성
    
• 반 집중 p2p 아키텍처
  • 슈퍼피어 (Super peer) : 정보 제공, 작업 분배, 결과 수집 점검 등

Software as Service [540~542p]

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

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

• SaaS 와 SOA
  • SaaS 는 웹 브라우저를 통해 접근하는 클라이언트에게 원격 서버가 기능을 제공, 문서 편집과 같은 긴 트랜잭션
    • SaaS 는 애플리케이션 기능을 사용자에게 제공하는 방법
  • SOA 는 서비스의 집합으로 시스템을 구성, 서비스는 다중 제공자에 의해 제공될 수 있음, 서비스 호출-작업 수행-결과 반환의 짧은 트랜잭션
    • SOA 는 애플리케이션 시스템을 구현하는 기술

TIP

서비스로서의 소프트웨어의 개념과 서비스 지향 아키텍처(SOA)와 관련성이 있지만 동일하지 않다.

1. 서비스로서의 소프트웨어는 웹 브라우저를 통해 접근하는 클라이언트에게 원격 서비스가 기능을 제공하는 방법 중 하나이다.
   서버는 상호 작용을 위한 세션 동안, 사용자의 데이터와 상태를 유지한다.
   
   
2. 서비스 지향 아키텍처는 소프트웨어 시스템을 별도의 상태가 유지되지 않는 서비스의 집합으로 구조화하는 방법이다.
   이러한 서비스는 다중 제공자에 의해 제공되며 분산될 수 있다. 일반적으로 트랜잭션은 짧으며 서비스가 호출되고 작업을 수행하고 결과를 반환하는 형태이다.