Jak Discrord przechowuje biliony wiadomości w swojej bazie? (film, 7 minut)
W tym filmie ByteByteGo omawia nie tylko migrację bazy danych, ale także ogromne zadanie, które podjęli inżynierowie Discord, przenosząc biliony wiadomości z jednej bazy danych do drugiej. Autor podkreśla, że to, co zajmuje taką niespotykaną skalę, jest fascynujące. Discord, który doświadczył poważnych problemów z wydajnością w używaniu Cassandry, zdecydował się na migrację do ScillaDB, szybszej i bardziej niezawodnej alternatywy. Tworzenie tego wpisu było możliwe dzięki informacjom publicznym i prezentacji Bo Ingrama na ScillaDB Summit 2023. Specyfika inżynieryjna Discord jest tu kluczowa, podkreślana przez innowacyjne podejście do skomplikowanych zadań. Kluczem do powodzenia było rozpoczęcie migracji od mniejszych baz danych, co umożliwiło zespołowi przetestowanie procesów. Zastosowali też nową warstwę pośrednią między monolitem API a bazą danych, wykorzystującą język Rust. Pomysł koalescencji żądań pomógł znacząco zmniejszyć obciążenie serwera.
Ważnym krokiem było stworzenie Superdysku, który łączył lokalne dyski SSD z Google Cloud's Persistent Disk. Zespół Discord starał się skupić na niskiej latencji przy odczycie danych, co miało kluczowe znaczenie dla wydajności systemu. Superdysk w połączeniu RAID 0 dla lokalnych SSD oraz RAID 1 dla Persistent Disk przyniósł pożądane efekty. Po zakończeniu przygotowań zespół przystąpił do migracji największej bazy danych – Cassandra Messages Cluster. Ten skomplikowany proces zajmował jedynie 9 dni, co jest imponujące, biorąc pod uwagę, że cała operacja odbyła się bez przestojów. Efekt to znacznie ciszej działający system przy zmniejszonej liczbie węzłów z 177 do 72.
Migracja produkcyjnej bazy danych do tak dużej skali jest nie lada wyzwaniem, ale dzięki innowacyjnym rozwiązaniom i dobrze przeprowadzonemu planowi Discord osiągnął wyjątkowy wynik. Zespół programistów jest niezmiernie dumny z tego, co udało im się osiągnąć, a film jest tego doskonałym podsumowaniem. Cała operacja pokazuje, jak ważne są odpowiednie strategie i zarządzanie ryzykiem w nowoczesnych systemach.
Z tego co wiadomo w momencie pisania tego artykułu, film zdobył 182,182 wyświetlenia oraz 7,214 „lajków”. Jeśli ktoś interesuje się inżynierią i rozwojem systemów, to z pewnością warto śledzić takie tematy. Dodam, że autor sugeruje również zapisanie się do newslettera, który porusza najnowsze trendy i tematy związane z dużymi systemami, cieszącym się zaufaniem 400,000 czytelników. Zapisz się na blog.bybygo.com, aby być na bieżąco z najnowszymi informacjami!
Toggle timeline summary
-
Wprowadzenie do ogromnego zadania migracji bazy danych, przed którym stanęli inżynierowie Discorda.
-
Przegląd migracji trylionów wiadomości z jednej bazy danych do drugiej.
-
Mówca dzieli się ekscytacją związaną z omówieniem migracji bazy danych od momentu dołączenia do Discorda.
-
Szczegóły dotyczące procesu migracji z Cassandry do ScillaDB, bardziej niezawodnej bazy danych.
-
Prezentacja Bo Ingrama na ScillaDB Summit 2023 dostarczyła informacji na temat migracji.
-
Początkowe wyzwania Discorda z problemami wydajnościowymi korzystającymi z Cassandry z powodu szybkiego wzrostu.
-
Wprowadzenie ScillaDB jako bazy danych kompatybilnej z Cassandrą, oferującej lepszą wydajność.
-
Dyskusja na temat ulepszeń, jakie oferuje ScillaDB, takich jak brak konieczności utylizacji pamięci.
-
Utworzenie warstwy pośredniej nazwanej Usługi Danych w celu poprawy interakcji z bazą danych.
-
Koncepcja Superdysku zaprojektowanego do radzenia sobie z wyzwaniami opóźnienia dysku podczas migracji.
-
Innowacyjne rozwiązanie Discorda polegające na priorytetowaniu odczytów dysków o niskiej intensywności w celu poprawy wydajności.
-
Udana implementacja technologii Superdysku w celu usprawnienia operacji bazy danych.
-
Szczegóły finalnej migracji klastra wiadomości z Cassandry w zaledwie 9 dni.
-
Wynikiem była bardziej wydajna system z mniejszą liczbą węzłów i poprawionym opóźnieniem.
-
Uznanie trudności i sukcesu migracji bazy danych produkcyjnej na dużą skalę.
-
Zaproszenie do subskrypcji newslettera o projektowaniu systemów dla bieżących informacji.
Transcription
In this video, we're going to discuss not just a database migration, but a colossal task Discord engineers took on, moving trillions of messages from one database to another. If you ever wonder what it takes to migrate data of such an unimaginable scale, you're going to love this. Let's dive right in. I've been eager to talk about this topic ever since I joined Discord. The engineering culture there is dynamic and innovative, and this story is a perfect illustration of that. Though this is all from public information, the insights and takeaways are my own. Discord recently peeled back the curtain on how they migrated trillions of messages from Cassandra, the database that housed your chats and conversations, to ScillaDB, a faster and more reliable alternative. The process was first shared at ScillaDB Summit 2023 by Bo Ingram, followed by a detailed blog post. A big shout out to Bo for presenting this complex process so clearly. So what did Bo share? I will summarize and share my own takeaways. You can watch his video and read his blog post if you want to learn more about it. Let's rewind back a few years. Discord found themselves in a bit of a pickle with their database choice. They were using Cassandra, but as the platform continued to grow, they faced serious performance issues. It took a lot of effort to maintain the main Cassandra cluster that held messages. The latency was unpredictable, and the frequent on-call incidents put huge strain on the team. By 2022, the Cassandra cluster held trillions of messages across 177 nodes. They knew they needed something different, but this message cluster was critical to Discord. If the message cluster is slow, Discord is going to be slow. If the message cluster is down, Discord is going to be down. Their solution? ScillaDB, a Cassandra-compatible database, but with a more powerful C++ base engine under the hood. Instead of jumping in headfirst to solve the riskiest and biggest problem, they started the migration with smaller databases. And this is my first takeaway. At Discord, the engineers move fast when mistakes are reversible. But if the solution is a one-way door, they spend a lot more time and care to get it right. They use these small migrations as an opportunity to test their waters and iron out as many issues as possible before tackling the big beast that held trillions of messages. Let's talk about ScillaDB. It was written in C++ and promised better performance, faster repairs, and most importantly, it was garbage collection-free. For a team that has so many issues with Cassandra's garbage collector, this was a breath of fresh air. The next key step was to create an intermediate layer between the API monolith and the database clusters. This layer is called Data Services. It was written in Rust, which is a safe and highly performance language. And it's a joy to write in Rust. The really cool idea about this layer is something called request coalescing. If multiple users request the same data, the database only needs to be queried once. This drastically reduced the potential for hot petitions. Imagine all those unintended add everyone messages in hugely popular Discord servers. With this layer in between, it is no problem for the database at all. Then they came up with the concept of a Superdisk, the database cluster run on Google Cloud. When faced with the challenges of disk latency, they couldn't rely on the local NVMe SSDs on the virtual machines for the critical data storage due to reliability and durability issues. The alternative was Google Cloud's Persistent Disk. While it was reliable and flexible, it had the disadvantage of higher latency since they were network-attached rather than directly attached. So what did Discord do? They went back to the drawing board and focused on creating a solution tailored to their specific needs. They chose to prioritize low-intensity disk reads over all other disk metrics while maintaining the existing database uptime guarantee. What they came up with was a Superdisk combining the best of local SSDs and Persistent Disk at the software level. Their Superdisk was a two-layer RAID solution. They used RAID 0 to combine multiple local SSDs into one low-latency virtual disk, and then RAID 1 to mirror this RAID 0 away with a Persistent Disk. They then configured the Linux kernel to direct the write to the Persistent Disk, which has a strong durability guarantee, and the read to the local SSDs, which offer low latency. This setup ensured low-latency reads from the local SSDs and write durability from the Persistent Disks. What's so great about this is an excellent example of problem-solving from first principles. Discord was dealing with a problem that had no ready-made solution. Instead of trying to make do with what was available, they redefined the problem based on their specific needs and then built a solution to match. The Superdisk worked. At peak low, the databases no longer started queuing up disk operations, and they saw no change in query latency. Finally, with all this prep work done, it was time to migrate their largest database, the Cassandra Messages Cluster. With trillions of messages and nearly 200 nodes, it was a daunting task. But with a newly written disk migrator in Rust and some clever strategies, they managed to do it in just 9 days. Yes, you heard it right, they migrated trillions of messages with no downtime in less than 2 weeks. And the payoff? A significantly quieter, more efficient system. It went from running 177 Cassandra nodes to just 72 ScalaDB nodes. It drastically improved latencies and the quality of life for the on-call staff. It was no ordinary task, but with clever risk mitigation and innovative solutions, they put it off. So there you have it. I am incredibly proud of what the team was able to pull off. Migrating a production database is no joke. And doing it at this scale, well, it is hard. If you like our videos, you may like our system design newsletter as well. It covers topics and trends in large-scale system design, trusted by 400,000 readers. Subscribe at blog.bybygo.com.