Transcript 클라우드 컴퓨팅 강의 3. 클라우드 컴퓨팅 기술

클라우드 컴퓨팅 강의
3. 클라우드 컴퓨팅 기술
2011년 04월 02일(3주차)
Contents
3.1 클라우드 컴퓨팅 구조
3.2 가상화 기술
3.3 클러스터
3.4 분산 시스템
3.5 서비스 지향 아키텍처
3.6 SaaS 플랫폼
3.7 보안
3.8 그린 컴퓨팅
명지대학교
3.1 클라우드 컴퓨팅 구조
 Cloud Computing 요소기술개념구조
PaaS
SaaS
IaaS
Cloud Computing
Utility Computing
Grid Computing
Cluster Computing
Super Computing
Saas[Software as a Service] :
웹 기반 원격 접근 App.
PaaS[Platform as a Service] :
개발환경 OS, 서버
Iaas [Infrastructure as a Service] :
가상 원격 컴퓨팅 자원
Utility Computing
: 사용자가 사용한 컴퓨팅자원(CPU,메모리,
디스크I/O 등)에 대해서만 과금이 가능한 컴퓨팅
아키텍처
Grid Computing
: 대규모 분산 컴퓨팅 아키텍처(계산/협업/데이터
그리드로 분류)
※ Cloud Computing에는 서버/스토리지 가상화
기술 적용이 필수 적임
명지대학교
3.2 가상화 기술
시스템(서버) 가상화
 가상화기술의분류
인프라(자원) 가상화
SOI2) 기반 가상화
정보 가상화
워크로드 가상화
Partitioning,하이퍼바이저,
I/O가상화
스토리지 가상화
컨트롤러/블록/Tape/
File(System)가상화
네트워크 가상화
VirtualIP, 802.1Q(VLAN)
파일 가상화
클러스터/그리드파일시스템
데이터 가상화
데이터연합&통합, (데이터)
그리드
트랜잭션 가상화
데이터연합&통합, (데이터)
그리드
테스크 가상화
JVM로드밸런싱
실리콘이중막웨이퍼(SOI:Silicon On Insulator)
트랜지스터와 트랜지스터간에 인위적인 절연막을 형성시켜
반도체 칩의 성능은 높이면서 전력소모량을 크게 낮출 수 있는
실리콘이중막웨이퍼(SOI:Silicon On Insulator)기술
프리젠테이션 가상화
SBC
명지대학교
3.2 가상화 기술
 가상화 기술 종류 및 특징
가
상
화
기
술
분
류
애플리케이션
가상화
기술특징
·사용자의 PC에 개별적으로 설치되어 있는 애플리케이션을
가상화를 통해 제공
·사용자는 필요한 애플리케이션을 자신의 PC에서 매번
설치하지 않고도, 즉시(On-Demand) 사용 가능
기술동향
·20년 전부터 발전한 기술로서 주로 업계에서는 SBC(ServerBased Computing), 프리젠테이션 가상화, 애플리케이션
스트리밍 등의 용어로 부름
·3D CAD 등의 리치 애플리케이션의 지원 및 소프트폰, IPv6
등의 지원 기술이 계속해서 적용 개발
·클라우드 SaaS(Software as a Service) 구현의 기반 기술
제공
위치
명지대학교
3.2 가상화 기술
 가상화 기술 종류 및 특징
가
상
화
기
술
분
류
기술특징
·서버-사이드 데스크톱 가상화는 사용자의 데스크톱에서
Windows Vista, Windows 7 등 의 이 기종의 또 다른
데스크톱을 가상으로 소유가 가능하게 함
·클라이언트-사이드 데스크톱 가상화는 PC 안의 이 기종의
가상 데스크톱을 운영 가능 하도록 함
·데스크톱 가상화를 통한 개인 작업 공간과 회사 작업 공간의
분리가 가능해짐
기술동향
·2006년부터 원격으로 가상 데스크톱에 접속하는 서버 사이드\
가상 데스크톱(Virtual Desktop Infrastructure)기술이
나오기 시작함
·기존의 클라이언트 기반의 여러 데스크톱을 운영하는 기술은
1997년부터 개발이 되어 나오기 시작함
·현재는 하드웨어에 직접 탑재되는 베어메탈 Type1 클라이언트
하이퍼바이저도 개발되어 서버 사이드 기술과 상호 연동될 수
있도록 통합 기술로 발전하고 있음
데스크톱가상화
위치
·클라우드 DaaS(Desktop as a Service) 구현 기반 기술 제공
명지대학교
3.2 가상화 기술
 가상화 기술 종류 및 특징
기술특징
가
상
화
기
술
분
류
서버 가상화
기술동향
·데이터센터 내의 수십 대의 물리적인 서버 워크로드들을 몇
대의 가상 서버로 통합 집적(Consolidation)하여 물리적인
상면 비용, 관리적인 측면의 비용, Green IT 측면의 전력량
을 포함한 서버 자원 활용도를 증대시킬 수 있음
·유닉스 프레임 시절의 하드웨어 파티셔닝으로부터 출발하여
소프트웨어 에뮬레이션 방식의 호스트 기반의 가상화 방식
그리고현재는 베어메탈(Bare-Metal) 기반의 가상화 엔진인
하이퍼바이저(Hypervisor) 형태의 서버 가상화 기술이
주를 이루고 있음
·클라우드 IaaS(Infrastructure as a Service) 구현
기반기술 제공
위치
명지대학교
3.2 가상화 기술
 가상화 기술 종류 및 특징
기술특징
가
상
화
기
술
분
류
·필요로 하는 스토리지 공간 대신 Thin-Provisioning이라는
기술을 통해 초기 필요 최소 공간만을 가상으로 할당하여
서비스 구현이 가능하도록 함
·또한, 이기종의 스토리지 시스템통합 사용할 수 환경을 제공
·NAS, FC SAN, IP SAN 등의 기술이 가상화 인프라 환경에서
스토리지 서비스로서의 지원이 가능하도록 발전해 나가고 있음
스토리지 가상화
기술동향
·클라우드 IaaS(Infrastructure as a Service) 구현 기반 기술
제공
위치
명지대학교
3.2 가상화 기술
 가상화 기술 종류 및 특징
기술특징
가
상
화
기
술
분
류
네트워크 가상화
기술동향
·하드웨어 어플라이언스 형태로 존재해 왔던 L2, L3, L7 스위치,
네트워크 방화벽, 보안 장비들을 가상 머신으로 구현하고,
네트위킹 자원들이 하나의 공유된 물리적인 환경에서도
내부적으로는 가상화를 통해 분리되어 동작하게 함
·기존의 물리적인 네트워킹 아키텍처에서 오토메이션과
프로비저닝이 가능한 가상 머신 어플라이언스 형태로의 기술
발전
·가상화 환경에서 멀티 코어를 활용하여 성능을 극대화
·멀티-테넌시(Multi-Tenancy)를 갖춘 IaaS 구현 기반 기술 제공
위치
멀티 테넌시(Multi-tenancy) : 하나의 시스템을 여러 고객(기업)이 사용하는 형태를
명지대학교
3.2 가상화 기술
 주요 IT 목적에서의 가상화 기술의 위치
Mobile and
Remote Working
VolP and UC
Agility
ITIL and Process
Improvement
Microsoft
Migrations
Service
Quality
Virtualization and
Consolidation
T/I&O Modernization
Economics
Green
IT/I&O
명지대학교
3.2 가상화 기술
 IT 발전 방향에서의 가상화 기술의 위치
IT/ I&O
Modernization
Microsoft
Migrations
Virtualization and
Consolidation
Green IT/I&O
ITIL and Process
Improvement
Mobile and
Remote Working
VoIP and UC
ITIL : 정보 기술(IT) 서비스를 지원, 구축, 관리하는 프레임워크. 효과적인 IT 서비스 관리를 위한 일종의 교본
명지대학교
3.2 가상화 기술
 가상화의 종류
 완전 가상화 Full Virtualization
 운영체제 계층 가상화 OS level Virtualization
 반가상화 Para-Virtualization
 어플리케이션 가상화 Application Virtualization
VMM : Virtual Machine Monitor = Hypervisor
프로세서나 메모리와 같은 다양한 컴퓨터 자원에 서로 다른 각종 OS의 접근
방법을 가상화하여 통제하는 얇은 계층의 소프트웨어, 가상화 레이어.
호스트 컴퓨터에서 다수의 운영 체제(operating system)를 동시에 실행하기
위한 가상 플랫폼(platform)을 말한다.
명지대학교
3.2 가상화 기술
 가상화의 종류(완전 가상화 Full Virtualization)
• VMware
• Micro Soft Virtual PC
• KVM (Kernel-based
Virtual Machine, Linux용
Open Source)
 Hypervisor Architecture 사용
 다양한 OS를 수정 없이 가상 Server상에 Install 가능
 단점 : Hypervisor에 의해 Processor에 큰 Overhead 발생
명지대학교
3.2 가상화 기술
 가상화의 종류(운영체제 계층 가상화 OS Level Virtualization)
단일 OS내에서 가상화가 이루어짐 (별도의 가상시스템이 미 존재)
가볍고 속도가 빨라 효율적, 대량의 가상 인스턴스 지원
단점 : 인스턴스 격리와 보안문제, 가상 인스턴스는 반드시 동일OS지원 필요
명지대학교
3.2 가상화 기술
 가상화의 종류(반 가상화 Para-Virtualization)
• Xen (open source)
물리적 하드웨어의 수정 복사본으로 서버 하드웨어와 동일한 아키텍처
Guest OS를 수정하여 Near-native speed구현 가능 (hypercall)
단점 : hypercall의 구현을 위해서는 guest OS의 수정이 필요
명지대학교
3.2 가상화 기술
 가상화의 종류(어플리케이션 가상화 Application Virtualization)
Application Virtualization Layer
물리적 플랫폼으로부터 완전히 분리되어 가상화 계층과 상호 작용
주문형 애플리케이션 스트리밍  애플리케이션 구축속도 향상
단점 : 가상 시스템 지원에 따른 부담  런타임/네이티브 환경 실행속도 저하
가상화 가능한 소프트웨어가 제한적
명지대학교
3.3 클러스터
 클러스터 관리 기술 개요
원활한 서비스 제공을 위하여,그 자체가 방대한 컴퓨터 클러스터 시스템인 클라우드 컴퓨팅
인프라에 대한 노드 관리,자동 업데이트 및 자동 설치, 프로비저닝, 그리고 로드 밸런싱 및 자동
확장성 제공이 필요함
컴퓨터 클러스터의 정의
많은 양의 계산을 하거나 데이터를 저장하기 위해 여러대의 컴퓨팅 자원을 하나로 묶어 놓은 시스템
※클라우드 컴퓨팅 서비스를 제공하는 클라우드 시스템 역시 매우 방대한 개수의 시스템들의
집합인 클러스터 시스템으로 정의할 수 있음
명지대학교
3.3 클러스터
 클러스터관리기술개요
컴퓨터클러스터의분류
분류
설명
고가용성(HA) 클러스터
Failover클러스터라고도 부르며 서비스의 가용성을 높이기 위한
목적으로 구현됨
여러 대의 서버들 중에 1대가 주(Active) 서버 역할을 하고 나머지는
보조(Standby) 서버로 동작 하다가 주 서버가 장애로 다운되면 보조
서버 중 1대가 주 서버로 선출되어 서비스 가용성을 유지하는 형태로
구성 구글 에서는 내부적으로 Chubby라는 Failover 클러스터를 구현해
다양한 업무에 활용하고 있다.
공개소프트웨어로는 Linux-HA 프로젝트가 있음
부하분산(Load
Balancing) 클러스터
1대 이상의 부하를 분산시키는 프런트 시스템(웹 서버, L4 스위치 등)이
있으며 이 프런트 시스템이 들어오는 작업
들을 백 엔드(Backend) 시스템들에 분배 시켜 주는 방식으로
클러스터가 동작 됨
컴퓨팅클러스터
고 성능 연산을 제공하기 위한 목적으로 구성된 컴퓨터들의 집합
그리드 컴퓨팅
명지대학교
3.3 클러스터
 주요요구기능
분류
기능설명
노드 관리
 가용성확보: 클러스터 Fail-Over 및 재 구성 지원(자동)
 유연성/확장성 확보: 클러스터 노드의 동적인 참여 및 배제
지원 (수동)
 물리적 하드웨어 및 논리 서버에 대한 관리를 동시에 지원
 부하분산, 논리 노드 및 프로세스 이동을 판단 기초 자료제공
자동 업데이트
및 자동 설치
기능
 전 클러스터 범위에 걸쳐 특정 기능 및 보안 관련 프로그램의
업데이트/설치/삭제 자동화로 해당 관리 업무 효율성/효과
확보
 모든 클러스터(노드들)를 대상으로 응
용 프로그램 자동 업데이트/설치/삭제 기
능구현
프로비저닝
및 작업 관리
 사용자권한(Login Identity Identification
Authentication Authorization, 서비스요청항목)을 클러스
터 내 자원 할당과 연계
 클러스터 내 유휴 자원을 실시간으로 할당하여 서비스 생성/
실행
 서비스 생성/실행/종료/ 사용자 통보/자원 해제 지원
 운영체제, 소프트웨어, 환경정보, 그리
고 스크립트등의 자원 관리 매커니즘
구현
 보안 연계 필수(SSO 등)
 클러스터 내 특정 자원에 대한 요청이 집중되는 병목 현상 방
지 및 해소
 각 사용자의 요청이나 자원 활용 상황에 따라 필요 자원을
적절히 할당
 Work Load의 급증에 대비한 동적 자원 재 할당 지원
 클러스터 실 시간 모니터링으로 확보
된 자원 상태 데이터
 동적으로 조정 가능한 클러스터 자원
관리정책
로드 밸런싱
및 자동 확장성
필요조건
 물리/논리 클러스터 노드에 대한
실시간 모니터링
클러스터 노드 관리 정책의 지속적인
조정
명지대학교
3.4 분산 시스템
 분산데이터관리
분산 데이터 관리 시스템(DDMS : Distributed Data Management System)은 대규모의 구조화된
데이터를 여러 부분으로 나눈 후,분산 저장/관리하는 클라우드 컴퓨팅 구현의 필수 구성 요소임
인터넷 응용 기반 클라우드 컴퓨팅의 분산 데이터 관리 요구 사항
확장 성
데이터 사용 요구 및 데이터 양 급증에 대응하여 동적으로 관련 시스템을 추가할 수 있는 유연성
고가용 성
동일 Data Set 복제 본을 다수의 분산된 위치에 저장하여 데이터 유실 및 서비스 중단 방지
고속처리
단순화된 데이터베이스 조회 연산으로 사용자 요청의 고속 처리 지원
 분산병렬처리
 네트워크를 경유하여 연결된 다수의 시스템들 간에 연산 작업을 병렬로(동시에) 수행하는 기술
 대용량 데이터를(비즈니스에) 적정한 시간 내에 가공/분석하기 위하여 분산 병렬 처리 기술이
활용됨
명지대학교
3.5 서비스 지향 아키텍처
■ SOA 필요성 증대
– 통신 회사(KT,SKT 등) 및 금융권(하나은행 등)의 차세대 시스템의 SOA 아키텍처 도입 증대
– SOA 투자로 인한 직간접적인 프로젝트 증대로 매출 순위의 뒤바뀜 (세계 SI 시장 1위 탈환)
명지대학교
3.5 서비스 지향 아키텍처
경영 환경 변화 요인 (동인)
정보 유통
가속화
•프로세스 자동화 통한 신속
한 의사 결정 및 생산성 향
상
글로벌 경쟁 •IT 기술의 발전에 의한 거래
심화
가치사슬
붕괴
전문화된
사업 모델
비용 감소
•고객의 선택의 폭 확장
•글로벌 경쟁체제 심화
비즈니스 요구사항
• 변화하는 비즈니스의 우선
순위를 신속히 적용할 수
있는 정보기술 체계 필요
• 변화하는 비즈니스 환경에
신속하게 대응
• 비즈니스 효율성과 성능을
향상
• IT를 비즈니스 전략에 보다
밀접하게 연관시킴
• 기업 내 각 부서, 비즈니스
단위, 비즈니스 파트너와의
통합운영
•IT 기술의 발전은 가치사슬의 변화를 유
발
•인터넷 기반의 Value Chain
• 비용 효율적 구조
• 안전하고 관리 가능한 환경을
제공
비즈니스  서비스
Business
목표
•기존 기업의 핵심 프로세스 해체
•핵심 기능 위주의 전문화된 비즈니스 모
델로 전환
아키텍처 요구사항
비즈니스 전략
(PI, BPR)
IT 아키텍처
SOA
서비스 지향 IT 아키텍처
 비즈니스 변화에
대응하는 서비스
중심으로 IT 응답성 제고
명지대학교
3.5 서비스 지향 아키텍처

SOA Position

Gartner 곡선에 의하면 SOA는 안정화 단계 및 실현 단계로 5-10년 사이 main stream이 될 것으로, SOA는 피할
수 없는 현실이며, 기업의 SOA Transformation이 중요해질 것으로 예상하고 있음
3.5 서비스 지향 아키텍처

SOA(Service Oriented Architecture) 개념



IT 시스템의 유연한 아키텍처를 서비스로 재구성함
Service는 비즈니스 서비스와 함께 IT 서비스로 분리 가능하며
이를 총괄적으로 구성 Enterprise Service 관리 방안이 있어야 함
Service Oriented
비즈니스 관점
Alignment
Service 정의
Architecture
IT 관점
3.5 서비스 지향 아키텍처

SOA 목적

기업의 비즈니스 변화에 IT 가 빠르게 대응할 수 있도록 고객의 비즈니스와 이를 뒷받침하는 Enterprise IT
아키텍처를 밀접하게 Align 시키도록 Principle, Framework, Methodology 를 제공함
SOA Goal
Business And IT
IT
비즈니스
Concept and
Principle
Framework
Methodology
3.5 서비스 지향 아키텍처
■ Service Oriented Architecture(서비스 지향 아키텍처 )란 ?
- 서비스 요청자(Client)와 제공자(Server)로 이루어진 어플리케이션 소프트웨어 설계방식
- 표준기반의 공통사용(재사용)이 가능한 서비스들의 관계를 느슨한 관계로 모델링하여
소프트웨어의 서비스화를 지향하는 아키텍처
☞ 웹 서비스(Web Service)는 SOA의 구현을 위한 현존하는 최적의 기술 대안
SOA 의 비즈니스 관점 및 서비스 관점
…whereby business activity components
are packaged as well-defined services,
accessible electronically by partners,
suppliers and others
Business Focus (Service Oriented)
+
…which is implemented within an
architectural technology framework
optimized for this purpose
Technology Focus (Architecture)
3.5 서비스 지향 아키텍처

기본요건
 SOA 는 표준화에 따른 서비스 구성을 통해 Layered 구조를 이루게 하며, 재사용
가능한 서비스 모듈의 사용 방안을 제공하여 서비스간 Loosely-coupled되어
통신하도록 하여 유연한 비즈니스 대응을 가능하게 함
요건
설명
지향점
잘 정의된 인터페이스
 서비스의 기능과 서비스 호출 규칙을 수립
개방형 표준 지향
 합의된 기준
de-Jure (公的 표준)
de-facto(事實표준)
느슨한 결합
 서비스를 특정 서비스 소비자와 완전 분리
플랫폼, 언어, 위치
서비스 입도
 의미있는 비즈니스 로직/프로세스 단위
3.5 서비스 지향 아키텍처
 서비스 지향 아키텍처의 특징

느슨한 연결 (Loosely Coupling) : 기민하게 각 서비스의 내부 구조 및 구현의 변화에 대응
 굵은 입도 (Coarse Granularity) : IT환경의 기술적인 복잡성을 덮어줌
 재사용 (Reuse) : 개발기간 단축, 비용 절감
 민첩성 (Agility)향상: 서로 다른 환경에서 개발된 시스템의 통합이 쉬우며, 변경 요청 발생時
신속 대응이 가능해짐
 개발 생산성 행상 : 개발자는 자신이 개발하는 시스템에서 어떤 서비스를 요청할 것인가만
신경을 쓰면 되고, 요청한 서비스가 어떻게 처리되는지는 몰라도 됨
SOA 구축 이전
SOA 구축 이후
사용자
사용자
SOA
주문 처리 업무 서비스
고
객
관
리
재
고
관
리
주문 처리 업무
배
송
관
리
송
장
관
리
실
적
관
리
고
객
모
듈
재
고
모
듈
배
송
모
듈
송
장
모
듈
실
적
모
듈
3.5 서비스 지향 아키텍처

1) 상호 운용성(Interoperable)

Universal Interface 인 Web Services 기술을 이용하여,

기존의 독점적인 “Lock and Key” 디자인이 아니라,

어디에서든 통하는 전기 socket과 같은 Interface를 통해 다수의 응용 어플리케이션과 쉽게 결합할 수 있는
기반을 제공함

예) 전자 제품 과 Wall-Sockets / USB 와 USB Device
3.5 서비스 지향 아키텍처

2) 조합 가능성(Composable)

Web Services 기술은 WSDL을 이용하여 자신의 묘사가 가능하며 이런 “Self-Describing” 특성과 SOAP을 통한 상호 운용성은
Software 솔루션을 서비스 조합으로 가능하게 함

서비스의 Building Block 화
Applications
composed of
Services
3.5 서비스 지향 아키텍처

3) 재사용성 (Reusable)

서비스는 자신을 설명하는WSDL (Web Services Description Language)를 갖고 있는 단위 소프트웨어로 SOAP 메시지 통신을 통해
언제 어디서든 호출 가능함

이런 특징을 갖는 서비스는 재사용이 가능하며, 따라서 Repository에서 관리되어 짐
WSDL is a Key
<description>
<types>
</types>
<interface name = “..”>
Request
</interface>
Service
<binding name = “..”>
</binding>
<service name= “..”
interface = “..”>
</service>
Response
</description>
Repository
/ UDDI
*) UDDI = Universal Description,
Discovery and Integration
3.5 서비스 지향 아키텍처

4) 느슨한 결합 (Loosely-coupled)

서비스 간 연동은 웹 서비스를 Wrapper로 사용하여 Loosely 하게 연동하도록 함

중요 비즈니스 서비스의 인터페이스를 웹 서비스로 노출하고, 호출 시 또한 웹 서비스를 활용,
독립적인 Coupling을 이루게 함
X
Order Web Service
I_SalesOrder_Create
Platform Z
Procurement
Application
Web
Service
Order
Service
Interface
Sales Order
Application
Platform X
플랫폼 및 기술에
3.5 서비스 지향 아키텍처

서비스 Granularity(입자성) 및 Abstraction(추상성)

입자가 굵은(Coarse Grained) Business Service와 입자가 작은(Fine Grained) Impl. Service의
적절한 조합(Aggregation)및 추상성을 통해 서비스 기반의 비즈니스 환경 구축 가능
 고려 요소
• 굵은 입자성
• 외부에서 사용의 적절성 )
• 느슨한 연결 / 디자인
• Low level 서비스와 Business 서비스의 조합
Aggregation
Abstraction
Service
Service
Wrapper
Wrapper
InfrastructureExisting
External Existing
Services
Application Services Application
Fine Grained
ImplementationBased Services
3.5 서비스 지향 아키텍처

서비스 통한 신속한 개발 가능

새로운 비즈니스인 교육 사업을 위한 Course Management Application 프로그램 개발 시 이미 개발되어
사용되어지는 서비스를 호출하여 구성 가능하며, 새롭게 개발되는 Room Availability 서비스는 또 다른
비즈니스 or 어플리케이션에서 호출하여 사용 가능함
주문 처리 어플리케이션
(Order Processing
Application)
과정 관리 어플리케이션
(Course Management
Application)
새로운 어플리케이션은
쉽게 사용 가능한
서비스를 찾을 수 있음
새로운 서비스는 또한
다른 Application에서
사용 가능함
고객 찾기
Service
신용 체크
Service
물품 처리
Service
재고 체크
Service
Room
Availabilit
y Service
3.5 서비스 지향 아키텍처

서비스 Communication

SOA Infrastructure에 의해 서비스의 프로토콜과 data 변환이 가능하여 확장 성을 보장 가능
Order Processing
Application
SOA Infrastructure 는
어플리케이션과 서비스
사이의 통신
메커니즘을 제공함
SOA Infrastructure
고객 찾기
Service
신용 체크
Service
물품 처리
Service
재고 체크
Service
서비스의 변경 사항은
기존 서비스를
사용하는 Application에
영향을 미치지 않음
3.5 서비스 지향 아키텍처

Service Legacy 연계

서비스 기반의 infrastructure를 통해 Legacy 시스템과의 연결을 표준화함. 어플리케이션은
SOA Infrastructure를 통해 Legacy의 서비스를 연동함으로, 신뢰성 있는 환경을 제공할 수 있음
Order Processing
Application
어플리케이션은
서비스를 표준화된
방식으로 access 함.
레가시 시스템의
복잡함과 다양함을
단순하고 명쾌하게 함
SOA Infrastructure
고객 찾기
Service
물품 찾기
Service
신용 체크
Service
Customer
Management System
Manufacturing System
36
재고 체크
Service
레가시 시스템을
호출하는 것이
서비스의 역할임
3.5 서비스 지향 아키텍처

SOA 구성


SOA 아키텍처는 기본적으로 Service Provider, Service Consumer, Service Broker로 이루어진 구조
자기 설명적인 (Self describing) 인터페이스를 (WSDL)를 가진 서비스는 플랫폼 독립적인 XML 형식으로
Formally하게 정의되어, Service Broker를 통해 서비스로 등록하고 관리되어 애플리케이션 수가 증가해도
서비스를 찾을 수 있는 방안이 제공됨 (UDDI)
Service Broker
Find
Register
Service
Contract
Service Consumer
Service Provider
Bind
Client
Service
※ UDDI(Universal Description, Discovery, and Integration)
- 인터넷에서 전 세계의 비즈니스 업체 목록에 자신의 목록을 등록하기 위한, XML기반의 규격
37
3.6 SaaS 플랫폼
SaaS 개념
소프트웨어 구축 및 유지보수 비용이 증대하고, 비즈니스 변화에 신속히 대응할 수 있는 소프트웨
어에 대한 요구가 높아짐에 따라 SaaS 모델이 등장하였음
소프트웨어 전달 방식의 변화
On-Demand
Business Services
SaaS
􀂄 구독료 모델
􀂄 신속한 솔루션 적용
􀂄 낮은 버전 및 성능 컨트롤
􀂄 IT 자원 투입 적음
Software as
a Service
Software as
a Product
On-Demand Business Services
􀂄 사용량 기반
􀂄 비즈니스 프로세스에 초점
On-Premise Software
􀂄 라이센스 모델
􀂄 데이터 센터에 인스톨하거나 호스팅
􀂄 버전 컨트롤, 성능 컨트롤 필요
􀂄 IT 구축에 많은 자원 투입
􀂄 긴 업그레이드 사이클
38
3.6 SaaS 플랫폼
고객의 프로세스 민첩성에 대한 요구, 소프트웨어 업계의 안정적인 수익 창출 요구, SOA 기술의
발전에 힘입어 SaaS 도입에 대한 관심이 높아지고 있음
고객 측면
시장 측면
-고객의 Agility 확보 니즈
• 프로세스 민첩성 및 유연성 확보가 최대 이슈인 상황에서
현재의 방식은 부담
• 초기 도입 비용의 부담을 줄이고, 업그레이드/유지보수
고민에서 상당 부분 해방
-SW 업계의 수익 구조 개편 요구
• 보다 안정적이며 지속적인 수익 구조 확보를 위해
비즈니스 모델 전환 필요
• 제3의 서비스 업체 없이 또한 이들의 역할이 최소화된
상태에서 직접 제공 가능함으로써 현재의 수익 구조를
획기적으로 개선
기술 측면
미래의 고도화된 SaaS 모델
-SOA 기술의 발달
• SOA 기술의 발달은 비즈니스 요구 사항에 따라
동적으로 어플리케이션을 모델링하여 사용할 수
있게 함
- Web2.0으로의 진화
• 플랫폼으로서의 웹으로 발전함에 따라 웹을 통한
어플리케이션 서비스 가시화
39
3.6 SaaS 플랫폼
ASP와 SaaS 서비스는 서비스/관리 방식이나 비용청구 방식에서는 유사하나, 아키텍쳐/커스터마
이징, 기능/성능 개선방식, 서비스 제공자 등 다양한 분야에서 차이를 나타내고 있음
유
사
점
일반적인 특징
ASP ( Application Service Provider )
SaaS ( Software as a Service )
서비스/관리 방식
-서비스 제공자의 원격지 서비스 및 관리
-웹 또는 클라이언트 / 서버
-서비스 제공자의 원격지 서비스 및 관리
-웹 서비스
-구독료 ( Subscription Fee )
( 사용자, 기간 )
-구독료 ( Subscription Fee )
( 기능, 사용자, 기간, 사용량 기준 )
- 일반적으로 외부 업체
( Application Hosting 업체 )
- S/W 제공자
Single-Tenant Architecture
-고객마다 사용 프로그램이 다름
( 응용프로그램을 공유할 수 없음 )
-고객별 코드변경에 의한 커스터마이징
Multi-Tenant Architecture
-응용 프로그램 공유
( 또는 서버/프로세싱, 데이터베이스까지 공유 )
-정교한 구성관리 도구에 의한 커스터마이징만 가
능함. 프로그램 코드 변경 불가능
기능/성능 개선
-1년 또는 1.5년에 1회 Upgrade
- 자동 적용 또는 요청에 의한 적용
-1년에 3-4차례 Upgrade 또는 Update
-사용자 환경에 무리없이 자동 적용
초기 S/W 구성
- On-Premise 제품을 ASP용으로 변환
-SaaS 서비스를 목표로 구성
-정보화 및 사업영위에 기본이 되는 시스템
영역
( ERP, G/W, 세금계산서 등 )
-필수 정보시스템이 아니면서도 활용도에 따라 생
산성에 많은 영향을 미치는 영역
( SFA, PTM 등 )
비용청구 방식
서비스 제공자
차
이
점
아키텍쳐/
커스터마이징
서비스 영역
40
3.6 SaaS 플랫폼
SaaS Maturity Model
Level 1: Ad Hoc/Custom
1990s
개별 고객을 위해 소스 코드를 수정한 SW 제공
SW 인스턴스는 완전한 독립 유지
Client-server architecture
Level 2: Configurable
동일한 소스 코드 사용, but 고객별 환경 설정 가능
여전히 인스턴스 분리
대폭적인 SW Architecture 수정 필요
Level 3: Configurable, Multi-Tenannt-Efficient
단일 인스턴스를 통해 모든 고객 서비스,
메타데이터를
통 해 고객 환경 설정 가능
권한제어, 보안 정책에 의한 컨트롤 필요
효율적인 자원 사용을 통한 운영 비용 절감 가능
Level 4: Scalable, Configurable, Multi-Tenant-Efficient
인스턴스들의 로드 밸런싱이 가능함
Scalability 보장(고객 수에 따라 서버, 인스턴스 증감
가능)
41
3.6 SaaS 플랫폼
Gartner는 SaaS서비스의 모델을 6계층으로 나누고 있으며, 그 중 플랫폼 계층은 SaaS화하기
위해 필요한 모든 Hardware와 Software 구성요소로 정의함
42
3.6 SaaS 플랫폼
해외는 대기업 사업부에서 시작하여 중견, 중소 기업으로 도입이 확산되는 경향을 보이며, 국내는
중소기업 정보화등의 영향으로 중소기업 중심이었으며 향후 중견, 대기업 사업부 등으로 확산될
것으로 예상됨
43
3.6 SaaS 플랫폼
SaaS 종합
종합
이슈
<고객에게 주는 가치>
<SaaS 벤더가 풀어야할 문제>
􀂄Core Competency에 집중
􀂄위험 감소
- Zero IT
- Low TCO
- Pay as you go
􀂄작업 환경 개선
- Security
- Uptime(Access Anytime)
- Global Access(Access Anywhere)
􀂄혁신 지원
- 고객이 주도하는 애플리케이션 기능 강화
- 잦은 업그레이드
<벤더에게 주는 가치>
􀂄예측 가능한 수익
􀂄개발 및 지원 비용 절감
􀂄판매 및 마케팅 비용 절감
􀂄고객 친화도 증가
􀂄Business Continuity
“ 데이터를 영원히 잃어버릴 가능성”
􀂄Data security and privacy
“내 데이터가 안전성과 비밀 보장성”
􀂄Accessibility
“내 데이터에 지금 접근 가능성”
􀂄Functional Limitation
“서비스 재구성 가능성”
􀂄Legacy Integration
“레거시 업무 시스템과 유연한 연동”
􀂄Application Performance
44
3.6 SaaS 플랫폼
SaaS 향후 과제
􀂄TCO 증명
􀂄SW 제작
– Consulting
– Multi-tenant Architecting Principles
– Database, Application, Control
– Quick & Easy SW Creation Tool
􀂄유통
– SW 가격 책정 방안
􀂄서비스
– SaaS Enabled Platform 국산화
– Metadata 관리 방안(UI, Process, Data,
Control, Version)
􀂄과금
– 서비스 가격 책정, 사용량 측정, 과금 방안
􀂄유지 보수
45
3.7 보안
 보안의 필요성
보안
성능
가용성
기존 IT기기와 통합이 어렵다
커스터 마이징 능력이 충분하지 않음
On-demand로 인한 과다비용 발생 가능성
다른 곳으로 저장 하기 어려움
클라우드 관련 법적 규제
주요 제공업체수가 적음
20%
46
40%
60%
80%
3.7 보안
 보안위협
1) MalWare 공격
가상머신의 취약점을 이용하여 공격자가 권한을 획득하거나 기타 경로를 통해 임의의
악성코드가 실행되는 경우, 악성코드는 가상머신의 상호 커뮤니케이션 과정에서
다른 사용자의 영역에 악성코드를 감염 시킬 수 있다.
APP
APP
APP
2차감염
Guest OS
Guest OS
1차감염
APP
Guest OS
Virtualization Layer
Host OS
Hardware
CPU
Memory
NIC
악성코드 감염 경로
47
Disk
3.7 보안
 보안위협
2) 정보 유출
가상머신의 취약점을 이용하여 허가되지 않은 권한을 획득한 경우에는 물리적 디스크에
대한 접근이 가능하고 이로 인한 정보 유출이 가능해진다.
3) 서비스 거부
하나의 가상머신에서 자원을 남용하거나 또는 가상머신에서 실행되는 프로그램이 가상머신
계층을 통과하여 Host의 권한을 획득하여 악의적인 행위를 하는 경우에는 Host 또는 다른 가상
머신에 서비스 거부가 발생할 수 있다.
4) 가상머신 인증
가상환경에서는 가상머신이 인증되지 않은 자에 의해 변경됨으로써 보안 위협이 발생되기도 한다.
악의적인 목적을 가진 공격자 또는 사용자가 가상머신을 실행하여 임의로 설정을 변경하고 권한을
획득하는 경우가 해당된다.
48
3.7 보안
 보안위협
5) 하이퍼바이저 보안
• 하이퍼바이저는 가상화를 가능하게 하는 핵심 기술로서 Host 컴퓨터에서 다수의 운영체제가
동시에 실행되기 위한 가상 플랫폼을 의미한다.
• 하이퍼바이저 보안은 현재 가상화 기술에서 가장 중요하게 제기되고 있는 보안 이슈로서 보안
전문가들은 하이퍼바이저의 취약점 노출로 인한 공격 발생을 우려하고 있다.
• 하이퍼바이저가 위협에 노출될 경우 아래의 그림과 같이 가상머신 또한 그대로 위협에 노출되기
때문이다.
APP
OS
Virtual Machine
보안위협
Hypervisor
Hardware
CPU
Memory
NIC
악성코드 감염 경로
49
Disk
3.7 보안
 보안위협
가상인프라에서 보안 이슈
•전통적 보안으로 가상 인프라 보호는 비용 및 복잡성을 증가 시킬 수 있다.
전통적인 보안
보완 사항
네트워크 경계에서 위협
및 공격만을 차단
네트워트 경계뿐만 아니라
VM간의 경계에도 위협으로
부터 보호되어야 함
Server Protection
에이전트의 관리
기능으로 단일 물리적
서버를 보호
물리적 서버에 시간과 비용을
투자하는 것과 같이 각각의
VM에서의 서버에도 필요
System Patching
개별 서버 또는 네트워크의
중요 취약점 패치
패치, 트래킹 그리고 VMs의
임의 사용을 통제
Security Policies
정책이 각 네트워크 세그먼트나
서버의 중요 어플리케이션에 국한
정책이 더욱 포괄적(웹, 데이터, OS영역,
DB)등으로 적용되어야 하며 VMs과 함께
이동 되어야 함
Network IPS
50
3.7 보안
 보안위협 요약
가상화 환경에서의 위협
APP
OS
하이퍼
바이저
관리
서버
VM
VM
APP
APP
APP
전통적인 위험 적용
OS와 어플리케이션에 대한 공격
하드웨어
SQL인잭션, XSS
Web응용 프로그램 공격, 정보
유출 발생
하이퍼바이저 위협
-가상머신간의 잘못된 통신
가상화 환경애서 바이러스 감염
- RootKit에 의해 제어되는
으로 인한 어려 서버가 영향,
가상머신 가상화 환경 전반에 위협이
사업 정지
파급
APP
하이퍼바이저
하드웨어
예상되는 피해 예
규정준수
오래된 OS가 설치된 VM을
- 쉽게 VM구축
대상으로 한 못 감염으로 인한
- 관리자 컨트롤 하는 관리 범위가
대외 공격 사이트로 악용
확대됨
하드웨어
구성요소의 증가 = 위협의 증가
51
3.7 보안
 보안위협 요약
기술적 보안
관리적 보안
Authentication
Authorization
Access
Control
정보보호 정책
준수, 책임 이행
보안전문에
의한 운영
Encryption
Fire wall, IPS
Ddos 방어 시스템
ESM
감사수행
(로깅, 모니터링,
Audit)
대응체계 수립
주기적인 모의
훈련
보안 취약점
분류
물리적 보안
출입통제
시스템
재난, 재해 업무
연속성 제공
시스템 도난
비인가 반출 대응
물리적 통제
52