0
votes

Comment surmonter le problème de départ à froid dans AWS Lambda avec Zappa?

J'ai déployé API (application Django) dans AWS en utilisant Zappa. Je suis confronté à un problème de départ à froid. Il prend près de 7 à 8 secondes pour démarrer l'application (code est de près de 25 Mo) .Comment surmonter ce problème ??

dans Zappa Params.json, j'ai gardé garder_warm = true strong> mais d'aucune utilisation. J'ai écrit la fonction Lambda pour déclencher l'API à l'aide de l'événement Cloudwatch Scheduling, il déclenche (je peux voir dans les journaux de Zappa) mais problème non résolu. p>

échantillon code de mon gestionnaire est: p>

{
    "dev": {
        "aws_region": "ap-south-1",
        "django_settings": "api.settings",
        "profile_name": "default",
        "project_name": "api-public",
        "runtime": "python3.6",
        "s3_bucket": "api-public",
        "slim_handler": true,
        "vpc_config" : {
            "SubnetIds": [ "subnet-052347e86b94b75d3" ], // use the private subnet
            "SecurityGroupIds": [ "sg-0ba3a644d413a2b00","sg-0db0b6de5b14cda33"]
        },
        "xray_tracing": true,// Optional, enable AWS X-Ray tracing on your lambda function.
        "memory_size": 1024, // Lambda function memory in MB. Default 512.
        "log_level": "DEBUG", // Set the Zappa log level. Can be one of CRITICAL, ERROR, WARNING, INFO and DEBUG. Default: DEBUG
        "keep_warm": true, // Create CloudWatch events to keep the server warm. Default true. To remove, set to false and then `unschedule`.
        "timeout_seconds": 300,
        "keep_warm_expression": "rate(3 minutes)", // How often to execute the keep-warm, in cron and rate format. Default 4 minutes.
        "exclude": [
            ".git/*",
            ".gitignore",
            "boto3*",
            "*botocore*",
            "django-debug-toolbar*",
            "sqlparse*",
            "zappa_settings.json",
            "README.md"
        ],
        "lambda_description": "zappa deployment public", // However you want to describe your project for the AWS console. Default "Zappa Deployment".
        "extra_permissions": [{ // Attach any extra permissions to this policy. Default None
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction", 
            "Resource": ["arn:aws:lambda:ap-east-1:940180048916:function:api-public-dev"],// AWS Service ARN
        }],
    }
}


1 commentaires

Notez que AWS a modifié la manière dont la mise en réseau de Lambda permet de réduire l'impact de ces débuts à froid. Pas complètement épuisé, mais sur son chemin. Pour plus, lisez aws.amazon .Com / Blogs / Compute / ...


4 Réponses :


0
votes

Pouvez-vous inclure votre configuration Zappa? Voici un exemple de comment Keep_warm doit être utilisé, dans le contexte du fichier de paramètres, avec plus de paramètres inclus: xxx

bonne chance!


6 commentaires

Selon votre suggestion, j'ai gardé les paramètres ci-dessus ... La taille du code a diminué de 5 Mo mais pas de chance avec un problème de départ à froid


J'ai ajouté ma configuration zappa (éditée).


Lorsque vous déployez, voyez-vous une ligne pendant le déploiement qui dit qu'il installe de rester au chaud? Quand je déploie, le mien dit ceci.


Quand je vois des journaux, j'ai trouvé ceci: [1555906810631] [Débogou] 2019-04-22T04: 20: 10.629Z AEF9D3A6-57F6-436A-956F6-436A-956F6-436A-956F6-436A-956F6-436A-956E-C0713C909B47 ZAPPA Event: {'Time': '2019-04-22T04: 19: 24Z ',' Type de détail ': "Evénement planifié", "Source": "Aws.events", "Compte": "Région": "AP-EST-1'," Détail ': {} , 'Version': '0', 'Ressources': ['Arn: AWS: Événements: AP-Sud-1: 940183248916: Rule / 2F22U81036CA6T RE8A11F0671216T RE8A11F0671216DBC14C 4E4-HANDERLER.KEKET_WAR M_CALLBACK'], 'ID': ' 620E9999-95CB-7116-9061-B4E000239FED ',' Kwargs ': {}} mais ça ne fonctionne pas


Y a-t-il quelque chose à voir avec la région mentionnée dans Zappa Params.json ??


Malheureusement, je ne suis pas sûr. Il y a un relâchement pour Zappa qui pourrait être intéressant de demander: Slack.Zappa.io



0
votes

Techniquement, ce n'est pas un problème si nous pouvons accepter le fait que c'est l'une des limites de fonction AWS Lambda.

Le problème principal ici est que, nous nous forçons à utiliser Lambda qui n'est évidemment pas adapté aux exigences dues à cette limitation (retard).

Le problème si nous utilisons Lambda pour ce cas est-ce,

  • Garder la fonction Lambda en vie pendant une certaine période serait cher! Super coûteux et évidemment Lambda (conteneur) n'est pas conçu pour fonctionner comme ce mec!

    Au lieu de passer la façon dont Lambda fonctionne normalement et vous coûte beaucoup d'argent, je voudrais suggérer d'utiliser une EC2 comme serveur Web Serer (API) avec une mise à l'échelle automatique et un équilibrage de charge de la charge.

    Dans cette approche, la réponse de l'API - sera bien plus rapide, car votre API est éveillé et attend toute demande - plus cher que vous ne l'aviez pas sur Lambda, car Lambda a chargé 0,00001667 $ par GB-Deuxième fois de calcul de calcul de votre Lambda, imaginez votre Lambda éveillé pendant 10 minutes :)

    J'espère que cela vous aidera! :)

    Cheer! Singes


7 commentaires

Votre réponse est fondamentalement fausse! Garder une lambda en vie ne signifie pas que vous exécutez du code pendant une quantité de temps x, mais simplement de pinger le conteneur de temps en temps de temps en temps. Les conteneurs vivent généralement environ 5 minutes si elles sont inactives (il y a des articles qui indiquent que parfois, il peut vivre jusqu'à 45 minutes). En outre, vous dites que Lambda est à la vice, mais alors vous mentionnez EC2 avec la mise à l'échelle automatique et l'ELB, qui sera beaucoup plus chère que Lambda pour un trafic bas (à bas, je parle d'environ 30 millions d'exécutions par mois). Si ces fonctions sont exécutées pendant une seconde et sont configurées (cont ...)


Pour utiliser 1024 Mo, il ne coûterait que 49 USD par mois. Si vous configurez ensuite 2 instances moyennes EC2 au moins pour vos groupes de mise à l'échelle automatique avec un ELB sur le dessus, cela coûterait déjà 53 USD, ce qui le rend déjà de 10% plus cher. Cela irait bien plus haut avec les pointes de la circulation. Longue histoire courte: Si vous ne connaissez pas le trafic et si vous ne savez pas comment Lambda Rold commence à travailler, vous ne devriez pas donner de fausses hypothèses.


Sans parler que les fonctions fonctionnent généralement plus rapidement qu'une seconde (mais gardons-la pour la simplicité) et la plupart des temps 1024 Mo par fonction sont surchargés. Si nous laissons tomber ce nombre à 256 Mo (plus que suffisant dans la plupart des cas), le coût des fonctions de la Lambda ne serait que de 11 USD par mois.


Alors maintenant, comment réchauffez-vous cette fonction AWS Lambda sans déclencher votre fonction ??? En outre, si vous n'avez pas de calculatrice, utilisez une avec AWS. Voir Casquette d'écran ci-joint [Entrez la description de l'image ici] [1] [1]: i.stack.imgur .com / 18p2r.png


Mec pour aider pour ce calcul: Basé à partir de vous: 1. Nombre d'exécutions = 30 000 000 2. Mémoire allouée (MB) = 1024 Mo 3. Temps d'exécution estimé (MS) = 5000 (5 secondes) vous coûtera par mois = 2499,63 $ / mois de mathématiques Questions :) Peace


0 - Oui, j'ai utilisé une calculatrice. 1 - Vous ne payez que lorsque le code est exécuté, mais un conteneur reste en vie après cela et que vous ne payez pas s'il n'y a aucun code exécuté. 2 - J'ai clairement dit 1 seconde par exécution. 3 - J'ai aussi dit clairement que la plupart du temps, la mémoire peut être réduite, alors je l'ai réduit à 256 Mo. 4 - Cela coûterait seulement 11 USD par mois. 5 - C'est trop pour votre cerveau de cacahuète à traiter.


Les fonctions AWS Lambda n'ont pas été créées pour des charges lourdes en effet. L'application Django est la charge la plus lourde de tous les temps.



0
votes

Les hits périodiques sont des techniques simples, mais cela ne vous aiderait pas au cas des demandes simultanées. Une instance Lamdba ne peut gérer qu'une seule demande à l'heure. Je ne sais pas comment le faire exactement avec Zappa. Pourtant, la solution prometteuse utilise les points de contrôle de Docker

https://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/1819-ug -Projects / STENBOMO-REFONCTION-REFONCTION-ELIMINATION-START-START-START-START-DÉMARTS-CONTENANT-REUSE.PDF

Bien sûr ou peut doubler la mémoire. Il ne doublerait pas de facturer parce que les demandes seraient traitées plus rapidement.

Je suis également un peu fantastique d'ajouter aux stratégies de fantaisie de Zappa, telles que les instances d'exécution de Chep 1M par défaut mais détectent le démarrage à froid et rediriger vers des instances ou des haricots à 3 m, mais les points de contrôle semblent plus prometteurs pour les cadres surdimensionnés comme Django.


0 commentaires

0
votes

Si vous avez besoin de garder une application de Django à réchauffer, vous utilisez AWS Lambda fonctionne dans le mauvais sens, car le démarrage. (croyez-moi, expérience personnelle)

Les fonctions AWS Lambda ont été créées pour déployer des fonctions légères au monde. Votre application Django est une fonction lourde (IEST) de tous les temps.

AWS Lambda a été conçu pour les applications qui ont une durée de vie des fractions de seconde. 25 Mo pour elle-même est une chargement énorme aux fonctions Lambda.

Pensez à utiliser un cadre léger en tant que ballon, à la place. Ne pas surmonter les fonctions de Lambda. Ils n'étaient pas destinés à cela.

Utilisez AWS ECS, à la place.


0 commentaires