2. Meta рассказала про свою версию GWP/Perforator -- профилирование всех датацентров.
So, the engineer typed an “&” after the auto keyword to indicate we want a reference instead of a copy. It was a one-character commit, which, after it was shipped to production, equated to an estimated 15,000 servers in capacity savings per year!
Немного смешно читать такой маркетинг, потому что давным давно такие штуки мы уже сделали в Google и автоматизировали по самое не хочу. В целом поздравляю, такие вещи позволяют держать CapEx в порядке и возможно помогут избежать хоть каких-то увольнений (a.k.a. могло быть и хуже).
3. https://dl.acm.org/doi/10.1145/3651890.3672262
В Google очень много данных надо копировать между датацентрами -- поисковый индекс, данные для обучения моделей и так далее. Наконец-то выложили ещё одну статью о достаточно большом и популярном внутри сервисе, как копировать данные между многими дц. Объёмы копирования до сих пор в моей голове не сильно укладываются: ~1 Eib (экзабайт) в день. Не помню статьей с таким масштабом. Несколько интересных поинтов про статью:
* Пересылать данные стоит когда линки между датацентрами наиболее свободные, чтобы не создавать огромные пики. В итоге effingo достаётся достаточно дешёвое железо, а квоты даются пользователям отдельно
* Каждый день обновляется матрица стоимости, сколько будет стоить переслать из одного дц в другой, тем самым больше шансов соптимизировать как отправлять данные. Например, Effingo строит минимальное остовное дерево из этих стоимостей и рассылает данные в этом дереве.
* "Fairness" среди одинаковых приоритетов, то есть копируется в среднем по-очередно у одного приоритета, но если углубляться, то там формула, о которой не рассказали
* Чексуммы, копии, Erasure codes, всё на месте. Битые данные возникают, ничего страшного. Но да, считать чексуммы на экзабайты в день тоже не самое дешёвое занятие. "we get 590 corruptions over 129EB for a rate of 4.55 corruptions per EB"
* Проводятся учения, чтобы найти пользователей, которые пользуются системой слишком много без выделенных на то ресурсов. "To stay ahead, Effingo team scheduled unavailability of best effort in three clusters for a period of around one day. As a result, four product teams detected that their production-critical systems unintentionally rely on best-effort; they obtained production quota"
Статья не описывает, почему, например, решили не делать torrent-like систему, но зато описывает, почему полностью централизованная система не сработала бы -- слишком уж большие объёмы.
В целом, в копировании данных мало можно соптимизировать не работая с клиентами -- тебя просят просто скопировать точно в нужных местах. Поэтому Effingo фокусируется на том, что может максимально -- оптимизиция стоимости пересылки этих данных так, чтобы они не мешали всем другим критичным сервисам гугла.
