ADR: Nextflow Profiles no HealthOmics — Separação de Configuração e Lógica

Pipelines bioinformáticos têm uma característica que os distingue de workloads de propósito geral: o mesmo código precisa rodar corretamente em contextos radicalmente diferentes. Um pipeline de variant calling que processa 30x WGS em produção pode precisar rodar com 2 CPUs e 8 GB de RAM em desenvolvimento para validação rápida, e com 64 vCPUs e 256 GB em produção para cumprir SLAs clínicos. Antes do suporte a profiles, a abordagem mais comum era manter arquivos nextflow.config separados por ambiente ou usar variáveis de ambiente com lógica condicional embutida no próprio código do workflow — ambas as abordagens violam o princípio de separação de concerns e introduzem drift entre ambientes.

No contexto do AWS HealthOmics, esse problema é amplificado por três forças específicas. Primeira: o serviço é HIPAA-eligible, o que significa que qualquer alteração em arquivos de workflow precisa passar por controles de auditoria — modificar nextflow.config para trocar de ambiente implica um artefato de workflow diferente, com hash diferente, exigindo re-validação. Segunda: workflows nf-core — que representam a grande maioria dos pipelines adotados em produção no setor — já vêm com profiles institucionais e de plataforma embutidos (test, test_full, docker, singularity, awsbatch), mas sem suporte nativo a profiles no HealthOmics, esses profiles eram ignorados ou exigiam adaptações manuais. Terceira: equipes de bioinformática raramente têm um SRE dedicado; a complexidade de manter múltiplas definições de workflow para o mesmo pipeline é um custo operacional real que se acumula com cada novo pipeline incorporado ao portfólio.

A decisão central aqui não é sobre Nextflow profiles em si — essa é uma feature da ferramenta que existe há anos. A decisão é sobre onde a separação de configuração e lógica deve ocorrer na cadeia de execução do HealthOmics. Antes dessa mudança, o HealthOmics tratava o workflow como um artefato imutável e completo: tudo que precisava variar entre execuções tinha que ser passado como parâmetros de input (--param valor) ou estar embutido no código. Isso funcionava para parâmetros de negócio (qual arquivo de referência usar, qual sample processar), mas era inadequado para configurações de plataforma (limites de CPU/memória por processo, estratégias de retry, configurações de executor).

Com o suporte a profiles, o HealthOmics agora aceita um campo engineOptions na API de start-run que permite especificar um ou mais profiles pelo nome: -profile test,aws. Isso significa que o artefato de workflow registrado no HealthOmics Workflow Registry permanece imutável — o mesmo ARN, o mesmo hash SHA-256 — enquanto o comportamento de execução varia pelo profile selecionado em tempo de run. Do ponto de vista de auditoria HIPAA, isso é significativo: você pode demonstrar que o código científico não foi alterado entre execuções, enquanto as configurações de plataforma variam de forma controlada e rastreável através dos parâmetros de run.

A implicação de design mais importante é que profiles são resolvidos em tempo de execução pelo motor Nextflow dentro do ambiente gerenciado do HealthOmics. Isso significa que o arquivo nextflow.config dentro do artefato do workflow precisa definir os profiles antecipadamente — você não pode injetar um profile que não existe no artefato. A flexibilidade é real, mas é delimitada pelo que foi definido no momento do registro do workflow.

A consequência mais imediata é a eliminação de uma classe inteira de erros humanos: a modificação acidental de parâmetros de produção durante edições de desenvolvimento. Em equipes que eu observei, esse tipo de erro — um maxMemory = 256.GB que sobrescreve o limite de dev de 8.GB porque alguém editou o arquivo errado — é responsável por uma fração significativa dos incidentes de run failure no HealthOmics. Com profiles, o arquivo de configuração de produção nunca é tocado durante o desenvolvimento.

A segunda consequência é sobre portabilidade de workflows nf-core. Pipelines como nf-core/sarek, nf-core/rnaseq e nf-core/viralrecon já incluem profiles como test (dataset mínimo para CI), test_full (dataset completo para validação) e profiles de plataforma como awsbatch. Com o suporte nativo no HealthOmics, equipes podem agora registrar esses workflows sem modificação e selecionar o profile test para validação de CI/CD e o profile de produção para runs clínicos — usando o mesmo artefato registrado. Isso reduz o tempo de onboarding de um novo pipeline nf-core de dias para horas.

A terceira consequência, menos óbvia, é sobre custo. Profiles de desenvolvimento com limites menores de CPU e memória significam que runs de validação consomem menos recursos gerenciados do HealthOmics. Considerando que o HealthOmics cobra por tempo de run e recursos alocados, a capacidade de executar validações rápidas com o profile test — que tipicamente usa datasets sintéticos de 1-2 GB em vez dos 100-300 GB de um WGS completo — pode representar uma redução de 40-60% no custo de runs de CI/CD, dependendo da frequência de execução.

Em ambientes HIPAA, a rastreabilidade de cada execução de workflow é um requisito, não uma conveniência. O modelo anterior — onde configurações de ambiente eram embutidas no artefato ou passadas de forma ad hoc — criava lacunas de auditoria: era difícil demonstrar que um run específico usou as configurações corretas sem inspecionar o artefato completo.

Com profiles, o campo engineOptions é capturado no run record do HealthOmics e propagado para os logs do CloudWatch. Isso significa que para cada run, você tem: (1) o ARN do workflow com seu hash SHA-256, que identifica unicamente o código científico; (2) os parâmetros de input, que identificam os dados processados; e (3) o engineOptions com os profiles selecionados, que identifica a configuração de plataforma. Esses três elementos juntos formam uma evidência de controle completa para auditoria.

Para maximizar essa rastreabilidade em um ambiente de grau clínico, recomendo estruturar o Step Functions state machine que orquestra os runs do HealthOmics para incluir o profile selecionado como um atributo de execução explícito, não apenas passá-lo no engineOptions. Isso permite queries no CloudWatch Logs Insights como fields @timestamp, workflowId, selectedProfile, runStatus | filter selectedProfile = 'prod' | stats count() by runStatus para auditorias rápidas. Adicionalmente, políticas IAM com condições no omics:engineOptions podem ser usadas para restringir quais roles podem iniciar runs com o profile prod — um controle de separação de ambientes que vai além do que era possível antes.

A feature de profiles não existe no vácuo — ela precisa ser integrada ao ecossistema de orquestração e governança que envolve o HealthOmics. A integração mais natural é com o Step Functions, que tipicamente serve como o orquestrador de workflows bioinformáticos em produção, gerenciando sequências de runs, dependências entre pipelines e tratamento de erros.

Na prática, recomendo modelar o profile como uma variável de entrada explícita no state machine do Step Functions, não como um valor hardcoded. O estado StartHealthOmicsRun deve receber $.profile como input e construir o engineOptions dinamicamente: "engineOptions": { "nextflow": { "profile": "$.profile" } }. Isso permite que o mesmo state machine sirva dev e prod, com o profile sendo determinado pelo evento que dispara a execução — um evento de CI passa test, um evento de produção clínica passa prod,aws.

Do ponto de vista de IAM, a separação de profiles abre uma oportunidade de controle que não existia antes. Você pode criar uma política de IAM que usa condições StringLike no omics:engineOptions para restringir quais roles podem iniciar runs com profiles de produção. Por exemplo, uma role de CI/CD pode ser limitada a iniciar apenas runs com -profile test ou -profile test_full, enquanto a role de execução clínica tem permissão para -profile prod,aws. Isso implementa separação de ambientes no plano de controle, não apenas no plano de dados.

Para observabilidade, o sinal mais valioso é correlacionar o profile selecionado com as métricas de custo e duração do run. Uma query no CloudWatch Logs Insights que agrupa runDuration e estimatedCost por selectedProfile permite identificar rapidamente se runs de desenvolvimento estão inadvertidamente usando profiles de produção — um sinal de alerta precoce para tanto desperdício de custo quanto potencial vazamento de configuração.