Inventário da Carga de Trabalho Lambda

Crie um registro de migração com evidências suficientes para reproduzir e comparar o comportamento da origem.

Para inventariar a carga de trabalho lambda, siga estas etapas:

  1. Configuração de registro, caminho de implantação, dependências, camadas, bibliotecas nativas, variáveis de ambiente, definições de VPC, função do IAM, triggers, proprietário e contatos operacionais.
  2. Capture métricas de linha de base: taxa de chamada, simultaneidade de pico, duração de p95 e p99, duração máxima, memória usada, tamanhos de payload, erros, timeouts, aceleradores, repetições, contagem de DLQ ou falha, idade da fila ou backlog, limites de alarme e limites de capacidade downstream.
  3. Salve eventos de sucesso representativos, eventos malformados, eventos duplicados, casos de timeout, falhas de permissão, amostras de falha downstream e exemplos de log de origem com valores confidenciais ocultados.

Procure: Um registro de inventário completo com links de evidência, notas de risco iniciais e lacunas que precisam de confirmação do proprietário.

Saída: Não confie apenas nas exportações de configuração. Logs, métricas, alarmes e eventos representativos geralmente revelam um comportamento que a configuração sozinha não mostra.

Avaliar Cada Função de Amostra para Migração do OCI Functions

Registre os requisitos, as alterações necessárias e a decisão de migração para cada função amostrada.

Para avaliar cada função de amostra para migração do OCI Functions, conclua um registro de avaliação com os seguintes itens para cada função de amostra:

  • Nome da função e proprietário do aplicativo
  • Finalidade e criticidade do negócio
  • Runtime e versão
  • Acionador e formato de evento de entrada
  • Serviços AWS e chamadas SDK usadas
  • Tempo de execução, memória, simultaneidade e tamanho do payload
  • Repetir, solicitar, duplicar entrega e comportamento de falha
  • Permissões e dependências de rede do IAM
  • Logs, métricas, alarmes e objetivos de nível de serviço atuais
  • Configuração e padrão de acionamento obrigatórios do OCI Functions
  • Alterações de código, adaptador ou implantação necessárias
  • Lacunas conhecidas e riscos não resolvidos

Use um dos seguintes resultados de avaliação:

  • Migração do OCI Functions pronta: A carga de trabalho pode ser movida para o OCI Functions com alterações limitadas.
  • Migração do OCI Functions com alterações: A carga de trabalho requer um adaptador, alterações de código direcionadas, alterações de configuração ou alterações operacionais.
  • Revisão de exceção obrigatória: O OCI Functions pode não atender a um requisito de carga de trabalho documentado. Não prossiga com uma arquitetura que não seja do Functions sem a revisão de exceção descrita neste playbook.

O proprietário do aplicativo e o proprietário da migração devem revisar a avaliação antes do início da implementação.

Avaliar os Requisitos de Migração do OCI Functions

Determine a abordagem de migração do OCI Functions para uma carga de trabalho.

Para avaliar os requisitos de migração do OCI Functions, siga estas etapas:

  1. Revise o trigger, o runtime, as dependências, a duração da execução, a memória, a simultaneidade, o payload, o IAM, a rede e os requisitos operacionais da carga de trabalho para determinar a abordagem de migração do OCI Functions.
  2. Separe a lógica de negócios portátil da análise de eventos específica da AWS, chamadas de SDK, suposições do IAM, registro em log e tratamento de novas tentativas.

    Isso torna as alterações de migração necessárias visíveis antes do início da implementação.

  3. Use os padrões de migração do OCI Functions a seguir como ponto de partida.
    Padrão de carga de trabalho Padrão de migração do OCI Functions Validar
    Carga de trabalho sem estado, orientada a eventos e de curta execução Funções do OCI Payload, memória, timeout, simultaneidade, dependências e acesso downstream necessário
    Carga de trabalho da API HTTP Gateway de API do OCI mais OCI Functions Autenticação, métodos, rotas, cabeçalhos, tamanho da carga útil, respostas a erros, latência e timeout
    Objeto, notificação, fila, fluxo ou processador de eventos de log OCI Functions com os OCI Events aplicáveis, Oracle Cloud Infrastructure Queue, OCI Notifications, OCI Streaming ou serviço OCI Connector Hub Formato do evento, comportamento de entrega, repetições, pedidos, tratamento de duplicidades, destino da falha e contrapressão

O OCI Functions é o alvo padrão para iniciativas de migração Lambda quando atende aos requisitos funcionais, de desempenho, de segurança e operacionais da carga de trabalho.

Projetar a Arquitetura do OCI de Destino

Defina padrões de chamada, identidade, segredo, rede, dependência, observabilidade e transferência.

Para projetar a arquitetura do OCI de destino, siga estas etapas:

  1. Selecione o caminho de chamada e a autenticação esperada do documento, a forma de payload, os cabeçalhos ou metadados, a latência, as repetições, a ordenação, o comportamento do batch, a entrega duplicada, a filtragem e o destino da falha.
  2. Defina o aplicativo OCI Functions, compartimento, repositório de imagens, VCN, sub-redes, tabelas de roteamento, regras de segurança, gateway de serviço ou gateway NAT, acesso privado, requisitos de saída e pontos finais downstream.
  3. Identifique cada serviço da OCI ou ponto final externo que as chamadas de função no runtime, incluindo OCI Object Storage, OCI Queue, OCI Streaming, OCI Vault, bancos de dados e APIs de terceiros.
  4. Defina sinais operacionais, como campos de log, ID de correlação, contagem de chamadas, duração, erros, timeouts, sintomas de capacidade, falhas downstream, exibições de painel, alarmes e etapas de runbook.

Procure um resumo da arquitetura de destino com lista de componentes, caminho de integração, design de segurança, design operacional e orientação de redesenho de diagrama.

Considerações: O design da arquitetura é concluído somente quando o fluxo normal, o fluxo de repetição, o fluxo de falha, o fluxo de acesso negado e o fluxo de rollback são descritos.

Considerações de Design e Seleção de Destino

Use essas considerações durante a revisão do projeto.

Eles são intencionalmente orientados para a ação para que os revisores possam pedir evidências, em vez de aceitar declarações gerais de prontidão.

  • Ajuste de destino: Use o OCI Functions para trabalho sem monitoramento de estado, orientado a eventos, de curta execução e conteinerizável que se adapte aos limites de destino e ao modelo de chamada. Use outro destino para cargas de trabalho de longa execução, com monitoramento de estado, semelhantes a daemon, com muita orquestração, semelhantes a trabalhadores ou combinadas com serviços da AWS.
  • Payloads e timeouts: Registra tamanhos reais de solicitação e resposta, duração máxima, contagem de timeout e semântica de resposta do chamador. Passe dados grandes por referência por meio do OCI Object Storage, OCI Queue, OCI Streaming ou outro armazenamento, em vez de por meio do payload da função.
  • Dependências: Converta suposições de camada ZIP e Lambda em dependências de imagem ou imagem de base compartilhada. Teste bibliotecas nativas, tamanho da imagem, versões de dependência, comportamento de inicialização, suposições de SDK incorporadas e comportamento de runtime.
  • Simultaneidade e dimensionamento: estoque por que a AWS reservou ou provisionou simultaneidade foi usada: capacidade reservada, limite de tráfego, redução de início a frio, limitação de origem de eventos ou proteção downstream. Projete o comportamento da OCI com planejamento de capacidade, simultaneidade provisionada quando apropriado, acione controles, contrapressão e limites downstream.
  • Acionadores: Validar forma de evento, repetição, ordenação, comportamento em batch, entrega duplicada, filtragem, destino de falha e idempotência. O comportamento do gatilho geralmente é a área de migração de maior risco.
  • Operações: Trate logs, métricas, alarmes, painéis de controle, rastreamentos, runbooks, trigger de rollback e proprietário de rollback como entregas de migração, não limpeza pós-cutover.

Guia de seleção de destino

Característica da carga de trabalho Destino do OCI recomendado Por que
Função conteinerizável, sem estado, orientada a eventos e de curta execução Funções do OCI Ajuste mais próximo quando as restrições de payload, timeout, memória, trigger, dependência, rede e simultaneidade forem atendidas.
Função de API HTTP com comportamento simples de solicitação/resposta Gateway de API do OCI mais OCI Functions Bom ajuste quando a autenticação, cabeçalhos, tamanho do payload, timeout, latência, código de status e semântica de resposta são validados.
Objeto, notificação, fila, fluxo ou processador de eventos de log OCI Functions com OCI Events, OCI Notifications, OCI Connector Hub, OCI Streaming por meio do Connector Hub ou fluxo de mensagens reprojetado O comportamento de envio, repetição, pedido, batch, duplicado, mensagem venenosa e falha deve ser recriado e testado.
Trabalho de longa duração ou processo semelhante a trabalhador Instâncias de Contêiner do OCI, OKE, OCI Compute ou workflow decomposto Evita restrições de chamada de função e runtime, preservando um caminho de implantação baseado em contêiner ou serviço.
Orquestração pesada de integração Oracle Integration, serviço de workflow ou reprojeto Melhor ajuste quando a carga de trabalho coordena sistemas, aguarda o estado externo ou gerencia etapas de compensação, em vez de executar uma pequena unidade de computação.
Processo com monitoramento de estado, estado durável local ou daemon OCI Compute, OKE ou reprojetado O OCI Functions não é um modelo de execução durável de estado local ou daemon.

Preparar Recursos do OCI e Acesso à Implantação

Prepare o ambiente de destino mínimo necessário para criar, implantar e testar a fumaça.

Para preparar recursos do OCI e acesso à implantação, siga estas etapas:

  1. Crie ou identifique o compartimento, o aplicativo OCI Functions, as sub-redes da VCN, o repositório do OCI Container Registry, os locais de segredo do OCI Vault, os recursos de log e os alarmes de monitoramento.
  2. Configure o acesso de desenvolvedor e CI/CD para criar imagens, enviar imagens, implantar funções, chamar testes de fumaça e ler logs.
  3. Crie regras de grupo dinâmico e instruções de política para acesso em runtime. Escopo por compartimento e recurso quando possível, especialmente para buckets, streams, filas, segredos do OCI Vault e bancos de dados.
  4. Push de imagem de teste de fumaça, implantação de função, chamada direta, emissão de log, leitura de segredo, leitura de segredo negada e uma chamada de serviço de downstream representativa.

Procure um ambiente de destino pronto com caminhos de acesso documentados e um teste de fumaça passageiro.

Considerações: Certifique-se de que a identidade de implantação e a identidade de runtime sejam separadas quando o processo exigir diferentes permissões.