Cloudflare heeft een analyse gepubliceerd van een van de grootste incidenten in zijn infrastructuur, waardoor gisteren het merendeel van het content delivery netwerk meer dan 3 uur buiten werking was. De storing deed zich voor na een wijziging in de database-structuur die in ClickHouse was opgeslagen, waarna het bestand met parameters voor het bottegenstandsysteem verdubbelde in grootte. In de database ontstonden dubbele tabellen, terwijl de SQL-query die het bestand genereerde simpelweg alle gegevens uit alle tabellen op sleutel uitgaf, zonder duplicates te filteren. SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;
Het gemaakte bestand verspreidde zich over alle knooppunten van het cluster dat inkomende verzoeken behandelde. In de handler, die dit bestand gebruikte om te controleren op botverzoeken, werden de in het bestand aangegeven parameters in het geheugen opgeslagen en om overmatig geheugengebruik te voorkomen, was er een limiet ingesteld op de maximaal toegestane bestandsgrootte. Onder normale omstandigheden was de werkelijke bestandsgrootte veel smaller dan de ingestelde limiet, maar na het dupliceren van tabellen overschreed deze de limiet.
Het probleem was dat in plaats van de limiet correct te verwerken en de vorige versie van het bestand te blijven gebruiken met een melding naar het monitoringsysteem over de storing, het verwerkingsprogramma resulteerde in een noodstop, wat verdere verkeersdoorgifte blokkeerde. De fout werd veroorzaakt door het gebruik van de unwrap()-methode in Rust met het type Result.
Wanneer de waarde van Result de staat 'Ok' heeft, retourneert de unwrap()-methode het bij deze staat behorende object, maar als het resultaat niet succesvol is, leidt de aanroep tot een noodstop (de 'panic!'-macro wordt aangeroepen). Gewoonlijk wordt unwrap() toegepast tijdens het debuggen of bij het schrijven van testcode en het wordt niet aanbevolen voor gebruik in productieprojecten.
Bron: opennet.ru
