Unsere Erfahrung mit AWS beim Start

    Unsere Aufgabe war es, den reibungslosen Betrieb von Staply zu gewährleisten , die Kosten zu minimieren und gleichzeitig die Flexibilität und Einfachheit der Architektur beizubehalten.
    In diesem Artikel erfahren Sie, welche Serverkonfiguration wir beim Übergang von der geschlossenen Beta zur offenen Nutzung verwenden. Der Zeitraum, in dem die Wertfrage am akutesten ist, da eine Belastung vorliegt, aber immer noch kein Gewinn erzielt wird. Das Fehlen von Material für den Zeitraum der durchschnittlichen Belastung und die Aufforderung zur Synchronisierung veranlassten das Schreiben dieses Artikels. Unsere Ergebnisse:







    • Der Service kümmerte sich um die Ladung: der "beliebte" Bereich bei HackerNews, Habr und ProductHunt
    • Die Spitzenlast während dieser Zeiträume lag im Bereich> 400 U / s und dauerte ~ 5 Stunden.
    • Maximal ~ 10 Registrierungen pro Minute.
    • NewRelic-Verfügbarkeit: 96,092% in den letzten drei Monaten und 99,991% im Februar


    Seit Beginn der Entwicklung verwenden wir Amazon AWS E2, mit dem wir unsere eigene Architektur erstellen können, ohne nach Möglichkeiten suchen zu müssen, um Hosting-Einschränkungen wie bei Heroku zu umgehen, und gleichzeitig umfassende Cloud-Lösungen anbieten zu können.
    Um den Dienst in einwandfreiem Zustand zu halten, haben wir versucht, einen starken Anstieg der Auslastung zu vermeiden und den Verkehr schrittweise zu erhöhen. Auf diese Weise konnten wir Engpässe im System erkennen und im Arbeitsmodus beseitigen, ohne dass es zu Notfällen kam.

    Amazon empfohlene


    Konfiguration: Unsere Konfiguration:
    • t1.micro-Instanz als Balancer (derzeit eher als Router) mit Haproxy
    • t1.small und m3.medium Instanzen mit Nginx Passenger und Redis
    • S3-Dateispeicher
    • RDS m1.small Instanz mit MySQL


    Tagesrechnung: ~ 8,21 $

    Achtung! Amazon überprüft regelmäßig detaillierte Rechnungen, verteilt Zahlungen für viele kleine Ausgaben, und eine Rechnung für einen nicht verwendeten Artikel kann unangenehm überraschend sein.


    Serverkonfiguration

    Der Service ist in Rails geschrieben, diese Tatsache wird jedoch im Artikel nur minimal beeinflusst.
    Zu Beginn der Entwicklung ist eine t1.micro- Instanz mit aktiviertem Swap ausreichend . AWS Free Tier mit einer kostenlosen Nutzungsdauer ermöglicht eine Kostensenkung auf Null.

    Wenn der Service auf Open Access umgestellt wird, ist es besser, nicht zu knausern und von Anfang an in der Architektur die Möglichkeit zu einer starken Kapazitätssteigerung zu legen. Durch die verteilte Multiserver-Architektur können Sie mit jedem Element separat arbeiten, ohne die anderen zu beeinträchtigen (z. B. wenn Sie die Instanz neu starten oder die Leistung erhöhen müssen).
    Verwenden Sie unbedingt die Überwachung, ein kostenloser NewRelic-Plan wird ausreichen.

    Beim Starten der öffentlichen Version des Projekts starten wir den zweiten Server, m3.medium(1 Intel Xeon-CPU, 3,7 GB RAM, Magnetspeicher, konfigurierter Austausch).

    Die Serverleistung wurde unter Berücksichtigung der Konfiguration der Rails-Anwendung berechnet:
    • Ruby 2.1.0
    • Nginx + Passagier 4
    • Jeder Thread belegt ca. 200 MB Speicher.


    Für die bequeme Weiterleitung von Anforderungen zwischen Entwicklungs- und Produktionsservern haben wir eine t1.micro- Instanz verwendet, auf der Haproxy installiert und die SSL-Terminierung konfiguriert ist .
    Die Verwendung von Private IP anstelle von Public in der Haproxy-Konfiguration kann die Verzögerung zwischen Servern erheblich verringern .

    Hab keine Angst vor vorzeitiger Optimierung, jetzt ist der richtige Zeitpunkt für sie. Mit jedem erkannten Engpass im Servicecode und jeder Reduzierung der Reaktionszeit um Hundertstelsekunden können Sie mehr Kunden unterstützen und sparen. Achten Sie dabei auf die Zyklen im Code, in unserem Fall lag das größte Optimierungspotential darin. Wir haben den Überschuss über die Grenzen der Zyklen hinaus entfernt und die Reaktionszeit um ein Dutzend Mal verkürzt.

    Zum Senden von E - Mails unter Verwendung von SES Amazon ist ,
    perfekt integriert in Rails mit Action - Mailer, und bietet einen kostenlosen Kontingent von 10.000 Meldungen / Tag.

    Dateien

    Dateien werden in S3 gespeichert, aber Sie sollten es nicht zum Speichern von Statiken (Skripten, Stilen, Bildern) verwenden. Die Verzögerung ist größer als beim Speichern von Dateien auf der Instanz.
    Dateizugriffsverzögerung:
    • S3: ~ 280 ms - 1,80 s
    • CloudFront: ~ 60 ms - 200 ms

    Aktivieren Sie das Cachen von Inhalten aus S3, indem Sie den Header {'Cache-Control' => 'max-age = 315576000'} hinzufügen.

    Um die Latenz zu verringern, empfiehlt Amazon die Verwendung von CloudFront, einem Dienst, der Inhalte von S3 an Regionen verteilt.
    CloudFront-Verkehr ist billiger als S3-Verkehr.

    Datenbank

    Sie können dieselbe Instanz für die Datenbank als Server verwenden, dies erhöht jedoch die Verbindungen zwischen den Elementen und verringert die Flexibilität der Architektur. Für die Datenbank verwenden wir die RDS- Instanz db.m1.small mit dem Magnetspeicher, sodass wir uns nicht um Sicherungen und Konfigurationen kümmern müssen.
    Beginnend mit der frühesten Beta-Version nutzten Kunden den Service und es gab Daten in der Datenbank, deren Sicherheit wir gewährleisten mussten

    Regionen

    Es ist notwendig, die Geografie potenzieller Kunden und den Markt, in dem wir arbeiten möchten, zu berücksichtigen: Die ganze Welt kann sofort abgedeckt werden, aber die Netzwerkverzögerung wird schwerwiegend sein.
    Alle Elemente der Architektur sollten sich in derselben Region befinden.

    Download-Geschwindigkeit zwischen Regionen:
    Bild

    In der Praxis kann die Verzögerung von St. Petersburg zu Servern in der Region US-EAST 6-mal größer sein als bei Anfragen an EU-WEST-Server.

    Der Aufbau einer einfachen und modularen Architektur von Anfang an bietet ein hohes Potenzial für ein reibungsloses Wachstum und den Übergang zu hohen Lasten.

    Wir freuen uns über Ihre Ratschläge und Kommentare. Das Feedback von Habré hat uns geholfen, viele Momente in unserem Service ernsthaft zu verbessern.

    Verwendete Ressourcen:

    Jetzt auch beliebt: