Freigeben über

August 2017

Band 32, Nummer 8

Dieser Artikel wurde maschinell übersetzt.

Azure: Batchverarbeitung mithilfe einer serverlosen Architektur

Durch Joseph Fultz | August 2017

Für Azure Enterprise-Kunden ist eine zentrale Herausforderung beim Verwalten ihrer Cloud Speicherbedarf zu steuern, was sie ausgeben und diese Kosten zurück an den Consumer Gebühren in Rechnung. Glücklicherweise sind mehrere Lieferanten, die Tools, z. B. Cloud Cruiser Cloudyn und Cloudability, unterstützen Sie beim Sammeln von Nutzungsdaten und generieren einen umfangreichen Satz von Berichten bereitstellen. Darüber hinaus finden Sie viele gute Beispiele für Daten programmgesteuert, z. B. im Beitrag eine frühere Kollege ändere, Ed Mondek, ziehen Sie in dem er zeigt, wie Daten in Excel abrufen und Sie ansehen (bit.ly/2rzDOPI). Wenn Sie ziehen Sie die Daten regelmäßig und Trend der Verlaufsdaten, vorhanden und prognostizierte Ansichten aktivieren möchten, müssen Sie jedoch deutlich mehr Daten speichern. Für ein großes Unternehmen mit Tausenden von Ressourcen pro Abonnement kann diese Datenmenge schwierige und ist sicherlich nicht was Sie möchten abzurufen und auf einem lokalen Computer zu halten.

Glücklicherweise gibt es besteht eine weitere Möglichkeit zur Verfügung. In diesem Artikel werde ich Sie serverlose extrahieren-transformieren-laden (ETL)-Prozess durchlaufen ich richten Sie solche Daten extrahieren, geben Sie ein wenig Anreicherung und speichern Sie die Daten an einem Speicherort gespeichert, wo Sie weitere Arbeit (Analytics, MapReduce-usw.) ausgeführt werden können. Ich werde Gesamtentwurf, Key Entscheidungspunkte und wichtige Aspekte zu berücksichtigen, die in eine serverlose Ansatz berühren.

Bestimmen Verbrauch

Die erste Entscheidung ist zwischen dem Enterprise Agreement (EA) Abrechnung-API und die Azure Abrechnung-API, die Anforderungen für bestimmte Abonnements zentriert auswählen. Meine Prototyp richtet sich an Enterprise-Kunden mit mehreren Bereitstellungen in einem EA. Im Szenario mit dem ich arbeite sind Abonnements im Rahmen der Verwaltungsgrenzen für beide Gruppen von bestimmten Produkt und zur Trennung von Produktion aus nicht produktive Ressourcen verwendet wird. Dies kann eine relativ große Anzahl von Abonnements endgültig festgelegt, aufgrund der flüchtigen Proof of Concept (PoC)-Typ der Arbeit, die erstellt wird, als neue Gruppen und neue Produkte, die Zeilen in Azure zu, um starten führen. Daher möchte ich mit der EA-API zu arbeiten, da es der Umfang der Aufgaben reduziert, dass ich besitzen, erstellen Sie einen Suchmechanismus für Abonnements. Dies bewirkt, dass mir die notierten Herausforderung, dass keine Daten für Abonnements, die außerhalb der Registrierung für das Unternehmen erstellt. Obgleich dies ein wichtiger Bereich konfigurieren ist, enthält eine Reihe anderer Prozess und Management Herausforderungen, die OUI gelöst werden müssen und liegt außerhalb des Bereichs der Aufgaben, die ausgeführt werden soll.

Anforderungen und Logikfluss

In jeder Architektur ist es der Schnittmengen zwischen Systemen, die meisten Unternehmenspraktiken im Entwurf erfordern und testen. Eine serverlose Architektur wird die Notwendigkeit die Datenmenge zu berücksichtigen, die über die Supersystem verschoben werden, und muss die bestimmten Einschränkungen der diskreten Subsysteme berücksichtigt nicht geändert. Die Prinzipale Änderung bei der Entwicklung einer solchen Supersystem ist mehr in die Tiefe oder den Bereich beim Definieren des Systems, z. B. das Ändern der Größe einer Warteschlange für den Durchsatz, aber nicht ändern der Größe der Hardware, der als Host es. Sie müssen weiterhin berücksichtigen, Latenz, Konnektivität Volume, Verfügbarkeit, Kosten und eine beliebige Anzahl von anderen Faktoren, aber die Arbeit der Größe und definieren die Angaben der Dienst beendet, nachdem Sie die Kapazität und die Kosten für die Funktion erforderlich, um die identifizierten erfüllen definiert haben. Es gibt keine zusätzlichen hostumgebung und die erforderlichen Elemente zu definieren, wie Sie in der Vergangenheit haben können.

Bevor erhalte Aussehen den Gesamtablauf bei der Informationen in das System entwerfen, wir Beachten Sie einige Fakten über die Quellsysteme und einige Anforderungen für das End-Status-System:

  • Alle Daten für jedes Abonnement, unter dem EA wird für alle Ressourcen für jeden Tag zurückgegeben werden in den angegebenen Monat verfügbar ist. Dies kann zu einer großen Datenmenge mit einem linearen Wachstum im Verlauf des Monats führen.
  • Alle Datensätze können im Verlauf des Monats aktualisiert werden. Die genannten Abrechnung zeitliche Planung ist 72 Stunden. Als Ausgangspunkt für Sicherheit müssen alle Datensätze endgültig festgelegt für einen bestimmten Monat bis zu 72 Stunden nach Beginn des nachfolgenden Monats berücksichtigt werden.
  • Die Verwendung von Daten ist nicht mit der ID für die Registrierung zurückgegeben, sodass ich, um sie hinzuzufügen müssen.
  • Bestimmen die Kosten ist eine separate Aktivität und erfordert Abrufen der Ratenkarte und die weitere Verarbeitung.
  • Keine Informationen werden für Abonnements, die nicht im angegebenen EA empfangen.

Darüber hinaus sind einige technische geschäftsanforderungen, die der Prototyp einschließen muss:

  • Die Fähigkeit zum Erstellen von nur-Lese und geografisch verteilten Datasets muss enthalten sein.
  • Verarbeitungsleistung muss anpassbar, Kosten und Leistung.
  • Die Fähigkeit zum Schützen des Zugriffs auf Abonnementebene entworfen sein sollte.

Der Gesamtablauf selbst ist recht einfach, da ich einfach werde die Daten abzurufen, eine kleine Menge von Informationen hinzufügen und in der Zielspeicher gespeichert.

Wie in dargestellt Abbildung 1, der Pfad zum Abrufen der Daten an das Ziel ist recht einfach, da keine mit allen externen Systemen als die Abrechnung EA-API Integration. Ich wissen, wenn ich über die Daten arbeiten, ich bestimmte Werte in der ersten Verarbeitung und die datenbereicherung möchten können (z. B. beim Hinzufügen der Registrierungs-ID), und auf der Persistenz-Seite, die ich vorhandene Einträge aus des Vortags Abrufvorgänge zu verarbeiten müssen. Ich möchte müssen wahrscheinlich sehen Sie sich diese beiden Vorgänge trennen.

Logikfluss
Abbildung 1 Logikfluss

Daher sehen Sie die drei wichtigsten Blöcke, die darstellen, abrufen, Anreicherung und Persistenz, die alle durch einige Warteschlangenmechanismus getrennt werden. Die Komplikationen starten, nachdem ich interessant Technologie machen, und starten Sie die Blick auf die Details mit diesen Komponenten implementieren, und machen die Pipeline zur anforderungsverarbeitung parallel ausgeführt werden.

Technologie-Zuordnung

An diesem Punkt im Prozess, zwei Faktoren zuzüglich der Anforderungen, die gesamtleistung des Systems kommen eine sprachbasierte: Unternehmensstandards und persönlichen Vorlieben. Wenn diese in Konflikt stehen, können nahezu unendlich viele Debatten ergeben. Glücklicherweise muss nicht in dieser Instanz ich dies kümmern. Ich müssen eigene Mischung von Einschränkungen, zusammen mit den von den ursprünglichen Anforderungen notierten. In diesem Fall möchte ich sicherstellen, dass dieser Markierungen erreicht:

  • Am einfachsten Compute-bereitstellungs- und Bearbeitungen/Updates für kurze Zyklen von Tests
  • Einfache automatische Skalierung
  • Einfache Bereitstellung zur geografischen Verteilung von Daten
  • Einfache Mechanismen für die Planung und Auslösen von Arbeit

Ich möchte hier, um den Fokus auf die Arbeit und nicht auf das System-Setup. Ich werde Dinge lassen wie Kostenanalyse für verschiedene Implementierungen und zur Einhaltung der Standards des Unternehmens erst, nachdem ich funktionsfähige Prototyp haben. Ich hatte berücksichtigt, die einige Alternativen, wie der Azure SQL-Datenbank im Vergleich zu Azure-Cosmos-Datenbank, aber ich werde den Fokus auf Meine Optionen und die primären Motivation für jede dieser Optionen.

  • Computing: Azure-Funktionen werden mir auch hier dienen. Er erfüllt Meine Notwendigkeit Skalierbarkeit und Einfachheit gleichzeitig einfache Konfiguration geplante und ausgelöste Aufträge und einfache Integration mit Bindungen bereitgestellt.
  • Queuing: Halten Dinge einfach, ich verwenden Azure-Speicher-Blobs und trennen Sie die Dateien von Containern an. Die Größe unbekannte, aber erwartungsgemäß große jedes anfängliche Eingabedatei macht speicherwarteschlangen eine nicht-Option für den Abruf der ersten und bringt sie wahrscheinlich außerhalb der Ausführung für die Verarbeitung der einzelnen Abonnements Daten unterteilt. Darüber hinaus möchte ich die Mechanismus uniform beibehalten und eigentlich keine erweiterten Funktionen, z. B. Nachrichten mit Priorität, routing, Sicherheit Message-spezifische und Servercache Meldungsbehandlung benötigen.
  • Storage: Azure Cosmos-DB ist tatsächlich Meine "Friend". Verwenden die Abonnement-ID als Partitionsschlüssel ermöglicht, dass ich den Zugriff nach Abonnement bei Bedarf zu beschränken. Darüber hinaus die Einfachheit des hinzufügen und Entfernen von Lese- und Lese-/ Schreibzugriff geografisch verteilten Replikate ' und ' Native Unterstützung in Power BI Objektsyntax für mein System dadurch. Zuletzt, müssen ein wenig persönliche Bias zu sämtlichen: Ich möchte einen ordnungsgemäße Dokument Speichermechanismus, der die SQL-Syntax unterstützt, die ich für das Abbrechen für zu viele Jahre verwendet haben.

Abbildung 2 stellt die Anwendung der Technologie, die logische Architektur sowie einige Verarbeitungsfluss hinzugefügt.

Technologie-Zuordnung und zum Datenfluss
Abbildung 2-Technologie-Zuordnung und zum Datenfluss

Ich habe die Liberty einschließlich der Namen, die ich verwendet in diesem Diagramm übernommen, aber haben Sie möglicherweise keine Namen in diesem Stadium des Entwurfs. Die Formen verwendet anzugeben, die Technologie in Play; die Zahlen in der Zeile sind die Sequenz, in der der Prozess ausgeführt wird, und die Pfeile geben an, welche Komponente des ausgehenden Aufrufs initiiert. Beachten Sie, dass ich identifiziert haben, vier Azure-Funktionen, vier Azure-Speicher-Blob-Container und drei Azure-Cosmos-DB-Auflistungen, die ich meine Implementierung der arbeiten einzelboxen als einsetzen müssen.

Das Aufteilen von Daten in drei Auflistungen eignet sich für erläutert wird, aber dient dem Zweck, grander. Ich wird nicht die gleiche Sicherheit für alle Typen von Dokumenten, und die Trennung kann, die leicht zu verstehen und zu verwalten. Noch wichtiger ist ich die Leistungsmerkmale von Auflistung definieren, und die Trennung ermöglicht, dass ich einfacher optimieren, die durch eine große Auflistung mit hohem Durchsatz speziell für die DetailedUsageData müssen, während die anderen beiden minimale bleiben.

Abrufen von Daten

Beginnend mit der ersten beiden Säulen der Daten Weg, möchte ich etwas Ähnliches wie Was ist mit einem Cron-Job alles ausführen. Während das WebJobs SDK selbst diese Art der Implementierung unterstützen würden, gäbe es viel Arbeit von der Runtime eAzure Funktionen basiert auf dem WebJobs SDK und natürliche Weise unterstützt Timer als Auslöser konfigurieren, es ist eine einfache Option. Ich könnte haben verwendet Azure Data Factory, da es ist ein Tool, das speziell für das Verschieben von Daten vorgenommen und unterstützt das Abrufen von Web-Daten und Arbeiten mit Blobs. Allerdings bedeutet dies, dass ich würde sich bestimmte Aspekte in Bezug auf Verweisdaten und doppelte Datensätze in der Azure-Cosmos-Datenbank aktualisieren, wenn ich die Zeilen-ID haben müssen Kenntnisse über die Entwicklung und Debuggen mit Azure-Funktionen und die Informationen, die ich mit der Integration von Azure-Funktionen mit Application Insights, abrufen können, stellt Azure-Funktionen meine bevorzugte Option in dieser Instanz.

Der Timer als Auslöser verfügt eine offensichtliche-Funktion, aber in der Reihenfolge für DailyEABatchControl wissen, was zu verarbeiten, Konfigurationsinformationen aus der Auflistung Registrierung, besitzt das folgende Schema abgerufen:

{
  "enrollmentNumber": "<enrollment number>",
  "description": "",
  "accessKey": "<access key>",
  "detailedEnabled": "true",
  "summaryEnabled": "false",
}

Jetzt ist das durch die Registrierungsnummer, Zugriffsschlüssel und ein Flag zur Verarbeitung ("DetailedEnabled") aktivieren ausreichend für mich funktionieren. Jedoch können sollte ich beginnen, Hinzufügen von Funktionen und Testlaufkonfiguration zusätzliche Informationen erforderlich, Azure Cosmos-DB mir einfach Elemente dem Dokumentschema hinzufügen, ohne eine Reihe von reagieren und Datenmigration führen. Sobald die DailyEABatchControl ausgelöst wird, wird durchlaufen, bis alle Dokumente und Aufrufen RetrieveUsage für jede Anmeldung, die "DetailedEnabled" wurde auf True festgelegt, durch die Trennung der Logik zum Starten eines Auftrags von der Logik zum Abrufen der Quelldaten. Ich die JobLog-Auflistung verwenden, um zu bestimmen, ob bereits ein Auftrag für den Tag ausgeführt wurde, entsprechend abbildung3.

Abbildung 3 Auftrag Steuerelementlogik

// Get list of enrollments for daily processing
List<Enrollment> enrollments = 
  inputDocument.CreateDocumentQuery<Enrollment>(
  UriFactory.CreateDocumentCollectionUri(dbName, enrollmentCollection), 
  new SqlQuerySpec("SELECT * FROM c WHERE c.detailedEnabled = 'true'"),
  queryOptions).ToList<Enrollment>();

// Get yesterday's date to make sure there are logs for today
int comparisonEpoch = 
  (int)(DateTime.UtcNow.AddDays(-1) - new DateTime(1970, 1, 1)).TotalSeconds;

string logQuery = 
  "SELECT * FROM c WHERE c.epoch > '" + comparisonEpoch.ToString() + "'";

List<JobLog> logs = inputDocument.CreateDocumentQuery<JobLog>(
  UriFactory.CreateDocumentCollectionUri(dbName, jobLogCollection), 
  new SqlQuerySpec(logQuery), queryOptions).ToList<JobLog>();

// Get list of enrollments for which there is no match
var jobList = enrollments.Where(x =>
  !logs.Any (l => l.enrollmentNumber == x.enrollmentNumber));

Der letzte Ausdruck ergibt eine gefilterte Liste von Anmeldungen, die für die Daten für den betreffenden Tag abgerufen wurde noch nicht. Ich werde rufen Sie als Nächstes die RetrieveUsage (in Schritt 3 Abbildung 2) aus innerhalb DailyEABatchControl durch Aufrufen von es mit "HttpClient" mit ausreichend Daten im Post-Text für die sie die Registrierung zu wissen, für die er ist Abrufen von Daten und den Monat für die abrufen ist, wie gezeigt in Abbildung 4.

Abbildung 4 Abrufen von Verwendungsdaten

foreach(var doc in jobList)
{
  HttpClient httpClient = new HttpClient();

  string retrieveUsageUri = @"https://" + 
    System.Environment.GetEnvironmentVariable("retrieveUsageUri");

  string postBody = "{\"enrollment\":\"" + doc.enrollmentNumber + "\"," +
    "\"month\":\"" + DateTime.Now.ToString("yyyy-MM") + "\"}";

  httpClient.DefaultRequestHeaders.Accept.Add(
    new MediaTypeWithQualityHeaderValue("application/json"));

  var content = new StringContent(postBody, Encoding.UTF8, "application/json");
  var response = await httpClient.PostAsync(theUri, content);    

  response.EnsureSuccessStatusCode();
 
  string fetchResult = await response.Content.ReadAsStringAsync();
}

Es ist erwähnenswert, dass dies beabsichtigt ist nicht auf einem System geöffnet werden. Ich erstelle eine geschlossene Verarbeitungsschleife, damit ich keine Aufrufer die RetrieveUsage-Funktion ausführen möchten. Folglich ich habe gesichert ist durch das Anfordern eines Codes, die in nicht angezeigt wird Abbildung 4, aber Teil des URI aus GetEnvironmentVariable("retrieveUsageUri") zurückgegeben. In einem Unternehmen wäre Dienstprinzipal, Implementierung und Azure Active Directory-Integration eine realistischere Auswahl um ein höheres Maß an Sicherheit zu erzielen.

Der letzte Schritt der der erste Abschnitt der meine Daten Weg ist innerhalb der Funktion RetrieveUsage, in dem sie auf den Container Newdailyusage mit Azure-Blob-Speicher dauerhaft gespeichert. Allerdings müssen, um diese Daten zu erhalten den Aufruf zu erstellen, und fügen Sie die AccessKey als ein trägertoken, das in der Kopfzeile:

HttpClient httpClient = new HttpClient();

string retrieveUsageUri = usageQB.FullEAReportUrl();

httpClient.DefaultRequestHeaders.Add("authorization", bearerTokenHeader);
httpClient.DefaultRequestHeaders.Add("api-version", "1.0");

var response = await httpClient.GetAsync(retrieveUsageUri);    

response.EnsureSuccessStatusCode();

string responseText = await response.Content.ReadAsStringAsync();

Aus Gründen der Übersichtlichkeit sind ich haben einige Manipulationen Datum außerhalb des in diesem Codeblock Ausschneiden und eine Hilfsklasse zum Generieren der BearerTokenHeader oder die UsageReportQueryBuilder noch nicht enthalten. Jedoch ist dies sollte ausreichend, um zu veranschaulichen, wie sie verwendet und sortiert sind. Die AccessKey wird an die statische Methode FromJwt, übergeben, die den Typ BearerToken zurückliefert, von dem ich einfach ziehen Sie den Header, und fügen es auf die Anforderung, die von der URL erstellt, die durch den Aufruf von usageQB.FullEAReportUrl erstellt wird. Zuletzt, aktualisieren Sie die ausgabebindung auf den Pfad und Dateinamen für das Blob-Ziel gewünschte:

path = "newdailyusage/" + workingDate.ToString("yyyyMMdd") 
  + "-" +  data.enrollment + "-usage.json";
var attributes = new Attribute[]
{
  new BlobAttribute(path),
  new StorageAccountAttribute("eabillingstorage_STORAGE")
};

using (var writer = await binder.BindAsync<TextWriter>(attributes))
{
  writer.Write(responseText);
}

Dies führt zu einer Struktur in Azure-Speicher, die wie folgt aussieht:

newdailyusage/
        20170508-1234-usage.json
        20170508-456-usage.json
        20170507-123-usage.json

Dadurch, dass mehrere Bereitstellungen und mehrere Dateien für jede Anmeldung Datenspeicher für den Fall, dass Sie aus irgendeinem Grund Verarbeitung stattfindet. Darüber hinaus, da Daten für die vergangenen Tage im Verlauf des Monats ändern können, ist es wichtig, die Dateien, die zur Recherche und Abstimmung verfügbar haben, für den Fall, dass Anomalien in den Berichtsdaten angezeigt.

Aufteilen von Daten für die parallele Verarbeitung

So vielen Daten eingehen und der Arbeit aktualisieren von Datensätzen aus irgendeinem Grund für einen bestimmten Monat pro Tag verarbeiten ist es wichtig, diese Daten in einer parallelen Weise verarbeiten. In der Regel ist mindestens heutzutage dies Wenn ich Sie die parallelen-Bibliotheken für c# gliedern, schreiben ein paar Codezeilen und man selbst auf die Schulter für Genie zur parallelen Verarbeitung wird. Allerdings in diese Instanz möchte wirklich ich, verlassen Sie sich nur auf die Funktionen der Plattform, die für mich und zulassen, um auf jeder separaten Aufgabe zu konzentrieren.

Die nächste Azure-Funktion in der Sequenz wurde mit einem Blob-Trigger konfiguriert, sodass er Dateien abruft, die in der eingangsverarbeitung Speichercontainer aufgenommen. Der Auftrag an diesem Punkt wird die eingehende Datei in eine Datei pro Tag pro Registrierung aufgeteilt. Alles in allem Dies ist ein sehr einfacher Schritt, es benötigt jedoch deserialisiert die JSON-Datei in den Arbeitsspeicher. Es ist wichtig, beachten, da die Methode, die ich ausgewählt haben, dass für den Prototyp verwenden einfach die Deserialize-Methode aufruft:

JsonConvert.DeserializeObject<List<EAUsageDetail>>(myBlob);

Mir ist diese Option, um für meine Zwecke ausreichend sein, aber die vorhandene RAM-Zuordnung für den Host der Azure-Funktion ist 1,5 GB. Es ist möglich, dass für eine große Registrierung mit erhebliche Ressourcen bereitgestellt, eine Datei groß irgendwann im Monat in den Arbeitsspeicher, geladen, in dem Fall eine alternative Methode werden würde für das Analysieren und teilen die Datei verwendet werden muss. Wenn Sie ein Azure-Funktion, die mehr als fünf Minuten benötigt erstellen, müssen sie darüber hinaus geändert werden, da der aktuelle Standard fünf Minuten ist, obwohl dies auf maximal 10 Minuten über die Hostkonfiguration JSON angepasst werden kann. Wie ich schon frühzeitig erwähnt, wird das Datenvolumen zu wissen, an jedem Punkt sowie für die Integration in das Gesamtsystem ist. Nachdem die Daten deserialisiert wurde, ich Sende ziehen Sie den maximalen Tag Wechsel und richten eine Schleife in Tag Max entsprechend starten auswählen, die Daten für diese Tage vom ersten Tag Abbildung 5.

Abbildung 5 pro Tag auswählen

// Loop through collection filtering by day
for(int dayToProcess = 1; dayToProcess <= maxDayOfMonth; dayToProcess++)    
{
  // Get documents for current processing day
  var docsForCurrentDay = results.Where (d => d.Day==dayToProcess);

  // Serialize to string
  string jsonForCurrentDay = 
    JsonConvert.SerializeObject(docsForCurrentDay);
  log.Info($"***** Docs for day {dayToProcess} *****");

  // Get date for one of the records for today
  string processDateString = (from docs in results where docs.Day == 
    dayToProcess select docs.Date).First();

  path = "newdailysplit/" + DateTime.Parse(processDateString).ToString("yyyyMMdd") 
    + "-" +  enrollment + "-dailysplit.json";

  // Write out each day's data to file in container "\newdailysplit"
  var attributes = new Attribute[]
  {
    new BlobAttribute(path),
    new StorageAccountAttribute("eabillingstorage_STORAGE")
  };

  using (var writer = await binder.BindAsync<TextWriter>(attributes))
  {
    writer.Write(jsonForCurrentDay);
  }
}

Sobald alle Tage in separate Dateien aufgeteilt und geschrieben wurden (siehe Schritt 7 in Abbildung 2), ich die Datei einfach auf den Container Processedusage verschieben. Um das Diagramm zu halten, Abbildung 2 leicht analysieren, ich habe weggelassen einige Container – insbesondere der Fehler Dateien Container aus dem Diagramm fehlt. Dies ist der Container der, der jede Datei, die bewirkt, eine Ausnahme während der Verarbeitung enthält dass, ob die Datei über die gesamte Nutzung-Datei oder nur eines der täglichen Teilungen verfügt. Ich verbringen nicht Zeit oder den Aufwand, korrigieren die Daten fehlen oder sind fehlerhaft Tage lang, da, sobald ein Problem festgestellt wird, der Prozess für einen bestimmten Monat und die Registrierung oder für eine einzelnes tägliche Teilung zum Beheben des Problems ausgelöst werden kann. Außerdem Warnungen sind klar fehlt in den Prototyp und Mechanismen für die kompensierenden, wenn Fehler auftreten, aber das ist etwas ich möchte Bubbling über Application Insights-Integration in der Operations Management Suite.

Beibehaltung der Daten auf Azure-Cosmos-DB

Mit den Teilen von Dateien und kann jetzt von der Funktion ProcessDailyUsage übernommen werden, ist es Zeit einige Probleme berücksichtigen, die behoben werden müssen, müssen nämlich Durchsatz für das Ziel und wie Updates behandelt. Häufig, wenn Sie über einige Lösungsarchitektur in einem Unternehmen arbeiten, führen Sie in älteren Systemen, die weniger fähig sind, oder, bei denen in Echtzeit Lade- und Szenarien mit hohem Durchsatz verwaltet werden müssen. Ich in meinem Cloud native Einrichtung für diese Architektur natürlich schwer Durchsatz Einschränkungen muss allerdings konnte ich Probleme selbst erstellen, wenn ich nicht die Zeit in Anspruch nehmen vorstellen, die über das Volume und die Geschwindigkeit der Daten, die ich in die Cloud-Dienste gespeist bin, ich bin nutzen.

Für meine Daten aller täglichen Teilungen ungefähr 2,4 MB und ca. 1.200 einzelne Dokumente enthält. Bedenken Sie, die jedes Dokument, eine messgerätablesung, die für eine Ressource in Azure bereitgestellt darstellt. Daher konnte für jede EA die Anzahl der Dokumente in einer täglichen Teilung erheblich Ressourcenverwendung im Unternehmen hängt. Die ProcessDailyUsage-Funktion ist so konfiguriert, dass auf der Grundlage empfangenden neue Blobs im Container Newdailysplit ausgelöst wird. Dies bedeutet, dass ich so viele wie 31 Funktion Ausführungen gleichzeitige Bearbeiten der Daten haben. Um Hilfe schätzen, was für die Bereitstellung für Azure-Cosmos-Datenbank erforderlich, verwendet den Rechner am documentdb.com/capacityplanner. Ohne einige Betriebszustand musste ich einige vermutungen für die anfängliche Bereitstellung zu erstellen. Mir ist 31 gleichzeitige Ausführungen werden, aber es ist ein bisschen schwieriger zu fixieren nach unten wie viele gleichzeitige Anforderungen pro Sekunde, die erstellt wird, ohne sich wiederholende ausgeführt wird. Das Endergebnis dieses Prototyps hilft, um die endgültige Architektur und Anforderungen für die Bereitstellung zu informieren, aber da ich diese Zeitachse vorwärts arbeite, werde ich es mit den folgenden als Regeln für die Schätzung der Versuch unternommen fertigen:

  • 1.200 Datensätze
  • 31 gleichzeitigen Ausführungen (für eine einzelnes EA)
  • 0.124 Sekunden pro Anforderung (empirische Beweise aus messen einige einzelne Anforderungen)

Ich werde auf 0,1 Sekunden für mehr konservative Schätzung, also Indexschlüsselwerten die Last gerundet. Dadurch werden 310 Anforderungen pro Sekunde pro EA, die wiederum ca. 7.800 anforderungseinheiten (RUs) auf Basis der Rechner Ergebnisse, wie in angezeigt werden kann, kommt Abbildung 6.

Azure-Cosmos-DB-Preisrechner
Abbildung 6 Azure Cosmos-DB-Preisrechner

Da die maximale RUs, die bereitgestellt werden können, ohne Unterstützung aufzurufen ist 10.000, scheinen dieser Art von hoch. Allerdings verwende ich eine Maximums parallele Prozesse und -Laufwerke von den Durchsatz erheblich, dem werden wiederum die Kosten leiten. Dies ist ein wichtiger Aspekt beim Entwerfen der Struktur, da es gut für mich führen Sie dies ist für einige Tests durchführen, aber für die reale Lösung, die ich benötigen einen Einschränkungsmechanismus, der die Verarbeitung verlangsamt, damit ich weniger RUs bereitstellen und mich etwas Geld sparen. Ich nicht benötigen, die Daten so schnell wie möglich aufgezeichnet werden, nur innerhalb einer angemessenen genug Zeit, die jemand überprüfen und ihn auf täglicher Basis nutzen kann. Die gute Nachricht ist, dass die Funktionen der Azure-Team eine Steuerelement-Parallelitätsmechanismen in den Rückstand der Probleme, die letztendlich behoben werden (bit.ly/2tcpAbI), und bieten eine gute Möglichkeit eines Steuerelements einmal implementiert. Einige andere Optionen: einführen künstliche beliebige Verzögerungen (wir alle geeinigt, dass diese beschädigt ist) oder überarbeiten Sie die Verarbeitung und die parallele Ausführung explizit in der C#-Code zu behandeln. Darüber hinaus wie technische Hilfe eines Experten effizient Fabio Cavalcante in einer Konversation, wäre gute Möglichkeit die Architektur ein wenig ändern, durch Hinzufügen von Azure-Speicher-Warteschlangen und zur Verwendung von Features wie z. B. Sichtbarkeit Timeouts und zeitgesteuerte Zustellung als einem Einschränkungsmechanismus fungieren. Hinzufügen, die wenige verschiebbaren Teile mit dem System, und ich würde Ausarbeiten der Interaktion über eine Warteschlange für die Aktivierung, während die Daten im Speicher bleiben müssen, oder unterteilen Sie die Daten in 64-KB-Blöcke, für die Warteschlange. Nachdem Einschränkung im Azure-Funktionen verfügbar ist, werde ich möglicherweise, sie oben im Formular einfacher zu halten, mit denen ich arbeite. Die wichtigsten ist hierbei, dass bei der Arbeit mit einer serverlose Architektur Sie mit den Einschränkungen der Plattformen vertraut sein müssen auf dem Sie, sowie die Kosten für jedes Entscheidungs erstellen möchten.

Bei der Bereitstellung von mehr als 2.500 RUs erfordert das System an, dass kein Partitionsschlüssel angegeben werden. Dies funktioniert für mich, da ich möchte, um diese Daten in jedem Fall zu partitionieren, um Skalierbarkeit und Sicherheit in der Zukunft zu.

Wie Sie in sehen Abbildung 7ich angegeben haben 8.000 RUs ist etwas mehr als die angegebene Berechnung und ich "subscriptionId" als Partitionsschlüssel angegeben haben.

Eine neue Sammlung wird bereitgestellt
Abbildung 7 eine neue Sammlung wird bereitgestellt

Darüber hinaus einrichten ich die ProcessDailyUsage mit einem Blob-Trigger für den Container Newdailysplit und mit einer Eingabe und Ausgabe für Azure-Cosmos-Datenbank. Die Eingabe Bindung wird verwendet, um Datensätze zu suchen, die für den angegebenen Tag und die Registrierung vorhanden und Duplikate zu behandeln. Ich werde stellen Sie sicher, dass mein FeedOptions das Flag partitionsübergreifenden Abfrage festlegt entsprechend Abbildung 8.

Abbildung 8 mit FeedOptions das Flag Partitionsübergreifenden Abfrage festlegen

string docsToDeleteQuery = String.Format(@"SELECT * FROM c where c.Enrollment = 
  ""{0}"" AND c.Date = ""{1}""", enrollment, incomingDataDate); 

FeedOptions queryOptions = new FeedOptions { MaxItemCount = -1, 
  EnableCrossPartitionQuery = true };

IQueryable<Document> deleteQuery = docDBClient.CreateDocumentQuery<Document>(
  UriFactory.CreateDocumentCollectionUri(dbName, collectionName), 
  new SqlQuerySpec(docsToDeleteQuery), queryOptions);

log.Info("Delete documents");
int deletedDocumentCount = 0;
foreach (Document doc in deleteQuery)
{ 
  await docDBClient.DeleteDocumentAsync(((dynamic)doc)._self,  
    new RequestOptions { PartitionKey = 
    new PartitionKey(((dynamic)doc).SubscriptionId) });
  deletedDocumentCount++;
}

Ich erstellen eine Abfrage ziehen Sie alle Einträge für die Registrierung auf, die das Datum, und klicken Sie dann die Schleife durchlaufen und löschen Sie sie. Dies ist eine Instanz, auf dem SQL Azure Dinge einfacher durch Ausstellen einer DELETE-Abfrage oder mit einem Upsert mit einem bekannten Primärschlüssel vorgenommen haben kann. Zum benötigen jedoch in Azure-Cosmos-Datenbanken, führen Sie die Upsert ich der Zeilen-ID, d. h. ich muss die Roundtripzeit zu gewährleisten und den Vergleich auf Felder, die ich noch wissen, um das Dokument eindeutig zu identifizieren und verwenden Sie diese Zeile Id oder Selflink. In diesem Beispiel ich einfach alle Datensätze löschen, und fügen Sie dann auf die neue – und potenziell aktualisierte – in Dokumenten zurück. Zu diesem Zweck muss der Partitionsschlüssel der DeleteDocumentAsync-Methode übergeben werden. Eine Optimierung wäre, ziehen die Dokumente zurück, und führen Sie einen lokalen Vergleich, aktualisieren alle geänderten Dokumente, und fügen net neue Dokumente. Ist ein wenig unnötig beanspruchen, da alle Elemente in jedem Dokument verglichen werden muss. Da es kein Primärschlüssel definiert, die für die Abrechnung Dokumente ist, können Sie wahrscheinlich übereinstimmende Dokument mithilfe von "subscriptionId" "," MeterId "," InstanceId "und" Datum suchen und vergleichen die übrigen Elemente dort. Dies würde Auslagern Teil der Arbeit von Azure-Cosmos-Datenbank und der gesamten Datenverkehr wird reduziert.

Mit der Funktionsweise deaktiviert, um die Dokumente in der Auflistung hinzufügen Schleife ich einfach durch die Dokumente und Aufruf AddAsync auf die DocumentCollector wie die ausgabebindung für die Azure-Funktion definiert:

// Update the enrollment field in the incomming collection
incomingDailyUsage.ForEach (usage => usage.Enrollment = enrollment); 

int processedRecordCount=0;
foreach (EnrollmentUsageDetail usageDoc in incomingDailyUsage)
{

  await documentCollector.AddAsync(usageDoc);
  processedRecordCount++;
}

Obwohl nicht viel geändert wird, haben ich auch ein wenig Anreicherung durchgeführt, indem Sie die Registrierungsnummer an jedes Dokument in der Auflistung. Mit einem täglich Split Datei erzeugt die Protokollinformationen in angezeigten Abbildung 9.

Abbildung 9 die Protokollinformationen aus täglicher Teilen Datei

2017-06-10T01:16:55.291 Function started (Id=bfb220aa-97ab-4d36-9c1e-602763b93ff0)
2017-06-10T01:16:56.041 First 15 chars: [{"AccountOwner
2017-06-10T01:16:56.181 get date
2017-06-10T01:16:56.181 getting enrollment
2017-06-10T01:16:56.181 Incoming date: 11/01/2016 for Enrollment: 4944727
2017-06-10T01:16:56.181 Collection: partitionedusage
2017-06-10T01:16:56.181 query:  SELECT * FROM c where c.Enrollment = "4944727" AND c.Date = "11/01/2016"
2017-06-10T01:16:56.181 Create delete query
2017-06-10T01:16:56.197 Delete documents
2017-06-10T01:17:23.189 2142 docs deleted while processing 20161101-4944727-dailysplit.json
2017-06-10T01:17:23.189 Import documents
2017-06-10T01:17:44.628 2142 records imported from file 20161101-4944727-dailysplit.json
2017-06-10T01:17:44.628 Moving file 20161101-4944727-dailysplit.json to /processedusage container
2017-06-10T01:17:44.674 Deleting 20161101-4944727-dailysplit.json
2017-06-10T01:17:44.690 Completed!
2017-06-10T01:17:44.690 Function completed (Success, Id=bfb220aa-97ab-4d36-9c1e-602763b93ff0, Duration=49397ms)

Letzter Hinweis

Nur Bedeutung links Vorgehensweise besteht darin, führen Sie eine gute viele Iterationen mit unterschiedlichen Eingaben aus, und klicken Sie dann zu messen, damit ich die Dienste ordnungsgemäß Größe anpassen können, die ich verwende. Dies schließt die geografische Replikationsfunktionen und die Sicherheit, die ich um Abonnement Datenzugriff implementieren möchten, müssen einige weitere Prototyping testen; wurden diese zwei der wichtigsten Gründe für das Azure-Cosmos-Datenbank auswählen. Die net Lektionen, abgeleitet werden sind einige der diejenigen, die wir im Bereich der learning beibehalten zusammengehören IT:

  1. Es gibt keine Magic-Nummerierung, auch nicht mit einer serverlose-Architektur.
  2. Nichts ersetzt gründliches testen.
  3. Größe der abhängigen Dienste und behandeln Sie diese ernsthaft Sie bei der Hardwarekapazität in der Vergangenheit verwendet haben.
  4. Achten Sie besonders auf die Kosten, insbesondere unter hoher Durchsatz Bedingungen.

Der Vorteil der Verwendung von serverlose Compute wie Azure-Funktionen ist, dass Sie Zahlen nur für was genutzt wird. Für die reguläre jedoch selten vorkommen Verarbeitung wie diese kann ein großer Vorteil in kosteneinsparungen sein. Abschließend Konfigurieren von Funktionen ist Benutzerfreundlicher und schnelleren Produkt als Host-Servern konfigurieren.

Joseph Fultzist ein Cloud-Lösungsarchitekt bei Microsoft. Er arbeitet mit Kunden von Microsoft zusammen und entwickelt Architekturen, die Geschäftsprobleme unter Nutzung von Microsoft Azure lösen. Früher war Fultz verantwortlich für die Entwicklung und die Architektur der Bruttogewinn des Car-Freigabe-Anwendung (mavendrive.com). Sie erreichen ihn auf Twitter: @JosephRFultz oder über E-Mail unter jofultz@microsoft.com.

Unser Dank gilt dem folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Fabio Calvacante

Diesen Artikel im MSDN Magazine-Forum diskutieren