s5cmd vs AWS CLI: скорость работы с S3 на VDS и удобство команд

Зачем сравнивать s5cmd и AWS CLI для S3 на VDS

При массовых операциях с S3-хранилищами админы обычно используют два инструмента: высокоуровневый AWS CLI (команда aws s3 ...) и утилиту s5cmd, заточенную на максимальную скорость. На VDS выбор влияет не только на «секунды до результата», но и на прогнозируемость выполнения бэкапов, миграций статики, агрегации логов, а также на стоимость — чем меньше времени и повторных запусков, тем ниже операционные расходы.

Ниже — практическое сравнение с упором на производительность (параллелизм, распараллеливание списков и запросов, работа с мелкими и крупными файлами), удобство команд и устойчивость к ошибкам сети/API. Разберёмся, как провести честный бенчмарк на VDS, какие параметры трогать, и в каких сценариях каждый инструмент сильнее.

Коротко об инструментах

AWS CLI (s3 и s3api)

AWS CLI — «эталонный» клиент: поддерживает весь спектр операций с S3, от простых копий до детального управления через s3api (метаданные, шифрование, политики, классы хранения, восстановление из архивного класса и т. д.). Высокоуровневые команды aws s3 cp и aws s3 sync удобны для повседневных задач и миграций. Параллелизм настраивается через профиль, поддерживаются многочастичные загрузки и адаптивные ретраи.

s5cmd

s5cmd — компактная утилита, ориентированная на скорость массовых операций. Сильные стороны: агрессивный параллелизм, быстрый листинг, батч-выполнение (run), поддержка шаблонов и пайпов. На типичных задачах «много мелких файлов» и «смешанный набор» s5cmd чаще выигрывает по времени, расходуя меньше CPU на единицу пересланных данных.

Установка и базовая настройка на VDS

AWS CLI

На большинстве дистрибутивов ставится из репозитория. Минимум:

apt update
apt install -y awscli
aws --version

Дальше — настройка профиля и ключей доступа через aws configure. Для S3-операций высокого уровня будут использоваться команды aws s3 ..., а для тонкой настройки — aws s3api ....

s5cmd

s5cmd доступен как статический бинарник или через пакетные менеджеры. Часто его ставят из исходников Go:

GO111MODULE=on go install github.com/peak/s5cmd@latest
export PATH=$PATH:$(go env GOPATH)/bin
s5cmd version

Ключи доступа берутся из тех же переменных окружения/профилей, что и у AWS CLI, поэтому переключаться между утилитами удобно.

Параллелизм, мультипарт и сетевые ограничения

Производительность в S3-операциях упирается в три вещи: количество одновременных запросов, размер частей при мультипарт-загрузке и состояние сети (латентность, пропускная способность, ограничители со стороны сервиса). На VDS добавляются файловые дескрипторы, диапазон эфемерных портов, лимиты открытых файлов и I/O.

Параллелизм в AWS CLI

Для aws s3 параметры регулируются через профиль. Практически полезные:

• max_concurrent_requests — сколько одновременных запросов держит трансфер-менеджер.
• multipart_threshold — с какого размера включать мультипарт.
• multipart_chunksize — размер части мультипарта.

Пример настройки профиля по умолчанию:

aws configure set default.s3.max_concurrent_requests 64
aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 64MB

Значения подбираются опытным путём: для 1 Гбит/с канала стартуют с 32–64 одновременных запросов и 32–64 МБ части, а дальше увеличивают до насыщения сети и CPU.

Параллелизм в s5cmd

У s5cmd есть глобальный флаг конкурентности (количество воркеров), который применяется ко всем операциям. Стартовые ориентиры: 64 воркера на 1 Гбит/с, 128–256 — если CPU и сеть позволяют. Для больших файлов s5cmd использует многочастичную загрузку; размер частей и степень параллелизма подбирает сам инструмент, но итоговый потолок упирается в количество воркеров и сетевые лимиты.

Стабильности добавляют ретраи с экспоненциальной задержкой: и AWS CLI, и s5cmd умеют повторять запросы при HTTP 5xx и сетевых ошибках. Если видите частые SlowDown/503 — уменьшайте параллелизм и проверяйте лимиты со стороны S3-совместимого сервиса.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Удобство команд и сценарии

Массовые копии и миграции

Классика для AWS CLI — рекурсивная копия и синхронизация:

# Копия всего префикса на локальный диск
aws s3 cp s3://bucket/prefix . --recursive --no-progress

# Обратная копия в S3 с метаданными
aws s3 cp ./public s3://bucket/prefix --recursive --cache-control max-age=31536000,public --no-progress

# Синхронизация (удаляет лишнее на приёмной стороне, если добавить --delete)
aws s3 sync ./public s3://bucket/prefix --no-progress

s5cmd делает ставку на шаблоны и массовые операции. Рекурсивность обычно решается шаблонами * и **, а для очень больших наборов удобно использовать батч:

# Прямая копия множества объектов (шаблон раскрывается на стороне инструмента)
s5cmd --concurrency 128 cp s3://bucket/prefix/** ./data

# Батч: заранее сгенерировали команды (одна операция в строке)
# Пример файла batch.txt:
# cp s3://bucket/a/001.log ./logs/001.log
# cp s3://bucket/a/002.log ./logs/002.log
# ...

s5cmd --concurrency 128 run < batch.txt

Плюс s5cmd — очень быстрый листинг и обработка больших списков. Плюс AWS CLI — «из коробки» удобный sync с семантикой сравнения размеров/дат и встроенные фильтры --include/--exclude в привычном стиле.

Мелкие файлы, лог-стримы, архивы

Когда объектов сотни тысяч и каждый — килобайты, важны: скорость листинга, низкая накладная на запрос/секцию и агрессивный параллелизм. Здесь s5cmd часто показывает 2–5x ускорение против aws s3 cp --recursive при равном числе одновременных запросов. Если добавлять предварительную фильтрацию (генерировать батч только нужных ключей), выигрыш растёт, потому что экономим лишние HEAD/LIST/GET.

Крупные бэкапы и артефакты сборок

На единичных больших файлах (гигабайты) оба инструмента упираются в мультипарт и пропускную способность канала. Разница часто несущественна: потолок задаёт сеть и ограничения сервиса. Тут главное правильно подобрать размер части и количество одновременных частей, а также следить за CPU-лимитами на VDS.

Честный бенчмарк на VDS: методика

Цель — получить сопоставимые цифры без «шейминга» сети и не уткнуться в локальные ограничения. Методика ниже многократно отрабатывала себя на проектах.

Наборы данных

• Много маленьких: 100k файлов по 4–16 КБ (имитация логов/мини-артефактов).
• Смешанный: 10k файлов 4–512 КБ и 500 файлов по 5–50 МБ.
• Большие: 5–10 файлов по 2–5 ГБ.

Генерацию делаем локально или заранее кладём в S3. Примеры локальной генерации:

mkdir -p bench/small bench/mixed bench/large

# Много маленьких файлов (осторожно: нагрузка на FS)
for i in $(seq 1 100000); do head -c 4096 < /dev/urandom > bench/small/file_$i.bin; done

# Смешанный набор
for i in $(seq 1 10000); do head -c 16384 < /dev/urandom > bench/mixed/m_$i.bin; done
for i in $(seq 1 500); do head -c 5242880 < /dev/urandom > bench/mixed/b_$i.bin; done

# Большие файлы
for i in $(seq 1 5); do head -c 2147483648 < /dev/urandom > bench/large/L_$i.bin; done

Подготовка VDS

• Проверьте лимиты: ulimit -n не ниже 65535 на время теста.
• Убедитесь, что диск не в бутылочном горлышке: чтение/запись локальных данных не должно ограничивать 1 Гбит/с сетевой поток.
• Следите за CPU: при слишком агрессивном параллелизме возрастёт системное время и ретраи.
• Если доступно, держите тестовую сессию на стабильном регионе/эндпоинте, избегайте «чехарды» маршрутов.

Если выбираете конфигурацию под такие тесты и прод-нагрузки, пригодится материал Как выбрать конфигурацию VDS (CPU/RAM).

Прогоны

Для каждого набора данных сделайте по 3 прогона на одинаковых настройках, затем меняйте конкуренцию.

# AWS CLI: загрузка локального каталога в S3
aws s3 cp bench/small s3://bucket/bench/small --recursive --no-progress

# AWS CLI: скачивание
aws s3 cp s3://bucket/bench/small ./download-small --recursive --no-progress

# s5cmd: аналогичная отправка (шаблон раскрывает содержимое каталога)
s5cmd --concurrency 128 cp bench/small/** s3://bucket/bench/small

# s5cmd: скачивание
s5cmd --concurrency 128 cp s3://bucket/bench/small/** ./download-small-s5

Метрики фиксируем такие: общее время команды (time), суммарный объём, количество объектов, средняя скорость (МБ/с), ошибки/ретраи. Для честности очищайте ОС-кеш при повторных скачиваниях, либо чередуйте направления (up/down), чтобы сгладить влияние page cache.

Что обычно показывает практика

• Много маленьких файлов: s5cmd быстрее в 2–5 раз за счёт более дешёвого листинга и агрессивного параллелизма. Разброс зависит от латентности до S3 и лимитов сервиса.
• Смешанный набор: преимущество s5cmd 1.5–3x, особенно если предварительно сформировать батч «нужных» ключей.
• Большие файлы: паритет или ±10–20%, упираемся в сеть и размер частей. Тут выигрывает тот, у кого корректнее подобраны chunk/воркеры под канал.

Если ваша основная боль — «много мелких объектов», начните с s5cmd: выигрыш почти всегда заметен без глубокого тюнинга. Для «больших бэкапов» разницы может не быть — выбирайте по удобству команд и интеграции.

Удобство и функциональность: где кто сильнее

Сильные стороны AWS CLI

• sync с предсказуемой семантикой: удобно для зеркалирования статики, когда нужна «делет-семантика».
• Полный доступ к S3 через s3api: метаданные, шифрование, политики, классы хранения, списки управления доступом, восстановление из архивов.
• Хорошая управляемость через профили и конфиги, меньше «сюрпризов» в корпоративной среде.

Сильные стороны s5cmd

• Быстрый листинг и дешёвая обработка шаблонов для массовых задач.
• Батч-режим run: можно генерировать миллионы команд и кормить их инструменту потоково.
• Простая модель конкурентности: один флаг — и поехали. Хорошо ложится на cron/CI.

Из практики: часто используют оба инструмента. aws s3 sync — для «зеркала» и инфраструктурных задач; s5cmd — для ускорения пайплайнов с большим количеством объектов или для «одноразовых» миграций, где скорость критична.

Тонкая настройка под VDS

Файловые дескрипторы и порты

• Увеличьте лимит дескрипторов: ulimit -n 65535 на время массовых операций.
• Проверьте диапазон эфемерных портов и количество соединений в TIME_WAIT. Мониторьте ss -s и нагрузку GC в пиках.

Размеры частей и очередей

• Начинайте с 32–64 МБ chunk для мультипарт и 32–128 параллельных запросов. Увеличивайте до насыщения сети при приемлемом CPU.
• На канале 10 Гбит/с настройка уже другая: крупнее chunk и выше параллелизм, иначе и CPU и RTT станут ограничителем.

Стабильность

• Следите за HTTP 429/503 и backoff: уменьшайте конкуренцию, если сервис сигналит перегрузку.
• Отдельно мониторьте долю ретраев и среднюю латентность. Частые ретраи «съедают» выигрыш от большого параллелизма.

Безопасность и целостность

Если есть жёсткие требования к целостности, используйте режимы, которые рассчитывают и проверяют контрольные суммы на стороне сервиса. В AWS CLI это удобно делать через низкоуровневые команды (s3api) с явными параметрами алгоритма контрольной суммы и шифрования. s5cmd подходит для скоростной массовой передачи; для «строгих» операций, где важна каждая деталь заголовков, зачастую проще вызвать s3api до/после загрузки, чтобы проверить метаданные и политики.

Типичные «грабли»

• Недооценка латентности: при высокой RTT увеличивайте параллелизм и размер частей, иначе скорость провалится на мелких файлах.
• Ограничения со стороны хранилища: если видите SlowDown — это сигнал снизить напор и сгладить очереди.
• FS-метаданные: миллионы мелких файлов забьют не сеть, а inode-операции. На генерации и чтении данных следите за нагрузкой на диск.
• Случайные «пропуски» при ручном батче: всегда проверяйте статистику «ожидалось/скопировано/ошибок» и делайте повторный проход по ошибкам.

Итоги: что выбрать

Если важна универсальность, «правильная» синхронизация и полный контроль над S3-фичами — выбирайте AWS CLI и при необходимости подключайте s3api. Для высокоскоростных операций с большим количеством объектов и батч-обработки — s5cmd почти всегда быстрее и проще в эксплуатации, особенно на VDS, где вы контролируете лимиты, окружение и расписание задач.

Практический компромисс: держите оба инструмента. AWS CLI — базовый слой и инфраструктурные процедуры; s5cmd — «ускоритель» для тяжелых потоков и разовых миграций. Тестируйте настройки на своих данных: стартуйте с 32–64 одновременных запросов и 32–64 МБ chunk, затем идите вверх до насыщения сети без всплеска ретраев и CPU.