Построение распределенных больших масштабируемых систем на примере Google

    Просмотрел замечательное выступление Гордона Роуэла (Gordon Rowel) на тему как Google строит большие системы. Вот ссылка. А ниже мой свободный перевод.

Правила построения надежных систем:

• Внедряйте масштабируемую систему (которая может вырасти не в 2 раза, а в 10 или в 100 раз через год или на следующей неделе)
• Решение должно быть единым, унифицированным (т.к. каждая система, которая отличается, вносит свои особенности и приводит к более сложным ситуациям по восстановлению)
• Необходимо понимание всех уровней работы решения
• Необходимо мониторить ВСЕ
• Планируйте систему для работы в случае различных сбоев
• Периодически "ломайте" систему, но под контролем  (вынимайте диски, отключайте питание и наблюдайте как работают системы, разделяйте их на части, замедляйте работу БД, ...)

Масштабирование

Мы не внедряем "сервер"

• сервера ломаются, питание пропадает
• клиенты или DNS необходимо перенастраивать
• все сервера находятся за балансировщиками

Мы не внедряем "кластер"

• сети ломаются, сервера ломаются, питание пропадает
• клиенты или DNS необходимо перенастраивать

Мы всегда внедряем резервируемые кластера

• пытаемся отправить клиентов к ближайшему рабочему кластеру
• используем технологию anycast для единого управления клиентскими настройками

Отказ в обслуживании

Плохо написанный код

• на небольшом кол-ве клиентов
• это раздражает

Плохо написанный код

• на огромном кол-ве клиентов
• может быть причиной серьёзнейших проблем в инфраструктуре

Пишите хороший код и готовьте релизы

• уделяйте внимание процессу выпуска релизов (Release Management)
• взаимодействуйте с владельцами сервисов
• готовьте планы откатов, предоставляйте время на тестирование стабильности
• знайте пределы систем при DoS атаках, тестируйте их

Балансировка нагрузки

   У вас есть достаточно производительности?

• как много серверов (backends) вам нужно?
• что случится, если половина ваших серверов потеряет питание?
• А если уже половина выключена для восстановительных работ?

Как вы отправляете клиентов к правильным кластерам?

• Настройки на стороне клиента (пример: Kerberos, но клиент должен поддерживать такую возможность)
• DNS round-robin  (простая глобальная балансировка)
• DNS виды (views) (или split-horizon в терминологии Microsoft, например)  (лучший ответ для клиетского ip)
• Anycast  (в IPv4 сетях реализуется с помощью протокола BGP)
• Рекомендация: DNS виды + Anycast

 

Глобальные сбои

Мониторьте все

• Если проверки доступности серверов в кластере не срабатывают (при работающих серверах), то будет не доступными часть серверов (или весь сервис)

Тестируйте все

• вы должны ожидать (и тестировать) отключения дата центров
• обратите внимание на каскадные отключения

Учитесь на сбоях

• Пишите "посмертные  отчеты"
• Делайте фокус на фактах!
• Что пошло не так и что может быть улучшено?
• "Посмертный отчет" не про вину

Разнообразие - это хорошо. Но для людей.

• Будьте беспощадны к разнообразию платформ.
• Любое отличие от стандарта рано или поздно ведет к "Ууупс" ситуации
• Каждое обновление ОС, это время для изменений и чисток
• Избавляйтесь от ручных/кастомных решений!