Embed Size (px)
Citation preview
T T A S t a n d a r d
정 보 통 신 단 체 표 준
제 정 일 : 20xx 년 xx 월 xx 일TTAx.xx-xx.xxxx 개 정 일 : 20xx 년 xx월 xx 일
사용량 기반 IT 서비스구현 및 도입 지침
(Guideline for Realization and
Induction of Usage Based IT
Service)
정 보 통 신 단 체 표 준 제 정 일 : 20xx 년 xx 월 xx 일 TTAx.xx-xx.xxxx 개 정 일 : 20xx 년 xx 월 xx 일
사용량 기반 IT 서비스 구현 및 도입 지침
(Guideline for Realization and Induction of
Usage Based IT Service)
본 문서에 대한 저작권은 TTA에 있으며 , 이 문서의 전체 또는 일부에 대하여 상업적 이익을 목적으로 하는 무단 복제 및 배포를 금합니다 .
Copyright Telecommunications Technology Associations(2005). All Rights Reserved.ⓒ
Copyright Telecommunications Technology Associations(2005). All Rights ⓒReserved.
ii
서 문
1. 표 준 의 목 적
본 지 침 은 서 버 등 정 보 자 원 의 사 용 률 이 낮 은 상 황 에 서 사 용 량 기 반 IT 서 비 스 도 입 촉 진 을 통 해 탄 력 적 인 IT 인 프 라 운 용 에 따 른 정 보 자 원 사 용 효 율 제 고 로 에 너 지 및 도 입/ 운 영/ 유 지 비 등 을 절 감 할 수 있 는 기 반 을 마 련 하 는 데 목 적 이 있 다 .
2. 주 요 내 용 요 약
사 용 량 기 반 IT 서 비 스 의 개 념 및 특 징 등 에 대 해 설 명 하 고, 사 용 량 기 반 IT 서 비 스 구 현 을 위 한 프 레 임 워 크, 비 용 모 델 , 시 스 템 아 키 텍 처 등 표 준 화 된 모 델 을 제 시 하 며 , 사 용 량 기 반 IT 서 비 스 적 용 을 위 한 고 려 사 항 및 전 략, 서 비 스 수 준 별 아 키 텍 처 구 현 방 안 과 사 용 량 기 반 IT 서 비 스 운 영 방 안 및 성 공 의 조 건 등 을 제 시 한 다 .
3. 표 준 적 용 산 업 분 야 및 산 업 에 미 치 는 영 향
비 즈 니 스 민 첩 성 향 상, IT 투 자 효 율 화 및 비 용 절 감 , IT자 원 사 용 최 적 화 를 통 한 그 린 IT 실 현 , IT 서 비 스 품 질 향 상 등 을 위 해 사 용 량 기 반 IT서 비 스 를 도 입 하 고 자 하 는 사 용 자 와 이 의 구 현 및 제 공 자 인 IT 서 비 스 업 체 에 게 유 용 한 지 침 으 로 활 용 가 능 하 다 .
4. 참 조 표 준 ( 권 고 )
4.1 국 외 표 준 ( 권 고 ) : 없 음
4.2 국 내 표 준 : 없 음
i
5. 참 조 표 준 ( 권 고 ) 과 의 비 교 : 해 당 사 항 없 음
6. 지 적 재 산 권 관 련 사 항 : 해 당 사 항 없 음
7. 적 합 인 증 관 련 사 항 : 해 당 사 항 없 음
8. 표 준 의 이 력
판 수제 /
개 정 일제 / 개 정 내 역
제 1판 20xx년 xx 월 제 정
ii
목 차
1. 지침 개요 11.1 사용량 기반 IT서비스 개념 11.2 사용량 기반 IT서비스 특징 및 분류 41.3 지침의 목적 및 적용범위 8
2. 사용량 기반 IT서비스 모델 92.1 사용량 기반 IT서비스 프레임워크 92.2 인프라 서비스 비용 모델 182.3 인프라 서비스를 위한 시스템 아키텍처 32
3. IT 활용 최적화를 위한 사용량 기반 IT서비스 적용 373.1 주요 고려사항 373.2 사용량 기반 IT서비스 적용 전략 493.3 사용량 기반 IT서비스 아키텍처 구현 583.4 사용량 기반 IT서비스 운영 75
4. 사용량 기반 IT서비스 성공의 조건 844.1 유틸리티 컴퓨팅의 사례 844.2 클라우드 컴퓨팅의 사례 864.3 사용량 기반 IT서비스 성공의 조건 88
5. 사용량 기반 IT서비스 적용에 따른 기대효과 및 전망 965.1 기대효과 965.2 사용량 기반 IT서비스의 발전 전망 101
iii
1. 지침 개요
1.1 사용량 기반 IT서비스 개념
1.1.1 사용량 기반 IT서비스 정의
IT 자산 또는 IT 관련 기능이 사용자에게 서비스 형태로 제공되고, 사용한 서비스의 양과 품질에 비례해서 결정되는 가격을 사용자가 지불하는 IT서비스 체계를 ‘사용량 기반 IT서비스’라고 정의한다. 이는 사용자가 필요한 IT 자산을 구매하거나 소유하지 않고 공급자가 제공하는 것을 필요할 때 필요한 만큼
사용하고, 사용한 만큼 대가를 치르면 되기 때문에 서비스라 할 수 있다. 서비스 제공자와 사용자는 서로 다른 기업 또는 기관이거나 동일한 기업/기관 내의 서로 다른 조직이 될 수 있다. IT서비스는 서버, 스토리지 등과 같은 인프라뿐만 아니라 플랫폼, 소프트웨어 그리고 비즈니스 프로세스 등 여러 가지로 분류할 수 있다.
[그림 1-1] 사용량 기반 IT서비스의 개념
1
[그림 1-2] 사용량 기반 IT서비스의 비용적인 효과
[그림 1-2]에서 보는 바와 같이 기존 구매에 의한 운영방식은 인프라를 독점적으로 사용한다는 장점에도 불구하고 서비스 주기에 따라 서비스 용량
(Capacity)을 달리하는 경우 능동적으로 대처하기 어렵고 이를 해결하기 위해 추가적인 장비 구매비용이 소요된다는 단점을 갖는다.
한편, 종량제에 의한 운영방식은 장비사용에 대한 가변성이 제공되어 사용량 변동에 따른 보다 유연한 대처가 가능한 장점을 갖는다.
1.1.2 IT서비스 환경의 변화
급변하는 비즈니스 환경에 대응하고 빠르게 발전하는 IT기술을 적용하기 위해서 IT 자산에 대한 개념이 “소유”에서 “사용”으로 변화하고 있다. 이전의 기업들은 오랜 동안 각 기업이 필요한 자산을 개별적으로 도입하고 소유해 왔다.
그러나 국내의 경우 1980년대 후반부터 운영 아웃소싱(SM), 웹호스팅, 코로케이션(Co-location), ASP(Application Service Provider) 등이
2
등장하여 IT 관련 기능 및 자산의 소유자와 사용자가 분리되는 ‘IT 기능의 서비스화’ 현상이 시작되었다.
특히, 2007년 이후 클라우드 컴퓨팅 개념과 실제 서비스 사례가 등장함에 따라 IT 자산 및 기능의 서비스화에 대한 시도가 확산되고 있다.
클라우드 컴퓨팅에서는 현재 인프라(IaaS), 플랫폼(PaaS), 소프트웨어 (SaaS) 등이 서비스로 제공되고 있고, 앞으로는 비즈니스 프로세스까지 서비스화(BPaaS: Business Process as a Service) 될 것으로 보인다.
[그림 1-3] IT 자산 및 기능의 서비스화 과정
1.2 사용량 기반 IT서비스 특징 및 분류
1.2.1 사용량 기반 IT서비스의 특징
3
서비스 사용자의 관점에서 전통적인 컴퓨팅 모델과 사용량 기반 IT서비스 모델의 특징은 아래와 같이 비교할 수 있다.
[표 1-1] 사용량 기반 IT서비스 특징구분 전통적인 컴퓨팅 모델 사용량 기반 IT서비스 모델
도입/구매(Acquisition)
- 하드웨어, 소프트웨어 등의 IT 자산을 구매
- IT 자산을 도입하고 시스템을 구축하기 위한 초기 투자 발생
- 필요한 서비스를 구매 - 사용자는 IT 자산을 구매, 소유할 필요 없음
- 서비스를 사용하기 위한 초기투자가 필요치 않음
비용(Cost)
- 고정자산과 시스템 운영에 비용을 지출
- 필요 자산의 규모 예측 오류로 인한 과잉공급 또는 과소공급 가능성 높음
- 사용량 기반 비용 지불- 필요한 만큼만 필요한 기간 동안 사용할 수 있으므로 과잉공급 또는 과소공급을 피할 수 있음
액세스(Access)
- 개인 PC로 내부 네트워크를 통해 연결
- 외부에서는 VPN을 통해 연결
- PC 또는 PDA 등의 다양한 단말기로 인터넷 또는 내부 네트워크를 통해 연결(인터넷을 통해 서비스를 제공하는 것이 기본 모델)
기술 아키텍처(Technical
Architecture)
- 싱글 테넌트(한 개의 인스턴스를 한 기업/사용자가 사용)
- 비공유 사일로(Silo) 구조- 워크로드 변동에도 할당된 자원의 양이 단기간에 변하지 않는 정적인 환경
- 멀티 테넌트(한 개의 인스턴스를 다수의 기업/사용자가 사용)
- 시스템 자원이 공유되는 공유 풀(pool) 구조
- 워크로드 변동에 따라 할당된 자원의 양이 변하는 동적 최적화 환경
유연성(Flexibility)
- 사일로 구조로 되어 있고 기술 다양성이 높아(기술 표준화 정도가 낮아) 장비 활용 유연성이 낮음
- 애플리케이션별 특화된 아키텍처 비율이 높아 시스템간 장비 이전/활용에 제약이 있고 긴시간 소요
- 높은 수준의 표준화 및 자동화를 바탕으로 하여 필요에 따라 사용량 증대 또는 축소 가능
- 확장과 축소가 짧은 시간 내에 가능
- 서비스 사용 추가 또는 사용 중단의 유연성
4
1.2.2 사용량 기반 IT서비스 분류
사용량 기반 IT서비스는 “서비스 자원이 무엇인가?”에 따라 아래와 같이 인프라 서비스, 플랫폼 서비스, 소프트웨어 서비스, 그리고 비즈니스 프로세스 서비스 등 네 종류로 구분할 수 있다.
서버, 저장 공간(스토리지 및 백업), 네트워크 등 하드웨어를 기반으로 하는 인프라 서비스(Infrastructure Service)
인프라에 애플리케이션 개발 환경이나 애플리케이션 실행을 위한
미들웨어나 플랫폼 소프트웨어가 추가된 플랫폼이 서비스 형태로
제공되는 플랫폼 서비스(Platform Service) 플랫폼 상에서 실행되는 사용자 애플리케이션이나 다양한 소프트웨어 즉, 소프트웨어가 서비스로 제공되는 소프트웨어 서비스(Software Service)
사람이 직접 개입하는 비즈니스 프로세스와 IT서비스가 결합되어 서비스로 제공되는 비즈니스 프로세스 서비스(Business Process Service)
5
[그림 1-4] 서비스 자원에 따른 사용량 기반 IT서비스 분류
이들 서비스 중 현재 국내외적으로 인프라 서비스가 가장 널리 알려져 있고
사례도 가장 많으며, 플랫폼 서비스는 구글 앱엔진(App Engine)과 세일즈포스 닷컴(salesforce.com)의 force.com이 널리 알려져 있다. 그리고 salesforce.com의 CRM서비스가 가장 성공적인 소프트웨어 서비스로 인식되고 있고, 이외에 구글 앱스(Google Apps) 등의 다양한 서비스 공급자들이 등장하고 있다. 그러나 마켓 데이터 분석 또는 지불 프로세스 처리 서비스 등의 비즈니스 프로세스 서비스는 아직 사례도 적고 생소하지만 2~3년 후에는 빠르게 증가하여 다양한 서비스가 등장할 것으로 예측된다.
서비스 자원에 따른 분류 이외에 “제공되는 서비스가 무엇인가?”에 따라 [표 1-2]에서와 같이 Operational Outsourcing Service, Co-Location Service, Managed Hosting Service, Infrastructure Service, Platform Service, Software Service 등 6가지로 분류할 수 있으며, 국내의 경우 Operational Outsourcing Service, Co-Location Service, Managed Hosting Service 등
6
3가지 서비스가 폭넓게 사용되고 있다.
Operational Outsourcing Service는 System Management라고도 불리는데, 기업/기관 소유의 IT 자산을 운영관리 하는 서비스를 제공하며, Co-Location Service는 기업/기관 소유의 IT 자산을 인터넷/네트워크 회선이 준비된 데이터센터 공간에 위치시키는 즉, 데이터센터 공간을 서비스로 제공하며, Managed Hosting Service는 위 두 서비스가 결합된 것을 말한다.
[표 1-2] 제공 서비스에 따른 사용량 기반 IT서비스 분류
서비스
구분 (서비스 명)
Operational
Outsourcing Service
(SM)
Co-Location Service
(Hosting)
Managed Hosting Service(SM +
Hosting)
Infrastructure Service
(IaaS)
Platform Service(PaaS)
Software Service(SaaS)
제공
서비스운영 (센터) 공간 (센터) 공간
+ 운영 + HW 자원 + SW 플랫폼
+ SW / Applicatio
n
1.3 지침의 목적 및 적용범위
본 지침은 사용량 기반의 IT서비스 제공자와 사용자가 사용량 기반 IT서비스를 이해하고 이의 구현 및 도입에 대한 기본적인 가이드라인을
7
제시하는데 그 목적을 두고 있다.
IT서비스 제공자에게는 사용량 기반 IT서비스를 제공하기 위한 환경/비즈니스 기획 시 고려해야 할 사항에 대한 정보를 제공하고, IT서비스 사용자에게는 사량용 기반 IT서비스에 대한 기본적인 이해와 서비스 도입 시 고려해야 할 사항을 파악하는데 필요한 정보를 제공한다.
이를 통해 기존 IT서비스 방식에 비해 자원 사용률, 에너지 효율, 유연성과 민첩성이 대폭 향상된 사용량 기반 IT서비스의 구현 및 도입을 촉진하고, 전환 과정에서의 시행착오를 최소화하는데 기여할 것이다.
사용량 기반 IT서비스는 인프라, 플랫폼, 소프트웨어 그리고 비즈니스 프로세스 등으로 분류할 수 있지만, 본 지침에서는 현재 관련 시장의 성숙도 및 인지도, 지침 개발의 시급성 및 활용성 등을 고려하여 다양한 사용량 기반 IT서비스 분야 중 IT 인프라 부문만을 적용범위로 하여 이에 대한 가이드라인을 제시하였다.
2. 사용량 기반 IT서비스 모델
2.1 사용량 기반 IT서비스 프레임워크
8
2.1.1 인프라 서비스 프레임워크
IT 인프라 서비스를 사용량 기반으로 제공하기 위한 서비스 시스템 전체 프레임워크는 다음과 같이 표현할 수 있다.
[그림 2-1] 인프라 서비스를 위한 사용량 기반 IT서비스 프레임워크
IT 인프라 서비스를 위한 계층은 사용자와의 접점인 비즈니스 레이어, 사용자가 선택한 서비스를 제공하고 관리하는 기능으로 구성된 딜리버리 레이어
그리고 가상화된 물리적 자원들의 집합인 리소스 레이어로 구성된다.
사용자에게 제공되는 서비스는 제공할 인프라 서비스의 특성과 가격, 정책
9
등을 수립하는 “계획”, 서비스 구현을 위한 “설계 및 구축”, SLA를 만족시키는 서비스를 사용자에게 안정적으로 제공하는 “서비스 운영관리” 그리고 서비스
품질을 평가하고 업그레이드나 개선이 필요한 요소를 찾는 “평가 및 개선”이라는
라이프사이클을 갖는다.
2.1.2 비즈니스 레이어(Business Layer)
비즈니스 레이어는 서비스를 사용하는 사용자와 인프라 서비스를 제공하기
위한 서비스 시스템 및 공급자와의 접점으로서 제공하는 서비스 카탈로그, 서비스 수준 협약(SLA), 계약 조건명세와 과금(가격계산 및 청구)으로 구성된다. 각 구성요소에 대하여 자세히 알아보면 다음과 같다.
가. 서비스 카탈로그(Service Catalog)
서비스 카탈로그는 IT서비스 공급자가 제공하는 서비스들의 목록으로서 사용자가 원하는 서비스를 손쉽게 선택할 수 있게 한다. 기능 측면에서 볼 때 식당의 메뉴판과 동일하다.
서비스 카탈로그는 대부분 다음의 요소들로 구성된다.
각 서비스에 대한 설명
서비스 제공에 소요되는 시간 또는 서비스 수준 협약
가격
서비스 제공 방법
몇 가지 인프라 서비스의 예:
10
VM 1대 (1GHz CPU 1개, 1GB Memory, 60GB Disk, Linux) Web 개발용 3-Tier 서버 (Web server[1GHz CPU 1개, 1GB
Memory, 60GB Disk, Windows2003], WAS Server[2GHz CPU 2개, 4GB Memory, 120GB Disk, Linux], DB Server[2.1GHz CPU 2개, 12GB Memory, 2TB Disk, Unix, ORACLE 10g])
SAP QA용 서버 개발용 서버 + LAMP stack (Standard VM + Linux, Apache,
MySQL, PHP/Python/PERL)
서비스 카탈로그는 사용자가 추가 옵션을 선택 또는 지정할 수 있도록 해야
한다.
나. 서비스 수준 협약(Service Level Agreement)
IT 인프라 서비스 수준의 정량적 측정을 통해 서비스 운영성과를 평가/관리하기 위하여 서비스 제공자와 사용자가 서비스 수준을 정의하고 이를
문서화한 계약체계다.
SLA는 제공되는 서비스에 대한 명확한 정의가 될 수 있어 사용자의 기대와 공급자가 제공하는 서비스 수준의 불일치에서 오는 마찰이나 갈등을 방지하는
역할을 할 수 있다. 그리고 개인 및 기업고객에게 서비스를 제공하기 위해서도 SLA는 꼭 필요한 사항이다.
다. 계약 조건(Terms & Conditions)
11
서비스 공급자와 사용자간의 서비스 제공 및 사용 계약에 대한 명세이다.예를 들면 서비스 공급자는 서비스 항목별 KPI(Key Performance Indicator) 및 SPI(Service Performance Index) 항목을 제시하고, 정기적으로 평가하여 고객에 제출한다는 내용을 계약 조건에 포함할 수 있다. 서비스 계약조건은 많은 양의 서비스를 장기간 사용하는 경향이 있는 기업고객에게 반드시 제공되어야
할 것으로 판단된다.
라. 과금(Accounting & Billing)
서비스 요금을 계산하고 청구하는 것으로 어카운팅과 빌링으로 구성된다.어카운팅은 자원 즉 인프라 서비스 사용량 데이터를 기반으로 사용자에게
적용되는 요율을 곱하여 청구할 가격을 계산하는 기능이고, 빌링은 요금 내역을 담은 청구서를 만들어 발부하는 기능이다. 적용하는 과금체계에 따라 미터링 및 애그리게이션이 필요 없이 어카운팅 및 빌링만으로 사용량 기반 가격체계를
구성할 수도 있다.
2.1.3 딜리버리 레이어(Delivery Layer)
딜리버리 레이어는 인프라 서비스를 요청한 사용자에게 자원을 할당하고, 할당된 자원의 상태를 모니터링하고, 사용자에게 할당된 자원의 사용량을 측정하는 등 인프라 서비스를 제공하기 위한 딜리버리 프로세스 및 운영관리
기능을 수행하는 계층을 의미한다. 즉, 딜리버리 레이어는 표준화된 인프라를 기반으로, 프로비저닝, 디프로비저닝, 이벤트 및 장애관리 프로세스를 수행하고, 워크로드 변동에 따라 자원 할당을 최적화하는 동적 최적화 기능 요소 등으로
구성된다.
12
주요 구성요소는 다음과 같다.
① 동적 스케쥴링(Dynamic Scheduling)은 사용자의 서비스 요청에 따라 인프라 자원의 최적 배분을 계획하고 실행하는 기능이다. 전체 자원 사용량은 최소화 하고, 각 개별 장비의 자원 사용률을 극대화 하는 기능을 수행한다. 그리고 예약 처리 기능도 수행한다.
② 용량 계획은 워크로드를 처리할 인프라 자원을 최적분배하기 위한 자원
용량 계획(capacity planning) 기능이다. 서비스 시스템 운영자는 전체 워크로드를 처리하는데 최소의 자원으로 수행할 수 있도록 자원을
최적으로 재분배 하기 위해 시뮬레이션 툴을 사용하기도 한다.
③ 모니터링은 사용자들에게 할당된 모든 활성 자원(Activated Resource)의 상태를 감시하는 것으로서 서비스에 영향을 줄 수 있는 이벤트나 장애
발생을 신속히 감지하여 관리자에게 알리는 기능을 수행한다. 물론 현재 상태에 대한 정보와 히스토리 정보를 제공하는 기능도 갖는다.
④ 미터링 및 애그리게이션(Metering & Aggregation)의 미터링은 자원사용량을 기반으로 요금을 계산하기 위해 사용자 별로 자원 사용량을
측정하고 그 데이터를 저장하는 것을 의미한다. 애그리게이션은 저장된 자원 사용량 데이터로부터 요금 계산에 필요한 데이터를 골라내어 사용자
별로 요금 계산에 적합한 형태로 처리하는 것을 말한다. 많은 경우에 시스템 사용량 측정 데이터로부터 직접 요금을 계산하기는 어렵기 때문에
이 과정이 필요하다.
13
딜리버리 레이어와 리소스 레이어에 기술 및 아키텍처 표준화, 운영관리 자동화, 그리고 자원 배분의 동적 최적화라는 원칙을 적용하는 것은 사용량 기반 IT서비스 시스템 구축에 필수적이다.
사용 장비 및 기술 스택에 가능한 한 높은 수준의 표준화를 적용할수록 운영
프로세스 표준화가 쉽고 자동화 적용 시 작업량을 줄일 수 있다. 그리고 표준화 수준이 높을수록 발생하는 장애 및 이벤트 종류가 줄어 들어 운영관리 효율을
높이고 서비스 중단 시간을 최소화 할 수 있게 된다. 이런 실질적인 이유 때문에 표준화의 원칙이 중요하다.
적절한 자동화 툴을 적용하여 서비스 할당 및 해제, 추가/변경 등의 운영관리 프로세스를 자동화 하여 민첩성을 확보하고, 운영효율을 극대화 하여야 한다. 자동화를 적용하지 않을 경우 훈련 받은 시스템 운영자 한 사람이 표준화 수준이
낮은 환경에서 관리할 수 있는 UNIX 서버는 약 20대, 표준화 수준이 낮은 상태에 자동화를 적용할 경우 30대~100대 범위인 것으로 조사 되었다. 그리고 대단히 높은 수준의 표준화와 자동화를 적용한 구글의 경우 이 수가
1,200인 것으로 알려졌다.
규모의 경제와 운영 효율화를 통해 인프라 서비스의 가격을 낮추기 위해서
높은 수준의 표준화와 자동화는 필수적인 요소이다.
서비스 인프라는 워크로드 처리에 필요한 최소의 자원으로 운영하는 동적
최적화가 가능하도록 설계, 구현되어야 한다. 개별 인프라 자원의 사용률을 극대화 함으로써 자산비용(Capital Expense)을 최소화 하고 전력, 냉각 및 전력 전송/변환 비용(Operational Expense)을 최소화 할 수 있다. 그리고 그린 컴퓨팅 트랜드에도 부합하기 위해 반드시 적용해야 할 원칙이다.
14
사용량 기반 IT서비스 시스템은 이 세가지 원칙에 따라 설계되고, 구현되고, 운영되어야 한다.
2.1.4 리소스 레이어(Resource Layer)
리소스 레이어(자원 계층)는 서버, 스토리지, 백업 장비, 네트워크 장비 및 회선 등의 IT 인프라 서비스를 제공하기 위한 실제의 자원 계층을 가리킨다. IT 인프라 자원은 일반적으로 서버, 스토리지 및 백업장비, 그리고 네트워크 장비로 구분한다.
서버는 크게 유닉스 서버와 리눅스 및 윈도우즈 서버로 구분할 수 있다. 사용자들이 많이 사용하는 플랫폼을 하드웨어 및 운영체제의 가용성과 가격에
따라 구분한다.
스토리지 및 백업 장비는 대용량 디스크 어레이, NAS(Network Attached Storage), 백업용 테이프 라이브러리, VTL(Virtual Tape Library), 그리고 SAN 스위치로 등이 포함된다.
네트워크 인프라는 L4/L7 네트워크 스위치, 라우터, 방화벽 (firewall) 장비, 이들이 결합된 어플라이언스 그리고 네트워크 회선으로 구성된다.
리소스 레이어는 각 IT 자원 종류별로 가상화 기술을 적용하여 자원 풀(resource pool)을 형성하게 된다. 가상화 기술을 적용 하여 사용자에게 필요한 만큼의 자원을 동적으로 할당할 수 있게 된다. 사용자 또는 워크로드에 필요한 만큼의 자원을 할당하여 자원 투입을 최적화 하기 위해서는 가상화 기술이
15
필수적이다.
IT 인프라를 서비스로 제공하기 위해서는 운영관리의 효율성을 위해 자동화 기술이 필수적이고, 인프라 환경이 가상화 되었을 때 자동화를 적용하기가 용이하다.
인프라 가상화 기술을 바탕으로 상위 레이어인 딜리버리 레이어에서 자동
프로비닝, 디프로비저닝 그리고 워크로드 변동에 따라 자원분배가 최적화 되는 동적 최적화 기능이 구현되게 된다.
2.1.5 서비스 라이프사이클
IT 인프라 서비스 제공자는 한 가지가 아니라 여러 종류의 서비스를 제공하게 된다. 그리고 경우에 따라서는 다수의 서비스 제공자가 단일 사용자 인터페이스를 통해 서비스를 제공할 수도 있다.
시간이 흐름에 따라 서비스는 업그레이드 되기도 하고, 더 이상 사용자의 수요가 없는 서비스는 폐기 되어야 한다. 따라서 서비스도 다음과 같은 라이프사이클을 갖게 된다.
서비스 계획 설계/구축 운영/관리 평가/개선
① 서비스 계획: 목표 고객(사용자)에게 제공할 서비스의 특성과 특징을 정의하고 가격 등을 결정 하는 것
② 설계/구축: 서비스 제공에 필요한 인프라/시스템의 아키텍처를
16
설계하고 실제로 구현하는 것
③ 운영/관리: 고객에게 서비스가 원활히 제공되도록 서비스 제공에 필요한 전체 인프라 및 인력을 운영 관리하는 것
④ 평가/개선: 서비스가 고객이 만족할 만한 수준으로 제공되는지 평가하고, 개선이 필요한 부분은 업그레이드 작업을 수행하는 것
2.2 인프라 서비스 비용 모델
2009년 현재 이미 여러 종류의 IT서비스가 제공되고, 사용되고 있다. 호스팅, 매니지드 호스팅, 그리고 IT 아웃소싱은 이미 수년 전부터 많은 기업들이 사용해 왔고, 비교적 근래에 소개된 인프라 서비스, 플랫폼 서비스 그리고 소프트웨어 서비스 사용자가 증가하고 있다.
IT 인프라 서비스를 위한 적합한 서비스 비용모델을 찾기 위해 각 서비스별 비용 요소를 조사해 보았다. 이들 각각의 서비스에 따른 비용 요소는 아래와 같이 요약할 수 있다.
17
[그림 2-2] 서비스 종류에 따른 비용 요소
가. 인프라 서비스 비용의 구성
IT 인프라 서비스를 제공하려면 데이터센터, IT 자산, 네트워크 회선에서부터 운영인력에 이르기까지 모든 요소가 필요하다. 따라서 IT 인프라 서비스를 제공하기 위한 비용요소는 데이터센터 공간비용, 전력 및 냉각 시설/설비 비용, IT 자산비용, 인력비용 그리고 IT 장비가 사용하는 전력 및 냉각전력 비용으로 구성된다. 이 비용에는 시설/설비 및 IT 자산의 유지보수 비용과 상각 비용이 반드시 포함되어야 한다.
이들 모두가 IT 인프라 서비스를 제공하는데 필연적으로 발생하는 비용으로서 IT서비스 사용량 변동에 따른 비용변화를 이해하기 위해서 다음과 같이 요약할 수 있다.
18
[그림 2-3] 인프라 서비스를 제공하기 위한 비용 요소
[표 2-1] 인프라 서비스를 제공하기 위한 비용 요소비용 요소 설명
공간비용(CapEx)
데이터센터 공간 비용. 즉 토지 구매 또는 임차비용과 데이터센터 건물 건축/임차비용, 그리고 건물 유지보수 비용을 포함
상당한 규모의 초기 투자비용과 비교적 일정한 수준의 유지보수 비용으로 구성
데이터센터 공간비용은 IT서비스 사용량 변화에 영향을 받지 않음
시설/설비 비용
(CapEx)
냉각장비, 전력설비, 네트워크 회선의 초기 구축비용 및 유지보수(운영관리) 비용
상당한 규모의 초기 도입비용과 비교적 일정한 수준의 유지보수(운영관리) 비용으로 구성
시설/설비 비용은 IT서비스 사용량 변화에 거의 영향을 받지 않음IT
자산비용(CapEx)
하드웨어 및 소프트웨어 등의 IT 자산 구입, 시스템 구축 및 유지보수 비용
IT 자산 비용은 초기 도입비용 및 유지보수 비용으로 구성하드웨어는 TiCAP(Temporary instant Capacity: 선불 전화카드처럼 CPU 활성화 시간에 따라 사용료 지불하는 요금제) 등을 적용했을 경우 사용량 변화에 따라 비용이 약간 변동함
사용량 변동환경을 고려하여 사용자 수나 사용 시간에 따라 라이선스 비용이 결정되는 소프트웨어는 2009년 현재 거의 없음
IT 자산은 일단 도입하면 IT서비스 사용량 변화에 따른
19
비용변화는 아주 작음
인력비용(OpEx)
IT 인프라/서비스 운영인력 및 관리인력 비용 운영인력 및 관리인력의 급여, 수당과 복지후생비로 구성고용의 비탄력성 때문에 IT서비스 사용량이 감소해도 IT 인력을 즉각적으로 줄이기 어려움. 그리고 업무량이 0.5명분 감소했을 경우 인력을 0.5명 줄일 수는 없음. 변화가 비교적 긴 시간 동안 지속될 때 인력 비용이 변동됨
운영이 고도로 자동화된 경우에는 전체 운영자의 수가 적어 IT서비스 사용량이 감소해도 인력비용 감소는 거의 발생하지 않음
전력비용(OpEx)
IT 장비가 사용하는 전력, 기계실 냉각 전력과 전력 전달/변환에 소모되는 전력 비용
IT 장비가 사용하는 전력은 전체의 40%~50%, 냉각 전력은 약 30%, 전달/변환 소모 전력은 20%~30%를 차지
장비 사용 전력비용은 IT서비스 사용량 변화에 따라 변동. 상관계수는 0.7 이하일 것으로 추정. 냉각 전력과 전달/변환 소모 전력도 변동. 냉각 전력의 상관계수는 0.5 이하 일 것으로 추정
Demand-Based Switching CPU/Dynamic Power Usage Management/가상화/워크로드 최적 재분배, Dynamic Smart Cooling 등을 적용했을 경우 IT서비스 사용량 변화에 따라 전력비용이 크게 변동함
Costtotal = Costspace + Costfacility + CostITAsset + Costpersonnel + Costpower
IT 인프라 서비스를 위한 전체 비용은 공간비용, 시설/설비 비용, IT 자산비용, 인력비용 그리고 전력비용의 합이라고 볼 수 있다. 이 전체 비용을 월별 비용으로 환산하려면 자산비용 성격이 강한 공간비용, 시설/설비 비용, IT 자산비용은 감가상각 기간에 따라 정액법 등을 적용하여 환산하면 된다. 운영비용인 인력비용과 전력비용은 월별 비용을 상대적으로 쉽게 구할 수 있다.
비용구성 요소를 모두 이해해도 IT 인프라 서비스의 가격을 결정하는 것은 단순하지 않다. IT 인프라 서비스를 위한 적합한 서비스 비용 모델을 만들고, 사용자에게 제공하는 서비스의 가격을 결정하기 위해서는 비용발생 요소 모두를
이해하고, 고정비용과 변동비용이 차지하는 비중과 그 규모에 대한 정확한
20
데이터를 가져야 한다.
이 데이터를 기반으로 IT서비스 사용량에 따른 손익 분기점을 예측할 수 있고, 수익을 유지하기 위한 적정한 가격 모델을 선택하고 서비스의 가격을 책정할 수
있기 때문이다. 그리고 데이터센터의 위치와 환경 구성에 따라 이 비용이 크게 달라지게 되므로([표 2-2] 참조) 각 데이터센터 별로 이 비용을 실제로 측정, 계산하여야 한다.
[표 2-2] 인프라 서비스 생산비용에 차이가 발생하는 요인비용 항목 비용에 차이가 발생하는 요인
공간비용
건물의 위치/입지에 따른 토지 비용(임차 또는 구매)데이터센터 규모, 등급 또는 데이터센터 구축방식 (콘크리트 건물 또는 컨테이너)에 따른 단위 면적당 건설비용
지역에 따른 세금차이 또는 과세 기관과의 협상에 따른 세금 차이
시설/설비 비용전력 및 냉각 장비의 모델 (High-end, Mid range,
Low-end)시설/설비 이중화 또는 여유율
IT 자산비용구매 가격 (구매 장비의 수에 따른 할인율 차이 및 구매 시점에 따른 가격 차이)
규모 또는 협상 결과에 따른 라이선스 비용차이
인력비용
운영인력의 스킬 차이에 따른 운영 효율성 IT 인프라 환경 복잡성 수준에 따른 운영 효율성운영관리 프로세스 자동화 수준에 따른 운영 효율성운영인력의 연령구성에 따른 인력 비용
21
전력비용
개별 장비의 전력 사용 효율 (Demand-Based Switching CPU/Dynamic Power Usage Management)
워크로드에 따른 동적 자원 재분배 수준 (가상화, 자동화)
기계실 장비 배치 및 냉각 방식 (모듈라 쿨링 시스템, 외기 냉각, 스태틱 스마트 쿨링, 다이내믹 스마트 쿨링)
데이터센터 외부의 기온에 따른 냉각비용
나. 인프라 서비스 비용 중 고정비용과 가변비용의 비중
여러 가지 조사를 통해서 알게 된 것은 처음의 예측과는 달리 IT서비스 사용량이 변해도 IT서비스 생산/공급 비용 요소의 상당 부분은 변동하지 않고 고정되어 있다는 것이다.
데이터센터 공간비용은 데이터센터 건물 건축/임차비용, 그리고 건물 유지 보수 비용으로 구성되는데 건물의 구조나 크기에 따라 단위 서비스당
공간비용이 달라질 수는 있으나 IT서비스 사용량이 변화해도 공간비용은 거의 아무런 영향을 받지 않는다. 어떤 장비가 설치되어 일정 공간을 점유하면 사용자 서비스에 사용되든(Active State) 사용되지 않든(Inactive State) 점유 공간에는 변화가 없기 때문이다.
냉각장비, 전력설비, 네트워크 회선의 초기 구축비용 및 유지보수 (운영관리) 비용으로 구성되는 시설/설비 비용도 IT서비스 사용량 변화에 거의 영향을 받지 않다. 냉각기(chiller), CRAC(Computer Room Air Conditioning unit), 발전기, UPS(Uninterruptible Power Supply), PDU(Power Distribution Unit) 등이 포함되는 시설/설비 비용은 상당한 규모의 초기 도입 및 구축 비용과
22
IT서비스 사용량 변화에 별다른 영향을 받지 않는 비교적 일정한 수준의 유지보수 비용으로 구성되기 때문이다.
IT 자산비용은 하드웨어 및 소프트웨어 등의 IT 자산 구입, 시스템 구축 및 유지보수 비용으로 구성된다. 하드웨어는 일단 도입되면 단기적인 사용/비사용 상태에 별다른 영향 없이 일정한 수준의 비용이 발생한다. 다만 TiCAP(Temporary instant Capacity : 선불 전화카드처럼 CPU 활성화 시간에 따라 선불 사용료를 차감하는 요금제) 같은 것을 적용했을 경우 사용량 변화에 따라 비용이 약간 변동할 뿐이다. 그리고 2009년 현재 사용량 변동환경을 고려하여 사용자 수나 사용 시간에 따라 라이선스 비용이 달라지는
소프트웨어는 거의 없다. 즉, IT 자산은 일단 도입하면 IT서비스 사용량 변화에 따른 비용변화는 아주 작다고 결론지을 수 있다. 그리고 연구 조사에 의하면 인프라 서비스(하드웨어 및 시스템 소프트웨어를 서비스로 제공)를 위한 전체 비용 중 IT 자산비용이 차지하는 비중은 30% 이내인 것으로 파악되었다(물론 다른 부분의 비용 효율성에 따라 이 비율은 달라진다. 일반적으로 IT 자산비용이 차지하는 비중은 20%~50% 범위에 있는 것으로 조사되었다).
IT인력은 고용의 비탄력성 때문에 IT서비스 사용량이 감소해도 IT 인력을 즉각적으로 줄이기 어렵다. 업무량이 0.5명 분 감소했다고 인력 0.5명을 즉각 줄일 수는 없기 때문이다. 그리고 서비스 인프라 운영이 고도로 자동화된 경우에는 전체 운영자의 수가 적어 IT서비스 사용량이 비교적 큰 범위에서 증감해도 인력비용은 거의 변동하지 않는다.
전력비용은 IT서비스 사용량 변화에 따라 비교적 큰 폭으로 변동할 수 있다. 워크로드에 따라 전력 사용량이 달라지는 Demand-Based Switching CPU가 탑재된 서버 사용, Dynamic Power Usage Management 적용, 가상화를
23
통한 워크로드 최적 재분배, 기계실 냉각에 Dynamic Smart Cooling 등을 적용했을 경우 IT서비스 사용량이 증가하면 전력 사용량이 증가하고, IT서비스 사용량이 감소하면 전력비용이 감소한다. 그리고 IT 장비의 전력 사용량이 감소하면 기계실 냉각 전력 사용량과 전력 변환 및 전달 사용량도 함께 감소
하는 케스케이드 효과(Cascade Effect)로 인해 IT 장비의 전력 사용량이 1Kw 감소 시 전체 전력 사용량은 2.4 Kw ~ 2.8Kw가 감소하게 된다.
IT서비스 생산 비용 요소 중 전력비용은 IT서비스 사용량 변화에 따라 비교적 큰 폭으로 변동할 수 있지만 모든 데이터센터에서 일률적으로 적용할 수 있는
일반적인 특성이 아니라 위에서 언급한 그린 IT 기술이 적용되고 적극적으로 관리될 경우에 해당되는 것이고, 전력 사용 효율화 기술의 적용 및 관리 수준에 따라 IT서비스 사용량 변동에 따른 전력 사용량 변동 폭이 달라진다는 것을 유의해야 한다.
[그림 2-4] 서비스 사용량 변동에 따른 IT서비스 생산 비용의 변화(고정비용과 가변비용 비중)
24
앞에서 알아본 바와 같이 IT서비스 제공을 위해 발생하는 비용의 상당부분은 고정비용이고 서비스 사용량 변동에 따라 변하는 가변비용은 작은 일부만을
차지한다.
데이터센터의 규모나 운영환경에 따라 달라지지만 연구 조사에 따르면 IT서비스 생산/공급 비용의 80% 이상을 고정비용이 차지하고 가변비용은 20% 미만인 것으로 알려졌다. 따라서, 사용량 기반 IT서비스를 구현하여 IT서비스의 가격을 사용량에 따라서 부과하는 가격모델을 만들 때 사용량에 따라 변동하는
가변비용 요소는 전체 비용의 20% 미만이라는 사실을 반영한 현실적인 모델을 도출하여야 한다.
다. 인프라 서비스 가격 모델
사용량에 따라 가격이 결정되는 IT서비스 비용 모델은 이론적으로 7~8 가지 방법이 가능할 것으로 조사되었다. 그러나 현실적으로 적용 가능한 실질적인 인프라 서비스 가격 모델은 다음과 같이 크게 세 가지 정도로 구분할 수 있다.
① 서비스 자원 단위별 가격(Resource Unit Pricing)
정의된 표준 사양의 서비스 단위별로 자원 유닛(Resource Unit)의 크기를 결정하고, 자원 유닛의 단위 시간당 사용료를 책정하여 서비스 가격을 산정하는 방식이다.
자원 유닛은 구입 가격 및 유지보수 비용을 반영하여 크기를 결정하고, 단위 시간당 사용료는 운영관리 비용을 반영하여 결정한다. 그리고 자원의 유형별로
25
운영관리 부담이 달라지므로 단위 시간당 사용료를 달리 책정한다.
가격 산정 절차를 설명하면 다음과 같다.
서비스 자원 즉 인프라 서비스에 필요한 하드웨어 및 관련 소프트웨어의
구입가격 및 유지보수 비용을 감안하여 기본 서비스 단위별로 자원 유닛
(RU)을 책정한다.
예) VM (1GHz, 1CPU, 1GB Mem) 1 RU VM (2GHz, 2CPU, 2GB Mem) 2 RU VM (3GHz, 2CPU, 4GB Mem) 2.5 RU Unix (1.6GHz, 1CPU, 4GB Mem) 5 RU Unix (1.6GHz, 2CPU, 6GB Mem) 8 RU Unix (2GHz, 4CPU, 8GB Mem) 10 RU Storage (1GB, RAID5) 5 RU Storage (1GB, RAID10) 8 RU Network (1Gb) 3 RU
자원 유닛 유형별로 단위 시간당 사용료를 책정한다. 자원의 종류에 따라 운영관리 부담이 달라지므로 단위 시간당 사용료는 자원 유형에 따라
다르게 책정한다. 또는 장비의 등급이 달라 가용성이나 OS 등이 달라져도 단위 시간당 사용료를 달리 책정한다.
예) 컴퓨트 자원 A (Win2K or Linux VM) 130원/Hr
26
컴퓨트 자원 B (UNIX) 500원/Hr 스토리지 자원 A (for Light service) 0.3원/Hr 스토리지 자원 B (for Standard service) 0.6원/Hr 스토리지 자원 C (for Premier service) 0.9원/Hr 네트워크 자원 100원/Hr
사용료는 다음과 같은 방식으로 계산한다.
사용료 = 자원 단위(RU) X 1시간 사용 요율 X 사용한 시간 X 사용한 자원의 수량
사용한 각 자원의 유형별로 가격을 계산하여 이들 모두를 더하면 전체
사용료가 계산된다.
예) 자원 단위 1 시간 사용요율 사용한 시간 /사용한 자원량 수 요금
서비스 자원 Resource Unit (RU) Rate (Won/Hr) Use Time (Hour) Amount (Unit) Fare (Won)VM (1GHz, 1CPU, 1GB Mem) 1 130 24 100 312000VM (2GHz, 2CPU, 2GB Mem) 2 130 1 1 260VM (3GHz, 2CPU, 4GB Mem) 2.5 130 1 1 325Unix (1.6GHz, 1CPU, 4GB Mem) 5 500 24 1 60000Unix (1.6GHz, 2CPU, 6GB Mem) 8 500 1 1 4000Unix (2GHz, 4CPU, 8GB Mem) 10 500 1 1 5000Storage (1GB, RAID5) 5 0.3 26 4000 156000Storage (1GB, RAID10) 8 0.3 3 1500 10800Network (1Gb) 3 100 3 1 900
[표 2-2] 서비스 자원 단위별 가격 산정 예
이 모델은 인프라 서비스 종류 및 단위별로 단위 시간당 사용료가 정해져
있다는 면에서 Amazon이 EC2, S3 등의 서비스에 적용한 방식과 유사하다. 사용자에게 할당된 자원은 실제 사용 여부에 관계없이 그리고 자원의 실제
사용률에 관계 없이 할당된 시간 동안 전체 자원을 사용한 것으로 계산하는
27
방식이다.
이 모델의 장점은 다음과 같이 정리할 수 있다.
새로운 서비스 추가 시 가격 결정 용이 : 새로운 서비스는 동일 유형 유사 크기 자원과 비교하여 자원 유닛의 크기만 결정하면 되므로 그 가격을
산정하기가 용이함
미터링이 불필요 : 사용자에게 할당된 각 인프라의 실제 자원 사용률을 측정하지 않고, 할당 받은 자원의 유형, 수량과 사용한 시간을 계산하여 가격을 산출함
이 모델은 서비스 자원의 단위 크기가 작고(1GHz CPU 1개, 메모리 1GB VM처럼), 불특정 다수의 고객이 인프라 서비스를 불규칙한 패턴으로 사용할 때 적합하다.
② 개별 장비 사용량에 따른 가격(Share-based Usage Pricing)
어떤 특정한 자원을 다수의 사용자가 함께 사용할 때 각 사용자별로 자원
사용량을 측정하여 이 사용량에 기반한 가격을 매기는 방식이다. 사용료는 자원의 1시간 사용 요율을 사용한 시간과 사용한 자원의 양을 곱하여 계산한다. 각 사용자 별로 사용료를 계산하기 위해서는 사용자별로 자원 사용량을
측정해야 한다.
이 모델은 대형 IT 자원을 다수의 사용자가 공유할 때 적합한 방식이다. 즉, HP Superdome 같은 대형 장비에 여러 사용자의 애플리케이션이 탑재되어
28
시스템 자원을 공유할 때 적용할 수 있다. 즉, 애플리케이션의 워크로드가 커서 대형 장비가 필요하고, 워크로드가 일정한 것이 아니라 시간에 따라 변동 폭이 큰 경우에 적합하다.
특정 서버에 워크로드 변동이 있는 애플리케이션 한 종만 탑재할 경우 평균
자원사용률이 35%를 넘는 경우는 드물기 때문에 다수의 사용자가 공동으로 사용하여야만 자원 사용률을 높일 수 있다. 한 사용자만 사용할 경우 서비스 제공자 입장에서 보면 전체 자원을 독점한 것이기 때문에 전체 자원을 100% 사용한 가격을 부과해야 한다. 따라서 사용자가 치르는 가격을 낮추기 위해서는 다른 사용자와의 공유가 필수적이다.
이 경우에도 물론 구입가격, 유지보수비용, 그리고 운영관리비용을 계산하고 전체 자원의 평균사용률을 감안(예측)하여 단위 시간당 사용료를 결정하여야 한다. 전체 비용과 예측한 평균 사용량을 계산하여 손익 분기점을 결정하고 이에 기반하여 단위 시간당 사용료를 결정해야 한다.
③ 기본료 + 사용량 기반 가격
인프라 서비스 사용료를 전화요금처럼 고정액의 기본료와 사용량 기반
가격으로 구성하는 방식이다. 서비스 사용료는 최소 사용량에 기반한 기본료와 사용량 변동에 따라 책정되는 사용량 기반 가격의 합으로 구성된다.
이 방식은 대형 IT 자원을 장기간 동안 지속적으로 사용하고, 최소 사용 시점에도 자원의 상당부분을 항상 사용하며, 워크로드가 시간에 따라 비교적 큰 폭으로 변동하는 경우에 적합하다.
29
자원 사용률을 극대화 하고, 사용량에 기반하여 가격을 책정하기 위해서는 워크로드가 작은 애플리케이션을 다수 탑재하여 자원을 공유하는 환경이 되어야
한다.
이 모델도 사용자별로 자원 사용량을 측정해야 한다. 이 방식은 그룹 계열사의 기간 시스템 등에 적용하기 적합하다.
2.3 인프라 서비스를 위한 시스템 아키텍처
IT 인프라 서비스 시스템을 구축하기 위해서는 가상화된 인프라를 기반으로 서비스 인프라 관리 및 서비스 포탈이 기능을 구현하여야 한다.
30
인프라 서비스를 위한 시스템 아키텍처는 아래와 같이 3개의 계층구조로 표현할 수 있다.
[그림 2-5] 인프라 서비스를 위한 시스템 아키텍처 모델
가. 서비스 포탈
서비스 포탈 계층은 사용자와 시스템 관리자가 웹 브라우저를 사용하여
서비스 시스템에 액세스할 수 있는 웹 인터페이스를 제공한다.
서비스 포탈은 일반 사용자를 위한 ‘사용자 셀프 서비스 포탈’과 시스템
관리자를 위한 ‘관리자 포탈’로 구성된다.
‘사용자 셀프 서비스 포탈’은 다음과 같은 기능을 제공한다.
서비스 카탈로그 : 메뉴판 같은 기능을 제공하여 사용자는 서비스 종류,
31
옵션 그리고 사용 기간을 선택할 수 있음
내 서비스 : 요청 또는 예약한 서비스의 상태, 현재까지의 사용 요금과 전체기간 동안의 예상 요금, 과거 서비스 사용 이력 정보를 제공
상태 모니터링 : 사용자에게 할당된 자원과 현재 상태를 보여줌
‘관리자 포탈’은 시스템 운영자에게 다음의 기능을 제공한다.
요청 승인 : 관리자의 승인을 필요로 하는 요청 목록 및 승인/거절 기능 자원 관리 : 모든 자원의 활성화/비활성화 상태와 상세정보, 자원 할당 여부와 성능 및 용량 계획을 위한 기능 제공
상태 모니터링 : 인프라의 현재 상태와 장애처리를 위한 기능 제공
나. 서비스 인프라 관리
서비스 인프라 관리 계층은 사용자의 서비스 요청이나 관리자가 실행시킨
기능을 수행하기 위하여 전체 워크플로우를 관리하고, 서비스와 인프라의 상태를 모니터링하고, 보안 상태를 유지하며 사용자가 접근할 수 있는 인터페이스 또는 액세스 채널을 제공한다.
이 계층의 기능은 크게 서비스 인터페이스 & 액세스, 서비스 오케스트레이션, 그리고 상태 모니터링 및 보안 세 가지로 요약할 수 있다.
‘서비스 인터페이스 & 액세스’ 모듈이 제공하는 기능은 아래와 같이 요약 정리할 수 있다.
서비스 사용자가 자신에게 할당된 자원에 액세스 할 수 있는 채널,
32
인터페이스 그리고 툴(tool)을 제공 API, 커맨드라인 인터페이스(Command Line Interface), 또는
DCML(DCML Exchange Tool) 등의 인터페이스를 제공
서비스 오케스트레이션은 교향악단의 지휘자가 하는 역할처럼 하위의 여러
구성요소들이 올바른 순서로 필요한 태스크를 수행하도록 워크플로우를
관리하고, 관련 데이터를 업데이트 하는 기능을 수행한다. 그리고 하위 구성 요소는 단순화하여 세 가지로 요약할 수 있다.
인프라 프로비저닝 & 스케일링 : 서버, 스토리지, 그리고 네트워크 대역폭을 할당하고 컨피규레이션을 설정하여 사용 가능하게 함. 그리고 자원을 추가하거나 사용하지 않는 자원을 풀(pool)로 되돌리는 기능을 수행
워크로드 & 전력관리 최적화 : 워크로드의 변동에 따라 VM을 물리 서버 상에 재분배 하고, 전력 공급량/동작 모드를 조절하여 자원 및 전력 사용량을 최적화 하는 기능을 수행
사용량 미터링 & 빌링 : 자원 사용량 정보를 수집하여 보관하고, 사용자별로 자원 사용량과 사용기간에 따라 가격을 계산하는 기능을 수행
33
[그림 2-6] 인프라 서비스 아키텍처(자원 할당 및 사용량 기반 빌링)
상태 모니터링 및 보안은
상태모니터링 컴포넌트는 서비스 자원의 상태를 감시하고 발생하는
이벤트에 따라 사용자나 관리자에게 메시지를 통보하는 기능을 수행
보안 컴포넌트는 해킹 시도 등의 침입탐지, 인가되지 않은 사용자의 불법적인 액세스, 바이러스 등의 보안 위협 요소를 감시하고 이벤트 발생 시 메시지를 통보하는 기능을 수행
다. 인프라 가상화
인프라 가상화 계층은 서버, 스토리지 등의 물리적 인프라와 가상화 기술을 적용하여 이들을 가상화한 가상 자원을 제공한다.
34
자원 가상화 및 통합 계층은 각 구성요소가 제공하는 가상화 기술을 바탕으로
추상화된 자원을 제공한다. 각 자원별로 구성 요소와 제공 기능을 요약하면 다음과 같다.
서버
- X86 또는 UNIX 계열 서버들로 구성됨- Xen, VMware, Hyper-V 등을 통해 VM을 제공
스토리지
- 대용량 스토리지(External Disk Array) 또는 내장 디스크로 구성됨- 서버, 어플라이언스 또는 스토리지에 구현된 가상화 기술을 통해 저장 공간을 제공
네트워크
- 네트워크 가상화 기능을 제공하는 스위치 또는 버추얼 커넥트 모듈로
구성됨
- 서비스 단위별로 가상랜을 구성하여 네트워크를 분리하고 필요한
네트워크 대역폭을 제공
3. IT활용 최적화를 위한 사용량 기반 IT서비스 적용
3.1 주요 고려사항
3.1.1 IT전략적 고려사항
35
가. IT 관리 인력들이 느끼는 위협
IT서비스 자체가 유연한 형태로 변형되면 내부 인력들도 유연성을 가져야 하는데 이와 관련된 직업의 안정성은 어느 정도 약화된다고 볼 수 있으며 이러한
점으로 인해 내부 IT 인력은 사용량 기반 IT서비스 추진에 반감을 가지고 있다. 특히 내부 관리 인력의 관점으로 볼 때 사용량 기반 IT서비스가 가져다 주는 비용적 이익이나 유연성을 통한 비용절감이나 비즈니스 기여의 가능성보다
성숙되지 못한 기술의 도입으로 야기될 수 있는 안정성에 대한 위협 요인이
사용량 기반 IT서비스의 본격적 추진을 어렵게 하고 있다.
나. 벤더 중립성에 대한 중요성
사용량 기반 IT서비스의 개념으로 볼 때 특정 벤더에 종속된 서비스는 기술적, 환경적으로 제약 요인이 많아 진정한 사용량 기반 IT서비스를 구현하기 위해서는 다양한 벤더의 특장점을 고루 취하면서도 한 업체에 종속되지 않는
기술의 유연성이 필요하다. 그러나 기반 기술을 H/W 벤더에 의존하는 IT서비스 업체나 고객은 기술적인 역량의 한계에 도달하게 된다. 또한 H/W 벤더가 추진하는 사용량 기반 IT서비스는 자사의 제품을 최대한 이용하는 형태로 발전되기 때문에 벤더 의존성과 관련된 고객의 위험 부담이 생기게 된다.
특히 H/W 벤더의 솔루션에는 고객의 전략적 입장에서 치명적인 단점을 가지고 있는데, 이들이 자사 제품 중심으로 서비스를 구성하고 일단 그들의 서비스 체계에 접목되면 그들로부터의 이탈이 매우 어려워 기술적 종속 현상이
나타날 수 있으며 그러한 구조에서는 장기적인 비용 절감이 가능하지 않을 수도
있다.
36
다. 네트워크(회선) 업체 관점
중앙 집중적인 대규모 end-to-end 사용량 기반 IT서비스의 원활한 제공을 위해서는 네트워크 업체의 협조는 필수요인이다. 그러나 네트워크 업체의 관점에서 볼 때 사용량 기반 IT서비스는 큰 장점이 있는 사업모델이 아니다. 진정한 사용량 기반 IT서비스 구현을 위해서는 새로운 비즈니스 모델을 개발하던지 회선 사업에 뛰어들던지 등의 해결방안 모색이 필요하다.
라. 사용량 기반 IT서비스 제공 업체의 단기적 매출 감소에 대한 감수
적용 초기에는 TCO 절감을 기본으로 비즈니스 사례를 제시하게 되는데, 같은 고객을 놓고 볼 때 이는 직접적인 매출 감소를 의미한다. 단 매출 감소가 이익의 감소로 연결되지 않도록 Delivery 모델을 개발해야 하며 규모의 경제를 실현할 수 있도록 고객층의 확보에 힘써야 한다.
성공조건 배경
높은 브랜드 인지도
사용량 기반 IT서비스의 특성상 급작스런 서비스의 중단이나 사고로 인한 정보의 분실 등은 사용자들에게 중대한 손실을 야기할 수 있어, 서비스의 지속성과 안정성을 보장할 수 있는 높은 브랜드 인지도가 중요
IT 자원에 대한 규모의 경제 달성
사용량 기반 IT서비스 제공자는 막대한 물리적인 IT인프라 구축이 필수적이므로 이를 저렴하게 구축하고, 단위 인프라에 대한 효율성(단위 인프라당 평균사용자 이용도)를 높이는 것이 핵심 경쟁력으로서 이를 위해서는 규모의 경제 달성이 중요
검증된 서비스 운용 경험
IT 자원의 효율성을 극대화하면서도 사용자에게 안정적인 서비스를 제공하기 위해 가변적인 사용자들의 서비스 요청을 최적화된 자원배분을 통해 실시간적으로 제공할 수 있는 고도화된 S/W 기술력 및 플랫폼의 유연성과 안정성을 동시에 만족시킬 수 있는 기술력이 필수적
3.1.2 IT비용 측면의 고려사항
37
가. IT 예산 및 투자
사용량 기반 IT서비스의 도입은 IT 재무 관리 구조 및 IT 예산 및 투자에 전환을 가져올 것으로 예상된다. 왜냐하면 사용량 기반 IT서비스는 IT 자원을 반드시 구매해서 시간과 비용을 들여 기업 내부에 고정적으로 설치하는 개념이
아니라 정기적인 사용료를 지불하며 안정적으로 서비스를 이용하는 계약
형태이기 때문이다. 따라서 총 소유비용에서 고정비용(IT 인프라 도입 및 구축)과 업그레이드, 유지보수 비용을 절감할 수 있다. 이렇게 절감된 비용은 새로운 비즈니스 수행을 위한 신규투자로 재투자됨으로써 기업의 IT구조가 이전에 비해 좀 더 비용 효율적인 IT구조로 바뀔 것으로 예상된다.
나. IT 인프라스트럭처의 구매 및 소유
사용량 기반 IT서비스는 IT 인프라스트럭처의 구매 및 소유 형태를 변화시킬 것으로 예상된다. 기존에는 IT 인프라를 자산으로 구매하거나 IT서비스 형태(SI)로 구축하는 형태였지만, 사용량 기반 IT서비스는 단지 서비스 혹은 렌트 개념으로 구매만 하면 끝나기 때문이다.
따라서, 이전에는 고정자산과 관리의 개념으로 고가의 비용을 지불해야 했지만, 사용량 기반 IT서비스는 필요한 만큼 사용하고, 사용한 만큼만 지불하면 되는 환경이 가능해지고, 필요 이상으로 IT 인프라를 구매할 필요가 없기 때문에 유휴 IT 인프라스트럭처가 줄어들어 자원 효율성이 증가하게 된다.
가능한 비용절감의 주요 요소는 다음과 같이 크게 3가지로 나누어 진다.
38
① 전략적 통합 구매를 통한 절감
IT 운영 규모가 큰 고객의 일반적인 사례로 볼 때, 벤더로부터 자산을 직접 협상/구매하는 경우 고객은 자신이 구매하는 물량에 대한 협상이 이상적으로 잘 되었다고 생각하는 경우가 대부분이나 정보 능력의 불균형으로 인하여 현실은
벤더가 유리한 방향으로 진행되는 것이 대부분이다. 이러한 현상의 가장 큰 이유는 개별 고객이 IT 자산의 가치를 평가할 객관적인 기준을 가지지 못하고 있기 때문이며 벤더들은 전략적으로 고객이 객관적 판단을 할 수 있는 잣대를
제공하지 않는다.
실제 각 고객사들이 직접 벤더들과 협상하여 구매를 결정한 사례를 볼 때
고객들이 획득하는 List Price 대비 할인율의 산포는 매우 크다. 같은 상황에서 비교적 객관적 판단의 능력이 많은 IT서비스 업체가 협상을 한다면 아래 [그림 3-1]과 같이 할인율 산포만 개선해도 직접적 비용 절감이 5% 이상 가능하다는 검토 결과가 있다.
사용량 기반 사용량 기반 서비스 적용 전 서비스 적용 후
[그림 3-1] 제품 할인율 변화(예)
예측할 수 있는 구매물량을 바탕으로 벤더와 협상하는 체계가 수립되면 기기
39
종류별 표준화를 유도하기도 용이하다. 같은 물량이라도 표준 기종을 정하고 연중 구매 일정을 계획하고 그에 따라 집중적으로 구매역량을 발휘하면 괄목할
만한 비용절감을 기대할 수 있다. 그에 더하여 각 기기의 용량을 측정할 수 있는 객관적인 기준을 설립하여 H/w 벤더들이 제공하는 이 기종간의 비교/평가 역량을 확보하는 것이 필요하다.
② 표준화에 기반된 운영 자동화를 통한 절감
IT 자산에 대한 표준화가 수립되면 운영의 자동화도 용이하다. 매번 다른 기종의 상이한 구성(configuration)을 대상으로 운영하는 것과 익숙한 기종이 유사하게 구성되어 있는 경우 운영 효율성의 차이가 나는 것은 명확하다. 특히 동일한 프로세스로 표준화된 장비를 대상으로 운영한다면 자동화에 투자를 하여
더 높은 생산성을 추구하는 것은 당연한 과제이다. 자동화에 자체 솔루션을 사용하던 전문 솔루션을 사용하던 상황에 맞는 자동화 시스템을 구축하면 된다. 단 자동화 프로젝트의 타당성은 개선되는 효과에 비추어 적정 규모를 투자하여
과다한 자동화를 지양하는 것이 바람직하다. 시스템 운영의 자동화에 대한 투자는 꼭 사용량 기반 IT서비스의 실현 이외에도 많은 파급 효과를 가져다 줄 수 있는 인프라 운영의 핵심 기술이므로 자동화 기술에 대한 투자는 필수적이라
하겠다.
③ 기기 교체 (technology refresh)를 통한 절감
IT 자원이 수행할 수 있는 동일한 컴퓨팅 자원 능력(computing resource power) 대비 가격은 매년 현격하게 감소하는 것이 현실이다. H/W 벤더들은 경쟁을 위해 매년 성능이 개선된 신규 모델을 출시하지만 박스별 가격은 큰
차이가 생기지 않는다. 이런 현상을 활용하여 박스별 대가체계가 아닌 제공 용량
40
또는 컴퓨팅 자원 능력별 대가체계를 통한 Delivery 모델을 적용하면 현격한 비용 절감을 실현할 수 있다. 이러한 체계는 "사용량 기반" 대가체계로 표현될 수 있는데, 이는 사업자가 제공하는 절감 노력과 함께 고객도 자원 사용의 필요성과 연관된 의사결정을 할 수 있어 고객과 사업자의 협력을 통한 비용
절감이 용이하다. 기기 교체를 통한 절감은 "Price Performance"라는 논리를 사용하여 추진되는데, 이는 글로벌 IT 사업자들이 흔히 사용하는 비용 산정 모델이다.
3.1.3. 기술적 고려사항
가. 가상화(Virtualization) 기술
고객에게 필요한 IT 자원을 유연하게 제공하기 위해서는 실제 서비스 업체에 설치된 자원을 가상화 할 수 있는 기술이 필요하다. 서버의 경우 기종이나 모델에 관계없이 단순히 컴퓨팅 자원으로서 제공이 가능해야 한다.
스토리지의 경우 물리적 볼륨(volume) 등의 제한 요소를 극복한 가상 기술이 필요하다. 일단 IT 자원이 가상화 되면 사용자 관점의 유저인터페이스의 구현을 통하여 물리적으로 설치된 IT 자원이 고객의 필요에 따라 유연하게 배치 또는 제거될 수 있게 되어 사용량의 변화에 능동적으로 대처하며 자원의 효율성을
높일 수 있는 기초가 마련된다.
가상화에 대한 논의는 여전히 활발하지만 IT 관리자들과 개발자들은 단지 가상화 기술이 제공하는 모든 것에 대해 절반만큼 도달한 상태다. 가상화는 작업량 통합으로 인해 관리자들로 하여금 에너지 소비를 낮추고 사용하는
기계와 회사가 필요로 하는 서버의 수를 줄여 비용을 낮추게 하고 있다.
41
가상화 소프트웨어는 하나의 운영체제와 하나의 애플리케이션 운영을 위해
디자인된 x86 컴퓨터 하드웨어의 제한을 탈피할 수 있게 해 준다. 가상화는 같은 컴퓨터에서 동시에 다중 운영체제와 애플리케이션을 구동시키는 것을
가능케 한다.
나. 자동화(Automation) 기술
가상화된 다양한 IT 자원을 효율적으로 관리하고 비용절감을 실현하기 위해서는 자동화된 운영관리 시스템의 구현이 필수이다. 단순한 시스템 모니터링부터 패치 적용, 문제 관리 등 정형화될 수 있는 모든 업무가 자동화될 필요가 있다.
자동화 관리의 실현을 위해서는 시스템 용도와 스펙별 표준 수립과 수립된
표준의 엄격한 준수가 중요하다. 시스템 표준화는 자동화 기술 부분 이외에도 앞에서 언급된 가상화 기술의 실현에도 중요한 요소이다.
시장에 나와 있는 대부분의 SMS(System Management Software)들도 표준화가 이루어지면 운영 부분의 많은 업무가 자동화될 수 있는 기능들을
갖추고 있다. 일단 시스템 운영의 자동화가 실현되면 운영 비용이 현격히 감소할 수 있을 뿐만 아니라 상황에 대한 응대나 작업처리의 정확도도 향상될 수 있어
서비스 수준을 높이는 효과도 기대할 수 있다.
이처럼 표준화를 통한 자동화는 너무도 당연히 추구해야 하는 과제이나 서로
다른 경영환경과 IT 자원을 보유하고 있는 다수의 고객을 대상으로 서비스를 제공해야 하는 IT서비스 업체의 측면에서는 사실상 추진하기 매우 힘든 것도
42
사실이다.
다. 측정(Measurement) 및 과금(Billing) 기술
사용량 기반 IT서비스를 이용하는 다수의 고객은 자신들이 쓰고 있는 IT 자원에 대한 공신력 있는 사용 내역서를 요구하게 되며 과금은 그러한 내역서에
바탕 되게 된다. 특히 많은 고객들이 내부 charge-back 시스템을 통하여 부서간 비용 정산을 하게 되므로 실제로 누가 얼마만큼의 IT 자원을 사용하였는지 명확하게 보여줄 수 있는 투명한 과금 기술 확보는 매우 중요하다.
측정 기술도 사용량 기반 IT서비스의 구현 정도에 따라 구축이 어려울 수도 있다. 간단한 예로 다수의 고객 애플리케이션이 하나의 Unix 서버에서 가동된다고 할 때 각 애플리케이션이 쓰는 CPU 사용량의 합은 항상 100%에 미달되게 되며 사용량 기반 IT서비스 자체 기능의 유지를 위해서도 CPU 자원을 소비되게 되는데, 이들 자원을 각 애플리케이션에게 배분할 것인지 등의 결정은 기술적인 측면과 거리가 멀 수도 있다.
특히 IT 자원 중 메모리 같은 부품들은 사용량(혹은 점유량)을 측정하기 매우 힘들기 때문에 측정의 대상에 포함시킬 수 없는 분야도 있다. 이런 경우에는 사용량보다는 투입되는 자원의 양이 과금의 기초가 되어야 한다.
3.1.4 보안적 고려사항
사용량 기반의 IT서비스는 자원을 소유하지 않고 IT서비스를 받는 형태로 인해 보안문제가 필수적으로 제기될 수 밖에 없으며, IDC에서 IT 관리자를 대상으로 설문조사(2008년)한 결과에서도 보안문제가 해결해야 할 최우선
43
과제로 뽑힌 상황이다.
[그림 3-2] Utility 환경에서의 이슈사항
사용량 기반의 IT서비스는 기존 IT 기술의 연장선상에 있는 것으로, 보안도 기존 보안 요소별로 구분하여 적용할 수 있다. 사용량 기반의 IT서비스를 받는 고객은 IT 자산을 유틸리티 형태로 제공 받지만, 자신의 데이터가 타인과 공유되기를 원하지 않으며, 특히 기업 사용자 입장에서 우려하는 보안 문제는 다음과 같다.
서비스 중단
기업정보 훼손
기업정보 유출
고객정보 유출
44
법/규제 준수 e-Discovery 대응
고객의 우려사항은 “기술적 측면”과 “관리적 측면”으로 나눌 수 있는데, 비용 투자를 통해서 해결할 수 있는 기술적 측면 보다는 내부 인력을 통한 정보자산
누출이라는 관리적 측면에 더 큰 우려를 나타낸다.
[그림 3-3] 기업 내부정보 유출 현황(2007년 국정원)
고객 우려사항을 보안의 관리적 측면에서 보면 다음과 같다.
고객 우려 사항 보안 이슈서비스 업체 인력에 의한 기밀정보 유출 운영인력 보안관리아웃소싱 시 보안관련 조직의 운영 보안조직 운영관리서비스 업체가 경쟁업체에 정보 유출 서비스 업체 불신보안조직 및 데이터에 대한 통제권 상실 보안통제권 상실보안사고 발생시 책임 소재 불분명 보안업무 책임소재
검증된 정보보안 관리 체계(보안조직, 인력보안, 보안감사 및 보안교육)에 의한 보안성 강화와 고객사의 통제권 강화를 통해 고객의 보안 우려사항을
45
해소하고, 정보보안 관리 체계 적용을 통해 업무 및 시스템 관련 보안사고 책임소재 및 피해보상에 대하여 법적 근거가 되는 문서로 작성하여 서비스
업체에 대한 불신을 해소하여야 한다.
보안이슈 대응전략 대응방안운영인력 보안관리 보안조직 보안관리와 보안기술의 분리보안조직 운영관리 인력보안 고객이 관리할수있는 보안조직구성서비스 업체 불신 신뢰성제고 보안사고시 피해보상 규정보안 통제권 상실 보안교육 프로세스 운영 및 정기적 교육보안업무 책임소재 보안진단 사고시 책임 소재의 기준 수립
3.2 사용량 기반 IT서비스 적용 전략
3.2.1 서비스 수준(Leveling) 관리
46
가. 서비스 수준 관리의 필요성
많은 기업들은 정보기술을 기업의 경쟁우위 확보를 위한 핵심수단으로
인식하여 정보기술 영역에 대한 투자 및 비용 지출을 지속적으로 증가시켜 왔다. 그러나, 투자 또는 지출비용 대비 효과에 대하여 부정적인 견해를 보이고 있으며, 투자비용 대비 높은 효과를 얻지 못한 이유에 대해 의문을 가지고 있다. 이와 같은 상황을 극복하기 위하여 IT투자 및 비용 대비 효과를 높일 수 있는 방안으로 보다 경쟁력 있는 서비스를 제공받을 수 있는 체계를 확보하는 것이
중요한 이슈로 부각되었다.
사용량 기반 IT서비스는 정보기술 자원을 고객이 필요로 하는 방식으로 원하는 만큼 제공하는 서비스이다. 따라서, 사용자 입장에서는 제공되는 서비스에 대한 요구사항을 체계적으로 정의한 서비스 수준협약(SLA : Service Level Agreement)이 반드시 필요하다.
SLA는 정보기술 서비스 수준의 정량적 측정을 통해 서비스 운영성과를 평가/관리하기 위하여 서비스 제공자와 사용자가 요구되는 서비스 수준을 정의하고
이를 문서화한 계약체계이며, 서비스 수준을 관리하기 위한 계획의 수립부터 서비스 수준의 합의, 운영 프로세스에 대한 모니터링, 리뷰 및 개선 과정을 포함하는 반복적 관리체계가 필요하다.
서비스 제공자와 사용자의 관점에서뿐만 아니라 서비스를 사용하는 고객
내에서도 정보기술 부서와 현업 부서간에도 이와 유사한 형태의 서비스 수준을
정의하고 모니터링을 실시하는 합의(OLA : Object Level Agreement) 를 체결하고, 궁극적으로 IT비용 절감 및 운영의 효율성 향상을 위한 활동을
47
지속적으로 전개해 나가는 것이 필요하다.
나. 서비스 수준 관리를 위한 필요 요소
SLA의 구성요소는 영역별 서비스 수준 관리 지표, 서비스 수준 관리 지표별 목표 수준, 서비스 수준 측정 기준, 서비스 수준에 대한 보고 체계 등이 포함된다.
구성요소 내 용
서비스 수준 관리 지표
(Service Level Metrics)
서비스 제공 영역별 서비스 수준을 정량적으로 파악하기 위한 성과지표
서비스 목표 수준(Service Level
Objectives)
서비스 수준관리 지표별 목표치 및 최소치 (일반적으로 최소치 미달 시 패널티 부과, 목표치 초과 달성 시 인센티브 부여)
서비스 성과 측정 기준
(Service Level Measurements)
정의된 서비스 수준 관리지표를 정량적으로 측정하기 위한 방법 (측정 구간 및 주체, 주기 등을 포함)
서비스 수준 보고(Service Level
Reports)서비스 수준에 대한 의사소통 체계로써의 보고 형식 및 보고방법
또한 제공되는 서비스 수준에 따라 서비스 비용을 차별화하고 서비스 수준의
향상을 촉진하기 위한 자극제로 패널티(Penalty)와 보상(Incentive)을 적용하는 것이 바람직한 형태라 할 수 있으며, 이를 위해서는 사용자와 서비스 제공 조직간 상호 협의에 의해 비즈니스 중요도를 고려해 적용 대상을 선정하고
패널티와 보상에 관한 상한선을 설정할 필요가 있다. 다. 서비스 수준 관리를 위한 고려 사항
48
기존의 정보기술 서비스 수준에 대한 평가는 계약 당시 합의된 서비스가
제대로 제공되었는가의 관점보다는 얼마나 많은 서비스 항목들이 제공 되었는가, 서비스를 위해 투입된 인력들이 사용자의 기대에 얼마나 부응 하였는가를 판단하는 형태로 수행되어 왔다. 즉, 외적 요인에 중점을 둔 서비스 수준 관리 방식이었다.
또한, 일부 IT서비스 사용자 측에서 서비스 제공자를 통제하기 위한 수단으로 오해하는 경우가 있다. 계약 시 SLA를 개발하고 여기에 제시된 서비스 항목을 계량화하여 측정한다면 서비스 제공자를 원하는 대로 통제할 수 있다고
판단하는 경우인데, 이는 올바른 판단이 아니다. SLA에 명시된 측정 대상만으로 서비스 수준을 보장받고 서비스 개선을 지속적으로 기대하기는 쉬운
일이 아니다. SLA는 서비스 제공자 관리를 위한 보조수단이며, 지속적인 서비스 개선을 위한 시발점으로 인식해야 한다는 것이다.
SLA에 관한 또 다른 인식의 오류는 SLA의 핵심이 서비스 항목에 대한 측정과 보고라는 생각이다. 정보기술 업무는 속성상 문제의 원인을 정확히 파악하기 어려울 때가 많으며, 예상하지 못한 경우가 빈번히 발생한다. 이런 모든 문제를 단순히 측정 및 보고를 통해 해결하고자 기대하는 것은 바람직하지
못하다.
SLA의 핵심은 사용자와 서비스 제공자가 서비스 수준을 계속 향상하기 위해 무엇을 개선해야 하는지 파악하고, 이를 어떻게 수행할 것인지 협상하고자 하는 의지이다. 측정 결과만을 놓고 측정된 수치가 뜻하는 바가 무엇인지, 측정 수치에서 파악된 문제의 본질이 무엇인지를 파악하고자 하는 것부터 출발해
실질적으로 개선되기까지 프로세스를 정립하고 이를 사용자와 서비스 조직의
49
구성원들과 공유해 준수하도록 하는 게 필요하다.
측정 항목을 정하고, 어떻게 측정할 것이며, 어느 수준에서 목표치를 결정할 것인가 하는 것은 서로 협상을 통해 도출해야 한다.
3.2.2 서비스 정책 수립
가. 서비스 수준 관리(SLM : Service Level Management)
SLM은 정보기술 서비스 수준을 관리하기 위한 계획의 수립부터 서비스 수준의 합의, 운영 프로세스에 대한 모니터링, 리뷰 및 개선 과정을 포함하는 반복 관리 체계이다. SLM을 사용자의 기대 수준에 부합하는 서비스를 제공하기 위해 요구되는 서비스, 프로세스, 조직구성, 운영인력의 역량 및 기술력을 통합해서 관리하기 위한 체계로 활용해야 한다는 것이다.
나. SLA 추진방법 및 단계
SLA 개발 시 가장 먼저 수행되어야 하는 작업은 정보기술 서비스 제공자가 사용자에게 제공하는 서비스의 내용 및 범위를 명확하게 정의하는 것이다. 이를 위해 서비스 제공자는 고객에게 제공할 서비스의 내용 및 범위를 명확하게
기술한 서비스 내역서(SOW : Statement Of Works)를 정의 작성해야 한다.
정보기술 서비스 내역을 명확하게 정의한 후에는 서비스 영역별로 서비스
수준 관리지표를 도출하고, 각 관리지표에 대한 측정방법 및 전제사항 등을 정의하여 서비스 목표수준을 설정한다.
50
서비스 수준 관리지표별 목표수준 설정 이후에는 목표수준의 초과달성 및
미달성 시 서비스의 지속적 향상을 위한 관리 수단으로서 패널티와 인센티브
기준을 설정할 수 있다. 패널티와 인센티브의 적용은 SLA 적용 시 필수적으로 요구되는 사항은 아니지만, 서비스 제공자 및 사용자 양자 간의 서비스 수준 현황 및 실적에 대한 검토 및 분석의 활성화와 서비스 수준의 지속적 개선을
위해 권장되는 사항이다.
다. 서비스 범위와 내용
서비스 카탈로그를 통한 범위 및 내용을 다음과 같이 정의할 수 있다.
서비스 범위 및 내용
- 서비스 개요 - 사용자 및 IT서비스 제공자의 의무 - 세부적인 서비스 범위 및 내역 - 서비스 환경(H/W, S/W, 설비, 인력, 사업장, 정책, 절차 등)
서비스 수준 합의 내용
- 서비스 수준 관리지표의 정의 - 서비스 수준 관리지표의 계산 공식 - 서비스 제공 시간 - 서비스 수준 관리지표의 측정 방법 - 서비스 수준 관리지표별 서비스 수준 정의 - 전제사항
패널티 및 인센티브 규정
51
- 서비스 수준 평가 기준 - 서비스 수준 평가 방법 - 패널티 부과 및 금액 기준 - 인센티브 지급 및 금액 기준 - 패널티/인센티브 정산 방법
라. 패널티와 인센티브의 차이
서비스 수준 향상을 위한 필요 방안(필수는 아님) 패널티는 서비스 최소 수준을 달성하지 못했을 경우 서비스 제공자가
사용자에게 지급하는 금액 또는 서비스 수준 향상을 위해 별도의 자원을
투입하는 서비스 개선 활동을 지칭함
인센티브는 합의된 서비스 목표 수준을 초과 달성한 경우에 사용자가
서비스 제공자에게 제공하는 금전적 또는 비금전적인 보상을 지칭함
패널티 및 인센티브 기준을 설정하는 단계
- IT서비스 제공자와 사용자가 공동으로 적용사례 조사, 공유 및 분석 - 해당 조직에 적합한 패널티 및 인센티브의 형태, 최대 적용률, 적용 방식 등에 대한 방안 수립
- 양자간 검토 및 합의를 거쳐 패널티 및 인센티브 규정을 설정 IT서비스 품질을 지속적으로 개선하고 향상시키기 위한 관리
수단으로서 인식되어야 함 패널티가 사용자에게 있어서 서비스 비용을 줄이기 위한 강제적
수단이나 인센티브가 서비스 제공자에게 부가적인 수익을 추구하는
수단이 되어서는 안됨
지속적인 IT서비스 수준 향상을 위해서는 합의된 패널티 및 인센티브
52
프로그램은 예외 없이 적용되어야 하며, 사용자와 제공자는 아래 사항을 준수하여야 함
<사용자> - 패널티 프로그램을 현명하게 활용한다. 합의된 서비스 최소 수준 미달이 발생하면 패널티 부과부터 먼저 생각하지 말고, 서비스 제공자와 함께 서비스 기본 수준을 지속적으로 유지할 수 있도록 발생된 문제에 대한
조치 상황을 확인한 후 패널티를 부과하도록 한다.- 서비스 제공자와의 관계를 해치지 않는 범위 내에서 바람직한 활동을 유발시킬 수 있도록 적절한 패널티 부과 수준을 정의한다.
<제공자> - 합리적인 패널티를 수용한다.- 이윤을 초과하고 서비스 수준 달성 및 초과 달성이 불가능하도록 설정된 패널티 프로그램은 거부한다.
SLA 적용 시 패널티와 인센티브를 적절히 활용한다면 서비스 제공자와 사용자간의 관계가 동반자적 견지에서 긍정적으로 발전되어
갈 수 있지만, 부적절하게 활용될 경우 금전적인 손실과 함께 상호간 신뢰 저하로 IT서비스 수준 자체가 심각하게 영향 받을 수 있다는 것을 염두에 두어야 한다.
마. 적용 기대효과와 발전 방향
SLA의 지속적인 관리를 통한 서비스 수준의 개선이 포인트임 IT서비스 사용자는 SLR(Service Level Requirements)을 구체적으로
53
주고 받아 정량적 파악이 가능하고 서비스 수준 향상을 위한 명확한 관리
포인트를 확보할 수 있음
IT서비스 제공자는 명확한 서비스 요청서를 확보하여 운영 인력들간의업무 역할 분담 및 운영 활동에 대한 정량적 측정을 통해 합의된 우선
순위에 따라 서비스를 개선함으로써 고객 만족도를 극대화 시킬 수 있음
서비스 제공자와 사용자간의 명확한 관리 포인트 확보, 사전 예방활동강화, 상호간의 동반자적 관계의 인식 등을 지속적으로 향상시켜 나가야 함
사용량 기반 IT서비스 체계와 기존 ITO 체계의 차이점 - 사용량 기반 IT서비스는 단독 사용에 의한 장비의 도입, 운영, 폐기의 라이프사이클을 가진 기존 ITO 체계 대비 공용 사용에 의한 서비스 평가 체계임
- 사용자와 제공자간의 명확한 서비스 수준에 대한 정의, 측정, 평가가 중요함
- 자원의 딜리버리, 할당, 운영, 해지에 따른 프로세스 단계별로 차별화된 서비스 측정 지수의 개발 및 측정이 서비스 수준 만족도 향상의
포인트임
54
3.3 사용량 기반 IT서비스 아키텍처 구현
3.3.1 서비스 수준별 아키텍처
IT자원을 사용량에 따른 서비스로 제공 시 서비스 수준은 제공 방식에 차별화되어 결정되어야 하며, 즉 제공방식에 따른 아키텍처를 선정하고 이에 따른 수준별 아키텍처 선정이 필요하다. 이는 서비스 사용자와 제공자간의 합의를 통하여 결정한다.
단, 서비스 수준은 서비스 비용과 밀접한 관련성이 있으므로 비즈니스 중요도에 따라서 가장 비용 최적화된 서비스 수준으로 사용량 기반 IT서비스가 제공되고 운영되어야 한다.
가. 제공 방식에 따른 아키텍처 분류
IT인프라를 서비스로 제공 시 제공 방식에 따라 구성 아키텍처를 크게 두 가지로 분류할 수 있다. 첫째가 독점방식(Dedicated)과 공유방식 (Shared)이며, 두 번째가 On-Site 방식과 Off-Site 방식이다.
55
각각은 사용자의 특성에 따라 비용 효과적인 아키텍처를 선택하면 된다. 아래에 각각의 특성에 대하여 간략히 정리하여 사용자의 이해를 돕고자 한다. 서비스 제공자의 사용량 기반 IT서비스가 특정 방식일 경우 해당 방식의 고려사항의 검토가 필요하다.
[표 3-1] 제공 방식별 아키텍처 분류표
구분 제공방식 특징 고려사항
점유방식
Dedicated
IT자원을 단일 사용자가 독점적으로 사용하는 방식 상대적인 고비용 보안 및 컴플라이언스 이슈가 없음
IFRS 등 컴플라이언스 고려 (Lease로 인식되어 부채로 잡힐 수 있음)
Shared 자원을 사용자간 공유 하여 사용 비용 절감 가능 가상화 기술 필요
보안가용성
위치
On-site
사용자 소유의 Facility에 IT자원을 위치시켜 사용량 기반의 서비스 Dedicated 방식 위주 상대적 고비용
자원 활용률Facility 품질
Off-Site
일반 IDC 또는 제공자의 데이터센터에 IT자원을 위치시키고 N/W을 통하여 서비스하는 방식 Shared 서비스 가능 상대적 저비용
보안컴플라이언스네트워크 비용
나. 서비스 수준별 아키텍처
56
제공 방식에 따른 아키텍처에 따라 일부 차별화될 수 있지만 일반적으로
서비스 수준은 비즈니스 중요도에 따라 크게 3등급으로 구분하며 각 등급별 필수 아키텍처 정의를 통하여 자원투입과 서비스 수준의 연계가 필요하다.
[표 3-2] 서비스 수준 정의
구분 수준 1 수준 2 수준 3
Description
가용성, 성능에 민감하지 않은 시스템Ex) 개발/테스트시스템
사내 기간 시스템 등 영향도가 내부적으로 한정된 시스템Ex) 메일, 파일 서버, 웹서버
매출, 고객과 직접 연계된 Mission Critical 시스템Ex) ERP, CRM/ SCM, EDW 등
서버아키텍처
가상화Blade Server
선택적 가상화Mid-Range서버
HA 필수DR구축 필요비상 시 대비Manual Process
스토리지아키텍처 None
Mid-Range- Raid : R5- De-Dup- Thin Provisioning
High-End - Raid : 10 - BCV
백업아키텍처
특별한 수준 요구사항 없음
Tape백업시스템별 RTO, RPO 설정
Tape 백업, 볼륨복제,서비스에 따라 RTO 및 RPO 설정,주기적인 복구 테스트 필요백업 Tape 소산 필요
보안아키텍처
특별한 수준 요구사항 없음
데이터센터 물리적 보안, 관리적/절차적 보안 요구
L2를 포함한 데이터 암호화, Anti-virus 등 솔루션 요구, 정기적인 Audit 기능
공통 전원/네트워크 이중화
57
서비스 수준별 요구 수준은 핵심성과지표(KPI : Key Performance Indicator)를 통하여 운영된다.
3.3.2 사용량 기반의 IT서비스 아키텍처 선정 절차
사용량 기반의 IT서비스 활용을 위한 서비스 수준별 아키텍처 선정 절차는 다음과 같다.
① 비즈니스 요구사항을 분석하고 명세화 한다.② 필요 IT자원에 대한 Capacity Planning을 실시한다.③ 서비스 가용성 및 응답시간, RTO(Recover Time Objectives) 등 Quality
Planning하고 정의한다.④ 필요 시 벤치마킹을 실시하고, Reference를 확인한다⑤ 제공방식에 따른 아키텍처를 결정하고 계획된 Capacity 및 Quality에 따라 서비스 수준을 결정하고 이에 맞는 수준별 아키텍처를 결정한다. 또한 IT서비스 제공자의 서비스를 비교한다.
⑥ TCO (Total Cost of Ownership) 비교 및 전략적 측면까지 고려하여 서비스 제공자를 선정한다.
가. 비즈니스 요구사항 분석
ISP, BPR 및 EA 컨설팅 등을 통하여 정보시스템 전략 수립, AS-IS 정보시스템 환경, TO-BE아키텍처 및 세부 과제 도출을 통하여 요구사항에 대한 명세화를 실시한다. 이를 기반으로 IT서비스 업체의 사용량 기반의 IT서비스 사용 여부에 대한 결정이 필요하다.
58
비즈니스 요구사항 분석을 위하여 필요한 필수 수행 내역을 아래 내용을
참조하여 각 조직에 맞게 수정하여 사용할 수 있다.
- 조직 내외부 경영환경 분석- 정보시스템 환경 및 데이터 환경 분석, 업무 프로세스 분석- 내부 및 외부 사용자 분석, 사용자 인터페이스 분석- 정부 Regulation 등 IT Compliance 분석- 비즈니스 계획 및 시장 예측
나. Capacity Planning
비즈니스 요구사항 분석을 통하여 이를 지원할 IT시스템에 대한 Baseline 용량계획을 수립하고, 장단기 용량예측을 수행한다. 주요 수행 내역은 아래 내용을 참조하여 각 조직 환경에 맞게 수정하여 사용할 수 있다.
- 시스템별 요구 트랜잭션 및 데이터량을 산정을 통하여 Baseline Capacity를 정의한다.
- 시스템 중요도를 기초로 이중화 및 다중화를 정의하여 Baseline Capacity를 보정한다.
- 애플리케이션의 종류 및 사용자 환경을 고려한 보정을 실시한다.- 데이터의 중요도에 따라 스토리지 Raid를 결정하고 백업 정책을 결정한다.- Network Bandwidth 및 Security Level을 설계한다.- 서버, 스토리지/백업, 네트워크에 대한 업체 및 제품을 선정한다.
다. Quality Planning
59
비즈니스 요구사항 분석 및 Capacity Planning을 Input으로 활용하여 적정한 수준의 시스템 가용성, 응답속도 등의 품질계획을 수립한다. 주요 수행 내역은 아래 내용을 참조하여 각 조직 환경에 맞게 수정하여 사용할 수 있다.
- 비즈니스 연속성 측면에서 핵심 시스템을 분류하고 RTO를 정의한다.- RTO에 기반하여 이중화 계획을 수립한다.- 이중화를 고려하여 필요한 전체 시스템을 List-up한다.- 정리된 전체 시스템에 대한 응답시간, 허용 Down Time, 실질 가동률 등 요구 수준을 명세화 한다.
- 필요 시 Local DR(Disaster Recovery) 또는 Remote DR을 구성한다.- Test Planning을 수립하고 명세화 한다.- 정의되고 합의된 모든 사항을 ‘사용량 기반의 IT서비스 수준 합의서’에 기술한다.
라. 서비스 수준(SLA) 결정
Quality Plan에 따라 시스템별 서비스 수준을 결정하고 해당 수준의 세부 KPI를 활용하여 목표 값을 설정하여 관리한다. 서비스 수준의 세부 KPI 선정 및 목표 수준은 제공 방식에 따른 아키텍처에 따라 달라질 수 있으며, 서비스 사용자와 제공자간의 합의 과정을 통하여 최종 결정한다.
[표 3-3] 시스템별 서비스 수준 및 KPI 사례
구분 수준 1 수준 2 수준 3주요 대상 Develop/Test Commodity Mission Critical
60
Availability 95% < < 99.5% 99.995% <Agility 1 Month 1 Month 1 Week응답시간백업 성공률 90% 95% 99%이중화 테스트 N/A 년 1회 분기 1회
마. 서비스 업체(제공자) 선정
IT시스템 구축 시 IT인프라를 자체 구축하지 않고 외부 서비스 제공자로부터 ‘사용량 기반의 IT서비스’ 를 도입하는 경우 자체 구축 시와 다른 부분들에 대한 검토 및 확인이 필요하다.
- 장기 계약에 따른 경영 건전성 체크가 필요하다.- 보안에 대한 Risk요인을 상세히 분석한다.- Off-site 서비스 이용 시 Data Center의 위치를 네트워크, 접근성, 자연환경 등 다양한 측면에서 검토가 필요하다.
- Total Outsourcing Partner로서 전략적 고려가 필요하다.
서비스 제공자 선정 시 아래 내용을 참조하여 사용자 조직 환경에 따라
수정하여 사용할 수 있다.
- 사용자 조직 내부적인 사전 Case Study를 진행한다.- 후보 사업자를 선정하고 ‘사용량 기반 IT서비스’ 제안을 위한 RFP를 작성 배포한다.
- RFP작성 시 기술표준, 보안 요구사항, 제공방식, 비즈니스 연속성 계획 등 사용자 조직의 전사적 아키텍처를 고려하여 관련 내용을 반영한다.
- 가능하다면 사용량 기반 IT서비스 사용 조직을 방문하여 효과 및 이슈
61
정보를 수집한다.- 제안서를 접수, 평가하여 우선협상 대상자를 선정하고 비용 협상을 통하여 최종 서비스 제공자를 선정한다.
3.3.3 세부 아키텍처 수립
비즈니스 중요도에 따른 차별화된 아키텍처 적용을 위하여 서버, 스토리지, 보안 등 아키텍처 주요 구성항목별 세부 아키텍처 정의가 필요하다.
[그림 3-4] 사용량 기반 IT서비스 아키텍처 분류
특히 이러한 세부 아키텍처는 IT자원을 서비스로 제공 받을 시 운영상의 문제 발생 시에 이슈의 원인이 되므로 세심한 검토가 필요하며, 반드시 문서화하여 기록으로 남겨야 한다. 따라서 계약서의 세부 조항으로 첨부하는 것이 최적의 방안이다.
치
Resource Layer
Delivery Layer
Business Layer
서버 아키텍처
보안 아키텍처
스토리지 아키텍처
SAN,DAS,NAS 인터페이스로 가상화된 스토리지 제공
서비스 수준에 따라 Server Resource Pool을 구성
시스템 측면, 데이터 측면, 네트워크 측면의 보안아키텍처 구성
62
가. 서버 아키텍처
사용량 기반의 IT서비스에서는 아래의 아키텍처들이 가장 일반적인 서버 아키텍처라 할 수 있다. 다만, 요구사항 또는 Capacity Planning의 내용에 따라 선별적으로 선택하고 수정 보완하여 사용할 수 있다.
① Partitioning / 가상화
가장 일반적인 사용량 기반의 IT서비스 인프라 아키텍처로 물리적 단일 H/W에 파티션 기술 및 가상화 엔진을 활용하여 다수의 Guest OS를 운영하는 기술이다.
이 방식은 유휴 Resource를 최소화하여 활용도(utilization)를 최적화할 수 있고 서버 H/W 자원을 공유하여 비용을 절감할 수 있다. 하지만, 장애 시 파급효과가 크고 신속한 원인 분석이 상대적으로 어려워 확실한 관리체계가
선결되어야 한다.
63
② Shared OS
Shared OS 아키텍처는 물리적 통합 방식으로 하나의 운영체제(OS)에 여러 애플리케이션 인스턴스를 올리는 방식이다. 유사한 방식으로 애플리케이션 통합 방식이 있으며, 하나의 운영체제 위에 하나의 인스턴스로 애플리케이션을 통합하는 방식이다.
사용량 기반 IT서비스 도입 시 AS-IS IT아키텍처를 기능성, 보안성, 효율성, IT비용 최적화하는 방향으로 애플리케이션 통합, 또는 인스턴스 분리 등 TO-BE 아키텍처 수립이 필요하다.
③ Blade Server
최근 가장 활성화되고 있는 방식이 Blade Server를 활용한 Scale-out 방식이다. 기존 C/S환경에서 인터넷 기반으로 진화하면서 요구가 확대되고 있는 아키텍처이다.
하지만 Green IT를 고려한 아키텍처 선정 시 단위 면적당 전원사용량,
64
발열량 등의 이슈로 그 활용 장점에 비해 도입이 더디고 있다.
최근 데이터센터가 최대 전력량의 한계로 공간의 여유가 있어도 더 이상 서버/스토리지 수용이 어려운 경우가 많은데 가장 큰 원인이 Blade Server와 고성능 Windows 서버 때문이다.
아키텍처 선정 시 TCO측면에서 비교할 경우 아직까지 Blade Server 아키텍처가 상대적으로 불리한 경우가 많지만 최근의 Green IT기술 발달에 따라 머지않아 핵심 아키텍처로 부상할 것으로 예상된다.
④ Stand Alone
하나의 H/W에 하나의 OS 및 하나의 업무를 구성하는 방식으로 초기에는 기술적 한계로 인하여 소용량 서버 등에서 주로 사용되었지만, 최근 Global ERP 등 대규모 업무 시스템의 대용량 성능 요구로 Mission-Critical 시스템에서 주로 사용되는 아키텍처이다. 다만, 멀티 노드(Multi-Node) 또는 다중화로 Multi Stand Alone 방식이 주로 사용된다.
65
나. 스토리지 아키텍처
사용량 기반의 IT서비스를 위하여 가상화, 중복제거(De-duplication), Thin Provisioning 등의 기술을 이용한 스토리지가 일반화 되고 있다. 또한 Disk 가격의 인하로 VTL, 중복제거 기술 등으로 기존 Tape장비의 문제점을 극복하기 위하여 스토리지 활용이 많아지고 있다. IT인프라에 대한 사용량 기반의 IT서비스 중 스토리지 종량제 서비스가 가장 먼저 서비스 되어 많은 기업에서 서비스를 제공하고 있으며, 사용자 측면에서도 가장 친숙한 분야라고 할 수 있다.
조직의 주요 데이터의 안정적인 저장을 위하여 스토리지에 대한 사용량
기반의 IT서비스 도입 시(서버를 포함한 Total 도입, 또는 스토리지 혹은 백업에 대해서만 사용량 기반 IT서비스를 도입할 수도 있음) 서비스 사용자는 데이터의 가용성뿐만 아니라 산업별 컴플라이언스, 데이터 보안 등을 고려하여 검토하여야 한다.
스토리지 아키텍처는 인터페이스에 따라 크게 SAN(Storage Area Network), DAS(Direct Attached Storage), NAS(Network Attached
66
Storage)로 구분되며, 일반적으로 서비스 중요도에 따라 High-End, Mid-Range, Low-End의 3등급 표준 스토리지 아키텍처로 차등화하여 제공된다. 서비스 제공 업체별로 차이가 있겠지만 서비스 사용자의 측면에서 차등화된
등급별 스토리지 아키텍처의 선정을 위하여 고려해야 할 특징은 다음과 같다.
[표 3-4] 스토리지 등급 사례등 급 Low-End Mid-Range High-End
Description단순 저장용, 조회용, 백업용 데이터,
상대적으로 중요도가 낮은 DB서버용 데이터
고성능, 고용량의 Mission Critical시스템 데이터
인터페이스아키텍처 NAS SAN, iSCSI, NAS SAN, DAS이중화 수준 전원 전원, 채널 Full 이중화권고 Raid Raid5 Raid5 Raid1
Raid 1+0권고 Cache N/A 16GB, 32GB TB당 2GB
주요 대상테스트/개발 시스템, 백업 서버, 파일서버
메일, Web, WAS, Portal시스템 ERP, CRM, DW 등
NAS의 경우 스토리지 구성을 위한 Network Switch 구매 및 Space 증가로 인하여 최근 i-SCSI 인터페이스 사용이 증가하고 있다.
스토리지 아키텍처에서 등급별 백업 정책도 다르게 적용되며 데이터의 중요도
측면에서 Tape백업, Disk백업, 기타 디바이스를 이용한 백업뿐만 아니라 재해복구(DR) 정책 수립도 필요하다. 일반적으로 아래의 백업 정책 및 프로세스가 필요하며, 서비스 중요도에 따라 차별화하여 적용한다.
- 백업 정책 : 백업 대상, 백업주기, 보관주기, 백업 미디어, 소산정책, RTO, RPO
67
- 백업 프로세스 : 백업 및 복구에 필요한 요청, 승인 프로세스- 기타 문서 : 백업 절차서, 백업 매뉴얼, 시스템별 복구 절차서, CSR 양식, 미디어 관리 대장
다. 보안 아키텍처
사용량 기반 IT서비스 도입 시 사용자 측면에서 가장 핵심적인 고려사항 중 하나가 보안이라고 할 수 있다. 따라서 사용자는 서비스 제공자가 제공하는 서비스를 구성하는 보안 정책, 프로세스 등에 대하여 상세한 검토가 필요하다. 하지만 사용하는 서비스 분야에 적용되는 보안 기술 또한 서비스 사용료의 원가
구성요소이므로 비용 효과성 측면의 접근이 필요하다.
서비스 사용자가 반드시 확인해야 할 사용량 기반 IT서비스 제공자의 보안 영역은 다음과 같다.
- 물리적 보안 (IT 자산의 반출입 관리, 생체인식기술 및 ID카드 등 다중 출입보안, 보안감독, CCTV 등)
- 관리적 보안 (출입관리 관리 프로세스, 승인절차, 정기적인 Audit 등 보안관리 정책 및 절차 수립)
- 네트워크 보안 (보안관제 모니터링, 방화벽 및 IDS/IPS, UTM등 신기술 적용 여부 등)
- 논리적 보안 (스토리지 데이터 암호화, 로그관리 등 데이터 보안 측면)- 기타 (서비스 사용량 및 사용료 정보에 대한 유출 방지)
서비스 사용자 조직 내부의 보안 정책에 따라 상이한 IT보안 요구사항이 정의될 것이며, 이러한 사항을 서비스 제공자와 합의를 통하여 서비스 사용
68
계약서에 반영하여야 한다.
3.3.4 아키텍처 성숙도 모델
조직의 비즈니스 환경 및 요구사항에 따라 다를 수 있겠지만 일반적으로 IT H/W 인프라 수준에서 S/W 인프라, 애플리케이션 수준으로 단계적인 사용량 기반 IT서비스 도입을 권장하며, 다음에서 제시한 성숙도 모델은 이를 위한 참조모델로 활용할 수 있다.
사용량 기반 IT서비스 도입을 검토하는 조직은 다음의 성숙도 모델을 참조하여 자사 IT인프라가 어느 수준인지를 판단하여 업무 특성에 맞는 사용량 기반 IT서비스 모델을 도입하도록 한다.
[표 3-5] 사용량 기반 IT서비스의 IT인프라 성숙도 모델
IT 인프라성숙도기능구분
리소스분배최적화방법, 최적화빈도와자동화여부, 컨피규레이션설정방법, OS 또는 SW 설치자동화여부, 서비스표준화/카탈로그화정도, 사용자맞춤형서비스제공여부
단계
구분
Level 5Service Oriented
Infrastructure Level 4
Automated Infrastructure
Level 3Dynamic Infrastructure
Level 2Static Infrastructure
Level 1Dedicated
Infrastructure
서비스프로비저닝
인프라프로비저닝
인프라프로비저닝
자원할당최적화
자원할당최적화
자원할당최적화
가상자원
가상자원
가상자원
가상자원
Automated ServiceProvisioning
Static Virtualization
Automated Infra Provisioning
Dynamic Virtualization
No Virtualization
69
IT 인프라 성숙도 사용량 기반 IT서비스 선정
단계구분
Level 5:Service Oriented Infrastructure
IT인프라가 아닌 서비스, 업무 솔루션으로 서비스
사용자 수, 트래픽 건수 등의 비용 모델 매출과 비용이 연동될 수 있음
Level 4:Automated Infrastructure
인터넷 기반 자동화 프로세스 자동 할당/해지가 가능하며 사용량 변동에 따라 유연하게 변경이 가능한 계약 구조
Level 3:Dynamic Infrastructure
외부 데이터센터 등에 기 구축된 통합 IT인프라 기반의 공유서비스 사용
복수의 서비스 제공자 비교를 통한 선정 가능
Level 2:Static Infrastructure
조직 내 동적인 가상화 기술 적용으로 사용량에 따른 유연한 인프라 사용으로 변동 사용료 방식 도입
Level 1:Dedicated Infrastructure
가상화 기술을 적용한 물리적 통합 인프라 구성 월별 비용 변동이 적은 서비스 방식 도입
70
조직의 성숙도 수준이 낮은 상태에서 4, 5수준의 서비스를 요구할 경우 사용량 기반 IT서비스 도입의 목적을 달성하기 힘들며, 사용자와 제공자간의 신뢰관계만 훼손할 가능성이 크다. 모든 조직에서 상위 수준의 성숙도 도입이 효과적이지는 않으며, 비즈니스 요구와 업무 환경, 사용자 특성 등에 따라 적정한 수준이 다르다고 할 수 있다.
3.4 사용량 기반 IT서비스 운영
71
3.4.1 IT서비스 사용량 측정(Measurement)
IT자원에 대하여 사용량 기반 IT서비스 활용 시 매월 사용량을 측정하여 사용량에 따라 비용을 과금하는 프로세스가 추가된다. 따라서 사용자와 제공자간의 객관적이고 신뢰성 있는 방식으로 사용량이 측정되고 리포팅 되어야
한다.
사용량 측정을 위해서는 측정 단위, 기간, 리포트 방식 등에 대한 명확한 사전 정의가 필요하고 명세화하여 계약 시 반영되어야 한다. 사용량 측정 대상인 서버, 스토리지 등 IT인프라에 대하여 2장에서 정의한 Service Unit을 활용하여 사용자와 제공자간의 합의를 통하여 효율적인 기준 정의가 필요하다.
사용량 기반 IT서비스 운영 중 사용량 측정을 위해서는 다음의 기준(Base Line)을 정의하여야 한다.
① Service Unit : Server Service Unit(SSU), Disk Service Unit(DSU), Backup Service Unit(BSU)
② 비용 모델 : 약정제(기간 내 동일 요금), 변동 요금제(종량제)③ 사용량 측정 방식 : 성능정보 gathering을 통한 자동화 방식 및 도구④ 사용량 측정 주기 : 월 사용료 산정을 위한 사용량 측정 기간 및 주기⑤ 사용량 리포트 방식 : 웹 기반 또는 메일 등
사용량 측정을 위해서는 아래의 개념도 사례와 같은 Metering Server, Metering Agent, 데이터베이스 및 Billing System과의 인터페이스 등 기술적인 조건들이 필요하다.
72
[그림 3-5] 미터링/빌링 시스템 개념도
사용량을 측정하고 사용료에 대한 빌링 및 청구는 자동화된 프로세스가
필요하며 사용 현황에 대한 기록은 데이터베이스를 통한 관리가 필요하다. 이를 이용하여 추이분석, 변동성에 대한 추정 및 준비가 효율적으로 수행될 수 있다.
3.4.2 서비스 사용료 산정(Costing/Pricing)
사용자가 매달 사용한 IT자원에 대한 비용 산정은 사용 개시 이전에 합의를 통하여 계약된 서비스 단가와 실 사용량을 통하여 산정되며, 비용 모델에 따라 다르게 적용이 가능하다. 사용료 산정에 분쟁을 없애기 위해 측정 기간, 방식 및 대상에 대하여 명확한 합의 과정이 필요하다. 사용료 산정은 일반적으로 자동화된 시스템을 통하여 이루어져야 하며, 다음의 과정은 사용료 산정
……
Billin g
Met
erin
g
Metering Server (Master Server)
Billing Server
사용자 Dash-Board
Metering Agent(사용 Infra 자원)
73
프로세스에 반드시 포함되어야 한다.
① 월 사용량 측정 : 측정 단위는 선택한 비용모델에 따라 다를 수 있다.② 서비스 수준 측정 : 서비스 계약에 명시된 서비스 수준의 충족 수준을 측정한다.
③ 사용자(고객) 합의 : 해당 월 사용량 및 서비스 수준에 대한 이상 유무 확인, 비 정상적인 사용 패턴에 대한 원인 규명, 제공자의 서비스 수준에 대하여 합의한다.
④ 사용료 산정(Billing) : 고객과 합의된 사용량을 기초로 해당 월 사용료를 산정한다. 이때 서비스 수준 합의서에 기초하여 패널티/ 인센티브가 있을 시 사용료에서 계상한다.
⑤ 고객 합의가 완료 시 자동으로 Accounting 한다.
2장에 설명된 서버의 Core, tpmC 측정단위, 스토리지의 용량(GB) 및 기타 네트워크의 대역폭(Bandwidth) 등 사용량 기반 IT서비스 측정 단위는 사용자의 환경, 대상 서비스, 비용 등을 고려한 적정한 선택이 중요하다.
3.4.3 Accounting 및 Charge-Back
가. 어카운팅(Accounting)
어카운팅 프로세스는 Billing 프로세스와 동일하게 적용되는 것이 효과적이지만, 빌링의 경우 기본적으로 월 사용량에 대한 발생 비용이 중요하며 실 청구 사용료는 서비스 수준 및 기타 다른 이유로 어카운팅 시에 조정이 될 수
있다.
74
따라서 패널티/인센티브 등은 어카운팅 프로세스로 정의할 수도 있다. 비용 청구 후 대금 지급 등은 해당 사용자의 회계 정책에 따르는 것이 일반적이며
이러한 사항에 대하여 계약 시 상호 확인하고 합의가 필요하다.
나. Charge-Back
사용자의 내부 재무 정책에 따라 사용료에 대한 사용자 내부 서비스 또는
조직에 대한 원가 귀속이 필요한 경우 실 사용 서비스 및 조직에 사용량에 따라
비용을 배부할 필요가 있다. 이것이 일회성 투자가 아닌 서비스를 사용하는 근본 취지에 부합된다고 보이며, 조직 차원의 낭비를 줄이고 책임성 부여를 통한 비용절감의 동인이 될 수 있다.
Charge-Back 방식에 따라 서비스 제공자의 Accounting 프로세스와 인터페이스가 가능할 수 있으며, 이 또한 불필요한 중복 프로세스로 인한 낭비를 제거하는 방식이 될 수 있다.
3.4.4 서비스 수준의 측정(SLA) 및 평가
사용량 기반 IT서비스를 사용 시 서비스 제공자는 사용자의 요구 수준 충족을 위한 IT Infra를 투입하고 서비스 수준을 측정하고 평가하는데 가장 효과적인 KPI선정을 통하여 서비스 수준을 관리한다. KPI 선정은 정량적으로 측정 및 평가가 가능한 항목을 선정하여야 한다.
서비스 수준의 측정은 서비스 수준 합의서에 명시된 측정 대상, 측정방식, 측정 주기, 기록 매체 및 방식을 준수하여 이루어지며, 서비스 수준 평가 시 이슈가 없도록 객관적인 도구를 사용하는 것이 효율적이다.
75
서비스 수준의 평가는 서비스 수준 합의서에 정의된 평가 방식을 따르며
공식적인 절차를 통하여 서비스 사용자와 제공자 사이에 평가 결과에 대하여
합의를 이루어야 한다. 이는 결국 서비스 사용료에 영향을 미치므로 투명한 절차와 상호 신뢰기반 위에서 이루어져야 한다.
사용량 기반 IT서비스 수준의 측정 및 평가 시 참고할 수 있는 주요 세부사항은 다음과 같다.
가. KPI 선정
핵심성과지표(KPI : Key Performance Indicator)는 사용량 기반 IT서비스를 운용함에 있어 서비스 제공자 및 사용자 상호간에 협의된 서비스 품질
수준의 준수 여부를 평가하기 위하여 사용되는 측정 지표들의 집합이다.
KPI는 선진 사례를 참고하여 서비스 제공자가 KPI지표 Pool을 제공하고 이를 기반으로 사용자 측면의 요구 내용 및 수준을 고려하여 상호 합의 하에
적합하다고 판단되는 대표 항목들을 선정, 작성한다.
사용량 기반 IT서비스 양 당사자간에 많이 활용되고 있는 주요 KPI에는 다음과 같은 지표들이 있다.
① 서버 가동률(Availability)= ((합의된 운영시간의 합 – 비정상적인 정지시간)/합의된 운영시간의 합) X 100
② 데이터 Backup/Restore 성공률
76
= (1- 백업 및 복구 실패 회수 / 합의된 백업 및 복구 회수) X 100③ 변경작업 이행율
= ((합의된 변경작업 시간 – 지연시간) / 합의된 변경작업 시간) X 100④ 변경요청 성공률
= (1 - (변경작업 실패 건수 / 총 시스템 변경작업 건수) X 100⑤ CSR 처리율
= (1 – (지연 CSR건수) / 총 CSR 수) X 100⑥ 중복 장애 발생 건수
= 각 시스템의 중복장애 건수 또는 특정 장애의 중복 발생 건수⑦ 장애 초기 복구율(‘**’H이내 장애 복구율)⑧ 스토리지 적시 공급 이행율
= (합의된 Delivery Time 내 공급건수 / 총 건수) X 100⑨ 스토리지 가동률
= ((합의된 운영시간의 합 – 비정상적인 정지시간) / 합의된 운영 시간의 합) X 100
⑩ HA 테스트 이행율= (총 테스트 이행 건수 / 합의된 HA테스트 계획 건수) X 100
⑪ DB Hit Ratio= Buffer Cache Hit Ratio, Library Cache Hit Ratio, Dictionary Cache Hit Ratio etc.
⑫ DB서버 평균 Down Time⑬ DB 가동률
상기 KPI에 대한 목표수준은 매년 사용자의 환경 및 요구 수준에 따라 별도의 ‘서비스 수준 합의서’를 작성하고, 서비스 사용자와 제공자 대표로 구성된 실무위원회에서 협의를 통하여 결정하며, 매년 말 서비스 수준 평가를 통하여
77
비용 정산, 개선사항 도출의 과제를 이행한다.
나. 패널티 및 인센티브
서비스 제공 결과인 서비스 수준의 평가에 따라 기 합의된 패널티(Penalty)와 인센티브(Incentive)가 발생할 수 있으며, 서비스 사용료에서 발생 패널티와 인센티브를 정산한다. 경우에 따라 다를 수 있지만 패널티와 인센티브의 실 정산은 년 단위로 이루어 지는 것이 일반적이다.
패널티와 인센티브는 궁극적으로 서비스 품질을 향상시키고자 하는 목적으로
사용되어야 하지만 패널티 자체는 서비스 제공자에게 큰 위험(risk)으로 작용할 수 있는데, 이러한 부분은 사용자와의 협의를 통하여 패널티 규모의 최대 범위를 월 서비스 비용의 10% 이내로 한정하는 방법 등을 적용하면 상호 신뢰기반 위에서 효율적인 서비스 운용이 가능할 수 있을 것이다.
패널티와 인센티브의 기준은 위에서 언급한 KPI의 합의된 수준의 달성 여부이며, 발생기준은 월, 분기, 년 단위로 사용자와 제공자간의 합의에 따라 합리적으로 적용할 수 있다. 일반적으로 패널티와 인센티브는 서비스 사용료의 가감을 통하여 실 정산되며, 특정 단위의 포인트 방식으로 축적한 후 년 단위로 정산하여 차기 년도 서비스 비용에서 처리하기도 한다.
아래는 패널티와 인센티브의 적용 기준이 되는 서비스 수준표의 사례이다.
구분 서비스 수준 설정 평가점수
탁월수준 각 항목별 목표 수준 ()%초과 달성 S (5)우수수준 각 항목별 목표 수준 ()%초과 달성 A (4)
78
목표수준 각 항목별 당해 년도 목표 수준 B (3)미흡수준 각 항목별 목표 수준 ()% 미흡 C (2)문제수준 각 항목별 목표 수준 ()% 미흡 D (1)
위의 수준표에 따라 10~20% 내에서 합의에 따라 적용률을 결정하여 패널티와 인센티브 적용 기준을 수립할 수 있으며, 그 하나의 사례는 다음과 같다.
기대수준 스코어 구분 적용률
탁월수준 5<=스코어 Reward 발생 10%우수수준 4<=스코어<5 Reward 발생 5%목표수준 3<=스코어<4 변동사항 없음 0%미흡수준 2<=스코어<3 Penalty 발생 5%문제수준 1<=스코어<2 Penalty 발생 10%
79
4. 사용량 기반 IT서비스 성공의 조건
4.1 유틸리티 컴퓨팅의 사례
2003년 초에 HP, IBM 같은 글로벌 IT 기업이 유틸리티 컴퓨팅 개념을 한국에 소개하고 유틸리티 데이터센터 같은 솔루션을 제시하여 많은 기업들의
관심을 끌었다.
유틸리티 컴퓨팅은 서버, 스토리지 등의 IT 자원을 수돗물이나 전기처럼 필요할 때 필요한 만큼 사용하고, 사용한 만큼 비용을 지불하는 것으로서 개념 측면에서는 사용량 기반 IT서비스와 동일하다. 즉, IT 운영 서비스 전문 업체가 모든 IT 자산을 소유하고, 전문기술과 운영 경험을 바탕으로 고효율로 운영하여 컴퓨팅 파워, 저장공간 등을 네트워크를 통해 낮은 가격에 제공하고, 일반 기업은 IT 자산이나 운영인력을 보유하지 않고 필요 할 때 전문 서비스업체로부터 필요한 만큼 제공받고, 사용한 양 만큼 비용을 지불하는 새로운 컴퓨팅 모델이다.
초기에는 여러 기업들이 유틸리티 컴퓨팅에 관심을 가지고 실행 가능성을
80
검토했으나 결과적으로 한국에서는 두 개 기업이 대형 UNIX 서버 몇 대와 스토리지 영역에서 구현하여 제한된 소수의 고객에게 제공했을 뿐 다른 사례는
거의 없어 사람들의 관심에서 조금 멀어졌다.
IT서비스 사용자와 전문 공급자가 분리되고, 더 낮은 가격에 필요한 만큼 제공한다는 유틸리티 컴퓨팅 모델은 전통적인 컴퓨팅 모델보다 우수하다고
판단되었으나 비즈니스 모델로서 크게 성공하지 못한 이유는 다음과 같이
정리할 수 있다.
첫째, IT 아웃소싱 조차 활성화 되지 않은 상황에서 IT서비스 공급자와 사용자를 분리하고 모든 IT 자산과 인력을 서비스 공급자가 가져가는 개념은 기업 내 IT 조직에게는 수용하기 어려웠다.
둘째, 유틸리티 컴퓨팅을 구현하는데 필수적인 가상화와 자동화 기술이 충분히 성숙되지 않아 기능의 유연성과 완성도가 높지 않았다. 그래서 구현 시 제약조건도 많고 비용이 많이 드는 반면 공급자나 사용자가 얻을 수 있는 혜택이
그리 크지 않았다.
셋째, 제시된 성공사례가 적어 새로운 것을 시도하려는 기업들이 등장하기 어려웠다.
이런 이유로 유틸리티 컴퓨팅이 비즈니스 모델로서는 크게 성공하지 못했으나, IT 기능의 유틸리티화 및 사용자와 운영자의 분리 개념은 IT분야에서 일하는 거의 모든 사람들에게 알려지게 되었다.
81
4.2 클라우드 컴퓨팅의 사례
한국에서는 2008년 하반기부터 클라우드 컴퓨팅이 소개되기 시작해서 2009년에 IT 산업 분야에서 가장 뜨거운 주제가 되었다. 클라우드 컴퓨팅을 단순화해서 설명하면 전문적인 공급자가 제공하는 IT서비스를 인터넷을 통해 사용하고, 사용한 양 만큼 비용을 치르는 것으로서 ‘IT 자산 또는 IT 관련 기능이 사용자에게 서비스 형태로 제공되고, 사용한 서비스의 양과 품질에 비례해서 결정되는 가격을 사용자가 지불하는’ 특징 면에서 볼 때 클라우드 컴퓨팅도
사용량 기반 IT서비스의 정의에 정확하게 부합한다.
아마존이 2006년 7월부터 아마존 웹 서비스(Amazon Web Service)라는 이름 하에 EC2(Elastic Compute Cloud), S3(Simple Storage Service) 등의 인프라 서비스를 제공하기 시작했고, 뉴욕 타임즈는 1851년부터 1922년 사이의 신문기사 1100만개를 PDF 타입 파일로 변환해서 일반인에게 무료로 제공하려는 Timemachine 프로젝트를 위해 컴퓨터나 저장장치 등을 전혀 구입하지 않고 아마존 AWS 서비스를 선택했다.
뉴욕 타임즈는 EC2로 백대의 가상 PC와 1.5TB S3 저장 매체를 사용하여 36시간 만에 변환 작업을 완료했고, 비용은 불과 1,465 달러를 치러 대표적인 인프라 서비스 성공 사례가 되었다.
온라인 비디오 믹싱 서비스를 제공하는 아니모토사는 자체적인 인프라를
82
구축하는 대신 아마존의 AWS 서비스를 사용하기로 결정했다. 이 결정으로 아니모토사는 위험부담 없이 즉시 비즈니스를 시작할 수 있었고, 사용자가 폭발적으로 증가하는 상황에서 워크로드 증가에 따라 아마존의 AWS 인프라 서비스를 즉시 추가하여 성공적으로 비즈니스를 운영했다.
이들 외에도 다양한 클라우드 컴퓨팅 인프라 서비스 성공 사례가 계속
추가되고 있다. 클라우드 컴퓨팅이 성공할 수 있었던 이유는 다음과 같이 정리할 수 있다.
서비스를 아주 저렴한 가격에 제공
서비스를 사용하기가 간편함
원할 때 원하는 만큼 사용할 수 있음(대규모 확장성/유연성) 이름이 널리 알려진 거대 기업이 서비스를 제공
다양한 활용 성공 사례 증가
83
4.3 사용량 기반 IT서비스 성공의 조건
4.3.1 사용량 기반 IT서비스 선택의 조건
사용량 기반 IT서비스는 단지 대가 체계만을 의미하지 않는다. 사용자 입장에서 보면 IT 자산 도입, 운영인력, 데이터 관리 면에서 과거와 상당히 다른 새로운 방식의 선택을 의미하기 때문에 단지 가격만이 아니라 여러 측면에서
상당한 혜택이 있어야 이런 변화를 선택할 수 있다.
사용자 입장에서 볼 때 기본적으로 다음의 두 가지 조건을 만족시킬 때 선택을
할 수 있을 것이다.
[그림 4-1] 사용량 기반 IT서비스 선택의 조건(1)
그리고 좀 더 구체적으로 살펴보면 다음과 같이 뚜렷한 장점을 제공할 때
사용자들이 사용량 기반 IT서비스를 선택할 수 있을 것이다.
84
[그림 4-2] 사용량 기반 IT서비스 선택의 조건(2)
IT서비스 공급자가 이것을 달성할 수 있을 때 즉, ‘사용량 기반 IT서비스 성공의 조건’을 갖출 때 그 요건을 만족하는 서비스를 사용자에게 제공할 수
있다.
4.3.2 사용량 기반 IT서비스 성공의 조건
사용량 기반 IT서비스 성공의 첫 번째 조건은 경제성이다. IT서비스 생산비용을 줄여 사용자에게 낮은 가격에 제공하면서도 이윤을 창출할 수
있어야 한다. 즉 사용자가 원하는 고품질의 서비스를 기존보다 최소한 15~20% 낮은 가격에 제공해야 한다. 그러면서도 IT서비스 공급자는 10~20%의 이윤을 확보할 수 있어야 비즈니스를 지속하고 성장할 수 있다.
따라서 IT서비스 공급자가 사용량 기반 IT서비스 비즈니스에서 성공하기 위해서는 전통적인 방식보다 30~40% 이상 비용을 낮출 수 있는 방법을
85
확보해야 한다.
[그림 4-3] IT서비스 생산 비용과 IT서비스의 가격
현재의 일반적인 IT 환경 및 기술 발전 현황을 고려할 때 IT서비스 비용을 낮출 수 있는 주요한 방법은 다음과 같이 4가지로 정리된다.
가. 규모의 경제(Economies of Scale)를 통한 단위 서비스 비용 절감
데이터센터의 규모를 대형화 하여 단위 서비스당 상면비용, 시설비용, 그리고 인프라 운영비용을 낮추어야 한다. 그리고 데이터센터의 입지를 잘 선정하여 토지비용과 세금 등도 절감하여야 한다.
아마존, 구글 등은 데이터센터 입지 선정 시 주 정부와의 협상을 통해 토지 임차비용과 세금을 크게 줄이고, 3만여 평 규모의 대형 데이터센터를 건축하여 단위 면적당 비용을 다른 기업들보다 크게 낮춘 것으로 알려졌다.
86
그리고 최근에는 데이터센터 건축 비용을 줄이고 단기간에 쉽게 확장할 수
있도록 컨테이너형 데이터센터를 짓고 있다. 이런 방법을 통해 상면 비용을 1/2~1/3 수준으로 낮추는 것이 가능할 것이다.
나. 운영효율 향상(Operational Efficiency Improvement)
사용하는 장비와 소프트웨어 스택(stack)의 표준화 수준을 현재보다 대폭 높여 운영환경, 이벤트 및 장애발생 유형을 단순화 하여야 한다. 기술 표준화는 자동화와 가상화 기술 적용을 용이하게 하고, 운영관리 프로세스 최적화와 자동화 구현을 손쉽게 한다. 이것이 실현되면 운영비용이 현격히 감소될 수 있고, 이벤트 대응 및 작업처리의 정확도가 향상될 수 있다.
표준화와 자동화가 적용되지 않았을 경우 시스템 관리자 한 사람이 UNIX 서버는 약 20대, Windows 서버는 15~40대를 운영할 수 있고, 비교적 낮은 수준의 표준화와 부분적인 자동화를 적용했을 경우에는 30~90대를 운영하는 것으로 조사되었다. 구글은 대단히 높은 수준의 표준화와 자동화를 통해 이 숫자를 1,200대로 끌어 올렸다.
그리고 포탈을 통해 사용자 셀프 서비스 방식으로 IT서비스를 제공하여 서비스 운영관리 인력 비용도 절감하여야 한다. 이 방법을 통해 운영효율을 5배 높여서 관련 인력비용을 1/5로 낮추는 것이 가능할 수 있을 것이다.
다. 자원 사용률 증대(Utilization Improvement)
각 애플리케이션별 전용시스템으로 구성되었을 경우 Windows 서버의 평균 CPU 사용률은 15~20%, UNIX 서버는 35~40% 수준인 것으로 조사 되었다.
87
이것은 수돗물을 최대로 틀어놓고 그 중 일부만 사용하는 것과 같은 것으로
귀중한 컴퓨팅 용량(Capacity)이 낭비될 뿐만 아니라 IT 장비의 전력 사용, 발열로 인한 냉각전력 사용, 전력 전달 및 변환과정에서의 손실 등 추가적인 비용발생을 초래하게 된다. 따라서 높은 수준의 기술 표준화, 가상화를 적용한 공유 자원 풀(Shared Resource Pool) 구성, 동적 최적화(Dynamic Optimization) 아키텍처 구현을 통한 자원분배 최적화를 적용하여 자원 사용률을 현재의 2~3배 수준으로 끌어 올려야 한다.
이 목표를 달성하기 위해 잊지 말아야 할 사항은 피크타임이 서로 다른 사용자
또는 애플리케이션이 골고루 분포되어야 전체 인프라의 자원 사용률을 높일 수
있다는 것이다. 일반적으로 특정 기업에서 사용하는 애플리케이션들은 80~90%가 비슷한 시기에 피크타임을 가지고 있어서 소수의 동일 유형 기업들에게만 인프라 서비스를 제공할 경우특정 시간에 피크타임이 집중되어
전체 자원 사용률을 높일 수 없다. 특성을 달리하는 다수의 기업, 또는 불특정 다수의 고객을 확보해야 이 목표를 달성할 수 있다. 구글이나 아마존은 전세계에 있는 불특정 다수 고객에게 서비스를 제공하기 때문에 특정 시기에만 수요가
집중되는 현상을 피할 수 있고 이런 이유로 높은 수준의 자원 사용률을 유지할
수 있다. 고객을 다양화할 경우 자원 사용률을 2배 이상 높여 단위 인프라 비용을 1/2 이하로 낮추는 것이 가능할 수 있을 것이다.
라. 그린 IT를 통한 전력비용 절감
2009년 현재 데이터센터 전체 운영비용 중 전력비용이 차지하는 비중은 5% 내외인 것으로 조사되었다. 그러나 IT 장비의 증가 추세와 한국의 전력요금 인상추세, 그리고 한국 기후의 아열대화를 결합하면 약 5년 후에는 전력요금이 평균 4배 이상 증가할 것으로 예측된다. 다른 비용은 비교적 일정한 수준을
88
유지하거나 미미하게 증가하는 추세인 것을 감안하면 5년 후에는 전력비용이 데이터센터 전체 비용의 20% 가량을 차지하게 될 것이다. 이것이 시사하는 바는 그린 IT 기술을 적용하여 전력비용을 절감할 경우 IT서비스 생산비용의 상당부분을 낮출 수 있다는 것을 의미한다.
미국의 어떤 기업은 외기냉각을 통해 기계실 냉각비용을 절감하기 위해서
데이터센터를 지하 200m 갱에 짓고, 다른 기업은 같은 이유로 알래스카에 짓고 있다. 또 다른 기업은 전력비용을 줄이기 위해 데이터센터를 수력발전소 인근에 짓고 있다. 네트워크 회선비용 보다 전력선 비용이 훨씬 비싸기 때문이다. 전력효율이 높은 장비 선택, 가상화 기술 적용 및 워크로드 변동에 따른 자원배분 최적화, 기계실 온도 변화에 따른 최적 냉방기술 적용, 전력 변환/전달 효율 향상 등을 통해 전체 전력비용을 50~60% 절감할 수 있을 것이다.
이들 중 특히 기술 표준화, 통합, 가상화와 자동화는 서로 밀접하게 연관되어 있어 인프라 서비스 시스템 아키텍처 설계 시 반드시 함께 고려되어야 하고, 이들 모두가 적용될 때 비용절감 효과를 극대화할 수 있다는 것을 유념해야 한다.
89
[그림 4-4] 표준화, 가상화, 자동화의 IT서비스 생산 비용에 대한 영향
사용량 기반 IT서비스 성공의 두 번째 조건은 안정적으로 서비스를 제공할 수 있는 안정성이다. 이것은 다음의 두 가지 측면을 갖는다.
첫째, 서비스 자체의 안정성으로서 장애나 사고 없이 사용자가 원할 때 언제가 서비스가 사용 가능해야 한다. 비즈니스가 글로벌화 함에 따라 24시간 365일 서비스를 하는 기업이 증가하기 때문에 IT 인프라 서비스도 언제나 제대로 동작되어야 한다.
둘째, 서비스 제공기업 자체의 안정성이다. 사용자 특히 서비스를 장기간 사용할 기업 사용자는 IT서비스 공급자 선택 시 그 회사가 어느 날 도산할 가능성을 고려하지 않을 수 없다. 이 경우 사용자는 당연히 오랜 동안 안정적으로 서비스를 제공할 것으로 기대되는 회사를 선택하게 되므로 IT서비스 공급자는 수익성을 바탕으로 비즈니스를 지속하여야 한다. 따라서 사용자로부터 지속적으로 선택되기 위해서는 브랜드와 규모가 중요하다.
90
사용량 기반 IT서비스 성공의 세 번째 조건은 사용자와 제공자간의 신뢰와 투명성이다. 특히 사용자가 개인이 아닌 기업이고 서비스를 장기간 사용할 경우 IT서비스 사용량 정보에 대한 신뢰와 투명성은 대단히 중요하다.
서비스 제공자가 서비스 사용량에 대한 상세한 정보를 주기적으로 제공하고, 사용자가 원할 경우 언제든 자세한 내용을 확인할 수 있어야 한다. 비용절감과 안정성이라는 실질적인 혜택이 있고 사용자와 제공자간에 믿음과 신뢰가 있을
때 비즈니스 관계가 오래도록 유지될 수 있기 때문이다. 제공자가 사용자로부터 신뢰를 얻지 못할 경우 사용자는 항상 다른 대안을 찾게 되고 제공자는 고객을
계속 잃을 수 밖에 없다.
5. 사용량 기반 IT서비스 적용에 따른 기대효과 및 전망
5.1 기대효과
91
최근 IT시스템 구축 시 기존의 전통적인 IT 자산 투자 방식이 아닌 사용량 기반 IT서비스를 도입함으로써 사용자 측면에서 Time-to-Market향상으로 시장의 환경변화 및 고객의 요구에 빠른 대응이 가능해지고 있다. 또한 기존의 전통적인 방식에서 IT 자산 투자 후 효율적인 사용에 대한 관리 및 사후 평가가 미흡했던 문제점을 사용량 기반 IT서비스 도입으로 IT인프라 비용 절감, 최적화 사용을 통한 효율화가 가능할 것이다.
최근 국내외적으로 Green IT가 핵심 관심사로 부각되고 있어 가상화 기술을 통한 IT인프라 구현 및 IT의 효율적 사용이 가능한 사용량 기반의 IT서비스가 주요 솔루션으로 간주되고 있다. 이러한 사용량 기반의 IT서비스 도입으로 IT비용, 효율성 차원 등에서 기업 또는 기관 등 서비스 사용자 측면과 서비스 제공자인 IT서비스 산업 측면에서의 기대효과는 다음과 같다.
5.1.1 도입 기업 측면
가. 비즈니스 민첩성(Agility) 향상
기존의 IT투자는 ISP(정보화전략수립)를 통한 정보환경 및 IT시스템 환경 분석을 시작으로 정보시스템, 프로세스 설계, Capacity Planning, 플랫폼 선정, Facility 계획, 구매/도입/설치/검수, 유지보수, Scale-up 등 복잡한 프로세스가 필요하다. 미래의 사용량을 미리 예측하여 설계하는 방식에는 한계가 있을 수 밖에 없으며, 또한 비즈니스 요구사항에 대하여 이러한 접근법은 많이 시간과 노력을 필요로 하여 결과적으로 많은 부대 비용이 발생하며 IT의 고객 만족도 저하로 이어진다.
92
사용량 기반 IT서비스 도입으로 이러한 IT투자의 Lead Time을 획기적으로 줄일 수 있으며 결과적으로 비즈니스 민첩성(Agility)이 향상될 수 있다. 사용량 기반 IT서비스 사용자는 IT인프라 자원에 대하여 필요한 시점에 필요한 만큼만 요청하여 사용하고 서비스 사용료를 지불하기만 하면 되기 때문에 기존의
복잡한 여러 프로세스로 인한 시간과 노력을 절약할 수 있다. 즉, 용량 설계의 어려움이나 구매/설치까지의 시간을 기다릴 필요가 없으므로 비즈니스의 IT에 대한 요구사항에 대하여 즉각적인 대응이 가능해진다.
나. IT투자 효율화 및 비용절감
기존의 전통적인 IT투자는 사용과 IT비용간의 조율기능이 전무한 실정이었다. 그러다 보니 IT 투자 후 효율적 사용에 대한 모니터링이 적절히 수행되지 못하였으며, 무분별한 사용에 대한 통제 또한 적절하게 수행되기 힘든 구조적 문제점을 안고 있었다. 이러한 문제점은 투자와 사용의 주체가 다르다는 측면도 있지만 IT자원의 사용이 IT운영 비용에 반영되지 못한 측면이 더 큰 원인으로 볼 수 있다.
사용량 기반의 IT서비스는 IT자원의 사용량이 IT비용으로 발생하는 구조로 매년 차기년도 사용량 예측으로 IT예산을 수립하고 그 변동성을 모니터링하고 통제하는 체계가 가능해질 수 있다. 이것을 통해 궁극적으로 IT비용 절감을 달성할 수 있을 것이다. 또한 다양한 플랫폼에 의한 복잡성 문제 등도 Shared기반의 표준 IT인프라 아키텍처 구축으로 해결이 가능하여 비용 효율적인 IT시스템 운용이 가능할 것이다.
다. 재무 건전성
93
ERP, CRM 등 일시적인 대규모 투자가 필요한 IT시스템을 사용량 기반 IT서비스로 이용할 경우 초기 투자비에 대한 부담을 해소할 수 있으며, 이를 통한 현금유동성(NPV : Net Present Value) 개선의 효과가 있다. 사용량 만큼만 비용을 지불하기 때문에 IT비용을 비즈니스와 연동이 가능하며 전체적인 기업의 재무 건전성에 기여할 수 있을 것이다. 또한 신규 비즈니스 계획 시 IT 자원에 대한 요구량에 따라 IT투자에 대한 가시성(Visibility)도 향상될 수 있다.
라. IT자원 최적 사용을 통한 Green IT 구현
전통적인 IT시스템 투자의 경우 독립적인 시스템 구축으로 과다 투자 및 비효율적인 중복투자의 문제가 심각하였다. 결국 사용하지도 않은 비용을 지속적으로 지불하고 있었으며 이로 기인한 에너지 낭비도 심각한 문제였다.
최근 국제적으로 탄소배출권 문제가 대두되어 국내에서도 핵심 쟁점화 되고
있으며, 머지않아 IT폐기물에 대한 심각성도 기업에 중요한 문제로 부각될 것이다.
사용량 기반 IT서비스 사용으로 불필요한 IT자원의 낭비를 줄일 수 있고 표준화된 IT인프라 구현으로 사용자 요구사항 및 비즈니스 환경 변화에 대한 IT시스템의 유연성을 높일 수 있을 것이다. 이것이 결과적으로 낭비를 제거하여 에너지 절감을 이룰 수 있고 과도한 IT폐기물 발생을 최소화할 수 있을 것이다. 또한 사용량 기반 IT서비스 사용자 입장에서는 탄소배출권에 대한 의무를 자연스럽게 서비스 제공자에게 넘길 수 있는 합법적이고 효과적인 방안이라고
할 수 있다.
마. 표준화 및 자동화를 통한 IT서비스 품질향상
94
일반적으로 사용량 기반 IT서비스를 제공 시 경제적인 측면에서 효과를 얻기 위해서는 IT인프라가 표준화된 플랫폼과 자동화된 프로세스에 의해 설계되고 구축, 운영되어야 한다. 유연하게 Scale-up과 Scale-out이 가능한 표준 서버, 스토리지, 네트워크 아키텍처 구현이 필요하며 시스템화된 자동 할당/해지 기능 구현이 필수적이다.
이러한 표준화 및 자동화, 가상화된 IT인프라를 사용함으로써 사용자는 IT서비스의 품질을 향상시킬 수 있을 것이다. 주기적인 자원 최적화를 통하여 이를 극대화하며 이는 사용자의 비용절감 효과를 제공할 것이다.
5.1.2 IT서비스 산업 파급효과
가. IT서비스 산업의 양적 질적 성장 촉진
지금까지 국내 IT서비스 산업은 IT시스템 운영, 개발 아웃소싱 위주로 성장을 해왔다. 하지만 글로벌 업체와의 경쟁 심화, 지속적인 IT비용의 증가 추세, 대기업 SI회사에 의한 시장 독점, 사용자의 ITO 효과에 대한 회의적 시각 등으로 새로운 서비스 구조 및 성장 동력이 필요하게 되었으며, 사용자에겐 품질 높은 서비스 선택의 다양성이 필요한 상황이다.
IT인프라에 대한 사용량 기반 IT서비스를 활성화함으로써 통신시장에서의 가상통신망사업자(MVNO : Mobile Virtual Network Operator)와 같은 2차 서비스 사업자 육성으로 사용자에게 적절한 가격의 서비스에 대한 다양한
선택을 제공할 뿐만 아니라 IT서비스 산업의 성장을 촉진하는 효과를 얻을 수 있을 것이다.
95
나. 국내 IT서비스 경쟁력 강화
기존의 IT투자 방식은 소수의 글로벌 IT업체에 의존하는 산업 구조적인 문제점을 안고 있었다. 특정 제품 종속적인 문제로 고비용을 지불하여 IT시스템을 도입하고 증설하는 일이 빈번하였으며, 특히 중소기업의 경우 구매력이 상대적으로 대기업, 공공기관과 비교하여 약점을 가지고 있어 고비용을 지불할 수밖에 없는 실정이었다.
사용량 기반 IT서비스 활성화를 통하여 사용자에게 다양한 선택을 제공하고 서비스 제공자는 대규모 IT인프라 선투자가 가능하여 구매 협상력이 기존보다 개선될 것이다. 이는 결국 국내 IT서비스 산업을 촉진시킬 것이며 대형 글로벌 벤더 종속성 문제를 일정수준 해결할 수 있을 것으로 기대한다.
5.2 사용량 기반 IT서비스의 발전 전망
이미 인터넷 개화기 이전의 초창기 메인프레임 시스템에서부터 컴퓨팅 자원을
논리적으로 분할하여 필요한 만큼만 할당하여 사용하는 개념은 사용되어 왔으며, 현재에 이르러 ASP, Utility Computing, SaaS, Cloud Computing에 이르기까지 그 개념과 기술을 발전시켜 다양하게 서비스화하고 있다.
본 지침에서 IT인프라에 초점을 맞추어 사용량 기반의 IT서비스를 정의하고 가이드라인을 제시하였지만 플랫폼, 어플리케이션, 나아가 비즈니스 프로세스 영역까지 확장되어 IT시스템을 자체 구축하지 않고 서비스로써 제공되고 사용하는 추세는 더욱더 증가될 것이다.
96
사용량 기반의 IT서비스는 B2B에서 일반 가정, 개인 나아가 특정 디지털 기기(Device)까지로 확대될 것이며, 차세대 인터넷 기술의 발달로 지리적 경계를 넘어서 글로벌 서비스화될 것이다.
97
표준작성 공헌자
표준 번호 : TTAx.xx-xx.xxxx
이 표준의 제․개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.
구분 성명 위원회 및 직위 연락처 소속사
과제 제안 문성준
공공정보
프로젝트그룹
간사
한국정보화진흥원
표준 초안
제출
이상학
공공정보
프로젝트그룹
의장
한국정보화진흥원
문성준
공공정보
프로젝트그룹
간사
한국정보화진흥원
김치호 -02-6710-3989
나종회 -062-670-2323
[email protected]광주대학교
송성환 -02-565-0531
[email protected]다음소프트
이성열 -031-8006-5161
삼성SDS
한인종 -02-2199-0879
표준 초안
검토 및
작성
이상학
정보통신
프로젝트그룹
의장
한국정보화진흥원
외 프로젝트그룹
위원
표준안
심의
이헌중 IT 응용 기술위원회 의장
한국정보화진흥원
정보통신단체표준(국문표준)
사용량 기반 IT서비스 구현 및 도입 지침(Guideline for Realization and Induction of
Usage Based IT Service)
발행인 : 한국정보통신기술협회 회장발행처 : 한국정보통신기술협회
463-824, 경기도 성남시 분당구 서현동 267-2Tel : 031-724-0114, Fax : 031-724-0019
발행일 : 20xx. xx
