Zusammenfassung: Basierend auf der FinOps-Erforschung und -Praxis von FunctionGraph im serverlosen Bereich schlägt dieses Papier das branchenweit erste serverlose Funktionsmodell zur Schätzung der Gesamtkosten vor
历川：华为云Serverless研发专家
平山：华为云中间件Serverless负责人
冯嘉：华为云中间件首席专家Die zentralen Thesen:
1) Obwohl die schnelle Entwicklung von Serverless umfangreiche und eingehende Aufmerksamkeit auf sich gezogen hat, fehlt es der vorherigen Schätzung der Gesamtkosten von Serverless-Funktionen immer noch an effektiver theoretischer Anleitung. Basierend auf der Erforschung von FinOps und der Praxis von FunctionGraph im serverlosen Bereich schlägt dieses Dokument das branchenweit erste Modell zur Schätzung der Gesamtkosten für serverlose Funktionen vor;
2) Basierend auf der Analyse der Schlüsselfaktoren des Kostenmodells werden fünf Optimierungsmethoden für die Betriebskosten von Funktionen vorgeschlagen; gleichzeitig schlägt HUAWEI CLOUD eine transparente, erstmals eine effiziente One-Click-"Anwenderfunktion". Cost Research Center".
Problemeinführung
Das Millisekunden-genaue Pay-per-Use-Modell von Serverless eliminiert die Notwendigkeit für Benutzer, für Leerlaufzeiten von Ressourcen zu bezahlen. Für eine gegebene Anwendungsfunktion wird es jedoch, da die Faktoren, die sich auf ihre Abrechnungskosten auswirken, nicht eindeutig sind, zu einer schwierigen Aufgabe für Benutzer, die Gesamtabrechnung während der Laufzeit der Funktion genau abzuschätzen .
Am Beispiel des zyklischen Leasingmodells traditioneller Cloud-Ressourcen können Benutzer durch Multiplizieren der Zyklusnummer mit dem Zykluseinheitspreis die Gesamtkosten der Leasingdauer leicht abschätzen und eine klare psychologische Kontoerwartung bilden , selbst wenn die Cloud-Plattform abgestuft ist Preisgestaltung oder Preisdiskriminierung Im Falle einer Strategie ist es nicht schwierig, die Gesamtmietkosten zu berechnen.
In Serverless-Szenarien gibt es jedoch immer noch keine effektive theoretische Anleitung, um die Gesamtkosten von Funktionen im Voraus abzuschätzen. Einerseits sind die Schlüsselfaktoren, die die Funktionsabrechnung beeinflussen, nicht eindeutig , wie beispielsweise Funktionsspeicherspezifikationen, Einzelinstanz-Parallelität, Funktionsausführungszeit usw.;
Natürlich besteht die theoretische Anleitung zum Finden der Funktionsabrechnung hauptsächlich darin, Benutzern eine effektive Grundlage zur Bewertung der Gesamtkosten von Funktionen zu bieten, aber noch wichtiger, wie das Schätzmodell weiter verwendet werden kann, um Benutzern dabei zu helfen, Anwendungsfunktionen und ihre Konfigurationsauswahl zu optimieren deutliche Reduzierung der Gesamtkosten von Benutzerfunktionen Kosten sind eine dringende Frage für FinOps im Serverless-Bereich.
FinOps konzentriert sich auf das Cloud-Ressourcenmanagement und die Kostenoptimierung und optimiert die Cloud-Ressourcenkosten für Benutzer, Unternehmen und Organisationen durch die organische Verknüpfung von Technologie-, Geschäfts- und Finanzfachleuten und verbessert das Input-Output-Verhältnis des Cloud-Geschäfts [1]. Basierend auf der FinOps-Untersuchung und -Praxis von HUAWEI CLOUD FunctionGraph im serverlosen Bereich analysiert dieses Dokument das Funktionsabrechnungsmodell und die wichtigsten Einflussfaktoren im serverlosen Szenario und stellt einen Modellrahmen für die Vorabschätzung der Gesamtabrechnung während des Funktionsbetriebs vor, was noch wichtiger ist , Das Modell bietet eine effektive Grundlage, um Benutzern dabei zu helfen, die Gesamtkosten des Funktionsbetriebs zu optimieren, die Leistung des serverlosen Ressourcenmanagements in der Benutzer-Cloud zu verbessern und ein wirtschaftliches serverloses .
1. Glossar und Hintergrundwissen
Zunächst erfolgt eine kurze Beschreibung mehrerer in Tabelle 1 aufgeführter Konzepte.
Tabelle 1: Allgemeine Substantive für serverlose Funktionen
Speicherspezifikation (Speicher) : Die Speicherspezifikation, auch bekannt als Funktionsspezifikation und Funktionsinstanzspezifikation, gibt die von der Serverless-Plattform für eine einzelne Instanz der Funktion zugewiesene Ressourcengröße an, die im Allgemeinen als die Speichergröße ausgedrückt wird, die die Funktion verwenden kann vom Benutzer angegeben; die CPU, die die Instanz verwenden kann Anteile sind proportional zur Speichergröße. Serverlose Cloud-Plattformen bieten in der Regel eine Vielzahl von Spezifikationen, aus denen Benutzer auswählen können.Am Beispiel von FunctionGraph können Benutzer aus 15 Funktionsspezifikationen wählen, wie in Abbildung 1 dargestellt.
Abbildung 1: FunctionGraph bietet verschiedene Funktionsspeicherspezifikationen
Funktionsausführungszeit : Dies bezieht sich auf die Zeit, die durch die Ausführung der Funktion selbst im Prozess der Vervollständigung einer Anrufanforderungsantwort verbraucht wird, was hauptsächlich durch die Funktionscodelogik bestimmt wird. Im Allgemeinen kann bei CPU-intensiven Funktionen die Erhöhung der Funktionsressourcenspezifikation (Speicher-CPU-Anteil) die Funktionsausführungsverzögerung erheblich reduzieren. Bei Funktionen, die die meiste Zeit mit Netzwerk-E/A und anderen Vorgängen verbringen, führt eine Erhöhung der Ressourcenspezifikation jedoch nur zu einer sehr begrenzten Verbesserung der Ausführungslatenz.
Maximale Anforderungen pro Instanz: Die maximale Anzahl von Anforderungen, die eine einzelne Instanz der Funktion gleichzeitig verarbeiten kann, hauptsächlich geeignet für Szenarien, in denen während der Funktionsausführung eine erhebliche Zeit auf die Rückgabe nachgelagerter Dienste gewartet wird, z. B. Datenbankzugriffsvorgänge oder Disk-IO usw. . Bei gleicher Verkehrslast kann die Erhöhung der Einzelinstanz-Parallelität einer Funktion die Anzahl der Instanzen pro Zähler reduzieren, Benutzerrechnungen sparen und das Kaltstartverhältnis von Funktionsaufrufanforderungen reduzieren.
Maximale Instanzen pro Funktion : Bezieht sich auf die Obergrenze der Anzahl von Instanzen derselben Funktion, die gleichzeitig zur gleichen Zeit ausgeführt werden. Für Benutzer kann die maximale Anzahl von Instanzen verhindern, dass die Kosten durch übermäßigen Ausbau der Cloud-Plattform bei ungewöhnlichen Verkehrsspitzen oder Funktionsausfällen aus dem Ruder laufen; für Cloud-Plattformen kann die maximale Anzahl von Instanzen verhindern, dass Plattformressourcen teilweise ausgelastet werden Wird unter anormalen Bedingungen verwendet, verbraucht Licht und gewährleistet dadurch eine Leistungsisolierung zwischen verschiedenen Funktionen.
2. Funktionsabrechnung und Kostenmodell
Zum Schätzmodell der Funktionsabrechnung aus der Einzelinstanz-Perspektive sei auf [2] verwiesen. In einer realen Produktionsumgebung verwenden serverlose Cloud-Plattformen neben asynchronen Funktionen in der Regel FCFS (First Come First Serve), um auf Anrufanfragen zu reagieren.Bei Gezeitenschwankungen im Funktionsverkehr passt sich die Plattform durch automatische Skalierung von Instanzen an und läuft ein Die Variation der Anzahl gleichzeitiger Instanzen mit der Zeit kann vollständig durch eine stückweise konstante lineare Funktion charakterisiert werden, wie in Abbildung 2 gezeigt.
Abbildung 2: Die Anzahl der gleichzeitigen Instanzen der Funktion ändert sich mit dem Skalierungsprozess
Obwohl es Unterschiede in den Abrechnungsmethoden zwischen verschiedenen Serverless-Cloud-Anbietern gibt, umfasst die Funktionsabrechnung im Allgemeinen zwei Teile: die Abrechnung der von der Funktion verwendeten Ressourcen und die Abrechnung der Anzahl der Anfragen wie folgt:
Die zweite Hälfte stellt den Gesamtbetrag der kostenlosen Abrechnung dar, der von der Cloud-Plattform bereitgestellt wird, unabhängig von Funktionsaufrufverkehr und Funktionskonfiguration.
3. Diskussion über Kostenoptimierungsmethoden
Mit dem Schätzungsmodell der Funktionskosten können die Schlüsselfaktoren diskutiert werden, die die Benutzerkosten beeinflussen. In der Schätzformel (1) sieht die Struktur der monatlichen Gesamtkosten der Funktion unter Vernachlässigung des gesamten kostenlosen Entgelts der Cloud-Plattform wie folgt aus:
Punkt 1: Optimieren Sie die Funktionscodelogik selbst, um die Funktionsausführungsverzögerung zu reduzieren
Bei gleicher Funktionslast kann eine geringere Ausführungslatenz den Benutzern weitere Abrechnungskosten ersparen. Unter der Prämisse der Benutzergeschäftslogik ist es die natürliche Anforderung der Softwareentwicklung, den Funktionscode kontinuierlich zu optimieren und die Effizienz der Funktionsausführung zu verbessern, aber im serverlosen Szenario ist dies noch dringender.
Erwägen Sie insbesondere die Verwendung leichter Programmiersprachen wie Python und Nodejs, um unnötige Elemente in der Konfiguration der Funktionsinitialisierung zu reduzieren, und verschieben Sie den Vorgang der Verbindung anderer Dienste wie Datenbanken in die Initialisierungsphase vor dem Eintrag der Funktionsausführung so weit wie möglich, um dies zu vereinfachen die Codelogik usw.
Um Benutzern zu helfen, den Ausführungsstatus von Funktionen zu erfassen, bietet FunctionGraph außerdem eine detaillierte Visualisierung und Beobachtbarkeit für Anwendungsfunktionen und unterstützt die Konfiguration umfangreicher Beobachtungsindikatoren, einschließlich der Anzahl der Aufrufe, der Anzahl der Fehler und der Ausführung Die Laufzeit der Funktion ist in Abbildung 3 dargestellt. Überwachungsbeispiel.
Abbildung 3: Beispiel für die Laufzeitüberwachung der FunctionGraph-Funktion
Punkt 2: Funktionscodepaket, Abhängigkeitspaket, Bildgröße optimieren
Wenn ein Funktionsaufruf einen Kaltstart auslöst, wird aus Sicht der Abrechnung die Kaltstartverzögerung in die Ausführungsverzögerung einbezogen und zusammen verrechnet, während ein erheblicher Teil der Kaltstartverzögerung von der Cloud-Plattform aus Speicherdiensten von Drittanbietern verbraucht wird (z. B. Laden Sie das Codepaket und das Abhängigkeitspaket des Benutzers vom HUAWEI CLOUD Object Storage Service (OBS) herunter oder ziehen Sie das Anwendungs-Image des Benutzers aus dem Image-Repository-Dienst, wie in Abbildung 4 gezeigt. Obwohl die meisten Cloud-Plattformen derzeit verschiedene Caching-Mechanismen verwenden, um Benutzercode und Bilder vorab zu cachen, um die Kaltstartleistung zu optimieren, ist die Verzögerung beim Laden von Benutzercode während des Instanzstarts immer noch sehr erheblich . Daher sollte die Größe des Funktionscodepakets so weit wie möglich optimiert werden, einschließlich der Reduzierung von abhängigen Paketen und Bildern, um die Abrechnungszeit zu reduzieren.
Abbildung 4: Abrechnungszeit und Optimierungspunkte bei Warm- und Kaltstart
Punkt 3: Schreiben Sie funktionsorientierte, leichtgewichtige Funktionen
Unter dem serverlosen Programmierrahmen sollten Funktionen so weit wie möglich als leichtgewichtiger, funktionsorientierter Programmcode geschrieben werden, das heißt, „Funktionen sollten klein und zweckgebunden sein“[3]; „ eine Funktion nur eine Sache tun lassen “, a Einerseits lässt sich die Laufzeitverzögerung einer Funktion mit einer einzigen Funktion leichter gezielt optimieren, andererseits sind bei gleichzeitiger Implementierung mehrerer Funktionen in einer Funktion mit hoher Wahrscheinlichkeit alle Gleichzeitig werden Funktionen in ihrer Leistung beeinträchtigt, wodurch sich die Gesamtverrechnung für die Dauer des Funktionslaufs erhöht.
Abbildung 5: Beispiel für den Funktionsablauf von HUAWEI CLOUD FunctionGraph
Wenn die Anwendungsfunktion wirklich mehrere Funktionen bereitstellen muss, können Sie erwägen, die große Funktion in mehrere kleine Funktionen zu zerlegen und dann die Gesamtlogik durch Funktionsanordnung zu implementieren, wie in der Funktionsflussfunktion FunctionGraph in Abbildung 5 gezeigt. Die Dekomposition großer Funktionen ist auch eine der Best Practices für Benutzer, um mit ungewöhnlichen Szenarien wie Zeitüberschreitungen beim Serverless Computing umzugehen [4].
Punkt 4: Unter der Prämisse der Geschäftsmodellunterstützung wird Single-Instance-Multi-Parallelität angenommen
Aus der Funktionskostenstruktur von Formel (2) ist ersichtlich, dass unter der Prämisse des Geschäftsmodells des Benutzers die Konfiguration einer bestimmten Einzelinstanz-Parallelität die monatlichen Gesamtkosten der Funktion effektiv reduzieren kann , wenn der Benutzer sie nicht konfiguriert , ist der Standardwert der Cloud-Plattform normalerweise 1, d. h. eine einzelne Instanz kann nur eine Anfrage gleichzeitig verarbeiten; daher startet die Plattform, wenn die Funktion gleichzeitig aufgerufen wird, mehrere Instanzen, um zu antworten, wodurch die Anzahl von Abrechnungsinstanzen, wie in Abbildung 6 gezeigt, kann die Verwendung einer einzelnen Instanz mit mehrfacher Parallelität auch die Endverzögerung der Anrufanforderung im Wartezustand verbessern.
Abbildung 6: Einzelinstanz-Parallelität: Abrechnungsstunden-Perspektive und Instanzanzahl-Perspektive
Je höher die Parallelität einer einzelnen Instanz ist, desto besser ist es natürlich.Beispielsweise wird eine übermäßig hohe Parallelitätseinstellung die Ressourcenkonkurrenzzwischen mehreren Threads in einer Funktionsinstanz intensivieren (z. B. CPU-Konkurrenz),was zu einer Verschlechterung der Funktionsantwort führt Leistung und beeinträchtigen die Leistung der Benutzeranwendung QoS-Indikatoren usw. Gleichzeitig sind, wie im Hintergrundwissen dieses Artikels erwähnt, nicht alle Anwendungsfunktionen geeignet, Single-Instance-Multi-Concurrency einzustellen. Single-Instance Multi-Concurrency eignet sich hauptsächlich für Szenarien, in denen ein beträchtlicher Teil der Verzögerung durch den Prozess der Funktionsausführung verbraucht wird, der auf die Rückkehr nachgelagerter Dienste wartet.In solchen Szenarien ist ein erheblicher Teil der Instanzressourcen wie CPU im Leerlauf und B. beim Zugriff auf Datenbanken und Nachrichtenwarteschlangen und andere Middleware oder Festplatten-E/A, Netzwerk-E/A usw. Single-Instance Multi-Parallelität erfordert auch, dass Benutzer die Fehlererfassung (z. B. Berücksichtigung der Granularität der Fehlererfassung auf Anforderungsebene) und die Thread-Sicherheit (z. B. Sperrschutz) von globalen gemeinsam genutzten Variablen im Funktionscode anpassen.
Punkt 5: Die Auswahl der Funktionsressourcenspezifikationen sollte die Auswirkungen auf die Ausführungsverzögerung berücksichtigen
Abschließend wird die Wahl der Funktionsressourcenspezifikation diskutiert. Aus Formel (2) ist deutlich ersichtlich, dass eine größere Angabe des Instanzspeichers einem höheren Abrechnungsaufwand entspricht. Bei der Wahl der Speicherspezifikation muss jedoch gleichzeitig die Auswirkung auf die Ausführungsverzögerung der Funktion berücksichtigt werden. Aus Sicht der Benutzerfunktionen wird die Funktionsausführungsverzögerung nicht nur durch die Geschäftslogik des Codes selbst bestimmt, sondern auch durch die Größe der verfügbaren Ressourcen, wenn die Instanz ausgeführt wird. Größere Instanzgrößen entsprechen größerem nutzbarem Speicher und mehr CPU-Anteilen, was die Ausführungsleistung von speicherintensiven oder CPU-intensiven Funktionen erheblich verbessern und die Ausführungslatenz verringern kann; natürlich gibt es eine Obergrenze für diese Verbesserung Ressourcenspezifikation überschritten wird, ist die Auswirkung der Ressourcenerhöhung auf die Reduzierung der Funktionsausführungsverzögerung nahezu vernachlässigbar, wie durch die gestrichelte Linie in Fig. 7 gezeigt. Die obigen Fakten zeigen, dass es für eine gegebene Benutzerfunktion zur Reduzierung der Gesamtabrechnungskosten notwendig ist, eine angemessene Instanzgröße zu konfigurieren, um den Mindestwert so weit wie möglich zu erreichen, wie durch die durchgezogene Linie in Abbildung 7 dargestellt.
Abbildung 7: Bei der Wahl der Funktionsspezifikation müssen die Auswirkungen sowohl auf die Kosten als auch auf die Ausführungslatenz berücksichtigt werden
Abbildung 8: Analyse der Schlüsselfaktoren der Funktionsabrechnungskosten
4. Kostenforschungszentrum für serverlose Funktionen
Kosten senken und die Effizienz für die Anwender steigern ist das Kernkonzept von FunctionGraph. Obwohl die fünf oben analysierten Methoden zur Optimierung der Funktionskosten aus der Sicht der Benutzer diskutiert werden, glauben wir, dass diese Probleme weit von dem Umfang entfernt sind, den Benutzer berücksichtigen müssen; im Gegenteil, FunctionGraph untersucht weiterhin, wie Benutzern in größtmöglichem Umfang geholfen werden kann Um den besten FinOps-Effekt zu erzielen, können Benutzer die Vorteile von Economical Serverless wirklich genießen ; zum Beispiel hilft es Benutzern unter der Prämisse einer detaillierten Visualisierung und Beobachtbarkeit auf Instanzebene, den gesamten Prozess von funktionalen FinOps zu automatisieren und bietet Benutzern transparente, effiziente Ressourcenverwaltungs- und Kostenoptimierungsdienste mit Ein-Klick-Funktion.
Abbildung 9. Wahrnehmung des Online-Ressourcenverbrauchs und dynamische Spezifikationsempfehlung
Zu diesem Zweck wird FunctionGraph basierend auf interner Praxis in naher Zukunft das „ User Function Cost Research Center – Cost Analysis and Optimization Center“ einführen, das Benutzern Offline-Leistungsoptimierung, Online-Ressourcenverbrauchswahrnehmung und -optimierung bietet. einschließlich Online-Ressourcenempfehlung (Online-Ressourcenempfehlung, wie in Abbildung 9 gezeigt), prädiktive automatische Skalierungsvorschau usw. minimieren die technische Schwelle für Benutzer zur Implementierung von FinOps-Funktionen Benutzergeschäftsentwicklung, serverlose Transformation usw. bieten extremen Komfort.
V. Zusammenfassung und Ausblick
Dieses Whitepaper behandelt hauptsächlich das FinOps-Problem im Serverless-Computing-Szenario, gibt das branchenweit erste Modell zur Schätzung der Gesamtkosten für Benutzerfunktionen und bietet basierend auf diesem Modell theoretische Referenzen und praktische Übungen für Benutzer, um Anwendungsfunktionen zu optimieren, die Effizienz der serverlosen Ressourcenverwaltung zu verbessern und zu reduzieren Gesamtkosten gem.
Mit dem Aufkommen eines aufstrebenden Technologiefeldes ist die erste Frage, die beantwortet werden muss, „Why & Value". Als serverloser Funktionsberechnungs- und Orchestrierungsdienst der nächsten Generation, unterstützt von Huawei Yuanrong, FunctionGraph, kombiniert mit FinOps und anderen technischen Konzepten, bietet Benutzern weiterhin kostengünstige serverlose Dienste. In der Folge werden wir weitere topaktuelle Theorien und Praxisbeispiele rund um Allzweck-Szenarien ohne Server teilen und der Community etwas zurückgeben, einschließlich der praktischen Erfahrung mit FunctionGraph in serverlosen Microservices.
Verweise:
[1] Was ist FinOps: https://www.finops.org/introduction/what-is-finops/
[2] Lambda-Funktionen schneller und billiger ausführen: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684
[3] AWS Lambda-Kostenoptimierungsstrategien, die funktionieren. https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/
[4] Best Practices für Zeitüberschreitungen. https://lumigo.io/learn/aws-lambda-timeout-best-practices/