Meilleures pratiques

Utilisez l'ensemble suivant d'instructions recommandées lors de la mise à disposition et de la gestion de vos instances sans serveur et lors de l'exécution d'applications Spark.

Meilleures pratiques lors de l'utilisation d'instances sans serveur, y compris des descriptions détaillées et des liens de référence
Pratiques recommandées Description Lien de référence
Utilisez des instances de service IBM Analytics Engine distinctes pour vos environnements de développement et de production. Il s'agit d'une meilleure pratique générale. En créant des instances IBM Analytics Engine distinctes pour différents environnements, vous pouvez tester les modifications de configuration et de code avant de les appliquer à l'instance de production. ND
Mise à jour vers la dernière version de Spark A mesure que les versions open source de Spark sont publiées, elles sont mises à disposition dans IBM Analytics Engine après un intervalle de temps requis pour les tests internes. Surveillez l'annonce d'une nouvelle version de Spark dans la section Notes sur l'édition et mettez à niveau l'environnement d'exécution de votre instance pour déplacer vos applications vers l'environnement d'exécution Spark le plus récent. Les environnements d'exécution plus anciens sont obsolètes et finalement supprimés à mesure que des versions plus récentes sont publiées. Veillez à tester vos applications dans le nouvel environnement d'exécution avant d'apporter des modifications aux instances de production.
Accorder un accès basé sur les rôles Vous devez accorder un accès basé sur les rôles à tous les utilisateurs sur les instances IBM Analytics Engine en fonction de leurs besoins. Par exemple, seule votre équipe d'automatisation doit disposer des droits permettant de soumettre des applications car elle a accès aux secrets et votre équipe DevOps ne doit pouvoir afficher que la liste de toutes les applications et de leurs états.
Choisissez la bonne configuration IBM Cloud Object Storage
  • Reprise après sinistre (DR) Résilience: Vous devriez utiliser l'option IBM Cloud Object Storage L'option de résilience interrégionale permet de sauvegarder vos données dans plusieurs villes d'une même région. En revanche, l'option de résilience régionale sauvegarde les données dans un seul centre de données.
  • Chiffrement: IBM Cloud Object Storage est fourni avec le chiffrement intégré par défaut. Vous pouvez également configurer Object Storage pour qu'il fonctionne avec le service BYOK Key Protect.
  • Données d'identification du service: par défaut, IBM Cloud Object Storage utilise des données d'identification de type IAM. Si vous souhaitez utiliser des données d'identification de style AWS, vous devez utiliser l'option "Inclure les données d'identification HMAC" comme décrit dans Données d'identification de service.
  • Noeuds finaux directs pour IBM Cloud Object Storage: utilisez toujours des noeuds finaux directs pour la connectivité à l'instance IBM Cloud Object Storage. Cela s'applique à l'instance principale IBM Cloud Object Storage ainsi qu'aux noeuds finaux utilisés à partir de vos applications (votre code ou ce que vous transmettez en tant que paramètres dans les configurations au niveau de l'instance ou de l'application). Les points d'extrémité directs offrent de meilleures performances que les points d'extrémité publics et n'entraînent pas de frais pour la largeur de bande sortante ou entrante.
Utiliser des noeuds finaux privés pour le métamagasin Hive externe Si vous utilisez Spark SQL et que vous souhaitez utiliser un métamagasin externe tel que IBM Cloud Databases for PostgreSQL comme métamagasin Hive, vous devez utiliser le noeud final privé pour la connexion à la base de données afin d'améliorer les performances et de réaliser des économies.
Exécution d'applications avec surengagement de ressources Un quota est associé à chaque instance sans serveur Analytics Engine. Lorsque des applications sont soumises sur une instance, elles se voient allouer des ressources à partir du quota d'instance. Si une application demande des ressources au-delà du quota disponible, l'application ne démarre pas ou s'exécute avec des ressources inférieures à celles demandées, ce qui peut entraîner une exécution de l'application plus lente que prévu ou, dans certains cas, l'échec de l'application. Vous devez toujours surveiller la consommation de ressources en cours sur une instance pour vous assurer que vos applications s'exécutent confortablement dans les limites indiquées. Vous pouvez ajuster les limites via un ticket de demande de service si nécessaire.
Allocation statique de ressources par rapport à la mise à l'échelle automatique Lorsque vous soumettez des applications, vous pouvez spécifier le nombre de programmes d'exécution à l'avance (allocation statique) ou utiliser l'option de mise à l'échelle automatique (allocation dynamique). Avant de décider d'utiliser l'allocation statique ou la mise à l'échelle automatique, vous pouvez exécuter quelques tests de performances en faisant varier différents ensembles de données avec la mise à l'échelle statique et automatique pour trouver la configuration appropriée. Remarques générales:
-Si vous connaissez le nombre de ressources (coeurs et mémoire) requises par votre application et qu'il ne varie pas selon les différentes étapes de l'exécution de l'application, il est recommandé d'allouer des ressources statiques pour de meilleures performances.
-Si vous souhaitez utiliser les ressources optimisées, vous pouvez opter pour la mise à l'échelle automatique des programmes d'exécution où les programmes d'exécution sont alloués en fonction de la demande réelle de l'application. Notez qu'il peut y avoir un léger retard associé lors de l'utilisation de la mise à l'échelle automatique dans les applications.
Activer et optimiser la consignation en aval -Activez la consignation en aval pour votre instance de service afin d'identifier et de résoudre les problèmes, d'afficher la progression et d'imprimer ou d'afficher les sorties de vos applications. Notez que l'acheminement des journaux entraîne un coût basé sur la quantité de journaux transférés ou conservés dans l'instance IBM Log Analysis. En fonction de votre cas d'utilisation et de votre besoin, vous devez décider des paramètres optimaux.
-Lorsque vous activez l'acheminement des journaux à l'aide de l'API par défaut, seuls les journaux du pilote sont activés. Si vous avez également besoin des journaux de l'exécuteur, par exemple, si des erreurs ne s'affichent que sur les exécuteurs, vous devez personnaliser la consignation pour activer également la consignation de l'exécuteur. Les journaux du programme d'exécution peuvent devenir très volumineux. Par conséquent, équilibrez les options permettant d'optimiser la quantité de journaux qui sont transférés à votre instance de journalisation par rapport aux informations que vous obtenez dans les journaux à des fins de traitement des incidents.
-Suivez les meilleures pratiques de IBM Log Analysis lorsque vous choisissez les bonnes techniques de configuration et de recherche. Par exemple, vous pouvez configurer le plan d'instance IBM Log Analysis pour une recherche de 7 jours avec l'archivage des journaux dans IBM Cloud Object Storage afin d'économiser sur les coûts. Consultez également la documentation IBM Log Analysis pour connaître les techniques de recherche des journaux qui vous intéressent en fonction des mots clés, du point de cohérence, etc.
Personnalisation de votre instance de service -Vous devrez peut-être personnaliser votre instance de service pour intégrer des packages Python ou conda qui ne sont pas préinstallés, ou pour intégrer certains fichiers (certificats ou fichiers de configuration) qui doivent être mis à disposition des applications Spark. En fonction de vos besoins, personnalisez votre instance à l'aide d'ensembles de bibliothèques et utilisez ces ensembles de bibliothèques lors de la soumission d'applications.
-La taille de votre ensemble de bibliothèques a une incidence sur le temps de démarrage de l'application et le temps de démarrage de l'exécuteur (lorsque vous mettez à l'échelle automatiquement les applications). Notez également qu'il existe une limite supérieure pour la taille d'un ensemble de bibliothèques, à savoir 2 Go. Par conséquent, si des applications différentes ont besoin d'ensembles de bibliothèques différents, il est préférable que vous utilisiez des ensembles de bibliothèques distincts, de sorte qu'ils puissent être spécifiés individuellement lors de la soumission de l'application.
-Utilisez la personnalisation uniquement pour importer des fichiers qui ne peuvent pas être introduits par les paramètres des détails de l'application. Voir Paramètres de soumission des applications Spark. Vous devez utiliser les options de paramètre équivalentes standard de spark-submit, telles que les options files, jars, packages et pyFiles, si cela correspond à votre cas d'utilisation. Si vous avez besoin de fichiers qui ne rentrent dans aucune de ces catégories, par exemple un certificat autosigné, un fichier de configuration JAAS ou un fichier .so, vous devez utiliser l'option "Personnalisation pour le téléchargement de fichier".
Appliquer des filtres lors de l'extraction de la liste des applications Lorsque vous devez extraire la liste des applications dans l'interface utilisateur ou à l'aide de l'API ou de l'interface de ligne de commande, il est préférable d'appliquer les filtres appropriés et d'extraire l'ensemble dont vous avez besoin.
Utiliser d'autres services ou outils pour la prise en charge de fonctions Outre l'utilisation d'une instance IBM Log Analysis et IBM Cloud Object Storage et selon votre cas d'utilisation, vous pouvez utiliser d'autres outils et services de support. Par exemple, vous pouvez utiliser Apache Airflow (géré par vous) pour orchestrer, planifier et automatiser vos applications. Vous pouvez également utiliser IBM Secrets Manager pour stocker les secrets requis pour vos applications et utiliser vos scripts d'automatisation pour lire les secrets de Secrets Manager avant de soumettre vos applications. Vous pouvez également utiliser les arguments de votre application de manière créative, en transmettant un jeton requis pour lire les secrets requis à partir de Secrets Manager directement à partir de votre application.
Utiliser des instances dans d'autres régions pour la sauvegarde et la reprise après incident Actuellement, les instances sans serveur IBM Analytics Engine peuvent être créées dans deux régions, à savoir Dallas (us-south) et Francfort (eu-de). Bien qu'il soit conseillé de créer vos instances dans la même région que celle où se trouvent vos données, il est toujours utile de créer une instance de sauvegarde dans une autre région avec le même ensemble de configurations que votre instance principale, au cas où l'instance principale deviendrait indisponible ou inutilisable. Vos automatisations doivent permettre le basculement des soumissions d'application entre les deux régions si nécessaire. ND
Utiliser des compartiments et des données d'identification de service distincts pour les fichiers d'application, les fichiers de données et l'instance principale Utilisez le principe de "séparation des préoccupations" pour distinguer l'accès entre les différentes ressources.
-Ne stockez pas de données ou de fichiers d'application dans le compartiment de l'instance principale.
-Utilisez des compartiments distincts pour les données et les fichiers d'application.
-Utilisez des données d'identification d'accès distinctes (basées sur la clé IAM) avec un accès restreint au compartiment pour les fichiers d'application et au compartiment qui contient vos données.
Les applications doivent s'exécuter dans les 72 heures Le nombre d'heures d'exécution d'une application ou d'un noyau est limité. Pour l'application de correctifs de sécurité et de conformité, tous les environnements d'exécution qui s'exécutent pendant plus de 72 heures sont arrêtés. Si vous disposez d'une application de grande taille, fractionner votre application en petits blocs qui s'exécuteront dans les 72 heures. Si vous exécutez des applications de diffusion en flux Spark, veillez à configurer des points de contrôle et à mettre en place une surveillance pour redémarrer vos applications si elles sont arrêtées.
Démarrer et arrêter l'historique Spark uniquement si nécessaire Arrêtez toujours le serveur d'historique Spark lorsque vous n'avez plus besoin de l'utiliser. Gardez à l'esprit que le serveur d'historique Spark consomme des ressources d'UC et de mémoire en continu pendant que son état est démarré.