Metodologia de sucesso da implementação do Synapse: avaliar o design do workspace

Observação

Este artigo faz parte da série de artigos Sucesso por design da implementação do Azure Synapse. Para obter uma visão geral da série, confira Sucesso por design da implementação do Azure Synapse.

O workspace do Synapse é uma experiência unificada de usuário gráfico que reúne seus mecanismos de processamento de dados e analíticos, data lakes, bancos de dados, tabelas, conjuntos de dados e artefatos de relatório, juntamente com orquestração de código e de processo. Considerando o número de tecnologias e serviços integrados ao workspace do Synapse, verifique se os principais componentes estão incluídos em seu design.

Revisão de design do workspace do Synapse

Identifique se o design da solução envolve um workspace do Synapse ou vários. Determine os drivers desse design. Embora possa haver razões diferentes, na maioria dos casos, o motivo para vários workspaces é a segregação de segurança ou de cobrança. Ao determinar o número de workspaces e limites de banco de dados, tenha em mente que há um limite de 20 workspaces por assinatura.

Identifique quais elementos ou serviços em cada workspace precisam ser compartilhados e com quais recursos. Os recursos podem incluir data lakes, IRs (runtimes de integração), metadados ou configurações e código. Determine por que esse design específico foi escolhido em termos de possíveis sinergias. Pergunte a si mesmo se essas sinergias justificam o custo extra e a sobrecarga de gerenciamento.

Análise de design do Data Lake

Recomendamos que o Data Lake (se for parte de sua solução) seja colocado devidamente em camadas. Você deve dividir seu data lake em três áreas principais relacionadas aos conjuntos de dados Bronze, Pratae Ouro. O Bronze (ou a camada bruta) pode residir em sua própria conta de armazenamento separada porque tem controles de acesso mais rigorosos devido a dados confidenciais não mascarados que podem estar armazenados nele.

Revisão do design de segurança

Examine o design de segurança do workspace e compare-o com as informações coletadas durante a avaliação. Verifique se todos os requisitos foram atendidos e se todas as restrições foram levadas em conta. Para facilitar o gerenciamento, recomendamos que os usuários sejam organizados em grupos com a criação de perfis com permissões apropriadas: você pode simplificar o controle de acesso usando grupos de segurança alinhados com funções. Dessa forma, os administradores de rede podem adicionar ou remover usuários dos grupos de segurança apropriados para gerenciar o acesso.

Os pools de SQL sem servidor e as tabelas do Apache Spark armazenam os dados deles em um contêiner do ADLS Gen2 (Azure Data Lake Storage Gen2) que está associado ao workspace. As bibliotecas do Apache Spark instaladas pelo usuário também são gerenciadas nessa mesma conta de armazenamento. Para habilitar esses casos de uso, os usuários e a MSI (identidade de serviço gerenciado) do workspace precisarão ser adicionados à função Colaborador de dados do blob de armazenamento do contêiner de armazenamento do ADLS Gen2. Verifique esse requisito em relação aos seus requisitos de segurança.

Os pools de SQL dedicados fornecem um conjunto avançado de recursos de segurança para criptografar e mascarar dados confidenciais. Os pools de SQL dedicados e sem servidor permitem a área de superfície completa das permissões do SQL Server, incluindo funções internas, funções definidas pelo usuário, autenticação SQL e autenticação do Microsoft Entra. Examine o design de segurança do pool de SQL dedicado da sua solução e os dados e o acesso ao pool de SQL sem servidor.

Examine o plano de segurança do data lake e todas as contas de armazenamento do ADLS Gen2 (e outras) que farão parte da sua solução do Azure Synapse Analytics. O armazenamento do ADLS Gen2 não é por si só um mecanismo de computação e, portanto, não tem capacidade interna de mascarar seletivamente atributos de dados. Você pode aplicar permissões do ADLS Gen2 no nível da conta de armazenamento ou do contêiner usando o RBAC (controle de acesso baseado em função) e/ou no nível da pasta ou do arquivo usando ACLs (listas de controle de acesso). Examine o design cuidadosamente e procure evitar complexidades desnecessárias.

Aqui estão alguns pontos a serem considerados no design de segurança.

• Verifique se os requisitos de configuração da ID do Microsoft Entra estão incluídos no design.
• Verifique se há cenários entre locatários. Esses problemas podem surgir porque alguns dados estão em outro locatário do Azure, precisam ser movidos para outro locatário ou precisam ser acessados por usuários de outro locatário. Verifique se esses cenários são considerados em seu design.
• Quais são as funções de cada workspace? Como eles usarão o workspace?
• Como a segurança é projetada no workspace?
  • Quem pode exibir todos os scripts, notebooks e pipelines?
  • Quem pode executar scripts e pipelines?
  • Quem pode criar/pausar/retomar pools do SQL e do Spark?
  • Quem pode publicar alterações no workspace?
  • Quem pode confirmar alterações no controle do código-fonte?
• Os pipelines acessarão dados usando credenciais armazenadas ou a identidade gerenciada do workspace?
• Os usuários têm o acesso apropriado ao data lake para procurar os dados no Synapse Studio?
• O data lake é protegido corretamente com o uso da combinação apropriada de RBAC e ACLs?
• As permissões de usuário do pool de SQL foram definidas corretamente para cada função (cientista de dados, desenvolvedor, administrador, usuário comercial e outros)?

Revisão de design de rede

Aqui estão alguns pontos a serem considerados no design de rede.

• Há conectividade projetada entre todos os recursos?
• Qual é o mecanismo de rede a ser usado (Azure ExpressRoute, Internet pública ou pontos de extremidade privados)?
• Você precisa ser capaz de se conectar com segurança ao Synapse Studio?
• A exfiltração dos dados foi levada em consideração?
• Você precisa se conectar a fontes de dados locais?
• Você precisa se conectar a outras fontes de dados de nuvem ou mecanismos de computação, como o Azure Machine Learning?
• A conectividade e movimentação de dados adequadas foram verificadas nos componentes de rede do Azure, como NSGs (grupos de segurança de rede)?
• A integração com as zonas DNS privadas foi levada em consideração?
• Você precisa ser capaz de navegar pelo data lake dentro do Synapse Studio ou simplesmente consultar dados no data lake com PolyBase ou SQL sem servidor?

Por fim, identifique todos os consumidores de dados e verifique se a conectividade deles foi contabilizada no design. Verifique se os postos avançados de segurança e de rede permitem que seu serviço acesse fontes locais necessárias e se há suporte aos seus protocolos e mecanismos de autenticação. Em alguns cenários, talvez seja necessário ter mais de um IR auto-hospedado ou gateway de dados para soluções SaaS, como o Microsoft Power BI.

Revisão de design de monitoramento

Examine o design do monitoramento dos componentes do Azure Synapse para garantir que eles atendam aos requisitos e às expectativas identificados durante a avaliação. Verifique se o monitoramento de recursos e acesso a dados foi projetado e se ele identifica cada requisito de monitoramento. Uma solução de monitoramento robusta deve ser implantada como parte da primeira implantação na produção. Dessa forma, as falhas podem ser identificadas, diagnosticadas e tratadas em tempo hábil. Além da infraestrutura base e das execuções de pipeline, os dados também devem ser monitorados. Dependendo dos componentes do Azure Synapse em uso, identifique os requisitos de monitoramento para cada componente. Por exemplo, se os pools do Spark fizerem parte da solução, monitore o repositório de registros malformado. 

Aqui estão alguns pontos a serem considerados no design de monitoramento.

• Quem pode monitorar cada tipo de recurso (pipelines, pools e outros)?
• Por quanto tempo os logs de atividades do banco de dados precisam ser retidos?
• O workspace e a retenção de logs de banco de dados usarão o Log Analytics ou o Armazenamento do Azure?
• Os alertas serão disparados em caso de erro de pipeline? Nesse caso, quem deve ser notificado?
• Qual nível de limite de um pool de SQL deve disparar um alerta? Quem deve ser notificado?

Revisão de design de controle do código-fonte

Por padrão, um workspace do Synapse aplica alterações diretamente ao serviço Synapse usando a funcionalidade de publicação interna. Você pode habilitar a integração do controle do código-fonte, o que fornece muitas vantagens. As vantagens incluem melhor colaboração, controle de versão, aprovações e pipelines de lançamento para promover alterações nos ambientes de desenvolvimento, teste e produção. O Azure Synapse permite um único repositório de controle do código-fonte por workspace, que pode ser o Git do Azure DevOps ou o GitHub.

Aqui estão alguns pontos a serem considerados no design do controle do código-fonte.

• Se estiver usando o Git do Azure DevOps, o workspace do Synapse e seu repositório estão no mesmo locatário?
• Quem poderá acessar o controle do código-fonte?
• Quais permissões cada usuário receberá no controle do código-fonte?
• Uma estratégia de ramificação e mesclagem foi elaborada?
• Os pipelines de lançamento serão desenvolvidos para implantação em ambientes diferentes?
• Será usado um processo de aprovação para mesclagem e para pipelines de lançamento?

Observação

O design do ambiente de desenvolvimento é de máxima importância para o sucesso do seu projeto. Se um ambiente de desenvolvimento tiver sido projetado, ele será avaliado em uma fase separada da metodologia.

Próximas etapas

No próximo artigo da série Sucesso por design do Azure Synapse, saiba como avaliar o design de integração de dados e validar que ele atende às diretrizes e aos requisitos.