Notice»

Statistics Graph

 
 

3. 문단 태그

컴퓨터 활용/홈페이지 과정 | 2013. 1. 28. 21:23 | Posted by 깨비형

1.<p>태그 : paragraph

○ 형식 : <p>, <p> … </p>

○ 설명

- 문단을 나눌 때 사용하는 태그

- 정렬 방식은 left(justify), center, right가 있으며, 기본값은 left를 적용한다.

<p>태그는 연속적으로 사용했을 때 아무리 많이 적어도 한 번만 인정됨



2.<br>태그 : Line Break

○ 형식 : <br>

○ 설명 : 강제로 줄바꿈하는 태그, 마감태그</br>은 없음



3.<pre>태그 : Preformatted text

○ 형식 : <pre> … </pre>

○ 설명 : 문서가 편집되어 있는 모양 그대로 보여준다.



4. &nbsp; 기호 : non-breaking space

○ 형식 : &nbsp;

○ 설명

- 글자와 글자 사이를 띄어 준다.

- 글자와 글자 사이를 많이 띄어주고 싶으면 여러 번 중복해서 사용해야 함



5. 특수문자 입력


특수문자 이름

설명

특수문자 입력 

화면에 나타나는 문자 

less-than symbol

~보다 작다

&lt;

<

great-than symbol

~보다 크다

&gt;

>

ampersand

엠퍼센트

&amp;

&

quotation mark

인용부호

&quot;

"

soft hyphen

하이픈

&shy;

-







'컴퓨터 활용 > 홈페이지 과정' 카테고리의 다른 글

6. <font>태그  (0) 2013.01.30
5. 글자(Text) 태그  (0) 2013.01.30
4. 선그리기와 제목 태그  (0) 2013.01.29
3. 문단 태그  (0) 2013.01.28
2. HTML 태그 맛보기  (0) 2013.01.28
1. HTML의 개요  (0) 2013.01.07

댓글을 달아 주세요

2. HTML 태그 맛보기

컴퓨터 활용/홈페이지 과정 | 2013. 1. 28. 20:22 | Posted by 깨비형

● <head>...</head>부분

    • <head>부분에 삽입되는 내용은 웹 페이지에 그 모습을 드러내 놓지는 않지만, html파일의 각종 중요한 정보를 담아 놓은 곳.
    • 즉, <head>안에 사용되는 내용은 웹 브라우저상에 보여지지는 않지만 문서의 중요정보를 담고 있거나 다른 부분에 스폰서 역할을 담당한다.



◈ <head>...</head>의 특징

    1. html문서에 육안으로 드러나지 않으며, 문서에 직접적인 영향을 주지 않음.
    2. html문서의 구조를 나타내는 곳.
    3. <head>...</head>사이에는 많은 정보를 넣을 수 있다.



● <head>부분에 삽입되는 <title>태그


 기본형식 : <title>...</title>

  설      명 : <title>태그는 웹 브라우저 상단에 사이트의 제목을 보여 주는 태그


※ title 이름 지정 시 주의점(title 이름은 본인의 사이트를 홍보 할 수 있는 훌륭한 마케팅 도구가 되므로 좋은 title 이름을 위해 다음과 같은 점을 주의해야 한다.)

①되도록이면 영어를 잘 모르는 사람을 위해 title이름은 한글로 설정.

②굳이 사이트의 설명을 적고자 한다면 짧고, 명료하게 사이트의 특성을 전달.

③사이트의 브랜드 명을 적는다.

④사이트의 도메인 네임을 한글로 적는다.



● 메모장 실행하는 2가지 방법

①[시작]단추 → [프로그램] → [보조 프로그램] → [메모장]을 클릭

②[시작]단추 → [실행] → [열기: notepad]를 입력한 후, Enter키를 누르면 메모장이 실행

  





'컴퓨터 활용 > 홈페이지 과정' 카테고리의 다른 글

6. <font>태그  (0) 2013.01.30
5. 글자(Text) 태그  (0) 2013.01.30
4. 선그리기와 제목 태그  (0) 2013.01.29
3. 문단 태그  (0) 2013.01.28
2. HTML 태그 맛보기  (0) 2013.01.28
1. HTML의 개요  (0) 2013.01.07

댓글을 달아 주세요

1. HTML의 개요

컴퓨터 활용/홈페이지 과정 | 2013. 1. 7. 13:46 | Posted by 깨비형

● HTML(Hyper Text Markup Language)이란?   

  • WWW(World Wide Web)의 하이퍼텍스트 문서를 만들기 위하여 사용되는 기본언어인 HTML은 문서의 형식(텍스트,글자색,폰트,그래픽,문서이동...)을 정의하는 명령어이며, ASCII문자로 구성된 일반적인 텍스트 파일로 웹 브라우저는 이 HTML언어로 제작된 문서를 해석하여 이용자에게 보여 주게 됩니다. 
  • 즉, HTML은 웹 페이지를 작성하는 프로그램 언어입니다.
  • HTML=TAG 라고 생각할 수 있지만 HTML은 프로그래밍 언어이고 TAG는 개개의 명령어로 다르다.

    


● HTML의 특징 및 주의사항


 1. HTML의 모든 명령어는 ("<"와 ">")를 사용한다.

ⓐ시작태그 : <태그명>

ⓑ마감태그 : </태그명>


 2. 태그는 종류에 따라 3가지가 있다.

ⓐ시작태그와 마감태그가 꼭 필요한 태그

      <html>...</html>  <title>...</title>  <body>...</body>

ⓑ마감태그를 사용하지 않아도 되는 태그

      <p>  <br>  

ⓒ마감태그가 없는 태그

      <img>  <hr> 


 3. HTML은 대.소문자를 구별하지 않는다.


 4. 문서내의 띄어쓰기(Space bar)는 한 칸만 인정된다.


 5. 문서내의 줄바꿈(Enter)은 한 칸만 인정된다.


 6. 작성된 문서 파일의 확장자는 .html 이나 .htm으로 지정한다.


 7. 주석문 처리는 "<!--부연설문-->"로 끝나면 웹 브라우저는 이 부분을 무시하고 넘어간다.


 8. 브라우저에 따라 사용되는 전용태그가 있다.

ⓐ익스플로러 전용 태그 : <MARQUEE>

ⓑ네스케이프 전용 태그 : <BLINK>

ⓒ양쪽 다 적용되는 태그 : 대부분의 태그 사용


 9. 태그의 형식이<태그>...</태그>일 경우, 다른 태그와 구조가 겹치거나 엇갈림이 없도록 한다.

   (예) <H1><B>올바른 태그사용법입니다.</B></H1> ....(0)

    <H1><B>그릇된 태그사용법입니다.</H1></B> ....(X)


 10. HTML 태그를 잘못 사용했다 하더라도 브라우저에서는 에러를 발생시키지 않는다.



● HTML의 기본구조 

 

 <HTML>

   <HEAD>

     <TITLE>여기에 제목이 들어감</TITLE>

   </HEAD>

   <BODY>

                 여기에 실질적으로 웹에서 보여지는 내용이 보여짐(본문내용)

   </BODY>

 </HTML> 


태     그

설                        명 

<HTML>...</HTML>

 html 문서임을 표시하는 태그

 <HEAD>...</HEAD>

 문서의 제목이나 특징,제작자의 정보 등 문서에 관한 정보를 기술

 <TITLE>...</TITLE>

 문서의 제목을 브라우저의 제목표시줄에  표시하는 태그

 <BODY>...</BODY>

 <body>...</body>태그 안에 들어있는 내용이 브라우저에 표시되는 부분이다. 



● HTML에서 알아야 할 기본 용어

 


 ① HTML태그(Tag)

  HTML태그들은 웹 브라우저에게 웹 페이지의 구조와 서식을 알려 준다

  태그는 지정된 명령문과 이것을 둘러싼 꺾쇠(<>)로 구성 되어 있다.

  대부분의 태그는 시작 태그와 끝 태그로 구성되어 두 태그 사이의 텍스트에 지정된 효과를 내도록 한다. 시작 태그만 있는 경우도 있다.

  태그는 대/소문자를 구별하지 않지만 대부분 대문자를 사용한다

  많은 태그들이 옵션을 지정할 수 있는 속성들을 가짐(예를 들어 <FONT>태그는 COLOR라는 속성을 가지고 텍스트 색을 바꾼다.)

  대부분의 속성들은 값을 지정할 수 있다.(예를 들면 COLOR속성에는  Red값을 가질 수 있다.)


 ② 홈페이지(Home Page) 

 

  홈페이지란 HTML형태의 문서로 작성된 것으로, 사용자가 자신의 정보를 다른 사람에게 알려 주는 방법으로, 표현한 기록을 "Web Page"라 하고 "Web Page"의 초기화면을 "Home Page"라 하지만 모든 웹문서(Web Page)를 Home Page라 통용해 부름

  글, 그림, 동화상 등을 이용하여 자신의 홈페이지를 작성할 수 있으며, 이제는 단순한 HTML문서에서 탈피하여 애니메이션,3D등이 지원되는 "자바"등 여러 가지 고급언어들이 등장하여 더욱 화려하고 다이나믹한 웹문서가 표현되고 있으며 앞으로도 계속 발전해 나갈 것


 ③ 웹 브라우저 

 

  웹 페이지는 서로 다른 브라우저들에게 약간씩 다르게 보일 수 있음

  웹 브라우저들은 HTML태그를 해석하는 방법이 약간씩 다르고, 많은 경우 HTML기능들 전부를 지원하지 못하는 경우도 있다.

   또 넷스케이프나 마이크로 소프트와 같은 웹 브라우저 개발 업체에서 자신의 웹 브라우서에서만 사용하는 태그나 속성을 알아보지 못하는 경우도 있으며, 이런 경우 다른 회사의 제품들은 이것을 알아보지 못할 수도 있다. 

  웹 브라우저가 어떤 태그나 속성을 알아보지 못하면 보통 그 정도는 무시된다. 

  이런 태그나 속성들은 일반적으로 HTML표준이 아닌 확장 형태에서 찾아볼 수 있다. 

 

 ④ HTML버전


  HTML은 여러 버전이 존재. HTML 표준이라고도 하는 HTML 정의서(specification)는 지속적으로 업데이트 되며, 몇 년 마다 꾸준히 새로운 HTML 버전이 출시되고 있다. 

  새 버전은 웹 페이지 생성에 있어 좀 더 많은 제어를 할 수 있도록 기능을 추가하는 것이 보통이며, W3C(World Wide Web Consortium)라고 하는 조직에서 HTML 버전을 관리

    

 ⑤ ASCII문자(American Standard Code for Information Interchange) 

 

  아스키는 컴퓨터나 인터넷상에서 텍스트 파일을 위한 가장 일반적인 포맷 

  아스키 파일에서는 각각의 알파벳이나 숫자 그리고 특수문자들이 7 비트의 2 진수(7개의 0 또는 1의 조합으로 이루어진 스트링)로 표현되며, 총 128개의 문자가 정의되어 있다. 

   아스키는 미국규격협회인 ANSI (American National Standards Institute)에 의해 개발되었다. 




 




'컴퓨터 활용 > 홈페이지 과정' 카테고리의 다른 글

6. <font>태그  (0) 2013.01.30
5. 글자(Text) 태그  (0) 2013.01.30
4. 선그리기와 제목 태그  (0) 2013.01.29
3. 문단 태그  (0) 2013.01.28
2. HTML 태그 맛보기  (0) 2013.01.28
1. HTML의 개요  (0) 2013.01.07

댓글을 달아 주세요

[15강] 공공 클라우드

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 16. 14:44 | Posted by 깨비형

1. 공공 클라우드 컴퓨팅 서비스의 필요성

 

  ○ 최근의 ICT 기술 중에 가장 각광 받고 있는 분야 중의 하나가 바로 클라우드 컴퓨팅이다.

 

  ○ 시장조사기관인 IDC의 2009년부터 2013년까지의 클라우드 컴퓨팅 서비스에 대한 전망 보고서에 의하면, 전체 ICT 관련 지출의 10%인 442억 달러가 클라우드 서비스 지출 비용으로 소요된다고 예상하였다.
    ▷ 특히, 클라우드 서비스 관련 매출의 성장세는 다른 전통적인 ICT 제품에 비하여 여섯 배 이상이 될 것 이라고 전망하였다.
    ▷ 또한, 미국, 일본, 영국, 독일 등의 선진국들은 탄소량 배출 감소를 위한 Green ICT의 구현과 예산을 절감하고 새로운 성장 동력을 발굴하기 위하여 클라우드 컴퓨팅 기술을 도입하고 적용하는데 적극적이다.

 

  ○ 이에 비하여 우리나라는 2009년에 이르러서야 정부 및 민간 차원에서 클라우드 컴퓨팅 도입을 위한 움직임에 들어가기 시작하였다.
    ▷ 이와 같은 문제점을 인식하고 정부에서는 클라우드 컴퓨팅과 관련하여 주도적인 역할을 수행하기 위해서 각종 연구와 정책에 대한 수행하고 있다.
    ▷ 본 마지막 강의는 이러한 움직임에 대응하기 위하여, 국가적으로 클라우드 컴퓨팅 기술을 공공부문에 적용할 수 있는 분야를 발굴하여, 적용 가능한 시나리오로 제안하였던 내용을 소개한다.

 

  ○ 선행조건
    ▷ 클라우드 컴퓨팅을 공공부문에 적용하기 위해서는 가장 먼저 선행되어야 할 작업이 바로 관련 법률 및 각종 제도의 정비가 선행되어야 한다.
    ▷ 또한 클라우드 컴퓨팅 환경을 고려한 SLA 관련 표준이 필요하다.
      -  특히 공공부문에 적용하기 위해서는 하드웨어 플랫폼의 경우 공공부문의 제품을 활용하고, 해당 소프트웨어만 민간 업체의 서비스 혹은 솔루션을 사용하기 때문에 이 부분에 대한 고려가 필히 반영되어야 한다.
      - 보안에 관련된 이슈의 경우, ‘공공기관의 개인정보보호에 관한 법률’ 등과 같은 기존의 법률들을 이용해 적용이 가능하나 KISA의 정보보호관리체계인증과 정보보호 안전진단제도 경우에는 정비가 필요하다.
    ▷ 또한, 클라우드 컴퓨팅과 관련된 민간 기업을 육성하고, 좀 더 나은 서비스를 제공받기 위해서는 다양한 업체들의 서비스를 선택할 수 있어야 한다.
      -  이런 환경을 구축하기 위해서는 클라우드 컴퓨팅과 관련된 각종 기반 기술들을 표준화해야 한다.
    ▷ 이밖에도 클라우드 컴퓨팅과 관련된 전문적인 인력을 양성하기 위한 새로운 학과의 신설이나 기존에 존재하는 학과들을 활용한 특화된 전문가 과정 등의 개설을 고려해야 한다.

 

 

2. 공공 클라우드 컴퓨팅 서비스의 유형

 

  ○ 공직자 통합 메일 시스템의 SaaS로의 전환이 필요한 이유
    ▷ 기존의 공직자 통합 메일 시스템의 경우 한번 구축되고 난 후에는 최소 2~3년에서 5~6년 동안은 버그 수정 및 기능 개선만이 이루어지는 경우가 대부분이다. 이와 같이 상업용(실제 사용료는 무료)으로 제공되는 각종 서비스들은 사용자의 요구 및 새로운 기술에 적극적으로 대처하고 있지만, 부처에서 운영하고 있는 메일 서비스들은 몇 년 전의 제품을 사용하고 있는 경우가 대부분이다.
    ▷ 현재, 공직자 통합 메일 시스템의 사용률이 매주 저조하다. 이는 통합 메일 시스템을 구축할 당시에 사용자의 아이덴티티 (기존 메일 주소 사용 보장 여부)를 전혀 고려하지 않았다는 점이다.
    ▷ 정부에서 제공하는 소프트웨어 및 하드웨어에 대한 구성원의 불신감 때문이다. 대부분의 공공 부문의 메일 시스템은 새로운 제품을 도입하는 경우 기존 보관 중의 메일의 전환이 지원되지 않거나, 전환되더라도 불편한 경우가 대부분이었다.
    ▷ 전환을 수행하더라도 기술적인 제약 조건이 거의 없으며, 기존 업무에 큰 영향을 미치지 않기 때문에, 전환을 수월하게 수행할 수 있다. 또한, 클라우드 컴퓨팅 기술의 공공부문 적용에 대한 다양한 적용 결과를 얻을 수 있다.

 

  ○ 공직자 통합 메일 시스템의 SaaS기반으로의 전환 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  사용자 선호도를 조사한다.
      -  Open 메일 시스템 아키텍쳐를 결정한다.
      -  업체 선정 절차를 시행한다.
      -  Private Cloud 기반에 메일 시스템을 구현한다.
      -  개발 완료 테스트를 시행한다.
      -  기존 메일 시스템 이전 작업을 시행한다.
      -  시범 운용을 추진한다.
      -  운용 및 유지보수를 진행한다.

 

 

  ○ 예상 효과 및 문제점
    ▷클라우드 컴퓨팅 전환으로 인한 정부 통합 메일 시스템의 활용도를 증가할 수 있다.
    ▷각 부처 및 공공기관에서 운용하던 메일 서비스의 통폐합으로 인하여 예산 절감의 효과 및 탄소 배출을 줄일 수 있는 그린 ICT 기술의 구현이 가능하다.
    ▷클라우드 컴퓨팅의 도입을 위한 공공부문에서의 최초의 선례를 제시함으로써, 향후 클라우드 컴퓨팅 기술의 도입에 발판을 마련할 수 있다.

 

  ○ 전자결재 및 문서관리 시스템의 SaaS로의 전환이 필요한 이유
    ▷ 정부의 각 부처 및 모든 하위 기관에서 활용 중인 모든 응용 프로그램들 중에서 가장 많이 사용되는 시스템이기 때문에 SaaS 기반으로 전환하는 경우 전환에 따른 파급 효과가 크며, 적용과 관련되어 다양한 경험적인 결과를 얻을 수 있다.
    ▷ 다양한 행정 정보 시스템들 중에서 각 조직별 단위화가 가능한 시스템이다.

 

  ○ 전자 결재 및 문서 관리 시스템의 SaaS기반으로의 전환 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  사업 추진에 따른 기초 예비 조사를 한다.
      -  요구사항 수렴 및 분석을 한다.
      -  Open Document 및 Open 전자결재 시스템 구조를 결정한다.
      -  참여 업체 선정 절차를 시행한다.
      -  광역 ICT 센터 기반의 Private Cloud 형 전자결재 및 문서관리 시스템을 구현한다.
      -  개발 완료 테스트를 시행한다.
      -  기본 문서자료를 이전한다.
      -  시범 운용을 시행한다.
      -  운용 및 유지보수를 진행한다.

 

 

  ○ G-Apps의 정의
    ▷ 각 부처 및 기관을 위한 SaaS 기반의 응용 프로그램들을 민간 기업들이 등록하고, 해당 응용 프로그램을 부처 및 공공기관에서 도입하여 사용하는 형태의 공공부문 전용의 오픈 마켓을 의미한다.

  ○ G-Apps의 구축이 필요한 이유
    ▷ 기존에 활용중인 각종 프로그램을 한꺼번에 SaaS 기반으로 전환하는 것은 기존에 활용중인 응용 프로그램과 다른 형태의 인터페이스로 인하여 구성원의 불편을 야기할 수 있다.
    ▷ 전 세계적으로 공공 부문에서 기존에 사용하던 모든 응용 프로그램을 SaaS로 전환한 사례가 없다. 미국의 경우에도 간단한 응용 프로그램부터 적용하고 있는 단계이다.
    ▷ 현재 수행하고 있는 구매 방식의 경우 정확한 수요 조사 방식이 아닌 단순하게 근무하고 있는 총인원의 수 혹은 보유 개인용 PC의 단순 수량을 기준으로 하고 있기 때문에 일정 부분 예산 낭비에 대한 위험 요소를 내포하고 있다.
    ▷ 사용하지 않는 불필요한 소프트웨어 기능에 대한 예산 소요가 발생하고 있다.

 

  ○ G-Apps의 구축 절차
    ▷아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  G-Apps의 도입에 따른 기초 조사를 시행한다.
      -  G-Apps를 위한 Open Market에 대한 요구사항 수집 및 분석을 시행한다.
      -  G-Apps를 위한 Open Market을 구현한다.
      -  Open Market을 시험하고, 운용한다.
      -  G-Apps 등록 및 도입한다.

 

 

  ○ G-Apps의 구축 에 따른 예상효과
    ▷클라우드 컴퓨팅 도입에 따른 효과에 관한 다양한 연구 결과에 의하면, 기업용 응용 프로그램을 클라우드 컴퓨팅 기술로 5 년간 적용하는 경우 기존 환경에 비하여 1/3 수준으로 비용을 절감할 수 있으며, e-메일과 같은 개인용 응용 프로그램의 경우에도 5배에서 10배에 해당하는 비용 절감을 가져올 수 있다고 한다.
    ▷SaaS 기반의 소프트웨어 적극적은 활용으로 재택 근무의 활성화를 유도할 수 있으며, 엄청난 탄소 절감 효과 및 비용 절감 효과를 가질 수 있다.

 

  ○ GAP의 정의
    ▷ 정보화 프로젝트에 효과적으로 활용할 수 있는 서비스 지향적인 공공부문 개발 플랫폼 (PaaS)인 Governmental Application Development Platform (GAP)을 의미한다.
    ▷ 아마존의 EC2와 S3의 개념을 도입한 것으로서 구축되어 있는 공공 정보 데이터베이스를 활용하여 공공부문과 연관된 각종 서비스들을 누구나 개발하고, 사용 할 수 있도록 지원하는 개발 플랫폼이다.
    ▷ GAP은 SOA 개념을 적용하여, 모든 공공부문의 업무들을 BPM을 적용하여 비즈니스 프로세스들로 정의하고, 비즈니스 프로세스들을 조합하여 사용자에게 서비스를 제공할 수 있도록 지원한다.
    ▷ 지원되는 언어로는 Java와 C++이며, 공통기능 서비스의 경우 오픈 API를 제공하며, GAP을 통하여 생성되는 모든 문서들은 오픈 문서 기반으로 저장된다.

 

  ○ GAP의 구축이 필요한 이유
    ▷ 공공부문의 정보화의 경우 양적으로는 엄청난 성장을 이루었으나, 전자정부 이용실태에 의하면 전자정부서비스의 이용율은 41.1%에 불과한 실정이다.
    ▷ 또한 스위스국제경영개발원의 세계경쟁력보고서에 의하면 우리나라 정부의 행정효율성은 2008년에 37위 등 에 그치는 등 ICT 인프라에 비하여 저조한 평가를 받고 있다.
    ▷ 행정정보와 관련된 정보화 시스템을 설계, 구현하는 경우, 가장 큰 문제는 서비스를 제공 받는 사용자의 입장보다는 개발하는 사람의 관점에서부터 시작되기 때문이다.
    ▷ 국가 정보화 기본 설계 (Natioanl EA)의 부재로 인하여 부처 간의 중복 투자로 인한 예산 낭비 등의 문제가 야기되고 있다.

 

  ○ GAP의 구축 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  클라우드 컴퓨팅 기반의 범국가적인 EA를 수립한다.
      -  요구사항 수집 및 분석을 시행한다.
      -  공공부문의 전 업무에 대한 BPM 시행과 GBP을 도출한다.
      -  기존의 구축된 데이베이스의 통합 및 재배치를 시행한다.
      -  오픈 아키텍쳐 형태의 ESB 기반의 GAP의 설계 및 구축한다.
      -  운용 및 민간부문에 단계적인 개방 절차 시행

 

  ○ 예상 효과
    ▷ GAP은 공공부문 정보 서비스를 개발하는데 필요한 모든 기반 기술을 제공하는 시스템이다.
    ▷ 공공부문 정보 서비스 개발에 필요한 대부분의 핵심 기능들은 GAP에서 오픈 API형태로 제공되기 때문에 모든 정보화 사업의 개발 시간 및 개발 비용의 감소를 유발할 수 있으며, 이로 인하여 예산 절감 효과를 가져 올 수 있다.
    ▷ 공공 데이터베이스와 오픈 API를 활용한 다양한 형태의 공공 부문 정보 서비스들이 개발되게 될 것이다.

 

  ○ K 및 W-Cloud Center의 정의
    ▷ Korea Cloud internet data Center (이하 K-Cloud Center)는 기존의 정부통합전산센터를 클라우드 컴퓨팅 기술을 접목하여 변환한 것을 의미한다.
    ▷ 광역 기반(Wide Area)의 Cloud internet data center (이하 WCloud Center)는 기존의 단위 지방자치단체별로 분산, 관리되었던 모든 시스템을 정부통합전산센터와 비슷한 광역 기반 IDC Center들을 건립한 후, 클라우드 컴퓨팅 기술을 접목하여 변환한 것을 의미한다.

 

  ○ K 및 W-Cloud Center의 구축이 필요한 이유
    ▷ 정부통합전산센터를 구축하여 중앙 부처 및 관련 공공기관의 모든 시스템 자원을 대전 및 광주로 통합하여 운용하고 있으나, 실질적인 통합이 아닌 장소 집약적인 통합만이 이루어져 있기 때문에, 통합에 따른 예산 절감이나 중복 투자 등의 기본적인 문제가 해결되지 않고 있다.
    ▷ 각 지방자치단체 및 기타 공공기관의 경우 각종 시스템 자원을 보관하고 있는 전산실의 열악한 환경 및 체계적인 관리 인력 부족으로 인하여 다양한 위험에 직면하고 있다.

 

  ○ 추진 절차
    ▷ 정부통합전산센터를 클라우드 컴퓨팅 기술을 적용하여 K-Cloud Center로 전환을 수행하고, 이후 모든 시스템 자원의 구매 및 활용은 K-Cloud Center에서 대행한다.
    ▷ K-Cloud Center는 모든 시스템 자원을 통합하여 하나의 거대한 가상 시스템을 구성하고, 가상화 기술을 적용하여 각각의 정보 시스템에 할당하는 방식을 사용한다.
    ▷ W-Cloud Center의 구축은 경기권, 강원권, 충청권, 전라권, 경북권, 경남권 등의 6개 광역권을 기준으로 하여, 각 광역권에 2개의 센터를 두는 방향으로 추진한다.
    ▷ 운영되는 방식은 K-Cloud Center와 동일한 방식을 사용한다.

 

  ○ 예상 효과
    ▷ K 및 W-Cloud Center의 구축으로 인하여 각 부처와 공공기관에서 운용하고 있는 잉여 시스템 자원들의 구매 비용 및 유지보수 비용을 절감이 가능하다. 또한 각 부처 및 공공기관의 갑작스런 시스템 자원의 요구에도 즉각적으로 대처가 가능함으로써 잉여 자원의 미확보로 인하여 발생할 수 있는 위험을 최소화 할 수 있는 장점이 있다. 또한 각 부처 및 공공기관은
각종 시스템 자원을 직접 운영할 필요가 없기 때문에 이에 대한 유지보수 비용을 절감할 수 있다.
    ▷ K 및 W-Cloud Center의 설립은 부처 및 공공기관에서 직접적으로 시스템 자원의 유지보수에 대한 부담을 감소시킬 수 있으며, 또한 관련 직원들을 다른 분야에 재배치할 수 있기 때문에 좀 더 효율적인 인력 활용이 가능하다는 장점이 있다.
    ▷ 전문화된 인력들의 관리로 기존에 비하여 전체적으로 시스템 자원의 운용의 안정성이 향상되고, 갑작스런 장애에도 즉각적이면서도 효과적인 대처가 가능하게 되었다. 또한, 기존의 정부통합전산센터들로만 한정 되었던 각종 데이터베이스들의 분산 백업 작업들이 지역적으로 최소 12군데 이상의 W-Cloud Center로 분산되어 백업되고 관리되고 있기 때문에 훨씬 더
안정적이고 강건한 데이터 백업 시스템을 구축할 수 있게 된다.
    ▷ 각 부처 및 공공기관별로 분산 관리되었던 각종 ICT자원들은 K 및 WCloud Center로 통합 관리된다. 통합 운영에 각 부처에서 개별적으로 잉여 시스템을 따로 준비할 필요가 없기 때문에 전체적으로 보유하는 시스템 자원의 감소를 가져올 수 있으며, 이에 따른 부가적인 효과로써 전체적인 탄소 배출량을 감소시킬 수 있게 된다.

 

  ○ 1단계에서는
    ▷ 관련 법규 및 제도 등을 제정 및 정비를 시행하면서 클라우드 컴퓨팅 기술을 적용하기 위한 1차 시범 사업을 수행한다.

 

  ○ 2단계에서는
    ▷ 1단계에서 시행한 1차 시범 사업을 통하여 얻어진 각종 지식과 경험을 바탕으로 본격적으로 클라우드 컴퓨팅으로 전환하는 사업을 단계적으로 시행한다. 또한, 정부종합센터의 클라우드 컴퓨팅 기반의 인터넷 데이터 센터로의 전환을 수행한다.

 

  ○ 3단계에서는
    ▷ 클라우드 컴퓨팅 기반의 소프트웨어를 공공부문에 판매하고 구매를 수행할 수 있도록 지원하는 "G-Apps"를 구축하며, 서비스 지향 PaaS 플랫폼인 GAP(Governmental Application development Platform)를 구축한다. 또한 2단계에서 시행하였던 클라우드 컴퓨팅 전환 사업을 전 중앙부처로 확대한다.

 

  ○ 4단계에서는
    ▷ 광역 자치 단체 기반으로 각 지방 자치 단체의 모든 서버 및 스토리지 시스템과 같은 시스템 자원을 하나로 통합하여 광역 기반의 클라우드 컴퓨팅 기반의 인터넷 데이터 센터를 구축하며, 서비스 지향 PaaS 플랫폼인 GAP(Governmental Application development Platform)를 구축 활용하는 다양한 프로모션을 진행한다. 또한, 2단계에서 시행하였던 클라
우드 컴퓨팅 전환 사업을 1차 지방자치단체들에게 적용한다.

 

  ○ 5단계에서는
    ▷ 기 구축된 클라우드 컴퓨팅 기반의 인터넷 데이터 센터로 전환된 정부통합전산센터와 광역기반 인터넷 데이터 센터를 유기적으로 통합하여 운영하며, 2단계에서 시행되었던 전환 사업을 모든 자치단체에게 적용하도록 한다. 또한, GAP 및 GAP을 통하여 공공 및 민간 분야에서 제공하는 다양한 공공부문의 서비스를 활용하게 된다.

 

 

3. 클라우드 기반의 스마트오피스 업무환경

 

  ○ 스마트 오피스 정의 : 통신망으로 클라우드에 원격 접속하여 장소에 관계없이 업무를 처리할 수 있도록 하는 것

 

  ○ 스마트 오피스 유형 : 어플리케이션 가상화, 데스크탑 가상화, 클라우드 스토리지 가상화

 

  ○ 스마트 오피스 도입효과 : 언제 어디서든 편리하게 업무처리 가능, 저탄소 업무환경 구현 가능, 외부 정보유출 방지, 관리의 자동화, 효율화 용이

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[15강] 공공 클라우드  (0) 2012.07.16
[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12

댓글을 달아 주세요

[14강] 클라우드 오해

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 16. 10:15 | Posted by 깨비형

1. 클라우드 컴퓨팅 서비스에 대한 오해

 

  ○ 클라우드 컴퓨팅 서비스에 대한 일반인의 다양한 정의와 의식을 갖고 있다. 이는 클라우드가 기업 및 개인의 모든 요구 조건을 만족 시켜 줄 수 있다는 생각과 일부 서비스 제공자의 과대 광고로 오해하고 있다.

 

  ○ 본 장에서는 이러한 클라우드 컴퓨팅 서비스에 대한 오해 할 수 있는 요소들에 대하여 설명한다. 다음의 9가지 요소가 일반적으로 쉽게 오해하고 있는 내용들이다.
    ① 단 한 가지“클라우드 서비스 모델”만 존재한다.
    ② 돈만 있으면 된다.
    ③ 클라우드 서비스는 업무량을 줄여준다.
    ④ 프라이빗 클라우드와 퍼블릭 클라우드 서비스를 아주 매끄럽게 융합시킬 수 있다.
    ⑤ 퍼블릭 클라우드와 프라이빗 클라우드는 영원히 매끄럽게 융합시키지 못하게 될 것이다.
    ⑥ 클라우드 서비스는 항상 비용을 절감시켜준다.
    ⑦ 클라우드 공급업체는 보안을 보장할 수 있다.
    ⑧ 가상 머신을 운용하고 있다면, 클라우드 컴퓨팅을 이용하고 있는 것이다.
    ⑨ 클라우드 컴퓨팅은 기술이 전부다.

 

  ○ 오해 1 단 한가지 "클라우드 서비스 모델"만 존재한다.
    ▷ 클라우드 서비스 모델은 기본적으로는 IaaS, PaaS, SaaS 형태로 나누지만 이외에도 다양한 방식의 모델이 존재한다.
    ▷ 특히 요즘은 하나 이상의 방식이 복합적으로 연동하는 형태로 서비스 하는 곳이 많이 늘어나는 추세다.

 

  ○ 오해 2 돈만 있으면 된다.
    ▷ 각기 시간과 능력이 있는 개발자라면 순수 가상 서버를 구성하는데 아무런 문제도 없을 것이다. 하지만, 사업을 해야 하는 입장에서는 운영체제, 여러 가지 애플리케이션, 그리고 데이터베이스 연결을 설치해서 구성하는 일이 매출 발생에 방해가 될 수도 있다.
    ▷ 그리고 만약에 보안, 데이터 포맷 혹은 양질의 데이터에 대한 표준이 있을 정도의 큰 기업일 지라도, 다른 누군가가 그 일을 해야 하는 것은 마찬가지다.
    ▷ 클라우드 기반 서버가 안전하지 않을 수도 있고, 회사의 표준을 충족시키지 못하거나, 전체 IT 환경에 통합되지 않을 수도 있다.
    ▷ 많은 IaaS(Infrastructure as a Service)가 기업 애플리케이션의 필요성을 충족시켜주지 못하고 있다.
    ▷ 아마존은 최근 자동 확장(Auto-scaling), 감시, 그리고 부하 분산 등이 포함된 새로운 기능의 공개 베타 버전을 발표했다. 하지만, 아마존의 새로운 기능들이 방향은 제대로 잡았으나, 구성 관리, 라이프 사이클 관리 등의 필요 기능은 없는 것처럼 보인다고 평가했다.

 

  ○ 오해 3 클라우드는 업무량을 줄여준다.
    ▷ 장기적으로, 아마 그럴 수도 있다. 하지만 그렇게 되려면, 어떤 클라우드 컴퓨팅 모델이 맞는지, 어떤 애플리케이션 또는 서비스가 안성맞춤인지, 그리고 적정 수준의 보안, 컴플라이언스, 그리고 가동시간을 보장하는 방법 등을 알아내야만 한다.
    ▷ 어떤 업체가 제공하는 서비스나 제품의 성능을 감시하기 위해서는 시간이 들어간다는 것을 명심하라.
    ▷ 상용으로 대량 생산되는 애플리케이션을 운용할 때는, 다중화(Redundancy), 신뢰성, 성능과 지연시간에 대해 많은 생각을 한다. 고객들은 애플리케이션을 클라우드로 이전하기 전에 그런 요구사항들이 충족되고 있는지를 우선 확인할 필요가 있다.
    ▷ 클라우드 기반 시스템들이 자동으로 스스로를 관리하는 이상적인 상황을 “희망 사항”이며, 이를 위한 연구, 개발이 지속적으로 진행되고 있다.
    ▷ 또한, 모든 애플리케이션이 클라우드에 적합한 것도 아니다. 예를 들어 클러스터 서버에 의존하는 애플리케이션들은 다른 고객들과 자원을 공유하는 클라우드 환경에 적합하지 않다. 왜냐하면 이런 애플리케이션들은 동일한 구성의 서버와 서버들 간의 대용량 전용 대역폭을 필요로 하는데, 이를 클라우드 공급업체가 항상 보장할 수는 없기 때문이다. 다시 말하지만, 이런 문제들에 대한 심각한 고려가 사전에 이루어져야 한다.

 

  ○ 오해 4 프라이빗 클라우드와 퍼블릭 클라우드 서비스를 아주 매끄럽게 융합시킬 수 있다.
    ▷ 어떤 클라우드 기획자들은 양쪽의 장점만을 설명하고 있다. 내부 데이터센터가 제공하는 통제권과 클라우드가 제공하는 낮은 가격과 유연성, 거기다가 드래그 앤드롭(Drag and Drop) 애플리케이션, 스토리지, 그리고 요구형 서버까지 존재한다.
    ▷ 특히 내부 데이터베이스에 의존하고 있으며 끊임없이 변하는 액세스 권한을 가지고 있는 수천 명의 사용자를 지원하는 복잡한 다계층(Multitier) 애플리케이션은 정말로 쉽지 않다.
    ▷ 현재 프라이빗 클라우드와 퍼블릭 클라우드 간에 애플리케이션을 이전하기 위해서는 많은 재구성 작업을 수작업으로 해야 하며, 기술적인 문제도 많다.
    ▷ 또한 고객이 프라이빗/퍼블릭 클라우드 양쪽 모두에서 동일한 플랫폼을 사용하고 있다면, 통합작업이 좀 더 쉽기는 하지만, 개방형 가상화 포맷(Open Virtualization Format) 같은 더 복잡한 환경을 위한 표준화 노력은 상호호환성 문제를 덜어주기에는 아직 초보 단계이다.
    ▷ 핵심 요구조건은 양쪽 환경을 지원할 수 있는 보안 인프라 데이터를 복제(Replicate)하거나 프라이빗/퍼블릭 클라우드를 통해서 액세스할 수 있는 안전하고 비용 효율적인 방법, 요구조건에 따라 서비스가 동작하고 있는지, 그리고 그렇지 않을 경우 이를 수리하기 위해 따라야 할 적절한 절차를 보장하는 통합 소프트웨어라고 한다.
    ▷ 내부 클라우드라면, 동일 클라우드 안에 있는 정책 데이터베이스에 액세스할 수 있을 것이나, 민감한 보안 데이터를 외부 클라우드에 호스팅하거나 내부 보안 데이터에 대한 외부 액세스 허용하는 것은 고객들이 꺼려할 수도 있다.

 

  ○ 오해 5 퍼블릭 클라우드 서비스와 프라이빗 클라우드 서비스는 영원히 매끄럽게 융합시키지 못하게 될 것이다.
    ▷ 공급업체들은 하이브리드 클라우드 서비스 모델의 제시와 함께 매끄러운 통합 서비스 제공을 위해 민첩하게 움직이고 있다.
    ▷ 예를 들면, 클라우드 컴퓨팅 서비스 제공 업체는 클라우드 서비스 통합을 12~18개월 내에 이 기능을 고객들에게 제공할 수 있을 것으로 예상하고 있다.
    ▷ 클라우드 컴퓨팅 서비스가 폭넓게 보급되기 전까지는, 퍼블릭/프라이빗 클라우드의 구성 사항, 데이터 모델, 그리고 설치 자동화 정책 등에 대한 표준화 작업을 하라고 권고한다.
    ▷ 표준화 작업을 수행하면, 지금 퍼블릭 클라우드를 활용할 수 있게 해주는 동시에 기술, 표준, 그리고 프로세스가 성숙해 가면 갈수록 두 클라우드 간에 자원을 더 많이 공유 할 수 있는 기반을 만들 수 있다.

 

  ○ 오해 6 클라우드 서비스 모델은 항상 비용을 절감시켜준다.
    ▷ 리눅스 같은 특정 플랫폼을 클라우드에서 운영하면, 비용 절감 외에는 얻는 것이 없다고 주장하고 있다. 전체 데이터센터의 경우에는 그냥 내부에 두는 것이 더 낫다는 것이다.
    ▷ 구글 앱스의 선임 제품 담당 책임자도 고도로 다중화된 아키텍처에서 저가 서버를 사용하여 얻는 절감 효과만을 고려하는 오류를 범했다고 지적했다.
    ▷ 또 다른 구글의 보고서에서 “구글이 자체 애플리케이션용으로 사용하는 것과 동일한 확장성을 갖는 애플리케이션 서버와 데이터베이스”를 사용함으로써 고객들이 별도로 데이터베이스와 애플리케이션 서버를 구매, 설치, 유지보수 그리고 확장하지 않음으로 해서 얻는 추가적인 절감 비용은 언급하지 않았다고 지적했다.
    ▷ 또 다른 예상하지 못한 사항은, 지금과 같은 라이선스 모델과 지원 모델 하에서는 고객들이 소프트웨어를 회사 내부가 아닌 클라우드에 설치함으로써 훨씬 더 많은 비용을 상용 소프트웨어 공급업체들에게 지불할 수도 있다는 것이다.

 

  ○ 오해 7 클라우드 공급업체는 보안을 보장할 수 있다.
    ▷ 클라우드 공급업체가 세상의 모든 보안 인증서를 가지고 있다 하더라도, 사용자의 특정 서버, 애플리케이션 그리고 네트워크가 안전하다는 보장은 없다.
    ▷ 신용카드 업계의 PCI DSS(PaymentCard Industry Data Security Standard:PCI 데이터 보안 표준)를 예로 들면, 소매업자나 신용카드 처리업체는 아마존이나 구글 같은 클라우드 공급업체가 제공하는 플랫폼 상에 자신들의 서버와 애플리케이션이 얼마나 잘 설치되어 있는지를 감사를 받는다.
    ▷ 클라우드 환경을 안전하게 만들기 위해서는 IT를 “외부에서 바라다보는 시각”을 유지해야 하며 사용자가 핵심적인 정보에 액세스하는 가능한 모든 경로에 대한 보안을 확보해야만 한다. 또 각 플랫폼을 보호하는 작업은 그리 어렵지 않았으나, 필요한 모든 보안 기술이 서로 어울려서 동작하도록 하는 작업이 어려웠다고 전해진다.
    ▷ 공급업체가 가령 동일한 데이터베이스에 대한 자신들의 테이블 스페이스(Table Space)를 각 고객들에게 줘버림으로써 비용 절감을 하지는 않았는지를 확인하기 위해서는 아키텍트들이 머리를 맞대고 앉아야 할지도 모른다고 지적했다. 만약 그렇게 되면 고객들이 다른 고객의 데이터를 볼 수 있게 된다.
    ▷ 클라우드 환경에서는 불안정한 네트워크에 가상머신(VM, VirtualMachine)을 연결시켜버릴 수도 있는 새로운 네트워크 카드(NIC: Networ Interface Card) 할당이 실제 환경에서보다 쉽다. 조직의 기존 파이어월은 새 NIC의 존재를 알 수 있는 방법이 없어서 이를 통과하는 트래픽을 감시할 수 없게 된다고 것. 이런 잠재적 위협 때문에 클라우드 공급업체의 보안 인프라를 맹목적으로 신뢰하는 것보다는 독립적으로 평가하는 것이 중요하다.

 

  ○ 오해 8 가상 머신을 운용하고 있다면, 클라우드 컴퓨팅을 이용하고 있는 것이다.
    ▷ 여러 대의 물리적 기기를 아우르는 논리 서버와 스토리지를 생성하는 가상화는 클라우드 컴퓨팅의 필수조건 중 한 가지이다. 하지만 가상 머신을 보유하고 있다는 것이 클라우드 컴퓨팅을 이용하고 있다는 의미는 아니다.
    ▷ 가상화의 모든 이점을 누리기 위해서는, IT 부서나 클라우드 공급업체도 필요에 따라 용량을 확대 또는 축소할 수 있는 능력, 선불 가격정책을 제공해서 사용자들이 필요에 따라 스스로 새로운 서버와 스토리지를 제공할 수 있게 해주어야만 한다.
    ▷ 특히, 특정 업무 전용으로 사전에 구성된 가상 서버 주문 같은 작업을 사용자가 직접 처리할 수 있도록 허용하는 것이 어떤 클라우드 고객들에게는 핵심적인 비용절감 목표일 수도 있다.
    ▷ 하지만 이런 셀프서비스는 VM웨어 Infrastructure 같은 소프트웨어를 운용한다고 해서 자동적으로 일어나지는 않는다.
    ▷ 예를 들면, 지멘스는 사용자들이 필요에 따라 프라이빗 클라우드에서 주문할 수 있는 가상 서버와 관련 서비스에 대한 표준 카탈로그를 만들기 위해“상당한 투자”를 해야만 했다.

 

  ○ 오해 9 클라우드 컴퓨팅은 기술이 전부다.
    ▷ 기술은 클라우드 컴퓨팅을 가능케 했다. 하지만, 비용 절감과 유연성을 실현하기 위해서는 제대로 된 프로세스도 필요하다.
    ▷ 클라우드 컴퓨팅의 기반이 되는 가상화는 고객들이 데이터와 애플리케이션을 물리적인 서버들 간에서 이동할 때에 매우 역동적으로 지원하고 있다. 아주 빈번하게 변경이 이루어진다면 지금 필요한 것은 이런 이동을 부드럽게 관리할 수 있는 능력이다.
    ▷ 실제로 이런 기능이 있으면 관리되지 않는 물리적 서버에서처럼 전기, 냉방 그리고 관리 시간을 잡아먹고 보안 상의 위협까지도 야기할 수 있는 미사용 또는 저사용 가상머신의 창궐을 막을 수 있다.
    ▷ 반면에 클라우드에서 표준 프로세스를 사용하면, 효율성이 증가한다. 가상화 같은 기술과 ITIL(Information Technology Infrastructure Library) 관리 프레임워크를 함께 사용함으로써, IT 관리와 행정 업무를 25~30% 까지 줄여줄 수 있다고 보도 되고 있다.

 

  ○ 클라우드 컴퓨팅 서비스에 대한 진실
      남은 것은 무엇인가? 클라우드는 근심 걱정 없는 마법의 컴퓨팅 나라가 아니라 이해와 제대로 관리하기 위한 힘든 일이 수반되는 복잡한 자원이라는 사실. 그리고 이건 오해가 아니다.

 


2. 소규모 기업이 클라우드 서비스를 이용하는 이유

 

  ○ 웹 사이트 호스팅부터 이메일, ERP까지 IT 기능을 아웃소싱 하는 것은 기업 규모에 관계없이 오래 전부터 보편화되어 왔다. 하지만 데이터베이스 서버나 파일 서버, 문서 스토리지, 애플리케이션 개발 등 중요한 IT 기능을 아웃소싱 하는 것에는 많은 기업들이 주저하고 있다.

 

  ○ 경험이 많은 IT 관리자는 최근 빈번하게 일어나는 서비스 중단이나 데이터 손실, 해킹 사건 등을 지적하며, 이로 인해 생산성 손실은 물론 소송이나 벌금, 심지어 기업의 파산으로 이어질 수 있다고 강조한다.

 

  ○ 하지만 기업 파이어월 외부로부터 얻을 수 있는 저렴한 비용의 인프라와 설비, 관리, 그리고 더 나은 서비스 가용성 등을 통해 얻을 수 있는 본질적인 이점이 있다는 것은 무시할 수 없는 사실이다.

 

  ○ 소규모 기업에서 클라우드 서비스로 현실화할 수 있는 절감 요소를 짚어본다.

 

   1. 인프라 절감
    ▷ 내부 IT 서비스를 위해 새로운 서버나 운영체제, 애플리케이션을 구매하는 대신 클라우드 서비스 업체에 매월 요금을 지불하기만 하면 된다.
    ▷ 운영체제와 애플리케이션을 갖춘 서버 한 대의 비용이 수천 달러에서 수만 달러에 이른다는 점을 생각하면, 엄청난 이점이 될 수 있다.
    ▷ 특히 전면적인 도입 전에 새로운 서비스를 테스트해 보고자 한다면, 이점은 더욱 커진다.

 

   2. 환경 설정과 관리 절감
    ▷ 만약 IT 직원이 새로운 운영체제와 애플리케이션에 익숙하지 않다면, 새로운 기능을 도입하는 것은 길고 힘든 과정이 될 수 있다.
    ▷ 클라우드 서비스 업체는 특정 애플리케이션을 지원하는데 있어서는 경험이 풍부한 관리자이다.
    ▷ 이것이 클라우드 기반 ERP가 인기있는 이유 중 하나이다.
    ▷ ERP는 도입이 까다롭기로 악명이 높은데, 하드웨어와 소프트웨어 모듈을 함께 돌아가게 하는 것도 어렵고, 소프트웨어를 적절하게 설정하는 것도 어렵다.
    ▷ 경험이 풍분한 인력을 갖춘 서드파티 클라우드 업체에게 모니터링이나 새로운 계정 설정, 패치 적용 같은 일상적인 업무는 너무나 쉬운 일이다.

 

   3. 설비 절감
    ▷ 클라우드 서비스 업체는 대규모의 현대식 데이터센테에 친환경 기능까지 갖추고 있으며, 이런 인프라를 여러 기업 간에 공유시켜 주기 때문에 같은 규모의 설비를 운영한다고 해도 클라우드 서비스 업체가 훨씬 더 저렴한 비용으로 운영할 수 있다.
    ▷ 여기에 일반적인 기업의 서버 활용도를 감안하면 격차는 더욱 커진다.

 

   4. 더 나은 성능과 기능
    ▷ 클라우드 서비스 업체는 다양한 기업에 서비스를 제공하기 때문에 대용량 고성능 시스템을 구매한다.
    ▷ 이들 시스템은 소규모 기업이 내부적으로 구동할만한 시스템보다 훨씬 성능이 뛰어나다.
    ▷ 또한 대부분의 소프트웨어 버전과 사이트 라이선스를 가지고 있기 때문에 소기업이 내부적으로 확보할 수 있는 것보다 더 저렴한 비용으로 기능을 이용할 수 있다.
    ▷ 또한 한두 명에 불과한 소기업의 IT 인력과 비교할 때, 성능을 최적화하는 방법을 더 잘 아는 인력을 보유하고 있을 가능성이 높다.

 

   5. 기업의 민첩성 향상
    ▷ 클라우드 서비스 업체는 쉽고 빠르게 서버와 서비스를 추가할 수 있으며, 이를 기업 내부 사용자뿐만 아니라 외부의 계약업체나 협력업체, 고객에게도 제공할 수 있다.
    ▷ 이는 소규모 기업이 내부적으로 구현하기 어렵거나 불가능한 수준의 유연성을 제공해, 소규모 기업의 고객의 요구나 핵심 비즈니스의 변화에 더 신속하게 대응할 수 있도록 해 준다.

 

   6. 장애 대비도 강화
    ▷ 클라우드 서비스 업체는 여러 곳의 데이터센터와 각 데이터센터마다 여러 회선의 인터넷 접속을 갖추고 있다. 물론 데이터센터 간의 데이터 복제도 지원한다.
    ▷ 여기에 더해 데이터 보호 수준도 높다. 단순 야간 백업을 넘어 지속적인 데이터 보호, 정전에 대비한 발전기, 특정 부품이 고장나도 돌아가는 고성능 서버 등을 갖추고 있다.

 

  ○ 이외에 여러 가지 이점을 언급하지 않더라도 클라우드 서비스가 제공하는 이점은 환상적이다. 물론 이런 이점은 클라우드 서비스 업체에 문제가 생겨 데이터가 손실될 가능성으로 상쇄될 수 있다. 하지만 이런 위험은 장애에 대비한 옵션을 추가하는 것으로 균형을 맞출 수 있다. 예를 들어 다른 클라우드 서비스 업체에 데이터를 백업하는 등의 방법을 이용할 수 있다. 마지막으로 클라우드로 이전하고자 하는 애플리케이션이 만에 하나 문제가 생겼을 때 비즈니스에 어떤 영향을 미치는지를 계산해 보아야 할 것이다.

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[15강] 공공 클라우드  (0) 2012.07.16
[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12

댓글을 달아 주세요

[12강] 가상화 엔진

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 15. 19:16 | Posted by 깨비형

1. 가상화 엔진의 개념


  ○ 가상화 엔진

    ▷ 가상액세스(Virtual Access), 가상관리(Virtual Management), 가상자원(Virtual Resources) 의 3가지 모두에 대한 점진적인 향상이 이루어질 수 있는 기본 서비스를 제공한다.

    ▷ 여기에는 모든 지원 플랫폼들에 걸쳐서 공통된 가상화 역량을 제공하는 핵심 컴포넌트들 뿐만 아니라 플랫폼에 고유한 가상화 역량 및 확장성이 포함되어 있다.

    ▷ 아래 그림은 가상화 엔진 플랫폼의 기본 개념도 이다


  ○ 가상화 엔진 (플렛폼)의 목표

    ▷ 중요한 목표 중 하나는 모든 플랫폼에 걸쳐서 공개 표준의 사용자 요구의 지원을 위한 기반을 제공하는 것이다.

      - 가상화 엔진 플랫폼에서 제공되는 기능들은 오픈 인터페이스와 산업표준 체계를 사용함으로써 서드파티 (Third Part) 제품들도 상호 작동될 수 있도록 해준다.

      - 상호 연동성을 기반으로 설계된 플랫폼은 점진적으로 더 높은 수준의 비즈니스 지향의 관리 솔루션을 구축하기 위한 빌딩 블록으로서의 집합체의 성격을 본질적으로 가지게 된다.

    ▷ 또 다른 주요 목표는 사용자의 경험을 단순화시키는 것이다.

      - 초기의 관심사는 사용자들로 하여금 가상화를 주요한 관리 전략의 하나로써 좀 더 적극적으로 적용할 수 있도록 도와주어서 사용자들로 하여금 가상화 환경을 시각화하고 제어하는 것을 수월하게 해주는 것이다.

      - 가상화 엔진 플랫폼은 관리의 중앙 집중화와 자원들이 서버 플랫폼들에 걸쳐서 관리되는 방식에 있어서 일관성을 제공한다.

    ▷가상화 엔진 플랫폼은

      - 가상화에 대하여 진화하는 접근방법을 제공한다.

      - 고객들은 워크로드 관리, 자원의 발견 및 기타 등에 있어서 단순한 물리적 분할에서부터 진보된 형태의 소규모 분할에 이르기까지 다양한 방법으로 가상화의 도입을 시작할 수 있으며, 관리되는 가상화 환경의 범위는 하나의 하드웨어 박스에서부터 혼합 애플리케이션을 구동하는 멀티티어(multi-tier) 이기종 서버들의 집합 등으로 다양할 수 있다.

    ▷ 가상화에 대한 고객들의 투자는 

      - 다수의 시스템이 뭉친 스케일-아웃 형태에서 물리적으로 통합된 시스템인 스케일-업 형태로 나아갈수록 더욱 더 투자보호 효과가 높아진다.

      - 같은 종류의 가상화 서비스가 사용되어지므로 어떤 플랫폼으로 이전되든지 간에 기존의 관리 및 보안 부분을 새로 교체할 필요가 없어지게 된다.

    ▷ 간단히 가상화 엔진에 있어서 

        • 가상 관리 및 가상 액세스 서비스의 전반적인 개요와 구성요소들을 알아보고 향후 어떠한 모습으로 발전할 것인가를 간략히 살펴보기로 한다.


       1) 가상 관리(Virtual Management)

    ▷ 가상 관리 서비스에는 아래와 같이 고객들이 가상 시스템의 운영을 단순화하고 최적화시킬 수 있도록 도와주는 3가지 제품 요소들이 포함되어 있다.

        • Enterprise Workload Manager (EWLM)

        • Resource Dependency Service (RDS)

        • Director

(가상관리를 위한 가상화 엔진의 전체적인 그림)


  ○ EWLM을 이용한 전사적 워크로드 관리 방법

    ▷ EWLM은 오픈소스 기반의 애플리케이션 응답 측정용 표준(ARM, Application Response Measurement)을 사용하여 수행되고 있는 애플리케이션으로부터 성능 데이터를 얻는다.

      - ARM 표준을 지원하는 제품과 벤더는 빠르게 증가하고 있으며,

      - 이중에서 대표적인 제품으로는

      - 웹스피어 애플리케이션 서버(WAS), 

      - DB2 UDB,

      - 아파치 웹서버,

      - 마이크로소프트의 IIS 서버 그리고

      - 웹스피어 MQ

      - JMS 메시징 등이 있다.

    ▷ 워크로드 매니저에서 소개된 개념을 확장한 EWLM은 널리 인증된 기술을 적용하여 멀티 티어, 이기종 환경에서 사용자가 정의한 서비스 레벨 목표를 달성하기 위하여 워크플로우를 모니터링하고 관리해준다.


  ○ EWLM을 이용한 전사적 워크로드 관리 방법

    ▷ 아래 페이지 그림처럼 워크로드 관리는 개별 서버수준 WLM에서 파티션들간의 PLM을 거쳐서 전체 IT 인프라에 걸친 워크로드 개념인 EWLM으로 개념적으로 나 기술적으로 발전을 거듭해 오고 있다.


   ○ 자원 관계 서비스(RDS : Resource Dependency Service)

    ▷ 오늘날 IT 매니저가 당면하고 있는 주요한 이슈들 중의 하나인, 어떤 자원들이 존재하며 어떻게 이들 자원들이 서로 연관 지어져 있는가에 대한 이슈들을 다룬다 . RDS에 대한 전략은 스스로 표현 가능(selfdescriptive) 인프라스트럭쳐 컴포넌트(Manageable Resources라고도 불림) 에서 제공되는 정보를 사용하여 토폴로지를 구축하는 것이다.

    ▷ 관리 가능한 자원이 공식적으로 나오기 전까지 RDS는 다양한 기술들을 사용하여 기존 애플리케이션, 도구 및 IT 시스템들로부터 자원과 관계 데이터를 발견 및 추출할 것이다. RDS는 공개 표준을 사용하여 자원의 상태를 표시하며, 관리 가능한 자원들을 액세스하고 관리하는데 업계 표준을 활용하기 위해 지속적으로 진화 할 것이다.

    ▷ 따라서 RDS가 제공하는 서비스는 관리 가능한 자원이 기반이 되는 시스템 관리의 발전에 대한 첫걸음이 된다.

    ▷ 아래 그림은 RDS의 전체적인 개념을 쉽게 이해할 수 있도록 보여주고 있다.

      - 가상화 엔진에서 RDS는 기업 내에 존재하는 자원들간의 관계 및 의존성, 자원들의 속성 및 상태에 대한 정보를 그래픽한 뷰로 구축해주는 토폴로지 서비스를 제공한다.

      - 이러한 토폴로지는 가상화 엔진 콘솔 상에 표시된다.


   ○ 관리자 (Director)

    ▷ 가상화 엔진 플랫폼에서 Director는 하나의 단일 콘솔에서 IT 관리자는 원격지 시스템의 하드웨어 구성을 상세히 살펴볼 수 있고 프로세서, 디스크, 메모리와 같은 핵심 요소들에 대한 사용량과 성능을 모니터링 할 수 있다.

    ▷ 서버 시스템 기반 위에 하드웨어 및 가상 파티션을 관리할 수 있는, 공통되고 일관된 솔루션을 제공해준다. 고객들은 Director를 이용하여 분산된 환경에서 서버 및 저장공간 등을 원격 관리 콘솔을 구동시킴으로써 일괄적으로 관리할 수 있게 됨으로써 플랫폼에 고유한 관리 노력과 복잡한 인터페이스를 제거시켜 준다.

      - 따라서 자원 발견, 이벤트 로그 및 액션 플랜, 파일 전송, 인벤토리 수집, 프로세스 관리, 자원 모니터링 및 한계치 등을 포함한 수많은 이전의 수작업들이 자동화 되어진다.

      - 경고와 관련이 깊은 예측적이고 사전 대응적인 관리 기능들과 실시간 시스템 진단 기능은 서버의 가용시간을 최대화하고 다운타임으로 인한 비용을 최소화시켜 준다.


      2) 가상 액세스(Virtual Access)

  ○ 가상 액세스(Virtual Access) 서비스는 가상화된 자원들에 대하여 시각적인 면과 프로그래밍 측면 2가지 모두에서 일관된

인터페이스 액세스를 제공해준다.


  ○ 여기에는 아래의 3가지 요소가 포함된다.

       - VE Console,

       - Programmatic Interfaces,

       - 관리 가능한 자원(Manageable Resources)


  ○ VE 콘솔(VE Console)

    ▷ VE Console은 기업 수준에서 가상화된 인프라스트럭쳐에서 자원들을 관리하기 위한 웹 기반의 단일 인터페이스를 제공해준다.

    ▷ 대표적인 기능으로는 헬스 센터와 단일 지점 관리 두 가지를 꼽을 수 있다.

      - Health Center : 분산된 시스템과 스토리 관리 환경에 걸쳐서 모든 시스템 자원들의 헬스에 대한 통합 뷰 제공

      - 단일 지점 관리 : 가상화 엔진의 다양한 기능들과 Director를 포함하여 서버 시스템, 애플리케이션 및 스토리지 관리 콘솔을 수행할 수 있는 하나의 장소 다양한 관리 시스템들로부터 얻은 자원 정보를 이용해서 헬스 센터는 실시간으로 자원의 상태와 헬스를 그래프와 차트 형태로 나타내 준다. 관리자는 상태를 모니터링하고, 경고 정보를 받아서 문제 상황을 심도 있게

파헤치고, 적합한 조치를 취하고 다른 주요 시스템과 스토리지의 관리 기능을 헬스 센터를 통해 수행할 수 있다. 관리자는 또한 RDS를 통해 들어온 자원의 토폴로지 정보를 봄으로써 자원의 관계와 의존성을 이해할 수 있게 된다. 헬스 센터와 토폴로지 지원은 다른 콘솔을 실행할 수 있는 능력과 결합되어지면 구체적인 OS 지식이 없어도 어느 정도 개별적인 OS 관리를 할

수 있게 도와준다.


  ○ Programmatic Interfaces

    ▷ 가상화 엔진 플랫폼 서비스는 웹 서비스 기반의 SOA 접근방법을 이용하여 개발되었다.

    ▷ 표준 기반의 컴포넌트 수준의 인터페이스를 사용함으로써 가상화 엔진의 서비스는 어디서나 상호 연동성을 가지게 되었다.

    ▷ 하드웨어 및 소프트웨어 벤더들은 가상화 엔진의 이러한 서비스를 포함하거나 확장 또는 개발하여 재사용할 수 있게 된다.

    ▷ 가상화 엔진 플랫폼 서비스는 리소스 모델, 프로파일 및 액세스 프로토콜을 관장하는 프로그래밍 가능한 인터페이스를 사용할 수 있도록 진화하기 시작했다. 그러한 표준들에는 아래와 같이 3가지 레벨이 있다.

         웹 서비스 접근 인터페이스

         웹 서비스 지원 모델로 맵핑 인터페이스

         자원 모델링 인터페이스


  ○  관리 가능한 자원  (Manageable Resources)

    ▷ 가상화 엔진 서비스는 관리 가능한 자원을 이해하는 것이 많은 도움이 된다. 관리 가능한 자원이란 가상 인프라스트럭쳐의 빌딩 블록으로써 전사적 차원에서 자원이 발견되고 공유되며, 관리되어지고 프로비져닝 되어지도록 해주는 핵심 요소이다.

    ▷ 오늘날 시스템 자원들은 전형적으로 각기  독립적인 관리도구와 애플리케이션들에 의해 관리되고 있다. 관리 가능한 자원은 이러한 장애들을 극복하는데 도움을 준다.

    ▷ 자원 관리를 위해 업계 공개 표준인 웹 서비스를 이용하여 형성된 각각의 관리 가능한 자원은 해당 자원을 발견, 확인, 관리 및 사용하기에 필요한 정보를 자체 내에 내재하고 있다, 실제로 각 자원은 호출 가능한 서비스가 된다고 볼 수 있다.

 예를 들어 시스템 관리 애플리케이션은 웹 서비스를 사용해서 어떤 스토리지에 있는 데이터를 다른 스토리지로 옮기거나 OS를 리부팅 할 수 있다. 관리 가능한 자원은 그것이 나타내는 자원과의 상호 작용을 다룰 수도 있다. 자원에 대하여 작동할 뿐만 아니라 애플리케이션은 웹 서비스를 사용하여 자원들 간의 상세한 구성 정보, 상태 및 관계 등을 발견, 확인, 획득 및 이해할 수 있게 된다. 관리 가능한 자원들은 또한 그래픽컬한 사용자 인터페이스를 제공해준다.

    ▷ 아래 그림 처럼 관리 가능한 자원들은 시스템 자원들에 대한 스마트한 가상적 표현으로써, 벤더와 플랫폼에 중립적이면서 자기 스스로 표현할 수 있는 컴포넌트들이며, 어떤 애플리케이션에서도 표준 웹 서비스를 통해 동일한 방식으로 접근 및 사용될 수 있다.



      3) 가상화 엔진 플랫폼의 미래 발전 전망

         - 프로그래밍 가능한 인터페이스 사용의 확장과 관리 가능한 자원 풀의 구축에 더하여 한층 더 진보된 가상화 기술은 향후 가상화 엔진 플랫폼을 통해 모습을 드러낼 것이다.

         - 여기에 덧붙여 결함 또는 장애가 발생하더라도 최소한의 중단(초/분, 애플리케이션 종류에 따라) 후에 안정화된 재 시작을 모니터하고 관리할 수 있는 기능이 제공될 것이며, 애플리케이션을 다른 서버(또는 같은 서버내의 다른 파티션으로)로 옮겨갈 수 있는 기능도 함께 제공될 계획이다.

        - 이러한 통합 과정은 진보된 서비스와 자원들은 공개 표준의 웹 서비스 인터페이스를 통해 외부로 드러날 것이며, 비즈니스의 연속성과 진보된 가상화 기능 및 스토리지와 서버의 혁신적인 기능들이 하나로 통합되어 활용될 것이다.


  ○ 아래 그림 같이 다양한 서버의 가상화 기술을 연결하고 재사용하는 시스템 디자인에 대한 전체적인 접근을 통해 이루어질 것이며, 서비스 기반의 협업 프로세싱 인프라스트력쳐를 지원하는 미들웨어 소프트웨어와 하드웨어가 근본 바탕을 이룰 것이다. 



  ○ 우리는 지금까지 가상화가 무엇이며, 가상화가 왜 중요하며 그리고 어떤 기술들이 현재 또는 조만간에 사용 가능한지 살펴보았다. 또한 다양한 업계 선도적 가상화 기술들과 이와 관련된 가상화 오퍼링인 가상화 엔진에 대하여 또한 간략히 살펴보았다.

    ▷ 이를 통해 우리는 가상화가 새로운 것은 아니라는 결론을 얻을 수 있다. 왜냐하면 기존 자원들로부터 더 많은 것을 얻을 수 있도록 해주는 혁신적인 서버, 네트워크 및 스토리지 가상화 제품을 지속적으로 제공해 왔기 때문이다.

    ▷ 또한 기업들은 그동안 가상화를 통해 증가된 활용률, 더 높아진 가용성 및 확장성, 더 커진 유연성 및 더 낮아진 IT와 관리 비용 등의 혜택을 얻어 왔기 때문이다.

    ▷ 이제 협업 처리가 중요시되는 시기가 도래하게 되면 많은 기업들은 점차 복잡해지고, 고비용을 요구하면서도, 온 디맨드 비즈니스를 위한 핵심적인 역량인 상호 연동성과 유연성은 부족한 기존의 IT 환경으로는 새로운 비즈니스 환경을 감당할 수 없음을 직관적으로 깨닫게 될 것이다.

    ▷ 따라서 기업들은 진보된 가상화 역량들을 활용함으로써 기업들은 단순화되고 유연한 IT 인프라스트럭쳐를 이룰 수 있다.

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[15강] 공공 클라우드  (0) 2012.07.16
[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12

댓글을 달아 주세요

[11강] 스토리지 가상화

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 13. 17:01 | Posted by 깨비형

1. 스토리지 가상화

 

  ○ 스토리지 가상화
    ▷ 스토리지 사용의 엄청난 증가 추세는 매일 매일의 스토리지 운영 및 데이터 관리에 많은 부담을 증가시켜왔다.
    ▷ 결과적으로 가용성과 프로비져닝에 대한 서비스 레벨을 만족시키는 것이 커다란 과제로 다가오고 있다.
    ▷ 이러한 부담을 없애기 위해서 기업들은 디스크와 테이프 스토리지 가상화 기술에 눈을 돌리기 시작했다.
    ▷ 스토리지 가상화는 온 디맨드 전략의 필수적 일부분으로써 애플리케이션에 거의 또는 전혀 영향을 미치지 않으면서도 하드웨어 인프라스트럭쳐에 변경을 가할 수 있게 해준다.
    ▷ 그럼으로써 관리를 용이하게 하고, 애플리케이션의 가용성을 증가시키고, 총 소유 비용을 낮출 수 있게 해준다.
    ▷ 스토리지 가상화의 4가지 주요한 형태로 분류 할 수 있다.
     1) 디스크 컨트롤러 가상화
     2) SAN 상의 스토리지 블럭가상화
     3) 파일 가상화
     4) 테이프 가상화

 

   1) 디스크 컨트롤러 가상화 (Disk Controller Virtualization) :
    ▷ 디스크 컨트롤러 가상화는 스토리지 서브시스템 또는 컨트롤러를 파티션으로 나누어 마치 여러 개의 스토리지 컨트롤러가 있는 것처럼 보이게 해준다.
      - 예를 들어, IBM의 System Storage DS8000 계열이 이런 기능을 제공한다.
    ▷ 예를 들어 아래 그림 처럼 디스크 컨트롤러 1개가 3개의 가상 스토리지 컨트롤러로 파티션 되어서 하나는 OLTP 워크로드를 수행하고, 하나는 BI(Business Intelligence) 워크로드를 수행하고 마지막 나머지 하나는 e-메일 서비스를 수행할 수 있다.
    ▷내부적으로는 논리적 파티셔닝(LPAR) 기술을 사용해서, 어떤 가상 디스크 컨트롤러의 성능이 다른 어떤 가상 디스크 컨트롤러가 수행하는 워크로드로부터도 영향을 전혀 받지 않게 해준다. 표준 애플리케이션을 하나 또는 그 이상의 파티션 자체에서 수행할 수 있게 된다.

 

   2) SAN 상의 스토리지 블럭 가상화
    ▷ 대부분의 사람들이 스토리지 가상화를 이야기할 때, 주로 SAN 상의 스토리지 블록 가상화를 가리킨다고 보면 된다.
      - 이러한 형태의 가상화는 사용자로 하여금 제각기 물리적으로 다른 스토리지 컨트롤러에 들어있는 유휴 디스크 조각을 모아서 가상 디스크를 생성할 수 있게 해준다.
      - 예를 들어 어떤 관리자가 디스크 컨트롤러 A로부터 300GB의 유휴디스크를, 컨트롤러 B로부터는 500GB를, 컨트롤러 C로부터는 200GB의 유휴 디스크를 모아서 1TB의 가상 디스크를 생성할 수 있다.
      - 결국 스토리지 블록 가상화는 제각기 다른 스토리지 컨트롤러들로부터 작은 용량의 유휴 디스크 공간을 모아서 하나의 큰 디스크 풀을 만들어서 어떤 서버도 사용할 수 있게 만들고, 디스크 스토리지의 활용률을 획기적으로 향상시킨다.
    ▷ 블록 가상화는 3가지 방법이 있다.
      - 어플라이언스 형태(예, IBM SAN Volume Contoller 또는 IBM SVC)
      - 지능적인 SAN 스위치(예, EMC의 Invista)
      - 스토리지 컨트롤러 자체에 임베디드된 형태(예, 히타치의 TagmaStore)
    ▷ 어플라이언스 또는 스위치는 서버와 스토리지 컨트롤러 사이에 위치한다.
    ▷ 임베디드된 가상화는 서버들과 다른 스토리지 컨트롤러 사이에 존재한다.
    아래 그림은 스토리지 블럭 가상화의 구조도 이다.


    ▷ 구조
      - 스토리지 가상화 솔루션들은 모두 가상 디스크에서 실제 디스크로의 위치에 대한 맵핑을 유지한다.
    ▷ 가상화 방법
      - 맵핑을 통해 하나의 물리적 위치에 대응하고 있는 가상 디스크를 다른 물리적 위치로 이동하여 대응 시킬 수 있다.
      - 이 때 서버 및 애플리케이션은 서로에게 아무런 영향을 끼치거나 받지도 않으면서 정상적으로 작동된다.
    ▷ 장점
      - 이러한 기능으로 인해 스토리지 관리자는 애플리케이션의 가용성에 아무런 영향을 미치지 않고서도 서버에서 스토리지의 데이터 맵핑을 자유롭게 재구성할 수 있게 해준다.
      - 블럭 가상화은 전체 기업 내에 걸쳐서 일관된 방법으로 서버들이 필요로 하는 고급 기능을 제공할 수 있다.
       ·예를 들어, 모든 서버들에 대하여 동일한 방법으로 스냅샷 카피 또는 리모트 카피와 같은 카피 서비스 기능을 제공할 수 있다.
      - 서버들은 수많은 스토리지 컨트롤러들 대신에 하나의 SAN 상의스토리지 가상화 솔루션하고만 인터페이스를 유지하면 된다.
      - 또한 사용자들은 각 스토리지 컨트롤러마다 하나씩 제공되는 디바이스를 모두 올릴 필요도 없이 단지 하나의 디바이스 드라이버만 로딩하면 된다(실제로 각 디바이스 드라이버 간에 충돌 여부가 발생하기도 한다).

 

   3) 파일 가상화
      - 파일 가상화는 이기종 서버간에 진정한 의미의 파일 공유를 가능하게 한다.(아래 그림 참조)
      - 즉 파일 가상화 기술을 이용함으로써 기업 내의 어떤 컴퓨터 또는 어떤 서버로부터라도 동일한 파일 네임을 사용하여 공통된 파일 그룹에 대한 접근이 가능하다.
       · 예를 들어, 파일은 리눅스가 돌아가는 컴퓨터에서 생성되었지만 윈도우가 돌아가는 다른 서버에서 동일한 파일 네임을 가지고 접근이 가능하다.
       · 이렇게 되면 서로 다른 서버들간에도 HA(Hardware Address)를 위한 클러스터가 가능할 수 있게 된다. 


   4) 테이프 가상화
    ▷ 테이프 가상화는 아래 그림 처럼 디스크를 이용하여 테이프 드라이브 자원인 것처럼 에뮬레이션 함으로써, 서버입장에서는 테이프 드라이브로 데이터를 백업 받는다고 간주하지만 실제로 디스크로 데이터를 백업 받게 되는 것이다.
    ▷ 또한 데이터의 일부분이 테이프에 비해 좀 더 빠른 하드디스크스토리지 캐쉬에 저장되기만 해도 마치 전체 데이터가 테이프 카트리지에 전부 저장된 것처럼 보이게 해주는 방식을 통해 데이터를 고속으로 백업 받을 수 있게도 해준다.

  ○ 네트워크 가상화
    ▷ 애플리케이션이나 서버를 네트워크 또는 다른 가상 자원들에게 물리적으로 연결하는데 사용되는 IT 자원들을 가상화하는 능력들의 집합체로 볼 수 있다.
    ▷ 여기서 가상화 가능한 네트워크 자원들에는
      - IP 어드레스,
      - 네트워크 어댑터,
      - LAN,
      - 대역폭 관리 등이 포함된다.

 

  ○ 장점
    ▷ 네트워크를 가상화함으로써 사용자는 IT 인프라스트럭쳐에 걸쳐서 좀 더 효율적이고, 비용 효과적이며, 안정적이며 가용성 있는 통신체계를 만들기 위해 네트워크 요소를 풀링하고 공유할 수 있다.
    ▷ 또한 가상화된 네트워크는 좀 더 유연해짐으로써 사용자들이 최소한의 다운 타임 또는 실시간으로 비즈니스의 니즈에 대처하는데 필요하도록 인프라스트럭쳐를 변경할 수 있게 해준다.

 

  1) 공유를 가능하게 하는 기술

    ▷ 가상 LAN (VLAN) 기술
      - 소프트웨어적으로 구현되며, 컴퓨터의 네트워크를 구성할 때 실제 연결되지 않았으나 마치 물리적으로 연결된 것처럼 행동하게끔 설정한다. VLAN은 사용자 A의 데이터가 공유 네트워크 상에서 사용자 B의 데이터와 서로 섞이지 않도록 보장하기 위해 가상화의 절연 기능을 이용한다.
      - IP-SEC 프로토콜
       · IP 네트워크를 단절되고 독립된 많은 가상 네트워크(VPNs)처럼 보이게 함으로써 IP 네트워크를 좀 더 효율적이고 안전하게 공유될 수 있도록 사용된다.
       · 네트워크의 2개의 논리적 끝단 사이에서 암호화된 데이터의 일치성을 보장해준다.
      - 터널링 기술
       · 다중 프로토콜 스위칭(MPLS)은 단절 기능을 제공해주는 터널링 기술이며 주로 성능 개선 목적으로 사용된다.

    ▷ 다중 호스팅을 지원하는 HTTP 서버
      - 활용률을 증대시키고 자동 복구를 지원하기 위해서, 고객들은 하나의 물리적 애플리케이션 서버가 다수의 가상 어플리케이션 서버인 것처럼 보이게 하기 위해 다수의 가상 로컬 IP 어드레스를 사용할 수 있다.

    ▷ 어댑터 가상화 기술
      - 서버에 붙은 물리적 네트워크 어댑터가 여러 개인 것처럼 보이게 하여 네트워크의 연결을 단순화 시켜서 서버들간의 네트워크 연결의 효율성을 향상시킬 수 있다. 대표적인 예로 System z의 OSA-express L2-L3 공유기술 또는 System p의 가상 이더넷 기술을 들 수 있다.

 

   2) 자원 풀링을 가능하게 하는 기술
    ▷ 아래의 기술들은 가상화의 단일화 기능을 이용하여 사용자로 하여금 네트워크 요소들을 하나로 묶어서 사용하게끔 해준다.
      - 다양한 형태의 IP 워크로드 밸런싱 기술
       · 여러 대의 애플리케이션 서버들을 마치 하나의 단일 애플리케이션 서버 또는 인스턴스 처럼 보이게 해준다.
       · 워크로드 밸런서는 내부적으로 다수의 애플리케이션 서버 풀에서 각 서버의 용량과 가용성 정도에 대한 정보를 실시간으로 수집하면서 애플리케이션 인스턴스들에 걸쳐서 워크로드를 밸런싱 하면서도 외부적으로는 하나의 단일화된 애플리케이션 앤터티를 네트워크에 보여준다.
       · 대표적인 사례로는 z/OS의 Sysplex Distributor, Cisco사의 콘텐츠스위칭모듈(CSM), 노텔/알테온사의 Load Balancer 등이 있다.
      - 네트워크어댑터 가상화 기술
       · 다수의 애플리케이션 네트워크 연결을 연관된IP 어드레스로 이동시킴으로써 동일한 인스턴스로 보이게 해준다.
       · 그렇게 함으로써 네트워크 양 끝단에서 동적 라우팅의 구성이나 라우터 디스커버리 프로토콜을 수행 할 필요 없이도 네트워크상에서 더 높은 가용성을 얻을 수 있게 한다. VIPA takeover, IP address takeover 및VRRP 등이 그러한 기술들의 좋은 사례들이다

 

   3) 에뮬레이션과 추상화
    에뮬레이션 또는 추상화(Abstraction) 기능을 통해 사용자들은 애플리케이션 서비스 영역에서 엔드-투-엔드 연결을 프로비져닝하고 관리하는 기능을 제공해 줄 수 있다.
    ▷ 사용자들은 에뮬레이션 기술을 사용하여 애플리케이션 프로그래머들로 하여금 각 애플리케이션이 SSL 기반 하에 돌아가도록 일일이 코딩하는 노력을 덜어줄 수 있다. 그러한 기술들은 애플리케이션 서버가 연결 지향의 보안 체계를 갖는 것처럼 보이게 해준다(예를 들어 SSL 또는 TLS 지원). 그러한 에뮬레이션은 소켓 프로그래밍 인터페이스 레이어의 아래에 위치한 TCP 레이어에서 수행되어진다.
    ▷ 대역폭 관리 소프트웨어는 특히 WAN 구간 및 TCP를 사용하지 않는 인터넷 링크(예를 들어 스트리밍 오디오 및 비디오 애플리케이션)에서 네트워크 성능을 관리할 수 있는 수단을 제공해준다. 해당 소프트웨어는 TCP/IP 스택에 상주하면서 대역폭의 할당을 제어하기 위해 정책 기반의 관리 기법을 사용한다. 대표적인 예로 z/OS의 하나의 구성요소인 IBM Service Policy Agent를 들 수 있다.
    ▷ 사용자들은 하나의 서버 내에서 서로 다른 논리적 파티션들이 하나 이상의 LAN으로 연결되어 있는 것처럼 행동하게끔 만드는데 가상화를 사용할 수도 있다. 이러한 형태의 가상화를 지원하는 기술들에는 HiperSockets과 가상 이더넷 LAN이 있다.
    ▷ 가상 네트워크 어플라이언스는 여러 가지 형태의 네트워크에 특화된 기능들을 하나로 엮어주는 네트워크 애플리케이션의 일종으로서 외관상 하나의 박스 안에 또는 가상서버상의 전속된 하나의 인스턴스 안에 상주할 수도 있다.

 

   4) 네트워크 자원들의 관리
    ▷ 가상화는 네트워크에 대하여 또 다른 차원의 관리와 제어를 요구한다.
      - 예를 들어 열개의 가상 서버들이 하나의 10GB 네트워크 어댑터를 공유하고 있다고 가정하면
       · 열대의 가상 서버들 중 어떤 하나가 소비할 대역폭을 제한할 수 있는 어떤 제어 메커니즘이 필요하게 된다.
       · 그러한 제어는 대역폭 사용 정책을 정의하거나 가상 네트워크 인프라 스트럭쳐 내에서 네트워크 정책을 강제할 수 있는 에이전트를 제공함으로써 강제로 이행될 수 있다.
    ▷ 네트워크 가상화를 위해 요구되는 관리와 제어 기능들은 온 디맨드 운영 환경(ODOE)의 일부로서 정의되고 있다.
       · 네트워크 자원 매니저(NRM, Network Resource Manager) 요소는 기본적으로 통합된 토폴로지 정보, 비즈니스 연속성(네트워크 자원의 자동 복구) 그리고 그러한 환경에서 가능한 프로비져닝 체제를 제공할 것이다.
       · 그리고 이러한 지원은 WSDM 기반의 인터페이스의 집합 형태로 결합될 것이다.

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[8강] 클라우드 컴퓨팅 도입전략  (0) 2012.07.11

댓글을 달아 주세요

[10강] 서버 가상화

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 13. 10:47 | Posted by 깨비형

1. 서버 가상화 시장

 

  ○'서버 가상화'란 하나의 컴퓨터에서 여러 개의 운영체제를 설치해 여러 개의 서버처럼 운용하는 기술로, 현재는 VM웨어, 마이크로소프트, 시트릭스(젠소스 인수) 등이 관련 시장을 주도하고 있다.

 

  ○가상화 기술은 하나의 서버를 여러가지 용도로 사용한다는 점에서 총 소유비용을 줄일 수 있고, 유지보수 등도 훨씬 더 간편케 해 급성장할 것으로 예상되는 시장이다.

 

  ○ 서버 가상화 시장
    ▷ 현재 VM웨어가 약 시장의 70%를 장악하고 있다고 평가되는 등 무서운 기세를 올리고 있다.
    ▷ 이 힘을 바탕으로 VM웨어는 미국 나스닥 시장에서 돌풍을 일으키며, 모 기업인 EMC의 현금원이 됐다. 그러나 VM웨어를 공략하는 업체들의 움직임도 발빠르다.
    ▷ 최근 시트릭스는 오픈소스 서버 가상화 솔루션 업체 젠소스를 인수해 VM 웨어에 도전장을 던진 바 있다. 시트릭스는 시트릭스 젠서버 등 젠소스 기술을 이용한 솔루션을 선 보이며 VM웨어와의 '맞짱'을 선언했다.
    ▷ 마이크로소프트는 VM웨어에서 돌아가는 서버들을 MS 포맷으로 전환할 수 있도록 해주는 '시스템센터 버추얼머신매니저' 을 발표하며 VM웨어를 견제하기 시작했다. MS는 윈도 서버 2008에 비리디안(코드명)이라는 가상화 솔루션을 탑재해 VM웨어와 경재하고 있다.
    ▷ 오라클은 전 세계 소프트웨어 시장의 2위이지만, 기업용 SW시장에서는 실질적으로 1위를 달리고 있다. 세계적인 기업 중 오라클 제품에 의지하지 않고 있는 기업이 거의 없을 정도다. 오라클은 오라클 VM이 자사의 DB, 미들웨어, 애플리케이션을 지원한다는 것을 명확히 하고 있다. 기존 오라클 제품을 이용하는 고객이나, 미래의 오라클 고객을 주 타겟으로 하겠다는 전략이다. 과연 오라클이 VM웨어의 독주를 막을 수 있을 지 주목된다.

 


2. 서버 가상화 개념

 

  ○ 서버 가상화는
    ▷ 하나의 서버에서 여러 개의 애플리케이션, 미들웨어 및 운영체제(OS)들이 제각기 서로 알 필요도 없고, 서로 영향을 미치지 않으면서 동시에 사용될 수 있도록 해준다.

 

  ○ 서버 가상화의 초기 형태에는
    ▷ 가상 메모리, 가상 I/O 그리고 에뮬레이션 등이 포함되었다.
    ▷ 이러한 초기 형태의 가상화 기술들은 곧 애플리케이션 및 서브 시스템의 가상화로 발전되어서 다수의 애플리케이션, 서브 시스템 또는 미들웨어 스택들이 하나의 운영 체제 아래에서 통제를 받으면서 수행될 수 있게 해준다.

 

  ○ 아래 그림은 서버 가상화의 여러 가지 형태를 간단히 설명해주고 있다.
    ▷ 서버 내의 가상화의 대표적인 예로는 Managed Runtime, 물리적 분할, 가상 머신, 논리적 파티셔닝, 가상 I/O를 들 수 있다.

 


3. 서버 가상화 기술

 

   1) Managed Runtime
      - 오랫동안 대형서버들은 단일 OS 시스템(또는 OS 이미지) 위에서 상용의 대규모이면서 높은 가용성이 요구되는 애플리케이션들이 서로 영향을 미치지 않으면서 돌아갈 수 있도록 독립적인 메모리 스페이스 영역과 CPU 자원을 별도로 할당하는 아키텍쳐 디자인을 유지해 왔다.
      -  위측의 그림 처럼 애플리케이션 중심의 단일 사용보다는 공유에 적합하도록 디자인된 좀 더 발전된 형태의 아키텍쳐는 애플리케이션과 미들웨어 사이에서 절연(Isolation) 효과와 데이터 정합성을 보장해준다.
      - 오늘날 Sun의 SPARC/Solaris와 같은 아키텍쳐들과 운영 체제들은 Managed Runtime 또는 컨테이너를 제공하려고 진화하고 있다.

 

   2) 물리적 분할(Physical Partitioning)
    ▷ 서버 가상화는 하드웨어 자원들이 물리적으로 분할이라는 하위 자원 단위로 분할되어 사용할 수 있게 해준다. 이때의 물리적 분할은 대개 CPU 프로세서와 I/O 디바이스를 경계로 이루어지며, 각 파티션은 최소한 1개 이상의 CPU 프로세서를 가져야 한다.
    ▷ 각 파티션은 물리적으로 완전 격리된 형태로 구성되며, 그래서 파티션들은 일반적으로 유연하지 못하고 전체 시스템을 재부팅 하기 전까지는 변경되지 못한다.
    ▷주 프레임에서 최초 소개되었던 물리적 파티션은 이제 서버들이 좀더 안정화되고 경량화되면서 장점를 잃어가고 있고 아주 소수의 시스템들만이 제공할 뿐이다.
    ▷분할은 크게 물리적 분할, 소프트웨어적 분할(주로 가상 머신) 그리고 논리적 분할 등으로 구분할 수 있다.

 

   3) 가상 머신(Virtual Machine)
    ▷ 1970년대 초반 가상 머신(VM)의 도래는 가상화의 새로운 장을 열었다.
    ▷ 가상 머신을 이용한 서버 가상화는 소프트웨어적 파티셔닝 또는 OS 이미지 가상화라고도 불리운다.
    ▷ 여기서 가상 머신은 일종의 단순화되고 변형된 모체 OS로써, 이런 OS 위에 우리가 알고 있는 리눅스, 윈도우와 같은 완전한 OS 시스템이 설치되어 돌아갈 수 있게 된다.
    ▷ 아래의 그림은 이러한 가상 머신의 개념을 간단히 보여 주고 있다.


      - 가상 머신 위에서 가동되는 개별 OS 이미지는 실제 디바이스와 에뮬레이션된 디바이스 모두를 액세스할 수 있다.
      - 아래의 그림에 간단히 보여 주고 있다.

 

      - 이런 가상 머신의 개념은 최근에 나온 것은 아니다.
      - 오늘날 가상 머신은 아주 치밀하고 가변적이어서, 실제 및 가상 자원들 모두가 공유될 뿐만 아니라 가상 머신들 사이에서 시스템 재시작 없이도 동적으로 스위칭 될 수 있도록 해준다.
      - 가상 머신을 통해 OS 이미지를 가상화하는 능력이 주어짐에 따라, 사용자들은 추가 하드웨어 구입 없이도 새로운 OS의 설치, 애플리케이션의 테스팅 및 업그레이드를 동일한 물리적 서버상에서 동시에 수행 시킬 수 있다.
      - 이를 통해 같은 물리적 서버상에서 다른 OS 이미지로 가동되는 운영 시스템들간에 아무런 영향을 끼치지 않고서도 새로운 애플리케이션들을 동시에 테스팅 할 수 있게 된다.

 

   4) 논리적 분할(Logical Partitioning)
      - 논리적 분할 은 가상 머신과 물리적 분할 사이에 있는 뛰어난 서버 가상화 기능이다.
      - 가상 머신과 함께 논리적 분할 은 IT 인프라스트럭쳐를 가상화하기 위한 전략에 있어서 핵심 요소가 된다.
      - 논리적 분할 은 별도의 모체가 되는 OS 없이 하이퍼바이저(Hybervisor)라는 펌웨어 수준에서 하나 또는 그 이상의 OS 이미지들이 하나의 물리적 서버 위에서 동작할 수 있도록 해준다
      - 이러한 각 논리적 파티션은 고정 혹은 가변적인 개수의 프로세서를 가질 수 있다.
      - 물론 논리적 파티셔닝을 통해 물리적 파티셔닝 기능을 구현할 수도 있다.
      - 참고로 1개의 단일 프로세서의 일부분을 할당하여 동적인 논리적 파티션을 만드는 것은 마이크로 파티셔닝(Micro Partitioning)이라 부른다.
      - 또한 논리적 파티션간에 자원 활용의 불균형이 존재하는 경우에는 시스템이 제공하고 있는 고급 파워 가상화 기능의 하나인 파티션 로드 매니저를 활용할 수도 있다.
      - 파티션 로드 매니저는 각 논리적 파티션들의 사용률을 실시간으로 파악하여 미리 정해진 사용률 정책을 기반으로 하여 워크로드가 낮은 파티션의 CPU 및 메모리 자원을 실시간으로 워크로드가 높아진 파티션으로 자동 재분배해 줌으로써 최적의 시스템 효율성을 추구하게 해준다.
    ▷ 하이퍼바이저의 아키텍처 구현 방식 사례: VMWare ESX의 구조도를 보여 주고 있다

 


   5) I/O 가상화
    ▷ 필요성
      - 가상 머신과 논리적 분할만으로는 서버 내 가상화의 공유 및 절연(Isolation) 기능을 완벽하게 구현할 수는 없다.
      - 이를 보완하기 위해 어댑터와 같은 I/O 자원들을 공유하거나 또는 가상 머신들 간에 혹은 논리적 파티션들간에 I/O 통신을 할 필요가 있다.
    ▷ 해결방법
      - 서버와 운영체제의 결합을 통해 I/O 가상화를 구현하기 위한 여러 가지 방법을 제공하고 있다.
    ▷ 시스템의 가상 I/O 서버(VIOS)
      - 특별한 목적의 가상 분할로서, 다른 파티션들에게 I/O 자원을 공급하는 역할을 한다.
      - 가상 I/O 서버는 물리적 자원을 소유하면서 다른 파티션들에게 I/O 자원의 공유를 허용해준다.
      - 사용자들은 가상 I/O 기술덕분에 물리적 어댑터를 특정 파티션에만 할당하고서도 다른 파티션들과 공유해서 사용할 수 있게 된다.
    ▷ 결과
      - 각 파티션마다 별도로 네트워크 어댑터, 디스크 어댑터 그리고 디스크 드라이브를 가져야 하는 요구사항이 제거됨으로써 전체적인 비용을 낮출 수 있게 된다.
    ▷ 가상 I/O 서버가 가지는 I/O 가상화의 기능에 따라 3가지로 분류된다.
      - 가상 SCSI,
      - 가상 이더넷,
      - 공유 이더넷 어댑터(Shared Ethernet Adapter)

 

     ★ 가상 이더넷 (Virtual Ethernet)
      - 대표적인 I/O 가상화의 하나로써 가상화의 애뮬레이션 기능을 이용하고 있다.
      - 각 파티션들간에 물리적인 네트워크 어댑터 없이도 메모리 버스를 통하여 통신이 가능하게 해준다.
      - 이것은 동일한 물리적 하드웨어상에서 돌아가는 솔루션의 계층 요소들끼리 메모리상에서 고속, 고효율의 통신이 가능하다는 것이다.
      - 이를 통해 사용자들은 별도의 물리적 어댑터를 사용하지 않고서 또 어댑터 구매에 따르는 관리 및 비용 부담 없이도 절연, 네트워크 이중화 그리고 향상된 보안 체계를 가질 수 있다.

 

     ★ 공유 이더넷 어댑터(SEA: Sharable Ethernet Adaptor) :
      - 공유 이더넷 어댑터는 파티션의 개수보다 물리적 어댑터의 개수가 적은 경우에 여러 파티션들이 물리적 이더넷 어댑터를 공유할 수 있도록 해준다.
      - 또한 가상 이더넷에서 실제 네트워크 어댑터로 네트워크 트래픽을 보내줌으로써 가상 이더넷과 실제 물리적 이더넷을 연결하여 주기도 한다.
      - 아래 그림은 공유 이더넷 어댑터를 통한 가상 통신의 흐름도를 보여주고 있다.

 


     ★ 가상 SCSI
      - 한 대의 서버를 여러 개의 파티션으로 나누어 구성할 경우 가장 문제가 되는 부분이 I/O 어댑터의 부족이며,
      - 특히 외장 디스크를 사용할 수 있게 해주는 파이버 채널 어댑터가 절실히 부족하게 된다.
      - 이를 해결하기 위해 가상 I/O 서버의 개념이 필요하다.
      - 가상 I/O 서버는 물리적인 디스크를 실제로 소유한 파티션으로서 디스크 볼륨이 필요한 파티션들에게(파이버 채널 어댑터가 없음) 논리적 디스크 볼륨의 형태로 디스크 볼륨을 할당해준다.
      - 즉, 가상 I/O 서버 파티션에서 만들어져 제공된 논리적 디스크 볼륨은 이를 이용하는 다른 파티션들에게 SCSI 디스크 형태로 나타난다.

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[8강] 클라우드 컴퓨팅 도입전략  (0) 2012.07.11
[7강] 클라우드 컴퓨팅 SaaS  (0) 2012.07.10

댓글을 달아 주세요

[9강] 가상화 개념

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 12. 06:59 | Posted by 깨비형

1. 가상화의 정의와 개념


  ○ 정의

      - 컴퓨터에서 컴퓨터 자원의 추상화을 일컫는 광범위한 용어임

      - "물리적인 컴퓨터 리소스의 특징을 다른 시스템, 응용 프로그램, 최종 사용자들이 자원과 상호 작용하는 방식으로부터 감추는 기술"로 정의할 수 있다.

      - 이것은 다중 논리 리소스로서의 기능을 하는 것처럼 보이는 서버, 운영체제, 응용 프로그램, 또는 저장장치와 같은 하나의 단일 물리적 자원을 만들어 낸다.

      - 아니면 단일 논리적 자원처럼 보이는 저장장치나 서버와 같은 여러 개의 물리적 지원을 만들어 낼 수 있다.


  ○ 가상화 유래

      - 이 용어는 오래되었다. 1960년대 이후로 널리 쓰였으며, 전체 컴퓨터 시스템에서 개별 기능/구성 요소에 까지 컴퓨터의 다른 많은 면과 영역에 적용되어 왔다.

      - 모든 가상화 기술의 공통 주제는 주변에 막을 씌워 "기술적으로 자세한 부분을 숨기는 것"이다.

      - 가상화는 다른 물리적 위치에서 리소스를 한데로 합치거나 제어 시스템을 단순하게 하여 다중 송수신 접근과 같은 것을 통해 기반이 되는 기능 추가를 보이지 않게 하는 외부 인터페이스를 만들어 낸다.

      - 새로운 가상 플랫폼과 기술의 최근 발전은 이렇게 성숙한 개념에 다시 한번 집중하게 만들었다.


  ○ 가상화 기술은 실제 존재하는 물리적 자원들을 논리적 자원들의 형태로 표시하는 기술로서, 물리적 자원을 이용하는 사용자(구체적으로 애플리케이션 및 서비스를 가리킴)에게는 논리적 형태로만 나타난다. 아래 그림 처럼 가상화 기술이 이들 논리적 자원들과 실제 물리적 자원들에 대한 연결을 담당해 줌으로써, 가상화 자원을 이용하는 사용자는 더 이상 어떤 자원들이 사용되는지를 구체적으로 알 필요가 없어진다.

  ○ 앞의 그림에서 보여주고 있는 것과 같이

    ▷ 가상화라는 중간 계층을 이용하여 애플리케이션과 서비스를 실제적인 자원들과 분리하는 이러한 형태는 사용자로 하여금 동일한 자원을 공유하게 해주고, IT 자원들을 개별 자원이라기 보다는 논리적인 자원 풀로서 사용하고 다루게 해준다.

    ▷ 서버내의 자원 분할(Partitioning)은 가상화의 대표적인 사례로서, 커다란 하나의 서버 시스템을 다수의 작은 시스템으로 보이게 해줌으로써 서버 자원을 공유하게 해준다.

    ▷ 또한 스토리지 가상화 기술은 여러 개의 물리적 스토리지 시스템들에 남아 있는 유휴 디스크을 모아서 만든 디스크 풀에서 가상화된 디스크를 만들 수 있게 해준다. 이렇게 가상화된 디스크에 접근함으로써 애플리케이션 서버는 실제로는 최대 사용 가능한 공간이 300MB 밖에 안되는 상황에서도 마치 1TB의 스토리지가 단독으로 붙어 있는 것처럼 간주하여 실행될 수 있다.


  ○ 결론적으로 가상화 기술은 실제로 존재하는 물리적 자원들에 대한 중재자 역할을 해주는 기술로써 위의 경우에 적용해 보면 가상화 기술은 애플리케이션 서버의 스토리지 요구를 가로채서 여러 개의 스토리지 컨트롤러에 걸쳐 있는 유휴 공간을 찾아내 줌으로써 스토리지 용량에 대한 요구를 만족시켜 주는 것이다.



2. 가상화의유형


  ○ 가상화는 일반적으로 서버, 스토리지 및 네트워크와 같은 전통적인 단위 하드웨어 자원에 많이 적용되어 왔다. 그러나 가상화의 적용 범위는 아래 그림처럼 단순히 하드웨어 차원의 IT 리소스에만 한정되지 않고 애플리케이션, 미들웨어, 분산 시스템 및 가상화 자원들 자체를 포함하여 비실체적인 자원들에 대해서도 적용될 수도 있다.



  ○ 위 그림에서 보여 준 것과 같이 가상화 범위는 다양하다.


  ○ 즉 미들웨어를 통한 워크로드의 가상화에는 잡 스케쥴러(JobScheduler)가 이용될 수 있으며, 애플리케이션 레벨의 가상화에는 애플리케이션 서버가 스스로 인스턴스를 제어하여 워크로드를 관리할 수도 있다. 대표적인 사례로 전자에는 다양한 그리드 스케쥴러가 있고, 후자에는 WAS-XD 같은 웹 애플리케이션을 들 수 있다.


  ○ 향후 전통적인 자원 가상화의 추세는 여전히 개별 하드웨어를 중심으로 이루어져 가겠지만, 새로운 형태의 가상화 역량이 추가적으로 요구되고 있다. 새로운 가상화 역량에는 작은 다수의 시스템 집합에서 가상 시스템을 만들어내거나 플랫폼과 벤더의 경계를 넘어서서 단순화되고 일관된 방식으로 관리될 수 있는 가상 시스템을 구현하는 것이 포함되어 있다. 여기에는 앞 페이지의 그림에서 관리의 가상화, 전사적 차원의 가상화 등이 포함될 수 있다.


  ○ 가상화의 적용 범위로

      - Infrastructure 계층의 디바이스, 네트워크, Power 가상화

      - Hardware, 계층의 서버와 저장장치 가상화

      - Operating Systems 계층의 운영체제 가상화

      - Middleware, 계층의 Applicaton 가상화

      - Workload 계층의 업무의 가상화

      - Bussiness Appplication 계층의 Database 가상화 등이 있다.


  ○ 여기서는 서버, 스토리지 및 네트워크 등 주로 하드웨어 인프라 차원에서의 가상화 기술에 설명해 나가도록 할 예정이며, 기회가 될 경우에 추가적으로 나머지 레이어에 대한 가상화 적용 기술들을 소개할 계획이다.


  ○ 가상화는 자원의 공유(Sharing), 단일화(Aggregation), 에뮬레이션(Emulation) 그리고 절연(Insulation)이라는 4가지 기본적인 기능을 가지고 있다. 아래 그림은 가상화의 기능별 종류 및 이에 따르는 사례들을 보여주고 있다.


   1) 공유(Sharing) :

    ▷ 가장 대표적인 가상화의 기능으로서 다수의 많은 가상 자원들이 하나의 동일한 물리적 자원과 연결되어 있거나 가리키는 것을 말한다. 물리적 자원의 일부분을 가상화된 자원마다 할당하거나 혹은 물리적 자원에 대하여 타임 쉐어링 기법으로 공유하는 방식이 주로 사용된다.

    ▷ 이러한 형태의 가상화는 가상화 자원을 사용하는 여러 사용자들(애플리케이션 또는 서비스)이 물리적 자원을 공유하게 해주며, 이때 각 사용자는 마치 자기가 해당 자원을 혼자서만 사용하는 것과 같은 착각을 하게 된다.

    ▷ 대표적 사례로는 서버 내의 논리적 분할, 가상머신(VM), 가상 디스크, 가상 LAN(VLANs)을 들 수 있다.


   2) 단일화(Aggregation) :

    ▷ 공유의 반대되는 가상화 개념으로서, 가상 자원은 여러 개의 물리적 자원들에 걸쳐서 만들어질 수 있으며, 이를 통해 외견상 전체 용량을 증가시키고 전체적인 관점에서 활용과 관리를 단순화시켜 줄 수 있다.

    ▷ 예를 들어, 스토리지 가상화는 여러 개의 물리적 디스크 시스템에 남아있는 각각의 유휴 디스크들을 하나의 가상화된 디스크로 만들어 주는데, 이때 가상화된 디스크는 가상 디스크를 만드는데 사용 되어진 어떤 물리적 디스크보다도 더 커질 수 있다


   3) 에뮬레이션(Emulation) :

    ▷ 물리적 자원 자체에는 원래부터 존재하지 않았지만 가상 자원에는 어떤 기능들이나 특성들을 마치 처음부터 존재했던 것처럼 가질 수 있다. 예를 들어 IP 네트워크 상에서 가상 SCSI 버스를 구현하는 iSCSI 또는 물리적 디스크 스토리지상에 구현된 가상 테이프 스토리지 등이 여기에 속한다. 또 다른 형태의 에뮬레이션에는 여러 개의 제각기 다른 물리적 자원들을 표준 구성요소 형태인 것처럼 가상 자원으로 표시하는 것이 있다. 여러 종류의 이더넷(Ethernet) 인터페이스를 마치 하나의 특정한 표준 이더넷 인터페이스 모델로 나타내는 것이 그 예이다.


   4) 절연 (Insulation) :

    ▷ 가상화된 자원들과 물리적 자원들간의 상호 맵핑은 가상화 자원들 또는 가상화 자원들을 사용하는 사용자들에게 아무런 영향을 미치지 않으면서 물리적 자원들이 교체될 수 있도록 해준다 . 이것은 투명한 변경(Transparent Change)이라고 불리우며, 투명한 변경은 가상화에 있어서 하나의 부가적인 혜택이기도 하지만, 때때로 그 자체가 하나의 기술로서 중요한 의미를 갖기도 한다. 어떤 가상 프로세서가 결함이 발생하였거나 혹은 곧 발생하려는 물리적 프로세서에서 다른 정상적인 물리적 프로세서로 자동적으로 옮겨간다거나, 디스크의 결함을 사용자들로부터 숨기기 위해 다중디스크(Redundant Disk)를 사용하는 RAID 스토리지 컨트롤러가 대표적인 사례이다. 달리 말해 장애 방지(Failure Proof)의 효과라고 볼 수 있다.


  ○ 가상화의 혜택은 가상화를 도입하려는 사용자들의 목표나 접근 방법, 채택된 기술 및 기존 IT 인프라스트럭쳐의 종류에 따라 크게 달라진다. 대부분의 사용자들은 (심지어는 단순히 서버 통합에 가상화를 사용하는 경우에도) 아래에 언급된 혜택들을 어느 정도 가질 수 있다. 또한 사용자들이 그들의 IT 인프라스트럭쳐를 가상화하는데 더 많은 노력을 기울일 때, 얻을 수 있는 가상화의 혜택은 그만큼 비례해서 커지게 된다. 아래 그림처럼 가상화 도입 시 얻을 수 있는 혜택들을 구체적으로 열거해 보면 다음과 같다.


   1) 높아진 자원의 활용률 :

      - 가상화는 물리적 자원들과 자원 풀에 대한 동적인 공유를 가능하게 해주며, 이를 통해 더 높은 자원의 활용률을 얻을 수 있다. 특히 평균 워크로드가 전체 자원의 워크로드 보다 훨씬 적은 가변적인 워크로드 상황에서는 더 높은 효과를 얻을 수 있다.


   2) 낮아진 관리 비용 :

      - 가상화는 관리해야 하는 물리적 자원들의 대수를 줄여줌으로써 관리 인력의 생산성을 향상시킬 수 있다.

      - 또한 물리적 자원들의 복잡성을 숨겨주고,

      - 자동화, 정보화 및 중앙화를 통해 공통된 관리 작업을 단순화시키고,

      - 워크로드 관리의 자동화를 가능하게 해준다.

      - 가상화는 이기종 플랫폼 환경에서도 관리 도구를 공통으로 사용할 수 있게 해준다


   3) 사용의 유연성:

      - 가상화는 빠르게 변화하는 비즈니스니스를 만족시키기 위하여 자원들이 동적으로 재구성되고 활용 될 수 있도록 해준다.


   4) 향상된 보안

      - 가상화는 단순한 공유 메커니즘에서는 불가능한 분리와 격리를 가능하게 해서 데이터와 서비스에 대하여 통제되고 안전한 액세스를 제공한다.


   5) 높아진 가용성

      - 가상화는 사용자레벨에 아무런 영향을 주지 않고도 물리적자원이 제거되거나 업그레이드 또는 변경 될 수 있도록 지원해 준다.


   6) 증가된 확장성

      - 자원 분할 및 단일화(Aggregation)는 가상화된 자원이 개별 물리적 자원보다 더 작아지거나 혹은 더 커질 수 있게 해준다.

      - 이를 통해 물리적 자원의 구성 변경이 없어도 필요한 만큼의 적정한 확장성을 얻을 수 있다.


   7) 상호 운영성 및 투자의보호

      - 가상화 자원들은 기존 물리적 자원들간에서는 불가능한 인터페이스와 프로토콜 레벨에서의 호환성을 제공해 준다.


   8) 향상된 프로비져닝 (Provisioning)

      - 가상화는 자원의 할당을 개별 물리적 단위보다도 더 세밀한 조각 단위에서 가능하게 해준다


  ○ 가상화를 도입하려고 할 때 처음부터 전사적 차원에서 접근할 필요는 없다. 오히려 장기적인 IT 발전 방향에 대한 로드맵을 그린 다음 단계적으로 가상화를 기업 내에서 확산 시켜나가는 접근 방법이 필요하다. 이러 접근 방법에 맞추어 가상화를 도입하는 순서는 동질적 가상화에서 시작하여 이질적 가상화, 전사적 가상화를 거쳐 마지막으로 글로벌 가상화로 점점 범위를 확대하면서 기업 내의 역량이 이에 따라 갈수 있도록 보조를 맞추어 가는 것이 중요하다. 아래 그림은 가상화의 단계별 발전 과정을 모형화하여 보여주고 있다.



  ○ 먼저 동질적 가상화(Virtualize like resources)란 가상화의 도입을 처음으로 고려할 경우에 많이 발생하며, 조직 또는 부서 단위에서 동일한 또는 비슷한 자원들을 하나의 가상 풀로 묶는 것이다. 여기에는 스토리지 가상화가 대표적인 예이다.


  ○ 이질적 가상화(Virtulaize unlike resources)란 OS 또는 애플리케이션처럼 성격이 다른 자원들을 하나로 묶는 것으로 워크플로우 (Workflow:작업흐름도)와 관련 있는 모든 자원들을 가상화하는 단계를 말한다. 여기에는 트랜잭션 또는 워크플로우의 자동화가 필수적이며, 가상화 엔진 또는 그리드 구축이 구체적인 예이다.


  ○ 가상화가 기업 내에 어느 정도 진척이 되면 전사적 가상화(Virtualize the enterprise)의 단계로 넘어간다. 이 단계에서는 모든 자원들이 동적으로 관리가 되며 각 부서간에 사용량에 따른 비용 할당이 가능하게 된다.


  ○ 마지막 단계의 가상화는 기업의 경계를 넘어서서 비즈니스 파트너와 심지어는 고객까지도 가상화의 주체로 참여하는 글로벌 가상화(Virtualize outside the enterprise)로 이행한다.



3. 가상화의 기술 분류


  ○ 시장에서 실제로 활용되고 있는 다양한 가상화 기술들은 분류 방식에 따라 여러 가지로 나누어볼 수 있다.


  ○ 먼저 이전의 앞 가상화 적용 범위의 그림처럼 가상화 계층의 위치에 따라

    ▷ 하드웨어 가상화에서부터

    ▷ OS 가상화, 애플리케이션 가상화, 관리 가상화 등으로 단계적으로 나누어볼 수 있으며

    ▷ 혹은 가상화가 적용되는 물리적 범위를 기준으로 시스템 내부 가상화, 시스템 외부 가상화 등으로 나누어볼 수도 있다. 물론 이외에도 다양한 분류 방법이 있을 수 있다.


  ○ 여기서는 후자의 경우처럼 가상화가 시스템 내부에 구현되었는가 또는 시스템 외부간에 구현되었는가에 따라 시스템 내부 가상화와 시스템 외부 가상화로 크게 나누었으며 각각은 다시 서버 가상화와 스토리지 가상화로 좀 더 세밀히 나눌 수가 있다. 한편 네트워크 가상화는 특성상 분류가 어려워 별도의 가상화 항목으로 배치하였다. 이것을 정리하면 다음 페이지 그림과 같이 나타낼 수 있다.


  ○ 아래의 그림은 가상화에 대한 기술 분류를 보여 주고 있다.



  ○ 서버 가상화와 스토리지 가상화 그리고 네트워크 가상화를 각각 나누어 진다.


  ○ 이들을 공통적으로 지원하는 차세대 가상화의 대표적인 실체인 가상화 엔진(Virtualization Engine)이 필요하다. 이들 내용은 가상화 설명의 끝 단계에서 자세히 설명한다.


'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[8강] 클라우드 컴퓨팅 도입전략  (0) 2012.07.11
[7강] 클라우드 컴퓨팅 SaaS  (0) 2012.07.10
[6강] 클라우드 컴퓨팅 PaaS  (0) 2012.07.09

댓글을 달아 주세요

1. 클라우드 선정 절차


  ○ 서비스 재고 (1) : 서비스 유형

    ▷ 현재 기업 아키텍처의 필요사항을 충족시키기 위해 사용자가 선택할 수 있는 클라우드 컴퓨팅 유형 또는 카테고리는 수없이 존재한다.

    ▷ 따라서, 필요한 서비스 유형을 선택하여야 한다.

    ▷ 서비스 유형은 (3~6강 내용 복습)

      - SaaS(Software-as-a-Service: 서비스 형태로 제공되는 보안 기능),

      - TaaS(Testing-as-a-Service: 서비스 형태로 제공되는 테스트 기능)

      - PaaS(Platform-as-a-Service: 서비스 형태로 제공되는 플랫폼)

      - IaaS(Infrastructure-as-a-Service: 서비스 형태로 제공되는 인프라)

      -위의 모두 서비스의 종류에 관계없이 모두 각자의 상충요소(Tradeoffs)가 있고, 각자가 해결하려는 문제 영역이 있다. 어쨌든 사용자는 자신의 아키텍처를 판단 기준으로 삼아야 한다.


  ○ 서비스 재고 (2): 클라우드 서비스 카테고리

   ※ 다양한 클라우드 서비스 카테고리는 아래와 같이 분류된다.


     - 스토리지

   - 데이터베이스

   - 정보

   - 프로세스

   - 애플리케이션

   - 플랫폼

   - 통합

   - 보안

   - 관리/거버넌스(Governance)

   - 테스팅, 그리고

   - 인프라스트럭처



  ○ 서비스 재고 (3) : 서비스의 재 분류

   ※ 소분류

    ▷ 솔루션

      - 공급업체별로 정도로 특정 문제들만을 해결해주는 서비스

    ▷ 서비스는

      - 스토리지, 데이터베이스, 정보, 프로세스, 통합, 보안, 관리/거버넌스, 그리고 테스팅 서비스

   ※ 대분류

    ▷ 솔류션

      - 공급업체별로 독자적으로도 완벽한 플랫폼을 제공하는 서비스

    ▷ 서비스는

      - 애플리케이션, 플랫폼 그리고 인프라 서비스

      - 하나의 대분류 클라우드 컴퓨팅 서비스 업체가 여러 개의 소분류 자원으로 구성될 수 있음


  ○ 서비스 재고 (4) : 서비스 분류별 구성요소

    ▷ 프로세스의 경우,

      - 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 프로세스, 통합

    ▷ 데이터의 경우,

      - 서비스 구성요소는 애플리케이션, 플랫폼, 인프라, 스토리지, DB, 정보

    ▷ 서비스의 경우,

      - 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 그리고 정보

    ▷ 서비스 업체가 제공하는 것을 한 예의 가상 구조적 분류를 기준의 한예

      - 프로세스 : Appian Anywhere를 통한 프로세스 서비스.

      - 데이터 : 아마존 EC2(Elastic Computing Cloud)를 통한 인프라 서비스와 아마존 Simple DB를 통한 데이터베이스 서비스.

      - 서비스 : 아마존 EC2를 통한 인프라 서비스

       · 사용자는 데이터를 아마존 EC2 플랫폼뿐 아니라 아마존 Simple DB에 저장할 수도 있다.

       · 그 다음, 사용자는 가령, 해당 플랫폼 내에서 온디맨드(On-Demand) 방식으로 제공되는 애플리케이션(application) 서버를 이용해 아마존 EC2 플랫폼 상에서 서비스를 구축 및 호스팅할 수 있다.

       · 끝으로, 사용자는 이런 프로세스들이 운용될 플랫폼으로 Appian Anywhere를 사용할 수 도 있다.

       · 프로세스가 서비스와 연결되고, 서비스는 데이터에 연결된다는 점을 명심하라. 사용자는 여기서 단지 대상 플랫폼을 선정할 뿐이다.

    ▷ 예를 들면, 하나의 PaaS(Platform-as-a-Service) 공급업체가

      - 스토리지, 데이터베이스, 프로세스, 보안 그리고 테스팅 서비스를 한꺼번에 제공할 수도 있다.

      - 여러 개의 소분류 자원을 제공하는 하나의 대분류 클라우드 컴퓨팅을 사용하는 것이 더 편할 수도 있겠지만, 판단은 전적으로 사용자 아키텍처의 요구사항 몫이다.

    ▷ 요구사항 및 자체 아키텍처와의 완벽한 연결을 고려했을 때, 여러 개의 소분류 클라우드 솔루션을 선택하는 것이 사용자의 아키텍처와 더 잘 어울린다고 판단할 수도 있다.

    ▷ 그러므로 클라우드 컴퓨팅 서비스 업체 카테고리 후보를 다음과 같은 아키텍처상의 구성요소를 기준으로 생각하는 것이 도움이 된다.

    ▷ 더 많은 클라우드 컴퓨팅 공급업체가 관련된 좀 더 복잡한 예를 살펴보자.

      - 프로세스 : Appian Anywhere를 통한 프로세스 서비스와 세일즈포스닷컴을 통한 애플리케이션 서비스

      - 데이터 : 3Tera Cloudware와 아마존 EC2를 통한 인프라 서비스 그리고 아마존 Simple DB를 통한 데이터베이스 서비스

      - 서비스 : 아마존 EC2, 3Tera Cloudware를 통한 인프라 서비스와 세일즈닷컴을 통한 애플리케이션 서비스, 그리고 세일즈포스닷컴의 포스닷컴

(Force.com)을 통한 플랫폼 서비스

    ▷ 혹은, 다음과 같이 단일 클라우드 컴퓨팅 공급업체를 통해 간단한 방식을 택할 수도 있다.

      - 프로세스 : 아마존 EC2를 통한 프로세스 서비스

      - 데이터 : 아마존 EC2를 통한 인프라 서비스

      - 서비스 : 아마존 EC2를 통한 인프라 서비스

    ▷ 이뿐만 아니라, 사용자는 자신의 필요에 따라 구내 또는 클라우드에 설치할 수 있는 보안, 테스팅, 그리고 거버넌스 등 다른 핵심 아키텍처 구성요소도 고려할 필요가 있다.

    ▷ 이렇게 설명하는 이유는 사용자가 가지고 있는 구조적 선택사항에 대해 설명하고 아키텍처, 최종적으로는 기업의 요구조건 충족을 위해 필요한 만큼의 선택사항을 이용하여 최종 아키텍처를 형성하기 위해 선택사항들을 어떻게 조합할 수 있는지를 보여주기 위함이다.



2. 클라우드 이전 과정


  ○ 다음 페이지의 그림은 보여준 매핑 과정 후에, 사용자가 올바른 클라우드 컴퓨팅 카테고리, 그리고 마침내는 적합한 클라우드 컴퓨팅 서비스 업체를 찾아내 자신의 프로세스, 서비스, 그리고 데이터를 좋은 클라우드 컴퓨팅 후보로 선정된 서비스 업체로 이전할 때 활용할 수 있는 전체 과정을 나타낸 것이다.


  ○ 핵심 단계는 다음과 같다.

     ① 후보 플랫폼 목록 작성

     ② 후보 플랫폼 분석과 시험

     ③ 타깃 플랫폼 선정

     ④ 타깃 플랫폼 설치

 


  ○ 아래의 그림은 프로세스의 각 단계와 프로세스, 서비스 그리고 데이터들에 대한 요구조건을 파악하고,그 요구조건들을 적합한 기술에 매핑 과정을 도시하고 있다.



   1)1단계 : 후보 플랫폼 목록 작성

    ▷ 사용자는 자신의 ”미래”아키텍처에 적합할 것으로 보이는 클라우드 컴퓨팅 플랫폼 목록을 일부 또는 전체 작성할 필요가 있다. 이를 위해서는 어떤 플랫폼들이 있는지, 어떤 카테고리에 속해 있는지 그리고 어떤 기능을 하는지 사용자가 정확하게 이해하고 있어야만 한다.

    ▷ 클라우드 컴퓨팅 솔루션이 어떠해야 하는지를 정의하는 확고 부동한 규칙은 존재하지 않는다. 그러므로 많은 소프트웨어 공급업체들이 자신들의 솔루션이 진정한 클라우드 컴퓨팅 솔루션이든 아니든, 클라우드 솔루션을 가지고 있다고 말하는 경향이 있다.

    ▷ 예를 들면, 일부 소프트웨어 공급업체들은 자사의 소프트웨어가 웹을 통해서 구내 컴퓨팅 시스템으로 다운로드 될 수 있으므로 자신들이 On-Demand 방식 또는 클라우드 컴퓨팅 플랫폼이라고 주장하고 있다. 사실은 그렇지 않다. 결국, 이 단계는 단지 목록을 주고받는 게 아니라 옥석을 구분하는 과정이다.

    ▷ 클라우드 컴퓨팅에 통달하기 위해서는 각 공급업체들이 제공하는 게 무엇인지를 이해하고 있어야 하므로 시장 상황이 어떻게 돌아가고 있는지를 꿰뚫고 있어야 한다. 그러므로 다음 두 가지 질문에 답을 할 수 있어야 한다.

      ① 필요한 것이 어떤 카테고리인가?

      ② 그 카테고리에 속해 있는 클라우드 컴퓨팅 공급업체

    ▷ 누구를 목록에 포함시킬 것인가? 채택할 카테고리는 최종 논리 아키텍처와 이 프로세스 동안 밝혀낸 요구사항에 의해 결정된다.


 1 단계에서 몇 가지 일반적인 사항들 고려해야 한다. 즉 반드시 필요한 기본적인 계층과 각 계층에서 확인해야 할 사항이 있다(<그림> 참조). 기본적인 계층으로는 스토리지, 데이터베이스, 프로세스, 서비스, 보안, 거버넌스 그리고 관리 계층 등이 있다. 아래의 그림은 핵심 아키텍처에서 요구되는 스토리지, 데이터, 애플리케이션, 거버넌스, 보안, 서비스 그리고 프로세스들의 연관 관계를 보여 주고 있다.



  ○ 스토리지 (Storage)

    ▷ 아키텍처의 일부 또는 전체를 지원하는 파일 시스템의 저장, 공유, 그리고 관리를 가능케 해주는 클라우드 서비스이다.

    ▷ 이를 위해서는 흔히 스토리지 서비스만 제공하는 클라우드 컴퓨팅 서비스 업체나 IssS의 일부로 스토리지 서비스를 제공하는 공급업체의 SaaS를 사용한다.

    ▷ 여기서 확인해야 할 사항은 용량(Capacity)과 성능이다.

      - 용량은 아키텍처 지원을 위해 필요에 따라 스토리지를 확장할 수 있게 해주는 기능이다.

      - 성능은 기업의 원활한 운영에 도움이 되는 속도로 클라우드 컴퓨팅 서비스와 파일을 교환하는 기능을 말한다.

    ▷ 여기서, 성능 문제가 가장 중요한 문제이므로 반드시 테스트를 해야 한다.


  ○ 데이터베이스 (DataBase)

    ▷ 이는 플랫폼, DB 또는 인프라 서비스를 이용한 데이터의 저장과 검색 기능이다.

    ▷ 여기서 고려할 사항으로는 클라우드를 통해 전달되는 DB에서 사용자의 아키텍처가 필요로 하는 특성과 기능이 포함되어 있는 지이다.

      - 다시 말해 내장 함수(Stored Procedures)와 트리거(Triggers), API 함수, 표준 함수, 그리고 성능 등을 확인해야 한다.

    ▷ IaaS에 국한해서 보면, 클라우드 컴퓨팅 서비스 업체들은 대개 오라클이나 MySQL 같은 잘 알려진 DB 만 제공한다.

      - DaaS(Database-as-a-Service) 공급업체들은 대개 자체 개발한 데이터베이스를 사용하므로 업체 고유의 DB 인 경우가 많다.

    ▷ 여기서도 성능이 한 몫을 한다.

      - 구내에 설치된 기존 애플리케이션은 대개 데이터 입출력 집중형이므로, 여기서도 유사한 성능 문제가 존재함을 알게 될 것이다.

      - 여러 사용자가 공유하는 플랫폼의 입출력 오버헤드(Overhead)와 인터넷을 통해 다량의 데이터를 클라우드 컴퓨팅 업체와 기업이 교환할 때 발생할 수 있는 지연시간(Latency)를 고려해야 한다.

    ▷ 이 때문에 데이터베이스 DB 를 사용하는 프로세스와 서비스 가까이에 데이터베이스를 두기로 결정할 수도 있다.

      - 이는 데이터베이스의 성능과 신뢰성을 고려한 아키텍처의 핵심 원칙이다


  ○ 프로세스 (Process)

    ▷ 대부분의 경우, 프로세스, 플랫폼, 애플리케이션, 그리고 인프라 공급업체들 상에 존재할 수 있다.

    ▷ 고려할 사항은 프로세스 공급업체가 제공하는 프로세스뿐이다.

      - 사용자가 다른 구조적 구성요소(대개는 서비스와 데이터)를 프로세스에 묶어 주어야 한다.

      - 데이터와 서비스는 시스템 내부 혹은 다른 클라우드 컴퓨팅 공급업체에 있으므로 통합 작업이 이루어지고 있는 지를 확인해야 한다.

      - 프로세스의 신뢰성 확인도 역시 사용자의 몫이다.

    ▷ SaaS 경우

      - 공급업체들은 대개 사용자가 자신의 프로세스를 생성할 수 있는 플랫폼을 제공하지는 않지만, 자신들의 플랫폼에서 사전에 구축된 프로세스를 사용하는 것은 허용한다. 왜냐하면, 공급업체가 제공하는 사전에 구축된 프로세스를 사용하면되므로 사용자가 맞춤형 주문처리 프로세스를 만들 필요가 없기 때문이다.

    ▷ IaaS와 PaaS(Platform-as-a-Service) 경우

      - 대개의 경우 스토리지, 데이터베이스, 프로세스, 애플리케이션 서비스, 개발, 그리고 테스팅이 포함된 “완벽한 스택”을 제공하는 플랫폼을 다루고 있음을 의미한다. 프로세스들은 그런 플랫폼들의 한 구성요소일 뿐이다.

       · “완벽한 스택”공급업체들은 클라우드 컴퓨팅의 원스톱 쇼핑이므로, 이런 공급업체를 이용하고 싶은 생각도 들것이다. 어떤 PaaS 공급업체의 애플리케이션 개발 기능은 엄청 마음에 드는데, 제품을 관리하는 방식이나 제공하는 프로세스 엔진은 전혀 마음에 들지 않는 경우에는 절충을 해야만 할 것이다. 많은 경우, 간편성이 희생되더라도 기업의 아키텍처에 적합한 프로세스를 활용하기 위해서는 해당 프로세스를 처리하기 위해 다른 클라우드 컴퓨팅 공급업체나 심지어는 구내 소프트웨어를 이용하는 것이 더 낫다.


  ○ 서비스 (Service)

    ▷ 일반적으로 말해서, 웹 서비스 같은 서비스는 대부분의 클라우드 컴퓨팅 플랫폼에 존재 할 수 있다.

    ▷ 하지만, 소수의 클라우드 컴퓨팅 공급업체들(플랫폼, 프로세스, 그리고 인프라 서비스공급업체)만이 서비스를 생성해서 호스팅 할 수 있는 능력을 제공한다.

    ▷ 반면, 애플리케이션, 정보 서비스 공급업체들은 자신들이 호스팅 하는 사전 구축된 서비스에 대한 액세스는 허용하지만, 서비스 수정은 불가능하다.

    ▷ 가장 일반적인 문제는 성능이다.

    ▷ 웹 서비스 같은 서비스들은 (REST나 SOAP사용에 관계없이) 서비스를 호스팅하는 플랫폼이서비스에 컴퓨팅 자원을 충분히 제공하지 못하거나 플랫폼과 네트워크를 포화상태로 만들 정도로 서비스가 너무 많을 경우에 성능 문제를 일으키는 경향이 있다.

    ▷ 실제로 서비스를 사용하여 플랫폼을 테스트하고 나서 플랫폼, 사용하는 서비스 개수, 아키텍처의 성능을 최적화하기 위해 서비스를 설계한 방식 등을 조정해야 한다.


  ○ 보안 (Security)

    ▷ 필요한 요구조건을 기반으로 아키텍처를 보호하기 위한 전략과 모델을 만들어 보안을 처리해야 한다.

    ▷ 보안은 구내 또는 클라우드 컴퓨팅 플랫폼상에 존재하는 플랫폼도 아니고 소프트웨어도 아니다. 제대로만 구현하면, 구내든 아니면 클라우드 컴퓨팅을 통해서건 보안 기능이 제공되는 위치와 역할 분담에 상관없이 아키텍처의 구조적 속성(Systematic Attribute)이 될 것이다.

    ▷ 적절한 접근방식과 요소 기술을 선택한다.

      - 이런 노력이 ID 관리와 ID 관리를 지원하는 표준을 중심으로 이루어지고 있다.

      - SOA(Service-oriented Architecture)와 클라우드 컴퓨팅을 이용한 SOA 같은 더 복잡하고 분산된 아키텍처를 지원하는 차원에서 ID 관리에 대한 관심이 높아지면서, 이 영역을 더 잘 정의하기 위한 표준의 필요성이 대두되고 있다.

    ▷ 왜 ID 관리가 필요한가?

    ▷ 이런 표준들은 모든 조직의 ID 관리 시스템을 통합된 하나로 함께 묶어 모든 사용자들이 안전하게 알 수 있도록 하는 것을 목표로 하고 있다.

    ▷ 클라우드 컴퓨팅을 사용하는 순간부터 서비스들을 내부에서만 사용하던 시절은 막을 내린다.

    ▷ 서비스를 사용하는 사람(소비자)이나 서비스를 만드는 사람(공급자)이 서로 상대방을 알지 못하면 악의적인 행동이나 부정확한 행동을 감수해야 한다.

    ▷ 그 결과 대단히 비싼 대가를 치르게 될 수도 있다.

    ▷ 클라우드 컴퓨팅에서는 이것이 현실이다.


  ○ 거버넌스 (Gorvernace):

    ▷ 거버넌스 시스템은

      - 클라우드 컴퓨팅의 각종 정책을 구현, 관리, 집행한다.

      - 속성상 런타임(Runtime)이며, 대개는 구내에 존재한다.

    ▷ 중요한 요소는 성능이다.

      - 어떤 때는 정책을 집행하면 시간지연 문제가 발생하는 경우가 있다.

      - 이에 대한 성능 저하 요소가 있는 지를 판단해야 한다.

      - 또 다른 요소는 능력이다.

      - 클라우드를 통해 전달되는 서비스에 해당하는 자원들을 관리하기 위한 거버넌스 메커니즘의 능력이다.

      - 거버넌스 기술이 리포지토리(Repository) 내에서 원격 서비스를 추적할 수 있는 능력과 실행 중에 해당 서비스들을 감시할 수 있는 능력을 가지고 있는지를 의미한다.


  ○ 관리 (Management)

    ▷ 관리 기술

      - 클라우드 컴퓨팅을 이용한 서비스 구조는 분산되어 있는 경우가 많고, 복잡한 구조이다. 이러한 클라우드 컴퓨팅 구조를 총괄하는 기술이다.

    ▷ 클라우드 도입 시에 관리 기술 확인

      - 클라우드 공급업체의 관리기술이 대화형 인터페이스를 가지고 있는 지를 확인해야 한다.

      - 핵심은 “동작을 하는지 하지 않는지를 알 수 있는 수준”에서 구내 시스템과 클라우드 컴퓨팅 기반 시스템을 모두를 볼 수 있는 관리 시스템을 제공하는 지를 검토 해야 한다.

      - 이를 바탕으로, 최소한 시스템이 다운되었는지, 그 상태가 다른 시스템에는 어떻게 영향을 주고 있는지를 파악 할 수 있다.

    ▷ 좀 더 섬세한 수준, 즉 서비스, 프로세스, 데이터, 스토리지 별로 시스템을 볼 수 있는 관리 시스템을 확보하여 문제를 진단하고, 실제로 문제가 발생하기 전에 이를 감지할 수 있는 시스템을 갖는 것이 바람직하다.

    ▷ 관리와 거버넌스는 밀접하게 연계되어 있으며, 매우 유사한 패턴을 갖는다.


  ○ 2단계 : 후보 플랫폼 분석과 시험 (Test) -1

    ▷ 사전에 설정한 요구조건을 충족시키는지 분석 및 확인

      - 이 작업은 선정한 각 후보 플랫폼을 심층적으로 분석한 다음, 시험을 통해 수행한다.

    ▷ 클라우드 시험

      - 실제로는 클라우드 컴퓨팅 플랫폼의 포괄적인 능력을 시험한다는 점에서 구내 시험과 약간 다르다.

      - 좀 더 구체적으로 말하면, 구성요소들을 실제로 플랫폼 상에 설치하기 전에 해당 클라우드 플랫폼이 서비스, 데이터, 그리고 프로세스를 포함한 구조적 구성요소의 요구조건을 어떻게 수용하는지 검토하게 될 것이다.

    ▷ 성능 모델링 (Modeling)

    ▷ 모델링은 서로 다른 유형의 부하 상태에서 시스템이 어떻게 동작해야 하는지에 대한 시뮬레이션을 만들어 낸다. 대개 경량, 중급, 대량으로 구분한다.

      - 어떻게 정보가 흐르고 어떤 서비스가 호출되는지, 그리고 그런 사항들이 구내와 클라우드 기반 컴퓨팅 자원들에게는 어떤 영향을 주는 지 등 아키텍처를 모델링하는 것을 의미한다.


  ○ 2단계 : 후보 플랫폼 분석과 시험 (Test) - 2

    ▷ 성능 시험 (Testing)

      - 성능 실험이란 부하가 걸렸을 때 아키텍처가 어떤 성능을 제공하는 지를 결정하기 위해 테스팅을 진행한다는 것을 의미한다.

      - 클라우드 컴퓨팅에서 어느 정도의 성능을 기대할 수 있는지, 그리고 처리 능력 감소와 대역폭 확장 같은 상황들이 전체 성능에는 어떤 영향을 주는지 등에 대해 감은 잡을 수 있다. 성능 모델을 입증하는 동안에는 성능 테스팅을 사용해야 한다.

    ▷ 본 후보 프랫폼의 분석과 시험 의미

      - 클라우드 기반의 전체 아키텍처가 얼마나 잘, 그리고 얼마나 빨리 업무를 지원하는지를 평가하는 것이다.

      - 더 나가서, 끊임없이 증가하는 스토리지, 데이터베이스, 프로세스, 그리고 서비스 처리 부하 상태에서 시스템이 어떤 성능을 제공하는지도 측정해야 한다.

      - 이러한 과정을 통해서 네트워크, 데이터베이스, 그리고 서비스 같은 잠재적 병목 구간을 찾아서 이를 수용하거나, 대안을 찾거나 아니면 포기하고 다른 업체를 찾을 수도 있다.


  ○ 3단계 : Target 플랫폼 선정

    ▷ 클라우드 컴퓨팅 플랫폼을 선정

      - 일단 이 모든 분석과정과 보안과 거버넌스를 감안한 다음에 후보 시스템 목록을 종합해서 검증 시험을 완료된 후에 클라우드 컴퓨팅 플랫폼을 선정한다.

      - 요구조건 충족을 하였는가?

    ▷ 클라우드 컴퓨팅 공급업체가 어떠한 상태인가?

      - 공급업체의 생존력과 사용자의 클라우드 컴퓨팅 플랫폼을 지속적으로 지원할 가능성

      - 하드웨어, 소프트웨어, 그리고 네트워크 장애로부터 복구하는 능력

      - SLA(Service Level Agreement와 사용자의 아키텍처를 위해 어느 정도의 서비스 레벨이 지원되어야 하는 지에 대한 클라우드 공급업체와 사용자 간의 공감대

      - 클라우드 컴퓨팅 공급업체의 정책과 어떤 것이 위반 사항인지에 대한 완벽한 이해


  ○ 4단계 : Target 플랫폼 설치

    ▷ 실행단계

      - 사용자가 실제로 코드를 포팅하고, 데이터를 이전하며, 새로운 서비스, 프로세스 그리고 데이터베이스를 생성하며, 이 모든 서비스, 데이터베이스, 그리고 프로세스가 제대로 동작하는지를 테스트하고 검증하는 단계이다.

      - 이전과 개발을 중심으로 하는 접근방식을 택해야 한다.

      - 가장 중요한 것부터 시작해서 중요도가 가장 낮은 것의 순서로 아키텍처 중의 어떤 구성요소를 이동시키거나 클라우드 컴퓨팅 플랫폼에서 생성해야 할지를 결정해야 한다.

    ▷ 아키텍처의 구성요소를 클라우드 컴퓨팅 플랫폼으로 이동시킬 때, 제대로 기능하는 지를 확인하고 다음 구성요소로 넘어가기 전에 적절하게 테스트되었는지도 확인한다.

    ▷ 점진적인 접근방식이 문제도 없고 클라우드 컴퓨팅 플랫폼에 서비스, 데이터, 그리고 프로세스를 설치하는 사람들이 일에 치이지 않게 해 준다.

    ▷ 이런 접근방식은 일을 해나가면서 배울 수 있는 학습 효과도 제공하므로 프로세스가 진행됨에 따라 클라우드 컴퓨팅 플랫폼을 사용자의 아키텍처에 맞게 작동시키는 방법에 대한 지식도 크게 증진될 것이다.


  ○ 최종 단계 : 새로운 클라우드 컴퓨팅 플랫폼 수용

    ▷ 실행 및 운영 단계

      - 실제로 시스템을 클라우드로 옮겨서 그 시스템들을 업무에 맞게 동작시키는 작업이다.

      - 기획이나 분석보다는 실행 작업이지만, 관련된 작업 중 가장 까다로운 작업이 기도 하므로 위험부담도 가장 크다.

    ▷ 클라우드 컴퓨팅은 아직도 변화하고 있는 중이기 때문에 광고와 시장이 뜨거워짐에 따라 매주 새로운 공급업체가 등장하고, 기존 공급업체들은 시장을 장악하기 위해 더 많은 기능성을 추가하기에 여념이 없다.

    ▷ 클라우드 컴퓨팅 플랫폼은 지속적으로 수행해야 하는 작업이다. 즉 정기적인 업그레이드, 버그 수정, 그리고 플랫폼에 대한 다른 변경사항의 원인이 되는 소프트웨어 배포가 필요하다.

    ▷ 이런 변경사항들이 전체 시스템을 더 나은 방향으로 유도하고 이런 플랫폼 상에 존재하는 아키텍처 상의 구성요소를 훼손하는 일은 없어야 한다.

댓글을 달아 주세요