Предлагаем пошагово проследить путь, который проходят запросы пользователя к объектному хранилищу, и выяснить, что происходит на каждом из его этапов:
-
Отправка запроса.
-
Выход запроса в сеть.
-
Балансировка запроса.
-
Получение запроса S3-хранилищем.
-
Проверка прав доступа.
-
Запись объекта в хранилище.
-
Возвращение ответа.
Для каждого этапа обсудим факторы, влияющие на скорость запроса и работу хранилища, и сформулируем практические советы, которые помогут увеличить производительность.
Этот этап полностью контролирует пользователь.
Эффективность запроса на этом этапе лежит на плечах клиента (например, на администраторе его системы) и влияет на общий результат работы с S3. Популярные проблемы:
Убедитесь, что приложению, работающему с S3, достаточно ресурсов: CPU, RAM, disk IO.
С точки зрения CPU и памяти:
-
В OS, где запущен тест, достаточно ядер CPU, и они не загружены другими приложениями. Если тестирование проводится внутри виртуальной машины, то лучше добавить ядра vCPU, чтобы исключить возможные проблемы на этой стадии. Для полноценного многопотчного тестирования желательно иметь не менее 8 vCPU.
-
Ядра, выделенные под машину с тестом, не разделяются с другими виртуальными машинами. Это поможет предотвратить возможное влияние соседних виртуальных машин на работу теста.
-
Запуск теста не осуществляется на прерываемых машинах, это является ещё одной частой проблемой. Если нагрузка запускается внутри контейнера K8s, то убедитесь, что выделено 100% CPU.
-
Также важно обращать внимание не только на гостевую ОС (чтобы не было других потребителей CPU), но и вовне (чтобы сама виртуальная машина не останавливалась, не подтормаживала).
К тому же важна производительность локальной дисковой подсистемы, откуда берутся данные для передачи в S3-хранилище. В случае недостаточной производительности дисковой подсистемы результаты работы с S3 будут ниже, так как значительное время уйдёт на получение данных до формирования запроса к S3. Убедитесь, что локальный диск, где размещены тестовые данные, значительно быстрее, чем ожидаемая скорость S3. Используйте High IOPS SSD (быстрые сетевые диски) или RAM-диски (для данных в оперативной памяти), чтобы хранить данные для теста, или считывайте их в оперативную память до того как будете выполнять замер производительности S3. Например, если вы загружаете данные с HDD в S3, а S3 отрабатывает любые запросы мгновенно, общий показатель результата теста будет не выше производительности HDD (100 RPS, 100 МБ/c).
После того, как приложение отправляет запрос в хранилище, он попадает в сеть.
-
Низкая пропускная способность канала.
-
Загруженность канала другим трафиком.
-
Ограничение скорости канала.
Здесь сработают те же рекомендации, что и для предыдущего раздела. А если точнее — надо исключить загрузку канала другими приложениями и трафиком, выделив больше ресурсов.
Кроме того, могут помочь ещё несколько советов:
-
Проверьте пропускную способность вашей локальный сети с помощью утилиты iperf.
-
Проверьте тип сетевого интерфейса: если у сетевого соединения низкая скорость, закономерно, что данные будут выходить в сеть долго. Речь не об ограничении пропускной способности полосы, а именно о latency узкого канала при передаче данных: 10 МБ данных пройдут быстрее через 10-гигабитную сеть, чем через 1-гигабитную сеть несмотря на то, что в обоих случаях не упрутся в предельно допустимую ширину канала.
-
Минимизируйте влияние «дикого» интернета. Каналы выхода в интернет бывают разные, но все они влияют на производительность. Чтобы снизить воздействие этого фактора, проведите тесты работ с S3 на виртуальных машинах, которые находятся внутри Yandex Cloud, и проверьте загрузку канала сторонним трафиком.
-
Ускорьте выход запроса, создав приватные выделенные сетевые соединения между локальной и облачной инфраструктурами. Сервис Interconnect, разработанный Yandex Cloud, позволяет создавать приватные соединения поверх магистрального канала. При этом пропускная способность выше, а задержки меньше, по сравнению с подключением через интернет.
После того как запрос вышел в сеть, он приходит из магистральной сети в одну из точек обмена трафиком и попадает в ближайший балансировщик трафика, где распределяется в одну из зон доступности, обеспечивая отказоустойчивость. С этого момента ответственность за прохождение запроса и его скорость лежит на Yandex Cloud.
Несмотря на то, что домен storage.yandexcloud.net имеет один IP-адрес, трафик обрабатывается большой фермой балансировки трафика, которая состоит из множества серверов в разных локациях. Задача балансировщика — передать запрос в ближайшую зону доступности S3-сервиса. Если одна из зон доступности не ответит, трафик перераспределится между другими зонами автоматически, и S3 продолжит работать.
Запрос поступает на nginx (прокси-сервер), и предаётся в компонент S3-proxy, который отвечает за разбор запросов протокола AWS S3. Важно, что прежде чем хранилище получит запрос, он должен полностью поступить на nginx.
- Если устанавливать отдельное соединение с S3 на каждый запрос, то будут возникать множественные TLS-сессии.
