„Hier gibt es keinen Chef“: Über die Arbeit mit Open Source und Apache Ignite in Sberbank Technologies

Bei den Worten "Open Source" scheinen viele entweder ein Enthusiast zu sein, der sich abends für ihr Lieblingsprojekt engagiert, oder ein kleines Unternehmen, das Geld verdient, indem es ein offenes Produkt unterstützt. Aber wenn Sie nur an sie denken, werden Sie ein wichtiges und interessantes Segment der Community vermissen. Früher schienen die Wörter "Unternehmen" und "Open Source" Antonyme zu sein, jetzt nutzen große Unternehmen OSS-Projekte nicht nur aktiv, sondern sie selbst werden dazu beitragen.

Im Laufe der Zeit war Sbertech zunehmend in der OSS-Community aktiv, und wir haben beschlossen, sie danach zu fragen. Wie verbindet sich strenge Bankenspezifität mit dem Open-Source-Geist der Freiheit? Welche Anforderungen an Open Source haben andere Unternehmen möglicherweise nicht? Gibt es Mitarbeiter in Sbertech, die Open Source als Hauptarbeitsaufgabe schreiben? Was sind deine Pläne und Wünsche für die Zukunft? Anton Churaev , der Free & Open Source beaufsichtigt, erzählte uns von all dem und mehr.



Oleg: Hallo Anton. Lassen Sie uns Ihnen die Chabrowiten ein wenig vorstellen. Erzähl über dich: Wer bist du, was machst du?

Anton: Ich bin ein Ingenieur, der sich jedoch nur in seiner Freizeit entwickelt. Jetzt baue ich Sbertech-Praktiken und -Kompetenzen für die Entwicklung und Anwendung von Free & Open Source-Produkten ein. Sie müssen verstehen, dass dies etwas andere Dinge sind.

- Ja, ich verstehe, ein paar Mal, als ich mit Stallman sprach, rief ich Free as Open an und hörte mir danach einen solchen Vortrag an, dass ich mich ein Leben lang daran erinnerte :-) Nun, wie ist Ihre Position?

- Kurator für die Entwicklung von Free & Open Source. Und Open Source Enthusiast :)

- Können Sie etwas mehr über die "Kompetenzen für die Implementierung von Open Source" entschlüsseln? Es klingt nach einer Art geheimem Wissen.

- Nur wenige Menschen stellen sich vor, was Open Source für Unternehmen bedeutet. Auf der einen Seite sind dies Innovationen und das Fehlen der Notwendigkeit, Waren zu entwickeln, sich auf die Wettbewerbsvorteile ihrer Produkte zu konzentrieren, sie wiederzuverwenden und Kosten zu senken. Oft sind dies Projekte, die tatsächlich zu Industriestandards geworden sind. Nehmen Sie das gleiche Hadoop - jeder weiß es, jeder weiß es, es ist seit langem ein Standard. Oder die gängigsten Datenbanken - die fünf wichtigsten sind drei Open Source-Produkte - MySQL, PostgreSQL und MongoDB.

Aber nur wenige Leute denken, dass die Verwendung von OpenSource viele versteckte Kosten verursacht. Das heißt nicht, dass wir etwas Open Source gefunden und alle unsere Probleme gelöst haben. Zum Beispiel gibt es große Fragen zur „Rechtshygiene“. Bei der Arbeit mit Hersteller-Software ist alles sehr klar: Ich habe eine Lizenz genommen, Sie arbeiten daran und nutzen den Support. Bei der Arbeit mit Open Source bleibt viel den Entwicklern und Benutzern überlassen. In diesem Fall sind rechtliche und rechtliche Fragen einer der ersten Punkte. Darüber hinaus gibt es in Russland Nuancen. Wenn auf der ganzen Welt das Konzept des geistigen Eigentums ziemlich weit entwickelt ist und jeder versteht, dass es sehr wichtig ist, dass es einen bestimmten Eigentümer gibt, dann hat sich in Russland historisch alles anders entwickelt. Hier sind wir nicht so vorsichtig und respektieren das geistige Eigentum, obwohl dies äußerst falsch ist. Und wenn Sie die „Hygiene“ der Verwendung von Open Source nicht gewährleisten können, können Sie die Qualität der Verwendung nicht sicherstellen.

- Kann ich klarstellen? Wie ist der rechtliche Status von GPL-Lizenzen in Russland? Beispielsweise erlaubt die GPL keine Änderungen der lokalen Gesetze und weist nicht auf territoriale Einschränkungen hin. Daher ist eine solche Vereinbarung nicht mit dem auf dem Gebiet der Russischen Föderation festgelegten Rechtssystem vereinbar, und dies ist sehr, sehr schlecht.

- Ich möchte Lizenzen nicht in bestimmte Zonen unterteilen. Die Sberbank ist ein globales Unternehmen, daher kann die Software sowohl in den USA als auch in der Europäischen Union eingesetzt werden. Und so wie ich es verstehe (ich bin kein Anwalt, aber nach bestem Wissen), sind wir im Falle eines Verstoßes gegen die Beschränkungen der Lizenzen des Urheberrechtsinhabers im Gebiet der USA beispielsweise nach den Gesetzen der USA verantwortlich. Vor diesem Hintergrund müssen Sie sehr vorsichtig sein, um Rechte zu sichern und die Anforderungen für das geistige Eigentum eines anderen zu erfüllen. Respektieren Sie die Autoren, die uns die Nutzung unserer Arbeit ermöglicht haben, wodurch wir Lösungen beschleunigt, optimiert, unsere Probleme gelöst und unseren Kunden letztendlich einen qualitativ hochwertigen Service geboten haben. Lassen Sie uns die Rechte und Anforderungen einhalten. Dies ist die erste Aufgabe.

- Und der zweite?

- Die zweite Aufgabe ist die Informationssicherheit. Es ist klar, dass die meisten Lizenzen einen Haftungsausschluss enthalten, der besagt, dass der Autor / Entwickler / Mitwirkende nicht für den möglichen Schaden verantwortlich ist, der durch den Betrieb dieser Software verursacht wird. Dies ist richtig, dies ist eine Verantwortung, die auf den Verbraucher übergeht und von ihm Reife erfordert. Alles ist nicht kostenlos.

Sie müssen für diese Verantwortung bezahlen und natürlich mit diesen Risiken umgehen. Dies können nicht alle Unternehmen. Wir haben eine sehr starke Abteilung für Informationssicherheit - wir haben Glück. Daher nehmen wir das Vorhandensein von Sicherheitslücken und bösartigem Code im Allgemeinen ernst. Jeder, der Open Source nutzen möchte, muss alle Risiken berücksichtigen - nicht nur rechtlich, sondern auch im Hinblick auf die Informationssicherheit.

- Welche Lizenzen mögen Sie?

- Akademisch.

- O! Lassen Sie uns genauer sein. Es gibt MIT / BSD usw. und es gibt Viren-Copyleft-Lizenzen wie Affero GPL. Welche davon?

- Gut. Sie können eine Lizenz nicht lieben oder nicht mögen. Das Produkt wurde für eine bestimmte Aufgabe hergestellt und wird auf eine bestimmte Weise verwendet. Bei der Verwendung von Open Source müssen Sie sicherstellen, dass Sie Ihr Produkt oder Ihre Dienstleistung bereitstellen, ohne die Rechte Dritter zu verletzen. In diesem Fall können Sie natürlich Copylefts (z. B. die GPL) verwenden, wenn Sie deren Verwendung sicherstellen, damit diese nicht gegen Einschränkungen und die Rechte anderer verstoßen. Natürlich gibt es weniger Schwierigkeiten bei der Verwendung von akademischen Lizenzen, einfach weil sie weniger Einschränkungen unterliegen und daher leichter zu befolgen sind. Kurz gesagt, ich nenne "akademisches" MIT, BSD, Apache usw.

- Okay, müssen sich normale Entwickler mit Informationssicherheit befassen? Oder ist es einer separaten Abteilung zugeordnet?

- Alle Entwickler müssen die Grundlagen der Informationssicherheit und die Prinzipien ihrer Sicherheit für ihre Systeme verstehen. In unserem Fall arbeiten wir jedoch mit einzelnen Entwicklern zusammen, die sich auf Bedrohungen der Informationssicherheit spezialisiert haben. Darüber hinaus wenden wir uns nicht nur der Analyse von Open Source-Produkten zu, sondern auch der Analyse von Algorithmen und Designlösungen.

"Es ist klar, dass diese speziellen Sicherheitskräfte alles wissen." Und was muss ein gewöhnlicher Entwickler in dieser Hinsicht wissen? Was sind die grundlegenden Punkte?

- Modell der Bedrohungen, Schutz der Kanäle, Datenschutz. Was ist anfällig für Bedrohungen: Möglicherweise handelt es sich um eine Benutzeroberfläche oder eine Datenübertragung über ein Netzwerk (alles wird mit uns verteilt, daher ist dies ein sehr wichtiges Thema). Grundlegende Tools wie Verschlüsselung, SSL, TLS, Authentifizierung, Autorisierung, Token-Behandlung usw. Sie müssen nicht viel wissen.

- Gerüchten zufolge haben Sie etwas mit Apache Ignite zu tun :-)

- In Bezug auf den Beitrag ist dies das Hauptprojekt, an dem ich gerade arbeite. Die Teilnahme an Apache Ignite gehört zu meiner zweiten Aufgabe - eine ausgewogene Investition in Free- und Open Source-Projekte sicherzustellen. Dies impliziert sowohl den kompetenten Einsatz von Produkten (es ist klar, dass der Einsatz von Bibliotheken eine Investition ist, wir als Benutzer erhöhen die Attraktivität des Produkts) als auch die Entwicklung und den Beitrag.

Für mich ist diese Aufgabe wahrscheinlich noch wichtiger. Wir würdigen die Produkte, die wir in unserem Unternehmen verwenden und dank denen wir viele Produkte und Systeme gebaut haben. Wir versuchen, sie zu verbessern und die Möglichkeit des Einsatzes in Unternehmen wie dem unseren sicherzustellen: zu optimieren, in einen Unternehmensstaat zu bringen.

Apache Ignite ist nicht das einzige Projekt, aber wir werden es sehr intensiv hineinschmuggeln, da eine der wichtigsten Plattformen in der Bank auf der Basis von Apache Ignite erstellt wird. Ignite ist ein verteiltes Computing-Grid, mit dem Sie Daten im Speicher speichern und verarbeiten können. Tatsächlich ist es die Grundlage für die IT-Landschaft unseres Unternehmens. Daher sind wir sehr an seiner Entwicklung interessiert.

- Viele Leute wissen, dass Sbertech GridGain verwendet, und Sie sprechen von Apache Ignite. Was ist der Unterschied zwischen den beiden?

- GridGain ist ein Open-Core-Produkt, das auf einem Open-Core-Produkt namens Ignite basiert. Und GridGain ist eine Reihe von Plug-Ins für diesen Kern, die Wartungs- und Betriebsverfahren vereinfachen und eine Reihe wichtiger Anforderungen an Informationssicherheit und Zuverlässigkeit stellen. Tatsächlich ist der Kern jedoch der wichtigste Teil, und mit Plugins können Sie all dies in einem echten Unternehmen nutzen. Und die Bank betreibt bereits GridGain.

- Da Ignite geöffnet ist, können Sie ein bisschen darüber sprechen, oder? Nutzen Sie es nur aus oder tun Sie etwas, um es zu beenden, interagieren Sie mit Entwicklern?

- Wir modifizieren es intensiv. Die Richtungen der Aufgaben sind klar definiert, um beispielsweise die Leistung unter Berücksichtigung der Besonderheiten der Sberbank sicherzustellen: groß angelegte Datenmengen, hohe operative Aktivität. Daher sollte es schnell und viel sein. Damit meine ich sowohl Latenz als auch Durchsatz.

Die zweite besteht darin, die Zuverlässigkeit sicherzustellen, d.h. Verfügbarkeit und Fehlertoleranz.

Drittens ist die betriebliche Effizienz, das TCO-Management. Angesichts der Größe der Sberbank führt bereits eine geringfügige Reduzierung des Ressourcenverbrauchs, beispielsweise von Festplatten um einen bestimmten Prozentsatz, auf unseren Skalen zu enormen Einsparungen.

Und die vierte ist die Aufgabe der Funktionsentwicklung. In der Tat ist die Hauptsache die Entwicklung von Schnittstellen und die Integration mit anderen Komponenten des Sberbank-Technologie-Stacks. Dies ist nützlich und wichtig für den Aufbau einer ausgereiften und integrierten IT-Architektur.

Separat besteht die Aufgabe darin, technische Schulden und Mängel (die immer bestehen) zu beseitigen. Dies ist wahrscheinlich auf die Zuverlässigkeit zurückzuführen.

- Lassen Sie uns diese Punkte zur Verdeutlichung durchgehen. Sie sagen, dass Sie daran arbeiten, Leistung, Latenz und Durchsatz zu verbessern, das ist alles. Die Frage ist - hat Ignite irgendwelche Probleme damit? Ich meine, gibt es etwas zu ändern oder ist es ein ideales Produkt?

- Nein, das Produkt kann nicht als ideal angesehen werden. In jeder Version fahren wir sowohl allgemeine Benchmarks als auch Mikrobenchmarks für bestimmte Komponenten. Wir arbeiten ständig an der Leistung - wir sollten hier nicht aufhören. Die Aufgabe ist schwierig, da die Komponenten und Lösungen bereits ziemlich straff sind und die Leistung fast an der Grenze des Eisens liegt. Dies erhöht die Komplexität, es gibt jedoch immer Raum für Verbesserungen. Wir haben verschiedene Anwendungsfälle, es erscheinen neue Benutzeraufgaben, in denen die Möglichkeit der Optimierung besteht. Optimieren Sie beispielsweise das Bandlaufwerk für die spezifische Art der Daten. Es gibt Aufgaben zur Optimierung der Netzwerkschicht, die wiederum von Einzelfällen abhängt. Deshalb müssen Sie immer am Puls der Zeit bleiben.

"Du hast gesagt, dass du einen Beitrag zur Gemeinschaft leisten würdest." Und all diese Entscheidungen über verschiedene Fälle und deren Optimierung sind eine Art Kompromiss. Wenn wir unsere Kompromisse eingehen und sie in die Gemeinschaft bringen, kann sich herausstellen, dass die Menschen in der Gemeinschaft leicht unterschiedliche Bedingungen und Prioritäten haben. Wie organisiere ich die Interaktion und kopiere trotzdem den Code, der für deine Fälle benötigt wird?

- Andere Kunden mit anderen Aufgaben. Es ist absolut richtig, dass dies ein Standardproblem ist. Es hängt alles von der Architektur der Lösung ab. Wenn die Lösung zum Beispiel die Möglichkeit beinhaltet, Plug-In-Erweiterungen, Plug-Ins und Bibliotheken für verschiedene Benutzerlösungen zu erstellen, können Sie aussteigen. Wenn beispielsweise ein Komparator vorhanden ist, kann der Benutzer jederzeit eine Lösung entwickeln, die diesen Komparator an die Eingabe weitergibt und das Problem basierend auf bestimmten Bedingungen löst. Auch hier sind die Funktionen sehr architekturabhängig. Es ist falsch, einfach grob für unsere Aufgabe zu codieren und zu formen, ohne an andere Kunden zu denken - solche Pull-Anfragen werden nicht überprüft.

Jeder versteht, was ein Open Source-Projekt ist, und im Allgemeinen können Sie es beeinflussen. Natürlich gibt es Gemeinschaften, in denen Unternehmen eindeutig präsent sind, die die Entwicklung in ihrem eigenen Interesse beeinflussen, aber wenn wir reines Open Source spielen, wird dies korrekt mit der Meritokratie (der Autorität der Würdigen) verglichen. Beweisen Sie, dass Ihre Entscheidung gut ist, und dann wird sie getroffen. Handeln, wie es in der geschlossenen Entwicklung oft der Fall ist, dh aus der Position "Ich bin der Chef, ich habe es gesagt", wird nicht funktionieren.

- Einer der interessantesten Fälle, die Sbertech öffentlich erzählte, ist die Single Semantic Layer. Eine große Datenmenge verteilt sich auf ein In-Memory-Raster. Wie hat sich dies auf den offenen Teil von Ignite ausgewirkt und wie interessant sind diese Entwicklungen für die Community?

- Ja, solche Entwicklungen sind im Gange und wir arbeiten sehr intensiv an Aufgaben, um Skalierbarkeit und Zugänglichkeit sicherzustellen. Wir haben Fälle gefunden, in denen das aktuelle Topologieverwaltungsschema nicht optimal ist, weil seine zeitliche Komplexität wächst aus der Anzahl der Knoten nicht ganz so, wie wir es möchten. Dies erschwert die Erreichung des Ziels etwas.

- Soweit ich mich erinnere, ist die Clusterarchitektur ein Ring. Das heißt, wenn wir uns dem Ring anschließen, gehen wir am Anfang zum Koordinator und dann entlang des Rings, bis wir den Schwanz finden. Und je mehr Elemente, desto mehr Zeit, richtig?

"Ja, irgendwie." Gleichzeitig nehmen mit zunehmender Anzahl von Knoten in der Topologie sowohl die Größe der Nachrichten, die entlang des Rings übertragen werden, als auch die Anzahl der Übergänge zwischen den Teilnehmern zu. Dies bedeutet nicht, dass ein Ring eine schlechte Entscheidung ist, aber in einigen Fällen passt er nicht. Daher schließen wir in der Community seit Ende 2017 die Topologieverwaltung ab, damit Benutzer ein Topologieverwaltungsschema auswählen können: einen Ring (manchmal passt er perfekt) oder einen Stern auf Zookeeper.

- Und woher kam der Ring? Warum ist es so Wo ist es perfekt?

- Dies ist eine wunderbare Lösung für die Topologien von 100-200 Knoten in einem Rechenzentrum. Ermöglicht es Ihnen, alle Knoten einfach und zuverlässig zu synchronisieren. Wenn wir zum Stern gehen, beginnen sie parallel und schneller zu arbeiten, aber gleichzeitig wird es viel schwieriger, sie zu synchronisieren. Das heißt, der Ring kann stabiler und zuverlässiger sein, stimmen Sie zu?

- Ja natürlich. Aber kann es so gemacht werden, dass diese Topologie durch einen Parameter in der Konfiguration geändert werden kann? Wie ist die Einstellung?

- Ja, wir machen es jetzt, wir nehmen beide Topologien in die Version auf. Wahrscheinlich decken die bereits vorgeschlagenen Implementierungen nicht alle Fälle von Benutzern ab, und sobald neue erscheinen, werden wir versuchen, deren effektive Verarbeitung sicherzustellen.

- Soweit ich weiß, ist dies eine ziemlich komplizierte Überarbeitung. Und diese Überarbeitung wird von Menschen in Sbertekh, während der Arbeitszeit oder abends zum Vergnügen durchgeführt?

- Dies wird von der Community durchgeführt, zu der auch PBT-Mitarbeiter gehören, deren Hauptaufgabe während der Arbeitszeit darin besteht, zu diesem Projekt beizutragen. Das Topologieproblem betrifft eine der Schlüssellösungen im Produktkern, sodass die Hauptlast auf die DiscoverySPI-Betreuer fiel. Ich hoffe jedoch, dass sich die Teilnahme unserer Entwickler auch positiv auf das Ergebnis ausgewirkt hat.

- Nun, das sind Leute, die ein Problem während der Arbeitszeit lösen, aber gleichzeitig Mitglieder der Gemeinschaft sind.

- Ja, der wichtigste Teil der Arbeit unserer Entwickler findet in der Community statt. Aber ich sehe auch von unseren Jungs solche Verpflichtungen, die in einer Stunde, zwei, drei Nächten auftraten.

- Und diese Mitarbeiter werden kein Problem damit haben, dass sie in einer Bank in einem geschlossenen System arbeiten und sich gleichzeitig für Open Source engagieren?

- Nein, das wird es nicht. Alle Teilnehmer sind offizielle Unternehmensmitarbeiter. Die Festlegung der Richtung und die Entscheidung über Investitionen wurden auf der Ebene der Unternehmensleitung getroffen, und ja, diese Gruppe engagierter Unternehmensmitarbeiter, die gemäß allen Unternehmens- und TC-Standards Open Source-Produkte im Interesse des Unternehmens entwickeln. Ja - dies ist Entwicklung und Open Source, ja - dies ist während der Arbeitszeit und auch außerhalb der Arbeitszeit, aber dies ist bereits der Fall, wenn die Community danach fragt.

- Wir haben gerade über einige externe Angelegenheiten gesprochen, über die die Community entscheidet. Aber höchstwahrscheinlich muss das Unternehmen seine eigenen Integrationen vornehmen, einige seiner Fälle verbessern ... Haben Sie viele eigene geschrieben? Oder ist es nur eine kleine Dopilka?

- In Bezug auf das Apache Ignite-Projekt belief sich unser Beitrag zum Projekt im letzten Quartal auf 8 bis 10 Prozent aller Änderungen, und wir bemühen uns, diesen Prozentsatz zu erhöhen. Wir haben viel geschrieben, und dies ist nicht nur die Entwicklung und Optimierung der vorhandenen Funktionalität, wir arbeiten auch an neuen Funktionen für das Projekt. Dies ist eine Herausforderung für die Gemeinschaft und Verantwortung für uns, da die Gemeinschaft nach ihrer Aufnahme in gewissem Maße die Aufgabe hat, sie zu unterstützen.

Aufgaben können nicht nur von der Community, sondern auch von Benutzern innerhalb des Unternehmens ausgeführt werden: Architekten, Entwicklungs- und Wartungsteams. Die Entwicklung des Projekts zu diesen Aufgaben wirkt sich auch erheblich auf das Produkt aus.

- Aber, sagen wir, es gab mehrere Berichte aus dem Sbertekh-Programm des PRPRB über sein "spezielles Feng Shui". Muss ich zusätzliche Tools und Administrationsseiten schreiben, um dies zu unterstützen?

- Die Schnittstellen für den Betrieb werden ständig weiterentwickelt. Die Verwaltungskonsole desselben Oracle ist vertrauter zu warten und verfügt über mehr Funktionen. Ob es vollständig reproduziert werden muss, ist eine andere Frage.

- Und in offener Form können Sie die Verwaltungskonsole sehen?

- Ja natürlich. Web Console veröffentlicht, Visor, CLI - alles ist öffentlich.

- Und wenn Sie es globaler betrachten, was sind die allgemeinen Richtungen und Ziele?

- Jetzt konzentrieren wir uns mehr auf die Entwicklung von Apache Ignite, das die Prioritäten des Unternehmens erfüllt. Aber unser technologischer Stack endet nicht dort. Open Source , , . , , . ( ), , . . , . . .

— , . - ?

— — , availability, durability, fault tolerance ..

— , .

— , — . , Open Source . . , .

— - , , ? , - , ceph?

— , ceph — . , , , .

— - ? ?

— OpenStack.

— , OpenStack — , . - , , ?

— OpenStack , , , Cloud Foundry, .

— ?

— :-) , ( ) . , — , , .

— .

— , - Open Source .

, . , , -.

— -?

— , , , -: , .. , , , , . . , Open Source, , , .

. , . -, , . . , , , .

, , ( -, , , ) — . , , , .

— .

— , . , «», , « , » «, ». , . , , . , , , . — , .

— , ? , … , , .

— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .

— ? ?

— , . , , – . — , ROI, .., .

— , - . , : , . , - Spring Hibernate, , , , . , , , . , .

— , , . , , . , , . , . , .