Exécuter vos applications analytiques avec HAQM EMR on EKS

Il est maintenant courant d’utiliser les technologies Big Data pour traiter un volume massif de données collectées au sein d’organisations. Néanmoins, nos clients qui possèdent leurs propres déploiements Apache Hadoop ou Apache Spark sur site sont confrontés à des difficultés. Vous êtes souvent frustrés par deux problèmes: (1) Le coûteux sur-dimensionnement des ressources pour gérer la variabilité de l’application; et (2) le temp trop important investi dans la maintenance de l’infrastructure afin de suivre les évolutions de versions des logiciels open source. De plus, nombre d’entre vous disposent de clusters Kubernetes pour gérer des applications métier, ce qui conduit à évoir deux environnement distincts à gérer. Aujourd’hui, vous pensez à migrer les applications analytiques dans Kubernetes afin de consolider les ressources.

AWS propose déjà HAQM EMR comme plateforme gérée pour des frameworks de Big Data et HAQM Elastic Kubernetes Service (HAQM EKS) comme plateforme gérée pour Kubernetes. En décembre 2020, AWS a annoncé HAQM EMR on EKS afin de simplifier l’exécution des frameworks de Big Data sur Kubernetes, et de vous apporter le meilleur des deux mondes.

Qu’est-ce que HAQM EMR on EKS?

HAQM EMR on EKS offre un nouveau modèle de déploiement par rapport au modèle existant HAQM EMR on HAQM Elastic Compute Cloud (HAQM EC2). Vous pouvez déployer des applications Spark sur le même cluster EKS que d’autres types d’applications. HAQM EMR on EKS permet à vos équipes de collaborer plus efficacement :

Les équipes de développement peuvent exécuter des applications sur un pool commun de ressources sans avoir à provisionner l’infrastructure. HAQM EMR Studio (Preview) et AWS SDK ou AWS CLI peuvent être utilisés pour développer, soumettre et diagnostiquer des applications analytiques fonctionnant sur des clusters EKS. Les équipes peuvent aussi exécuter des tâches planifiées sur HAQM EMR on EKS en utilisant Apache Airflow géré par eux-mêmes ou en utilisant HAQM Managed Workflows for Apache Airflow (MWAA).
Les équipes d’infrastructure peuvent gérer de manière centralisée une plateforme informatique commune pour consolider les applications analytiques avec d’autres applications basées sur des conteneurs. Ceci simplifie la gestion de l’infrastructure avec des outils communs d’HAQM EKS. Les équipes profitent d’un cluster partagé pour les applications qui nécessitent différentes versions de frameworks Open Source. La plateforme centralisée permet également de réduire les coûts opérationnels avec la gestion automatisée des clusters Kubernetes et du patching sur les systèmes d’exploitation. Avec HAQM EC2 et AWS Fargate, les équipes disposent de plusieurs ressources de calcul pour répondre aux exigences de performance, opérationnelles ou financières.

Le schéma suivant illustre les deux différents modèles de déploiement pour HAQM EMR :

Avantages

L’exécution des applications analytiques avec HAQM EMR on EKS présente de nombreux avantages, notamment :

Meilleure gestion des ressources et des économies de coûts
Comme expliqué dans le mode de fonctionnement ci-dessus, au lieu d’avoir des pools de serveurs séparés pour différentes équipes, avec Kubernetes, vous avez une meilleure vue en termes d’utilisation des ressources par les équipes, ce qui permet de réduire les coûts et d’utiliser au mieux les ressources.

Vous pouvez exécuter toutes vos applications analytiques sur un seul cluster Kubernetes, et chaque application peut choisir sa propre version de Spark et ses dépendances. En quelques secondes, Kubernetes peut arrêter les conteneurs d’une application et réaffecter les ressources à une autre application. C’est donc plus efficace en terme d’utilisation de ressource par rapport à YARN.

Réduction de la charge opérationnelle
Bien qu’il soit possible d’exécuter Apache Spark sur des clusters gérés par Kubernetes, vous devez toujours installer, gérer et optimiser manuellement Apache Spark pour qu’il fonctionne sur Kubernetes. HAQM EMR on EKS facilite la mise en place, l’exploitation et la mise à l’échelle de vos environnements de Big Data sur Kubernetes. HAQM EMR on EKS prend en charge le contrôle précis des accès avec l’intégration d’IRSA (Rôles IAM pour les comptes de service), l’intégration de catalog AWS Glue, ainsi que le connecteur EMRFS optimisé pour HAQM Simple Storage Service (HAQM S3). Toutes ces fonctionnalités sont difficiles à configurer et maintenir sur Spark open-source.

Hautement flexible et évolutif
En plaçant les applications analytiques dans HAQM EMR on EKS, HAQM EKS gère la mise à l’échelle automatique des ressources pour vous. Grâce aux groupes de nœuds gérés par HAQM EKS, vous n’avez pas besoin d’allouer séparément la capacité de calcul pour faire évoluer vos applications Kubernetes. Vous pouvez également choisir AWS Fargate pour provisionner automatiquement des capacités de calcul sans serveur à la demande pour vos applications. Vous vous concentrez sur les tâches métier plutôt que sur l’allocation des ressources sous-jacentes.

Meilleur dimensionnement
Les applications analytiques sont de plus en plus diverses et il est difficile de dimensionner correctement les ressources sous-jacentes pour s’assurer qu’elles peuvent s’adapter aux différentes applications. HAQM EKS vous donne un contrôle plus granulaire sur l’allocation des ressources des pods.

Performances
Le runtime d’HAQM EMR pour Apache Spark peut être plus de 3 fois plus rapide que les clusters sans runtime EMR (en anglais). De plus, comme la ressource de calcul est déjà présente dans HAQM EKS, vous pouvez démarrer les applications en quelques secondes au lieu de quelques minutes.

Comment cela fonctionne-t-il ?

Dans cette section, nous illustrons comment les différents composants fonctionnent, vous trouverez des exemples de code dans la section suivante – “Mise en route rapide” pour tester dans votre environnement.

Les étapes principales du workflow HAQM EMR on EKS sont les suivantes :

Utilisez un cluster HAQM EKS existant ou créez-en un en utilisant l’utilitaire de ligne de commande eksctl ou la console HAQM EKS;
Créez un cluster virtuel en enregistrant HAQM EMR avec un espace de nom sur un cluster HAQM EKS (explications détaillées et des examples de codes dans les sections suivantes);
Soumettez votre job spark au cluster virtuel en utilisant l’AWS CLI ou le SDK.

Voici ci-dessous un diagramme qui explique plus en détail ce workflow :

Etape 1:
L’administrateur enregistre HAQM EMR avec un espace de noms sur HAQM EKS, ceci crée un cluster virtuel. HAQM EMR peut alors exécuter des applications analytiques sur cet espace de noms. Dans le diagramme ci-dessus, il y a deux espaces de noms donc deux clusters virtuels.

Etape 2:
Le premier data engineer soumet une tâche Spark au premier espace de noms emr-on-eks-1 et il peut préciser sa propre version EMR dans la configuration de la tâche.

Etape 3:
Ensuite, HAQM EMR crée automatiquement un conteneur avec une image de base HAQM Linux 2, Apache Spark et les dépendances associées.

Etape 4:
Chaque tâche s’exécute dans un pod qui télécharge le conteneur et commence à l’exécuter. Le pod se termine après la fin de la tâche. Si l’image du conteneur a déjà été déployée sur le nœud, une image en cache est utilisée et le téléchargement est contourné. Des conteneurs secondaires, tels que des proxies de logs ou de métriques, peuvent être déployés dans le pod. Une fois le travail terminé, vous pouvez toujours en voir les étapes d’execution et le rapport associé en utilisant le serveur d’historique Spark dans la console HAQM EMR.

Etape 5:
Un autre Data Scientist peut soumettre des tâches dans un autre espace de noms emr-on-eks-2 qui seront exécutées dans le même cluster EKS. Il peut aussi choisir un nouveau runtime avec une version EMR différente.

Mise en route rapide

Avant de commencer, suivez les étapes décrites dans le guide de développement (en anglais) pour configurer votre cluster EKS. Le guide vous aidera à:

Installer des outils nécessaires, tels que: AWS CLI, eksctl, kubectl.
Créer un cluster HAQM EKS à l’aide de l’outil eksctl.
Créer une correspondence entre le rôle IAM du service et l’utilisateur Kubernetes (RBAC) afin que HAQM EMR on EKS puisse accéder au cluster.
Activer les rôles IAM pour les comptes de service Kubernetes (IRSA).
Créer un rôle IAM pour exécuter des jobs et configurer des politiques associées.
Créer des utilisateurs IAM avec des politiques associées pour effectuer les différentes actions dans HAQM EMR on EKS.

À titre d’exemple, voici une commande CLI simple pour enregistrer votre cluster HAQM EKS :

$ aws emr-containers create-virtual-cluster \
--name <virtual_cluster_name> \
--container-provider '{
  "id": "<eks_cluster_name>",
  "type": "EKS",
  "info": {
    "eksInfo": {
      "namespace": "<namespace_name>“ 
    }
  }
}'

Dans la console HAQM EMR, vous le retrouvez dans la liste des clusters virtuels.

Lorsque les clusters HAQM EKS sont enregistrés, les jobs EMR sont déployés sur des nœuds et des pods Kubernetes pour gérer l’exécution des applications et la mise à l’échelle automatique. Les endpoints gérés sont configurés afin que vous puissiez connecter des notebooks et des clients SQL. HAQM EMR construit et déploie un runtime optimisé en terme de performance pour les frameworks Open Source utilisés dans les applications analytiques.

Vous pouvez lancer vos jobs Spark avec la commande ci-dessous:

$ aws emr-containers start-job-run \
          --name <job_name> \
          --virtual-cluster-id <cluster_id> \
          --execution-role-arn <IAM_role_arn> \
          --virtual-cluster-id <cluster_id> \
          --release-label <emr_release_label> \
          --job-driver '{
            "sparkSubmitJobDriver": {
              "entryPoint": <entry_point_location>,
              "entryPointArguments": ["<arguments_list>"],
              "sparkSubmitParameters": <spark_parameters>
            }'
          --configurationOverrides '{
            "monitoringConfiguration": {
              "cloudWatchMonitoringConfiguration": {       
                "logGroupName": "<log_group_name>",        
                "logStreamNamePrefix": "<log_stream_prefix>"     
              }, 
              "s3MonitoringConfiguration": {       
                "logUri": "s3://<my_s3_log_location>"     
              }
       }'

Pour surveiller et debugger les tâches, vous pouvez utiliser les journaux d’inspection téléchargés sur votre emplacement HAQM CloudWatch et HAQM S3 configuré dans le cadre de la surveillance et de la configuration. Vous pouvez également utiliser la console EMR pour lancer le serveur d’historique Spark.

Prochaines étapes

Si vous vous sentez frustrés par la gestion des clusters pour les applications analytiques et que vous souhaitez réduire davantage les coûts et augmenter l’efficacité opérationnelle, il est temps de découvrir HAQM EMR on EKS. Vous n’avez pas besoin de devenir un expert de Kubernetes et vous bénéficierez de tous les avantages de l’exécution des applications analytiques sur Kubernetes.

Pour en savoir plus, consultez la documentation. Veuillez envoyer vos commentaires sur le forum AWS pour HAQM EMR ou par l’intermédiaire de vos contacts d’assistance AWS habituels.

Weibo GU

Weibo est architecte de solutions chez AWS dédié aux entreprises industrielles, il a aussi des expertises dans Big Data et machine learning.

Le Blog HAQM Web Services