난이도 : 초급 Nicholas Chase, 회장, Chase & Chase, Inc.
2004 년 2 월 17 일
2004 년 10 월 21 일 수정 자율 컴퓨팅이 살아있는 생물들처럼 컴퓨터를 작동하도록 하는 과정이라면 자율 컴퓨팅 개발자는 자신이 만든 제품 및 시스템 기능이 제대로 수행되고 있는지를 검사하는 의사와 같은 존재이다. 제품 및 시스템에 문제가 발생한 경우 여러분은 그 부분을 진단해 고친 다음 기능이 제대로 되는지 확인하게 된다. 이 글에서는 자율 컴퓨팅 개념을 여러분의 제품에 구현하기 위한 초석을 다질 것이다. (주: IBM Autonomic Computing Toolkit Release 2로 업데이트)
자율컴퓨팅: 신속한 문제해결
간단히 말해 시스템 관리자는 시스템 자체에서 행해지는 반복적 업무를 수행하는 데 너무 많은 시간을 허비한다. 예를 들어 회계시스템 관리자 미셸이 새 부기 클라이언트를 설치할 때 그녀는 운영체계, 작동시간 및 환경, 그리고 클라이언트 설치 전 드라이브 공간 및 램 용량을 점검하는 방법을 알지 않아도 된다. 클라이언트 설치 프로그램에서는 그녀의 업무를 체크하고 가급적 반복적 업무를 수행하기 전 발생하는 문제를 해결한다.
게다가 데이터베이스 로그 파일이 해당 드라이브를 채우는 경우 시스템에서는 새 로그파일을 제공해 시스템 관리자가 로그파일을 살펴보면서 손수 작성하는 일을 하지 않아도 된다. 해커 국제 공동체에서 여러분의 서버를 공격대상으로 삼을 때 서버에서 자가 방어 기능이 작동되어 서버가 완전 정지 되지 않는다.
이처럼 자율 컴퓨팅 영역은 계속 진화, 발전되고 있다. 하지만 많은 경우 자율 컴퓨팅 툴이 시중에 나와 있어 여러분은 이를 가지고 애플리케이션을 자율화한다. 이 글에서는 애플리케이션 및 시스템을 자체 충족시키기 위해 여러분이 오늘날 사용하는 자율 컴퓨팅 툴에 관해 나와 있다.
자율 컴퓨팅 기술에 대한 실상
새로운 기술이 등장할 때마다 그 기술에 대해 생각하거나 글로 개제하면서 논의하는 기간이 있기 마련이다. 하지만 이를 실지로 사용하는 방법에 대해서 확실히 아는 사람은 아무도 없다. 기술이 흥미로울수록 이에 대한 화두를 내놓는 사람들도 많아지는 법이다. 자율 컴퓨팅 환경은 시스템 관리자에게 정기적으로 주어지는 매일의 워크로드 양을 상당부분 줄여준다는 점에서 상당히 흥미로운 주제다. 따라서 이에 대한 화두가 많이 생긴다. 하지만 여러분이 아는 지식 가지고는 자율 컴퓨팅 환경을 다룬다는 건 좀 어려운 일이다.
하지만 자율 컴퓨팅 환경이 복잡하거나 견고하게 보이기 때문에 어려워할 필요는 없다. 다행히도 이 환경으로 전 세계를 주름잡을 시스템을 구축하는 것은 아니다. 어쨌든 가까운 미래에 벌어지는 일은 아니다.
하지만 비즈니스 목표와 일치하는 시스템 기능을 수행하는 첫 기초 단계를 밟는 것에 관해 말하고자 한다. 이 기초단계가 바로 자율 컴퓨팅 환경에 있어 중요하다. 필자가 다시 말하고자 한다. 우리는 여러분의 비즈니스 규칙 변환에 관해 얘기하고자 하는 게 아니다. 다만 여러분의 비즈니스를 통해 비즈니스 룰이 수행되는 방식을 얘기하고자 한다.
 |
자율 컴퓨팅 툴킷 다운로드
자율 컴퓨팅 툴, 기술, 실례 및 데모는 자율 컴퓨팅 툴킷을 다운로드 하여 얻을 수 있다. 시스템의 자가치유기능이 더 생기도록 하기 위해 자율 컴퓨팅 툴킷에 제공된 툴로 기존 애플리케이션 안에 있는 자율 컴퓨팅 기능을 실행한다. 자율 컴퓨팅 툴킷 기술, 툴을 통해 문제 진단능력을 향상시키고, 소프트웨어 설치 및 유지를 단순화하고, 시스템의 지속적 관리를 보장하며 자율 컴퓨팅 원리를 시스템 디자인에 적용할 수 있게 된다.
|
|
자율 컴퓨팅 툴킷(참고자료)내의 툴은 각각의 시스템 요소에서 인지할 뿐만 아니라 요소들끼리 서로 교신하는 아키텍처를 제공하는 첫 번째 단계로 활용된다.
자율 컴퓨팅 아키텍처는 다음과 같은 중요 기능들로 이루어져 있다. :
- 솔루션 설치 및 전개 기술
- 통합 솔루션 콘솔
- 문제 진단
- 자율 관리
- 자원 할당 및 조정
- 종합분석
- 정책-기반 관리
- 이종 워크로드 관리
이들 각각의 목표와 다루는 방법을 설명하겠다.
솔루션 설치 및 전개 기술
최근에 여러분이 주 소프트웨어 패키지를 설치한 때는? 여러분이 하드웨어 및 필수 소프트웨어의 필요조건을 만족시켰는지 그 여부를 알아내는 데 걸린 시간은? 여러분은 부가적 패키지를 다운로드 시킨 뒤 설치했는가? 이 패키지를 설치하면서 기존에 설치된 소프트웨어가 망가졌는가? 망가진 소프트웨어를 복구하는 데 걸린 시간은 얼마정도 되는가?
솔루션 설치를 시작해 소프트웨어를 설치한 위치, 설치한 필수 소프트웨어 및 기존 설치된 소프트웨어들을 보존하는 방식에 대해 설치 프로그램에서 인지한다는 판단이 들게 되면 그야말로 바람직한 것이 아닌가?
이게 바로 자동 컴퓨팅 프로그램 설치 및 전개 개념의 근거가 되는 일반적 생각이다.
일반적으로 다음과 같다. 여러분은 소프트웨어 패키지를 설치한다. 소프트웨어 패키지는 실제 코드와 실제 코드의 내용을 설명하는 디스크립터 파일, 소프트웨어 설치 전 반드시 수행되어야 하는 필수 소프트웨어로 이루어져 있다. 디스크립터/객체 패키지를 가리켜 설치가능 유닛이라 한다. 그리고 이런 유닛이 모이면 그림 1과 같은 솔루션 모듈을 이루게 된다.
그림 1. 솔루션 모듈
이 경우 전체 솔루션 모듈은 2차 솔루션 모듈 및 독립 설치가능 유닛을 포함하게 된다.
소프트웨어를 설치하기 전 설치 프로그램은 디스크립터를 판독하고 이전에 설치된 소프트웨어, 하드웨어 데이터베이스를 점검해 소프트웨어 및 하드웨어에 관한 필요조건이 만족되는지를 결정하게 된다. 만족되는 경우 소프트웨어가 설치되고 소프트웨어 정보는 데이터베이스에 부가된다. 그렇지 않은 경우 필수 소프트웨어를 다운로드, 설치하고 부가 소프트웨어를 제공하면서 대체 서버를 선택하는 등 자율 정교화 레벨에 따라 설치 프로그램에서 운영자에게 경보를 보내거나 문제 해결 등의 작업을 하게 된다.
상기 작업은 자율 컴퓨팅 툴킷에서 설명한 솔루션 설치 및 전개 기술 툴을 통해 이루어지게 된다. IBM사는 소프트웨어 설치 제품의 두 선두 업체인 InstallShield 및 ZeroG와 파트너쉽을 체결해 이와 같은 자율 컴퓨팅 기술을 InstallShield 및 ZeroG사 상품에 구현했다. 자율 컴퓨팅 툴킷은 또한 Installshield, ZeroG사에서 나온 제품이 솔루션 설치 및 전개 기술 툴을 활용해 소프트웨어 설치 과정을 자동화시키는 것에 관한 실제 과정도 포함되어 있다.
통합 솔루션 콘솔
소프트웨어는 설치된 후 관리되어야 한다. 이상적인 자율 컴퓨팅 시스템에서는 단일 득점에서부터 모든 애플리케이션이 관리된다. 이로 인해 두 가지 이점이 생기게 된다.
우선, 시스템 관리자는 여러 가지 자율 컴퓨팅 툴을 배우지 않아도 된다. 그리고 모든 정보가 단일 환경 하에 있기 때문에 결국엔 단일 시스템에서 모든 정보를 관리하게 된다.
필자는 이런 점들로 인해 정책-기반 관리 수행능력을 여러분들에게 제공하는 방식에 대해 다룰 것이다.
자율 컴퓨팅 툴킷 환경은 이미 훌륭히 갖추어져 있다. 통합 솔루션 콘솔은 브라우저 기반 환경으로 운영자로 하여금 한 장소의 모든 운영기능을 다루게 하는 기능이다. 주로 WebSphere® Studio 용 포털 툴킷에 기초해 통합 솔루션 콘솔을 개발한다. 따라서 단일 시스템 내의 포틀릿 또는 요소들로 운영 기능을 다루게 된다. 운영자가 새 소프트웨어를 추가할 때 소프트웨어 운영기능 및 도움말 파일은 일반 운영 시스템에 추가된다.
문제 진단
자율 컴퓨팅 아키텍처에서는 주로 자가-구성, 자가-치유, 자가-최적화 및 자가-보호 기능을 갖춘 시스템을 창출해 내는 것이 주 목적이다. 그런 시스템을 만들기 위해 시스템에서 문제를 인지해 원인을 진단, 적절한 치유책을 내놓아야 한다. 로그를 사용하는 것이 이에 대한 가장 합리적인 해결책이다.
애플리케이션 사용자가 문제를 발견할 경우 문제의 원인을 찾아내는 애플리케이션 로그에 관해서는 여러분이 애플리케이션 개발자라면 다 안다. 대부분 이런 로그는 일반인들이 아닌 애플리케이션 개발자들만이 안다. 시스템이 갑자기 정지되는 경우 “예상외 종료”, “예상외 정지” 또는 “도와주세요! 갑자기 종료됐어요.”라고 쓰여진 이벤트를 사용자가 찾고 있다는 것을 애플리케이션 개발자라면 다 안다.
자동화 시스템에서 문제를 진단하는 데 있어 로그 파일을 이용하려면 로그는 공통 포맷을 반드시 지녀야 한다.
그 포맷은 Common Base Events Format으로 XML-기반 문법으로 이루어져 있다.
Common Base Event V1.0.1은 11가지의 상태 목록, StartSituation, StopSituation, ConnectSituation, ConfigureSituation, RequestSituation, FeatureSituation, DependencySituation, CreateSituation, DestroySituation, ReportSituation, AvailableSituation등을 정의하고,
또한 OtherSituation 목록을 정의해 제품 특수요건을 지원한다. 애플리케이션에서 Common Base Events Format으로 이벤트를 출력하는 경우 자동 컴퓨팅 시스템에선 이런 이벤트 정보를 사용해 이벤트 및 상태 목록과 연관시키면서 문제가 발생된 경우 및 시간, 문제 해결책을 알게 된다. 예를 들어 다음과 같은 한 가지 상태(고도로 단순화됨)가 가능한 경우다.:
Listing 1. 단순화된 예
Application server can't connect to the database
+ Application server can ping database server machine
= Database is down
|
이 경우 시스템은 증상 데이터베이스를 찾아 데이터베이스가 다운되었는지의 여부를 결정한다. 그러면 시스템은 데이터베이스를 다시 재가동하면서 시스템 관리자에게 문제가 발생되었다는 메시지를 보내게 된다. (증상 데이터베이스는 또한 이벤트 및 상태 목록을 서로 연관시키는 데 중요한 역할을 한다.)
하지만 애플리케이션이 있지만 Common Data Base Format에서 이벤트가 출력되지 않는 경우엔 어떻게 되는가? 그러면 애플리케이션을 자율 컴퓨팅 시스템에 구현할 수 없다는 말인가? 이 경우 두 가지 중 하나를 선택하면 된다. 하나는 애플리케이션을 변환시키면 되고 다른 하나는 레거시 기반 이벤트를 Common Data Base Format으로 변환하는 일반 로그 어댑터를 사용하면 된다. 자율 컴퓨팅 툴킷의 일부에 포함되는 어댑터 구성 에디터 툴은 WebSphere Studio Application Developer 또는 Eclipse Platform으로 통합되고 이로 인해 여러분은 로그를 자율 컴퓨팅 시스템이 인식할 수 있는 포맷으로 바꾸는 데 있어 일반 로그 어댑터에서 사용되는 룰을 창출하게 된다.
자율 컴퓨팅 툴킷은 또한 별개의 Eclipse-기반 툴인 로그 및 추적 분석기를 포함한다. 이 툴은 다른 애플리케이션들의 로그에서부터 나온 이벤트를 보여주는 데 사용되는 실질적 인터페이스를 제공한다. 이와 관련된 이벤트가 Common Base Events format인 경우 이벤트와 상태 간의 상호관계를 볼 뿐만 아니라 이벤트 발생 순서를 알게 된다. 그렇게 되면 시스템 개발자 및 지원 스태프에게는 놀라운 진전이 아닐 수 없다.
자율 관리
자율 컴퓨팅 시스템에서 이벤트 및 상태를 발견, 제어할 때 주로 제어 루프를 사용한다. 이 루프는 취급되는 이벤트를 찾는 시스템을 계속 관리한다. 그림 2에 자율 컴퓨팅 기준 아키텍처가 나와 있으며 이 아키텍처에 의해 제어루프가 정의된다.:
그림 2: 제어 루프
제어 루프는 이벤트들을 탐지하고 다루는 시스템이다. 이벤트를 탐지하고 다루는 과정은 다음과 같은 4단계가 있다.:
-
모니터: 먼저 시스템은 로그 파일이건 인-메모리 과정이건 상관없이 센서에 의해 탐지되는 이벤트를 찾는다. 시스템은 지식베이스를 활용해 이벤트의 내용을 인식한다.
-
분석: 이벤트가 발생한 경우 지식베이스는 이벤트 해결책을 진단하는 데 도움을 주는 정보를 포함한다.
-
계획: 이벤트를 탐지하고 분석한 뒤 시스템은 지식베이스를 이용해 이벤트 해결책을 진단한다. 증상 데이터베이스는 이벤트 정보를 포함하고 중심정책 서버는 이벤트 실행에 관한 진단을 내린다.
-
실행: 계획을 체계화하면 기존 지식베이스에 나와 있는 대로 계획을 통해 실제 이벤트를 실행한다.
제어 루프가 단일 개념 프로세스이긴 하지만 단일 제품 상에서 수행될 필요는 없다. 예를 들어 IBM®Director사는 제어루프 과정 중 모니터 및 분석 과정을 수행하고 Toshiba ClusterPerfect사는 계획 및 실행 단계를 수행함으로써 두 회사 제품은 제어루프를 공유하고 있다.
한편 자율 관리 툴킷은 자율관리엔진(AME)을 포함하고 있다. 이 엔진은 제어 루프 4단계를 모두 수행한다. 물론 AME는 그다지 복잡하지 않은 제품과 교신해야 한다. 또한 AME에 적절한 리소스 모델이 있는 한 AME는 어떤 제품과도 교신한다. 로그 엔트리 또는 특수 과정 상태 가운데 리소스 모델에서 선택한 것을 AME에 나타낸다.
여러분은 WebSphere Studio Application Developer 또는 Eclipse IDE로 통합되는 자율 컴퓨팅 툴킷 리소스 모델 빌더 툴을 이용해 자신만의 리소스 모델을 만들 수 있다.
자원할당 및 조정
지금까지도 자율 컴퓨팅 아키텍처 개발은 초기 단계에 있다. 하지만 이 아키텍처에 있어 프로비저닝 분야는 가장 유용한 분야 중 하나임이 확실하다. 프로비저닝을 통해 아키텍처는 발전하고 있으며 새로운 기계들이 시스템 종업원들에게 대량으로 공급되고 있기 때문이다. 완전 자율 컴퓨팅 시스템은 새로운 통신 용량이 시스템에 할당(또는 해제)될 때, 또는 이를 자동적으로 할당, 해제할 때를 예측한다.
실제로 프로비저닝 시 두 가지 문제가 있다. 우선적으로 프로비저닝 자체에 관한 문제다. 당장 이미 사용하고 있는 기계를 이용해 통신 용량을 추가하려면 시스템 관리자는 이에 대한 조치를 내리면서 새 드라이브를 매핑하거나 최악의 경우 하드웨어를 조작하는 행위를 해야 한다. 때로는 한 장소에서 다른 곳까지 이동서버를 요구하는 상황이 생길 수도 있다. 시스템이 복잡해질수록 운영체계 및 소프트웨어를 설치하는 것과 같은 비교적 가벼운 일을 해도 에러가 많이 발생할 소지가 높다.
IBM Tivoli® Provisioning Manager와 같은 자동화 프로비저닝 툴로 시스템 관리자는 필요한 경우 잘 정의된 반복적 소프트웨어 기능 세트에 컴퓨터 지식을 구현하면서 프로비저닝 과정을 자동화한다.
하지만 프로비저닝 과정을 더 자동화할 경우는 어떤가? 시스템 관리자가 단순히 자동화과정에 대한 기능들을 정의하고 사람의 개입 없이 시스템에서 이런 기능들을 수용한다고 여기는 경우 어떻게 될까? 이런 경우 오케스트레이션을 제공하는 제품이 필요하다. 기본적으로 IBM Tivoli Intelligent Orchestrator와 같은 오케스트레이션 제품은 전 시스템을 모니터하고 자율 컴퓨팅 개념을 이용해 시스템 실행 시기를 정한다. 그런 뒤 이 제품은 시스템 관리자 또는 비즈니스 정책에 따라 정의된 대로 적절한 기능을 한다.
복합 분석
짐작했듯이 프로비저닝 및 오케스트레이션 과정 등에서는 복잡한 논리를 포함하는 것들이 있다. 자율 컴퓨팅 툴킷에 의한 자바 구현의 경우 여러분은 인공지능 유사 기능을 제공하는 JavaBeans 부품을 선택할 수도 있다.
아직도 초기 단계인 자율 컴퓨팅 툴킷은 인공지능 유사 기능을 제공하는 소프트웨어를 포함한다. 프로비저닝 및 오케스트레이션 과정 등이 이루어지는 방식을 이해하기 위해선 새로운 툴로 IBM alphaWorks (참고자료)상에서 현재 사용되고 있는 Agent Building and Learning Environment(ABLE)에 대해 아는 것이 도움이 된다.
ABLE은 다양한 데서 데이터를 읽고 쓰는 Data Beans와 같은 AbleBeans 및 순방향 추론 및 퍼지 로직 빈과 같은 의사결정 트리, 베이지안 추정 및 룰 빈과 같은 추론을 수행하는 학습 추론 등을 제공한다. AbleBeans는 룰을 이용한 AbleAgents로 통합된다. 예를 들자면 ABLE 2.0에는 역전파를 이용, 데이터를 분류하는 데 이용되는 중성 분류자를 포함한 몇 가지 에이전트 및 ABLE 2.0 유닛, 과정 및 타이머 기능을 정의하는 룰 블록이 갖추어진 룰 셋을 포함한 룰 에이전트가 반드시 따라다닌다.
정책-기반 관리
위에 나와 있는 모든 추론이 제대로 잘 진행되면 자율 컴퓨팅 시 모든 과정이 제대로 되어 가는 것처럼 보인다. 하지만 실지로는 그렇지 않다. 계획 정책에 따라 모든 결정이 이루어진다. 완전 자율 컴퓨팅 시스템에서 계획 정책들은 시스템에 걸쳐 조정된다. 지식베이스를 이용해 모든 결정이 내려지는 경우 여러분은 단일 위치에서 비즈니스 룰을 정하게 된다.
게다가 비즈니스 룰은 한 장소에서 검증 가능하다. 이와 같은 관리기법은 용이해 시스템 관리자 뿐만 아니라 주주 및 조정자를 위한 정책 승인을 해야 하는 CEO들과 같은 주주들에게 상당히 좋은 기법이다.
이종 워크로드 관리
좋다! 정책 기반 관리까지 잘 됐다. 여러분은 설치가능 유닛을 이용해 시스템에 애플리케이션을 설치했다. 또한 통합 솔루션 콘솔로 시스템을 관리하고 자율 관리 엔진을 이용해 문제를 보면서 해결했다. 그 정도면 되지 않았을까?
글쎄! 아직은 아니다. 자율 컴퓨팅 시스템은 모든 것을 처음서부터 끝까지 추적해 계속 최적화 시켜 시스템이 더 나은 성능을 보이고 문제 해결차원을 넘어서야 한다. 간단히 말해 비즈니스 워크로드 관리가 자율 컴퓨팅 시스템에서 궁극적으로 추구하고자 하는 바다.
IBM Virtualization Engine의 Enterprise Workload Manager (EWLM) 컴포넌트와 같은 제품들은 이종 워크로드 관리기능을 제공한다. 이런 제품들로 여러분은 IT 기반구조에 걸친 다중계층, 분산, 이종 또는 동종 워크로드 들을 모니터하고 관리해 최종 사용자 서비스를 더 낫게 하기 위한 명확한 비즈니스 목표를 이룩할 수 있게 된다. 이와 같은 기능들로 여러분은 서비스 부류 정의에 따른 워크 요구량을 알게 되고 서버와 하부 시스템 경계에 걸친 워크 요구량 기능을 추적해 근본적인 물리적 네트워크 자원을 관리, 각 서비스 부류에 대한 특수 성능 목표량을 정하게 된다.
EWLM과 같은 제품에서 제공되는 워크로드 관리 기능을 이용하기 위해서는 애플리케이션에서 Application Response Management (ARM) 포맷에 있는 기능정보를 제공해야 한다. EWLM용 IBM® 소프트웨어 개발 키트(SDK)는 애플리케이션 및 미들웨어에서 ARM 4.0-레벨 계측 시스템 개발, 테스트 및 EWLM ARM 어댑터 라이브러리 수행 개발 및 테스트에 도움이 되는 툴이다.
다음 단계
여러분은 시스템이 자가 구성, 자가 치유, 자가 최적화 및 자가 보호되는 툴, 기술을 활용할 수 있다. IBM 자율 컴퓨팅 툴킷을 다운로드하고 자율 컴퓨팅의 중추적 기능을 이용한 애플리케이션을 만들어내면 된다. 자율 컴퓨팅 툴킷에는 솔루션 설치, 통합 솔루션 콘솔, 문제 진단, 자율 관리와 같은 몇 가지 기능들이 포함되어 있다. 이밖에도 이 툴킷에 부가되는 소프트웨어에는 복합분석, 정책-기반 관리, 이종 워크로드 관리와 같은 기능들이 들어가야 한다.
하지만 여러분이 직접 고찰하면서 만들어보면 위의 얘기들이 사실이라는 것을 알게 된다.
참고자료
필자소개 | 
| Nicholas Chase는 Studio B의 저자이며 웹 사이트 개발 분야에서 활동하고 있다. |
기사에 대한 평가
| 
