🌓 ⚗️ 👨‍👨‍👧 Comment réduire les coûts dans AWS 🛌🏽 👥 💻

Le monde change radicalement. De nombreuses entreprises recherchent un moyen de réduire leurs coûts, juste pour survivre. Dans le même temps, la charge qui pèse sur les services en ligne s'intensifie - en particulier ceux liés à l'organisation du travail à distance, à la conduite de vidéoconférences et à l'apprentissage en ligne.

Dans ces conditions, il est extrêmement important d'une part - d'assurer la fiabilité et l'évolutivité de votre infrastructure. En revanche, ne vous envolez pas dans le tuyau avec l'achat de serveurs, de disques, le paiement du trafic.

Chez Bitrix24, nous sommes très actifs dans l'utilisation d'Amazon Web Services, et dans cet article, je parlerai de plusieurs fonctionnalités AWS qui peuvent vous aider à réduire vos coûts.

Bitrix24 est un service mondial, nous travaillons pour des clients du monde entier. Depuis 2015, depuis l'entrée en vigueur de la loi 242- sur la localisation des données personnelles, les données des utilisateurs russes sont stockées sur des serveurs en Russie. Mais toute l'infrastructure du service au service des clients restants dans le monde est déployée dans Amazon Web Services.

La crise économique est déjà un fait accompli. Le dollar a augmenté et il est peu probable qu'il revienne à sa position précédente dans un proche avenir, donc payer pour l'hébergement en devises étrangères devient assez onéreux.

Dans ces conditions, si vous continuez à placer vos ressources dans AWS, vous serez très probablement intéressé par les techniques qui vous aideront à économiser sur la location de l'infrastructure.

Je vais parler des principaux que nous utilisons nous-mêmes depuis de nombreuses années. S'il existe d'autres méthodes que vous utilisez - veuillez les partager dans les commentaires.

Alors allons-y.

RI - Instances réservées

Le moyen le plus simple et le plus évident d'économiser de l'argent sur AWS est d'utiliser des instances EC2 réservées. Si vous savez que vous utiliserez certainement certaines instances au moins au cours de l'année, vous pouvez leur verser un acompte et bénéficier d'une remise de 30% à 75%.

Exemple de calculs pour les instances c5.xlarge:

Tous les prix et calculs sont ici .

Parfois, cela semble compliqué et déroutant, mais en général, la logique est la suivante:

Plus la période de réservation est longue - 1 ou 3 ans - plus la remise est importante.
Plus le prépaiement est immédiat - vous pouvez le faire sans aucun prépaiement, vous pouvez utiliser tous les prépaiements initiaux et complets - plus la remise est importante.
Si nous réservons un type spécifique d'instance, mais que nous n'en utilisons pas de convertible, il y a plus de remise.

Pour nous, nous faisons des réservations pour 1 an, car la planification pour 3 ans est assez difficile. Et cela permet une bonne économie sur EC2.

Instances ponctuelles

L'utilisation d'instances ponctuelles est essentiellement une sorte d'échange de ressources. Lorsqu'Amazon dispose de nombreuses ressources inactives, vous pouvez définir le prix maximum que vous êtes prêt à payer pour ces «instances ponctuelles» spéciales.

Si la demande actuelle dans une certaine région et AZ (zone de disponibilité) est faible, ces ressources vous seront fournies. De plus, à un prix 3-8 fois inférieur au prix de la demande.

Quel est le piège?

La seule chose est que s'il n'y a pas de capacité disponible, les ressources demandées ne vous seront pas données. Et si la demande augmente brusquement et que le prix au comptant dépasse votre prix maximum fixé, votre place sera terminée.

Naturellement, de telles instances ne conviennent pas, par exemple, à une base de données en production. Mais pour certaines tâches qui sont associées, par exemple, à certains calculs, le rendu, le calcul de modèles, pour les tests est un excellent moyen d'économiser.

Voyons en pratique pour quels montants nous nous battons. Et combien de fois les taches peuvent «disparaître» à un prix.

Voici un exemple de l'historique des prix des instances ponctuelles directement à partir de la console AWS pour la région eu-central-1 (Francfort) pour les instances c5.4xlarge:

que voyons-nous?

Le prix est environ 3 fois plus bas que sur demande.
Il existe des instances ponctuelles disponibles dans les trois AZ de cette région.
Depuis trois mois, le prix n'a jamais augmenté. Cela signifie qu'un spot lancé il y a trois mois avec un prix maximum donné, par exemple 0,3 $, continuerait de fonctionner.

Comment nous utilisons les spots dans la pratique:

- Nous utilisons des spots pour les serveurs d'applications.

- Pour eux, nous utilisons activement le bundle CloudWatch + Auto Scaling - pour évoluer automatiquement tout au long de la journée: la charge augmente - de nouvelles instances sont lancées, la charge diminue - elles sont éteintes.

- Pour plus de sécurité, nous avons deux groupes Auto Scaling travaillant pour les équilibreurs - au cas où les taches s'épuiseraient. Un groupe AS - avec des instances normales (à la demande), le second - avec des spots. Amazon via CloudWatch Events avertit dans 2 minutes que l'instance ponctuelle sera supprimée (se terminera). Nous traitons ces événements et parvenons à étendre le groupe principal au nombre d'instances requis, si cela se produit.

Détails ici - Avis d'interruption des instances ponctuelles .

- Pour travailler plus efficacement avec Auto Scaling et utiliser au maximum les machines du groupe avec des spots, nous utilisons cette approche:

Le groupe spot a une poubelle supérieure inférieure - nous commençons à augmenter «plus haut» plus tôt.
Et une poubelle inférieure inférieure - nous commençons à évoluer plus tard "vers le bas".
Pour un groupe régulier, l'inverse est vrai.

Magasin d'instances EC2

Tous ceux qui travaillent avec AWS savent que les principaux lecteurs utilisés pour les instances EC2 sont EBS (Elastic Block Store). Ils peuvent être montés sur des instances, désactivés, montés sur d'autres instances, instantanés à partir d'eux.

Tous les EBS selon leur type sont facturés d'une manière ou d'une autre. Et ils coûtent de l'argent assez tangible.

Dans le même temps, pour de nombreux types d'instances lors de leur création, la connexion des disques locaux est disponible - EC2 Instance Store .

La caractéristique principale de ces disques est que si vous arrêtez l'instance avec un tel disque, ces données sont perdues après le démarrage.

Mais en même temps, ils sont conditionnellement gratuits - il n'y a un paiement que pour l'instance elle-même.

Ces disques peuvent être parfaitement utilisés pour toutes les données temporaires qui ne nécessitent pas de stockage constant - swaps, cache, toutes autres données temporaires. Les performances des disques Instance Store sont assez élevées: en plus des très anciens types d'instances, des SSD ou des SSD NVMe sont désormais utilisés pour eux.

Résultat: nous connectons moins de disques EBS, nous payons moins.

S3 Téléchargements multiparties incomplets

La discussion ci-dessus concernait principalement EC2. Ensuite, nous décrivons quelques astuces qui permettront d'économiser lors de l'utilisation de S3 (Simple Storage Service).

Si vous travaillez activement avec S3, vous savez probablement que S3 et la plupart des clients pour travailler avec ce stockage prennent en charge le téléchargement en plusieurs parties - un grand objet est chargé avec des «pièces», qui sont ensuite «assemblées» en un seul objet.

Cela fonctionne très bien, mais il y a une embuscade.

Si le téléchargement n'est pas terminé pour une raison quelconque (la connexion a été interrompue, par exemple, et le téléchargement n'a pas repris), les parties téléchargées ne sont pas supprimées par elles-mêmes. Cependant, ils prennent de la place, vous payez pour eux.

Et une surprise désagréable - ces données incomplètes ne sont en aucun cas visibles lorsque vous travaillez avec des outils standard pour S3: ni via «ls» dans cli, ni dans les programmes clients. Vous pouvez les trouver, par exemple, dans aws cli en utilisant la commande list-multipart-uploads .

Mais travailler avec eux est trop fatigant ...

Il serait plus logique de supprimer une option concernant le stockage des téléchargements multiparties incomplets dans les paramètres d'un compartiment particulier. Mais pour une raison quelconque, Amazon ne l'a pas fait.

Néanmoins, il existe un moyen de vous faciliter la vie et de supprimer automatiquement les téléchargements multiparties incomplets. Dans les paramètres de compartiment de l'onglet Gestion, il y a une section Cycle de vie. Il s'agit d'un outil pratique qui vous permet de configurer diverses règles automatiques pour travailler avec des objets: déplacez-les vers d'autres référentiels, supprimez-les après un certain temps (expire) et - y compris - contrôlez le comportement des téléchargements multiparties incomplets.

Un article détaillé à ce sujet est sur le blog AWS - mais avec des exemples de l'ancienne interface, mais tout est assez clair.

L'important est que Lifecycle configuré pour supprimer les données incomplètes fonctionnera non seulement pour les nouveaux objets, mais aussi pour les objets existants.

Le volume réel occupé dans l'espace S3 peut être surveillé via CloudWatch. Lorsque nous avons mis en place la suppression des téléchargements multiparties incomplets, nous avons été surpris de constater que nous avions libéré plus d'une douzaine de téraoctets ...

Nivellement intelligent S3

S3 a plusieurs classes de stockage différentes:

La norme.
Standard-IA (peu fréquenté) - pour les objets qui sont rarement accessibles.
Une zone-IA - pour les données relativement non critiques. Dans cette classe, les objets sont répliqués sur moins de points.
Le glacier est un stockage très bon marché, mais vous ne pouvez pas en obtenir instantanément un objet. Vous devez faire une demande spéciale et attendre un peu.

Tous ont des conditions d'utilisation et des prix différents. Ils peuvent et doivent être combinés - en fonction de vos différentes tâches.

Mais relativement récemment, un autre type de stockage très intéressant est apparu - Intelligent Tiering.

L'essence de son travail est la suivante: moyennant un petit supplément, la surveillance et l'analyse de vos données dans S3 sont effectuées, les appels à celles-ci sont surveillés et s'il n'y a pas d'appels pendant 30 jours, l'objet est automatiquement déplacé vers le stockage d'accès peu fréquent, ce qui coûte beaucoup moins cher que le stockage standard. Si après un certain temps l'objet est à nouveau accessible - aucune perte de performances ne se produit en même temps - il est à nouveau déplacé vers le référentiel d'accès standard.

La commodité la plus importante: vous-même n'avez rien à faire.

Amazon fera tout «intelligemment» lui-même - il saura quels objets mettre.

En activant la hiérarchisation intelligente, nous avons économisé jusqu'à 10 à 15% sur certains compartiments.

Tout semble trop beau et magique. Mais ne peut-il pas y avoir des écueils? Ils le sont et ils doivent bien entendu être pris en compte.

Il y a des frais supplémentaires pour les installations de surveillance. Dans notre cas, il est entièrement couvert par les économies.
Vous pouvez utiliser la hiérarchisation intelligente pour tous les objets. Cependant, les objets de moins de 128 Ko ne seront jamais transférés au niveau d'accès peu fréquent et seront toujours payés au prix normal.
Ne convient pas aux objets stockés moins de 30 jours. Ces objets seront toujours payés au moins 30 jours à l'avance.

Comment activer la hiérarchisation intelligente?

Vous pouvez spécifier explicitement la classe de stockage INTELLIGENT_TIERING dans l'API S3 ou CLI.

Et vous pouvez configurer la règle de cycle de vie, selon laquelle, par exemple, tous les objets après un certain temps de stockage seront automatiquement déplacés vers Intelligent Tiering.

En savoir plus sur le même blog AWS .

Glacier

Si nous parlons de différentes classes de stockage dans S3, alors, bien sûr, Glacier mérite également d'être mentionné .

Si vous avez des données qui doivent être stockées pendant des mois et des années, mais dont l'accès est extrêmement rare - par exemple, les journaux, les sauvegardes - alors assurez-vous d'envisager d'utiliser Glacier. Le prix de son utilisation est plusieurs fois inférieur au S3 standard.

Pour un travail pratique avec Glacier, vous pouvez utiliser les mêmes règles de cycle de vie.

Par exemple, vous pouvez définir une règle selon laquelle un objet sera stocké dans un stockage normal pendant un certain temps, par exemple, 30 à 60 jours (généralement, un accès est nécessaire aux journaux ou sauvegardes les plus proches dans le temps, si nous parlons de leur stockage), puis il sera déplacé vers Glacier, et après 1-2-3 ... ans - complètement retiré.

Ce sera beaucoup moins cher que de le stocker simplement dans S3.

* * *

J'ai parlé de quelques astuces que nous utilisons nous-mêmes activement. AWS est une énorme plate-forme d'infrastructure. Certes, nous n'avons pas parlé des services que vous utilisez. S'il existe d'autres moyens d'enregistrer dans AWS qui vous sont utiles, veuillez les partager dans les commentaires.