Serviço de Faturamento de Nuvem

Um módulo de serviço de faturamento habilitado para SOA para o ambiente de nuvem

Faturamento de nuvem é o processo de gerar notas a partir dos dados de uso de recursos usando um conjunto de políticas predefinidas de faturamento. O autor define um módulo de serviço de faturamento de nuvem habilitado para uma arquitetura orientada a serviços, que preenche tanto requisitos funcionais — um serviço de cotação, funções e políticas de conversão, esquemas de pagamento e identificação de usuários — quanto requisitos não funcionais, mas essenciais, como segurança, escalabilidade, normas e tolerância a falhas.

Hans-Dieter Wehle, e-business Architect, IBM Developer Relations

Hans-Dieter WehleHans-Dieter Wehle é exímio IT Specialist em computação em nuvem da IBM. É membro do IBM R&D Design Center em Boeblingen, Alemanha, e tem mais de vinte anos de experiência no segmento de mercado de computadores, que vai do suporte de campo até a consultoria e desenvolvimento de software. Wehle passou a fazer parte da IBM R&D em 1999, desde 2006, trabalha com TI verde e soluções de computação em nuvem, e participou de vários projetos de desenvolvimento da IBM.



18/Mar/2011

O propósito de ter um componente de faturamento otimizado para a nuvem é possuir a capacidade de fornecer uma interface para gerar notas de uso. Faturamento de nuvem é o processo de gerar notas a partir dos dados de uso de recursos usando um conjunto de políticas predefinidas de faturamento. A nota pode ser referente a dinheiro real ou a uma ideia mais abstrata de troca, dependendo das políticas gerais individuais de computação em nuvem — isso não importa, pois o serviço de faturamento não especifica o uso de um modelo econômico específico.

Este artigo fornece um guia rápido, que mostra como definir um módulo de serviço de faturamento de nuvem projetado para um ambiente com arquitetura orientada a serviços. Trata de requisitos funcionais, como serviços de cotação, funções e políticas de conversão, métodos de pagamento e questões de identificação de usuários. Também aborda os requisitos não funcionais essenciais, como segurança, escalabilidade, normas e tolerância a falhas.

Partes de um módulo de serviço de faturamento de nuvem

Primeiramente, vamos esclarecer a arquitetura deste módulo de faturamento para a nuvem. Em seguida, explicarei o pensamento no qual se baseia a política de faturamento e a linguagem e sintaxe usadas. Também abordarei o mecanismo de regras/inferência e o papel que ele desempenha e, em seguida, concluirei esta seção com uma discussão rápida sobre fluxo de trabalho e resolução de conflitos.

O módulo funcional: a forma segue a função

O módulo geral de serviço de faturamento de nuvem deve fornecer tipos de porta para suportar todos os seus requisitos funcionais (descritos na próxima seção):

  • O serviço de faturamento gera notas de acordo com as políticas que recupera de um repositório de políticas de faturamento.
  • As notas são armazenadas no repositório de notas, para que o gerente as use posteriormente.

A Figura 1 mostra a arquitetura geral dos serviços de contabilidade e faturamento.

Figura 1. A arquitetura do módulo
A arquitetura do módulo

O processo de geração de notas não é automatizado, e deve ser iniciado pelo gerente. Todas as funcionalidades do serviço são implementadas em um serviço da Web.

A Figura 2 mostra o módulo sob o ponto de vista da tecnologia e ilustra os vários subcomponentes e a interação entre essas diferentes tecnologias.

Figura 2. O módulo sob o ponto de vista da tecnologia
O módulo sob o ponto de vista da tecnologia

O serviço de faturamento estabelece a conexão ao servidor da Web por meio de uma interface PHP, e obtém o documento de registro a partir do repositório Usage Record (UR).

Políticas de faturamento, sintaxe de faturamento, linguagem

Um exemplo simples de política de faturamento é semelhante às instruções a seguir:

  • 1 CPU/h (horas de uso) é igual a 1 token
  • Desconte 20% no caso de um CPU/h superior a 20 h

Independentemente de suas políticas de faturamento serem simples ou complexas, haverá um momento em que o gerenciador de recursos desejará modificá-las. Capturar todos os casos é simplesmente impossível, e mudar o código de origem sempre que você inclui novas políticas, obviamente, não é factível.

É importante fazer uma distinção clara entre a lógica de faturamento que calcula a nota final e as políticas de faturamento que definem as diretrizes de geração de notas. As políticas de faturamento não fazem parte do serviço — constituem um elemento externo que o serviço de faturamento usa. São escritas pelo gerenciador de recursos e armazenadas em um repositório. O serviço de faturamento usa esse repositório para extrair as diretrizes necessárias para gerar a nota final.

Suponha que você deseja formalizar as duas políticas que citei como exemplos. É possível criar algo semelhante a isto: (cpu_h(x) sendo x números de CPU e token(x) sendo x números de tokens e, em seguida

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

Essa notação captura as duas políticas, entretanto, possui dois grandes problemas:

  • Não é um idioma natural.
  • Não consegue capturar todos os casos.

Lembre-se: a pessoa que configura as políticas de faturamento não é necessariamente um programador, e escrever em uma notação desse tipo pode ser um grande problema. É mais fácil e natural expressar as políticas de faturamento em um idioma mais natural do que essa notação.

O segundo problema é a grande dificuldade de expressar uma variedade ampla de políticas complexas usando essa notação. As regras de negócios podem mudar muito rapidamente, e as regras de faturamento precisam acompanhar essas mudanças. Só se pode prever a necessidade de uma futura política por meio do uso de uma sintaxe de regras robusta.

Além disso, diversos tipos de linguagem são usados para descrever as políticas, cada um possui vantagens e desvantagens.

Um idioma natural permite expressar as regras em termos simples:
Quando o evento é Atribuição de VM e o tipo de cliente é Platinum, o custo por segundo é 0,0002 euros.

O idioma natural é simples de usar e possui uma curva de aprendizado plana. Isto é mais interessante para usuários que não possuem muito conhecimento de informática.

A mesma descrição de política em uma linguagem específica para o domínio (que usa a mesma sintaxe e semântica do documento de especificação) fica assim:
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.)

A linguagem específica para o domínio é mais estruturada e simples de editar e alterar rapidamente do que o idioma natural.

Mais sobre o encadeamento progressivo

O encadeamento progressivo ou inferência baseada em dados (fundamentado na regra de inferência modus ponens : se P, portanto Q; P é verdadeiro, portanto Q é verdadeiro) é um dos dois principais métodos de raciocínio para o uso de regras de inferência, regras sintáticas ou funções que tomam premissas e retornam uma conclusão. O encadeamento progressivo se inicia com os dados disponíveis, faz a iteração para frente, tentando extrair mais dados (novos), até atingir um objetivo. (O outro método é o encadeamento regressivo, no qual você começa com o objetivo e trabalha em sentido reverso, para checar se os dados granulares o suportam; ambos se baseiam na regra modus ponens, mas o encadeamento regressivo é considerado inferência baseada nos objetivos.)

Uma das vantagens do encadeamento progressivo em relação ao regressivo é o fato de que a recepção de novos dados pode acionar novas inferências — isso torna o mecanismo mais adequado para situações dinâmicas, nas quais é provável que as condições mudem.

O mecanismo de regras/inferência e o seu papel

O mecanismo de regras/inferência é a parte do sistema que avalia as regras com base no estado do sistema ou na entrada do usuário. Não basta ter a sintaxe da política — também é necessário ter um mecanismo para assegurar a validade da política e avaliá-la. O mecanismo de regras foi projetado para essa função.

O mecanismo que estou descrevendo é um mecanismo de regras com encadeamento progressivo, que usa uma implementação aprimorada do algoritmo de Rete. Nesse estágio do desenvolvimento, meus colegas e eu estamos no processo de avaliação de diversos mecanismos de regras, e dois chamaram a nossa atenção:

  • O ACEL (Autonomic Computing Expression Language) da IBM foi desenvolvido originalmente como parte da Linguagem de Políticas de Computação Autônoma para descrever as condições em que uma política deve ser aplicada a um sistema gerenciado.
  • Para usar os padrões de mercado, é necessário usar a API Java™ Rule Engine (JSR94) como interface de programação.

As regras de faturamento são inseridas e modificadas por meio de um front end da Web simples. Veja a estrutura do mecanismo de regras/inferência:

Figura 3. O mecanismo de regras/inferência
O mecanismo de regras/inferência

Mais sobre o algoritmo de Rete e reconhecimento de padrões

O algoritmo de Rete é um algoritmo eficiente de reconhecimento de padrões para implementar sistemas de regra de produção, e evoluiu para se tornar a base de vários shells de sistemas especializados bastante difundidos. Rete vem da palavra em latim que significa rede.

O algoritmo de Rete sacrifica o uso de memória para aumentar a velocidade, ele supera a implementação mais lenta da verificação dos dados em relação às regras (verificar se os dados se enquadram na regra > eliminar a regra se não se enquadrar, mantê-la caso se enquadre > mover para a regra seguinte > fazer loop/iterar de volta ao início das regras) criando uma rede ("rete") de nós, na qual cada nó corresponde a um padrão na parte condicional "if" de uma regra. O Rete armazena na memória de trabalho as informações dos dados em relação aos fatos. Isso, por sua vez, permite que os sistemas compartilhem os dados nos nós para eliminar alguns tipos de redundância, armazenem correspondências parciais ao unir tipos de fatos diferentes (o que impede que o sistema tenha que reavaliar todos os dados sempre que mudanças são introduzidas), e livrem-se de elementos de memória com eficiência quando os fatos são removidos da memória de trabalho.

O processo de estabelecer a correspondência entre fatos novos ou já existentes e as regras de produção é chamado reconhecimento de padrões. Há diversos algoritmos usados para o reconhecimento de padrões por meio dos mecanismos de regras. As regras são armazenadas na memória de produção e os fatos, correspondidos na memória de inferência, na memória de trabalho.

Os fatos são inseridos na memória de trabalho, onde são modificados ou retratados. Um sistema com um grande número de regras e fatos pode fazer com que muitas regras sejam verdadeiras para a mesma asserção de um fato — diz-se que essas regras estão em conflito. A agenda gerencia a ordem de execução dessas regras em conflito, usando uma estratégia de resolução de conflitos.

Fluxo de trabalho e estratégia de resolução de conflitos

Por "fluxo de trabalho", entende-se a ordem de precedência das regras ao avaliá-las (qual regra deve ser avaliada primeiro?). Por "resolução de conflitos", entende-se a decisão sobre a regra que deve ser disparada se mais de uma regra é avaliada como verdadeira. Esses dois pontos são importantes e devem estar presentes em um módulo de serviço de faturamento bem-sucedido.

A seguir, vamos passar a uma discussão concisa dos requisitos funcionais.


Requisitos funcionais de um módulo de faturamento

Agora detalharei sucintamente os requisitos funcionais que devem ser levados em conta em um módulo de faturamento.

O serviço de cotação

A instância de broker da nuvem deve suportar um serviço de cotação, para permitir que os usuários peçam cotações antes de usar um recurso. Por exemplo, "quanto custa a execução de tais coisas em um site de cálculo?" A cotação não deve ser vinculante, e só deve ser válida por um período curto.

A função de conversão e as políticas

A instância de broker da nuvem deve implementar uma função de conversão que converta um registro de uso para uma moeda, seguindo um esquema de conversão básico — como o custo de 1 CPU/hora = 1 token por instância — e negociar o valor monetário do token de acordo com o modelo econômico e a demanda. A instância de broker da nuvem deve permitir que o proprietário do recurso o forneça com modelos de conversão customizados para servir melhor seus interesses.

O processo de identificação de clientes (entidades)

A instância de broker de nuvem deve permitir a identificação da entidade a ser cobrada pelo uso do recurso. Um usuário pode pertencer a organizações virtuais diferentes e executar diversas tarefas, nesse caso, é importante identificar quem deve pagar por cada tarefa. Também é possível que uma tarefa seja paga a partir de orçamentos diferentes — dependendo, por exemplo, da disponibilidade de dinheiro.

Funções e políticas dos esquemas de pagamento

A instância de broker da nuvem deve suportar pelo menos um esquema de pagamento. São exemplos disso: permitir um esquema de pós-pagamento, pré-pagamento (no momento da reserva, por exemplo) ou pagamento contínuo.

O serviço de nuvem deve ter flexibilidade em termos de precificação do tema (que pode mudar com o tempo) ou ter tarifas diferentes, como tarifas por uso, tarifas fixas, tarifas únicas ou descontos. A política pode se assemelhar a isto, por exemplo:

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

Requisitos não funcionais, mas essenciais

Para tratar dos requisitos não funcionais essenciais de um módulo de faturamento de nuvem, o módulo deve possuir, no mínimo:

  • A capacidade de proporcionar segurança às suas transações
  • Autenticação baseada na função
  • Trilhas de auditoria para permitir a análise da atividade.

Especificamente, é necessário tomar providências para impedir que clientes desautorizados ou impostores enviem eventos ou acionem o processo de faturamento sem a devida autenticação ou permissão.


Conclusão

Ao detalhar a anatomia de um ambiente de nuvem, você pode ver algumas questões que devem ser levadas em conta no planejamento para o desenvolvimento da sua própria nuvem. Ofereci uma visão do papel do módulo dentro dos serviços de contabilidade e faturamento e de seu papel na infraestrutura de toda a nuvem. Você viu exemplos de políticas de faturamento, sintaxe e linguagem, e conheceu mais profundamente o funcionamento do mecanismo de regras/inferência. Também forneci uma lista de verificação de requisitos funcionais para um módulo de faturamento e dos requisitos não funcionais, mas essenciais, que também deve ser levado em conta.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing, WebSphere
ArticleID=643673
ArticleTitle=Serviço de Faturamento de Nuvem
publish-date=03182011