У світі, де цифрові дані є новою нафтою, а їх збереження – критично важливим завданням, іноді найнесподіваніші речі можуть спричинити справжній хаос. Ніхто б і не подумав, що крихітне анімоване GIF-зображення, що важить всього 1,6 мегабайта, може роздути резервні копії до астрономічних 377 гігабайтів, виводячи з ладу цілі файлові системи та роблячи збереження даних абсолютно безглуздим. Саме така курйозна, але вельми показова історія трапилася з однією з платформ, яку обслуговує компанія Discourse.
В епіцентрі цієї цифрової драми опинився той самий невгамовний GIF з “Друзів”, де Дженніфер Еністон енергійно танцює, демонструючи свою “щасливу” реакцію. Це зображення, завдяки надмірному ентузіазму користувачів та, що важливіше, специфічній “політиці безпеки” Discourse, розмножилося неймовірні 246 173 рази всередині резервних копій. Уявіть собі: один невинний, на перший погляд, файл перетворився на гігантську, потворну копію самого себе, поглинувши обсяг, що еквівалентний сотням тисяч фотографій або цілій бібліотеці фільмів.
Компанія Discourse, яка стоїть за однією з найпоширеніших платформ для онлайн-спільнот і на сьогодні живить понад 22 000 форумів та чатів по всьому світу, має функцію так званих “захищених завантажень”. Ця функція, яка, начебто, мала б підвищувати безпеку, діє досить своєрідно. Вона створює абсолютно нову копію файлу з унікальним ідентифікатором щоразу, коли зображення переміщується між різними “контекстами безпеки” – наприклад, з особистого повідомлення до загальнодоступного допису. Зміст файлу залишається тим самим, але для системи це вже зовсім інший файл, що й призводить до неконтрольованого розмноження.
Перша спроба розробників Discourse вирішити цю проблему з “інфляцією” даних полягала у використанні так званих “жорстких посилань” під час резервного копіювання. Замість того, щоб копіювати кожен дублікат файлу окремо, система мала створювати посилання на єдиний оригінал. Це звучало як елегантне та ефективне рішення, обіцяючи значну економію місця. Проте, як часто буває у складному світі технологій, реальність виявилася дещо іншою.
Здавалося б, геніальний план наразився на неочікувану перешкоду – обмеження файлової системи EXT4, що є стандартом для багатьох Linux-систем. Вона дозволяє створити лише близько 65 000 “жорстких посилань” на один файл. Коли справа дійшла до сотень тисяч дублікатів GIF, система просто відмовилася далі створювати посилання. Замість очікуваного одного завантаження для всіх 246 173 копій, Discourse отримав одне завантаження і ще приблизно 181 000 “запасних” завантажень, що спрацьовували після досягнення ліміту. Очевидно, це не було тією “перемогою”, на яку розробники розраховували.
Масштаби проблеми підкреслював і інший випадок з клієнтом Discourse, де із загальних 432 гігабайтів завантажених файлів лише 26 гігабайтів були унікальним контентом. Решта – це були лише дублікати, які призвели до 16-кратного роздування загального обсягу даних. Це яскраво демонструє, як на перший погляд невинна функція може призвести до колосального марнотратства ресурсів та потенційних збоїв. Сайт, де GIF з Рейчел з “Друзів” став причиною такого лиха, був, очевидно, дуже “щасливим”, оскільки зображення використовувалося “постійно в дописах, приватних повідомленнях, скрізь”.
На щастя, компанія Discourse таки спромоглася знайти вихід із ситуації та запропонувала нове рішення для своєї первісної “латки”. Цей оновлений механізм також починає зі створення “жорстких посилань”, але коли файлова система сигналізує про помилку “занадто багато жорстких посилань” (EMLINK), система просто копіює файл локально і розглядає цю нову копію як “основну”, доки не досягне ліміту знову. Розробники з деяким задоволенням заявляють, що це рішення “працює на будь-якій файловій системі і не потребує додаткових налаштувань”. Звісно, після того, як їм довелося навчитися на власних помилках, доведений до стресу інфраструктурою, яку, як виявилося, може вивести з рівноваги навіть танцююча Дженніфер Еністон.
