Herausforderungen bei der Sichtbarkeit von Anwendungen
Nachdem ich eine Webanwendung erstellt und sie allgemein zur Verfügung gestellt habe, besteht die erste Herausforderung darin, die Anzahl der Server zu bestimmen, die für den eingehenden Datenverkehr bereitgestellt werden müssen.
Um die Anzahl der Server zu bestimmen, muss ich das Verkehrsaufkommen kennen, das auf ihnen landen wird. Die Kenntnis aggregierter Zahlen hilft hier nicht weiter, da der Datenverkehr nicht konstant und gleichmäßig ist. Das Verständnis des Verkehrsmusters ist zwingend erforderlich.
Zunächst muss ich Server auf der Grundlage der maximalen Last bereitstellen, es sei denn, ich habe eine Lösung, die meine Server automatisch auf der Grundlage des Datenverkehrs skaliert.
Sobald ich mich vergewissert habe, dass der gesamte Datenverkehr ordnungsgemäß abgewickelt wird, kann ich mir Gedanken über das Nutzererlebnis machen. Zunächst muss ich feststellen, wie lange die Nutzer brauchen, um eine Seite nach dem Anklicken zu laden. Um dies herauszufinden, teile ich es in zwei Teile: Server-Antwortzeit und Browser-Redner-Zeit.
Wenn alles gut aussieht, ist es an der Zeit, tiefer zu gehen und herauszufinden, welche Bereiche (URLs) der Anwendungen mehr genutzt werden als andere. In der Regel handelt es sich dabei um die kritischen Teile des Anwendungs-Workflows, die besondere Aufmerksamkeit in Bezug auf Verfügbarkeit und Reaktionszeit erfordern. Wenn ich sehe, dass der Datenverkehr zu einer bestimmten URL sehr hoch ist, ziehe ich in Erwägung, Server für diesen Datenverkehr zu reservieren, und versuche, diesen Codepfad zu optimieren.
Wenn die vorrangigen Infrastrukturaufgaben erledigt sind, möchte ich mehr über die Nutzer erfahren. Ich schaue mir an, wie viele Nutzer die Website besuchen, ob sie neu sind oder wiederkommen und wie häufig sie wiederkommen. Ich untersuche auch, wie viele Seiten sie sich ansehen und in welcher Reihenfolge sie die Seiten besuchen. Dann berücksichtige ich, welche Browser und Geräte sie verwenden, woher sie kommen und wie sie geografisch verteilt sind.
Als Nächstes finde ich heraus, wie viel des Datenverkehrs von nicht nützlichen Bots stammt, damit ich diesen Verkehr blockieren und mich auf den echten Verkehr konzentrieren kann. Außerdem möchte ich den von einem Angreifer gesendeten böswilligen Datenverkehr erkennen (und auch verhindern). Die böswillige Absicht kann ein DDoS-Angriff (Distributed Denial of Service) sein, ein Versuch, Daten zu stehlen, oder einfach ein Versuch, die Benutzeroberfläche zu beeinträchtigen.
Wenn ich eine neue Version meiner Anwendung entwickle, vergleiche ich gerne ihre Leistung mit der derzeit laufenden Version. Ich übergebe die neue Version nur dann in die Produktion, wenn ihre Leistung akzeptabel ist.
Es reicht nicht immer aus, einen umfassenden Einblick in diese Bereiche zu gewähren. Wenn etwas schief läuft, sollte das Tool, das die Anwendung transparent macht, mir auch bei der Fehlersuche helfen und mir ermöglichen, bis auf die Ebene der einzelnen Anfragen vorzudringen.
Google Analytics ist allgemein dafür bekannt, dass es angemessene Daten zur Sichtbarkeit von Anwendungen liefert. Das reicht jedoch nicht aus, denn:
- Google Analytics erfasst nur den Verkehr, über den die HTML-Seite aufgerufen wird. Alle meine Ajax-Aufrufe und Anfragen an andere Ressourcen werden nicht erfasst
- Google Analytics erhält nur Trigger, wenn JavaScript auf der Seite ausgeführt wird. Der Zugriff von Bots ist nicht enthalten
Was ich also in Google Analytics sehe, ist die Teilmenge des Verkehrs, die auf meine Server trifft. Wenn Berichte besagen, dass der Bot-Verkehr mehr als 30 % ausmacht, kann ich auf der Grundlage der Google Analytics-Zahlen keine genaue Planung vornehmen. Da es sich bei Google Analytics um ein clientseitiges JavaScript-Tool handelt, kennt es meine Bereitstellungsinfrastruktur nicht und hilft mir nicht, Probleme zu ergründen oder zu skalieren.
Ein Traffic Load Balancer ist inline und kann einen gewissen Einblick geben, aber Load Balancer wie AWS ELB, NGINX oder HAproxy bieten nur einen sehr begrenzten Einblick in den Datenverkehr und sind aus analytischer Sicht nicht wirklich hilfreich.
Die gute Nachricht ist, dass ich eine Lösung habe, die mir nicht nur Einblick in meinen Anwendungsverkehr gibt und mir hilft, Probleme zu finden, sondern die mir auch hilft, Korrekturmaßnahmen zu ergreifen. A10 Networks Lightning ADC bietet kontinuierliche Einblicke in den Datenverkehr zusammen mit fortschrittlichem Load Balancing und Content Switching, Sicherheit (Web Application Firewall und Schutz vor Datenverkehrsspitzen, DDoS-Angriffen und bösartigen Bots), Inhaltsoptimierung und -beschleunigung sowie nahtlose Datenverkehrssteuerung in einem kontinuierlichen Bereitstellungsszenario.
Kostenlose 30-Tage-Testversion
Entdecken Sie, wie eine echte Cloud-native Architektur in Ihrer Umgebung funktioniert, indem Sie den A10 Lightning Application Delivery Controller (ADC) testen.
Holen Sie sich die kostenlose Testversion
Sehen ist Glauben.
Vereinbaren Sie noch heute eine Live-Demo.