Продолжаем беседовать с разработчиками экосистемы сервисов Serverless. В прошлый раз Глеб Борисов рассказал о возможностях и перспективах функций в Yandex.Cloud, сегодня Данил Ошеров погрузит нас в мир бессерверных систем и сервис Object Storage.
У меня был опыт разработки систем, обеспечивающих доступность файлов в разных дата-центрах. Мне надо было синхронизировать файлики, для чего пришлось разрабатывать целую систему, и я был не одинок в такой работе, это делали практически все разработчики корпоративного ПО.
Со временем такие системы перестали быть актуальными, они ушли на второй план, а на смену пришли новые, построенные по протоколу S3. Почему так случилось? Почему S3 стал «главным» протоколом для синхронизации данных?
Разберемся по порядку. Протокол S3 придумала Amazon, их удобное облачное решение для хранения данных своим выходом взорвало рынок и поменяло правила игры остальных игроков. Другие компании были вынуждены повторять этот протокол, чтобы их данные были доступны для тех же инструментов, которые работают с Amazon. Отсюда и такая популярность. S3 — не единственный подобный протокол для взаимодействия с облачным хранилищем, но он самый популярный.
Массовое распространение облачных решений привело к отказу от кастомных самописных — это самый важный переход. Тебе, как клиенту, больше не нужно задумываться, что есть несколько физических точек присутствия, облачное решение дает гарантию надежного хранения и доступности файлов. Бонусом ты получаешь удобный API. Пользователь загружает файлы в облако, они там надежно хранятся и выдаются обратно в любой момент, а как обеспечивается отказоустойчивость и скорость — клиента уже не волнует.
Как-то так получилось, что и решение оказалось удачным, и протокол стал популярным. Это заслуга сильной компании — Amazon, или рынок созрел для переноса данных в облака?
Рынок созрел. Бизнес готов доверить свои данные облачным хранилищам. Если бы на месте Amazon оказалась Google, взорвав рынок своим протоколом, то мы бы сейчас пользовались им.
Еще один важный момент: большие компании, такие как Google и Microsoft, также предоставляют услугу облачного хранилища, но при этом вынужденно ушли от протокола S3. Свой протокол, свои клиенты, свои библиотеки для работы со своим хранилищем. Этот набор необходим для поддержания общей экосистемы облака, предоставления унифицированного интерфейса, а не потому что S3 чем-то плох.
Мы предоставляем S3-совместимый протокол, чтобы клиентам было максимально удобно как мигрировать к нам, так и использовать уже готовый инструментарий: всевозможные консольные утилиты, готовые приложения, написанные программы. Но в любой момент клиенты могут просто переключиться на использование Yandex Object Storage, и всё также будет работать. Это большой плюс.
В перспективе может появиться наш собственный SDK и наш собственный протокол. Потому что бежать за Amazon и смотреть только на него — не совсем правильное решение.
Типовая история для всех облачных провайдеров. Они обязаны реализовать хранилище с поддержкой S3-протокола. Но в какой-то момент собственная реализация начинает предоставлять больше возможностей в соответствии с существующей архитектурой облачного решения, и возможностей протокола S3 начинает не хватать.
Да, мы не должны себя ограничивать. Сейчас рынок максимально сфокусирован на S3-совместимых решениях. Это нормально, поэтому мы никоим образом не отказываемся от него, а продолжаем развивать нашу совместимость. Мы фокусируемся сейчас именно на поддержке S3-совместимого решения, но при этом всегда держим в голове и в планах развитие собственного протокола, собственных SDK. Но это вопрос будущего.
Решение на базе S3 стало настолько популярным, что появилось множество реализаций этого протокола.
Это так. Вот только самое важное во всех реализациях — техническая сторона, как и где ты хранишь сами файлы. Готовый веб-сервер, который умеет отвечать S3-совместимым протоколом, — отлично, но вопрос в том, где он эти файлы хранит. Если они лежат на одной машине, то такое решение не отказоустойчивое и не масштабируемое. Такое хранилище подойдет для тестов или простых сценариев, но что-то серьезное уже не потянет, и ты захочешь большего. Одной машины станет недостаточно, и возникнет вопрос: а как расширяться? Поэтому что-то готовое, что можно было бы построить поверх любого облака, сложно представить. Как итог, хранилище — это базовый сервис любого облака, фундаментальный.
Object Storage существует поверх инфраструктуры дата-центров в разных местах. Сейчас есть три большие точки присутствия, три зоны доступности. А как между этими дата-центрами перемещаются копии файлов?
Никак, они сразу находятся везде. Когда ты отправляешь файл на загрузку в наш storage, мы его сохраняем сразу в нескольких точках присутствия и получаем сразу несколько копий.
Получается, на входе существует какой-то прокси, который разделяет эти данные в момент записи?
Всё так. Если бы мы сохраняли только одну копию, а затем этот файл синхронизировали на остальные копии, то в зазор времени между сохранением и репликацией могло бы произойти какое-то изменение или катастрофа. Машина, на которую мы сохранили файл, могла «умереть», или мог выйти из строя диск. Это грозило бы потерей данных, что недопустимо для storage. Поэтому мы сразу сохраняем файлы в нескольких копиях.
Пока файл находится в нашем storage, возникают разные ситуации, вплоть до выхода из строя всего дата-центра. Поэтому наличие дополнительных копий критично необходимо, чтобы обеспечить непрерывный доступ к данным. Мы не можем ограничиваться только одним дата-центром. Аварии случаются не только с дата-центром, но и с машинами или дисками. Они могут «умирать», унося с собой «на тот свет» и одну из копий данных. Ее нужно восстанавливать, и за этим сложным процессом у нас следит внутренний механизм, который определяет нехватку копий и автоматически сразу их восстанавливает.
Наша цель — обеспечивать постоянную доступность файлов. Мы стараемся предугадывать возможные потери, недоступность зон или машин.
Как реагирует Object Storage на отключение одного из дата-центров во время учений? Правильно я понимаю, что сервис, который следит за количеством «живых» копий файла, срочно начинает восстанавливать их количество?
Инфраструктуры Яндекса и Yandex.Cloud — независимые, учения Яндекса никак не влияют на работоспособность сервисов Yandex.Cloud. Это важный момент.
Архитектура любых сервисов Яндекса построена так, чтобы обеспечивать их работу в случае отказа любого одного дата-центра. Таким же образом и Object Storage обязан хранить файлы в достаточном количестве копий, чтобы при отключении любого дата-центра файлы оставались доступны.
При осуществлении плановых учений мы не запускаем создание копий, как это происходит в случае аварии, а продолжаем работать в состоянии временной деградации. Это позволяет избежать большой внутренней нагрузки, связанной с миграцией и копированием огромных объемов данных. Когда учения заканчиваются, мы продолжаем работать в штатном режиме. Копирование данных и восстановление происходит именно при нештатных ситуациях, когда у нас вылетает диск или отказал целиком хост.
А учения — это регулярные процессы, которые подсказывают нам, как ведут себя сервисы при возможной аварии.
Правильно я понимаю, что на S3 как на базовом элементе инфраструктуры внутри Яндекса и Yandex.Cloud построено огромное количество других сервисов, отвечающих за работу других публичных услуг?
Да, объектное хранилище использует огромное количество сервисов. Причем сервис Object Storage, предоставляемый как услуга платформы Yandex.Cloud, построен на тех же технологиях, что и хранилище для внутренней инфраструктуры. Это не раздельные решения, специально написанные для облака или специально написанные для Яндекса, а единая система объектного хранения с независимыми инсталляциями, но одинаковым технологическим стеком.
В результате клиенты Yandex.Cloud получают сервис, способный справиться с любой нагрузкой. Его построили для безупречного оказания услуг Яндекса при любых нагрузках, и он показывает отличные тайминги и доступность. Качество Яндекса гарантировано для всех пользователей Yandex.Cloud, в производительности и отказоустойчивости можно не сомневаться.
Технологические решения в области S3 полностью переиспользуются в виде отдельной инсталляции?
Да. Тот опыт, который мы получаем, проектируя решения для Яндекса, очень важен и помогает предоставлять качественные услуги в Yandex.Cloud. Поэтому учения, проводимые Яндексом, не должны пугать клиентов облака, а скорее могут показать им нашу ответственность за предоставляемые сервисы.
От теории к практике. Какие возможности S3 чаще всего привлекают клиентов, и какие кейсы они реализуют? Для меня, например, это гарантированная доступность файла в нескольких зонах, в нескольких дата-центрах.
Действительно, это базовое требование к Object Storage, которое важно для всех. Но S3 подходит для любых данных — давай поговорим о том, в каких случаях тебе это может потребоваться.
Наиболее популярный кейс — это бэкапы. То есть ты можешь сохранять в облаке бэкапы своей базы данных, или логи своего приложения, или любые другие резервные копии. Они будут надежно хранится и будут доступны в любой момент, когда потребуются, хотя насчет бэкапов — лучше, чтобы такой момент не наступал. Для задач резервного копирования объектное хранилище, построенное по протоколу S3, подходит очень хорошо.
Есть и другие кейсы. Например, хранение картинок. Это горячий контент, который ты показываешь на сайте, — к нему нужен стабильный и быстрый доступ. Более того, ты можешь загрузить по S3 и данные самого сайта, всевозможные js-файлы и статику — и показывать пользователям их напрямую из Object Storage.
В отличие от кейса с бэкапами, где в облаке хранятся холодные данные, страницы и графика сайта, — это горячие данные, для них выделяется более быстрый пул. В зависимости от скорости и частоты доступа подбирается тариф. Холодное хранение дешевле.
То есть скорость доступа к холодным данным ниже, чем к горячим?
Она может быть ниже. Частота запросов к файлам в холодном хранилище ниже и критичность высокой скорости доступа меньше. Мы сделали такое разделение, так как был пользовательский спрос. Теперь у клиентов есть выбор: для активных файлов, которые часто используются и перезаписываются, выбрать горячее хранилище с высокой скоростью, а для «просто хранить» — холодное, с низкой скоростью и ценой.
Еще один кейс использования объектного хранилища — сервис потокового вещания или раздачи видео. В S3 загружаются чанки видео лайвстрима, а затем из него напрямую раздаются и показываются пользователям.
Как это работает — есть стандартные решения?
Да, тут есть стандартные решения. У тебя сохраняется некий манифест, из чего состоит потоковое вещание, в нем есть ссылки непосредственно на чанки, которые воспроизводятся у тебя в браузере или в плеере.
При лайв-вещании данные активно загружаются и постоянно скачиваются пользователями, которые смотрят это видео. Это как раз горячее хранение. Но очевидно, что со временем старые данные становятся не так актуальны, эти видео редко смотрят, и их можно переложить в холодное хранилище, как в архив. S3 также предоставляет механизм очистки всего старого. Это один из примеров того, как с помощью удобного API мы стараемся решать наиболее востребованные задачи пользователей.
Меня еще волнует вопрос внезапной пиковой нагрузки. Допустим, видео или картинка завирусилась или на сайт совершена DDoS-атака.
В целом обычно помогают системы мониторинга, но только отличить DDoS от органической нагрузки сервис мониторинга не может. Для него нет разницы — пришли пользователи массово качать новую версию игры или популярное видео, либо это боты активно скачивают файлы, чтобы «уронить» сервер. Оба кейса имеют место быть, и без человеческого анализа их разделить сложно.
На чем сейчас написана реализация S3?
Недавно мы целиком перевели разработку нашего S3 на Go. До этого мы разработали прототип S3 на Python, потому что нужно было быстро запуститься. После этого часть реализовали на плюсах, чтобы выдерживать большие нагрузки от сервисов Яндекса, когда S3 сильно начал расти. Но периодически возникали проблемы.
Поэтому мы решили, что нужно унифицировать процесс нашей разработки и перейти к единому стеку. Выбрали Go, и осенью прошлого года перевели всё на него. Теперь стек технологий, которые используются внутри Яндекса и в Облаке, — единый. В результате мы не только привели весь стек к единообразию, но также получили неплохой performance boost.
А когда вообще в Яндексе появился S3?
Первый прототип был создан около четырех лет назад. Еще за год до начала реализации вопрос создания S3 внутри Яндекса регулярно поднимался, но начало работы всегда откладывалось. После успешного внутреннего использования мы запустили в Yandex.Cloud наше решение.
Насколько Object Storage в Yandex.Cloud отличается от реализации S3 в Amazon?
Все реализации S3, отличные от Amazon, отстают от оригинала. S3 в Amazon был реализован уже очень давно и всё время до текущего момента постоянно улучшался и обрастал новыми возможностями. За время, которое было у нас, мы реализовали неплохой набор фич, но при этом еще многое впереди.
Как я уже говорил, просто слепо бежать за Amazon, потому что «он это делает так», в какой-то момент станет неактуально. Если мы возьмем готовые библиотеки приложения, то увидим, что они оперируют неким ограниченным набором функциональности, который им нужен от S3. Поэтому многие разработчики, зная, что есть не только S3 от Amazon, берут альтернативные совместимые решения для конкретных задач. Сейчас принято не оперировать огромной кучей фичей, а использовать подмножество S3-API функциональности.
Исходя из этого наш Object Storage обладает функциональностью, которая необходима большинству. И конечно, мы много сил уделили развитию UI. Сейчас наши клиенты получают полноценное продакшен-решение.
P.S.
Самый простой и понятный сценарий, который может использовать любой хаброжитель в своих целях, — раздача статического контента с Object Storage, например статического сайта. Это может стать основой вашего Serverless-приложения. О подробностях и нюансах разработки в этой экосистеме можно узнать в сообществе Serverless в Telegram: Yandex Serverless Ecosystem.
На осенней конференции Yandex Scale был анонсирован free tier для сервисов экосистемы бессерверных вычислений. Это специальные тарифы для Serverless-сервисов с уровнем нетарифицируемого использования. Например, для Yandex Object Storage каждый месяц не тарифицируются первые 100 000 операций GET, HEAD и первые 10 000 операций PUT, POST. Более подробно об условиях читайте в разделе.
