LINUX.ORG.RU

Amazon S3

 , , ,


2

2

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

Недавно Амазон объявил о переходе с модели eventual consistency на strong consistency, то есть read-after-write consistency.
А также есть статья в блоге некоего высокопоставленного манагера из Амазона:
https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html — Diving Deep on S3 Consistency

Первое, что думается в ответ на эти новости: а как же теорема CAP? Подсказки для этого ответа ищутся в гугле:

https://news.ycombinator.com/item?id=25271791

So they claim performance and availability will remain same while claiming strong consistency. I was confused at first but then “same” availability isn’t 100% availability. So it indeed CP.
https://www.scalefactory.com/blog/2020/12/03/s3-small-announcement-big-impact/
In this paper about Spanner, we learn that it’s possible to build a CA system (one which prioritises Consistency and Availability) and also build a network so good that the risk of Partitions to be Tolerant of is negligible enough to effectively ignore.

Короче говоря, CAP никуда не делось, вечного двигателя, сверхсветовой передачи информации, или телепорта в амазоне не изобрели. Амазон пошел по логичному пути: пока нет ни единого разрыва сети, БД дает consistency+availability гарантии, когда сеть рвется — запросы на запись перестают выполняться, имеющиеся данные замораживаюся в том систоянии, в котором они были до разрыва.

Теперь по самой реализации. Инфа в гугле крайне скудная, пока что лучшее, что удалось найти:
https://www.reddit.com/r/aws/comments/k4yknz/s3_strong_consistency/gecdohv/

If I had to guess, s3 synchronously writes to a cluster of storage nodes before returning success, and then asynchronously replicates it to other nodes for stronger durability and availability. There used to be a risk of reading from a node that didn't receive a file's change yet, which could give you an outdated file. Now they added logic so the lookup router is aware of how far an update is propagated and can avoid routing reads to stale replicas.

Судя по всему, ключевым архитектором сего чуда был некто Нихил Шах:
https://www.linkedin.com/in/nikhiljshah/

DATA ITEM AND WITNESS SERVICE PARTITIONING IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P73159-US01

TRANSACTION MANAGEMENT FOR MONOTONIC WRITE CONSISTENCY IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P74530-US01

Первое, что находится в гугле по запросам «strong consistency witness» и «monotonic writes witness» — это статьи:

http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf - Voting with Witnesses: A Consistency Scheme for Replicated Files
https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

Первая статья делает акцент на quorum-based консенсусе — это весьма медленная штука и я сомневаюсь, что амазон смог бы отрапортовать про бесплатный апгрейд согласованности данных, если бы оная для простого чтения требовала еще одной круговой задержки по всему кластеру. Из этой же оперы идет статья с модификацией Apache ZooKeeper:

https://www.usenix.org/system/files/fast20-ganesan.pdf - Strong and Efficient Consistency with Consistency-Aware Durability

Здесь авторы просто отложили операции записи, за счет чего уменьшили время ответа по запросам записи до уровня асинхронной репликации (и потеряли гарантии сохранности при исчезновении питания, но кого это волнует в 2022?). Монотонность чтений без необходимости опроса всего кластера «гарантировали» списком активных узлов, которые получили актуальные изменения и знают об этом. Можно спорить по поводу того, вовремя ли отвалившиеся узлы поймут, что у них уже нет актуальных данных, и потому сериализуемы ли чтения по кластеру, но ведь чтения несериализуемы даже в оригинальном ZooKeeper по абсолютно той же причине (узел может продолжать думать, что он лидер, хотя в кластере выбран новый лидер) — так что вроде как ухудшения нету.

Вот я сидел-сидел, думал-думал, и подумал «а зачем здесь полный консенсус?». Соответственно, взор мой возвращается снова на

https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

где авторы используют свидетелей просто как избыточное eventual consistency хранилище. Вам ничего это не напоминает? Мне напоминает устройство S3 до введения строгой согласованности.

Лично я склоняюсь к тому, что Амазон под капотом S3 оставил тот же самый eventual consistency, работающий на типичной для той же Amazon DynamoDB модели «sloppy consensus», например, когда у вас 10 узлов в сети и для подтверждения записи достаточно подтверждения от 3 узлов (а не шести, как это было бы в строгом консенсусе). Данные со временем будут раскопированы асинхронно на остальные узлы. Естественно, sloppy consensus никак не защищает от split brain, когда у вас две части кластера теряют связь и начинают независимо изменять файлы (в обоих частях есть по три узла для успешного подтверждения), и потому не знают про изменения в другой части кластера. Очевидно, при восстановлении связи нужно как-то конфликтные изменения разруливать. Amazon DynamoDB и Riak уже давно используют решение «в лоб» — оставлять запись с самым последним timestamp. Ту же политику декларирует S3:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#Consistenc...

Amazon S3 does not support object locking for concurrent writers. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins.

Совпадение? Не думаю. По итогу воображается что-то такое:

https://habrastorage.org/webt/ve/c9/ua/vec9uatqx1zht2814ljj-ipvipm.png

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

Как можно заметить, я нарисовал четыре стрелки от кэша к хранилищу — это минимальное количество связей, которое нужно для гарантированного получения данных, залитых на 2 из 5 хранилищ. В принципе, используя информацию из оповещения кэш может стучаться только в два первых хранилища, в которые данные будут размещены раньше всего. Конечно, может оказаться так, что данные уже нужны, а они даже в первые хранилища не залиты — это достаточно редкая ситуация, которую можно разрулить через запрос «отдай мне данные версии XXX, если они у тебя уже есть».

Здесь возникает множество подводных камней при потери связи между узлами. Например, кэш может так и не дождаться ответа на «отдай мне данные версии XXX». Но проблема может быть еще серьезнее: что если кэш вообще не получил уведомления и до сих пор считает, будто данные остались в своей старой версии? Вот это и есть вся фишка CAP и недосказанности со стороны Амазона — а ничего не делать, тупо выдавать старую версию файла, хотя уже давно есть новая. Скрестим пальчики и будем надеяться, что ситуация февраля 2017 года больше никогда не повторится.

★★★★

Ответ на: комментарий от Miguel

И чо?

Например, то, что там под капотом трешак, который отвалится как при сбое каналов связи в амазоне. так и при отказе достаточно большого числа серверов. Можно назвать это «reliability through obscurity», примерно как классический энтерпрайз плана «вот эту кнопку не жми, потому что система упадет и тебя уволят».

Забавно, что при этом находятся люди с мнением вроде «Амазон знает что делает», «будущее за облаками», и так далее — я перевернул картину другой стороной, и стало видно, что на самом деле S3 держится на соплях и иконе пресвятой богоматери.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)

Уже какое-то время наблюдаю как вы пытаетесь натянуть сову на глобус(параллельные вычисления на питон) вместо того чтобы использовать инструменты специально для этого предназначенные. Не понимаю зачем, но это ваше дело.

И тут та же история. Казалось бы, с S3 всё просто, или вас устраивают гарантии, скорость и цена - тогда вы просто пользуетесь их услугами, или вас не устраивает предложение от Амазон - тогда ищите другой сервис либо делаете свое.

К чему всё это? Амазон всех обманывает?

curver
()
Ответ на: комментарий от curver

Казалось бы, с S3 всё просто, или вас устраивают гарантии, скорость и цена - тогда вы просто пользуетесь их услугами, или вас не устраивает предложение от Амазон - тогда ищите другой сервис либо делаете свое

Ну как бы я с самого начала так и написал, но тут как бы NDA, хотя бы неформальное.

К чему всё это? Амазон всех обманывает?

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

byko3y ★★★★
() автор топика

Уже собрался-было публиковать стать, и тут внезапно понял, что не могу придумать эффективной схемы работы кэша в случае, когда некие объекты изначально не находятся в кэше, и при этом находятся в процессе асинхронной репликации. Сыпать сообщения от N хранилищ к M наблюдателям — такая-себе затея. Делать одного-двух-трех лидеров — значит сильно резать производительность кластера.

Судя по всему, эту проблема Амазон решил через тот же механизм, который они используют для репликации и оповещений, то есть, асинхронная репликация хорошо контролируема, и таким образом этот же механизм позволяет решить проблему «где сейчас достать самую актуальную версию объекта XXX/YYY/ZZZ».

К'мон, неужели никому кроме меня не интересна реализация S3? Мне же за этой исследование никто не заплатит, я тупо для собственного понимания этим занимаюсь, и для вас же публикую — неужели всем остальным достаточно только подергать за ручки панели AWS?

byko3y ★★★★
() автор топика
23 февраля 2022 г.
Ответ на: комментарий от byko3y

Почти все люди доходят до стадии «лишь бы деньги платили, а всё остальное пофиг». Я к тому, правильно делаешь, что на хабр постишь. Хоть плюсики получишь. И в одном месте всё.

anonymous
()
Ответ на: комментарий от byko3y

К’мон, неужели никому кроме меня не интересна реализация S3? Мне же за этой исследование никто не заплатит, я тупо для собственного понимания этим занимаюсь, и для вас же публикую — неужели всем остальным достаточно только подергать за ручки панели AWS?

А что там интересного? Версионирование на таймстампах и стратегия ласт-врайт - вин?

Поробуй базу данных на фронтенде добавить в js. Так окунешся в распеделенные системы, что тошнить будет.

TDrive ★★★★★
()
Ответ на: комментарий от urxvt

Амазон aws не про это. Он - про дешевизну и про глобальность. Когда создаёшь контейнер / виртуалку и поднимаешь её по всему миру за 3 минуты, за $50 в месяц, условно говоря. Дешевле другими способами не сделаешь в данный момент времени. Все остальные конкуренты всегда предлагали либо аналогичную, либо гораздо более дорогую цену. Т.ч. Амазон берёт доступностью и ценами. Понятно, что своя техника, в конечном счёте, обойдётся дешевле и часто не хуже амазон. Но. Потребуется софт. Для виртуалок - различные vmware (только они предлагают фичастые много датацентровые миграции и менеджмент), короче, дело далее за софтом и дешёвой сетью, в глобальном контексте, а это уже рост расходов на порядок зачастую. Т.ч. всё упирается в деньги

menangen ★★★★★
()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от byko3y

неужели всем остальным достаточно только подергать за ручки панели AWS?

Нахрена мне AWS? Я всегда дома могу поднять сервак на статичном IP и с репликой на рабочем IP. Настроить днс со всякими робин-бобинами. А провайдеры сейчас дают 1 Гбит/с, т.е. в сумме у меня 2 Гбит/с, в крайнем случае 1 Гбит/с.

А когда хватит мозгов/денег при выходе на объемы, то заказать разработку кастомного сервака со 100500 эпик ядрами и петабайтами оперативки объединенных по PCI-e шине и грамотным проектированием бекенда с принципом один сервак на континент, тем самым пересечение по БД будем минимальным.

и для вас же публикую

Остальным похрен как там индусы сделали бекенд, ты это до сих пор не понимаешь? 95% жрут дерьмо и улыбаются. Кому не похрен делают своё кастомное решение.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от urxvt

То что Амазон говно, понятно по его убогому и неудобному интерфесу

Так убогий неудобный инетрфейс — это ведь норма нынче. Амазон просто идет в ногу со временем.

byko3y ★★★★
() автор топика
Ответ на: комментарий от TDrive

А что там интересного? Версионирование на таймстампах и стратегия ласт-врайт - вин?

Основная проблема заключается в том, что поверх слабо согласованного о-о-очень большого хранилища файлов нужно выстроить сильно согласованное хранилище метаданных. В статье я с пруфами и догадками пытался показать, почему Amazon (и не только он, на самом деле) не смог реализовать такую архитектуру сразу, как по итогу он ее реализовал с минимальными телодвижениями, и какие неафишируемые и неустранимые ограничения на самом деле у новой модели S3 есть. Это сильно больше, чем «версионирование на таймстампах».

Поробуй базу данных на фронтенде добавить в js. Так окунешся в распеделенные системы, что тошнить будет

Спасибо, прошлые 9 лет в основном именно толстые клиенты и разрабатывал. Да, тошнило. Меня больше всего обескураживает тот факт, что вот я теперь умею строить распределенные системы — казалось бы, всем это нужно, да? А хрен там: идешь на вакашки по распределенке. и что ты там видишь? Докер, AWS. Или «специалист по распределенным системам, требования — глубокое понимание механизмов оптимизации SQL запросов» — чиво бл? Какие к черту SQL-запросы в распределенных системах? SQL — это антипод распределенности, именно потому распределенные системы стали NoSQL, но быстро снова пришли к транзакциям, что теперь называется NewSQL, хотя корректнее это было бы назвать DTL — Distributed Transaction Language.

byko3y ★★★★
() автор топика
Ответ на: комментарий от menangen

Когда создаёшь контейнер / виртуалку и поднимаешь её по всему миру за 3 минуты, за $50 в месяц, условно говоря

При том, что у бюджетных хостеров аналогичные три виртуалки будут стоить $15/месяц с бесплатным трафиком, а на трафике из амазона ты заплатишь намного больше $50 за месяц, если превысишь бесплатный лимит в 100 ГБ/месяц. Меня улыбает эта ценовая политика амазона, когда при росте количества потребляемых ресурсов цена на них не падает, а растёт. Типа «первая доза — бесплатно».

Все остальные конкуренты всегда предлагали либо аналогичную, либо гораздо более дорогую цену

Кто «все»? Гугл, MS? На них хостинг в мире закончился? Или ты мне расскажешь о том, что я не могу прожить без присутствия моих серверов в Кейп Таун или Бахрейне?

Понятно, что своя техника, в конечном счёте, обойдётся дешевле и часто не хуже амазон. Но. Потребуется софт. Для виртуалок - различные vmware

Берешь и покупаешь готовый VPS. Если ты купил выделенный сервер, то зачем тебе там виртуалка?

byko3y ★★★★
() автор топика
Ответ на: комментарий от foror

А когда хватит мозгов/денег при выходе на объемы, то заказать разработку кастомного сервака со 100500 эпик ядрами и петабайтами оперативки объединенных по PCI-e шине и грамотным проектированием бекенда с принципом один сервак на континент, тем самым пересечение по БД будем минимальным

Зачем заказывать. Они уже продаются.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

Со 100500 эпик ядрами и петабайтами оперативки? И какой прайс на них установили? Пара миллиардов долларов при себестоимости в один миллион долларов? Ты ещё скажи суперкомпьютеры продаются, хоть сейчас в днс заказывай.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Со 100500 эпик ядрами и петабайтами оперативки? И какой прайс на них установили? Пара миллиардов долларов при себестоимости в один миллион долларов? Ты ещё скажи суперкомпьютеры продаются, хоть сейчас в днс заказывай

Supermicro AS-1023US-TR4  — двухсокетный AMD EPYC и 32 слота оперативы (до 4 ТБ, хотя практически более реальна цифра 2 ТБ). Это близко к технологическому пределу для платформы. $5000 за сам сервак, плюс $8000 за каждый терабайт оперативы — и никаких миллионов. Дальше повышать производительность можно только наращивая число серверов, InfiniBand — вот это всё.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

до 4 ТБ, хотя практически более реальна цифра 2 ТБ

Узко мыслишь: https://servernews.ru/1047144 Впрочем, есть и кустарные поделия https://ddramdisk.store/shop/

InfiniBand — вот это всё

Ни о чём: zQSFP+ (QSFP28, SFF-8665, 100 Гбит/с). Почему бы не навешать платы с эпиками на PCIe x16 слоты получив под 500 Гбит/с, а с последней версией и под 1 Тбис/с? Вот же делают люди DPU https://www.ixbt.com/news/2020/10/05/nvidia-arm-gpu-ampere-mellanox-bluefield-2-bluefield-2x.amp.html

Останется дело за софтом, это тебе не на пыхе или джанге бекенд с монгой пилить конечно, тут думать нужно.

foror ★★★★★
()
Ответ на: комментарий от byko3y

Да! это ад какой-то. Что оно, что популярный Слак, что Скайп. Этим всем пользоваться просто невозможно.

urxvt ★★★★★
()
Ответ на: комментарий от foror

Узко мыслишь: https://servernews.ru/1047144 Впрочем, есть и кустарные поделия https://ddramdisk.store/shop

Оно сильно медленнее оперативы. Так-то дисков дофига можно навешать, вон, Backblaze продает серваки 4U на 500 ТБ. Пятсот терабайт!

Ни о чём: zQSFP+ (QSFP28, SFF-8665, 100 Гбит/с). Почему бы не навешать платы с эпиками на PCIe x16 слоты получив под 500 Гбит/с, а с последней версией и под 1 Тбис/с? Вот же делают люди DPU https://www.ixbt.com/news/2020/10/05/nvidia-arm-gpu-ampere-mellanox-bluefield...

Разве это не те же самые компы, соединенные сетью? Просто на стероидах. Причем, сверхбыстрые сетевые соединения не просто избегают на обычных компах — с ними вылазят такие проблемы, которые на медленных соединениях обычно неактуальны. Посмотри на тот же Bluefield — там половину чипа занимает сетевой адаптер.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Nervous

Что там, вкратце? Амазон говно? Или S3?

Манагеры из амазона как обычно перемудрили, переусложнили, долго-долго мучались с копеечной задачей, и наконец ее выполнили за 15 лет. Слава микросервисам. Я не написал этого вывода в статье, но по комментам к этому всё и шло на фоне нескольких аналогов, в принципе не имеющих проблем, с которыми столкнулся амазон. В статье я в основном приводил цитаты и рисовал модели, обладающие процитированными свойствами. И самый интересный вывод заключается в том, что у S3 до сих пор есть довольно серьезные ограничения, которые нельзя решить без переделки системы с нуля.

Есть даже статья из блога Backblaze, которая описывает конкретные ошибочные решения архитекторов S3, которые привели к чрезмерной ресурсоемкости эксплуатации и неприятному эффекту eventual consistency:

https://www.backblaze.com/blog/design-thinking-b2-apis-the-hidden-costs-of-s3...

Вторая задача моей статьи (и многих моих постов на лоре) — я пытаюсь приблизиться к той психологии продажи посредственной поделки в «стиле Джобса» с помпой, будто это поворотная веха в истории индустрии, когда в реальности это просто «мы догнали конкурентов». Но конкуренты вложились в технологию, а Amazon вложился в рекламу, и по итогу про амазон знают все, а про альтернативы конкретно в США даже среди айтишников знают единицы. Со временем Амазон заработал столько денег, что смог себе позволить кинуть кучу ресурсов на исправление изъянов айфона S3.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Оно сильно медленнее оперативы

«причём в сравнении с традиционными сетевыми решения он намного быстрее именно в плане времени отклика, обеспечивая задержки менее 10 нс против типовых 20 – 100+ нс» - не сильно медленнее выходит, сколько у ram задержки, вроде такие же порядка 10 нс?

Разве это не те же самые компы, соединенные сетью?

Выходит не те же самые компы. Что-то типа numa 2.0

foror ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.