Comment nous avons construit Snowflake sur Azure

Comment nous avons construit Snowflake sur Azure

Aujourd’hui, nous avons annoncé la disponibilité générale de Snowflake sur Azure. En tant que membre de l’équipe d’ingénieurs qui a construit Snowflake sur Azure, je suis particulièrement ravi de dévoiler ce sur quoi nous avons travaillé.

Snowflake sur Azure a été un projet ambitieux. Nous voulions offrir le même service Snowflake que les clients utilisent déjà sur d’autres plates-formes cloud mais conçu pour Azure, y compris toutes les fonctionnalités existantes et nouvelles, avec une base de code unique et avec les mêmes caractéristiques de performance. Dans cet article, je vais vous en dire un peu plus sur la façon dont nous l’avons fait, et sur certaines des fonctionnalités et forces d’Azure sur lesquelles nous nous sommes appuyés.

Tirer parti des forces d’Azure

L’activation de Snowflake pour s’exécuter sur Azure comprenait trois grandes catégories : s’appuyer sur Azure Blob Storage pour tout le stockage persistant interne et orienté client, utiliser Azure Compute pour exécuter des charges de travail et sécuriser tous les accès à l’aide d’Azure Active Directory et des fonctionnalités de sécurité intégrées aux composants Azure. .

Stockage

Le stockage d’objets blob Azure a une hiérarchie à deux niveaux. Les comptes de stockage contiennent des conteneurs, et les conteneurs ont une hiérarchie de dossiers classique en leur sein. Les conteneurs peuvent être sécurisés indépendamment avec des jetons de signature d’accès partagé (SAS), qui sont des informations d’identification limitées dans le temps et les autorisations. Lors de l’accès aux données client, Snowflake utilise des jetons SAS limités uniquement au conteneur de ce client, ce qui permet à Snowflake de s’assurer que les données du conteneur d’un client ne sont jamais accessibles lorsqu’elles sont exécutées dans le contexte d’un autre client.

Utilisations de flocon de neige suppression réversible pour les blobs de stockage Azure pour protéger les données contre la corruption et la suppression accidentelle, et pour récupérer les données en cas d’événement catastrophique. Construit en coordination avec notre équipe, la suppression réversible nous permet d’offrir la résilience des données sans créer notre propre fonctionnalité d’instantané.

La charge de travail de Snowflake a tendance à avoir une utilisation élevée du stockage, et comptes de stockage à grande échelle donner à Snowflake une capacité accrue et des limites d’entrée et de sortie plus élevées sur nos comptes de stockage. Mise en réseau accélérée améliore également les performances réseau de Snowflake, ce qui est important pour les communications entre les machines exécutant une requête et pour les lectures et les écritures sur le stockage. Ces deux fonctionnalités étaient essentielles pour atteindre nos objectifs de performance.

Calculer

Lorsque vous exécutez votre charge de travail dans Snowflake, les machines utilisées pour exécuter vos requêtes sont dédiées à votre usage exclusif. Pour ajouter de la puissance de calcul quand vous le souhaitez, Snowflake alloue de manière élastique des machines pour votre charge de travail à l’aide de modèles Azure Resource Manager. Azure Compute nous permet de créer, de gérer et de libérer ces ressources tout en garantissant qu’une seule panne dans un centre de données ou une mise à jour forcée du système n’affecte pas votre capacité à exécuter vos requêtes.

Sécurité

Chez Snowflake, nous prenons la sécurité très au sérieux, il était donc crucial de créer un modèle de sécurité hermétique. Notre modèle de sécurité repose sur les concepts de sécurité natifs d’Azure. Nous utilisons Azure Active Directory pour gérer les identités et fournir une journalisation et une surveillance de sécurité continues. Comme je l’ai mentionné ci-dessus, Snowflake utilise des jetons SAS pour s’assurer que les données d’un client ne sont jamais accessibles lors de l’exécution de la requête d’un autre client, même pour les processus internes de Snowflake. Mais les jetons SAS nous permettent de sécuriser plus que de simples données internes dans un conteneur de stockage. Snowflake crée également de manière dynamique des jetons expirables à court terme que nos pilotes Snowflake utilisent pour récupérer des fichiers de résultats ou placer et récupérer des données dans des zones de stockage, telles que des tables, des utilisateurs et des étapes nommées. Ces jetons garantissent que les connexions demandant des données sont sécurisées à l’aide de TLS et proviennent des propres adresses IP de Snowflake. Les jetons SAS ne peuvent être utilisés que pour les opérations et fichiers spécifiques dont un client a besoin, conformément aux principes du moindre privilège. Enfin, tous les jetons SAS que nous créons expirent après un temps limité.

Snowflake crypte toutes les données à tout moment. Les données sur les comptes de stockage de Snowflake sont chiffrées au repos à l’aide Chiffrement du stockage Azure. De plus, nous stockons les données à l’aide d’une couche de chiffrement supplémentaire avec les données AES-256 et le chiffrement de clé à l’aide de clés gérées par Snowflake. Comme les jetons SAS, les clés de chiffrement du compte d’un client ne peuvent être récupérées que lors de l’exécution de requêtes pour ce compte, garantissant qu’un client ne peut pas déchiffrer les données d’un autre client.

Les étapes externes permettent aux clients d’importer et d’exporter les données qu’ils gèrent sur leurs propres comptes de stockage Azure. Étant donné que les jetons SAS offrent un contrôle précis, étendu et basé sur l’expiration, nous utilisons des jetons SAS créés par le client pour accéder aux données dans les étapes externes Azure. En plus d’exiger l’utilisation de jetons délimités, nous encourageons fortement les clients à chiffrer tous les fichiers sur leurs étapes externes à l’aide du chiffrement côté client et d’une clé de chiffrement de 256 bits. Snowflake déchiffre ensuite ces données lors du chargement et les chiffre lors du déchargement à l’aide de vos clés et du même chiffrement de données AES et du même chiffrement de clé AES-KW pris en charge par le SDK Azure Storage.

Comment nous le construisons

La prise en charge de plusieurs plates-formes cloud peut ajouter une charge importante à vos équipes d’ingénierie et d’exploitation. Dès le début, nous avons décidé que nous devions développer la prise en charge d’Azure en utilisant la même base de code que nous utilisons pour d’autres plateformes cloud. Nous utilisons des couches d’abstraction pour encapsuler les interactions avec les API de stockage, de calcul et de sécurité spécifiques au cloud. Nous avons un processus de construction unique et un ensemble unique de fichiers binaires que nous déployons dans toutes les régions Snowflake, quelle que soit la plate-forme cloud sur laquelle ils s’exécutent. À mesure que Snowflake s’étend à d’autres régions, nos processus d’ingénierie, de publication et de maintenance restent évolutifs. Cela signifie également que nous pouvons déployer une nouvelle version en quelques heures dans chaque région et surveiller toutes les régions et plates-formes cloud à l’aide d’un seul ensemble d’outils.

image1 1

Partenariat avec Microsoft

Nous n’aurions pas pu construire cela sans une étroite coordination avec Microsoft. Le projet Snowflake sur Azure comprenait de nombreuses longues sessions téléphoniques et réunions dans les salles de conférence de Redmond. Plusieurs nouvelles fonctionnalités ont été conçues en pensant à Snowflake, notamment la suppression logicielle du stockage Azure et les améliorations apportées au provisionnement des machines virtuelles. Un grand merci à l’équipe Azure pour nous aider à livrer ensemble.

Et après?

Nous sommes loin d’avoir fini. Chaque nouvelle fonctionnalité de Snowflake est désormais conçue en tandem pour chaque plate-forme cloud que nous prenons en charge. Et, à mesure que de nouvelles fonctionnalités seront ajoutées à Azure, nous les exploiterons dans Snowflake pour Azure. Aujourd’hui, nous appelons East US 2 chez nous. Dans les mois à venir, nous nous diversifierons dans de nouvelles régions Azure pour toucher davantage de clients. Mais d’abord, peut-être de courtes vacances pour l’équipe Snowflake sur Azure.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.