Рік без єдиного байта

Про автора. Арчі Рассел (Archie Russell) — інженер бекенду Flickr

Одна з найвитратніших статей в роботі сервісу зразок Flickr — це зберігання. За останні роки ми описували різні техніки для зниження вартості: використання COS динамічна зміна розміру на GPU і перцептивное стиснення. Ці проекти були дуже успішні, але ми продовжували втрачати багато грошей на зберіганні даних.

На початку 2016 року ми поставили перед собою завдання вийти на новий рівень — протриматися цілий рік взагалі не закуповуючи нові носії інформації. Використовуючи різні техніки, нам це вдалося.

Історія витрат
Невеликі арифметичні розрахунки на серветці показують, що витрати на зберігання являють собою предмет реального занепокоєння. В день з високою відвідуваністю користувачі Flickr завантажують до 25 млн фотографій. Кожна з них вимагає в середньому 3,25 МБ, що в сумі становить 80 ТБ. Наївно розміщуючи їх на хмарному хостингу начебто S3 фотографії одного дня потягнуть на $30 тис. на рік і продовжать генерувати витрати на кожен наступний рік.

У дуже великого сервісу понад 200 млн активних користувачів. З тисячею фотографій у кожного з них зберігання на хостингу начебто S3 обійдеться більш ніж в $250 млн у рік (або $1,25 на користувача) плюс мережеві та інші витрати. Все це накопичується по мірі реєстрації нових акаунтів, а існуючі користувачі роблять фотографії з зростаючою швидкістю. На щастя, наші витрати, а також витрати будь-якого великого сервісу, відрізняються від наївного зберігання на S3, але все одно залишаються значними.


Витрати на байт зменшилися, але розмір кожної фотографії з iPhone-подібних платформ виріс. Витрати на зображення значно не змінилися

Витрати на зберігання справді падають з часом. Наприклад, розцінки S3 знизилися з $0,15 за гігабайт на місяць у 2009 році до $0,03 за гігабайт на місяць у 2014 році, а провайдери хмарного хостингу випустили нові тарифи для зберігання даних з рідкісним доступом. Виробники NAS теж сильно знизили ціни.

На жаль, це зниження витрат на байт врівноважується протилежними силами. На iPhone збільшення дозвіл камери, режим безперервної зйомки і додавання коротких анімацій (Live Photos) збільшує розмір зображення в байтах настільки швидко, що витрати зображення залишаються практично незмінними. А зображення з iPhone далеко не найбільші.

Щоб протидіяти цим витратам, фотохостинги впровадили ряд опцій. Ось лише деякі з них: зберігання фотографій в зниженому якості або пережиму, стягнення плати з користувачів за зберігання даних, впровадження реклами, продаж суміжних товарів, таких як паперові відбитки фотографій, і прив'язка до покупки хостингу мобільних пристроїв.

Є також ряд технічних підходів для стримування витрат. Ми окреслили деякі з них, а нижче опишемо три підходи, які реалізували: це налаштування порогів в системах зберігання, поширення існуючих методів економії місця на більшу кількість зображень і впровадження стиснення JPG без втрат.

Налаштування порогів в системах зберігання
Ми занурилися в проблему і ретельно досліджували наші системи зберігання. Ми виявили, що налаштування були виставлені з припущенням про великій кількості перезапису і частому видалення інформації, чого не відбувалося. Наше сховище досить статичне. Користувачі дуже рідко видаляють або змінюють зображення після завантаження. У нас також є дві зарезервовані області. 5% зарезервовано під снапшоти — знімки стану, корисні для скасування випадкових вилучень або перезапису, а 8,5% вільного дискового простору залишено в резерві. В сумі близько 13% місця не використовується. Професіонали кажуть, що 10% диску слід залишати вільним, щоб уникнути деградації продуктивності, але ми вивели, що для нашої завантаження достатньо 5%. Так що ми об'єднали дві зарезервовані області в одну і зменшили поріг вільного місця на диску до цієї величини. Це наш найпростіший метод вирішення проблеми (поки), але він приніс хороший результат. Після пари невеликих змін в конфігурації ми звільнили більше 8% наших носіїв.


Налаштування порогів в системах зберігання

Розширення існуючих підходів
У попередніх статтях ми описали динамічну генерацію зменшених копій зображень і перцептивное стиснення. Поєднання двох методів зменшило простір для зберігання зменшених копій на 65%, хоча ми не застосовували ці техніки до багатьох зображень, завантажених до 2014 року. У цього є одна велика причина: широкомасштабні зміни у старих файлах за своєю суттю ризиковані, а безпечне проведення операції потребує значного часу і зусиль розробників.

Ми боялися, що якщо розширимо дію системи динамічної генерації зменшених копій, то це сильно збільшить навантаження на інфраструктуру динамічної генерації, тому вирішили видалити статичні зменшені копії лише у найменш популярних зображень. Використовуючи такий підхід ми утримали все навантаження по динамічної генерації зменшених копій в межах всього чотирьох GPU. Процес сильно навантажив системи зберігання; для мінімізації навантаження ми рандомізовали операції по різних томах. Весь процес зайняв приблизно чотири місяці, а в результаті ми звільнили навіть більше місця, ніж після установки порогів в системах зберігання.


Зниження кількості розмірів зменшених зображень

Стиснення JPG без втрат
Flickr давно залишався прихильником точного запису побайтно завантажених зображень. Це накладає обмеження на максимально можливий обсяг звільненого місця, але існують інструменти для стиснення без втрат фотографій JPG. Два добре відомих інструменту — PackJPG, Leptonвід Dropbox. Ці програми декодують JPG, а потім дуже акуратно стискають його, використовуючи більш ефективний метод. Зазвичай вдається зменшити JPG приблизно на 22%. У масштабах Flickr це дуже багато. Недолік в тому, що пережиму споживає багато ресурсів CPU. PackJPG працює зі швидкістю близько 2 МБ/с на одному ядрі, тобто приблизно 15 ядро-років знадобиться для перетискання петабайта фотографій. Lepton задіює кілька ядер і зі швидкістю 15 МБ/с набагато швидше PackJPG, але вимагає приблизно таких же ресурсів CPU для виконання такої ж роботи.

Це вимога CPU також ускладнює повсякденну роботу сервісу. Якщо ми пережмем всі зображення на Flickr, то нам потенційно потрібні тисячі ядер для виконання завдань декодування. Ми подумали над введенням деяких обмежень на доступ до стисненим зображень, таких як вимога авторизації користувача для доступу до оригіналів, але в підсумку вирішили, що якщо звертаємося тільки до приватних фотографій з рідкісним доступом, то в підсумку розпакування буде нечастим подією. До того ж, обмеження максимального розміру зображень обмежувало максимальні обчислювальні ресурси для розпакування. Ми викотили це зміна як частину існуючого набору технологій, без вимоги виділити додаткові ресурси CPU, і тільки з самим незначним зміною з точки зору користувача.

Запуск процедури стиснення без втрат на оригінальних фотографіях користувачів, ймовірно, був нашим самим ризикованим дією. Зменшені копії можна відтворити без проблем, але зіпсоване початкове зображення відновити неможливо. Ключовим елементом нашої стратегії був метод «пережиму−розпакування−перевірка»: кожне перетиснене зображення распаковывалось і порівнювався з вихідним оригіналом, перш ніж видаляли оригінал.

Робота все ще триває. Ми стиснули значну частину, але обробка всього архіву — тривалий процес, а ми досягли нашої мети «жодного нового байта за рік» вже до середини року.

Варіанти на майбутнє
Є ще кілька ідей, які ми вивчаємо, але поки не реалізували.

У поточної моделі зберігання для кожного зображення є оригінал і зменшені копії, які зберігаються у двох дата-центрах. Така модель передбачає, що зображення повинні бути готові для перегляду відносно швидко в будь-який момент часу. Але приватні фотографії на акаунтах, неактивних більше кількох місяців, навряд чи будуть дивитися. Ми можемо «заморозити» ці фотографії, стерти їх зменшені копії і згенерувати їх заново в тому випадку, якщо «сплячий» користувач повернеться. Такий процес «розморожування» займе менше 30 секунд для типового облікового запису. До того ж, для приватних фотографій (але не «сплячих» користувачів) ми могли б перейти на одну несжатую версію кожної зменшеної копії, зберігаючи стислу версію у другому дата-центрі з можливістю розгортання в разі необхідності.

Можливо, нам навіть не потрібні дві копії на диску кожної оригінальної фотографії «сплячого» користувача. Ми змалювали модель, в якій ми переміщаємо одну копію на більш повільну систему з стрічковими накопичувачами з рідкісним доступом, а іншу залишаємо на диску. Це зменшить доступність даних під час збою, але оскільки ці фотографії належать «сплячим» користувачам, ефект буде мінімальним, а користувачі все ще будуть бачити зменшені копії своїх фотографій. Найделікатнішу частиною тут є розміщення даних, тому що час пошуку на стрічкових накопичувачах непомірно велика. В залежності від умов, що вважати «сплячої» фотографією, такі методи можуть заощадити ще до 25% дискового простору.

Ми також вивчили можливість усунення дупликатов, але визначили кількість дупликатов в районі 3%. У користувачів дійсно багато дупликатов своїх власних зображень на своїх пристроях, але вони обчислюються нашими інструментами завантаження. Ми також подивилися на альтернативні графічно формати, які можна використовувати для зменшених копій. WebP може бути більш компактним, ніж звичайний JPG, але використання перцептивного стиснення дозволили нам наблизитися до WebP по розміру в байтах з більш швидкими операціями зміни розміру. Проект BPG пропонує набагато більш ефективне кодування на основі H. 265, але має обтяження з інтелектуальною власністю та інші проблеми.

Є кілька варіантів для відео. Хоча Flickr призначений в основному для фотографій, відео зазвичай набагато більше за розміром і займають значно більше місця.

Висновок

Кілька етапів оптимізації

З 2013 року ми оптимізували нашу систему зберігання приблизно на 50%. Завдяки останнім зусиллям ми прожили 2016 рік, не купивши жодного додаткового носія, і у нас ще залишаються додаткові варіанти оптимізації.

Пітер Норби (Peter Norby), Тея Комма (Teja Komma), Сидзе Джой (Shijo Joy) і Бей Ву (Bei Wu) склали кістяк нашої команди для бюджету з нульовою надбавкою байтів. Багато інші сприяли.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.