Überraschung! Dies ist ein Bonus-Blogbeitrag für die Reihe „KI für Webentwickler“, die ich kürzlich abgeschlossen habe. Wenn Sie diese Serie noch nicht gelesen haben, möchte ich Sie dazu ermutigen . Hör zu In diesem Beitrag befassen wir uns mit der bestehenden Projektarchitektur und Möglichkeiten, wie wir sie sowohl für Anwendungsentwickler als auch für den Endbenutzer verbessern können. Ich werde einige allgemeine Konzepte besprechen und in meinen Beispielen spezifische Akamai-Produkte verwenden. https://www.youtube.com/watch?v=dvXJmiQY2Xk&embedable=true Grundlegende Anwendungsarchitektur Die bestehende Anwendung ist ziemlich einfach. Ein Benutzer gibt zwei Gegner vor, dann sendet die Anwendung eine von der KI generierte Antwort zurück, wer in einem Kampf gewinnen würde. Auch die Architektur ist einfach: Der Client sendet eine Anfrage an einen Server. Der Server erstellt eine Eingabeaufforderung und leitet die Eingabeaufforderung an OpenAI weiter. OpenAI gibt eine Streaming-Antwort an den Server zurück. Der Server nimmt alle notwendigen Anpassungen vor und leitet die Streaming-Antwort an den Client weiter. Ich habe die Cloud-Computing-Dienste von Akamai genutzt (früher). ), aber das wäre eigentlich für jeden Hosting-Dienst dasselbe. Linode 🤵 sieht aus wie ein Kellner in einem schicken Restaurant und 👁️‍🗨️ ist „ein Auge“ oder eine KI. lolz Technisch funktioniert das einwandfrei, es gibt jedoch ein paar Probleme, insbesondere wenn Benutzer doppelte Anfragen stellen. Es könnte schneller und kostengünstiger sein, Antworten auf unserem Server zu speichern und nur für eindeutige Anfragen an OpenAI zu gehen. Dies setzt voraus, dass nicht jede einzelne Anfrage nicht deterministisch sein muss (die gleiche Eingabe erzeugt eine andere Ausgabe). Nehmen wir an, es ist in Ordnung, dass dieselbe Eingabe dieselbe Ausgabe erzeugt. Schließlich würde sich die Vorhersage, wer in einem Kampf gewinnen würde, wahrscheinlich nicht ändern. Datenbankarchitektur hinzufügen Wenn wir Antworten von OpenAI speichern möchten, können wir sie praktischerweise in einer Art Datenbank ablegen, die eine schnelle und einfache Suche mit den beiden Gegnern ermöglicht. Auf diese Weise können wir bei einer Anfrage zunächst die Datenbank überprüfen: Der Client sendet eine Anfrage an einen Server. Der Server prüft, ob in der Datenbank ein Eintrag vorhanden ist, der mit der Eingabe des Benutzers übereinstimmt. Wenn ein früherer Datensatz vorhanden ist, antwortet der Server mit diesen Daten und die Anfrage ist abgeschlossen. Überspringen Sie die folgenden Schritte. Wenn nicht, folgt der Server Schritt drei im vorherigen Ablauf. Vor dem Schließen der Antwort speichert der Server die OpenAI-Ergebnisse in der Datenbank. Gepunktete Linien stellen optionale Anforderungen dar und das 💽 sieht aus wie eine Festplatte. Bei diesem Setup werden alle doppelten Anfragen von der Datenbank verarbeitet. Indem wir einige der OpenAI-Anfragen optional machen, können wir potenziell die Latenzzeit reduzieren, die Benutzer erleben, und außerdem Geld sparen, indem wir die Anzahl der API-Anfragen reduzieren. Dies ist ein guter Anfang, insbesondere wenn sich der Server und die Datenbank in derselben Region befinden. Dies würde zu viel schnelleren Reaktionszeiten führen als der Zugriff auf die Server von OpenAI. Wenn unsere Anwendung jedoch immer beliebter wird, gewinnen wir möglicherweise Benutzer aus der ganzen Welt. Schnellere Datenbanksuchen sind großartig, aber was passiert, wenn der Engpass in der Latenz durch die Flugzeit liegt? Wir können dieses Problem lösen, indem wir die Dinge näher an den Benutzer heranbringen. Integrieren Sie Edge Compute Wenn Sie mit dem Begriff „Edge“ noch nicht vertraut sind, könnte dieser Teil verwirrend sein, aber ich versuche es einfach zu erklären. Edge bedeutet, dass Inhalte so nah wie möglich am Benutzer sind. Für manche Menschen könnte das IoT-Geräte oder Mobilfunkmasten bedeuten, aber im Fall des Internets ist das kanonische Beispiel ein . Content Delivery Network (CDN) Ich erspare Ihnen die Details, aber ein CDN ist ein Netzwerk weltweit verteilter Computer, die auf Benutzeranfragen vom nächstgelegenen Knoten im Netzwerk reagieren können ( ). Während sie traditionell für statische Assets konzipiert waren, haben sie in den letzten Jahren damit begonnen, Edge-Computing zu unterstützen ( ). etwas, worüber ich in der Vergangenheit geschrieben habe Auch etwas, worüber ich in der Vergangenheit geschrieben habe Mit Edge Computing können wir einen Großteil unserer Backend-Logik ganz nah an den Benutzer heranbringen, und das hört nicht beim Computing auf. Die meisten Edge-Computing-Anbieter bieten auch eine Art schließlich konsistenten Schlüsselwertspeicher in denselben Edge-Knoten an. Wie könnte sich das auf unsere Anwendung auswirken? Der Kunde sendet eine Anfrage an unser Backend. Das Edge-Computing-Netzwerk leitet die Anfrage an den nächstgelegenen Edge-Knoten weiter. Der Edge-Knoten prüft, ob im Schlüsselwertspeicher ein Eintrag vorhanden ist, der mit der Benutzereingabe übereinstimmt. Wenn ein vorheriger Datensatz vorhanden ist, antwortet der Edge-Knoten mit diesen Daten und die Anfrage ist abgeschlossen. Überspringen Sie die folgenden Schritte. Wenn nicht, leitet der Edge-Knoten die Anfrage an den Ursprungsserver weiter, der sie an OpenAI und yadda yadda yadda weiterleitet. Bevor die Antwort geschlossen wird, speichert der Server die OpenAI-Ergebnisse im Edge-Schlüsselwertspeicher. Der Edge-Knoten ist das blaue Kästchen und wird durch 🔪 dargestellt, da er über eine Kante verfügt. EdgeWorker ist das Edge-Computing-Produkt von Akamai, dargestellt durch 🧑‍🏭, und EdgeKV ist Akamais Schlüsselwertspeicher, dargestellt durch 🔑🤑🏪. Die Edge-Box befindet sich näher am Client als der Ursprungsserver in der Cloud, um die physische Entfernung darzustellen. Der Ursprungsserver ist hier möglicherweise nicht unbedingt erforderlich, aber ich denke, es ist wahrscheinlicher, dass er vorhanden ist. Aus Gründen der Daten-, Rechen- und Logikflüsse entspricht diese weitgehend der vorherigen Architektur. Der Hauptunterschied besteht darin, dass die zuvor gespeicherten Ergebnisse jetzt ganz in der Nähe der Benutzer vorhanden sind und fast sofort zurückgegeben werden können. (Hinweis: Obwohl die Daten am Edge zwischengespeichert werden, wird die Antwort immer noch dynamisch erstellt. Wenn Sie keine dynamischen Antworten benötigen, ist es möglicherweise einfacher, ein CDN vor dem Ursprungsserver zu verwenden und die richtigen HTTP-Header auf festzulegen Zwischenspeichern Sie die Antwort. Hier gibt es viele Nuancen, und ich könnte noch mehr sagen, aber ... nun ja, ich bin müde und möchte es eigentlich nicht. Wenn Sie Fragen haben, können Sie sich jederzeit an mich wenden.) Jetzt kochen wir! Auf etwaige doppelte Anfragen wird nahezu umgehend reagiert und wir ersparen uns gleichzeitig unnötige API-Anfragen. Dadurch wird die Architektur für die Textantworten geklärt, aber wir haben auch KI-generierte Bilder. Cachen Sie diese Bilder Das Letzte, worüber wir heute nachdenken werden, sind Bilder. Beim Umgang mit Bildern müssen wir über Lieferung und Lagerung nachdenken. Ich bin mir sicher, dass die Leute bei OpenAI ihre eigenen Lösungen haben, aber einige Organisationen möchten aus Sicherheits-, Compliance- oder Zuverlässigkeitsgründen die gesamte Infrastruktur besitzen. Einige betreiben möglicherweise sogar ihre eigenen Bildgenerierungsdienste, anstatt OpenAI zu verwenden. Im aktuellen Workflow stellt der Benutzer eine Anfrage, die letztendlich an OpenAI weitergeleitet wird. OpenAI generiert das Bild, gibt es aber nicht zurück. Stattdessen geben sie eine JSON-Antwort mit der URL für das Bild zurück, das auf der Infrastruktur von OpenAI gehostet wird. Mit dieser Antwort kann mithilfe der URL ein -Tag zur Seite hinzugefügt werden, wodurch eine weitere Anfrage für das eigentliche Bild ausgelöst wird. <img> Wenn wir das Image auf unserer eigenen Infrastruktur hosten möchten, benötigen wir einen Ort zum Speichern. Wir könnten die Bilder auf die Festplatte des Ursprungsservers schreiben, aber das könnte schnell den Speicherplatz verbrauchen und wir müssten unsere Server aktualisieren, was kostspielig sein kann. ist eine viel günstigere Lösung ( ). Anstatt die OpenAI-URL für das Bild zu verwenden, könnten wir es in unsere eigene Objektspeicherinstanz hochladen und stattdessen diese URL verwenden. Objektspeicher Ich habe auch darüber geschrieben Damit ist die Speicherfrage gelöst, Objektspeicher-Buckets werden jedoch im Allgemeinen in einer einzelnen Region bereitgestellt. Dies spiegelt das Problem wider, das wir beim Speichern von Text in einer Datenbank hatten. Eine einzelne Region kann weit von Benutzern entfernt sein, was zu großer Latenz führen kann. Da Edge bereits eingeführt wurde, wäre es ziemlich trivial, CDN-Funktionen nur für die statischen Assets hinzuzufügen (ehrlich gesagt sollte jede Site ein CDN haben). Nach der Konfiguration ruft das CDN bei der ersten Anfrage Bilder aus dem Objektspeicher ab und speichert sie für zukünftige Anfragen von Besuchern in derselben Region zwischen. So würde unser Ablauf für Bilder aussehen: Ein Kunde sendet eine Anfrage, um ein Bild basierend auf seinen Gegnern zu erstellen. Edge Compute prüft, ob die Bilddaten für diese Anfrage bereits vorhanden sind. Wenn ja, wird die URL zurückgegeben. Das Bild wird der Seite mit der URL hinzugefügt und der Browser fordert das Bild an. Wenn das Bild zuvor im CDN zwischengespeichert wurde, lädt der Browser es fast sofort. Dies ist das Ende des Flusses. Wenn das Bild zuvor nicht zwischengespeichert wurde, ruft das CDN das Bild vom Objektspeicherort ab, speichert eine Kopie davon für zukünftige Anforderungen zwischen und gibt das Bild an den Client zurück. Dies ist ein weiteres Ende des Flusses. Wenn sich die Bilddaten nicht im Edge-Schlüsselwertspeicher befinden, wird die Anforderung zum Generieren des Bildes an den Server und weiter an OpenAI gesendet, das das Bild generiert und die URL-Informationen zurückgibt. Der Server startet eine Aufgabe zum Speichern des Bildes im Objektspeicher-Bucket, speichert die Bilddaten im Edge-Schlüsselwertspeicher und gibt die Bilddaten an Edge Compute zurück. Mit den neuen Bilddaten erstellt der Client das Bild, das eine neue Anfrage erstellt und mit Schritt 5 oben fortfährt. Das Content-Delivery-Netzwerk wird durch einen (🚚) und ein (📶) bezeichnet, und die Objektspeicherung wird durch Socken in einer Box (🧦📦) oder Objekte im Speicher bezeichnet. Diese Bildunterschrift ist wahrscheinlich nicht notwendig, da sie meiner Meinung nach klar ist, aber ich bin zu stolz auf mein Emoji-Spiel und benötige eine Bestätigung. Vielen Dank, dass Sie mich verwöhnt haben. Fortfahren. Lieferwagen Netzwerksignal Diese letzte Architektur ist zugegebenermaßen etwas komplexer, aber wenn Ihre Anwendung großen Datenverkehr bewältigen muss, ist sie eine Überlegung wert. Voilà Direkt am! Mit all diesen Änderungen haben wir KI-generierte Texte und Bilder für eindeutige Anfragen erstellt und stellen für doppelte Anfragen zwischengespeicherte Inhalte vom Edge aus bereit. Das Ergebnis sind schnellere Reaktionszeiten und ein deutlich besseres Benutzererlebnis (neben weniger API-Aufrufen). Ich habe diese Architekturdiagramme absichtlich auf verschiedene Datenbanken, Edge-Computing-, Objektspeicher- und CDN-Anbieter anwendbar gehalten. Mir gefällt, dass meine Inhalte breit anwendbar sind. Es ist jedoch erwähnenswert, dass es bei der Integration des Edge um mehr als nur um Leistung geht. Es gibt auch viele wirklich coole Sicherheitsfunktionen, die Sie aktivieren können. Im Akamai-Netzwerk können Sie beispielsweise auf Dinge wie zugreifen , , , und mehr. Das würde jedoch den Rahmen des heutigen Beitrags sprengen. Webanwendungs-Firewall (WAF) DDoS-Schutz (Distributed Denial of Service). Intelligente Bot-Erkennung Deshalb möchte ich Ihnen vorerst ein großes „Dankeschön“ fürs Lesen sagen. Ich hoffe, du hast etwas gelernt. Und wie immer können Sie sich jederzeit mit Kommentaren, Fragen oder Bedenken an uns wenden. Vielen Dank fürs Lesen. Wenn Ihnen dieser Artikel gefallen hat und Sie mich unterstützen möchten, können Sie dies am besten tun , , Und . teilt es Melden Sie sich für meinen Newsletter an folge mir auf Twitter Ursprünglich veröffentlicht am austingil.com .

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Making security fun one episode at a time

KI-Anwendungen: Advanced Architecture Advice (auch bekannt als AAAA!)

Zu lang; Lesen

Austin Gil

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...

KI-Anwendungen: Advanced Architecture Advice (auch bekannt als AAAA!)

Zu lang; Lesen

Austin Gil

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...

ÄHNLICHE BEITRÄGE