Kontoauszüge in unterschiedlichen Währungen für 40
Werbung
Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Millionen Nutzer Kann ActuateOne jeden Monat die Kontoauszüge für 40 Millionen Kunden vorbereiten und in kürzester Zeit verfügbar machen? Diese Aufgabe stellte ein Kunde im Rahmen eines Proof of Concept (PoC). Actuate nahm die Herausforderung an. Schließlich sind Leistungsfähigkeit und zuverlässige, lineare Skalierbarkeit die Markenzeichen iServer-basierter Lösungen. In diesem Whitepaper werden die Ergebnisse des PoC vorgestellt. Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Hinweis Die in diesem Whitepaper enthaltenen Informationen sind Eigentum der Actuate Corporation („Actuate") und dürfen in keiner Form ohne die vorherige Zustimmung von Actuate verwendet werden. © 2012 Actuate Corporation. Alle Rechte vorbehalten. Marken und eingetragene Warenzeichen von Actuate Corporation: Actuate , ActuateOne, das Actuate-Logo, BIRT, Collaborative Reporting Architecture, BIRT Analytics, e.Report, , BIRT.Spreadsheet, Encyclopedia, Formula One, Interactive Viewing, The People Behind BIRT, BIRT Performance Analytics, Report Encyclopedia, Reportlet und XML reports. Alle anderen Marken sind Warenzeichen der jeweiligen Inhaber. Version 1 – Januar 2012 Actuate (Deutschland) GmbH Kaiserstraße 44 60329 Frankfurt am Main Tel.: +49 (0)69 / 669025-0 http://www.actuate.com 2 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Inhalt Kurzübersicht ..................................................................................................................................................................................................... 4 Die Ausgangssituation ............................................................................................................................. 4 Voraussetzungen und Ziele ................................................................................................................................................... 5 Die Herausforderung wird gemeistert ................................................................................... 8 Eine Architektur für 40 Millionen Nutzer .............................................................................. 11 Zusammenfassung ................................................................................................................................... 11 Monatliche Datenkonsolidierung über im Batch erzeugte BIRT Data Objects (BDO) ............... 12 Ergebnisse .............................................................................................................................................. 13 Zusammenfassung ................................................................................................................................................................................ 13 Bedarfsgesteuertes Erzeugen und Betrachten der Auszüge ....................................................... 15 Viewing-Ergebnisse .................................................................................................................................. 5 Durchsatz .............................................................................................................................................................................................................. 16 Zusammenfassung ............................................................................................................................................................................... 16 Fazit ................................................................................................................................ 17 3 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Kurzübersicht Ein Kunde stellte Actuate und die BIRT-basierte Lösung ActuateOne vor eine besondere Herausforderung: Es sollte eine Anwendung für die monatliche Kontoabrechnung aufgesetzt werden, die im ersten Schritt 40 Millionen Nutzer und im zweiten Schritt 200 Millionen Nutzer unterstützen konnte. Dazu sollte ein ClusterModell verwendet werden. Zusätzlich mussten noch folgende Anforderungen erfüllt werden: Die Daten sollen den Nutzern innerhalb der ersten fünf Tage des neuen Monats zur Verfügung stehen. Das Zeitfenster zur Verarbeitung der Transaktionsdaten ist also knapp bemessen. Die Größe der Kontoauszüge variiert und reicht von 12 bis 250 Seiten. Für letztere werden 2.000 Zeilen Transaktionsdaten benötigt. Die meisten Kunden schauen sich ihre Kontoabrechnung online, also in HTML an, aber 15% laden sich ihre Auszüge als PDF herunter. 20% der Nutzer rufen zudem ihren Kontoauszug innerhalb der ersten zwei Tage nach der Verarbeitung ab. Die Abrechnungen sind multinational und unterstützen unterschiedliche Währungstypen. Und last but not least müssen alle Kontoauszüge den Anwendern sieben Jahre zur Verfügung stehen. Die mit dieser Aufgabe verbundenen Herausforderungen waren vielfältig. Zunächst einigten sich Actuate und der Interessent auf den Aufbau eines Testsystems. Es sollte zum einen die Nutzung realitätsnah widerspiegeln und zum anderen beweisen, dass ein skalierbares, reproduzierbares Topologiemodell aufgebaut werden kann, mit dem sich das erste Ziel – das Erstellen und Testen einer Anwendung für 40 Millionen Nutzer – realisieren lässt. War dies erreicht, sollte dieses Modell dann 5-mal erweitert werden, um das endgültige Ziel (die Unterstützung von 200 Millionen Usern) zu erreichen. Der Betrieb des Systems bestand aus zwei Phasen: der Datenaufbereitung und der Erstellung der Auszüge. Für die Datenaufbereitung mussten die Transaktionen des Monats so organisiert werden, dass daraus schnell individuelle, von den Empfängern ganz nach Bedarf abrufbare Kontoauszüge in mehreren Währungen erstellt werden konnten. Im letzten Schritt musste das System beweisen, dass es in der Lage war, die Belastungsspitzen durch das On-Demand-Laden zu bewältigen, wenn die Kunden ihre Auszüge in den ersten zwei Tagen nach der Datenaufbereitungsphase abriefen. Actuate hat jede dieser Herausforderungen erfolgreich gemeistert: Zuerst wurde ein System für 40 Millionen Nutzer auf Basis einer einfachen Vier-Server-Topologie aufgebaut. Die vorgegebenen Aufbereitungs- und Bereitstellungsziele wurden ebenfalls erreicht und belegten die lineare Skalierbarkeit des Systems. Außerdem bewiesen die Testergebnisse nicht nur, dass Actuate diese Ziele erfüllen konnte. Es zeigte sich darüber hinaus, dass insgesamt weniger Zeit benötigt wurde, da der Aufwand für die Datenaufbereitung deutlich geringer war. Das für die Bereitstellung vorgegebene Zeitfenster wurde von sieben Tagen auf weniger als 2 ½ Tage verringert. Der Interessent konnte dadurch seinen Nutzern eine unglaubliche Service-Verbesserung bieten. Die Ausgangssituation Anwender auf der ganzen Welt wollen nach dem Monatsende schnellstmöglich ihre Kontoauszüge einsehen. Das stellte das Unternehmen unter einen enormen Druck. Bisher musste dazu ein mehrstufiger Prozess durchlaufen werden, der mehr als zwei Wochen in Anspruch nahm und nicht länger mit dem geschäftlichen Wachstumskurs Schritt halten konnte. Bei der Realisierung stand Actuate vor drei Herausforderungen. 4 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Erstens: Die Datenaufbereitung dauerte zu lange. Schuld daran war das durch einen ETL-Vorgang gesteuerte, sehr zeitaufwendige Laden in die Datenbank. Der ETL-Prozess wurde nicht verändert, aber das Laden in die Datenbank wurde umgangen, da Actuate dieselben Dateien (im CSV-Format) verwenden konnte. Zweitens: Es galt, die in den ersten Tagen nach Verfügbarkeit der Kontoauszüge auftretende Belastungsspitze aufzufangen. Außerdem sollten die Antwortzeiten immer hervorragend sein und zwar unabhängig vom Zeitpunkt des Systemzugriffs. Drittens: Das System musste die reale Bereitstellung von Kontoauszügen in den von den Nutzern erwarteten Größen und Formaten unterstützen. Außerdem sollte gezeigt werden, das ein Wachstum der Anwenderpopulation und der dazugehörigen Transaktionen von 4 Millionen auf 40 Millionen und letztendlich auf 200 Millionen problemlos möglich ist. 5 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Voraussetzungen und Ziele Im Folgenden werden die Ergebnisse des vom Kunden geforderten Proof of Concept (POC) detailliert vorgestellt. Actuate sollte den Nachweis erbringen, dass sich mit den Actuate-Lösungen eine Systemarchitektur aufbauen ließ, die 40 Millionen Nutzer mit ihren monatlichen Kontoauszügen versorgen konnte. Dies war jedoch nicht die einzige Vorgabe. Das System musste so skalierbar sein, dass durch eine einfache Erweiterung der Ressourcen 200 Millionen Anwender unterstützt werden konnten. Der Test sollte das tatsächliche Verhalten des Systems widerspiegeln und zwar auf Basis des aktuellen Betriebsprofils des Kunden. Als Anwendung zum Erzeugen und Bereitstellen von Kontoauszügen unterliegt das System jeden Monat regelmäßigen, zyklischen Leistungsmerkmalen. Das für den Tauglichkeitsnachweis erstellte Betriebsprofil sah so aus: • 40.000.000 Nutzerkonten, Anmeldungen und Transaktionsdetails in mehreren Währungen müssen erstellt werden, um die Datenmenge für einen Monat widerzuspiegeln. Zuerst werden die Transaktionsdaten geordnet und für jeden Kontoauszug im Batch-Modus aufbereitet. Danach können alle Auszüge für die Nutzer bedarfsgemäß erstellt werden. Es werden nur die Daten vorbereitet. Die Auszüge selbst werden erst dann erstellt, wenn ein Nutzer sie abruft. • Die Daten für die Kontoauszüge müssen in den ersten fünf Tagen nach Abschluss der monatlichen Berichtsperiode aufbereitet werden, damit die aktiven Nutzer ihre Auszüge innerhalb der ersten Woche nach Monatsende erhalten. • Jeder Kontoauszug beginnt mit einer Gesamtübersicht und zeigt den Anfangssaldo, die Umsätze je Währung und Transaktionsart und den Schlusssaldo des Monats. Die weiteren Seiten des Auszugs enthalten die detaillierten Buchungsinformationen gruppiert nach Währung und in chronologischer Reihenfolge. Jeder Auszug enthält zudem auf jeder Seite Kopf- und Fußzeilen mit dem Logo und den Informationen des Kunden. 6 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer • Die Größe der Kontoauszüge unterscheidet sich folgendermaßen: 94% der Auszüge enthalten 75 Buchungszeilen. Das ergibt eine 12-seitige Kontoabrechnung in mehreren Währungen und ein PDF-Dokument von 30 KB. o 5% der Auszüge enthalten 300 Buchungszeilen auf 40 Seiten. Das PDF ist 80 KB groß. o 1% der Auszüge enthalten 250 Seiten mit 2.000 Buchungszeilen. Das ergibt eine PDF-Größe von 400 KB. Die Auszüge müssen so strukturiert sein, dass sie gespeichert und mindestens sieben Jahre lang jederzeit von den Nutzern abgerufen werden können. o • • Sind die Kontoauszüge fertiggestellt, erlebt das System seine Belastungsspitze. 20% der Anwender greifen innerhalb der ersten zwei Tage nach Benachrichtigung auf ihren Auszug zu. In dieser Zeit wirft die Mehrheit der Nutzer (85%) einfach online (in HTML) einen Blick auf ihre Kontoabrechnung, aber 15% der Anwender fordern ihre Auszüge im PDF-Format an. 7 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Zur realistischen Abbildung dieser zwei Tage einigten sich Actuate und das Kundenunternehmen darauf, dass zwei Drittel der Nutzer sofort am ersten Tag der Auszugverfügbarkeit ihre Abrechnung abrufen. Die Belastungsspitze sollte also am ersten Tag des Zweitageszeitraums stattfinden und der Test wurde auf die Ladeanforderungen während dieser Spitzenbelastung ausgelegt. Die im PoC angesetzte Gesamtzeit betrug fünf Tage für die Datenaufbereitung und in den folgenden zwei Tagen sollte die Spitzenbelastung für die Bereitstellung erfolgen. Alles sollte also in der ersten Woche des neuen Monats ablaufen. In Zahlen ausgedrückt ergibt sich daraus folgende Performancesituation: • Für 40 Millionen Nutzer aus 4.2 Milliarden Transaktionsdatensätzen (686 GB) die Daten für die Kontoauszüge aufbereiten. Zeitrahmen: innerhalb von fünf Tagen nach Monatsende. • 8 Millionen Anwendern innerhalb von zwei Tagen Zugriff auf die Auszüge ermöglichen, dies beinhaltet auch das Erstellen von 1.2 Millionen PDF-Dokumenten. • Verteilung der Nutzeraktivität dieser 8 Millionen, so dass zwei Drittel, also 5,3 Millionen, am ersten Tag auf das System zugreifen und der Rest am zweiten Tag. Weitere Verteilung des Zugriffs auf normale Geschäftszeiten auf Basis der unten stehenden Verteilungskurve. Diese Kurve legt das Nutzungsschema für die 5,3 Millionen Zugriffe während des ersten Tages der Verfügbarkeit der Kontoauszüge fest. Beim Spitzenzugriffswert in der Hauptbelastungszeit von o9:30 - 10:30 Uhr wird von 439.000 aktiven Nutzern ausgegangen. 8 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Die Herausforderung wird gemeistert Actuate stellte eine geclusterte BIRT-iServer-Umgebung zur Verfügung. iServer sollte beide Stufen des Prozesses übernehmen und zuerst die Transaktionsdaten in für die Kontoabrechnungen verwendbare Daten verwandeln und Auszüge erzeugen, sobald sie von den Nutzern angefordert wurden. Die Kontoauszüge können im HTML- und im PDF-Format erstellt werden. Der zweistufige Prozess nutzt unterschiedliche BIRTFunktionen. Zunächst wurden BIRT Data Objects (BDO) aufgesetzt. Sie repräsentieren die entsprechenden Subsets der Daten und werden im letzten Schritt des ETL-Prozesses erstellt, so dass die Daten der erzeugten CSV-Dateien nicht mehr ins Data Warehouse geladen werden müssen. Die fertigen Berichtsdesigns für die Auszüge wurden ebenfalls mit BIRT entwickelt. Beide Inhaltsdarstellungen, die Datenstruktur sowie das endgültige Dokumentdesign wurden mit BIRT Designer Professional erstellt. Die verwendete Architektur und Hardware-Topologie setzte sich aus folgendem zusammen: • Eine ETL-Datenbank (ETL-Daten) mit den Transaktionsdaten. Die Datenbank enthielt über eine Milliarde Zeilen mit Transaktionsdatensätzen, die die Daten für 10 Millionen Nutzer darstellten. Diese Daten wurden viermal verwendet, um CSV-Dateien zu erstellen. So entstanden die BIRT Data Objects mit den Daten für 40 Millionen Nutzer. (Der ETL-Prozess des Kunden erzeugte sehr große CSV-Dateien, die in das Data Warehouse geladen wurden. Der Test machte diesen Ladeprozess überflüssig und nutzte die CSV-Dateien direkt als Datenquelle.) • Eine iServer-Encyclopedia-Metadaten-Datenbank (iServerDB), in der iServer-Metadaten wie Dateizugriffsrechte und Dateispeicherorte abgelegt waren. • Ein Vier-Knoten-Cluster von BIRT iServern (iServer-Cluster) mit Factory- und Viewing-Services zum Erstellen der BIRT Data Objects während der Batch-Phase und zum Erzeugen und Betrachten der Kontoabrechnungen während der Abruf-Phase. o Bei der ETL-Datenbank, der iServer DB und den iServer-Factory-Maschinen handelte es sich um Server des Typs Dell PowerEdge R610 (Intel Xeon X5650, 2.66 GHz) Dual Chip, 6 Cores/Chip mit 48 GB Arbeitsspeicher und einer SPECint_2006_Rate von 353. Der Listenpreis für jeden dieser Server betrug zum Zeitpunkt des Kaufs circa 8.000 US-Dollar. (6 Rechner x $ 8T = $ 48T) (Der aktuelle Marktwert liegt bei circa 3.000 US-Dollar pro Gerät.) • Auf zwei Dateiservern wurden die erzeugten Berichte und Data Objects gespeichert. Jeder enthielt 12 Festplatten in zwei Partitionen. Bei jeder Platte handelte es sich um ein 600 GB SAS 15K 6 Gbit/Sek. Laufwerk. (Einzelpreis ca. 750 US-Dollar x 24 Laufwerken = 18T US-Dollar). Der Festplatten-IO stellte einen potenziellen Engpass dar. • Vier Information-Console-Knoten mit Lastausgleich für den Portal-Zugriff auf den Back-End-iServerCluster. • Drei Test-Clients, die die Systembelastung übernehmen und die Nutzeraktivitäten auf der Information Console und iServer erzeugen sollten. • Ein 10-Gigabit-Netzwerk, alle Rechner liefen unter Redhat Linux. • Die Gesamtkosten für die Betriebsinfrastruktur betrugen weniger als 80.000 US-Dollar. 9 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer 10 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Eine Architektur für 40 Millionen Nutzer Vor dem Test mussten zunächst die Datenquelleninformationen erstellt werden, die die Anwendertransaktionen darstellen sollten. Außerdem wurden die iServer-Datenbanken mit den Konten für alle 40 Millionen Nutzer angelegt. Der Kunde stellte zu diesem Zweck Daten mit den Transaktionen für 10 Millionen Nutzer zur Verfügung. Diese Anzahl wurde von Actuate dann einfach vervierfacht. Sobald das Datenset mit 4 x 10 Millionen Transaktionsdaten erstellt war, wurden die mit diesen Transaktionsdatensätzen verbundenen Nutzerkonten in iServer geladen. Die Speicherschicht der iServer Encyclopedia besteht aus zwei unabhängig von einander skalierbaren Komponenten: 1. Bei der iServerDB handelt es sich um einen Datenbankserver, auf dem Postgres läuft. Dort sind die relevanten Metadaten der Umgebung wie die Nutzerkonteninformationen und die Speicherorte der Dateien, auf die jeder Anwender zugreifen darf, abgelegt. 2. Die zweite Komponente ist das Dateisystem selbst, das aus einem über das Netzwerk zugänglichen Speichersystem besteht. Für das Testsystem verwies die iServerDB auf die vier Datenträger des iServer-Dateisystems, wobei jeder Datenträger 10 Millionen Nutzerkonten enthielt. Diese Art der Konfiguration lässt sich skalieren, ist hochverfügbar und redundant, wenn das System wächst. Potenzieller Schwachpunkt eines solchen Systems sind die Schreib-/Lesevorgänge auf den Festplatten. Bei einem Probedurchlauf führten die umfangreichen I/Os auch tatsächlich zu überlasteten Platten. Im Test konnte dieser Engpass durch Hinzufügen eines zweiten Dateisystems behoben werden. Für die Praxis empfiehlt sich der Einsatz von SSD-Speichern. Damit wären zwar zusätzliche Kosten verbunden, aber das Problem ließe sich so wohl dauerhaft lösen. Die iServer DB mit Postgres kann ebenfalls Reproduktion unterstützen, was auch sie fehlertolerant macht. Für diese Funktion unterstützt Actuate außerdem Oracle, DB2 und Microsoft SQL Server 2008. Zusammenfassung Es kann eine reproduzierbare Topologie aufgebaut werden, die jeweils mindestens 40 Millionen Nutzer unterstützt. Gleichzeitig eröffnet sie einen vorausberechenbaren Wachstumspfad für die Einbindung von 200 Millionen Nutzerkonten, ohne dass das System dadurch an Komplexität gewinnt. 11 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Monatliche Datenkonsolidierung über im Batch erzeugte BIRT Data Objects (BDO) In der ersten Testphase war zu beweisen, dass Actuate die monatlich anfallende Datenmenge aufbereiten und am Monatsende bereitstellen konnte. Statt die Daten nach dem monatlichen ETL-Prozess aus dem Data Warehouse zu ziehen, entschieden sich die Actuate-Experten, einfach direkt die vom ETL-Vorgang erzeugten CSV-Dateien zu nutzen. Damit wurde ein ganzer Schritt des bisherigen Ladeprozesses übersprungen. Die Vorbereitung der Kontoauszüge wurde dadurch erheblich verkürzt und die Erstellung war weniger komplex. Trotzdem hatte der Kunde für die im Batch-Modus ablaufende Datenaufbereitung 120 Stunden (fünf Tage) angesetzt. Bei dem Prozess ging es darum, die Datenmenge eines Monats in Kundenkonto-gemäß gruppierten Blöcken anzuordnen. Für diese Aufgabe setzte Actuate das Caching-Dienstprogramm von BIRT Data Object ein. Damit wurden im Arbeitsspeicher die Auszugsinformationen der einzelnen Nutzer aufbereitet und zwischengespeichert. Dieser Test umfasste die zeitgesteuerte, simultane Erzeugung einer großen Menge von BIRT Data Objects. • Die CSV-Dateien enthielten alle 4,2 Milliarden Zeilen mit 668 GB an Transaktionsdaten. • BDOs sind BIRT Data Objects mit einem komprimierten Datenformat. Der Prozess erzeugte 56 BDOs mit einer Gesamtgröße von 718 GB. • Jedes BDO enthielt circa 1 Millionen Kontoauszüge und war 11 bis 13 GB groß. 12 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Ergebnisse Es waren zwei Testdurchläufe vorgesehen, einer mit einem 2-Knoten- und einer mit einem 4-Knoten-iServerCluster. Damit sollte zum einen bewiesen werden, dass die Aufgabe mit nur zwei Knoten gelöst wird und zum anderen wollte man demonstrieren, dass das BIRT-iServer-System linear skaliert und hiermit das Wachstumsmodell unterstützt werden kann. Im ersten Testdurchlauf ging es um die Anordnung der Daten nach Konto, ohne dabei die Daten im BIRT Data Object zu sortieren. Jeder iServer-Knoten war für die Ausführung von acht BIRT-Factoryen konfiguriert. Testlauf 1, Auszüge geordnet nach Konto Konfiguration Zeit Durchsatz (MB/Sek.) 2 iServer-Cluster, 16 BIRT-Factories 135 Min. 88 MB/Sek. 4 iServer-Cluster, 32 BIRT-Factories 69 Min. 176 MB/Sek. Testlauf 2, Auszüge geordnet nach Konto und sortiert Konfiguration Zeit Durchsatz (MB/Sek.) 2 iServer-Cluster, 16 BIRT-Factories** 155 Min. 74 MB/Sek. 4 iServer-Cluster, 32 BIRT-Factories** 115 Min. 99.2 MB/Sek. **CSVs auf einem NFS-Server, Festplatten-IO zu hoch 4 iServer-Cluster, 32 BIRT-Factories (2 CSV-Dateiserver) 75 Min. 152.4 MB/Sek. Zusammenfassung Das Erzeugen der BIRT Data Objects wurde innerhalb des vorgegebenen Zeitrahmens von fünf Tagen mit Leichtigkeit bewältigt – sogar nur mit dem zwei Knoten-iServer-Cluster. Der Test bewies, dass sich mit BIRT Data Objects mehr als 4,9 Tage an Aufbereitungszeit sparen lassen. Der zur Erzeugung erforderliche Aufwand betrug darüber hinaus immer circa 75 Minuten, ob die Daten nun sortiert waren oder nicht. Das Sortieren hatte keinerlei Auswirkung auf die Gesamtperformance. 13 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Durch das Sortieren wurde man jedoch auf einen potenziellen Engpass aufmerksam. Damit die BIRT-Rechner schnell genug mit Daten gefüllt werden konnten, erforderte der Zugriff auf die CSV-Daten einen schnelleren Festplatten-IO. Nach dem Beheben dieser Schwachstelle war das System wieder linearer skalierbar. Von der ursprünglich für die Datenaufbereitung angesetzten Woche wurden weniger als zweieinhalb Tage benötigt – und zwar für die gesamte Bereitstellung. Der Kunde verfügt also über genügend Spielraum für die Anbindung weiterer Nutzer, ohne dass damit Performanceprobleme verbunden wären. 14 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Bedarfsgesteuertes Erzeugen und Betrachten der Auszüge In der letzten Phase des Tests ging es um die Leistung des Systems beim Abrufen der Kontoauszüge durch die Nutzer. Dabei sollte jeder User die folgenden Aktionen ausführen: 1. Anmelden auf der Website. Die Internetpräsenz des Kunden basiert nicht exklusiv auf Actuate, sodass Single-sign-on während des Log-ins erforderlich ist. 2. Abrufen des Kontoauszugs, wodurch direkt eine On-Demand-Abfrage zum Erstellen und Betrachten des entsprechenden Abrechnungsberichts angestoßen wird. Während dieses Vorgangs wurde das folgende Anforderungsprofil berücksichtigt: 3. 85% der Nutzer schauen sich die erste Seite ihres Auszugs über den Actuate Viewer in HTML an 4. 15% der User laden sich den kompletten Kontoauszug als PDF herunter 5. Abmelden Die Größe der Kontoauszüge und ihre Bereitstellung unterschieden sich gemäß der folgenden drei Vorgaben: Nutzermenge Datenbankgröße Seitenzahl PDF-Dokumentgröße 94% aller Nutzer 75 Zeilen 12 Seiten 30 KB 5% aller Nutzer 300 Zeilen 40 Seiten 80 KB 1% aller Nutzer 2000 Zeilen 250 Seiten 400 KB Viewing-Ergebnisse Man erinnere sich an den Ziel des Tests: Am ersten Tag war eine Spitzenbelastung zu bewältigen, bei der 439.000 Kontoauszüge pro Stunde abgerufen wurden. Dies bedeutete, dass während dieser Zeit 122 Nutzer pro Sekunde ihren Auszug anschauen. In der Abbildung unten sind das Ziel sowie die im Test verwendete inkrementelle, lineare Anlaufzeit dargestellt. Durch letztere ließ sich die Zielvorgabe um mehr als 7 Prozent unterschreiten. 15 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Durchsatz Die folgende Tabelle zeigt detailliert die Durchsatzmessungen während der On-Demand-Auszugserstellung und Abruftests. Jeder Test verwendete sämtliche 56 BIRT Data Objects und jeder Testlauf basierte auf dem gleichem Verhältnis von Information Consoles (IC) zu iServern (IS), wobei vier Viewing Services (VS) pro iServer gesteuert wurden. Während der einstündlichen Testläufe wurden außerdem Fehler und Fehlerquoten gemessen und protokolliert. Jeder Nutzer, bei dem ein Fehler auftrat, führte die Abfrage erneut - und dann erfolgreich - aus. Konfiguration Durchsatz IC x IS, VS 1x1, 4 VS 31 Abrufe/Sek. Nutzer/ Stunde 111K Antwortzeit 0.98 Sek. CPUiServer 79% CPUIC 22% Fehler 42 Fehlerquote 0.0004% 2x2, 8 VS 66 Abrufe/Sek. 238K 0.92 Sek. 80% 24% 88 0.0004% 3x3, 12 VS 99 Abrufe/Sek. 358K 0.93 Sek. 79% 24% 131 0.0004% 4x4, 16 VS 131 Abrufe/Sek. 473K 0.94 Sek. 80% 25% 176 0.0004% Zusammenfassung Das System erfüllte die Zielvorgabe und verarbeitete über 122 Nutzerabrufe pro Sekunde. Außerdem wurde bewiesen, dass dieses Performanceprofil linear skalierbar ist, wenn die Anzahl der Server erhöht wird. 16 Whitepaper: Actuate in der Praxis: Kontoauszüge in unterschiedlichen Währungen für 40 Million Nutzer Fazit Im Rahmen dieses Proof of Concept sollten spezifische, vom Kunden vorgegebene Skalierbarkeits- und Performanceaufgaben erfüllt werden. Für diesen Test gab es drei Hauptzielsetzungen: 1. Aufbau einer skalierbaren Architektur, die eine Anfangsbelastung von 40 Millionen Nutzern bewältigen kann und mit dem Fünffachen an Belastung keine Schwierigkeiten hat. 2. Nachweis, dass sich die einem monatlichen Datenaufkommen entsprechenden Beispieldaten schnell für den Abruf aufbereiten und zur Verfügung stellen lassen. 3. Beweis, dass die Umgebung tatsächlich die fertigen Kontoauszüge auch bei Spitzenbelastung bereitstellen kann. Die Ergebnisse übertrafen alle Erwartungen und zeigten, dass iServer-Komponenten linear skalierbar sind (werden die Ressourcen verdoppelt, verdoppelt sich auch der Durchsatz) – selbst bei einer Umgebung mit 40 Million Nutzerkonten. Wenn die Anforderungen des Projekts wachsen, kann die einfache Topologie problemlos ausgebaut werden, ohne dass die Komplexität zunimmt. Bei der Datenaufbereitung konnte die meiste Zeit eingespart werden. Jetzt steht 98% der bisher dafür benötigten Zeit für andere Aufgaben zur Verfügung. Bei der vom Kunden vorgegebenen Komplexität der Kontoauszüge und Nutzeraktivitätskurve konnte das System die Zielvorgabe nicht nur erfüllen, sondern war bei der Bewältigung der stündlichen Spitzenauslastung auch noch 7% schneller, ohne dabei die CPU des Systems zu überlasten. Bei der Erstellung von multi-nationalen Kontoauszügen für 40 Millionen Nutzer konnte Actuate nicht nur belegen, dass dies mit BIRT möglich ist, sondern auch zeigen, dass sich damit auch ein erheblich größeres System unterstützen lässt. Kein anderer Anbieter hat sich dieser Herausforderung gestellt. ActuateOne steht allein an der Spitze einer Anwendungsarchitektur für 40 Millionen Nutzer. 17
