Как эффективно работать с S3: практические советы

Это вторая статья из цикла материалов о работе с объектным хранилищем S3. На недавнем вебинаре мы рассказывали, как не нужно работать с S3. В статье поделимся советами о том, как обеспечить надёжность хранения данных и увеличить производительность при работе с S3.

Обеспечьте надёжность за счёт реплицирования данныхОбеспечьте надёжность за счёт реплицирования данных

Обеспечение высокой производительности — задача непростая. Например, некоторым компаниям приходится жертвовать надёжностью хранения ради увеличения производительности.

Такая ситуация может возникнуть, если:

• Данные хранятся только в одной зоне доступности. Это снижает задержки коммуникаций внутри хранилища, позволяя ему быть быстрее. Однако при такой схеме данные уязвимы при сбоях в зоне доступности.

• Включено кеширование записей. Это повышает производительность операционной системы, но может привести к потере данных в случае перебоев питания, сбоя оборудования или программного обеспечения.

Мы рекомендуем хранить данные с репликацией в нескольких зонах доступности. В Yandex Cloud, чтобы обеспечить высокую надёжность хранения, данные сохраняются в трёх зонах.

При этом Yandex Cloud возвращает клиенту ответ об успешности операции после того, как данные попадут на физические носители во всех трёх зонах доступности. Это гарантирует строгую согласованность данных, которая позволяет клиентам эффективно реализовывать сценарии синхронизации — работать с единым хранилищем из нескольких зон доступности и всегда получать единый стек данных. Эта функциональность является необязательным пунктом стандарта S3, но она реализована в Yandex Cloud.

Используйте параллельную и составную загрузкуИспользуйте параллельную и составную загрузку

S3 позволяет сохранять объекты размером в несколько терабайт. При этом объект хранится таким же, каким его загрузили: размещается в одной ячейке хранения и обрабатывается как единое целое.

Однако чем больше объект, тем выше вероятность, что его загрузка через интернет завершится ошибкой сети. Поэтому мы рекомендуем загружать большие объекты частями меньшего размера. Такой способ сохранения объектов в Object Storage называется составная загрузка. Более того, каждая часть многосоставного объекта хранится и обрабатывается отдельно. Таким образом, при чтении участвует больше дисков, что может увеличить скорость чтения для некоторых задач.

Также мы рекомендуем настраивать жизненные циклы объектов в бакете. Это позволит автоматизировать процесс удаления частей составных загрузок, которые не были завершены. В противном случае оставшиеся части составной загрузки сохранятся, будут занимать место в бакете и потреблять финансовые ресурсы.

При этом параллельная загрузка позволяет ускорить процесс размещения объектов в бакете за счёт одновременного запуска нескольких составных загрузок.

Используйте GeeseFS для ускорения работы S3Используйте GeeseFS для ускорения работы S3

AWS CLI — основной инструмент работы с S3, но не единственный. Вы можете выбрать другие решения для работы с хранилищем.

Например, GeeseFS — программа для монтирования бакетов Yandex Object Storage через FUSE. Инструмент позволяет работать с хранилищем S3 как с обычной файловой системой. GeeseFS экономит потребление трафика, поддерживает частичное изменение объекта и дозапись. Кроме этого, у GeeseFS реализован механизм кеширования, который обеспечивает ускоренное получение данных за счёт параллелизации запросов.

С помощью частичного изменения вы можете хранить в бакете данные (например, логи) в виде единого файла, периодически дописывая в него информацию. Подключив опцию монтирования enable-patch вы можете увеличить производительность GeeseFS за счёт передачи в S3-хранилище только тех изменений, которые вы внесли в данные.

За счёт параллелизма GeeseFS может показывать лучшую производительность и обеспечивать существенную экономию времени по сравнению с AWS CLI. Например, при загрузке файлов, что было продемонстрировано на примере в вебинаре.

Работайте с данными, не опасаясь превысить лимиты по частоте запросовРаботайте с данными, не опасаясь превысить лимиты по частоте запросов

Мы не ограничиваем наших пользователей искусственными лимитами по частоте запросов (RPS), потому что масштабируем инфраструктуру, чтобы удовлетворять все поступающие запросы.

Тем не менее, если вы создадите существенную специфическую нагрузку на объектное хранилище, оно может выдавать ошибку 503 SlowDown. Подчеркнём, что нагрузка при этом должна быть именно специфическая.

Что значит «специфическая нагрузка»?

Если вы получаете ошибку 503, то, скорее всего, делаете что-то не так. Например, совершаете аномально много запросов в один и тот же ключ или шлёте циклические запросы с ошибкой авторизации от «упавшего» приложения.

В случае возникновения ошибки 503 мы рекомендуем проверить корректность выполнения запросов в S3 или обратиться в нашу техническую поддержку.

Коды ошибки 429 vs 503Коды ошибки 429 vs 503

Ответы 429 TooManyRequests и 503 SlowDown для клиента S3 означают одно и то же: нужно замедлиться и снизить нагрузку.

Обычно приложения, работающие с S3, умеют справляться с такими ошибками и не падать. Какой-то специальной настройки не требуется, в большинстве случаев приложения просто повторяют запрос.

AWS (основоположник стандарта S3) чаще всего возвращает 503, а не 429. Так работает большинство SDK.

Мы реализовывали S3 API максимально совместимым, в том числе по возвращаемым кодам ошибок (ведь их обрабатывает множество приложений, работающих с S3). Разобраться в таком количестве непросто, поэтому для совместимости и удобства мы возвращаем 503, а не 429.

Проводите нагрузочное тестирование на большом объёме данныхПроводите нагрузочное тестирование на большом объёме данных

Небольшой объём данных на тесте (Working set) не покажет реальной картины. Это происходит по нескольким причинам:

• Небольшое количество данных использует минимальное количество компонентов хранилища.

• Постоянно обновляются одни и те же ключи/объекты. Используется малое количество записей внутри базы данных хранения объектов.

• Не используются преимущества параллельной нагрузки.

Рекомендуем проводить тестирование на большом объёме данных, чтобы масштабируемое хранилище могло продемонстрировать все свои возможности. Объём данных должен соответствовать вашим данным в продакшне, если это невозможно, то можно ограничиться несколькими миллионами объектов. Нет смысла тестировать хранилище всего на тысяче объектов/файлов. При желании все их можно получить или записать за пару секунд параллельной загрузки.

Для проведения нагрузочного тестирования S3 мы рекомендуем использовать утилиту WARP. Она позволяет создать множество нагрузочных клиентов и осуществить параллельную работу с S3, как это происходит в продуктивной среде при работе с хранилищем. Автоматизация утилиты позволяет протестировать нагрузку на S3 одновременно с множества виртуальных машин в нескольких зонах доступности.

Кстати, в нашем S3-хранилище периодически проходит оптимизация метаданных бакета. Поэтому после загрузки в пустой бакет нескольких миллионов объектов стоит подождать как минимум одни сутки, чтобы прошла оптимизация.

ВыводыВыводы

Эти простые рекомендации помогут увеличить эффективность работы с S3-хранилищем, оптимизировав его производительность.

Хотите узнать о работе с S3 ещё больше? Читайте первую статью нашего цикла. Из неё вы узнаете, какие основные этапы проходит запрос в базу данных и как избежать снижения производительности объектного хранилища.