MServer in der AWS


  • Administrator

    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:

    Den Dockercontainer gibt es hier:

    Und den Dockersource hier:
    https://github.com/mediathekview/MServer-Docker

    Mehr Informationen was genau im Einsatz ist und wie ich das ganze zum laufen bekommen habe werde ich noch Dokumentieren und hier darauf hinweisen. ;)


  • Administrator

    Was kommt zum Einsatz?

    • EC2 Container Service

    • S3

    • 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

      1. Der Trigger für den MServer Container Start-Lambdatask
      2. Die Log ausgaben der MServer Container Tasks werden hier gesammelt und analysiert.

    Beispiel Ablauf

    1. Der CloudWatch trigger startet den Lambdatask, dieser startet den EC2 Container Service Container-Task.

    2. 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.

    3. Im Dockercontainer werden entsprechend der Environmentvariables die Konfigurationsdateien des 1. S3 Buckets angezogen.

    4. Der Dockercontainer starten nun den MServer

    5. Nach Durchlauf des eigentlichen Crawlerlaufs werden die Filmlisten in die 2. S3 geladen.

    6. Die neuen Filmlisten sind nun durch das “Static Website Hosting” aufrufbar

    7. 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?

    1. 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.

    2. 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.

    3. 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 Frankfurt

    Kosten 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.


  • Administrator

    @lookshe

    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. ;)


Anmelden zum Antworten
 

132
Online

994
Benutzer

853
Themen

4477
Beiträge

Es scheint als hättest du die Verbindung zu MediathekView-Forum verloren, bitte warte während wir versuchen sie wieder aufzubauen.