In der letzten Woche war ich auf der IT-Konferenz DUMP (https://dump-ekb.ru/) in Jekaterinburg und möchte berichten, worüber in den Sektionen Backend und Devops gesprochen wurde und ob regionale IT-Konferenzen beachtenswert sind.
Nikolai Swertschkow von Evil Martians über Serverless
Was gab es dort überhaupt?
Die Konferenz hatte insgesamt 8 Sektionen: Backend, Frontend, Mobile, Testing und QA, Devops, Design, Science und Management.
Die größten Säle hatten übrigens Science und Management, jeweils für etwa 350 Personen. Backend und Frontend waren nur wenig kleiner. Der Devops-Saal war der kleinste, aber sehr aktiv.
Ich habe Vorträge in den Sektionen Devops und Backend gehört und mich ein wenig mit den Referenten unterhalten. Ich möchte über die behandelten Themen berichten und einen Überblick über diese Sektionen auf der Konferenz geben.
In den Sektionen Devops und Backend traten Vertreter von SKB-Kontur, DataArt, Evil Martians, dem Jekaterinburger Webstudio Flag, Miro (RealTimeBoard) auf. Die Themen umfassten CI/CD, Arbeit mit Warteschlangendiensten, Logging; besonders gut wurden die Themen Serverless und die Arbeit mit PostgreSQL in Go behandelt.
Außerdem gab es Vorträge von Avito, Tinkoff, Yandex, Jetstyle, Megafon, 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 2 Wochen auf dump-ekb.ru hochzuladen).
Devops-Sektion
Was überraschend war – die Sitzung fand im kleinsten Raum mit etwa 50 Plätzen statt. Die Leute standen sogar in den Gängen 🙂 Ich werde von den Vorträgen berichten, die ich hören konnte.
Ein Petabyte schweres Elasticsearch
Die Sitzung begann mit dem Vortrag von Vladimir Lila (SKB-Kontur) über Elasticsearch bei Kontur. Sie haben einen recht großen und stark ausgelasteten Elasticsearch (~800 TB Daten, ~1,3 Petabyte unter Berücksichtigung der Redundanz). Elasticsearch für alle Dienstleistungen von Kontur ist einheitlich, besteht aus zwei Clustern (mit 7 und 9 Servern) und ist so wichtig, dass Kontur einen speziellen Elasticsearch-Ingenieur hat (nämlich Vladimir selbst).
Vladimir teilte auch seine Gedanken über die Vorteile von Elasticsearch und die Probleme, die es mit sich bringt.
Vorteile:
- Alle Logs an einem Ort, einfacher Zugriff darauf
- Speicherung von Logs über ein Jahr und ihre einfache Analyse
- Hohe Geschwindigkeit bei der Arbeit mit Logs
- Tolle Datenvisualisierung „out of the box“
Probleme:
- Nachrichtenbroker – ein Muss (bei Kontur erfüllt Kafka diese Rolle)
- Besonderheiten der Arbeit mit Elasticsearch Curator (gelegentlich hohe Last durch regelmäßige Aufgaben im Curator)
- Keine integrierte Authentifizierung (nur gegen separate, recht hohe Kosten oder als Open-Source-Plugins in unterschiedlichen Entwicklungsstadien für die Produktion verfügbar)
Die Bewertungen zu Open Distro for Elasticsearch sind durchweg positiv 🙂 Das Authentifizierungsproblem ist dort gelöst.
Woher kommt das Petabyte?Ihre Knoten bestehen aus Servern mit 12*8 TB SATA + 2*2 TB SSD. Cold Storage auf SATA, SSD nur für warmen Cache (Hot Storage).
7+9 Server, (7 + 9) * 12 * 8 = 1536 TB.
Ein Teil des Speicherplatzes ist als Reserve eingeplant, um Redundanz usw. zu gewährleisten.
In Elasticsearch werden Logs von etwa 90 Anwendungen gesendet, einschließlich aller Berichtsdienste von Kontur, Elba usw.
Besonderheiten der Entwicklung mit Serverless
Im Folgenden die Präsentation von Ruslan Serkin von DataArt über Serverless.
Ruslan sprach darüber, was Serverless-Entwicklung im Allgemeinen bedeutet und welche Besonderheiten sie aufweist.
Serverless ist ein Entwicklungsansatz, bei dem Entwickler in keiner Weise mit der Infrastruktur in Berührung kommen. Beispiel: AWS Lambda Serverless, Kubeless.io (Serverless innerhalb von Kubernetes), Google Cloud Functions.
Eine ideale Serverless-Anwendung ist einfach eine Funktion, die über ein spezielles API Gateway an den Serverless-Anbieter Anfragen sendet. Der ideale Microservice wird dabei von einer Vielzahl moderner Programmiersprachen unterstützt, die in AWS Lambda verfügbar sind. Die Kosten für die Unterstützung und Bereitstellung der Infrastruktur sind bei Cloud-Anbietern praktisch null, während die Unterstützung kleiner Anwendungen ebenfalls sehr kostengünstig ist (AWS Lambda – 0,20 $ / 1 Million einfacher Anfragen).
Die Skalierbarkeit eines solchen Systems ist nahezu perfekt – der Cloud-Anbieter kümmert sich selbst darum, und Kubeless skaliert automatisch innerhalb des Kubernetes-Clusters.
Es gibt jedoch Nachteile:
- Die Entwicklung großer Anwendungen wird komplexer.
- Es gibt Schwierigkeiten bei der Profilerstellung von Anwendungen (es sind nur Protokolle verfügbar, aber kein klassisches Profiling).
- Es gibt keine Versionierung.
Um ehrlich zu sein, habe ich vor einigen Jahren zum ersten Mal von Serverless gehört, aber all die Jahre war mir nicht klar, wie ich es richtig anwenden kann. Nach dem Vortrag von Ruslan begann ich zu verstehen, und das Verständnis wurde nach der Präsentation von Nikolai Sverchkov (Evil Martians) aus der Backend-Sektion gefestigt. Der Besuch der Konferenz hat sich auf jeden Fall gelohnt 🙂
CI für Niedrigbudget-Lösungen: Sollte man ein eigenes CI für eine Webagentur entwickeln?
Mikhail Radionov, Leiter der Webagentur Flag aus Jekaterinburg, berichtete über seine maßgeschneiderte CI/CD-Lösung.
Seine Agentur hat den Weg vom „manuellen CI/CD“ (SSH auf den Server, git pull durchführen, das 100 Mal am Tag wiederholen) zu Jenkins und einem individuellen Tool namens Pullkins beschritten, das es ermöglicht, den Code zu überwachen und Releases durchzuführen.
Warum war Jenkins nicht ideal? Es bot nicht genug Flexibilität und war bei der Anpassung schlichtweg zu kompliziert.
„Flag“ entwickelt mit Laravel (PHP-Framework). Bei der Erstellung ihres CI/CD-Servers nutzten Mikhail und seine Kollegen die integrierten Mechanismen von Laravel, genannt Telescope und Envoy. Dadurch entstand ein PHP-Server (bitte beachten), der eingehende Webhook-Anfragen verarbeitet, Frontend- und Backend-Bauten durchführt, auf verschiedene Server bereitstellt und in Slack Bericht erstattet.
Um die Möglichkeit zu schaffen, Blue/Green Deployments durchzuführen und einheitliche Einstellungen in den dev-, stage- und prod-Umgebungen zu haben, wechselten sie zu Docker. Die Vorteile blieben die gleichen, es kamen Möglichkeiten zur Vereinheitlichung der Umgebung und nahtlosen Bereitstellung hinzu, was jedoch auch die Notwendigkeit mit sich brachte, Docker für eine ordnungsgemäße Nutzung zu erlernen.
Wie wir die Anzahl der Rollbacks von Server-Releases um 99% reduziert haben
Der letzte Bericht in der DevOps-Sektion wurde von Viktor Jeremtschenko, Lead DevOps Engineer bei Miro.com (ehemals RealTimeBoard), gehalten.
Das Herzstück von RealTimeBoard, dem Hauptprodukt des Miro-Teams, ist eine monolithische Anwendung in Java. Diese ohne Ausfallzeiten zu bauen, zu testen und bereitzustellen, ist eine herausfordernde Aufgabe. Es ist wichtig, eine Version des Codes bereitzustellen, die nicht zurückgerollt werden muss (da es sich um einen schweren Monolithen handelt).
Auf dem Weg zur Schaffung eines Systems, das dies ermöglicht, hat Miro einen Weg eingeschlagen, der Arbeit an der Architektur, den verwendeten Werkzeugen (Atlassian Bamboo, Ansible usw.) und der Teamstruktur umfasst (sie haben jetzt ein dediziertes DevOps-Team sowie viele separate Scrum-Teams mit Entwicklern unterschiedlicher Profile).
Der Weg war mühsam und steinig, und Viktor teilte die gesammelten Schmerzen und den dabei vollzogenen Optimismus.
Gewann ein Buch für Fragen
Backend-Sektion
Ich habe zwei Vorträge verfolgt — von Nikolai Swertschnkow (Evil Martians), ebenfalls über Serverless, und von Grigori Koshelew (Firma Kontur) über Telemetrie.
Serverless für normale Sterbliche
Während Ruslan Sirkin über Serverless sprach, zeigte Nikolai einfache Anwendungen mit Serverless und erklärte Details, die die Kosten und Geschwindigkeit der Anwendungen in AWS Lambda beeinflussen.
Eine interessante Tatsache: Das kleinste kostenpflichtige Element sind 128 Mb RAM und 100 ms CPU, das kostet 0,000000208 $. Gleichzeitig sind 1 Million solcher Anfragen pro Monat kostenlos.
Einige Funktionen von Nikolai überschritten oft das Limit von 100 ms (die Hauptanwendung war in Ruby geschrieben), deshalb führte die Umstellung auf Go zu erheblichen Einsparungen.
Vostok Hercules – Telemetrie neu definieren!
Der letzte Vortrag der Backend-Sektion von Grigori Koschelew (Firma Kontur) handelte von Telemetrie. Telemetrie umfasst Protokolle, Metriken und Anwendungs-Trace.
Kontur nutzt dafür selbstentwickelte Werkzeuge, die auf Github veröffentlicht wurden. Das Werkzeug aus dem Vortrag – Hercules, , wird zur Übermittlung von Telemetriedaten verwendet.
Im Vortrag von Wladimir Lila in der DevOps-Sektion wurde die Speicherung und Verarbeitung von Protokollen in Elasticsearch behandelt, aber es gibt noch die Herausforderung, Protokolle von Tausenden von Geräten und Anwendungen zu liefern, die mit Tools wie Vostok Hercules gelöst wird.
Contur hat einen für viele bekannten Weg von RabbitMQ zu Apache Kafka durchlaufen, aber es ist nicht so einfach :) Sie mussten Zookeeper, Cassandra und Graphite in das Schema integrieren. Ich kann die Informationen zu diesem Vortrag nicht vollständig offenbaren (nicht mein Fachgebiet), aber bei Interesse kann man auf die Folien und das Video auf der Konferenzwebsite warten.
Wie im Vergleich zu anderen Konferenzen?
Ich kann nicht mit den Konferenzen in Moskau und Sankt Petersburg vergleichen; ich kann sie jedoch mit anderen Veranstaltungen im Ural und dem 404Fest in Samara vergleichen.
Die DAMP umfasst 8 Sektionen, das ist ein Rekord für Ural-Konferenzen. Besonders große Sektionen sind Wissenschaft und Management, das ist auch ungewöhnlich. Das Publikum in Jekaterinburg ist recht strukturiert – in der Stadt gibt es große Entwicklungsabteilungen von Yandex, Contur und Tinkoff, was auch die Vorträge beeinflusst.
Ein weiterer interessanter Punkt ist, dass viele Unternehmen gleich 3–4 Referenten auf der Konferenz haben (so war es bei Contur, Evil Martians und Tinkoff). Viele von ihnen waren Sponsoren, aber die Vorträge waren durchaus auf dem Niveau mit anderen, das sind keine Werbevorträge.
Gehen oder nicht gehen? Wenn Sie im Ural leben oder in der Nähe sind und Interesse an den Themen haben – ja, natürlich. Wenn Sie an einer weiteren Reise denken – ich würde mir die Themen der Vorträge und Videos aus den Vorjahren ansehen. und eine Entscheidung getroffen habe.
Ein weiterer Vorteil von Konferenzen in den Regionen ist in der Regel, dass es einfacher ist, nach den Vorträgen mit den Referenten zu sprechen, da es einfach weniger Interessierte für Gespräche gibt.
Danke an DUMP und Jekaterinburg! )
Quelle: habr.com
