Облачная служба биллинга

Модуль службы биллинга с поддержкой SOA для облачной среды

Облачный биллинг — это процесс оформления счетов по данным об использовании ресурсов с применением набора стандартных правил. Автор определяет модуль сервиса облачного биллинга для сервис-ориентированной архитектуры, охватывая как функциональные требования — службу информирования о ценах, функции и правила преобразования, схемы оплаты и идентификацию пользователей, так и нефункциональные, но важные требования, такие как обеспечение безопасности, масштабируемости, стандартизации и отказоустойчивости.

Ханс-Дитер Веле, высококвалифицированный ИТ-специалист, IBM

Ханс-Дитер ВелеВысококвалифицированный специалист по облачным вычислениям Ханс-Дитер Веле (Hans-Dieter Wehle) работает в IBM. Он входит в штат Научно-исследовательского и конструкторского центра IBM в Бёблингене (Германия) и имеет более чем 20-летний опыт работы в компьютерной индустрии, от технической поддержки на местах до разработки программного обеспечения и консалтинга. В IBM пришел в 1999 году, и с 2006 года занимается главным образом "зелеными" ИТ и облачными вычислениями; принимал участие в различных проектах IBM в области разработки.



17.10.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри:

Оптимизированный для облака компонент биллинга обеспечивает интерфейс для выставления счетов за использование ресурсов. Облачный биллинг — это процесс выставления счетов по данным об использовании ресурсов с применением набора стандартных правил. В зависимости от общей политики облачных вычислений счет может выставляться на реальные деньги или следовать более абстрактному понятию обмена — это не имеет значения, поскольку служба биллинга не зависит от конкретной экономической модели.

Настоящая статья представляет собой краткое руководство по определению модуля облачного биллинга для сервис-ориентированной архитектуры. В ней рассматриваются функциональные требования, такие как служба информирования о ценах, функции и правила преобразования, способы оплаты и задачи идентификации пользователей. Статья также охватывает важные нефункциональные требования: обеспечение безопасности, масштабируемости, стандартизации, отказоустойчивости и др.

Компоненты модуля службы облачного биллинга

Прежде всего мы рассмотрим архитектуру модуля биллинга для облака. Затем я объясню принципы политики биллинга, а также используемый язык и синтаксис. Я расскажу также о механизме правил/умозаключений и той роли, которую он играет, и закончу этот раздел кратким описанием рабочего процесса и процесса разрешения конфликтов.

Рабочий модуль: форма вытекает из функций

Модуль единой службы облачного биллинга должен предоставлять средства поддержки всех функциональных требований (они описаны в следующем разделе):

  • служба биллинга составляет счета по правилам, извлекаемым из Репозитория правил биллинга;
  • эти счета хранятся в Репозитории счетов для последующего использования менеджером.

На рисунке 1 показана общая архитектура службы учета ресурсов и выставления счетов.

Рисунок 1. Архитектура модуля
Архитектура модуля

Процесс составления счета не автоматизирован и должен быть инициирован менеджером. Вся функциональность службы реализована в виде Web-сервиса.

На рисунке 2 показан модуль с технологической точки зрения и иллюстрируются различные компоненты, а также взаимодействие между различными технологиями.

Рисунок 2. Модуль с технологической точки зрения
Модуль с технологической точки зрения

Служба биллинга устанавливает связь с Web-сервером через PHP-интерфейс и получает подтверждающий документ из Репозитория учета ресурсов (Usage Record - UR).

Правила, синтаксис и язык биллинга

Вот простой пример правил биллинга:

  • 1 ЦП/ч (час эксплуатации) равен 1 жетону;
  • скидка 20% за ЦП/ч свыше 20 ч.

Однако какими бы простыми или сложными ни были правила расчетов, наступит время, когда менеджер ресурсов захочет их изменить. Учесть все варианты просто невозможно, а изменение исходного кода при каждом добавлении нового правила ― конечно, не выход.

Важно сделать четкое разграничение между логикой биллинга, которая приводит к окончательному результату, и правилами биллинга, которые определяют принципы составления счетов. Правила биллинга не являются частью службы; они представляют собой внешний элемент, который использует служба биллинга. Эти правила составляются менеджером ресурсов и хранятся в репозитории. Служба биллинга использует этот репозиторий для извлечения правил, необходимых для составления окончательного счета.

Предположим, что нужно формализовать два правила, приведенных выше в качестве примера. Можно написать что-то вроде: пусть (cpu_h(x) - x часов ЦП, а token(x) - x жетонов; тогда

(1)# bill = token(cpu_h(x));
(2)# if 
         cpu_h(x) > 20
     then
         bill = bill*.8;

Эта запись учитывает оба правила; однако в ней кроются две важные проблемы:

  • она составлена не на естественном языке;
  • она не позволяет учесть все случаи.

Человек, который составляет правила биллинга, не обязательно должен быть программистом, и составление такой записи может оказаться затруднительным. Намного проще было бы выразить правила биллинга на естественном языке.

Вторая проблема заключается в том, что с помощью такой записи очень трудно выразить широкий спектр сложных правил. Бизнес-правила могут очень быстро меняться, а с ними и правила биллинга. Выполнить требование возможности изменения правил в будущем можно только с использованием мощного синтаксиса правил.

Существуют также различные языки, используемые для описания правил; у каждого из них свои преимущества и недостатки.

Естественный язык позволяет выражать правила на простом английском языке:
When the event is VM Assignment and the client's type is Platinum, then the cost per second is 0.0002 euros. (При событии VM Assignment для клиента типа Platinum тариф за одну секунду составляет 0,0002 евро.)

Естественный язык прост в применении и не требует обучения. Это наиболее привлекательный язык для пользователей, не имеющих специальных знаний по вычислительной технике.

Описание тех же правил на языке предметной области (с использованием того же синтаксиса и семантики, что и в спецификации) выглядит следующим образом:
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (секунд), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (евро, фунтов и т.п.)

Язык предметной области лучше структурирован и позволяет легче вносить изменения, чем естественный язык.

Подробнее о прямых умозаключениях

Прямые умозаключения, или умозаключения, направляемые данными (основанные на логическом принципе модус поненс: если P, то Q; если P истинно, то и Q истинно) ― один из двух основных методов умозаключений при использовании логических правил, синтаксических правил или функций, которые принимают исходные условия и возвращают результат. При прямом умозаключении, отталкиваясь от предоставленных данных, выполняют итерации в попытке получить другие (новые) данные ― до тех пор, пока не будет достигнута цель. (Другой метод ― обратные умозаключения, когда отталкиваются от цели и двигаются назад, чтобы проверить, отвечают ли этой цели отдельные данные; оба метода основаны на принципе модус поненс, но обратные умозаключения считаются умозаключениями, направляемыми целью.)

Одним из преимуществ прямых умозаключений перед обратными является то, что поступление новых данных может вызвать новые умозаключения. Это делает механизм лучше приспособленным к динамическим ситуациям, в которых условия могут меняться.

Механизм правил/умозаключений и его роль

Механизм правил/умозаключений представляет собой часть системы, которая оценивает правила на основе состояния системы или данных, вводимых пользователем. Одного синтаксиса правил недостаточно: нужен также механизм утверждения правомерности правил и их оценки. Именно для этого и предназначен механизм обработки правил.

Описываемый здесь механизм ― это механизм обработки правил с прямыми умозаключениями, использующий расширенную реализацию алгоритма Rete. На текущем этапе разработки мы с коллегами оцениваем несколько механизмов обработки, и два из них привлекли наше внимание:

  • ACEL от IBM (Autonomic Computing Expression Language - Язык автономных вычислительных выражений), разработанный в рамках проекта Autonomic Computing Policy Language (Язык автономных вычислительных правил) для описания условий применения правил к управляемой системе;
  • чтобы придерживаться отраслевых стандартов, нужно использовать в качестве интерфейса программирования Java™ Rule Engine API (JSR94).

Правила биллинга вводятся и редактируются посредством простого Web-интерфейса. Рассмотрим структуру механизма правил/умозаключений.

Рисунок 3. Механизм правил/умозаключений
Механизм правил/умозаключений

Подробнее об алгоритме Rete и сопоставлении с эталоном

Алгоритм Rete (произносится рэй-ти или ри-ти) представляет собой эффективный алгоритм сопоставления с эталоном для реализации систем производственных правил, который стал основой многих популярных экспертных систем. Название Rete происходит от латинского слова, означающего сеть.

Алгоритм Rete расходует много памяти ради увеличения быстродействия; он превосходит более медленную реализацию проверки правила за правилом (проверить, соответствуют ли данные правилу > Отбросить правило, если нет; сохранить, если да > Перейти к следующему правилу > Перебрать все правила и вернуться к начальному) путем создания сети (часть Rete правила), каждый узел которой соответствует эталону из условной части "если" правила. Rete записывает информацию "данные-факты" в рабочую память. Это позволяет системам совместно использовать данные узлов для исключения избыточности; сохранять частичные совпадения при объединении фактов разного типа (что избавляет систему от необходимости пересмотреть все факты всякий раз при внесении изменений); а также эффективно высвобождать память, когда факты удаляются из рабочей памяти.

Процесс сопоставления новых или существующих фактов с производственными правилами называется сопоставлением с эталоном. Существует ряд алгоритмов, используемых механизмами обработки правил для сопоставления с эталоном. Правила хранятся в производственной памяти, а факты, которые механизм умозаключений сопоставляет с эталоном, - в рабочей памяти.

Факты записываются в рабочую память, где они изменяются и откуда извлекаются. Когда в системе большое количество правил и фактов, может оказаться, что для одного и того же набора фактов справедливо несколько правил; такие правила называют конфликтующими. Программа управляет порядком этих конфликтующих правил с помощью стратегии разрешения конфликтов.

Рабочий процесс и стратегия разрешения конфликтов

Под рабочим процессом я понимаю порядок очередности правил при их оценке (какое правило должно оцениваться первым). Под разрешением конфликтов я понимаю определение того, какое правило должно применяться, если истинными признаны несколько правил. Оба эти пункта важны и должны присутствовать в успешном в модуле службы биллинга.

А теперь давайте перейдем к краткому обсуждению функциональных требований.


Функциональные требования к модулю биллинга

Здесь я кратко опишу функциональные требования, предъявляемые к модулю облачного биллинга.

Служба информирования о расценках

Облачная служба должна поддерживать информирование о расценках, чтобы пользователи могли справляться о них, прежде чем использовать ресурс. Например: «Сколько будет стоить запуск того-то и того-то в данном вычислительном узле?» Расценки не должен обязывать и должны действовать лишь в течение некоторого короткого периода времени.

Функция преобразования и правила

Облачная служба должна реализовывать функцию преобразования, которая конвертирует записи об использовании ресурсов в денежные знаки, основываясь на схеме преобразования, — например: "Стоимость 1 ЦП/час = 1 жетону", — и определять денежное выражение жетона в зависимости от экономической модели и спроса. Облачная служба должна позволять владельцу ресурса предоставлять его с настраиваемыми моделями преобразования, чтобы лучше соблюдать свои интересы.

Процесс идентификации клиента (лица)

Облачная служба должна обеспечивать идентификацию лица которое платит за использование ресурсов. Пользователь может принадлежать к другой виртуальной организации и решать несколько задач; в этом случае важно определить, кто должен платить за каждую задачу. Может также оказаться, что работа оплачивается из разных бюджетов, например, в зависимости от наличия средств.

Функции и правила схемы расчетов

Облачная служба должна поддерживать, как минимум, одну схему оплаты. Например, схему оплаты по факту, предоплаты (скажем, при бронировании машинного времени) или схему регулярных платежей.

Облачная служба должна обладать гибкостью с точки зрения схемы ценообразования (которая со временем может меняться) или иметь различные тарифы, такие как повременная оплата, фиксированная плата, аккордная оплата или амортизационные отчисления. Пример политика может выглядеть следующим образом:

EVENT = "VM Assignment", 
CLIENT_TYPE = "Platinum", 
RESOURCE_TYPE = "BLADE Type 4", 
RESOURCE_AGE < 240 * 60 * 60 (секунд), 
SERVICE_LEVEL = "Platinum", 
COST_PER_SECOND = 0.0002 (евро)  

EVENT = "ONE_OFF SERVICE 1", 
RESOURCE_TYPE = "BLADE Type 4", 
ONE_OFF_COST = 1

Нефункциональные, но важные требования

Для удовлетворения важных нефункциональных требований, предъявляемых к облачному модулю биллинга, он должен, как минимум, поддерживать:

  • безопасное выполнение своих операций;
  • проверку подлинности на основе ролей;
  • контрольный след для анализа деятельности.

В частности, необходимо принять меры к предотвращению инициирования событий неавторизованными клиентами или запуск процесса биллинга без надлежащей аутентификации или санкции.


Заключение

Этот детальный анализ модуля биллинга для облачной среды познакомил читателя с некоторыми соображениями, позволяющими ему обдумать свой собственный план разработки. Мы рассмотрели, как модуль вписывается в службу учета ресурсов и выставления счетов и в общую облачную инфраструктуру. Привели примеры правил биллинга, а также синтаксиса и языка и углубились в работу механизма правил/умозаключений. Кроме того, мы представили перечень функциональных требований, предъявляемых к модулю биллинга, и нефункциональных, но важных требований, которые также необходимо рассмотреть.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы в первый раз заходите в developerWorks. Выберите данные в своем профиле (имя, страна/регион, компания) которые будут общедоступными и будут отображаться, когда вы публикуете какую-либо информацию. Вы можете изменить данные вашего ИБМ аккаунта в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, SOA и web-сервисы
ArticleID=840903
ArticleTitle=Облачная служба биллинга
publish-date=10172012