ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Сравнить S3 vs EBS для checkpoint'ов 70B

1. Цель задачи

Оценить производительность (время сохранения и загрузки) и стоимость хранения чекпоинтов модели 70B параметров (~140 ГБ) при использовании Amazon S3 (объектное хранилище) и Amazon EBS (блочное хранилище, GP3/io2). На основе измерений построить decision‑matrix, позволяющую выбрать оптимальное хранилище для разных сценариев (частые чекпоинты vs редкие, длительное хранение vs временное).

Ключевой результат Набор метрик (latency p50/p99, throughput, cost/GB/месяц, cost/операцию) и анализ trade‑off для чекпоинтов 140 ГБ.

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального инструмента — симулируем:

1. Установить Python 3.10+, boto3, s3fs, fio, sysbench.
2. Создать синтетический файл размером 140 ГБ: fallocate -l 140G /tmp/checkpoint.bin (на файловой системе с достаточным местом).
3. Настроить bucket|S3 bucket (регион eu‑west‑1) и EBS volume типа gp3 (2000 IOPS, 500 MB/s throughput) того же размера 200 ГБ (чтобы хватило под чекпоинт + буфер).
4. Написать скрипт, который повторяет операции upload/download (S3) / read/write (EBS) с замером времени и через time или process_time().

3. Технологический стек

4. Этапы выполнения

Этап 1: Подготовка инфраструктуры (30 минут)

Действия

1. Создать EC2 инстанс (c6i.4xlarge) в выбранном регионе (например, eu‑west‑1).
   • Root‑диск: 50 ГБ gp3 (запас).
   • VPC, security group с разрешённым HTTPS/S3 доступом.
2. Создать EBS volume (gp3, 200 ГБ) и прикрепить его как /dev/xvdb.
   • Настроить IOPS 3000 (базовый), throughput 500 MB/s.
3. Создать bucket|S3 bucket (уникальное имя, стандартный класс, без публичного доступа).
4. Установить зависимости Python 3, boto3, s3fs, fio, sysbench, git.
5. Сгенерировать синтетический чекпоинт 140 ГБ на временном диске EC2 (если root‑диск мал – используем каталог на EBS второй том).
   • dd if=/dev/urandom of=/mnt/checkpoint.bin bs=1M count=7000 conv=fsync (займёт ~70001M = 7G? нет: 140 ГБ = 1401024 = 143360 МБ → count=143360).
   • Внимание Случайная запись 140 ГБ может быть медленной. Для ускорения можно использовать fallocate с длиной 140 G, если файловая система поддерживает.

Ожидаемый результат этапа Рабочая тестовая среда (EC2 + EBS + S3), готовый файл /mnt/checkpoint.bin.

Этап 2: Бенчмарк S3 (upload/download) (1 час)

Действия

1. Измерить чистое время upload чекпоинта 140 ГБ в S3.
   • Использовать aws s3 cp с флагом --no-progress и time.
   • Повторить 5 раз, зафиксировать каждое время.
   • Дополнительно: измерить multipart‑upload через boto3 и s3fs.
2. Измерить чистое время download того же файла из S3 в локальную папку.
   • Аналогично через aws s3 cp --recursive (один файл) с time.
3. Собрать метрики throughput (MB/s) = 140 * 1024 / time, latency p50/p99 если доступны (или просто среднее).
4. Примечание Убедиться, что инстанс и S3 в одном регионе для минимальной задержки.

Ожидаемый результат этапа Таблица с временами upload/download (по 5 запусков), средний/медианный throughput, оценка стоимости вызовов S3 (PUT/GET + egress в пределах региона бесплатно, но по стандарту S3 – плата за запросы).

Этап 3: Бенчмарк EBS write/read (1 час)

Действия

1. Подготовить EBS том создать на нём файловую систему XFS (или ext4), смонтировать в /mnt/ebs.
2. Измерить последовательную запись (write) 140 ГБ на EBS.
   • Скопировать /mnt/checkpoint.bin в /mnt/ebs/ командой cp, замерить через time.
   • Проверить, что файл не помещается в cache – использовать dd if=/mnt/checkpoint.bin of=/mnt/ebs/cp.bin bs=1M oflag=direct для прямого I/O.
   • Повторить 5 раз.
3. Измерить последовательное чтение (read) того же файла с EBS.
   • time dd if=/mnt/ebs/cp.bin of=/dev/null bs=1M iflag=direct.
   • Повторить 5 раз.
4. Зафиксировать IOPS, throughput (через iostat -x 1 30 во время операций), average latency.

Ожидаемый результат этапа Метрики write/read throughput, IOPS, latency для EBS gp3 (с 3000 IOPS). При необходимости повторить для другого типа EBS (io2 Block Express), изменив конфигурацию (это дополнительный этап, опционально).

Этап 4: Анализ cost/latency trade-off (1–2 часа)

Действия

1. Рассчитать стоимость хранения
   • S3 Standard: $0.023/ГБ/мес * 140 ≈ $3.22/мес.
   • EBS gp3 (200 ГБ): $0.08/ГБ/мес * 200 ≈ $16/мес.
   • (цены us-east‑1)
2. Рассчитать стоимость операций
   • S3: PUT стоимость $0.005 за 1000 запросов, GET $0.0004 за 1000 запросов. Для 140 ГБ (multipart ~parts) – пренебрежимо мало.
   • EBS: плата за хранение только (IOPS и throughput не дополнительно для gp3 до лимитов). Если требуется больше IOPS – доплата.
3. Сравнить метрики производительности
   • Построить таблицу: S3 throughput (upload/download), EBS write/read throughput, latency per 1 MB.
   • Рассчитать total time: save + load полного чекпоинта 140 ГБ.
4. Выделить сценарии
   • Частые чекпоинты (каждые 5–10 минут), хранятся временно (перезапись) → EBS, т.к. быстрее (нет HTTPS overhead).
   • Редкие чекпоинты (раз в час) с длительным хранением → S3, т.к. дешевле и не занимает локальный volume.
   • Гибрид: быстрый чекпоинт на EBS, затем асинхронная отправка на S3 для долговременного хранения.
5. Graph Показать latencies с error‑bar на графиках.

Ожидаемый результат этапа Decision‑matrix (таблица), содержащая для каждого сценария (частый/редкий/гибрид) рекомендуемое решение, стоимость и время. Краткие выводы.

Этап 5: Оформление отчёта (30 минут)

Действия

1. Создать документ с результатами
   • Методология, окружение, точные команды.
   • Таблицы с сырыми данными (5 замеров).
   • Графики latency/throughput (сравнение S3 vs EBS).
   • Анализ cost/latency trade-off и рекомендации.
2. Включить код скриптов тестирования (например, Python скрипты бенчмарка).
3. Указать ограничения (синтетический файл, не учитывает сети/регион, single‑threaded vs multi‑threaded).

Ожидаемый результат этапа Законченный отчёт в Markdown/PDF, доступный для ревью.

5. Критерии приемки (Definition of Done)

• Создана и корректно настроена среда EC2 + EBS + S3.
• Проведены минимум по 5 замеров upload/download для S3 и write/read для EBS.
• Получены надёжные метрики: время, throughput (MB/s), при необходимости latency p50/p99.
• Выполнен расчёт стоимости хранения и операций для каждого хранилища (на 1 месяц, 140 ГБ).
• Построен хотя бы один график сравнения (столбчатая диаграмма времени/стоимости).
• Сформулированы как минимум три сценария использования с конкретной рекомендацией.
• Отчёт доступен в виде Markdown-файла с таблицами и кодом бенчмарков (или ссылкой на репозиторий).
• Описаны возможные источники погрешности (синтетический файл, прямой I/O, cache effects).

6. Ожидаемый результат

Основной артефакт
report_benchmark_checkpoint_70B.md – отчёт, включающий:

• Описание конфигурации (инстанс, EBS gp3 200GB, Bucket Standard).
• Таблицы замеров (S3 upload, S3 download, EBS write, EBS read) – по 5 строк каждая.
• График: latency_comparison.png – столбцы (mean time для каждого типа операции) или box‑plot.
• Таблица cost analysis (ценовые данные на момент теста).
• Decision‑matrix (рекомендации для частых/двойных/редких чекпоинтов).
• Выводы и ограничения.

Дополнительные результаты

• Набор скриптов в отдельном файле benchmark.py или bash‑скрипте с командами.
• Лог выполнения (benchmark.log) с выхлопами time, iostat.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание При первом выполнении может потребоваться дополнительное время на настройку AWS (до 1 часа). Запас: +1 час на непредвиденные задержки (очистка кэша, повторные замеры, решение проблем с сетью).

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я создал(а) два отдельных AWS ресурса (S3 bucket и EBS volume) и прикрепил(а) их к EC2.
• Я сгенерировал(а) синтетический файл 140 ГБ и убедился(ась), что он не sparse (при dd с /dev/urandom или fallocate с последующей записью).
• Провёл(а) минимум 5 измерений для каждого типа операции (upload/download/write/read), зафиксировал(а) время.
• Очищал(а) кэш ОС между замерами (echo 3 > /proc/sys/vm/drop_caches) для EBS.
• Для S3 использовал(а) aws s3 cp с параметром --no-progress чтобы избежать искажения времени из-за вывода.
• Для EBS использовал(а) O_DIRECT (dd с direct) чтобы миновать кэш ФС.
• Записал(а) все настройки (тип инстанса, регион, размер/тип EBS, конфигурация S3 multipart) в отчёт.
• Рассчитал(а) среднее значение и медиану времени, throughput в MB/s, и стоимость.
• Сделал(а) выводы для минимум трёх сценариев (частые чекпоинты / редкие / гибрид) и указал(а) рекомендацию.
• Оформил(а) отчёт в Markdown с таблицами и графиком, приложил(а) скрипты/логи.