대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 Database as a Service : 클라우드 아키텍처의 설계
등록일 조회수 7318
첨부파일  

Database as a Service

클라우드 아키텍처의 설계



변하는 비지니스 환경에서 기업은 경쟁사와의 경쟁, 시장의 변화에 대한 빠른 대응이 필요하다. 클라우드는 그러한 요구사항에 의해 탄생하였고 IaaS 와 PaaS 및 SaaS 등 다양한 영역의 서비스가 만들어졌다. 글로벌 선진 기업들은 이미 클라우드 서비스의 도입으로 IT 유연성 확보와 비용절감 등의 효과를 거두고 있다. 오라클은 모든 클라우드 솔루션을 최고 수준으로 통합 제공하는 유일한 IT기업이 며, 데이터베이스 영역에서 Database as a Service로 기업의 데이터베이스 클라우드 서비스를 지원한다. 이번 Cover Story 2에서는 오라클의 Database as a Service 에 대해 소개 하고자 한다.



Database as a service 소개

Database as a Service(DBaas)는 데이터베이스 서비스 프로바이더가 하나 혹은 그 이상의 서비스 소비자에게 데이터베이스 서비스를 제공하는 아키텍처, 운영 전략이다. DBaaS 아키텍처는 다음과 같은 요구사항을 만족해야 한다.

- 자원의 신속한 제공 및 Self-Service 방식으로 동작하는,서비스 소비자 중심의 Provisioning과 데이터베이스 관리
- 서비스 프로바이더가 설계한 서비스 등급과 정의된 비즈니스 달성 수준, QoS에 기반한 자동화된 모니터링과 통합 감사 및 규제 기능
- 데이터베이스 서비스 사용량에 기반한 Show-back 리포트와 Charge-back 기능
이러한 특성들을 포함하여 DBaaS는 태생적으로 클라우드 서비스를 통해 누릴 수 있는 자원의 탄력적인 운용과, 확장가능한 멀티테넌트, 자동화된 자원 관리, 용량 산정 및 설계 의 통합화를 지원한다.


왜 DBaaS를 도입해야 하는가?

비용 절감

비즈니스 및 IT 리더들은 신속하고 정확한 정보에 기반한 의사결정을 수행하기를 원한다. 정확한 정보를 적시에 활용하기 위해서, IT 프로젝트는 분리 구성된 정보시스템 각각의 요구사항, 환경설정, 지원모델 구축을 위해 막대한 Human Effort 와 자원 및 비용을 필요로 했다. 전통적으로 운영시스템은 업무지속성 확보를 위해 피크타임의 워크로드를 견딜 수 있도록 구성되어 왔고, 해당 운영시스템 들은 개발, 테스트, QA 시스템 등의 여러 용도로 주기적으로, 리플리케이션되어 제공 되어야만 하는 과제를 앉고 있었다. 이러한 피할 수 없는 유지보수에 소요되는 비용은 데이터의 증가와 더불어 더욱더 커지고 있는 실정이다.

DBaaS는 조직이 각 프로젝트의 다양한 환경, dedicated된 H/W 및 S/W의 배포와 유지관리 및 서포트에 소요되던 업무들을 절감 시켜주고, DBaaS 플랫폼 위에서 표준화되고 최적화된 가치를 제공할 수 있게 만들어 준다. DBaaS 아키텍처는 탄력적인 자원관리 위해서 투명하게 디자인되며, Product 혹은 Non-Product 데이터베이스 시스템대상으로 업무량 증가에 의한 Scale-Up, 감소에 의한 Scale-Down 에도 적정 워크로드를 보장할 수 있도록 지원한다.


서비스 수준 향상

DBaaS 아키텍처를 통한 서비스 향상 기대효과는 서비스 프로바이더와 소비자 모두에게 반가운 내용이다. 프로바이더는 H/W, S/W 구성의 복잡성을 감소시키고, 개 발하기 용이하도록 미리 설계된 서비스 카탈로그를 제공하면서 컨피규레이션에 대한 부담을 덜 수 있다. 이러한 부담의 해소는 비즈니스 목표 달성을 위한 신속성, 정확성, 향상된 품질로 이어질 수 있고, 또한 표준화된 개발 프로세스와 지원체계 개발 품질의 향상을 기대할 수 있다. 정리하자면, 플랫폼의 표준화 최적화에 집중할 수 있고, 자원관리, 용량관리에서 모호하고 불확실 했던 영역을 보완할 수 있어 서비스 수준의 향상이 가능해진다.
소비자가 얻는 기대효과는 3가지로 정리를 할 수 있다.



1. Self-Service Provisioning과 관리
Self-Service Provisioning과 관리를 통해 소비자가 보다 빠르고 쉽게 비즈니스를 위한 어플리케이션의 배포가 가능해진다.

2. 미리 약속된 서비스 정의
소비자가 프로바이더로부터 제공받는 서비스의 가용범위와 서비스 수준을 정확하게 이해 가능하고, 업무량의 증감으로 인한 대응이 용이하다.

3. Metering 및 Chargeback을 통한 IT비용 및 활용도 측정
소비자가 IT 자원의 활용 정도에 대해 투명하게 확인이 가능해지면서, 보다 정확한 근거에 기반한 시간 및 비용의 IT 투자결정이 가능해 진다.



DBaaS의 차이점은 무엇인가?

오늘날, 데이터베이스 서비스 제공에는 다양한 접근전략이있다. Database as a Service 가 전통적인 아키텍처와 특별히 구분되는 부분은 서비스-중심이라는 점과 소비자 기반 Self-Service 모델이라는 점일 것이다. 이 두 가지 특징이 DBaaS아키텍처가 투명성 및 유연성을 제공하는 동시에 비용절감효과와 보안, 효율성, 서비스 수준의 효과적인 향상을 달성할 수 있게 한다. DBaaS 아키텍처는 서비스 카탈로그를 통해 제공할 데이터베이스 서비스, 사이즈, 서비스 수준을 정의한 다. DBaaS 서비스 프로바이더가 명확하게 정의된 서비스 카탈로그와 가격모델을 개발하는 것이 중요한데, 서비스 카탈로그를 통해 소비자가 빠르고 쉽게 제공받을 서비스와 가격을 확인할 수 있기 때문이다.


<그림1> 프로바이더가 서비스 카탈로그를 제공하고, 소비자가 사용할 서비스를 선택한다.


또 다른 DBaaS 아키텍처의 중요한 요소는 프로바이더-소비자 간의 협의다. 소비자가 어떻게 원하는 서비스를 등록할 것인지, 계정관리를 수행할 것인지, 결제에 대한 방안, 자원활용률의 확인 방안, Provisioning과 데이터베이스 서비스의 사용에 대한 체계수립이 필요하기 때문이다.


<그림2> 프로바이더 및 소비자가 DBaaS를 관리하고, 체계수립이 가능한 오라클 EM12c


프로바이더가 이러한 기능요소와 요구사항들을 소비자에게 관리 포탈로 제공할 수 있어야, 소비자가 안정적으로 리스크 관리와 서비스를 지속할 수 있다.


DBaaS 도입시 고려사항

비즈니스 고려사항

DBaaS 를 통해 비즈니스 내/외부적으로 정량적인 효과를 기대할 수 있는데, 우선적으로 다음과 같은 비즈니스 요구사항에 대한 정량적인 고민이 필요하다.



- 비즈니스 사용자 기대효과
DBaaS 는 비즈니스에 직/간접적으로 이득이 있어야 한다. 예를 들어, 비즈니스 유저가 업무를 더 잘 수행하게 되거나,비용 효율성을 얻거나, 빠른 업무처리가 가능해야 한다.

- 비즈니스 프로세스 기대효과
DBaaS 는 SCM (Supply Chain Management) 이나 ERP(Enterprise Resource Planning) 혹은 HCM (Human Capital Management) 과 같은 비즈니스 프로세스에 측정 가능한 이득을 주어야 한다. 예를 들어, DBaaS는 신속하고 최적화된 기반구조를 통해 데이터베이스 서비스를 제공하고 핵심 비즈니스 프로세스를 지원할 수 있어야 한다.

- 전략적 비즈니스 목표 달성에 대한 기대효과
DBaaS 는 전략적 비즈니스 목표달성을 지원해야 한다. 예를들어, DBaaS 같은 표준화되고 최적화된 플랫폼을 통해 새로운 어플리케이션의 생성, 이관, 통합에 소요되는 시간을 줄일 수 있어야 한다.



IT 고려사항


- 전사적 전략
조직은 DBaaS 를 고려하면서 전사적 IT 전략을 이해하고 있어야 한다. IT 운영 모델의 이해, 배포에 대한 프로세스의 변경에 대한 임팩트에 관한 고민이 선행되어야 한다. 또 하나의 핵심 요소는 IT 운영모델의 거버넌스이다. DBaaS 아키텍처를 고려하면서 조직은 서비스가 어떻게 통합 관리될 수있고, 각종 법규 및 규정의 준수가 가능한지 확인해야 한다.그리고 DBaaS 아키텍처가 전사적 아키텍처에 부합해야 하며 IT 전략의 정책 및 계획안에 있어야 한다.

- 운영조직 및 프로세스
DBaaS 는 잘 운영할 수 있는가도 중요하다. Best Practice 컨셉이나 레퍼런스 아키텍처 그리고 서비스 중심 운영 모델들은, DBaaS 에서 소비자에게 반복적이고 안정적으로 측정 가능한 방식으로 제공하기 위해 적절한 IT 프레임워크가 필요하다. ITIL (IT Infrastructure Library), COBIT (Control Objectives of Information and related Technology),OEAF (Oracle Enterprise Architecture Framework) 등이 DBaaS 를 성공적으로 딜리버리할 수 있는 프레임워크이다.

- 기술적 옵션
프로바이더가 프레임워크에 대한 전략을 수립한 이후에, 해당 프레임워크에 기반한 DBaaS 서비스 배포 및 운영방안이 수립 가능해지고, 기술적 옵션들을 고민해 나갈 수 있다. 비즈니스 및 IT 요구사항, 서비스 관리, 자원 관리, 자산, 스킬,아키텍처 정책과 기술표준 등의 다양한 팩터들을 만족하는 기술들을 선택해야 한다.



DBaaS Architecture View

오라클 DBaaS 아키텍처 소개

DBaaS 를 위한 기술서비스에는 데이터베이스 서비스, 가용성 서비스, 보안서비스, 스토리지 서비스, 테스팅 서비스, 관리 서비스가 있다. 각 요소 서비스들은 클라우드 서비스를 위한 중요 기술요소이며 DBaaS 의 아키텍처를 구성하면서 서비스 품질에 맞도록 구현되어야 요구사항에 적합한 클라우드 서비스가 가능하다. 오라클은 각 서비스 요소에 속하는 다양한 솔루션을 보유하고 있고, 스토리지, 서버, 가상 머신, 오퍼레이팅 시스템, 데이터베이스, 미들웨어, 어플리케이션의 모든 스택을 아우르는 제품 군으로 구성된 오라클 Red Stack 을 제공하고 있다.


<그림3> 오라클 Red Stack


아키텍처 설계는 DBaaS 구현 중 중요한 단계이며, 설계는 개념 아키텍처 설계, 논리 아키텍처 설계, 물리 아키텍처 설계로 진행해 나가면서 To-Be 아키텍처를 수립한다.


개념 아키텍처 설계

개념 아키텍처 설계는 DBaaS 구현을 위한 기술 요구사항들을 개념적으로 정의해 나가는 단계이다. 데이터베이스 관리와 자동화를 위한 기술, 통합된 데이터를 접근하기 위한 기솔, 클라우드 사용자(Self-Service User)의 인증과 권한부여 및 보안에 관련한 기술, 클라우드 서비스 관리를 위한 기술 등 DBaaS 서비스를 제공하기 위해 필요한 요소들을 개념적으로 정의한다.


<그림4> DBaaS 개념 아키텍처 구성도


논리 아키텍처 설계

논리 아키텍처 설계에서는 개념적인 아키텍처에서 도출된 내용을 바탕으로 각 기술 요구사항에 적합한 제품들을 선정하고 구성하는 단계이다. DBaaS 서비스를 위한 데이터베이스 솔루션으로 오라클 데이터베이스 12c를 선정하고, DBaaS 서비스의 신청, 배포, 자원관리 및 과금등의 관리를 위한 관리 프레임워크로 오라클 엔터프라이즈 매니지먼트 12c를 선정해보자. 또한 DBaaS서비스를 위한 H/W 를 선정하기 이전에 논리적 레벨에서 To-Be 데이터베이스 서비스들을 분석하고, 적절한 서비스 레벨 및 사이즈로 매핑하여 논리적 아키텍처 구성을 완성한다.


<그림5> DBaaS의 논리 아키텍처 구성도, 서비스 카탈로그 선정 및 배치


이 단계에서 to-be 서비스 매핑을 위해 DBaaS 서비스 카탈로그가 필요한데, 서비스 카탈로그의 설계는 DBaaS 서비스 카탈로그 설계 부분에서 상세히 다루도록 하겠다.


물리 아키텍처 설계

물리 아키텍처 설계에서는 DBaaS 서비스를 위한 기술서비스 요소에 실제 플랫폼을 정의하고, 스토리지 설계, 백업 설계, 서버 Pool 구성, DBaaS 관리 콘솔의 옵션 구성과 서비스 리파지토리 구성 DBaaS 서비스 관리자 및 서비스 관리 API 등을 구성하여 DBaaS 이행을 위한 설계를 결정짓는다.


DBaaS 서비스 카탈로그

To-Be 아키텍처를 설계하는 과정은, 기존의 수많은 콘솔리데이션 및 차세대 시스템 구축 사업에서 수행되었던, 익숙한 프로세스를 거쳐 진행이 된다고 볼 수 있다. 그러나, 데이터베이스를 Private 클라우드 서비스로서 제공하는, DBaaS 만의 To-Be 아키텍처 설계를 위해서는 서비스카탈로그의 설계가 필요한데, 이것은 기존에 경험해보지 못한 새로운 설계가 필요한 부분이다. 클라우드 서비스 프로바이더는 서비스 사용자(Self-Service User)를 위해 적절한 수준의 서비스 레벨과 데이터 사이즈로 미리 구성된, DBaaS 서비스 카탈로그를 설계해놓고 목록으로 제공하며, 서비스 사용자가 UI (User Interface)를 통해 이를 신청하고 배포 받아 사용함으로써 새로운 데이터베이스 서비스를 제공 받게 된다. 따라서 업무적으로 기술적으로 사전 협의된 적절한 DBaaS 서비스 카탈로그의 설계가 중요한 요소가 된다. DBaaS 서비스 카탈로그의 설계는 다음과 같은 프로세스로 진행이 된다.


<그림6> DBaaS 서비스 카탈로그 설계 프로세스


비즈니스 카탈로그 정의

비즈니스 카탈로그 정의에서는 비즈니스 요구사항 분석을 통한 서비스 레벨을 도출한다. Bronze, Silver, Gold 등의 카탈로그 서비스 등급을 정의하고, 모든 비즈니스 항목을 고려한 SLA (Service Level Agreement) 수준에 준하는,서비스 수준을 정량화 한다.


<그림7> DBaaS 비즈니스 카탈로그 설계



테크니컬 카탈로그 정의

테크니컬 카탈로그 정의에서는 제공할 비즈니스 서비스의 단계와 그 정량적 수준이 정해졌으니, 그것들의 요구사항을 만족할 수 있는 기술 솔루션을 매핑하는 단계다.
데이터베이스 솔루션에는 오라클 데이터베이스 12c, 가용성을 위해서 RAC(Real Cluster Application) 수준을 정의, 관리 콘솔을 위한 오라클 엔터프라이즈 매니지먼트 12c선정 등이 이 과정에서 서비스 수준에 따라 차등 매핑된다.


<그림8> DBaaS 테크니컬 카탈로그 설계


서비스 배포 모델 정의

서비스 배포 모델은 서비스의 요청에 따라 여러 배포모델이 구성되는데, 그 방향을 결정하는 단계이다. 기존 콘솔리데이션 데이터베이스 환경에서는 단일 SMP 머신에서 데이터베이스 엔진을 별도로 가져가는 구성, 같은 데이터베이스 엔진내에서 데이터베이스 인스턴스 레벨로 구분 짓는 구성, 동일 데이터베이스 인스턴스 내에서 데이터베이스 스키마로 구분짓는 구성들이 자주 쓰였다. DBaaS 의 서비스 배포모델에서는 오라클 데이터베이스 12c의 멀티테넌트 기술이 포함된, 데이터베이스 엔진 레벨, 플러그형 데이터베이스(Pluggable Database) 레벨, 인스턴스 레벨, 스키마 레벨 의 확장된 배포모델을 포함한 구성이 가능하다. 고객 업무의 비즈니스 중요도에 따라 그 적정 배포모델의 구성이 필요하다.


리소스 모델 정의

리소스 모델은 클라우드 서비스가 배포되는 저장소의 구성을 설계하는 부분이다. 리소스 모델 에서 Zone 과 Pool 이라는 개념이 등장한다. Zone은 하나 이상의 데이터베이스 H/W 서버가 그룹 지어진 것으로, Local 과 DR 로 크게 구분 지을 수 있다. Pool 은 Zone 안에서 데이터베이스 엔진 하위로 종속된 작은 그룹이라고 보면 되겠다. 하나의 Zone 안에서 Pool 은 버전 별로, 서비스 모델 별로, 가용성 수준별로 차등구성이 가능하다. DBaaS 에서 DR 수준의 가용성을 구현하기 위해서는 Local 과 DR Zone 에 동일 수준의 Pool 이 서로 Active Data Guard 로 구성된 서비스 카탈로그를 구성하면 된다.


<그림9> DBaaS 서비스 카탈로그 예시


Metering과 Chargeback

DBaaS 서비스를 사용한다면, 서비스 프로바이더는 수익모델 체계를 수립해야 한다. 클라우드 서비스의 주요 팩터인, 자원을 필요한 만큼 할당하고 탄력적으로 운용하며 사용한 만큼만 비용 회수하는 전략이 필요하다. DBaaS Metering과 Chargeback을 위해 고려해야 할 요소는 세가지가 있다.

1. Provisioning 모델

앞에서 소개해 드린 바와 같이 Provisioning 즉 배포 모델은 데이터베이스 엔진, 인스턴스, PDB, 스키마 레벨로 구분이 가능하다. 일반적으로 전자 쪽으로 갈수록 자원의 사용률은 많아지고 과금을 위한 기본료의 차등 산정이 필요할 것이다.

2. 서비스 인프라스트럭처 활용율

하나의 서버에 여러 데이터베이스 서비스를 콘솔리데이션 하고자 할 때 tpmc 기반의 용량산정을 수행하고, 서버의 임계 치를 OLTP는 70%, OLAP 은 90% 정도로 정해두고 서비스 통합하는 방식의 접근전략이 주를 이루었다. DBaaS 서비스를 통해서는 정량화된 비용 측정 기준을 통해 Provisioning 후 즉시 해당 서비스들의 실 사용량의 측정 및 과금이 가능하다. 이를 통해 용량산정 및 구축 이후의 후속조치가 명확해질 수 있고 자원의 탄력성이 완성된다. 많은 비용을 들여 인프라를 구축해 두었으나, 예상보다 자원 사용율이 미미 하다면 추가 콘솔리데이션을 고려해서 서버 비용은 절감하면서 추가과금 효과를 누릴 수 있고, 잔여 자원을 여분으로 유지하면서 공실 자원에 대한 가중 팩터를 고려하는 Cost Recovery 정책을 수립하여 비용을 회수해 나갈 수도 있다. 탄력적인 수익모델의 설계가 가능해진다.

3. 서비스 비용 예측

DBaaS 서비스를 이용한다는 것은 서비스 사용자에 의해 선택된, 서비스 카탈로그가 클라우드 데이터베이스 안에서 H/W와 S/W 자원을 소모하여 제공이 된다는 것이다. 서비스 프로바이더가 투자비용을 회수하기 위해서는 서비스 구축 총 비용의 역산에서부터 서비스 비용의 설계가 시작되어야 한다는 것을 의미한다. 1기의 서버에 Zone 과 Pool 을 셋업하여 DBaaS 자원으로 구성하기 위해서 투자되는 H/W비용과 S/W 라이선스 비용의 총 합에서 비용회수 목표 시점까지의 총 개월 수를 나눈 값에, DBaaS 로 배포된 서비스가 사용하는 전체 Core 대비 할당 Core 수, 전체 Memory 대비할당 Memory 의 비율을 보정해 나가면 프로바이더가 원하는 시점에 Cost Recovery가 가능해지는 비용 전략의 수립이 가능하다.



<그림10> DBaaS 서비스 제공 이후 Cost Recovery 예상 시점


정리하자면, Metering 및 Chargeback을 통해 고객의 SLA에 준하는 DBaaS 리소스를 제공하고 그 활용 정도를 측정하고 과금하여 Cost Recovery를 기대 할 수 있으며, 사용되는 자원 소비량과 예상요구량의 보다 확실한 모니터링을 통해탄력적이고 비용 효율적인 자원의 운용이 가능해진다.


DBaaS 를 위한 오라클 솔루션

오라클 데이터베이스 12c

오라클 데이터베이스 12c 에서 새로 도입된 멀티테넌트 아키텍처는 DBaaS 클라우드 아키텍처 모델과 align 된다. 기존에 수많은 데이터베이스를 운영해왔던 기업이라면 주목할 만한 장점들을 가지고 있다. 멀티테넌트 아키텍처에서는 컨테이너 데이터베이스 하나에 플러그형 데이터베이스 여러 개를 포함시킬 수 있어, 데이터베이스를 한 번에 관리 가능하고,패치, 업그레이드, 백업 업무가 수월해진다.오라클 데이터베이스 12c는 다음과 같은 특징들로 DBaaS서비스를 가속화한다.

- 멀티테넌트 아키텍처는 PDB (Pluggable Database) 레벨로 Provisioning 이 가능하다.
- 멀티테넌트 아키텍처는 Clone 복제기능을 통한 신속한 배포가 가능하다.
- 각 PDB 레벨로 완벽한 보안체계를 지원한다.
- 기존 오라클의 고가용성 R AC(Rea l Appl icat ion Cluster), 재해복구 기술(Active Data Guard) 이 완벽히 연동된다.
- 데이터베이스 콘솔리데이션의 효율성을 배가시킨다.



<그림11> 멀티테넌트를 통한 콘솔리데이션 효율 향상


오라클 엔터프라이즈 매니저 12c

오라클 엔터프라이즈 매니저 12c(Enterprise Manager)는 오라클의 통합 전사 IT 관리 제품군에 속하면서, 업계 최초로 클라우드 라이프사이클 매니지먼트를 제공하는 솔루션이다. 오라클 엔터프라이즈 매니저 12c의 비즈니스 기반 IT관리 기능들을 통해 어플리케이션에서 스토리지, 전통적인 오라클 IT 환경에서부터 전사적인 클라우드 환경까지 모두를 빠르게 셋업하고 관리하고 지원 가능하다.

오라클 엔터프라이즈 매니저 12c는 오라클의 프리e Provisioning, 중 앙집중 관리체계, 정책기반 자원관리, 통합된 Chargeback과 용량산정, 통합된 베어 메탈 환경 및 가상환경을 어플리케이션에서 스토리지 레벨까지 모두 관리 가능한 완성된 솔루션이다.


클라우드 매니지먼트 팩

오라클 클라우드 매니지먼트 팩은 오라클 데이터베이스로 전체 데이터베이스 클라우드 라이프 사이클을 관장할 수 있게 만들어 주는 솔루션이다. 클라우드 매니지먼트 팩을 통해 클라우드 관리자가 자원 풀을 관리하고, 룰 기반의 접근제어를 수행하며, 서비스 카탈로그를 정의하고, Chargeback 플랜을 설계할 수 있다. 서비스 사용자는 데이터베이스의 서비스를 요청할 수 있고, 즉시 사용 할 수 있다. 또한 트래픽에 따라 유저가 Scale-Up 혹은 Scale-Down 을 수행할 수 있다.


Planning and Setup

엔터프라이즈 매니저 12c는 자동으로 토폴로지에 속한 인프라스트럭처의 디스커버가 가능하며, 현재의 워크로드를 파악하는데 용이하다. 관리자는 콘솔리데이션 플래너를 활용해 기존시스템에서 새로운 시스템으로의 이관 계획을 SLA에 준하여 관리할 수 있다. 플랫폼간의 빠른 이동 및 Provisioning을 지원하며, 자원 풀링을 통해 복합 콘솔리데이션 모델을 지원하고, 고가용성 솔루션인 RAC 를 포함하는 데이터베이스 레벨의 콘솔리데이션, 스키마 레벨의 콘솔리데이션, 오라클 데이터베이스 12c의 멀티테넌트 옵션인 Pluggable Database 레벨로의 콘솔리데이션이 가능하다.


Self-Service 애플리케이션을 활용한 Provisioning

엔터프라이즈 매니저12c는 개발자, 테스터, DBA, Self-Service 유저를 위한 독립된 Self-Service 포탈을 제공한다. DBaaS 소비자가 활용 가능한 Provisioning 방식은 다음과 같다.



-표준화된 RAC 인스턴스
-스탠바이 데이터베이스를 포함한 RAC 인스턴스
-데이터베이스 위에서 스키마로 제공되는 스키마 서비스
-오라클 데이터베이스 12c 멀티테넌트에서 가능한 Pluggable Database 서비스
-엔터프라이즈 매니저 12c 스냅 클론 기능을 활용한 Thin Clone
-RMAN 백업을 활용한 데이터베이스 Full Clone



그리고, Self-Service 유저는 라이프사이클 관리가 가능한데, 데이터베이스 서비스의 시작/종료, 모니터링 및 헬스 체크, 데이터베이스 및 스키마 서비스 요청을 수행 할 수 있다. Self-Service 포탈은 다양한 버전과 표준화된 데이터베이스로 설계된 서비스 템플릿의 목록을 제공하고 유저는 과거의 요청이력이나, 잔여 할당 자원량, 현재의 워크로드 량과 Chargeback 관련 정보를 확인할 수 있다. 포탈은 또한 유저가 즉시 혹은 Daily 기반의 자동 데이터베이스 백업을 수행할 수 있게 한다. 해당 기능들은 CLI(Command Line Interface) 나 API 를 통해서도 제공되어 자체 개발된 어플리케이션에서도 연동 가능하다.


Metering과 Chargeback

엔터프라이즈 매니저 12c는 다양한 개발자들과 비용센터간의 명확한 비용청구를 위해 여러 형식의 수집 Metric 을 지원하고 Chargeback 설계가 가능하다. 사용량 기반의 과금체계 뿐만 아니라, 데이터베이스 환경기반의 과금(예. 버전이나플랫폼)이나 고정된 비용 형태의 과금이 정책 수립이 가능하다. 스토리지 사용량 기반의과금 또한 지원한다.

Chargeback은 Rich Report를 지원한다. 특정기간의 과금량과 자원사용량의 트렌드 분석이 가능하고, 코스트 센터 별 혹은 서비스 유형별로 Summary Report가 가능하다. 이러한 상세 리포트 기능들은 IT 부서와의 예산 집행이나 수립 활동 시 근거 자료로 활용이 가능할 것이다. BI 퍼블리셔 기능을 활용해 리포트들은 PDF, HTML, Word, Excel, PowerPoint 의 다양한 포맷으로 제공된다.


<그림12> 엔터프라이즈 매니저 12c Chargeback 리포트


성능 및 가용성 모니터링

크리티컬 애플리케이션을 클라우드로 이관하고자 하는 IT매니저의 큰 고민 중 하나는 퍼포먼스이다. 엔터프라이즈 매니저 12c는 클라우드 자원의 헬스체크를 위한 Rich Solution을 제공한다.

관리자가 확인할 수 있는 Incident Console 을 통해 호스트관련 문제 해결, 데이터베이스 혹은 관련된 물리적 혹은 가상의 인프라스트럭처의 문제 해결이 가능하다. 클라우드 관리자 콘솔은 자원 및 쓰루아웃풋, 서비스 가용성에 대한 모니터가 가능하고, 트렌드 리포트를 통해 자원 소모량의 추세 분석 및 그에 따른 용량계획을 용이하게 한다.


DBaaS with 엔터프라이즈 매니저 12c

엔터프라이즈 매니저 12c는 엔터프라이즈 환경에서 오라클기반의 DBaaS 구현을 위한 최적의 솔루션이다. 광범위하고 다양하게 구축, 배포, 관리가 가능하고, 클라우드의 전체 라이프사이클을 하나의 관리 콘솔에서 가능하게 만들어 준다.


오라클 Application Express(APEX)

<그림13> DBaaS 를 위한 엔터프라이즈 매니저 12c


오라클 애플리케이션 익스프레스, APEX는 오라클 데이터베이스를 지원하는 Rapid Application Development 도구이다. APEX 는 개발자가 수분 안에 어플리케이션을 개발할 수 있게 지원한다. 한번 개발이 완료되었다면, 어플리케이션은 즉시 사용가능하고 비즈니스 목표를 달성하기 위해 쉽게 유지보수 가능하다. APEX 는 PL/SQL이 지원되며, 광범위한기능의 구현이 가능하다. APEX 는 또한 개발 생산성 향상을 위한 여러 기능을 포함하고 있고, 인터랙티브 리포트기능은 비즈니스 유저가 쉽게데이터를 분석하여 결과를 만들어낼 수 있게 해 준다. 이런 APEX 를 오라클 데이터베이스와 연동하여 클라우드 관리서비스 어플리케이션을 개발할 수 있다.


DBaaS 관리 콘솔이 지원하는 기능

<그림14> DBaaS 관리 콘솔, APEX 애플리케이션


<그림15> DBaaS 관리 콘솔, 엔터프라이즈 매니저 12c 클라우드 매니지먼트 팩


<그림14>는 APEX 로 구현한 DBaaS 관리 어플리케이션이며, 오라클 엔터프라이즈 매니저 API 호출을 통해 커스터마이즈 된 DBaaS 서비스 관리를 수행할 수 있다.
<그림15>의 오라클 엔터프라이즈 매니저12c 의 클라우드매니지먼트 팩에서도 동일한 관리가 가능하며, 이런 DBaaS 관리 콘솔이 지원하는 기능들은 다음과 같다.



사용자 등록

서비스 프로바이더와 서비스 소비자의 계정을 등록한다. 등록된 계정을 통해 엔드 유저는 스스로 프로비져닝을소비자는 할당되된 자원에만 접근해야 하므로, 이에 따른 적절할 권한의 분리 및 관리가 필요하다. 오라클 엔터프라이즈 메니저에서는 해당 권한이 미리 설계되어 있고, 즉시 프로바이더와 소비자의 권한을 분리하여 생성이 가능하다.


서비스 카탈로그 관리

서비스 프로바이더와 소비자는 비즈니스/테크니컬 협의를 통해 서비스 카탈로그를 정의해야 하고, 프로바이더가 서비스 카탈로그를 포탈에 등록한다. 다양한 버전, 가용성, 업무 중요도에 따른 서비스 등급이 구분된 카탈로그가 제공 가능하다. 오라클은 고가용성을 위한 Active Data Guard 구성을 포함하는 최고 서비스등급의 카탈로그 설계가 가능하여 미션 크리티컬 업무도 설계 가능하다. Snap Clone 과 결합된서비스 카탈로그를 활용하여 고속 프로비저닝의 활용도 가능하다.


서비스 요청 관리

서비스 소비자는 제공될 클라우드 자원에 대한 일정 할당량을 가지고 있다. 클라우드 자원과 서비스 소비자는 M:1 관계이며, 정해진 량을 초과하는 신규서비스 신청은 프로바이더에 의해 제공 Quota에 대한 확장이 이뤄진 이후에 가능하다. 서비스 소비자가 관리 콘솔에서 업무적 요구사항에 부합하는 서비스 카탈로그를 신청하면, 소비자의 가용 자원 Quota를 확인한 후 그 즉시 프로비져닝이 진행되고, 프로비져닝이완료되면 데이터베이스의 사용이 가능하다.


모니터링 및 리포트

소비자는 운영/관리하는 서비스의 헬스체크 및 자원 모니터링을 수행 할 수 있고, 사용량에 대한 Charge-back 리포트를 확인할 수 있다. BI 퍼블리셔를 활용할 경우 다양한 포맷으로 가공된 리포트의 생성이 가능하다. 프로바이더는 전체 클라우드 자원에 대한 모니터링 및 리포트 관리를 수행한다.


서비스 헬프 데스크

기본적으로 클라우드 소비자가 서비스 관리를 수행하고, 추가적으로 어드민의 운영 관리가 필요한 부분을 요청하고 서비스 받을 수 있다.


승인 및 공지

클라우드 소비자의 요청건을 승인하고, 프로바이더가 공지를 제공하는 용도, 요청내역의 확인 및 이력관리, 프로비져닝 결과를 공지하는 기능이다.


서비스 정책 수립

Self-Service User 에 의해 요청된 서비스를 제공하기 위해서는, 프로바이더가 사전에 서비스 카탈로그 설계와 서비스가 제공될 리소스를 구성해 놓아야 한다. 리소스는 Host,Zone, Pool 순으로 셋업을 해나간다. Host 는 클라우드 서비스를 제공한 H/W 의 등록에 해당하는 부분이고, Zone에서는 하나의 지역적인 클라우드 존을 생성한다. DR을 위한 Zone의 분리 구성을 고려해 보아야 하고, 다수의 데이터베이스와 클러스터를 포함하는 Zone 의 구성이 가능하다. Zone을 구성하면서 CPU 사용율, 메모리 사용율, 데이터베이스 인스턴스 개수의 제한을 둘 수 있다. 생성된 Zone 에 접근할 클라우드 유저를 선정하여, 특정 Zone을 사용할 서비스 사용자들을 할당할 수 있다. Zone 구성이후 하위 자원에 대한 Pool 을 구성할 수 있다. Pool 은 데이터베이스 버전별, 클러스터 여부, 배포 모델 등으로 구분되어 구성되며 서비스가프로비져닝 되는 최소 단위이다.


계정관리와 빌링

DBaaS 관리자, 프로바이더는 제공하는 자원별로 과금정책을 수립할 수 있다. Cpu 사용량, 메모리 사용량, 스토리지 사용량, 기본요금제, 데이터베이스 옵션별 과금 체계, I/O 및 Network 사용량 별, SQL의 수행별로도 과금정책의 수립이 가능하다. 챠지플랜을 다양하게 수립하여 기간별로 구분 적용할 수 있다. 또한 서비스 소비자의 코스트센터를 관리 할수 있어 코스트센터별로 비용관리가 가능하다.


결론

조직은 보다 효과적이고 효율적인 데이터베이스 서비스를 제공하고자 DBaaS를 찾는다. 데이터베이스가 잘 정의되고 자동화된 서비스 배포 모델을 가지고 제공된다면, 비용절감과 서비스 품질 향상의 효과를 기대할 수 있을 것이다. 멀티테넌트 모델을 활용한 어플리케이션의 배포는 자원의 활용도 측면이나 업무의 효율성 향상의 기회가 될 수 있고, 잘 구성된 클라우드 관리 콘솔은 표준화되고 콘솔리데이션 된 데이터베이스 환경에서 운영비용을 절감하고 관리부담을 줄여 효과적인 운영 자동화를 이룰 수 있을 것이다.

오라클의 DBaaS는 전사적 클라우드로 가는 여정에서 보다 효율적인 데이터베이스 서비스의 표준화와 통합화된 플랫폼과 관련한 토탈 솔루션을 제공한다. 오라클 데이터베이스 12c와 오라클 엔터프라이즈 매니저12c를 통해 DBaaS를 도입하는 기업은 서비스의 신속성, 비용절감 효과와 리스크 감소 효과를 기대할 수 있을 것이다.


<그림16> DBaaS의 목표



출처 : 한국오라클

제공 : DB포탈사이트 DBguide.net