MServer in der AWS
-
Ich habe mich die letzten Tage besonders gestern etwas mehr mit der AWS beschäftigt und habe jetzt den MServer soweit als Dockercontainer in der AWS laufen.
Das Ergebnis seht ihr hier:
http://mserver-cloud-filmlisten.s3-website.eu-central-1.amazonaws.com/Den Dockercontainer gibt es hier:
https://hub.docker.com/r/mediathekview/mserver-docker/Und den Dockersource hier:
https://github.com/mediathekview/MServer-DockerMehr Informationen was genau im Einsatz ist und wie ich das ganze zum laufen bekommen habe werde ich noch Dokumentieren und hier darauf hinweisen.
-
Was kommt zum Einsatz?
-
EC2 Container Service
- Hier drin läuft der MServer Dockercontainer
-
S3
- Hier laufen 2 Buckets:
- Bucket mit den Konfigurationsdateien für den MServer
- Bucket für die erstellten Filmlisten zusätzlich noch eine index.html welche via rufuspollock/s3-bucket-listing und “Static Website Hosting” zu folgender Ausgabe führt: http://mserver-cloud-filmlisten.s3-website.eu-central-1.amazonaws.com/
- Hier laufen 2 Buckets:
-
Lambda
- Hier läuft ein Skript auf Basis von pahud/ecs_task_runner.js welches den MServer Container-Task mit zusätzlicher Hilfe eines CloudWatch Triggers aktuell einmal am Tag startet.
-
CloudWatch
- Der Trigger für den MServer Container Start-Lambdatask
- Die Log ausgaben der MServer Container Tasks werden hier gesammelt und analysiert.
Beispiel Ablauf
-
Der CloudWatch trigger startet den Lambdatask, dieser startet den EC2 Container Service Container-Task.
-
Der Container-Task ruft nun den aktuellsten MServer Dockercontainer ab und führt diesen, ähnlich dem run.sh, unter Angabe der benötigten Environmentvariables aus.
-
Im Dockercontainer werden entsprechend der Environmentvariables die Konfigurationsdateien des 1. S3 Buckets angezogen.
- Dies erledigt config_clone.sh
-
Der Dockercontainer starten nun den MServer
-
Nach Durchlauf des eigentlichen Crawlerlaufs werden die Filmlisten in die 2. S3 geladen.
-
Die neuen Filmlisten sind nun durch das “Static Website Hosting” aufrufbar
-
Bei Aufruf der Domain des 2. S3 Buckets liest das Script die im S3 Bucket liegenden Dateien aus und zeigt eine Übersicht dieser an.
Welche Vorteile bietet dies?
-
Skalierbarkeit im EC2 Containerservice können die, dem Task zur Verfügung stehenden Ressourcen sehr leicht angepasst werden. Durch ein sehr gutes Monitoring lässt sich leicht erkennen wann dies zu tun ist.
-
Performance für die User die Anbindung der S3 Buckets ist, wie zu erwarten war, grandios und verträgt auch eine große Anzahl an Nutzern. Sollte dies nicht ausreichen ist es auch sehr einfach möglich die statische Webseite in Zukunft mit Hilfe von Cloudfront und einem Elastic Load Balancer auszuliefern.
-
Man zahlt nur was man nutzt. Amazon berechnet einem nur Ressourcen die man auch tatsächlich benutzt hat.
Fazit:
Durch den Einsatz von AWS wäre es möglich auf günstige Art und Weise eine starke, in Frankfurt gehostete, Infrastruktur zu erzeugen. Diese bietet sehr gute Geschwindigkeiten, skalierbare Performance und sehr gute Analyse-, Monitoring- und Steuerungswerkzeuge. Dadurch würde eine einzelne Infrastruktur dieser Art absolut ausreichen um alle Nutzer von MediathekView zu bedienen. Da eben auch nur für genutzte Ressourcen gezahlt werden muss und nicht für einen dauerhaft laufenden V- oder Rootserver mit ähnlichen Kapazitäten kommt das ganze auch recht günstig daher und sollte sich so Problemlos von den Spenden lassen. Hierzu sei noch anzumerken, dass der Crawler ja nicht dauerhaft läuft und nur alle paar Stunden ausgeführt werden muss.
-
-
@Nicklas2751 sagte in MServer in der AWS:
Durch den Einsatz von AWS wäre es möglich auf günstige Art und Weise eine starke, in Frankfurt gehostete, Infrastruktur zu erzeugen. Diese bietet sehr gute Geschwindigkeiten, skalierbare Performance und sehr gute Analyse-, Monitoring- und Steuerungswerkzeuge. Dadurch würde eine einzelne Infrastruktur dieser Art absolut ausreichen um alle Nutzer von MediathekView zu bedienen. Da eben auch nur für genutzte Ressourcen gezahlt werden muss und nicht für einen dauerhaft laufenden V- oder Rootserver mit ähnlichen Kapazitäten kommt das ganze auch recht günstig daher und sollte sich so Problemlos von den Spenden lassen. Hierzu sei noch anzumerken, dass der Crawler ja nicht dauerhaft läuft und nur alle paar Stunden ausgeführt werden muss.
Deine Mühe und Anstrengung sind auf jeden Fall toll, aber günstig ist leider etwas anderes. Die Anwendungen für AWS sind vielseitig und Amazon bietet dort echt interessante Dinge, aber zum Hosting eignet sich das eher weniger, da die Kosten dort explodieren.
Rechenbeispiel (Daten sind jeweils von mir gemessen und verdoppelt, da etwa die Hälfte meinerseits abgefangen wird):
Datenvolumen täglich: ca. 800GB
Anzahl Requests täglich: ca. 60k
Anzahl Tage im Monat: 30
Preise von aws.amazon.com/de/s3/pricing/ mit Region FrankfurtKosten Request:
60k * 30Tage * $0.0043 pro 10 000 Anforderungen = 7,74$Kosten Datentransfer:
800GB * 30Tage = 24.000GB
Bis zu 10 TB pro Monat $0.090 pro GB: 10.000GB * 0,09 = 900$
Nächste 40 TB pro Monat $0.085 pro GB: 14.000GB * 0,085 = 1190$Kosten gesamt pro Monat: 7,74$ + 900$ + 1190$ = 2097,74$
sollte sich so Problemlos von den Spenden lassen
Wenn so viel Spenden eingenommen werden, dann verstehe ich nicht, warum es bisher Probleme gab.
nicht für einen dauerhaft laufenden V- oder Rootserver mit ähnlichen Kapazitäten kommt das ganze auch recht günstig daher
Für diese Preise bekommt man schon einige Managed-Server, sodass keine Zeit mehr in Wartung und Pflege investiert werden muss.
Ohne jetzt Werbung machen zu wollen, bei der Open Telekom Cloud, die ähnliches bietet, läge man bei ca. 1500€ pro Monat.
-
Wenn so viel Spenden eingenommen werden, dann verstehe ich nicht, warum es bisher Probleme gab.
Das habe ich ja nicht behauptet, sondern nur vermutet. Mir ist die aktuelle Menge der Spenden Einnahmen nicht bekannt.
Aber auch gerade wegen solcher Zahlen gibts diesen Thread. Einerseits um die technische Machbarkeit aufzuzeigen und was ich wie getan habe. Andererseits um meine Vermutungen und Spekulationen mit realen Daten ablgeichen zu können.
