![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
컴포넌트를 클라우드에 최적화하는 목적은 사용 요금 청구서를 생성하기 위한 인터페이스를 제공할 수 있기 위함이다. 클라우드 청구는 미리 정의된 청구 정책 세트를 사용하여 자원 사용 데이터에서 청구서를 생성하는 프로세스이다. 개별적인 클라우드 컴퓨팅 일반 정책에 따라 실제로 돈을 청구하는 것일 수도 있고 더 추상적인 교환의 개념을 지칭하는 것일 수도 있지만, 청구 서비스에서는 특정한 경제 모델을 사용하도록 지정하지 않으므로 이는 중요하지 않다.
본 기사는 서비스 지향 아키텍처 환경에 적합하게 설계된 클라우드 청구 서비스 모듈을 정의하는 방법을 보여주는 간단한 안내서라 할 수 있다. 이 기사에서는 견적 서비스, 변환 기능 및 정책, 지불 방법 및 사용자 식별 문제와 같은 기능적 요구사항을 다룬다. 보안, 확장성, 표준 및 내결함성과 같이 필수적인 비기능적 요구사항도 다룬다.
우선, 클라우드를 위한 이런 청구 모듈의 아키텍처부터 살펴보자. 그런 다음, 청구 정책과 사용되는 언어 및 구문의 바탕이 된 사고를 설명하겠다. 또한, 규칙/추론 엔진과 이 엔진의 역할을 설명한 다음, 워크플로우 및 충돌 해결에 대해 간단히 논하는 것으로 이 섹션을 마무리하겠다.
일반적인 클라우드 청구 서비스 모듈은 다음과 같이 모든 기능적 요구사항을 지원하는 포트 유형을 제공해야 한다(다음 섹션에서 설명함).
- 청구 서비스는 청구 정책 저장소(Billing Policies Repository)에서 검색되는 정책에 따라 청구서를 생성한다.
- 청구서는 이후에 관리자가 사용할 수 있도록 청구서 저장소(Bills Repository)에 저장된다.
그림 1은 회계 및 청구 서비스의 일반적인 아키텍처를 나타낸 것이다.
그림 1. 모듈의 아키텍처
청구서 생성 프로세스가 자동화되어 있지 않으므로 관리자가 이 프로세스를 시작해야 한다. 이 서비스의 모든 기능은 웹 서비스로 구현된다.
그림 2는 기술 관점에서 이 모듈을 나타낸 것으로, 다양한 서브컴포넌트와 이런 다양한 기술 간의 상호작용을 보여준다.
그림 2. 기술 관점에서 본 모듈
청구 서비스에서는 PHP 인터페이스를 통해 웹 서버에 대한 연결을 설정하고 사용 레코드 저장소(UR(Usage Record) Repository)에서 레코드 문서를 가져온다.
간단한 청구 정책의 예는 다음과 유사한 서술문이다.
- 1 CPU/h(사용 시간)는 1개의 토큰과 같음
- 20시간 이상의 CPU/h에 대해 20% 할인
하지만, 청구 정책을 간단하게 만들든 복잡하게 만들든 상관없이, 자원 관리자가 정책을 수정하려고 할 때가 있을 것이다. 모든 경우를 포괄한다는 것은 절대로 불가능하며 정책을 새로 추가할 때마다 소스 코드를 변경하는 것도 물론 가능하지 않다.
최종 청구 금액을 계산하는 청구 논리와 청구서 생성 방법에 대한 지침을 설정하는 청구 정책을 분명히 구분하는 것이 중요하다. 청구 정책은 서비스에 포함되지 않고 청구 서비스에서 사용하는 외부 요소를 구성한다. 자원 관리자가 청구 정책을 작성하여 저장소에 저장한다. 청구 서비스는 이 저장소를 사용하여 최종 청구서를 생성하는 데 필요한 지침을 추출한다.
예제로 언급한 위 두 가지 정책을 형식화한다고 가정해보자. 그러면 CPU 시간을 x로 하는 (cpu_h(x)와
토큰 수를 x로 하는 token(x)를 사용하여 다음과 같이 작성할 수 있을 것이다.
(1)# bill = token(cpu_h(x));
(2)# if
cpu_h(x) > 20
then
bill = bill*.8;
|
이 표기법에서는 두 가지 정책을 모두 캡처했지만, 다음과 같은 두 가지 주요 문제점이 발생한다.
- 자연어가 아니다.
- 모든 경우를 포괄할 수는 없다.
청구 정책을 설정하는 사람이 반드시 프로그래머란 법이 없으므로 이런 표기법으로 작성했을 때 프로그래머가 아닌 사람은 이해하기가 정말 어려울 수 있다는 점을 기억하자. 이런 표기법보다는 좀 더 쉽게 이해할 수 있는 자연어로 청구 정책을 표현하는 것이 훨씬 더 쉽고 자연스럽다.
두 번째 문제점은 이 표기법을 사용하여 다양하고 복잡한 정책을 표현하기가 무척 어렵다는 점이다. 비즈니스 규칙은 상당히 빠른 속도로 변화할 수 있으며, 청구 규칙도 이런 변화를 따라가야 한다. 미래의 정책적 요구사항 예측은 강력한 규칙 구문을 통해서만 완료할 수 있다.
정책을 설명하기 위해 다른 유형의 언어도 사용되는데, 각 언어마다 고유의 장점과 단점이 있다.
자연어를 사용할 경우 다음과 같이 평이한 말로 규칙을 표현할 수 있다.
이벤트가 VM Assignment이고 클라이언트의 유형이 Platinum인 경우 초당 비용은 0.0002유로이다.
자연어는 사용하기 쉽고 배우기도 쉽다. 그리고 컴퓨터를 능숙하게 다루지 못하는 사용자에게 가장 전달력이 강하다.
(스펙 문서에 사용되는 것과 같은 구문과 시맨틱을 사용하는) DSL(Domain Specific Language)로 위와 동일한 정책을 설명하면 다음과 같은 형태가 된다.
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (seconds), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (Euros, Pounds, etc.)
DSL은 자연어보다 더 구조적이고 더 쉽고 빠르게 편집하고 변경할 수 있다.
규칙/추론 엔진은 시스템 상태나 사용자 입력을 바탕으로 규칙을 평가하는 시스템의 한 요소이다. 정책 구문이 있는 것으로는 충분치 않다. 정책의 유효성을 어설션하고 정책을 평가할 메커니즘도 있어야 한다. 이것이 바로 규칙 엔진의 설계 목적이다.
필자가 설명하려는 엔진은 Rete 알고리즘의 향상된 구현을 사용하는 전향 연쇄 짓기 규칙 엔진이다. 이 개발 단계에서 동료와 나는 여러 가지 규칙 엔진을 평가하는 프로세스를 진행하면서 다음 두 가지 사항에 주목했다.
- IBM의 ACEL(Autonomic Computing Expression Language)은 원래 관리 시스템에 정책을 적용해야 할 때의 조건을 설명하기 위해 Autonomic Computing Policy Language의 일부로 개발되었다.
- 산업 표준을 사용하려면 Java™ Rule Engine API(JSR94)를 프로그래밍 인터페이스로 사용해야 한다.
간단한 웹 프론트엔드를 통해 청구 규칙을 입력하고 수정한다. 규칙/추론 엔진의 구조를 살펴보자.
그림 3. 규칙/추론 엔진
프로덕션 규칙에 맞춰 새로운 사실이나 기존 사실을 일치시키는 프로세스를 패턴 일치라 한다. 규칙 엔진은 패턴 일치를 위해 여러 가지 알고리즘을 사용한다. 규칙은 프로덕션 메모리에 저장되고 추론 엔진은 작동 중인 메모리의 데이터와 사실의 일치 여부를 검사한다.
사실이 수정되거나 취소된 작동 중인 메모리에 사실이 삽입된다. 규칙과 사실의 수가 많은 시스템에서는 동일한 사실 어설션에 대해 많은 규칙이 True가 되며, 이런 규칙은 충돌 상태에 있다고 말한다. 어젠더는 충돌 해결 전략을 사용하여 이렇듯 충돌하는 규칙의 실행 순서를 관리한다.
여기서 워크플로우란 규칙을 평가할 때의 규칙 우선 적용 순서(어떤 규칙을 먼저 평가해야 하는가?)를 의미한다. 충돌 해결이란 둘 이상의 규칙이 True로 평가되는 경우 어떤 규칙을 실행할지 정하는 것을 의미한다. 이 두 가지 사항 모두 중요하며 성공적인 청구 서비스 모듈에 있어야 할 사항이다.
다음으로, 기능적 요구사항을 간결하게 설명하는 단계로 바로 넘어가자.
이제 클라우드 청구 모듈에서 고려할 기능적 요구사항을 간단 명료하게 정리하겠다.
클라우드 브로커링 인스턴스는 사용자가 견적을 요구한 후 자원을 사용할 수 있도록 견적 서비스를 지원해야 한다. 예를 들어, "그 컴퓨팅 사이트에서 이런저런 것을 실행하려면 얼마나 드는가?"와 같은 것이다. 견적에 구속력을 부여하면 안 되고 견적은 짧은 시간 동안 유효할 뿐이다.
클라우드 브로커링 인스턴스는 기본적인 변환 스킴(예: 1CPU/h의 비용 = 인스턴트당 토큰 1개)에 따라 사용 레코드에서 통화로 변환하는 변환 함수를 구현하고 경제 모델과 수요에 따라 토큰의 금전적 가치를 협상해야 한다. 클라우드 브로커링 인스턴스는 자원 소유자가 자신의 이익에 더욱 부합하도록 이 인스턴스에 사용자 정의 변환 모델을 제공하도록 허용해야 한다.
클라우드 브로커링 인스턴스는 엔티티 식별이 자원 사용량에 맞춰 청구되도록 허용해야 한다. 사용자가 다른 가상 조직에 속해 있고 여러 작업을 실행할지도 모르며, 이 경우에는 각 작업에 대해 누가 요금을 지불해야 할지 식별하는 것이 중요하다. 인스턴스에 대해 돈을 쓸 수 있느냐에 따라 다른 예산 항목에서 작업 비용이 지불되는 일도 발생할 수 있다.
클라우드 브로커링 인스턴스는 최소한 하나 이상의 지불 스킴을 지원해야 한다. 어떤 경우에는 사후 지불, 사전 지불(인스턴스 예약 시점에) 또는 계속 지불 스킴을 허용하고 있다.
클라우드 서비스는 (시간에 따라 변할 수 있는) 주제에 대한 가격 결정에 유연성이 있거나 사용 요금, 고정 요금, 일회성 요금 또는 할인과 같은 다양한 요금제가 있어야 한다. 예를 들어, 정책은 다음과 같은 형태일 수 있다.
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE < 240 * 60 * 60 (seconds), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (Euros) EVENT = "ONE_OFF SERVICE 1", RESOURCE_TYPE = "BLADE Type 4", ONE_OFF_COST = 1 |
클라우드 청구 모듈에 대한 비기능적이지만 필수적인 요구사항을 해결하려면 모듈에 최소한 다음과 같은 기능이 있어야 한다.
- 트랜잭션을 안전하게 수행하는 능력
- 역할 기반 인증
- 활동을 분석하기 위한 감사 내역
특히, 권한 없는 클라이언트나 사기꾼이 정당한 인증 또는 권한 없이 이벤트를 보내거나 청구 프로세스를 트리거하지 못하도록 하기 위한 단계를 수행해야 한다.
클라우드 환경 청구 모듈을 철저히 분석하여 그 세부사항을 살펴봄으로써, 고유의 클라우드 청구 모듈 개발을 계획할 때 숙고할 고려사항을 몇 가지 확인해보았다. 필자는 어떻게 회계 및 청구 서비스에 적합한 모듈을 개발하고 전체 클라우드 인프라에 맞춰 조정할지에 대한 비전을 제시했다. 청구 정책과 구문 및 언어에 대한 예제를 살펴보며 규칙/추론 엔진의 작동 방식을 심층적으로 파악해보았다. 필자는 청구 모듈에 대한 기능적 요구사항 외에도 역시 고려해야 할 비기능적이지만 필수적인 요구사항을 정리한 체크리스트도 제시했다.
교육
-
이 튜토리얼에서는 XML 문서로 작성된 Autonomic Computing Expression Language의
사용 방법을 보여준다.
-
developerWorks 클라우드 개발자 자원에서는 클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
-
다음 단계: IBM Smart Business Development and Test on the IBM Cloud에 액세스하는 방법을 확인하자.
제품 및 기술
-
IBM Smart Business Development and Test on the IBM Cloud에서 사용 가능한 제품 이미지를 확인하자.
토론
-
developerWorks의 클라우드 컴퓨팅 그룹에 참여하자.
-
developerWorks에 있는 뛰어난 클라우드 블로그를 모두 읽어보자.
-
연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 developerWorks 커뮤니티에 참여하자.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그