Об авторе. Арчи Рассел (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) составили костяк нашей команды для бюджета с нулевой прибавкой байтов. Многие другие оказали содействие.
Автор: m1rko
