Wie acht Personen ein Hochlastprojekt skalieren. Unsplash-Erfahrung

Foto: Alex Smith | Unsplash

Guten Tag!

Mein Name ist Victor Pryazhnikov, ich arbeite in der Feature-Abteilung von Badoo . Die Hauptaufgabe unserer Abteilung besteht darin, die Funktionen zu entwickeln, die Benutzer unserer Website und Anwendungen sehen. Als ich auf einen Artikel von Luke Chesser, Mitbegründer von Unsplash, stieß, faszinierte sie mich, dass es ihnen gelingt, ein relativ großes Projekt mit einem sehr kleinen Team zu entwickeln. Der Ansatz des Autors beeindruckt mich mit seinem Pragmatismus und hat mich irgendwie daran erinnert, dass Sie nicht Google sind. Deshalb habe ich beschlossen, ihn zu übersetzen.

Eines der lustigsten Dinge in der Unsplash-Entwicklung ist die Größe und Beliebtheit des Produkts.

An einem typischen Tag verarbeitet unsere API mehr als 10 Millionen Anfragen von unsplash.com und Tausenden von Anwendungen von Drittanbietern, Millionen von Ereignissen durchlaufen unsere Datenverarbeitungspipeline, 60 Millionen Updates werden zu unseren Feeds hinzugefügt und wir liefern 60 Millionen Bilder.

Gleichzeitig ist unser Team relativ klein: zwei Designer, drei Personen, die mit dem Frontend arbeiten, zwei mit dem Backend und ein Dateningenieur. Wir haben keinen separaten DevOps-Ingenieur, und jedes Teammitglied verbringt die meiste Zeit damit, neue Funktionen zu experimentieren und zu entwickeln, um die weitere Entwicklung des Produkts sicherzustellen.

Obwohl wir mit Unsplash bereits viel erreicht haben, stehen wir noch am Anfang seiner Reise als Produkt und Unternehmen. Wir müssen noch etwas beweisen, und dies bedeutet, dass sich das gesamte Team auf die Lösung von Problemen konzentrieren muss, die nur bei Unsplash auftreten, und nicht auf die Probleme, die ein anderes Unternehmen hat, wie das Organisieren von Berechnungen, die Netzwerksicherheit, das Erstellen von Infrastrukturen und das Verwalten Abhängigkeiten usw.

In den letzten drei Jahren haben wir eine Reihe von Grundsätzen entwickelt, die es uns ermöglichen, uns auf Wachstum zu konzentrieren und Skalierungsprobleme zu vermeiden. Unglücklicherweise für diejenigen, die nach einer Silberkugel suchen, wird sie nicht hier sein: Es ist nur gesunder Menschenverstand und eine Reihe von Prinzipien, die wir von anderen entlehnt haben.

1. Verwenden Sie langweilige offensichtliche Lösungen

Oder sei pragmatisch.

Bevor Sie mit der Einführung eines neuen Tools, einer Datenbank (RethinkDB, RocksDB usw.), eines neuen Musters („Alles ist funktionsfähig!“) Oder einer neuen Architektur („Microservices, Hilfe!“) Beginnen, probieren Sie alle offensichtlichen Optionen aus.

Auf der Backend-Seite gibt es nur sehr wenige Probleme, die mit bekannten Standardwerkzeugen und bewährten Mustern wie Caching, Stapelverarbeitung, asynchroner Verarbeitung und vorläufiger Aufbereitung der erforderlichen Daten nicht effektiv gelöst werden können.

2. Konzentrieren Sie sich auf die Lösung von Benutzerproblemen, nicht auf Technologie

Unsplash ist ein Produkt, kein Technologieunternehmen. Wir haben viel Geld von Investoren erhalten, um uns auf die Lösung der Probleme unseres Produkts und des Marktes zu konzentrieren, anstatt zu versuchen, die Betriebskosten für den Einsatz gemeinsamer Technologien um drei Prozent zu senken.
Wir verbringen unsere Zeit damit, vorgefertigte Technologien so einzusetzen, dass die Probleme unserer Benutzer gelöst und die Unsplash-Community erweitert werden. Dies sind Aufgaben, die nur für Unsplash gelten. Wenn es uns gelingt, etwas Neues und Wertvolles zu schaffen, können wir die Optimierung auf einen späteren Zeitpunkt verschieben, wenn diese 3% -Optimierungen zur Hauptwachstumsquelle werden können.

Unsere potenziellen Kollegen, die von der Größe von Unsplash und einem kleinen Team, der Verwendung von Bildern und künstlicher Intelligenz sowie zukünftigen Funktionen erfahren haben, sind möglicherweise verwirrt darüber, dass wir viele sofort einsatzbereite Technologien, Dienste und Frameworks verwenden. Dies bringt uns dazu, im Moment etwas mehr zu zahlen, aber es ermöglicht uns, die interne Entwicklung dieser Technologien für einige Zeit zu verschieben und sie auf die Schultern unserer zukünftigen Kollegen zu verlagern.

Das Auslegen des Codes, das Konfigurieren von Servern, Systemabhängigkeiten, die Datenverarbeitung und -analyse, die Bildverarbeitung und die Personalisierung sind Beispiele für Bereiche, in denen wir uns nicht auf unsere technischen Ressourcen konzentrieren, sondern für jeden von ihnen vorgefertigte Dienste von Drittanbietern verwenden.

3. Geben Sie Geld für die Lösung technologischer Probleme aus

Die Kehrseite des Fokus auf Produktprobleme sind die zusätzlichen Kosten für den Zugang zu Standardtechnologien und Diensten von Drittanbietern.

Es wurde ein Witz in unserem Team. Sie sagen, dass meine erste Reaktion auf ein Problem die Frage sein wird: "Haben Sie versucht, es mit Geld zu lösen?". Aber das ist kein Scherz, sondern einer meiner Lieblingsansätze zur Lösung von Problemen.

Die Optimierung der mit Infrastruktur und Technologie verbundenen Kosten ist bei einfachen und sich wiederholenden Lösungen ein so häufiges Problem, dass sich kein Produktunternehmen mit Investoren darum kümmern sollte, bis es das Gefühl hat, dass das Wachstum der Hauptmetrik nicht mehr seine Priorität hat.

Wenn wir Geld für die Lösung technologischer Probleme ausgeben, lösen wir die Hände des Teams, damit es sich auf wiederkehrende komplexe Probleme konzentrieren kann, z. B. die Suche nach einer Möglichkeit, die Benutzerbasis im laufenden Quartal um 40% zu vergrößern.

---

Das sind also drei ziemlich einfache, aber abstrakte Prinzipien, denen wir folgen.

Aber wie sehen sie in der Praxis aus?

Wenn Sie sich die Unsplash-Architektur ansehen, werden Sie feststellen, dass sie sehr einfach und fast langweilig ist (zumindest nach den Standards von 2017).


Ein vereinfachtes Diagramm der Hauptteile, aus denen Unsplash besteht

Wo immer möglich verwenden wir Heroku , um das Layout, die Konfiguration, das Testen, den Support und die Skalierung unserer Kernanwendungen zu vereinfachen. Heroku ist eine Art Magie, die die Teile der Anwendung und den Entwicklungsprozess voneinander trennt, sodass unsere Teammitglieder nicht damit vertraut sein müssen, um Experimente zu entwickeln und zu gestalten.

Wir minimieren aggressiv die Menge an Code, die wir für die Geschäftslogik der Anwendung schreiben (violette Bereiche im Bild). Beim Schreiben verwenden wir aktiv Frameworks, die von anderen Personen erstellt wurden, die als Experten auf ihrem Gebiet Lösungen entwickelt haben, die in 95% unserer Anwendungsfälle erfolgreich funktionieren.

Wir setzen Redis, Elasticsearch und Postgres aktiv in der Produktion ein. In der Vergangenheit haben wir andere Datenbanken ausprobiert, sind aber immer zu diesen drei zurückgekehrt, da wir sicher sind, dass wir verstehen, wie sie sich unter Last verhalten.

Wir verwenden auch aktiv Task-Warteschlangen und verarbeiten viele Vorgänge asynchron, z. B. das Aktualisieren, Aggregieren und Synchronisieren von Daten zwischen verschiedenen Quellen.

Für die Datenverarbeitung verwenden wir Snowplow , ein in Scala geschriebenes offenes integriertes Framework, bei dem unser Team nicht mehr über die Organisation des Ein- und Ausstiegs nachdenken muss und nicht über die Verarbeitung selbst.

Wir verwenden auch eine ganze Reihe von Cloud-Überwachungsdiensten wie Datadog , New Relic , Sentry und Logentries , anstatt unseren eigenen StatsD- oder ELK-Stack bereitzustellen und zu warten.

Wir haben das Hosting und die Infrastruktur für die Bereitstellung unserer Bilder an imgix ausgelagert , ein führendes Unternehmen für die Arbeit mit dynamischen Bildern. Wenn sie neue Funktionen hinzufügen, nimmt unser Team eine Änderung an der URL vor - und unsere Benutzer erhalten auch Zugriff auf diese Funktionen.

Wir zeichnen alle Aktionen unserer Benutzer im Stream- Service auf und nutzen ihre Erfahrung beim Erstellen und Optimieren hoch geladener persönlicher Bänder. Stream vereinfacht die Verarbeitung von Milliarden von Aktionen für uns und bietet eine einfache API zum Ein- und Aussteigen, die mit einer solchen Produktivität arbeitet, dass unser Team Monate oder sogar Jahre damit verbringen würde, diese selbst zu erstellen.

Wir trainieren keine Bilderkennungsalgorithmen selbst, sondern verwenden TinEye für die umgekehrte Bildsuche und Google Vision für die Bilderkennung und -klassifizierung .

Wir zeichnen alle Verhaltensereignisse in Vero auf , einer Plattform für die Arbeit mit Benachrichtigungen und Mailinglisten, mit der wir die Arbeit mit ihnen in die Hände unserer Kollegen übertragen können, die keine Entwickler sind. Sie selbst können Briefe mit einem hohen Grad an Personalisierung erstellen, basierend auf der komplexen Verwendung verfügbarer Daten zum Benutzerverhalten.

---

Gleichzeitig konzentrieren wir uns auf diejenigen Teile von Unsplash, die eine Verbesserung unserer Kernkompetenz bewirken können.

Im vergangenen Jahr haben wir unsere einzelne Ruby on Rails-Anwendung in die Rails-API, die Webanwendung Node.js + React, aufgeteilt und eine separate Datenanwendung erstellt, die alle unsere internen und Produktmetriken sammelt und verarbeitet.

Dadurch konnte unser Team Funktionen erstellen, die auf unserem alten Stapel, der nur aus Schienen bestand, fast unmöglich erschienen. Nachdem unser Team die Probleme und Technologien unserer Anwendungen geteilt hatte, hatte es auch die Möglichkeit, die besten Tools in jedem der Bereiche zu verwenden:

• Am Frontend verwenden wir React und Webpack zusammen mit einem kleinen Express-Server, um Server-Rendering- und Proxy-API-Anforderungen zu unterstützen. Wir haben die Tools unseres Frontend-Teams absichtlich nicht mit temporären Hacks wie React -Rails oder Webpacker an das Backend gebunden . Die JavaScript-Community veröffentlicht zweifellos die besten Tools für die Arbeit mit dem Frontend. Durch die direkte Arbeit mit JavaScript kann unser Team den Benutzern schnell hochwertige Funktionen bereitstellen.
  
• Im Backend verwendet unser Team weiterhin das beste Framework für die Entwicklung einfacher Webanwendungen: Rails. Das Ruby on Rails-Ökosystem bietet die besten Tools für die Funktionalität auf der Backend-Seite. Da dieses Framework weit verbreitet ist, wurde jedes Problem bereits von jemandem gefunden, dokumentiert, und mit hoher Wahrscheinlichkeit gibt es bereits eine Lösung dafür.
  
• Auf der Datenseite verwendet unser Team einen kleinen Express-Server, um die Datenverarbeitung zu sammeln und zu organisieren. Die Verarbeitung selbst findet in Snowplow statt, das im AWS-Cluster ausgeführt wird. Dort befinden sich vorgefertigte Images, die die Konfiguration und Bereitstellung vereinfachen. Auf diese Weise kann unser einziger Dateningenieur, Tim, den größten Teil seiner Zeit damit verbringen, Daten an Snowplow zu übertragen und die Ergebnisse von dort so abzurufen, dass andere Teammitglieder sie leichter verstehen und Einblicke erhalten.
  

Wir schreiben aktiv Tests , messen die Leistung mit Tools wie Scientist und Datadog, legen Änderungen in Form von Experimenten fest und automatisieren die Arbeit mit unserer Infrastruktur so weit wie möglich.

Wir entwickeln eine neue interne API, die auf GraphQL basiert , um Iterationen von Experimenten, neuen Funktionen und Produkten zu beschleunigen, die nicht voneinander abhängig sind, da wir festgestellt haben, dass unsere REST-basierte API ohne ein hohes Maß an Koordination zwischen Daten-, Design-, Front-End- und Back-End-Teams ausfällt - besser Wir werden diese Zeit für Funktionen verwenden, nicht für JSON-Änderungen.

Obwohl es interessant ist, an diesen Änderungen zu arbeiten, nehmen wir sie nicht vor, weil wir den Juckreiz unseres Programmierers stillen möchten, sondern weil dies unsere wirklichen Probleme löst, die uns daran hindern, schnell Funktionen bereitzustellen und zu entwickeln.

Ich denke, dass die meisten Leute, die bis zu diesem Ort gelesen haben, eine von drei Schlussfolgerungen im Kopf haben:

1. Unsplash ist sehr einfach, daher können Sie diesen Ansatz verwenden. Was ich mache, ist viel komplizierter, deshalb sind wir gezwungen, die Dinge anders zu machen.
   
2. Ich bin ein Entwickler. Es klingt sehr langweilig - ich möchte ein neues Bilderkennungssystem mit hoher Last erstellen!
   
3. Cool! Es ist mir egal, gib mir einfach schöne kostenlose Fotos , die ich verwenden kann.
   

Leute mit der Schlussfolgerung Nummer 1, Sie haben Recht: Es gibt Unternehmen, die viel komplexere Dinge tun als wir. Aber es gibt nicht viele von ihnen. Wir alle erstellen dieselben Systeme, konzentrieren uns jedoch auf einige andere Dinge. Aus diesem Grund können die verwendeten Lösungen in Form von Frameworks abstrahiert und in verschiedenen Projekten wiederverwendet werden (daher sind die meisten Stellen zum Thema Einstellung einander so ähnlich).

Menschen mit der Schlussfolgerung Nummer 2, es kommt darauf an, was Sie interessant finden. Wenn Sie die Grenzen der Technologie erweitern möchten, arbeiten Sie für ein Unternehmen, dessen Mission es ist, dies zu tun. Es gibt nicht viele von ihnen, aber die meisten anderen Unternehmen tun dies einfach nicht.

Zu Leuten mit der Schlussfolgerung Nummer 3 werde ich sagen: "Ja, das ist richtig!" Letztendlich ist es das, wofür wir das alles tun.

Badoo steht den Prinzipien nahe, über die der Autor spricht. Der Hauptunterschied besteht darin, dass unser Projekt viel größer ist und die Nutzung externer Dienste für uns oft sehr teuer ist. Darüber hinaus sind viele unserer Lösungen sehr einfach und wir versuchen, ihre Änderungen sorgfältig anzugehen, indem wir die Kosten für die Einführung und den Betrieb einer neuen Technologie mit den Vorteilen vergleichen, die wir daraus ziehen werden. Einige unserer Lösungen sind ziemlich altmodisch, da sie vor einiger Zeit entwickelt wurden, aber der Übergang zu ähnlichen neuen Lösungen nur aus Gründen der Mode wird sich nicht für die dafür aufgewendeten Ressourcen auszahlen. Gleichzeitig sind wir bereit, neue Technologien einzuführen, wenn wir verstehen, dass sie echte Vorteile bringen können (z. B. PHP 7 , Go , Cassandra , Tarantool , Exasol ).