Google тримає величезний масив даних, для оптимізації та швидшої доставки якого потрібно щодня переміщувати дані між внутрішніми серверами. Обсяг такого переміщення настільки великий, що доступні інструменти не підходять і довелося створити свій.
Google розкрив технічні деталі свого внутрішнього інструменту передачі даних під назвою Effingo та похвалився, що використовує цей проект для переміщення в середньому 1,2 екзабайта щодня.
Як пояснюється в документі [PDF], представленому на конференції SIGCOMM 2024 у Сіднеї, обмеження пропускної здатності та вперто постійна швидкість світла означають, що навіть Google не застрахований від необхідності копіювати дані, щоб вони були розташовані поблизу там, де їх обробляють або віддають користувачам.
Документ описує керовану передачу даних як «неоспіваного героя великомасштабних, глобально розподілених систем», оскільки вона зменшує затримку мережі з сотень у всьому світі до десятків мілісекунд на континенті.
У документі також зазначається, що інструменти передачі даних знайти неважко, і запитується, навіщо потрібен такий рівень керування, як Effingo.
Відповідь полягає в тому, що інструменти, які Google міг знайти, були оптимізовані для часу передачі або обробляли потоки даних «точка-точка» — і вони не справлялися із завданням обробки 1,2 екзабайта, які Effingo переміщує в середньому на день зі швидкістю 14 терабайт на секунду.
Щоб впоратися з задачею, Effingo збалансовує ефективність інфраструктури та потреби користувачів і визнає, що деякі користувачі та деякі передачі важливіші за інші: наприклад, аварійне відновлення обслуговуючої бази даних порівняно з міграцією даних із кластера з обслуговуванням заплановано через тиждень.
Інструмент має гарантувати, що завдання отримують необхідну продуктивність, і гарантувати, що якщо завдання мають однаковий пріоритет, вони обидва отримують належний рівень ресурсів, а не борються за IOPS, пропускну здатність або обчислювальні ресурси.
Як Google це робить?
У документі пояснюється, що Effingo оптимізовано для файлової системи Colossus, розробленої та використовуваної власними силами Google, яка зазвичай розгортається в кластерах, що містять тисячі машин.
Effingo розгорнуто в кожному кластері. Його програмний стек містить площину для керування життєвим циклом копії та площину даних, яка передає байти та звітує про стан. «Код і споживання ресурсів нерівномірні: площина даних використовує 99 відсотків ЦП, але займає менше семи відсотків рядків коду», — йдеться в документі.
Кожен кластер підключений до кожного іншого – деякі в межах центру обробки даних у мережі CLOS із низькою затримкою та високою пропускною здатністю. Інші покладаються на з’єднання WAN, які використовують інфраструктуру Google і сторонніх розробників.
Незалежно від технології, що лежить в основі глобальної мережі, інструмент під назвою Bandwidth Enforcer (BWe) присутній.
BWe — це ще один проект Google, призначений для розподілу пропускної здатності на основі пріоритету обслуговування та вартості, отриманої шляхом додавання додаткової пропускної здатності. BWe визначає «класи мережевих послуг» (NSC), і всі потоки трафіку в Google позначаються одним із попередньо визначених NSC.
Коли користувач ініціює перенесення даних, Effingo запитує розподіл трафіку від BWe та приступає до переміщення даних якомога швидше.
Такий розподіл трафіку може відбуватися на основі заздалегідь визначених квот, які Google визначає за допомогою метрик для вхідної та вихідної смуги пропускання на кластер, IOPS і доступних воркерів Effingo – коду, який обробляє переміщення даних і виконується як завдання Borg. Нагадування: Borg — це контейнерна платформа, яку Google створив як Kubernetes.
Effingo може робити ставки на використання ресурсів, визначених квотою, для робочих навантажень, які потребують певної продуктивності мережі. Інструмент також може покладатися на найкращі ресурси для менш критичних потоків.
Навіть незважаючи на всю цю роботу з розподілу ресурсів, Effingo має середній глобальний розмір резерву в 12 мільйонів – зазвичай близько восьми петабайт. Навіть у найкращий день у черзі стоїть близько двох мільйонів файлів. Відставання зростають приблизно на 12 петабайт і дев’ять мільйонів файлів, коли десять найбільших користувачів сервісу починають нові передачі.
