Как мы добились скорости загрузки выше, чем у AWS S3
Вам не всегда нужно самое быстрое облачное хранилище — ваши требования к производительности зависят от вашего варианта использования, бизнес-целей и потребностей в безопасности. Но все же, чем быстрее, тем лучше. А Backblaze только что анонсировала инновацию в облачном хранилище B2, которая обеспечивает гораздо большую скорость: загрузка большинства файлов теперь будет на 30% быстрее, чем в AWS S3.
Сегодня я углублюсь во все детали этого улучшения производительности, расскажу, как мы это сделали и что это значит для вас.
TL:DR
Результаты: согласно нашим тестам, клиенты, которые полагаются на загрузку небольших файлов (1 МБ или меньше), могут ожидать ускорения загрузки в среднем на 10–30 %, и все это без каких-либо изменений в надежности, доступности или цене.
Что это значит для тебя?
Все клиенты B2 Cloud Storage получат выгоду от этих улучшений производительности, особенно те, кто использует Backblaze B2 в качестве места хранения программного обеспечения для защиты данных. Небольшие загрузки размером 1 МБ или меньше составляют около 70% всех загрузок в облачное хранилище B2 и являются обычным явлением для рабочих процессов резервного копирования и архивирования. К конкретным преимуществам повышения производительности относятся:
Когда я могу ожидать более быстрой загрузки?
Сегодня. Обновления производительности были полностью развернуты во всех регионах хранения данных Backblaze.
Как мы это сделали
До этой работы, когда клиент загружал файл в Backblaze B2, данные записывались на несколько жестких дисков (HDD). Эти операции необходимо было завершить до возврата ответа клиенту. Теперь мы записываем входящие данные на те же жесткие диски, а также одновременно в пул твердотельных накопителей (SSD), который мы называем «тайником осколков», ожидая только того, пока записи с жесткого диска попадут в память файловых систем. кэши и запись на SSD завершаются перед возвратом ответа. После завершения записи на жесткий диск мы освобождаем место на твердотельных накопителях, чтобы его можно было использовать повторно.
Поскольку запись данных на SSD происходит намного быстрее, чем запись на жесткие диски, конечным результатом является более быстрая загрузка.
Это всего лишь краткое изложение; если вас интересуют технические подробности (а также результаты тщательного тестирования ), читайте дальше!
Путь к повышению производительности
Как вы, возможно, помните из многих сообщений в блогах и вебинарах Drive Stats, Backblaze хранит все данные о клиентах на жестких дисках, которые некоторые ласково называют «вращающейся ржавчиной». Исторически мы резервировали твердотельные накопители для загрузочных дисков Storage Pod (сервера хранения).
До настоящего времени.
Правильно — твердотельные накопители вошли в сферу хранения данных. Чтобы добиться такого повышения производительности, мы объединили производительность твердотельных накопителей с экономической эффективностью жестких дисков. Сначала я немного углублюсь в историю, чтобы добавить некоторый контекст к тому, как мы проводили обновления.
Жесткий диск против SSD
IBM выпустила первый жесткий диск еще в 1957 году, поэтому справедливо сказать, что HDD — это зрелая технология. Емкость накопителей и скорость передачи данных на протяжении десятилетий неуклонно росли, в то время как стоимость одного байта резко упала. Этот первый жесткий диск IBM RAMAC 350 имел общую емкость 3,75 МБ и стоил 34 500 долларов. С поправкой на инфляцию это около 375 000 долларов, что соответствует 100 000 долларов за МБ или 100 миллиардов долларов за ТБ в долларах 2023 года.
Фотография людей, заталкивающих один из первых жестких дисков в грузовик.
Первый жесткий диск, поставляемый IBM.
Сегодня версия Seagate Exos X16 емкостью 16 ТБ — жесткого диска, широко используемого в Backblaze B2 Storage Cloud, — продается по цене около 260 долларов США, 16,25 доллара США за ТБ. Если бы стоимость одного байта у него была такая же, как у IBM RAMAC 250, его можно было бы продать за 1,6 триллиона долларов — примерно столько же, сколько текущий ВВП Австралии!
SSD-накопители, напротив, существуют только с 1991 года, когда 20-мегабайтный диск SanDisk поставлялся в ноутбуки IBM ThinkPad по OEM-цене около 1000 долларов. Давайте рассмотрим современный SSD: Micron 7450 MAX емкостью 3,2 ТБ. Розничная цена Micron SSD составляет около 360 долларов, а цена составляет 112,50 долларов за ТБ, что почти в семь раз дороже, чем у жесткого диска Seagate.
Итак, жесткие диски легко превосходят твердотельные накопители по стоимости хранения, но как насчет производительности? Вот цифры из паспортов производителей:
Поскольку пластины жесткого диска вращаются с постоянной скоростью, в данном случае 7200 об/мин, они могут передавать больше блоков за один оборот на внешнем крае диска, чем ближе к середине — отсюда и две цифры скорости передачи данных X16.
SSD более чем в 20 раз быстрее при устойчивой передаче данных, чем HDD, но посмотрите на разницу в скорости произвольной передачи! Даже когда жесткий диск работает максимально быстро, передавая блоки с внешнего края диска, твердотельный накопитель читает данные более чем в 2200 раз быстрее и записывает почти в 900 раз быстрее.
Такая огромная разница связана с тем, что при чтении данных из случайных мест на диске пластинам приходится совершать в среднем 0,5 оборота между блоками. При скорости 7200 оборотов в минуту (об/мин) это означает, что жесткий диск тратит около 4,2 мс на переход к следующему блоку, прежде чем он сможет даже передать данные. Напротив, в технических характеристиках твердотельного накопителя указана задержка всего 80 мкс (это 0,08 мс) для чтения и 15 мкс (0,015 мс) для записи, что в 84–280 раз быстрее, чем у вращающегося диска.
Давайте рассмотрим реальную операцию, скажем, запись 64 КБ данных. Если предположить, что жесткий диск может записывать эти данные в последовательные секторы диска, он будет вращаться в среднем 4,2 мс, а затем потратит 0,25 мс на запись данных на диск, в общей сложности 4,5 мс. SSD, напротив, может мгновенно записывать данные в любое место, затрачивая на это всего 27 мкс (0,027 мс). Это (отчасти теоретическое) преимущество в скорости в 167 раз является основой улучшения производительности.
Почему я выбрал блок размером 64 КБ? Как мы упоминали в недавнем сообщении в блоге, посвященном производительности облачного хранилища, в целом файлы большего размера лучше, когда речь идет о совокупном времени, необходимом для загрузки набора данных. Однако могут существовать и другие требования, требующие использования файлов меньшего размера. Многие приложения резервного копирования разбивают данные на блоки фиксированного размера для загрузки в виде файлов в облачное объектное хранилище. При выборе размера блока существует компромисс: блоки большего размера улучшают скорость резервного копирования, а блоки меньшего размера уменьшают требуемый объем хранилища. На практике блоки резервных копий могут иметь размер всего 1 МБ или даже 256 КБ. Блоки по 64 КБ, которые мы использовали в приведенных выше расчетах, представляют собой фрагменты, составляющие файл размером 1 МБ.
Задача, стоящая перед нашими инженерами, заключалась в том, чтобы воспользоваться преимуществами скорости твердотельных накопителей для ускорения загрузки небольших файлов без больших затрат.
Улучшение производительности записи небольших файлов
Когда клиентское приложение загружает файл в Backblaze B2 Storage Cloud, модуль координатора разбивает файл на 16 сегментов данных, создает четыре дополнительных сегмента четности и записывает полученные 20 сегментов на 20 разных жестких дисков, каждый в отдельный модуль.
Примечание. По мере увеличения емкости жесткого диска увеличивается и время, необходимое для восстановления после сбоя диска, поэтому мы периодически корректируем соотношение между сегментами данных и фрагментами четности, чтобы поддерживать целевой уровень надежности в одиннадцать девяток. Раньше вы слышали, как мы говорили о соотношении 17 + 3, но мы также используем 16 + 4, а в наших новейших хранилищах используется схема 15 + 5.
Каждый под записывает входящий осколок в свою локальную файловую систему; на практике это означает, что данные записываются в кэш в памяти и будут записаны на физический диск в какой-то момент в ближайшем будущем. Любые запросы к файлу могут быть удовлетворены из кэша, но данные еще не сохранены постоянно.
Мы должны быть абсолютно уверены, что сегменты были записаны на диск, прежде чем мы вернем ответ «успех» клиенту, поэтому каждый под выполняет системный вызов fsync для передачи («сброса») данных сегментов из системной памяти через жесткий диск. записать кеш на сам диск перед возвратом его статуса координатору. Когда координатор получил как минимум 19 успешных ответов, он возвращает ответ об успехе клиенту. Это гарантирует, что даже если весь центр обработки данных отключится от электропитания сразу после загрузки, данные будут сохранены.
Как мы объяснили выше, для небольших блоков данных подавляющая часть времени, затрачиваемого на запись данных на диск, тратится на ожидание поворота диска в правильное место. Запись сегментов на SSD может привести к значительному увеличению производительности для небольших файлов, но как насчет семикратной разницы в стоимости?
Наши инженеры придумали, как получить кусок пирога и съесть его, используя скорость твердотельных накопителей без значительного увеличения стоимости. Теперь, получив файл размером 1 МБ или меньше, координатор, как и раньше, разбивает его на шарды, а затем одновременно отправляет шарды набору из 20 подов и отдельному пулу серверов, каждый из которых заполнен 10 описанными выше твердотельными накопителями Micron — «тайник осколков». Серверы Shard Stash легко выигрывают гонку «сбросить данные на диск» и возвращают свой статус координатору всего за несколько миллисекунд. Тем временем каждый модуль жесткого диска записывает свой сегмент в файловую систему, ставит в очередь задачу по сбросу данных сегмента на диск и возвращает подтверждение координатору.
Как только координатор получает ответы, подтверждающие, что по крайней мере 19 из 20 подов записали свои шарды в файловую систему и по крайней мере 19 из 20 шардов были сброшены на SSD, он возвращает свой ответ клиенту. Опять же, если в этот момент произойдет сбой питания, данные уже будут безопасно записаны в твердотельное хранилище.
Мы не хотим оставлять данные на твердотельных накопителях дольше, чем необходимо, поэтому каждый под, закончив запись своего шарда на диск, сигнализирует тайнику шарда, что он может очистить свою копию шарда.
Реальный прирост производительности
Как я уже упоминал выше, рассчитанное 167-кратное преимущество SSD в производительности над HDD является в некоторой степени теоретическим. В реальном мире время, необходимое для загрузки файла, также зависит от ряда других факторов: близости к центру обработки данных, скорости сети, а также всего программного и аппаратного обеспечения между клиентским приложением и устройством хранения данных, и это лишь некоторые из них.
Первым регионом Backblaze, получившим повышение производительности, стал Восток США, расположенный в Рестоне, штат Вирджиния. За 12-дневный период после развертывания тайника осколков среднее время загрузки файла размером 256 КБ составило 118 мс, а файла размером 1 МБ — 137 мс. Чтобы воспроизвести типичную клиентскую среду, мы запустили тестовое приложение в дата-центре нашего партнера Vultr в Нью-Джерси, загрузив данные в Backblaze B2 через общедоступный Интернет.
Для сравнения мы провели тот же тест на восточном регионе США (Северная Вирджиния) Amazon S3, us-east-1на той же машине в Нью-Джерси. В среднем загрузка файла размером 256 КБ на S3 занимала 157 мс, а файла размером 1 МБ — 153 мс.
Итак, сравнивая Backblaze B2 в восточном регионе США с эквивалентом Amazon S3, мы оценили новый улучшенный Backblaze B2 как на 30 % быстрее, чем S3 для файлов размером 256 КБ, и на 10% быстрее, чем S3 для файлов размером 1 МБ.
Эти низкоуровневые тесты были подтверждены, когда мы засекли время, когда программное обеспечение Veeam Backup & Replication выполняло резервное копирование 1 ТБ виртуальных машин с размером блока 256 КБ. Резервное копирование сервера на Amazon S3 заняло три часа 12 минут; мы измерили время того же резервного копирования на Backblaze B2 всего за два часа 15 минут, что на 40 % быстрее, чем у S3.
Методика тестирования
Мы написали простое тестовое приложение Python с использованием AWS SDK для Python (Boto3). Каждый тестовый запуск включал синхронизацию 100 загрузок файлов с использованием API S3 PutObject с задержкой 10 мс между каждой загрузкой. (К вашему сведению, задержка не включена в измеренное время.) Тестовое приложение использовало одно соединение HTTPS во время тестового запуска, следуя рекомендациям по использованию API. В течение последних нескольких недель мы проводили тестирование на виртуальной машине в регионе Vultr в Нью-Джерси каждые шесть часов в течение последних нескольких недель как для нашего восточного региона США, так и для его соседа по AWS. Задержка до конечной точки API Backblaze B2 составила в среднем 5,7 мс, до конечной точки API Amazon S3 — 7,8 мс, измеренная по 100 пинг-запросам.
Что дальше?
На момент написания серверы Shard Stash были развернуты во всех наших центрах обработки данных во всех наших регионах. На самом деле, вы, возможно, даже заметили, что небольшие файлы загружаются быстрее. Важно отметить, что эта конкретная оптимизация — лишь одно из серии улучшений производительности, которые мы реализовали, и их будет еще больше. Можно с уверенностью сказать, что все наши клиенты Backblaze B2 будут наслаждаться более быстрой загрузкой и выгрузкой, независимо от нагрузки на их хранилище.
Сегодня я углублюсь во все детали этого улучшения производительности, расскажу, как мы это сделали и что это значит для вас.
TL:DR
Результаты: согласно нашим тестам, клиенты, которые полагаются на загрузку небольших файлов (1 МБ или меньше), могут ожидать ускорения загрузки в среднем на 10–30 %, и все это без каких-либо изменений в надежности, доступности или цене.
Что это значит для тебя?
Все клиенты B2 Cloud Storage получат выгоду от этих улучшений производительности, особенно те, кто использует Backblaze B2 в качестве места хранения программного обеспечения для защиты данных. Небольшие загрузки размером 1 МБ или меньше составляют около 70% всех загрузок в облачное хранилище B2 и являются обычным явлением для рабочих процессов резервного копирования и архивирования. К конкретным преимуществам повышения производительности относятся:
- Быстрее защищает данные при удаленном резервном копировании.
- Освобождает время ИТ-администраторов для работы над другими проектами.
- Уменьшает перегрузку пропускной способности сети.
- Более эффективная дедупликация данных.
Veeam стремится работать вместе с нашими партнерами над внедрением инноваций и созданием единого фронта против киберугроз и атак. Новые улучшения производительности, выпущенные Backblaze для облачного хранилища B2, способствуют реализации нашей миссии по обеспечению радикальной устойчивости наших общих клиентов.Андреас Нойферт, вице-президент по управлению продуктами, альянсы, Veeam
Когда я могу ожидать более быстрой загрузки?
Сегодня. Обновления производительности были полностью развернуты во всех регионах хранения данных Backblaze.
Как мы это сделали
До этой работы, когда клиент загружал файл в Backblaze B2, данные записывались на несколько жестких дисков (HDD). Эти операции необходимо было завершить до возврата ответа клиенту. Теперь мы записываем входящие данные на те же жесткие диски, а также одновременно в пул твердотельных накопителей (SSD), который мы называем «тайником осколков», ожидая только того, пока записи с жесткого диска попадут в память файловых систем. кэши и запись на SSD завершаются перед возвратом ответа. После завершения записи на жесткий диск мы освобождаем место на твердотельных накопителях, чтобы его можно было использовать повторно.
Поскольку запись данных на SSD происходит намного быстрее, чем запись на жесткие диски, конечным результатом является более быстрая загрузка.
Это всего лишь краткое изложение; если вас интересуют технические подробности (а также результаты тщательного тестирования ), читайте дальше!
Путь к повышению производительности
Как вы, возможно, помните из многих сообщений в блогах и вебинарах Drive Stats, Backblaze хранит все данные о клиентах на жестких дисках, которые некоторые ласково называют «вращающейся ржавчиной». Исторически мы резервировали твердотельные накопители для загрузочных дисков Storage Pod (сервера хранения).
До настоящего времени.
Правильно — твердотельные накопители вошли в сферу хранения данных. Чтобы добиться такого повышения производительности, мы объединили производительность твердотельных накопителей с экономической эффективностью жестких дисков. Сначала я немного углублюсь в историю, чтобы добавить некоторый контекст к тому, как мы проводили обновления.
Жесткий диск против SSD
IBM выпустила первый жесткий диск еще в 1957 году, поэтому справедливо сказать, что HDD — это зрелая технология. Емкость накопителей и скорость передачи данных на протяжении десятилетий неуклонно росли, в то время как стоимость одного байта резко упала. Этот первый жесткий диск IBM RAMAC 350 имел общую емкость 3,75 МБ и стоил 34 500 долларов. С поправкой на инфляцию это около 375 000 долларов, что соответствует 100 000 долларов за МБ или 100 миллиардов долларов за ТБ в долларах 2023 года.
Фотография людей, заталкивающих один из первых жестких дисков в грузовик.
Первый жесткий диск, поставляемый IBM.
Сегодня версия Seagate Exos X16 емкостью 16 ТБ — жесткого диска, широко используемого в Backblaze B2 Storage Cloud, — продается по цене около 260 долларов США, 16,25 доллара США за ТБ. Если бы стоимость одного байта у него была такая же, как у IBM RAMAC 250, его можно было бы продать за 1,6 триллиона долларов — примерно столько же, сколько текущий ВВП Австралии!
SSD-накопители, напротив, существуют только с 1991 года, когда 20-мегабайтный диск SanDisk поставлялся в ноутбуки IBM ThinkPad по OEM-цене около 1000 долларов. Давайте рассмотрим современный SSD: Micron 7450 MAX емкостью 3,2 ТБ. Розничная цена Micron SSD составляет около 360 долларов, а цена составляет 112,50 долларов за ТБ, что почти в семь раз дороже, чем у жесткого диска Seagate.
Итак, жесткие диски легко превосходят твердотельные накопители по стоимости хранения, но как насчет производительности? Вот цифры из паспортов производителей:
Поскольку пластины жесткого диска вращаются с постоянной скоростью, в данном случае 7200 об/мин, они могут передавать больше блоков за один оборот на внешнем крае диска, чем ближе к середине — отсюда и две цифры скорости передачи данных X16.
SSD более чем в 20 раз быстрее при устойчивой передаче данных, чем HDD, но посмотрите на разницу в скорости произвольной передачи! Даже когда жесткий диск работает максимально быстро, передавая блоки с внешнего края диска, твердотельный накопитель читает данные более чем в 2200 раз быстрее и записывает почти в 900 раз быстрее.
Такая огромная разница связана с тем, что при чтении данных из случайных мест на диске пластинам приходится совершать в среднем 0,5 оборота между блоками. При скорости 7200 оборотов в минуту (об/мин) это означает, что жесткий диск тратит около 4,2 мс на переход к следующему блоку, прежде чем он сможет даже передать данные. Напротив, в технических характеристиках твердотельного накопителя указана задержка всего 80 мкс (это 0,08 мс) для чтения и 15 мкс (0,015 мс) для записи, что в 84–280 раз быстрее, чем у вращающегося диска.
Давайте рассмотрим реальную операцию, скажем, запись 64 КБ данных. Если предположить, что жесткий диск может записывать эти данные в последовательные секторы диска, он будет вращаться в среднем 4,2 мс, а затем потратит 0,25 мс на запись данных на диск, в общей сложности 4,5 мс. SSD, напротив, может мгновенно записывать данные в любое место, затрачивая на это всего 27 мкс (0,027 мс). Это (отчасти теоретическое) преимущество в скорости в 167 раз является основой улучшения производительности.
Почему я выбрал блок размером 64 КБ? Как мы упоминали в недавнем сообщении в блоге, посвященном производительности облачного хранилища, в целом файлы большего размера лучше, когда речь идет о совокупном времени, необходимом для загрузки набора данных. Однако могут существовать и другие требования, требующие использования файлов меньшего размера. Многие приложения резервного копирования разбивают данные на блоки фиксированного размера для загрузки в виде файлов в облачное объектное хранилище. При выборе размера блока существует компромисс: блоки большего размера улучшают скорость резервного копирования, а блоки меньшего размера уменьшают требуемый объем хранилища. На практике блоки резервных копий могут иметь размер всего 1 МБ или даже 256 КБ. Блоки по 64 КБ, которые мы использовали в приведенных выше расчетах, представляют собой фрагменты, составляющие файл размером 1 МБ.
Задача, стоящая перед нашими инженерами, заключалась в том, чтобы воспользоваться преимуществами скорости твердотельных накопителей для ускорения загрузки небольших файлов без больших затрат.
Улучшение производительности записи небольших файлов
Когда клиентское приложение загружает файл в Backblaze B2 Storage Cloud, модуль координатора разбивает файл на 16 сегментов данных, создает четыре дополнительных сегмента четности и записывает полученные 20 сегментов на 20 разных жестких дисков, каждый в отдельный модуль.
Примечание. По мере увеличения емкости жесткого диска увеличивается и время, необходимое для восстановления после сбоя диска, поэтому мы периодически корректируем соотношение между сегментами данных и фрагментами четности, чтобы поддерживать целевой уровень надежности в одиннадцать девяток. Раньше вы слышали, как мы говорили о соотношении 17 + 3, но мы также используем 16 + 4, а в наших новейших хранилищах используется схема 15 + 5.
Каждый под записывает входящий осколок в свою локальную файловую систему; на практике это означает, что данные записываются в кэш в памяти и будут записаны на физический диск в какой-то момент в ближайшем будущем. Любые запросы к файлу могут быть удовлетворены из кэша, но данные еще не сохранены постоянно.
Мы должны быть абсолютно уверены, что сегменты были записаны на диск, прежде чем мы вернем ответ «успех» клиенту, поэтому каждый под выполняет системный вызов fsync для передачи («сброса») данных сегментов из системной памяти через жесткий диск. записать кеш на сам диск перед возвратом его статуса координатору. Когда координатор получил как минимум 19 успешных ответов, он возвращает ответ об успехе клиенту. Это гарантирует, что даже если весь центр обработки данных отключится от электропитания сразу после загрузки, данные будут сохранены.
Как мы объяснили выше, для небольших блоков данных подавляющая часть времени, затрачиваемого на запись данных на диск, тратится на ожидание поворота диска в правильное место. Запись сегментов на SSD может привести к значительному увеличению производительности для небольших файлов, но как насчет семикратной разницы в стоимости?
Наши инженеры придумали, как получить кусок пирога и съесть его, используя скорость твердотельных накопителей без значительного увеличения стоимости. Теперь, получив файл размером 1 МБ или меньше, координатор, как и раньше, разбивает его на шарды, а затем одновременно отправляет шарды набору из 20 подов и отдельному пулу серверов, каждый из которых заполнен 10 описанными выше твердотельными накопителями Micron — «тайник осколков». Серверы Shard Stash легко выигрывают гонку «сбросить данные на диск» и возвращают свой статус координатору всего за несколько миллисекунд. Тем временем каждый модуль жесткого диска записывает свой сегмент в файловую систему, ставит в очередь задачу по сбросу данных сегмента на диск и возвращает подтверждение координатору.
Как только координатор получает ответы, подтверждающие, что по крайней мере 19 из 20 подов записали свои шарды в файловую систему и по крайней мере 19 из 20 шардов были сброшены на SSD, он возвращает свой ответ клиенту. Опять же, если в этот момент произойдет сбой питания, данные уже будут безопасно записаны в твердотельное хранилище.
Мы не хотим оставлять данные на твердотельных накопителях дольше, чем необходимо, поэтому каждый под, закончив запись своего шарда на диск, сигнализирует тайнику шарда, что он может очистить свою копию шарда.
Реальный прирост производительности
Как я уже упоминал выше, рассчитанное 167-кратное преимущество SSD в производительности над HDD является в некоторой степени теоретическим. В реальном мире время, необходимое для загрузки файла, также зависит от ряда других факторов: близости к центру обработки данных, скорости сети, а также всего программного и аппаратного обеспечения между клиентским приложением и устройством хранения данных, и это лишь некоторые из них.
Первым регионом Backblaze, получившим повышение производительности, стал Восток США, расположенный в Рестоне, штат Вирджиния. За 12-дневный период после развертывания тайника осколков среднее время загрузки файла размером 256 КБ составило 118 мс, а файла размером 1 МБ — 137 мс. Чтобы воспроизвести типичную клиентскую среду, мы запустили тестовое приложение в дата-центре нашего партнера Vultr в Нью-Джерси, загрузив данные в Backblaze B2 через общедоступный Интернет.
Для сравнения мы провели тот же тест на восточном регионе США (Северная Вирджиния) Amazon S3, us-east-1на той же машине в Нью-Джерси. В среднем загрузка файла размером 256 КБ на S3 занимала 157 мс, а файла размером 1 МБ — 153 мс.
Итак, сравнивая Backblaze B2 в восточном регионе США с эквивалентом Amazon S3, мы оценили новый улучшенный Backblaze B2 как на 30 % быстрее, чем S3 для файлов размером 256 КБ, и на 10% быстрее, чем S3 для файлов размером 1 МБ.
Эти низкоуровневые тесты были подтверждены, когда мы засекли время, когда программное обеспечение Veeam Backup & Replication выполняло резервное копирование 1 ТБ виртуальных машин с размером блока 256 КБ. Резервное копирование сервера на Amazon S3 заняло три часа 12 минут; мы измерили время того же резервного копирования на Backblaze B2 всего за два часа 15 минут, что на 40 % быстрее, чем у S3.
Методика тестирования
Мы написали простое тестовое приложение Python с использованием AWS SDK для Python (Boto3). Каждый тестовый запуск включал синхронизацию 100 загрузок файлов с использованием API S3 PutObject с задержкой 10 мс между каждой загрузкой. (К вашему сведению, задержка не включена в измеренное время.) Тестовое приложение использовало одно соединение HTTPS во время тестового запуска, следуя рекомендациям по использованию API. В течение последних нескольких недель мы проводили тестирование на виртуальной машине в регионе Vultr в Нью-Джерси каждые шесть часов в течение последних нескольких недель как для нашего восточного региона США, так и для его соседа по AWS. Задержка до конечной точки API Backblaze B2 составила в среднем 5,7 мс, до конечной точки API Amazon S3 — 7,8 мс, измеренная по 100 пинг-запросам.
Что дальше?
На момент написания серверы Shard Stash были развернуты во всех наших центрах обработки данных во всех наших регионах. На самом деле, вы, возможно, даже заметили, что небольшие файлы загружаются быстрее. Важно отметить, что эта конкретная оптимизация — лишь одно из серии улучшений производительности, которые мы реализовали, и их будет еще больше. Можно с уверенностью сказать, что все наши клиенты Backblaze B2 будут наслаждаться более быстрой загрузкой и выгрузкой, независимо от нагрузки на их хранилище.
