Ich glaube, ich habe ursprünglich die Natur des Problems, das Sie erleben, falsch interpretiert.
So, jetzt das Problem ist, dass Cloudfront die Anfrage nach 30 Sekunden
Ich nahm Timeout, da Sie Cloudfront erwähnt, dass Sie vor Ihrem API-Gateway Endpunkt explizit konfiguriert Cloudfront hatte.
Es mag wahr sein, dass Sie da API-Gateway nicht, taten implizit nutzt Dienste von den „AWS Edge-Network“ (auch bekannt als Cloudfront) einen Teil seines Service zu bieten.
Meine Annahme war, dass die "versteckten" CloudFront-Distributionen von API Gateway ein anderes Verhalten aufwiesen als eine standardmäßige CloudFront-Distribution, aber offensichtlich ist das in diesem Zusammenhang nicht relevant.
Tatsächlich ist API Gateway also has a 30 second response timeout und Can Be Increased?No. Das "CloudFront" -Zeitlimit ist also im Wesentlichen dasselbe Zeitlimit wie das vom API-Gateway auferlegte.
Dies hätte natürlich Vorrang vor einem längeren Timeout Ihrer Lambda-Funktion.
Es gibt keine einfache und offensichtliche Problemumgehung. Dies scheint eine Aufgabe zu sein, die außerhalb des Entwurfs des API-Gateways liegt.
Eine Option - die ich persönlich nicht mag, wenn APIs es auf mich zwingen - ist die Paginierung. Ich hasse das wirklich ... gib mir einfach die Daten, ich kann damit umgehen ... aber es hat seine praktischen Anwendungen. Wenn die Anforderung für 1000000 Zeilen gilt, geben Sie die Zeilen 1 bis 1000 zurück und geben Sie eine next_url zurück, die die Zeilen 1001 bis 2000 abruft.
Eine weitere Option ist, dass die ursprüngliche Funktion die Anforderung mithilfe eines asynchronen Aufrufs an eine zweite Lambda-Funktion sendet. für die Verarbeitung und eine Umleitung zurückgeben, die den Benutzer an eine neue URL senden, wo die Daten abgerufen werden können. Bleib jetzt bei mir, denn diese Lösung klingt wirklich schrecklich, aber theoretisch ist es machbar. Die asynchrone Funktion würde die Arbeit im Hintergrund erledigen und die Antwort in S3 speichern. Die URL, unter der die Daten abgerufen werden, wäre eine dritte Lambda-Funktion, die den Schlüssel im S3-Bucket, in dem die Daten gespeichert werden sollen, abfragt, etwa einmal pro Sekunde für 20 Sekunden. Wenn die Datei angezeigt wird, würde sie eine URL für diesen Standort vorzeichnen und eine endgültige Weiterleitung an den Browser mit der signierten URL als Location auslösen. Wenn die Datei nicht angezeigt wird, wird der Browser erneut an sich selbst weitergeleitet, so dass die Abfrage fortgesetzt wird, bis die Datei angezeigt wird oder der Browser die Umleitungsschleife nicht mehr benötigt.
Sketchy? Ja. Lebensfähig? Wahrscheinlich. Gute Idee? Das ist strittig ... aber es scheint, als ob Sie etwas tun, das wirklich außerhalb der grundlegenden Design-Parameter von API Gateway ist, so dass entweder eine ziemlich komplexe Problemumgehung benötigt wird, die Sie irgendwo anders als mit API Gateway implementieren möchten.
Natürlich könnten Sie Ihr eigenes "API Gateway" schreiben, das auf EC2 läuft und Lambda-Funktionen direkt über die Lamdba-API aufruft und Ergebnisse an den Aufrufer zurückgibt - also übernimmt Lambda die Arbeit und die Skalierung, aber Sie vermeiden die 30 Sekunden Zeitüberschreitung. 30 Sekunden warten auf eine Webantwort.
Abgesehen von "nicht die Anfrage über CloudFront senden" gibt es keine einfache Lösung. Das 30-Sekunden-Timeout in CloudFront kann nicht geändert werden. Welche Art von Lösung haben Sie im Sinn und wie lange dauern diese Anforderungen? –
Ja Ich sah in Docs, dass Timeout-Einstellungen nicht geändert werden können und diese Anforderungen Daten für die Datenbank generieren. So übergibt der Benutzer, wie viele Datenzeilen er will und generiert sie auf Lambda. Es hängt also völlig vom Benutzer ab, er kann 1 Reihe oder 1M Reihen passieren. –