Dans ce blog, Mykal Dortch, développeur de systèmes Cloud, partage son expérience en matière de limites de capacité inattendues lorsqu’il travaille avec des FSC et suggère plusieurs stratégies de déploiement qui peuvent aider à surmonter ce type de problèmes.
J’ai récemment eu le plaisir d’aider un client à migrer plusieurs applications de son coûteux centre de données sur site vers le Cloud. Ayant effectué de nombreuses migrations pour d’anciens clients, j’ai passé en revue ma liste de contrôle pratique et j’ai vérifié que tout était en place pour faire avancer les choses. VPN ? Check. DNS ? Check. Planification de la capacité, octroi de licences, mise en réseau ? Check, check, check.
De toute évidence, nous avions mis les points sur les i et les barres sur les t. Nous avons travaillé ensemble pendant des semaines pour vérifier que toutes les images étaient en place dans les différents environnements et que nos piles primaires et de basculement se connectaient aux bases de données appropriées avec une disponibilité multirégionale. Nous avons vérifié les microservices, les dépendances, les mises à jour, les correctifs, les versions du système d’exploitation ; en fait, tout ce qui pourrait causer des maux de tête après la migration. Nous étions prêts.
Un problème inattendu
Le jour de notre premier déploiement complet, nous avons « actionné l’interrupteur » pour tester ce qui allait devenir l’environnement de production. Presque immédiatement, nous avons rencontré des problèmes. J’ai d’abord constaté que plusieurs instances de base de données étaient déployées, mais sans quelques volumes attachés. Ensuite, j’ai constaté que certaines des instances de l’infrastructure étaient lentes à se déployer et finissaient par échouer. Je me suis dit que c’était inhabituel, mais le but de ce « test » était d’exposer les problèmes que nous pourrions rencontrer pendant la période de mise en service. J’ai passé au peigne fin les scripts de déploiement et examiné les erreurs dans l’espoir d’identifier rapidement la cause première. La bonne nouvelle, c’est qu’il n’y a pas d’erreurs de syntaxe à trouver. Cependant, nous avons remarqué que plusieurs des déploiements ont renvoyé les mêmes types d’erreurs : quota de disque insuffisant et quota de CPU disponible insuffisant.
Après une rapide consultation du service de facturation, j’ai dressé une liste de demandes d’augmentation de quotas et l’ai envoyée au CSP. Ce qui s’est passé ensuite a été une surprise totale. Notre demande a été refusée ! Après avoir vérifié qu’il ne s’agissait pas d’un poisson d’avril, j’ai répondu dans l’espoir d’obtenir une explication plus détaillée et j’ai été informé qu’en raison des limitations de capacité dans la région souhaitée, aucune augmentation de quota ne serait accordée pour le moment. J’ai pensé que c’était un peu vague, alors j’ai poussé un peu plus loin pour obtenir un calendrier sur la date à laquelle les ressources seraient disponibles. La réponse a été un peu décourageante : aucune date d’exécution n’a pu être fournie.
Ayant travaillé avec des fournisseurs de services Cloud pendant des années, j’ai été surpris par ce résultat. De nombreux FSC sont prudents quant à l’ampleur de leur infrastructure sous-jacente, mais donnent généralement l’impression d’une capacité illimitée. La surprise de la découverte de cette limite a été comme un coup d’œil derrière un rideau de magicien. Dans un déploiement raté, la magie de l’échelle infinie a été réduite à un tour de parloir.
Mise à jour de mon Playbook de déploiement
Heureusement, tout n’était pas perdu. Avec un peu de réoutillage et quelques changements de configuration, nous avons réparti le déploiement sur plusieurs régions et prélevé un CDN pour nous assurer que le contenu était facilement accessible aux utilisateurs, quel que soit leur emplacement. Si ce changement nous a amenés à repenser la façon dont l’application était déployée, il m’a également fait repenser mes étapes de planification pour les déploiements Cloud. Mon manuel de déploiement comprend maintenant un certain nombre d’actions spécialement conçues pour éviter exactement ce genre d’incident. J’ai effectivement divisé ces ajouts dans une section que j’appelle « faire confiance mais vérifier ». Bien que je croie toujours fermement au Cloud et à tous ses pièges, j’ai ajouté ces mises en garde pour assurer une meilleure procédure de déploiement, puis-je dire, « plus parfaite ».
Dans un premier temps, je prends ma liste d’exigences existante et, après avoir alloué des ressources à chaque application, instance ou ressource, comme d’habitude, je les additionne toutes et les trie par région. Une fois rangés et triés, je vérifie que mes besoins sont inférieurs d’au moins 50 % au quota alloué, afin d’avoir de la marge pour une croissance future. Sinon, je soumets en vrac des demandes d’augmentation avec des explications détaillées sur les ressources que je prévois de déployer, les régions, les exigences, etc. À ce stade, j’aime aussi vérifier auprès du personnel technique du FSC si une annonce potentielle pourrait avoir un impact sur mes objectifs de déploiement. J’espère que cette étape permettra d’identifier les erreurs de calcul que j’ai commises concernant les plans futurs de la CSP. J’ai également eu de la chance à plusieurs reprises et j’ai découvert un paramètre peu connu, permettant de réaliser des économies, ou une fonction qui n’était pas encore disponible, et j’en ai profité lors de la phase de planification : ça ne fait jamais de mal de nouer des relations.
Après la demande initiale, je teste les quotas en créant automatiquement un ensemble de ressources destinées à tester le quota d’une ressource donnée. Par exemple, je peux essayer de provisionner des disques avec des capacités allant jusqu’au quota dur. De même, pour les processeurs, la mémoire et les autres ressources limitées par des quotas, je testerai les limites pour vérifier qu’elles sont effectivement disponibles. La première fois, je l’ai fait à la main mais j’ai depuis créé un script qui automatise le processus et garantit que les ressources créées sont lancées, testées et détruites avec un coût minimal et sans effets négatifs. En cas d’erreur, je peux également consulter les informations du journal et identifier le fournisseur Cloud, la ressource et le quota qui ont causé l’erreur. Cela fournit des informations précieuses pour moi-même, le client et le fournisseur Cloud, en levant tout doute sur la possibilité de déployer l’infrastructure et les applications proposées.
Dans plusieurs autres cas d’utilisation, notamment lorsqu’il s’agissait de haute disponibilité, nous avons également évité les quotas de ressources importants en déployant des ressources et des applications sur plusieurs fournisseurs Cloud. En fonction des besoins d’un client, nous nous sommes également étendus sur plusieurs zones et/ou régions. L’idée générale est de réduire la probabilité d’atteindre les quotas de ressources en élargissant les déploiements potentiels pour englober les ressources de plusieurs fournisseurs Cloud et obtenir une redondance supplémentaire et/ou une reprise après sinistre dans le processus. Les trois schémas les plus courants pour cette configuration sont décrits dans le diagramme ci-dessous, mais je les ai surnommés (1) maillage régional solo, (2) maillage régional multi-cloud, et (3) maillage multi-cloud, multi-régional.
Le maillage régional Solo utilise plusieurs zones dans la même région, mais s’en tient à un seul fournisseur Cloud. Cette répartition des ressources présente l’avantage supplémentaire de permettre une reprise après sinistre sans avoir à gérer les nuances entre les différents CSP. Il présente également moins de complexité réseau sous la forme de règles de pare-feu, de routes et d’adresses IP publiques. Comme de nombreuses ressources sont allouées par zone, cela multiplie le quota par le nombre de zones, ce qui représente un énorme avantage potentiel.
Dans le même ordre d’idées, le maillage régional multi-cloud développe cette idée en créant la ressource dans deux régions très proches mais qui varient selon le fournisseur Cloud. Cela augmente tous les avantages du maillage régional en solo, accroît la résilience et supprime la dépendance à l’égard d’un fournisseur donné. Ce n’est pas sans inconvénient, car le trafic entre les fournisseurs Cloud sera probablement payant. J’ai limité ce problème dans le passé en faisant fonctionner les applications de manière active sur un CSP et passive sur l’autre.
Enfin, le maillage multi-cloud et multi-régional répartit les ressources entre les régions et les fournisseurs Cloud pour une distribution efficace maximale. D’après mon expérience, c’est souvent excessif, mais j’ai pensé que je devais le mentionner par souci de rigueur. C’est très résilient, mais cela peut aussi être inutilement compliqué. Les quotas ne sont donc plus un problème, puisque les applications/ressources peuvent être ajustées en fonction du coût, de la disponibilité des ressources et d’autres facteurs, au prix d’une facture plus élevée.
En marge de ces trois stratégies de déploiement, j’utilise également la ségrégation des applications comme moyen d’éviter les quotas. Étant donné que la plupart des quotas de ressources sont généralement attribués par compte/région, le déploiement des grandes applications dans leur propre compte/région les protège de toute accaparement de ressources par d’autres applications qui partagent normalement la même infrastructure. Je développerai ce point dans un prochain article consacré à la ségrégation des applications.
Dans ces conditions, certains pourraient ressentir le besoin de revenir à la sécurité perçue d’un modèle de serveur traditionnel CapEx et d’éviter complètement le Cloud. Ce serait une erreur. Les avantages de la migration de vos applications et de votre infrastructure vers le Cloud sont bien documentés, avec des économies de coûts et de temps réalisables. La prise en compte des quotas dans votre déploiement cloud devrait présenter peu de difficultés supplémentaires et, si elle est effectuée tôt dans la phase de planification, une augmentation minimale des coûts. Je n’ai pas l’intention de présenter ici toutes les solutions possibles, mais plutôt de donner un aperçu d’un test de validation que j’ai maintenant intégré dans tout déploiement potentiel. Puisse-t-il vous épargner de nombreuses heures de frustration. Ce serait bien !
