L'histoire de la migration du serveur domestique (MariaDB + Java) vers AWS (DynamoDB + Python + PHP) avec un coût mensuel réduit

• DynamoDB (sur demande)
• SQS (file d'attente standard)
• Lambda(Python+Pandas) + CloudWatchEvent
• ECS(EC2spot+ECR+ALB)
• S3 (format HIVE + json)
• Route53
• API Gateway

Diagramme de configuration après migration

DynamoDB Il est plus facile de migrer vers RDS (MariaDB), mais si vous migrez et exploitez des centaines de Go de données, le coût d'exploitation sera réduit. J'ai écrit qu'il migrerait vers plusieurs centaines de Go, mais toutes les données de migration seront transférées vers S3 au format HIVE + format JSON. Si nécessaire, exécutez S3 → Lambda → SQS → DyanamoDB, qui sera décrit plus loin.

Le niveau gratuit de DynamoDB est le niveau gratuit de 25 Go au moment de la rédaction de l'article et de 25 WCU / RCU à la demande.

• 1WCU peut écrire jusqu'à 1 Ko de données en 1 seconde
• 1 RCU peut lire jusqu'à 4 Ko de données en 1 seconde

Par conséquent, il est souhaitable de conserver les données par enregistrement dans 1 Ko. Cette fois, une seule table est utilisée et 5WCU / RCU est attribué. Puisque le site d'information sur le marché extrait chaque article, la clé de partition sera naturellement item_id. Puisque je veux l'avoir dans l'ordre chronologique, la clé de tri est l'heure UNIX de la date et de l'heure d'enregistrement.

Dans la base de données avant migration (MariaDB), nous avions des données en unités de magasin (avant agrégation) à intervalles de 10 minutes, La base de données migrée (DyanmoDB) contient des données en unités d'article (agrégées) à des intervalles de 3 heures.

Puisque SQS est également utilisé, la méthode d'agrégation / stockage spécifique sera décrite plus tard, mais la consommation de WCU sera comme indiqué dans la figure ci-dessous. Vous pouvez continuer à utiliser la base de données gratuitement tant que la capacité est inférieure à 25 Go.

SQS Vient ensuite SQS. Je n'avais jamais été au courant des files d'attente, mais en étudiant la SAA, j'ai découvert que c'était une très bonne solution et j'ai décidé de l'utiliser en combinaison avec DynamoDB.

Le niveau gratuit pour SQS est de 1 million de demandes. Je ne l'ai pas compris au début, mais j'utiliserai 2 demandes d'envoi et de réception. Actuellement, nous estimons avec 2000 éléments, nous le définissons donc en unités de 3 heures pour le limiter à 1 million de demandes. 2 000 * 8 * 30 * 2 = 960 000 Comme c'est SQS, ça va si vous sortez un peu, mais je veux que ça reste aussi gratuit que possible, donc c'est toutes les 3 heures.

Comme mentionné ci-dessus, les données agrégées sont stockées dans DynamoDB toutes les 3 heures. Il est stocké en unités d'articles, mais actuellement, il était nécessaire de stocker environ 2000 articles toutes les 3 heures. Si vous stockez 2000 articles en 1 seconde, vous avez besoin de 2000 WCU comme 1 Ko par article. Puisqu'il fera faillite pour plus de 1000 $ par mois, cette fois je combinerai SQS et DynamoDB pour changer le timing d'écriture.

Plus précisément, il s'agit de Lambda (agrégation) → SQS → Lambda (extraction SQS / stockage DynamoDB) → DynamoDB. Il n'est pas nécessaire qu'il s'agisse d'un FIFO, il utilise donc une file d'attente standard.

Au début, je pensais que le déclencheur Lambda de SQS était pratique, mais il y avait une consommation que je ne m'attendais pas à surveiller, et lorsque j'ai enquêté, ce qui s'est passé. Référence: https://encr.jp/blog/posts/20200326_morning/

C'est une petite chose, mais je me sentais un peu mal à l'aise, j'ai donc décidé de le récupérer moi-même auprès de SQS avec CloudWatch Event et Lambda au lieu du déclencheur Lambda.

Le nombre de SQS reçus est le suivant. Dans CloudWatch Event, la file d'attente est affichée par unités d'une minute et Lambda définit une limite d'acquisition de file d'attente pour éviter autant que possible la surcharge de capacité.

Lambda CloudWatch Event + Lambda est responsable de toutes les acquisitions et agrégations.

Lambda est le nombre de requêtes et le temps d'exécution. Le niveau gratuit est de 1 million de requêtes et 400 000 Go de secondes. Au moins, mon utilisation n'a pas dépassé le niveau gratuit. (Un peu plus de 10% du cadre libre)

Au moment de la rédaction de cet article, les fonctions suivantes sont créées.

• Acquisition des données de base (sauvegarde S3)
• Acquisition des données de vente / commande (sauvegarde dans S3)
• Agrégation des données de vente / commande (acquisition / stockage S3 / SQS)
• Acquisition de données de population (sauvegarde S3)
• Agrégation des données de population (acquisition / stockage S3 / SQS)
• Fonction de réponse pour API Gateway
• Autres fonctions de création de contenu

Puisque j'utilise Python + Pandas, il est très facile de faire l'agrégation. Au début, j'ai pensé que je pourrais le pousser avec, mais cela est devenu très douloureux dans la mémoire, alors j'ai utilisé des Pandas.

Puisqu'il utilise le Framework sans serveur, il est plus facile à déployer. Je pense que ce que je fais est le même que CloudFormation, donc je décris également API Gateway.

• L'autorité administrative est requise, mais je pense que cela est inévitable en raison du mécanisme ...

Si vous répétez le test et le déploiement, le gaspillage augmentera probablement à cause de la gestion des versions. Je pense que vous devriez utiliser "serverless-prune-plugin" pour le supprimer automatiquement.

Le montant d'utilisation pour Lambda est le suivant. La quantité de mémoire allouée varie en fonction de la fonction, mais elle est définie entre 128 Mo et 512 Mo.

CloudWatchEvent Utilisé pour le traitement par lots (traitement régulier). Je pense qu'il y a diverses choses telles que EC2 + cron et digdag, mais comme Lambda peut être utilisé, je vais le combiner avec CloudWatch Event.

Quand j'ai pensé que le lot ne fonctionnait pas à un moment donné, c'était GMT ... Comme la langue est définie sur le japonais, je me méfiais de JST ...

ECS(EC2) Ensuite, concernant ECS, c'est très puissant. C'est une combinaison de ECR + ECS + ALB + Route53.

1. ECR - contenant l'image du docker
2. ECS (Service-> Task) --Exécuter le conteneur docker
3. ALB-Cibler la tâche ECS (conteneur docker)
4. Route 53 - Communication inter-conteneur de docker utilisant la découverte de service ECS

J'utilise EC2 au lieu de Fargate. (Parce que c'est pas cher ...) ECS et ALB vous permettent d'exécuter plusieurs conteneurs de tâches> docker dans une seule instance EC2.

Cela vous permet de déployer sans mettre à jour ni ajouter de nouvelles instances. (Sauf s'il s'agit de la limite de mémoire de l'instance) L'existence de l'instance EC2 elle-même devient mince et, comme elle est exécutée par docker, elle ne se connecte pas par SSH lui-même.

EC2 utilise également des instances ponctuelles. Cela a entraîné une réduction de 70% des frais par rapport aux instances à la demande, en fonction du type d'instance.

Au lieu d'une grosse remise, c'est un substitut qui peut être interrompu par AWS à tout moment. En cas d'échec, Spot Fleet reconstituera automatiquement les instances requises et le service ECS reconstituera les tâches requises. Dans le même temps, le contrôle de santé par ALB fonctionne, les choses anormales sont supprimées de la cible et les choses normales sont ciblées.

Depuis que j'ai utilisé l'instance t3.micro cette fois, cela coûte environ 1 yen par heure, et s'il est exploité par 2 unités pendant 1 mois, ce sera environ 1440 yens. Étant donné que nous utilisons des instances Spot, ce sera cette fois-ci de 432 yens avec une réduction de 70%, selon le cas.

ALB Comme mentionné précédemment, il est utilisé pour la combinaison avec ECS, mais il est possible d'utiliser des certificats par ACM. C'est beaucoup plus facile que Let's Encrypt, car ce n'est qu'une simple pression sur un bouton.

Cependant, cela coûtera probablement environ 2000 yens en fonction du nombre d'accès. Une utilisation personnelle est un peu chère si vous l'utilisez avec un seul service, mais parce que l'hôte est possible, Si vous exécutez plusieurs services, je ne pense pas que ce soit un investissement élevé compte tenu de l'ECS, de l'ACM, du routage et de la gestion.

De plus, les sessions persistantes sont désactivées car Redis gère les sessions. En effet, si l'EC2 tombe soudainement lorsqu'il est allumé, l'accès sera effectué à l'EC2 déposé.

Route 53 Ce sera autour du domaine. D'ailleurs, en ce qui concerne le domaine, nous avons transféré de "Name.com" à "Route 53" l'année dernière. En gros, cela coûte environ 50 yens par mois.

En plus de cela, il existe une fonctionnalité appelée ECS Service Discovery. Il est difficile de réaliser la communication entre les conteneurs avec ECS. (Bien que différents conteneurs sur le même serveur puissent être connectés, différents serveurs, mode réseau, etc ...)

Dans la découverte de services, les services enregistrés auprès d'ECS peuvent être automatiquement enregistrés / mis à jour dans la zone hôte interne. Si le mode réseau est awsvpc, un enregistrement peut être enregistré.

Puisqu'une nouvelle zone hôte sera créée, cela coûtera environ 50 yens à nouveau, mais il est très utile de lier automatiquement le service et le domaine interne. Même si le service (tâche) tombe en panne, ECS le renverra automatiquement et le liera.

Dans cet environnement, Redis (et non ElastiCache) est configuré dans ECS, donc Il est utilisé pour communiquer avec le côté application (conteneur séparé). Ce serait bien de pouvoir utiliser ElastiCache, mais cela coûte de l'argent ...

S3 Dans S3, vous serez facturé pour la quantité de stockage et GET / PUT. Dans ce système, les données de base et les données pré / post sont stockées dans S3. Étant donné que PUT ne peut être effectué que du côté système, j'essaie de ne pas le générer autant que possible, mais comme GET dépend du timing de l'utilisateur, mettez-le en cache dans EC2 en utilisant Redis afin que GET ne se produise pas autant que possible. Je suis.

Mesures du robot d'exploration

La communication coûte aussi de l'argent, c'est une petite chose, mais je pense que plus on combine les services, plus l'impact est grand. Surtout dans ALB, il y a des frais pour les nouvelles connexions, donc je ne veux pas gaspiller la communication. C'est bien que robots.txt puisse le gérer, mais je pense que c'est aussi une bonne idée de déconnecter la connexion entrante avec ACL.

Environ 2 mois plus tard

Je me demandais s'il serait instable parce que j'utilisais des instances Spot, mais j'ai été surpris qu'il n'y ait aucune preuve qu'il était tombé. J'avais développé de nouvelles fonctions pendant plusieurs semaines après le remplacement, mais c'est beaucoup plus facile à développer que dans l'environnement précédent.

D'autant plus qu'il est développé avec Docker, c'est un peu difficile au moment de la construction, mais après cela, il vous suffit de construire et de mettre à jour la tâche. Les pandas du côté Lambda sont également très faciles à manipuler, et une fois le mécanisme établi, j'ai l'impression de pouvoir tout faire. → Fondamentalement, les données sont générées par Lambda, stockées dans Redis par Laravel, et le résultat est renvoyé à l'utilisateur.

Le montant d'utilisation du niveau gratuit était le suivant avant la fin du mois.

Cela faisait plus d'un an que j'avais créé mon compte, alors je pensais que je n'aurais pas un abonnement gratuit d'un an. C'était un niveau gratuit et aucune facturation n'était encourue. Est-ce un an à compter de la première facturation au lieu de créer un compte?

Perspectives d'avenir

Cette fois, j'ai l'impression d'avoir fait la transition. Étant donné que toutes les données passées sont enregistrées dans S3, elles sont prêtes à être reflétées dans DynamoDB chaque fois que nécessaire. (Je pense que les données passées ne sont pas vraiment nécessaires ...)

Comme je ne faisais que des travaux de conception, les travaux d'exploitation sont rares. Par exemple, le processus de déploiement est manuel. J'aimerais combiner CircleCI et CodeDeploy l'un après l'autre, mais je me demande si je suis en difficulté si je développe par moi-même.

En outre, les environnements de surveillance sont également rares. Nous ne surveillons pas la forme externe et ne configurons pas SNS. J'ai récemment remarqué que je définissais robots.txt et ACL car les bots accèdent beaucoup et consomment sobrement LCU. Étant donné que le journal est envoyé vers CloudWatch, je souhaite créer un environnement dans lequel il peut être facilement analysé.

Puisque nous avons affaire à des données numériques, je pense qu'il serait intéressant d'essayer l'apprentissage automatique. En fait, je l'ai un peu touché (régression multiple), mais j'ai crié sur mon PC avec de nombreux paramètres ('A' Lambda est très difficile, alors je me demande si cela ressemble à la configuration d'une instance et à son analyse.

finalement

Le contenu de chacun est devenu mince, mais si j'en ai l'occasion, j'aimerais m'y plonger et écrire un article. Merci d'avoir lu jusqu'ici!