Масштабный сбой, который наблюдался на YouTube, в Gmail и Google Docs 14 декабря, вызвал панику как у рядовых, так и у корпоративных пользователей. Во время сбоя были затронуты примерно 15% запросов к Google Cloud Storage, особенно, запросы с использованием OAuth, HMAC или аутентификации по электронной почте.
Предварительно причиной падения сервисов называли проблемы с работой системы аутентификации. И, как стало известно после официального заявления Google, проблема действительно скрывалась в работе службы аутентификации, из-за которой последовало переполнение хранилища.
Что же произошло?
Служба идентификации пользователей Google поддерживает уникальный идентификатор для каждой учётной записи и обрабатывает учётные данные аутентификации для токенов OAuth и файлов cookie. Служба хранит данные учётной записи в распределённой базе данных, а также использует протоколы Paxos для координации обновлений. Поступающие запросы при обнаружении устаревших данных отклоняются, это делается в целях обеспечения безопасности.
Google регулярно обновляет используемый внутри корпорации набор инструментов автоматизации, необходимых для управления квотами ресурсов, выделяемых под работу служб. В октябре службу User ID Service переводили на новую систему квот, но с частичным сохранением прежней системы. В этот период возник первый сбой. Дело в том, что в системе сохранились старые компоненты. Они использовались при отправке запросов, а затем возвращались с сообщением об использовании службы User ID как 0.
Существующий "льготный период" для применения ограничений квот отсрочил воздействие ошибки. Но когда лимиты истекли, запустились автоматические системы квот, позволяющие уменьшить квоту, разрешенную для службы User ID. Именно это и повлекло за собой проблемы
Другими словами, действующей система безопасности не удалось заметить, что старая система выдаёт сценарий нулевой заявленной нагрузки. В итоге это привело к:
- Изменению квоты для большого количества пользователей
- Снижению квоты ниже уровня использования ( поскольку заявленное было ошибочно указано как ноль)
- Чрезмерному сокращению квот для систем хранения
- Уменьшению квот, поскольку разница между использованием и квотой превышала предел защиты
В результате квота для базы данных учетных записей была уменьшена, что не позволило Paxos вносить обновления в БД. Вскоре после этого большинство операций чтения устарело, что привело к ошибкам при поиске аутентификации.
Масштабы проблемы обнаружились сразу после начала работы новых квот. Начали поступать автоматические предупреждения о пределах емкости хранилищ и об ошибках службы User ID. Попытка исправить ситуацию привела к отключению принудительного использования квоты в ЦОДах.
В Google извинились перед клиентами и пообещали изменить работу своих систем. В частности, внедрить проверку автоматизации управления квотами, чтобы сделать невозможным быстрое введение глобальных изменений. Мониторинг и оповещения улучшат, чтобы они могли отслеживать неправильные сборки. БД службы User ID сделают более устойчивой к сбоям записи, повысят устойчивость сервисов GCP.
Кто пострадал
Пользователи Cloud Console
Любые пользователи, которые ранее не прошли аутентификацию в Cloud Console, не смогли войти в систему. Пользователи, которые уже прошли аутентификацию, могли использовать Cloud Console, но, возможно, заметили, что некоторые функции ухудшились.
Во время сбоя были поражены внутренние инструменты службы поддержки Cloud, из-за чего компания не смогла поделиться информацией о происходящем с клиентами на Google Cloud Platform и Google Workspace Status Dashboards.
Облачное хранилище Google
Примерно 15% запросов к Google Cloud Storage (GCS), особенно те, которые использовали OAuth, HMAC или аутентификацию по электронной почте, были утеряны или пострадали тем или иным образом. Позднее большая часть проблем была устранена, однако длительные ошибки наблюдались у 1% клиентов, которые пытались завершить возобновляемую загрузку, начатую во время окна. Эти загрузки были оставлены в невозобновляемом состоянии; Код ошибки, возвращенный GCS, можно было повторить, но последующие попытки были неуспешными, и эти объекты остались незавершенными.
Google Cloud Networking
Пользователи продолжали замечать повышенное количество ошибок при работе, пока Google полностью не восстановил облачную сеть. Затрагивались только операции, которые вносили изменения в сеть VPC уровня данных. Все существующие конфигурации в плоскости данных остались работоспособными.
Google Kubernetes Engine
Во время инцидента ~ 4% запросов к API плоскости управления GKE завершились сбоем, и почти все рабочие нагрузки, управляемые Google, и клиентские рабочие нагрузки не могли передавать метрики в Cloud Monitoring.
~ 5% запросов к плоскостям управления Kubernetes были неудачными, но точных цифр нет, так как у компании нет зарегистрированных метрик облачного мониторинга.
В течение часа после отключения ~ 1,9% узлов сообщали о таких условиях, как StartGracePeriod или NetworkUnavailable, которые могли повлиять на рабочие нагрузки пользователей.
Google Workspace
Все службы Google Workspace полагаются на инфраструктуру учетной записи Google для входа в систему, аутентификации и обеспечения контроля доступа к ресурсам (например, документам, событиям календаря, сообщениям Gmail). Как следствие, все приложения Google Workspace, прошедшие проверку подлинности, не работали на время инцидента. После того, как проблема была устранена, приложения Google Workspace были восстановлены. Некоторые службы, включая Календарь Google и консоль администратора Google Workspace, работали с перебоями из-за скачка трафика после первоначального восстановления. Некоторые пользователи Gmail сталкивались с ошибками в течение часа после восстановления из-за кеширования ошибок из служб идентификации.
Google BigQuery
Во время инцидента потоковые запросы возвращали ~ 75% ошибок, в то время как задания BigQuery возвращали ~ 10% ошибок в среднем во всем мире.
Что дальше?
По большому счёту, ничего. Можно продолжать работу с cервисами компании. Однако этот сбой в очередной раз показал важность ответственного подхода к разработке, а также хранению данных. Кроме того, российским клиентам облачных серверов Google стоит задуматься о российских альтернативах. В ряде случаев российские "облака" получаются надёжнее, доступнее и безопаснее.
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Понравилась статья? Ставьте ЛАЙК 👍, делитесь в социальных сетях и подписывайтесь на канал, чтобы не пропускать новые выпуски! Если у вас есть желание оценить преимущества облачной платформы Cloud4Y, оформите заявку на бесплатный тестовый доступ или позвоните нам +7 (495) 268-04-12.
