Microsoft Azure – Schnellere Datenbereitstellung mit Azure, der Web-API und Redis

Durch Johnny Webb | Dezember 2015

Im heutigen Worldof in Echtzeit Marketing, den sich drehenden Kreis fehl, die häufig begleitet warten auf eine Seite zu laden oder eine Suchabfrage zum Auffüllen der Tod eines Verkaufs wahrsten Sinne des Wortes bedeuten kann. Wie mehr Datensätze erstellt, gespeichert und analysiert werden, die Generierung von umfangreichen, Echtzeitdaten Insights wächst immer schwieriger. Die Frage ist die richtige Technologie-Tools auswählen und Architekturen am besten Spuren von Millionen von Datensätzen und sofortige Ergebnisse für den Kunden eine bessere bereitstellen.

In diesem Artikel wird einen aktuelle Anwendungsfall untersuchen, in dem Bereich halfen wir einen Client Redis und Web-API zu implementieren. Wir kommen unser Implementierungsansatz, die Probleme, die wir festgestellt und wie wir letztendlich erforderlichen Leistung erreicht.

Geschäftliche Herausforderung

Vor einigen Monaten erreicht eine diversifiziert Fortune 100-Versicherungsunternehmen und Finanzdienste Organisation Harte-Hanks, ein globales marketing-Unternehmen, mit einer neuen Initiative. Das Unternehmen wollte eine bessere und umfangreichere Kundenzufriedenheit bei der online-Versicherungsunternehmen Kostenvoranschlag bereitstellen. Zu diesem Zweck musste schnellen und proaktiven Zugriff auf die Daten des Kunden zu aktivieren.

Das Ziel war, damit Benutzer anzuzeigen, und wählen eine oder mehrere Versicherungspolicen über Self-service oder Agent gerichteten Internetanwendungen. Schließlich würde dies zu höheren Geschäftswert, höhere Kundenzufriedenheit, höhere Gebühren für Angebot zu binden und eine verbesserte Inbetriebnahme Agentprozess führen. Um dies Realität bei der gespeicherten Informationen und Daten der Kunden verarbeitet werden, musste Angebot verglichen und proaktiv, auf nahezu sofortige Weise bereitgestellt.

Der Client-Datenbank enthält mehr als 50 Millionen Datensätze, die mit einer herkömmlichen Datenbank bedeutete, dass eine Anforderung dieser Art in der Regel mehrere Sekunden dauern würde. Wir wurden beauftragt bereitgestellt, die einen Webdienst kann das Ausführen von Abfragen für diese großen Datenquelle und Bereitstellung von Ergebnissen für Verbraucher in Millisekunden.

Für diese Aufgabe ausgewertet wird die Implementierung von Redis und Web-API. Die gesamte Measure Faktoren wurden:

Transaktionsanforderungen
Objekt-Anfragen
Antworten pro Sekunde
Gesamt-Bandbreite von Daten
Gesamtdurchsatz des Standorts

Implementierung: Wie wir es getan haben

Erstellen einen Webdienst zum Verfügbarmachen von Daten erfordert mehrere Ebenen von Komponenten, die bestimmten Funktionen bereitstellen. Wächst die Anforderung für den Webdienst muss die Infrastruktur zur Unterstützung dieser Ebenen anpassen und rasch skaliert werden. Und obwohl Skalierbarkeit wichtig ist, Verfügbarkeit ist ebenso wichtig und muss immer berücksichtigt werden, um den Consumer zufrieden sind. Darüber hinaus müssen verfügbar gemachten Endpunkte überwacht und zusammen mit der bestimmte Authentifizierungsprotokolle, um sicherzustellen, dass die Daten geschützt und die maximale Leistung sicher übermittelt werden. Damit diese Anforderungen für unsere Lösung gerecht zu werden, nutzten wir Microsoft Azure. Innerhalb von Azure wir eine Kombination von Ressourcen, z. B. virtuelle Computer, Web-apps, virtuelle Netzwerke, Ressourcengruppen bereitgestellt und Verfügbarkeit auf um eine voll funktionsfähige, qualitativ hochwertige Lösung zu erstellen.

Die Datenschicht

Da die meisten unserer Lösungen sind mit den Microsoft-Stapel erstellt, ist es sinnvoll, die wir nutzen von Microsoft SQL Server in den meisten Fällen. Die SLA-Anforderungen für diese Lösung wird jedoch eine Dienst-Antwortzeit von weniger als 1 Sekunde pro Anforderung mit einer Geschwindigkeit von ca. 6.000 Anforderungen pro Stunde in einem Dataset mit mehr als 50 Millionen Datensätze angegeben. Da herkömmliche Datenbanken wie SQL Server Daten auf dem Datenträger gespeichert und werden von IOPS Engpässe, konnte nicht garantiert werden, dass jeder Abfrage die Anforderung übergeben würden. Um die Angelegenheit noch weiter zu erschweren, gehörten die Teilmenge der Daten, die wir benötigten bereits verfügbar machen in einer herkömmlichen Datenbank Terabyte an Daten enthält. Aus diesem Grund wurde Auswerten von Lösungen, die große Datasets schnell unterstützen konnte. Wird, wenn wir Redis ermittelt.

Redis ist ein in-Memory-Struktur Datenspeicher, der mehrere Datentypen unterstützt. Die Essentials-Server-Anforderungen umfassen ein Linux-Distribution ausreichend RAM für Ihre Daten zu kapseln und genügend Speicherplatz für Dauerhaftigkeit von Daten. Redis kann auch als Cluster konfiguriert werden, aber dies ist eher geeignet für Lösungen mit Terabyte an Daten. Da unser Dataset weniger als 50 GB wurde, entschieden wir einfach zu halten und Einrichten einer einzelnen Master/Slave-Konfiguration. Um diese Konfiguration zu hosten, haben wir zwei CentOS 7.1 virtuelle Computer in einem virtuellen Netzwerk in Azure. Jeder virtuelle Computer enthalten, 56GB Arbeitsspeicher, eine statische IP-Adresse und einen SSH-Endpunkt mit AES256-Verschlüsselung. Da beide virtuellen Computer eine verfügbare Gruppe freigegeben, bereitgestellten Azure 99,95 Prozent, die SLA Betriebszeit garantiert. Als Zugabe wurden alle Ressourcen, die wir erstellt eine Ressourcengruppe erstellt, die speziell für diese Lösung ermöglicht uns, überwachen und Verwalten der Abrechnung monatlich angehängt. Innerhalb von wenigen Minuten waren unsere VMs bereitgestellt und uns verfügbar.

Einarbeitung unsere Redis-Server ist einfach und erfolgt auch innerhalb einer Stunde. Nach dem Herunterladen und Installieren der neuesten stabilen Version auf unseren Servern neu erstellten, zuallererst wir die Konfigurationsdatei geändert um zuzulassen, was nur Anhängen-Datei (einer) Persistenz Redis aufruft. Kurz gesagt, dies bedeutet, dass jeder Befehl gesendet wird, um unserer Instanz gespeichert wird auf dem Datenträger. Würde der Server neu starten, werden alle Befehle Wiederherstellen des Servers in seinen ursprünglichen Zustand erneut ausgeführt. Um ein sehr großer einer auszuschließen, Umschreiben der Datei mit der kürzesten Befehlsfolge erforderlich, um das aktuelle Dataset im Arbeitsspeicher neu gelegentlich ein BGREWRITEAOF Befehl ausgelöst. Darüber hinaus konfiguriert wird eine maximale Speicherverwendung von 50GB, erstellen einen Puffer und verhindert, dass Redis alle Systemarbeitsspeicher belegen, wenn zu viele Daten geladen wurde. Denken Sie daran, wenn unsere Lösung je mehr Arbeitsspeicher benötigt konnte wir problemlos ändern der Größe der VM mit der Azure-Verwaltungsportal und aktualisieren Sie die Konfiguration später. Im nächsten Schritt konfiguriert es die Slave-Instanz, um den Master, erstellen die Replikation der Daten zu bestätigen. Würde die master-Instanz nicht mehr verfügbar sind, wäre die Slave-Instanz unserer Kunden bedient. Abschließend Neustart wir unsere Redis-Server für die Konfigurationen wirksam wird. Hier werden die Konfigurationen, die wir verwendet:

appendonly yes
maxmemory 50000000000
slaveof 10.0.0.x 6379
# cluster-enabled no

Laden von Daten und Vergleichstests

Die Daten in Redis aus unserem herkömmlichen Datenbank laden benötigten enthalten ca. 4 GB Customer-Metadaten. Diese Metadaten wurde täglich aktualisiert, sodass wir erstellen einen Prozess, um es in einen Redis-Datentyp umzuwandeln, mussten und Bulk laden, um unsere Lösung auf dem neuesten Stand zu halten. Zum Ausführen dieser wurde erstellt einen automatisierten Prozess, um die täglichen Changesets in Redis-Protokoll-formatierte Dateien zu extrahieren und übertragen sie auf dem Masterserver unter Verwendung des SSH-Endpunkts verfügbar. In der master-Instanz haben wir ein Bash-Skript, um das Massenladen Dateien mit dem Pipemodus. Um zu verdeutlichen, wurde Pipemodus ein Schlüsselelement unserer Lösung als 28 Millionen Datensätze innerhalb von fünf Minuten laden konnten wir. Beachten Sie dass, ist jedoch dieser Pipemodus noch nicht kompatibel mit einer Clusterimplementierung. In unserer anfänglichen Prototypen erstellen Phase stellten wir fest, dass das Laden von 28 Millionen Datensätze in einem Cluster Stunden dauern würde, da die Datensätze einzeln übertragen wurden. Dies war ein wichtiger Faktor bei der Entscheidung für die Struktur eine einfachen Master/Slave-Implementierung beizubehalten. Die Pipe-Modus und die Antwort für eine einzelne Instanz wie folgt aussieht:

$ cat data.txt | redis-cli –pipe
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 1000000

Nach der Pipemodus ausgeführt angegeben die Antwort an, wie viele Fehler und Antworten empfangen wurden. Wir diese Antwort in das Skript analysiert, die Datei archiviert und eine e-Mail-Benachrichtigung an die entsprechenden technischen Teams gesendet. Für jeden Fehler konnte die Techs extrahieren ausgewertet und alle Daten, die geladen werden müssen schnell zu identifizieren. Nach dem Abschluss des täglichen Verarbeitung Skripts benchmarked wir unsere Implementierung mit dem Redis-Benchmark-Dienstprogramm. Abbildung 1 zeigt die Ergebnisse unserer Lösung, reassuring wir, dass es unsere SLA-Anforderungen erfüllen.

Der Redis-Vergleichstest
Abbildung 1: des Redis-Vergleichstests

Dienstschicht

Es war äußerst wichtig, dass der Client der einzige Verbraucher unserer Lösung sein. Glücklicherweise erleichtert Azure dies mit Access Control Service, und ermöglicht uns die ein OAuth-Anbieters speziell für unsere Lösung zu erstellen. Nach der Implementierung erforderlich unserer Dienste ein spezifisches Token pro Anforderung mit einem neuen Token nach fünf Minuten erneut generiert. Nebenbei bemerkt sollten das Token immer bis zum Ablauf beibehalten werden. Anfordern eines neuen Tokens für jeden Dienstaufruf würde im Wesentlichen Engpässen bei Ihrer Lösung oder, schlimmer noch, ihn kann nicht zugegriffen werden, wenn Sie die Anforderung, die von Azure angegebenen Grenzwert überschreiten. Es wird dringend empfohlen, die alle Benutzer dieses Feature der Azure-Dokumentation vor der Implementierung in einer produktiven Umgebung nutzen.

Es sind mehrere C#-Redis-Clients verfügbar, aber wir StackExchange.Redis verwendet, da wir sind der Ansicht, dass es sich um das beliebte und ausgereifte war. Da wir unsere Daten wurde in gespeichert sind, verwendet haben wir den LRANGE-Befehl zum Abfragen von Daten. Um eine erneute Verbindung für jede Abfrage zu vermeiden, wurde die Verbindung verwendet, die für den StackExchange.Redis in ein Singleton-Muster verwaltet. Das Beispiel in Abbildung 2 veranschaulicht, wie wir Daten abrufen.

Abbildung 2 mit Redis und Abrufen von Daten

private static Lazy<ConnectionMultiplexer> lazyConnection =
  new Lazy<ConnectionMultiplexer>(() => {
  return ConnectionMultiplexer.Connect(
    ConfigurationManager.AppSettings[Constants.AppSettings.RedisConnection]);
});
public static ConnectionMultiplexer Connection
{
  get
  {
    return lazyConnection.Value;
  }
}
public async static Task<MemberResponse> MemberLookup(MemberRequest request)
{
  MemberResponse response = new MemberResponse();
  try
  {
    if (request != null && request.customer != null && request.customer.Count() > 0)
    {
      foreach (var customer in request.customer)
      {
        Customer c = customer;
        RedisKey key = GetLookupKey(c);
        IDatabase db = Connection.GetDatabase();
        c.policies = await db.ListRangeAsync(key, 0, -1, CommandFlags.None);
        response.customer.Add(c);
      }
      response.success = true;
    }
    else
    {
      response.exceptions = new List<ServiceException>();
      response.exceptions.Add(Classes.ErrorCodes.Code_101_CustomerRequired);
      response.success = false;
        }
  }
  catch (Exception ex)
  {
    response.exceptions = new List<ServiceException>();
    response.exceptions.Add(Classes.ErrorCodes.Code_100_InternalError);
    response.success = false;
    Logging.LogException(ex);
  }
  response.executedOn =
    Utils.FormatEST(DateTime.UtcNow).ToString(Constants.DateTimeFormat);
  return response;
}

Um unsere Lösung in Azure zu hosten, haben wir eine Web-app erstellt. Für eine optimale Leistung war es wichtig, dass wir die Web-app in der gleichen Region wie der Redis-Instanzen bereitgestellt. Sobald die Anwendung bereitgestellt wurde, haben wir eine VNET-Verbindung dem virtuellen Netzwerk Redis, ermöglicht des Diensts direkten Zugriff auf die Daten abrufen. Diese Verbindung wird veranschaulicht, Abbildung 3.

Abbildung 3-VNET-Integration-Verbindung

Diese Web-app wurde konfiguriert Skalieren auf 10 Instanzen basierend auf CPU-Auslastung. Da der Datenverkehr für unsere Lösung geändert, würden die Web-app nach Bedarf skalieren. Ein SSL-Zertifikat wurde als eine zusätzliche Sicherheitsebene dar auf die app, zusammen mit der IP-Filterung, die speziell für den Client angewendet. Obwohl die app für die automatische Skalierung konfiguriert wurde, hatte er Automatisches Failover nicht. Um die Verfügbarkeit der Lösung an den Client zu maximieren, stellen wir einen Klon der primären Web-app erstellt, aber in einer anderen Region gespeichert. Beide apps hinzugefügt wurden, einem Azure Traffic Manager, was wir für das automatische Failover genutzt.

Schließlich eine benutzerdefinierte Domäne erworben und erstellt einen CNAME-Eintrag auf die Traffic Manager-URL, die unsere Implementierung abgeschlossen. Um die täglichen Leistung unserer Lösung zu überwachen, haben wir eine Instanz von New Relic direkt aus dem Azure Marketplace. Durch die Nutzung von New Relic könnten wir schnell Bereiche identifizieren, die zur Verbesserung der sowie die Verfügbarkeit des Servers erforderlich.

Nachbereitung

Durch diese Lösung in Azure bereitstellen, erfahren, wie andere Technologie Stapel stellen schnell zu einer leistungsfähigen und erfolgreiche Lösung zusammenarbeiten. Obwohl eine Lösung in Azure bereitstellen Serverwartung, beseitigt, wenn Sie die Muster an Stelle folgen, müssen Sie Erfolg. Abhängig von die durchschnittliche Dauer von Lösungen können Sie auf Hardware-Kosten sparen, durch alle Projektmappen in die Cloud verschieben.

Am Ende der Implementierung wurde die durchschnittliche Antwortzeit 25 Millisekunden für 50 gleichzeitige Benutzer. Auf Basis dieser Ergebnisse, ist die Antwortzeit erweiterte ungefähr 10 Millisekunden pro 15 hinzugefügten gleichzeitigen Benutzern.

Sean Iannuzziist Leiter der Technologie für Harte-Hanks und wurde in der IT-Branche seit mehr als 20 Jahren spielen eine entscheidende Rolle in die Lücke zwischen Technologie und Visionen für eine Vielzahl von sozialen Netzwerken, Big Data-Datenbank-Lösungen, cloud computing, e-Commerce- und finanzanwendungen von heute. Iannuzzi hat noch keine Erfahrung mit mehr als 50 eindeutige Technologieplattformen, mehr als ein Dutzend Awards/Zertifizierungen erreicht und spezialisiert driving technologierichtung und Lösungen für die geschäftlichen Ziele zu erreichen.

Johnny Webbist als Softwarearchitekt für Harte-Hanks und qualitativ hochwertige Lösungen mit modernster Technologie für bekannte Clients für den letzten 10 Jahren wurde implementiert. Sein Fachgebiet enthält die vollständige Lebenszyklus der Softwareentwicklung als auch Microsoft .NET Framework-Softwarearchitektur, Cloud-computing, Webentwicklung, Entwicklung für mobile Geräte, API-Entwicklung, SQL-Datenbanken und NoSQL-Datenbanken.

Dank den folgenden technischen Experten für die Überprüfung dieses Artikels: Eric Rätsel (Liquidhub)
Eric Riddle ist technische Manager für flüssige Hub in Philadelphia. Er wurde entwickeln und Entwerfen von Lösungen mit .NET Framework seit dessen Einführung. Sein Fachgebiet umfasst Front-End-Web-Entwicklung, REST-API, WCF, Windows-Dienste und SQL Server. Er verfügt über umfassende Erfahrung in der Finanzdienstleistungen und direct marketing-Branche.