In der letzten Woche war ich auf der IT-Konferenz DUMP (https://dump-ekb.ru/) in Jekaterinburg und möchte erzählen, worüber in den Sektionen Backend und Devops gesprochen wurde und ob regionale IT-Konferenzen von Bedeutung sind.
Nikolai Svertchkov von Evil Martians über Serverless
Was war überhaupt los?
Insgesamt gab es auf der Konferenz 8 Sektionen: Backend, Frontend, Mobile, Testing und QA, Devops, Design, Wissenschaft und Management.
Die größten Säle hatten übrigens Wissenschaft und Management, jeweils für etwa 350 Personen. Backend und Frontend waren nur geringfügig kleiner. Der Saal für Devops war der kleinste, aber sehr aktiv.
Ich habe Vorträge in den Sektionen Devops und Backend gehört und ein wenig mit den Referenten gesprochen. Ich möchte über die behandelten Themen berichten und eine Übersicht über diese Sektionen geben.
In den Sektionen Devops und Backend traten Vertreter von SKB Kontur, DataArt, Evil Martians, dem Jekaterinburger Webstudio Flag und Miro (RealTimeBoard) auf. Die Themen betrafen CI/CD, die Arbeit mit Warteschlangendiensten, Logging, die Themen Serverless und die Arbeit mit PostgreSQL in Go wurden gut behandelt.
Es gab auch Vorträge von Avito, Tinkoff, Yandex, Jetstyle, MegaFon und der Bank Ak Bars, aber ich konnte sie nicht persönlich besuchen (Videoaufzeichnungen und Folien der Vorträge sind noch nicht verfügbar, sie versprechen, sie innerhalb von zwei Wochen auf dump-ekb.ru hochzuladen).
Devops-Sektion
Was mich überrascht hat – die Sektion fand im kleinsten Saal mit etwa 50 Plätzen statt. Die Leute standen sogar in den Gängen 🙂 Ich werde über die Vorträge berichten, die ich hören konnte.
Elastic mit einem Petabyte
Die Sektion begann mit einem Vortrag von Wladimir Lila (SKB Kontur) über Elasticsearch bei Kontur. Sie haben ein ziemlich großes und stark belastetes Elasticsearch (~800 TB Daten, ~1,3 Petabyte unter Berücksichtigung der Redundanz). Elasticsearch ist für alle Dienste von Kontur einheitlich, besteht aus zwei Clustern (mit 7 und 9 Servern) und ist so wichtig, dass es bei Kontur einen speziellen Elasticsearch-Ingenieur gibt (nämlich Wladimir selbst).
Wladimir teilte auch seine Gedanken über den Nutzen von Elasticsearch und die Probleme, die es verursacht, mit.
Nutzen:
- Alle Logs an einem Ort, einfacher Zugang zu ihnen
- Aufbewahrung von Logs für ein Jahr und deren einfache Analyse
- Hohe Geschwindigkeit bei der Arbeit mit Logs
- Tolle Datenvisualisierung 'out of the box'
Probleme:
- Message Broker – ein Muss (bei Kontur übernimmt Kafka diese Rolle)
- Besonderheiten der Arbeit mit Elasticsearch Curator (periodisch hohe Last durch regelmäßige Aufgaben im Curator)
- keine eingebaute Authentifizierung (nur gegen separate, ziemlich hohe Gebühren oder als Open-Source-Plugins in unterschiedlichem Produktionsstatus)
Die Rückmeldungen zu Open Distro for Elasticsearch waren ausschließlich positiv 🙂 Das gleiche gilt für das Autorisierungsthema dort.
Woher die Petabytes?Ihre Knoten bestehen aus Servern mit 12*8 Tb SATA + 2*2 Tb SSD. Cold Storage auf SATA, SSD nur für den heißen Cache (Hot Storage).
7+9 Server, (7 + 9) * 12 * 8 = 1536 Tb.
Ein Teil des Speicherplatzes ist als Reserve eingeplant, um Redundanz u.ä. abzudecken.
In Elasticsearch werden Logs von etwa 90 Anwendungen gesendet, einschließlich aller Berichterstattungsservices von Kontur, Elba u.a.
Besonderheiten der Entwicklung auf Serverless
Im Folgenden der Bericht von Ruslan Serkin aus DataArt über Serverless.
Ruslan sprach über die Entwicklung mit dem Serverless-Ansatz im Allgemeinen und welche Besonderheiten sie hat.
Serverless ist ein Ansatz zur Entwicklung, bei dem die Entwickler keinerlei Berührung mit der Infrastruktur haben. Beispiel: AWS Lambda Serverless, Kubeless.io (Serverless innerhalb von Kubernetes), Google Cloud Functions.
Eine ideale Serverless-Anwendung ist einfach eine Funktion, die eine Anfrage an den Serverless-Anbieter über einen speziellen API-Gateway sendet. Der ideale Mikrodienst, wobei in AWS Lambda eine große Anzahl moderner Programmiersprachen unterstützt wird. Die Kosten für die Unterstützung und Bereitstellung der Infrastruktur werden bei Cloud-Anbietern null, die Unterstützung kleinerer Anwendungen wird ebenfalls sehr günstig sein (AWS Lambda — 0,2$ / 1 Million einfacher Anfragen).
Die Skalierbarkeit eines solchen Systems ist nahezu ideal — der Cloud-Anbieter kümmert sich selbst darum, Kubeless skaliert automatisch innerhalb des Kubernetes-Clusters.
Es gibt Nachteile:
- die Entwicklung großer Anwendungen wird schwieriger
- es gibt Schwierigkeiten mit dem Profiling von Anwendungen (nur Logs stehen zur Verfügung, aber kein Profiling im gewohnten Sinne)
- es gibt keine Versionierung
Ich sage ganz ehrlich, ich habe vor ein paar Jahren von Serverless gehört, aber all die Jahre war mir unklar, wie ich es richtig anwenden soll. Nach Ruslans Bericht hatte ich ein Verständnis, und nach Nikolai Swerchkovs (Evil Martians) Bericht aus dem Backend-Bereich wurde es gefestigt. Der Besuch der Konferenz war also nicht umsonst 🙂
CI für kleine Budgets, oder lohnt es sich, ein eigenes CI für eine Webagentur zu schreiben?
Mikhail Radionov, Leiter der Webagentur Flag aus Jekaterinburg, sprach über selbstgeschriebenes CI/CD.
Seine Agentur hat den Weg vom „manuellen CI/CD“ (auf den Server per SSH gehen, git pull durchführen, 100 Mal am Tag wiederholen) zu Jenkins und zu einem selbstentwickelten Tool namens Pullkins, das es ermöglicht, den Code zu kontrollieren und Releases durchzuführen, zurückgelegt.
Warum hat Jenkins nicht überzeugt? Er bot standardmäßig nicht genügend Flexibilität und war zu kompliziert bei der Anpassung.
„Flag“ wird auf Laravel (PHP-Framework) entwickelt. Bei der Entwicklung des CI/CD-Servers haben Michail und seine Kollegen die integrierten Mechanismen von Laravel namens Telescope und Envoy genutzt. Das Ergebnis ist ein PHP-Server (bitte beachten), der eingehende Webhook-Anfragen verarbeitet, in der Lage ist, Frontend, Backend zu bauen, auf verschiedene Server zu deployen und in Slack zu berichten.
Um die Möglichkeit einer Blue/Green-Bereitstellung zu haben und einheitliche Einstellungen in den Dev-, Stage- und Prod-Umgebungen zu gewährleisten, sind sie zu Docker gewechselt. Die Vorteile blieben die gleichen, es kamen Möglichkeiten zur Homogenisierung der Umgebung und nahtlosem Deployment hinzu, und es entstand die Notwendigkeit, Docker zu lernen, um korrekt damit arbeiten zu können.
Wie wir die Anzahl der Rollbacks bei Server-Releases um 99% reduziert haben.
Der letzte Vortrag in der DevOps-Sektion wurde von Viktor Jaremtschenko, Lead DevOps-Ingenieur bei Miro.com (ehemals RealTimeBoard), gehalten.
Die Grundlage von RealTimeBoard, dem Hauptprodukt des Miro-Teams, ist eine monolithische Anwendung in Java. Diese ohne Ausfallzeiten zu bauen, zu testen und zu deployen, ist eine anspruchsvolle Aufgabe. Wichtig ist es, eine Version des Codes zu deployen, die nicht zurückgerollt werden muss (es handelt sich schließlich um ein schweres Monolith).
Auf dem Weg zum Aufbau eines Systems, das dies ermöglicht, hat Miro einen Weg eingeschlagen, der die Arbeit an der Architektur, den verwendeten Werkzeugen (Atlassian Bamboo, Ansible usw.) und die Teambildung umfasst (sie haben derzeit ein dediziertes DevOps-Team und viele separate Scrum-Teams von Entwicklern verschiedener Profile).
Der Weg erwies sich als schwierig und steinig, und Viktor teilte den gesammelten Schmerz und den dennoch ungebrochenen Optimismus.
Gewann ein Buch für Fragen.
Backend-Sektion.
Ich habe an 2 Vorträgen teilgenommen — von Nikolai Swertschkow (Evil Martians), ebenfalls über Serverless, und von Grigori Koschelew (Firma Kontur) über Telemetrie.
Serverless für einfache Sterbliche.
Während Ruslan Sirkin erklärte, was Serverless ist, zeigte Nikolai einfache Anwendungen mit Serverless und erläuterte die Details, die die Kosten und die Geschwindigkeit der Anwendungen in AWS Lambda beeinflussen.
Interessante Detail: Das kleinste bezahlte Element — 128 Mb RAM und 100 ms CPU, kostet 0,000000208$. Dabei sind 1 Million solcher Anfragen pro Monat kostenlos.
Einige Funktionen bei Nikolai überschritten häufig das Limit von 100 ms (die Hauptanwendung war in Ruby geschrieben), daher brachte das Neuschreiben in Go eine hervorragende Einsparung.
Vostok Hercules – mache Telemetrie wieder großartig!
Der letzte Bericht der Backend-Sektion von Grigori Koschelew (Firma Kontur) über Telemetrie. Telemetrie sind Protokolle, Metriken, Anwendungstraces.
Kontur verwendet dafür selbstgeschriebene Tools, die auf Github veröffentlicht sind. Das im Bericht erwähnte Tool ist Hercules, , das zur Übertragung von Telemetriedaten verwendet wird.
Im Bericht von Wladimir Lila in der Devops-Sektion wurde die Speicherung und Verarbeitung von Protokollen in Elasticsearch behandelt, aber es gibt auch die Aufgabe, Protokolle von Tausenden von Geräten und Anwendungen zu liefern, und dafür werden Tools wie Vostok Hercules eingesetzt.
Kontur hat den für viele bekannten Weg von RabbitMQ zu Apache Kafka beschritten, aber es war nicht so einfach. Sie mussten Zookeeper, Cassandra und Graphite in das Schema aufnehmen. Informationen zu diesem Bericht kann ich nicht vollständig enthüllen (nicht mein Fachgebiet), wenn es interessiert – man kann auf die Folien und Videos auf der Website der Konferenz warten.
Wie im Vergleich zu anderen Konferenzen?
Ich kann sie nicht mit den Konferenzen in Moskau und St. Petersburg vergleichen, ich kann sie mit anderen Veranstaltungen im Ural und dem 404fest in Samara vergleichen.
Die DAMP wird in 8 Sektionen durchgeführt, das ist ein Rekord für Ural-Konferenzen. Sehr große Sektionen Wissenschaft und Management, das ist auch ungewöhnlich. Das Publikum in Ekaterinburg ist ziemlich strukturiert – in der Stadt gibt es große Entwicklungsabteilungen von Yandex, Kontur, Tinkoff, das hinterlässt auch einen Eindruck auf die Berichte.
Ein weiterer interessanter Punkt – viele Unternehmen haben gleich 3–4 Referenten auf der Konferenz (so war es bei Kontur, Evil Martians, Tinkoff). Viele von ihnen waren Sponsoren, aber die Berichte waren durchaus auf dem Niveau anderer, es sind keine Werbeberichte.
Gehen oder nicht gehen? Wenn Sie im Ural oder in der Nähe leben, haben Sie die Möglichkeit und interessante Themen – ja, natürlich. Wenn Sie an einer weiteren Reise denken – ich würde die Themen der Berichte und die Videos der Berichte aus den vergangenen Jahren anschauen und eine Entscheidung treffen.
Ein weiterer Vorteil von Konferenzen in den Regionen ist, dass man in der Regel leicht nach den Berichten mit dem Referenten sprechen kann, es gibt einfach weniger Interessenten für ein solches Gespräch.
Danke an DAMP und Ekaterinburg! )
Quelle: habr.com
