Exécuter vos applications analytiques avec Amazon 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à Amazon EMR comme plateforme gérée pour des frameworks de Big Data et Amazon Elastic Kubernetes Service (Amazon EKS) comme plateforme gérée pour Kubernetes. En décembre 2020, AWS a annoncé Amazon 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 Amazon EMR on EKS?

Amazon EMR on EKS offre un nouveau modèle de déploiement par rapport au modèle existant Amazon EMR on Amazon Elastic Compute Cloud (Amazon EC2). Vous pouvez déployer des applications Spark sur le même cluster EKS que d’autres types d’applications. Amazon 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. Amazon 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 Amazon EMR on EKS en utilisant Apache Airflow géré par eux-mêmes ou en utilisant Amazon 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’Amazon 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 Amazon 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 Amazon EMR :

Avantages

L’exécution des applications analytiques avec Amazon 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. Amazon EMR on EKS facilite la mise en place, l’exploitation et la mise à l’échelle de vos environnements de Big Data sur Kubernetes. Amazon 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 Amazon Simple Storage Service (Amazon 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 Amazon EMR on EKS, Amazon EKS gère la mise à l’échelle automatique des ressources pour vous. Grâce aux groupes de nœuds gérés par Amazon 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. Amazon EKS vous donne un contrôle plus granulaire sur l’allocation des ressources des pods.

Performances
Le runtime d’Amazon 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 Amazon 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 Amazon EMR on EKS sont les suivantes :

Utilisez un cluster Amazon EKS existant ou créez-en un en utilisant l’utilitaire de ligne de commande eksctl ou la console Amazon EKS;
Créez un cluster virtuel en enregistrant Amazon EMR avec un espace de nom sur un cluster Amazon 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 Amazon EMR avec un espace de noms sur Amazon EKS, ceci crée un cluster virtuel. Amazon 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, Amazon EMR crée automatiquement un conteneur avec une image de base Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon EMR on EKS.

À titre d’exemple, voici une commande CLI simple pour enregistrer votre cluster Amazon 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 Amazon EMR, vous le retrouvez dans la liste des clusters virtuels.

Lorsque les clusters Amazon 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. Amazon 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 Amazon CloudWatch et Amazon 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 Amazon 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 Amazon 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 Amazon Web Services