Amazon представила подробности сбоя сервисов AWS 7 декабря в регионе US-East-1 в Северной Вирджинии. Он оказался связан с некорректной работой оборудования.
Компания отмечает, что, хотя большинство сервисов AWS и все клиентские приложения работают в основной сети облачной службы, но она использует также внутреннюю сеть для размещения основных сервисов, включая мониторинг, внутренний DNS, сервисы авторизации и части управления EC2.
Внутренняя сеть подключена к нескольким географически изолированным сетевым устройствам, которые обеспечивают дополнительную маршрутизацию и трансляцию сетевых адресов, что позволяет сервисам AWS обмениваться данными между внутренней и основной сетью.
7 декабря автоматическая операция по масштабированию емкости одного из сервисов AWS, размещенных в основной сети, вызвала сбой в работе клиентов во внутренней сети. Это привело к значительному всплеску активности подключений, которая перегрузила сетевые устройства между внутренней и основной сетью AWS, что привело к задержкам связи. Эти задержки спровоцировали еще большее количество попыток подключения, что привело к постоянной перегрузке и проблемам с производительностью на устройствах, соединяющих обе сети.
В итоге данные мониторинга в реальном времени стали недоступны для внутренних операционных групп, что ограничило их возможности по поиску источника перегрузки. Вместо этого операторы полагались на журналы событий, чтобы понять, что происходит, и первоначально определили проблему как внутренние ошибки DNS. Тогда группы сосредоточились на перемещении внутреннего трафика DNS с перегруженных сетевых путей. Это повысило доступность нескольких затронутых сервисов за счет снижения нагрузки на затронутые сетевые устройства, но не полностью устранило проблему. Тогда группе пришлось продолжить работу. Операторы находили основные источники трафика для определения выделенных сетевых устройств, отключали некоторые службы с интенсивным сетевым трафиком и подключали дополнительные сетевые возможности. В итоге перегрузка значительно уменьшилась, и все сетевые устройства полностью восстановили работу спустя полдня.
По итогам инцидента AWS немедленно отключила действия по масштабированию, вызвавшие перегрузку, и не возобновит их, пока не будут развернуты все исправления. Изменение планируется внедрить в течение следующих двух недель. Также команда развернула дополнительную сетевую конфигурацию, которая защитит потенциально затронутые сетевые устройства даже в случае аналогичной перегрузки.
Сетевые проблемы повлияли на ряд сервисов AWS: некоторые испытали влияние на плоскости управления, использующие сервисы, размещенные во внутренней сети. Если экземпляры EC2 не были затронуты этим событием, то API-интерфейсы EC2, которые клиенты используют для запуска новых экземпляров или описания своих текущих, показывали повышенную частоту ошибок и задержки. Клиенты сервисов AWS, таких как Amazon RDS, EMR, Workspaces, не смогли бы создавать новые ресурсы из-за невозможности запустить новые инстансы EC2 во время сбоя. API-интерфейсы Route 53 были также затронуты, что не позволяло клиентам вносить изменения в свои записи DNS, но существующие записи DNS и ответы на запросы не пострадали. Клиенты также столкнулись с ошибками входа в консоль AWS в затронутом регионе. Amazon Secure Token Service (STS) испытывал повышенные задержки при предоставлении учетных данных сторонним поставщикам удостоверений через OpenID Connect (OIDC). Это привело к ошибкам входа в систему для других сервисов AWS, которые используют STS для аутентификации, таких как Redshift.
На клиентов также повлияли задержки мониторинга CloudWatch.
Хотя сбой не затронул клиентов, осуществляющих доступ к Amazon S3 и DynamoDB, но в ходе него доступ к корзинам Amazon S3 и таблицам DynamoDB через конечные точки VPC был нарушен.
API-интерфейсы AWS Lambda и вызов функций Lambda работали нормально на протяжении всего мероприятия. Однако API-шлюз, который часто используется для вызова функций, а также службы управления API-интерфейсом для клиентских приложений, сталкивался с повышенным уровнем ошибок. На серверы API Gateway повлияла их неспособность связаться с внутренней сетью. В результате этих ошибок многие серверы шлюза API в конечном итоге перешли в состояние, в котором их необходимо было заменить для успешного обслуживания запросов. Обычно это происходит посредством автоматизированного процесса утилизации, но это было невозможно до тех пор, пока API-интерфейсы EC2 не начали восстанавливаться.
Контейнерные сервисы AWS, в том числе Fargate, ECS и EKS, испытали повышенную частоту ошибок API. Хотя существующие экземпляры контейнера продолжали нормально работать, но их нельзя было перезапустить из-за проблем с EC2.
В Amazon Connect наблюдалось повышенное количество отказов при обработке телефонных звонков, сеансов чата и контактов задач во время мероприятия. Проблемы с API-шлюзами, используемыми Connect для выполнения функций Lambda, привели к увеличению количества отказов.
Перегрузка сети помешала инструменту AWS Service Health Dashboard надлежащим образом переключиться на резервный регион. В итоге команда решила предоставлять обновления через глобальный баннер на панели мониторинга работоспособности службы. Компания планирует выпустить новую версию панели мониторинга работоспособности сервисов в начале следующего года, которая упростит понимание воздействия сервисов, и новую архитектуру системы поддержки клиентов.
Комментаторы сообщения признают, что работу сложных систем как AWS невозможно спрогнозировать, особенно когда входные данные не контролируются на стороне компании. Однако некоторые отметили, что Amazon должна была уведомить о проблеме вовремя и должным образом, так как у многих статусные панели демонстрировали рабочее состояние системы, но при этом выполнять операции было невозможно.
7 декабря пользователи сообщили о широкомасштабном сбое в работе Amazon Web Services. Он привел к падению веб-сайтов и служб, включая Associated Press, Disney +, Vice, Amazon Prime Video, Roku и Netflix. В результате сбоя автоматизированные складские боты остановили работу. Не работали приложения, обеспечивающие подключение сотрудников хранилища, доставки и Amazon Flex. Сбой повлиял и на пользователей устройств Ring, которые не могли подключиться к своим камерам. Не работали также динамики Alexa. Наконец, из-за неполадок пострадала dYdX, «децентрализованная биржа» криптовалютных деривативов, работающая на основе блокчейна Ethereum.
habr.com
Компания отмечает, что, хотя большинство сервисов AWS и все клиентские приложения работают в основной сети облачной службы, но она использует также внутреннюю сеть для размещения основных сервисов, включая мониторинг, внутренний DNS, сервисы авторизации и части управления EC2.
Внутренняя сеть подключена к нескольким географически изолированным сетевым устройствам, которые обеспечивают дополнительную маршрутизацию и трансляцию сетевых адресов, что позволяет сервисам AWS обмениваться данными между внутренней и основной сетью.
7 декабря автоматическая операция по масштабированию емкости одного из сервисов AWS, размещенных в основной сети, вызвала сбой в работе клиентов во внутренней сети. Это привело к значительному всплеску активности подключений, которая перегрузила сетевые устройства между внутренней и основной сетью AWS, что привело к задержкам связи. Эти задержки спровоцировали еще большее количество попыток подключения, что привело к постоянной перегрузке и проблемам с производительностью на устройствах, соединяющих обе сети.
В итоге данные мониторинга в реальном времени стали недоступны для внутренних операционных групп, что ограничило их возможности по поиску источника перегрузки. Вместо этого операторы полагались на журналы событий, чтобы понять, что происходит, и первоначально определили проблему как внутренние ошибки DNS. Тогда группы сосредоточились на перемещении внутреннего трафика DNS с перегруженных сетевых путей. Это повысило доступность нескольких затронутых сервисов за счет снижения нагрузки на затронутые сетевые устройства, но не полностью устранило проблему. Тогда группе пришлось продолжить работу. Операторы находили основные источники трафика для определения выделенных сетевых устройств, отключали некоторые службы с интенсивным сетевым трафиком и подключали дополнительные сетевые возможности. В итоге перегрузка значительно уменьшилась, и все сетевые устройства полностью восстановили работу спустя полдня.
По итогам инцидента AWS немедленно отключила действия по масштабированию, вызвавшие перегрузку, и не возобновит их, пока не будут развернуты все исправления. Изменение планируется внедрить в течение следующих двух недель. Также команда развернула дополнительную сетевую конфигурацию, которая защитит потенциально затронутые сетевые устройства даже в случае аналогичной перегрузки.
Сетевые проблемы повлияли на ряд сервисов AWS: некоторые испытали влияние на плоскости управления, использующие сервисы, размещенные во внутренней сети. Если экземпляры EC2 не были затронуты этим событием, то API-интерфейсы EC2, которые клиенты используют для запуска новых экземпляров или описания своих текущих, показывали повышенную частоту ошибок и задержки. Клиенты сервисов AWS, таких как Amazon RDS, EMR, Workspaces, не смогли бы создавать новые ресурсы из-за невозможности запустить новые инстансы EC2 во время сбоя. API-интерфейсы Route 53 были также затронуты, что не позволяло клиентам вносить изменения в свои записи DNS, но существующие записи DNS и ответы на запросы не пострадали. Клиенты также столкнулись с ошибками входа в консоль AWS в затронутом регионе. Amazon Secure Token Service (STS) испытывал повышенные задержки при предоставлении учетных данных сторонним поставщикам удостоверений через OpenID Connect (OIDC). Это привело к ошибкам входа в систему для других сервисов AWS, которые используют STS для аутентификации, таких как Redshift.
На клиентов также повлияли задержки мониторинга CloudWatch.
Хотя сбой не затронул клиентов, осуществляющих доступ к Amazon S3 и DynamoDB, но в ходе него доступ к корзинам Amazon S3 и таблицам DynamoDB через конечные точки VPC был нарушен.
API-интерфейсы AWS Lambda и вызов функций Lambda работали нормально на протяжении всего мероприятия. Однако API-шлюз, который часто используется для вызова функций, а также службы управления API-интерфейсом для клиентских приложений, сталкивался с повышенным уровнем ошибок. На серверы API Gateway повлияла их неспособность связаться с внутренней сетью. В результате этих ошибок многие серверы шлюза API в конечном итоге перешли в состояние, в котором их необходимо было заменить для успешного обслуживания запросов. Обычно это происходит посредством автоматизированного процесса утилизации, но это было невозможно до тех пор, пока API-интерфейсы EC2 не начали восстанавливаться.
Контейнерные сервисы AWS, в том числе Fargate, ECS и EKS, испытали повышенную частоту ошибок API. Хотя существующие экземпляры контейнера продолжали нормально работать, но их нельзя было перезапустить из-за проблем с EC2.
В Amazon Connect наблюдалось повышенное количество отказов при обработке телефонных звонков, сеансов чата и контактов задач во время мероприятия. Проблемы с API-шлюзами, используемыми Connect для выполнения функций Lambda, привели к увеличению количества отказов.
Перегрузка сети помешала инструменту AWS Service Health Dashboard надлежащим образом переключиться на резервный регион. В итоге команда решила предоставлять обновления через глобальный баннер на панели мониторинга работоспособности службы. Компания планирует выпустить новую версию панели мониторинга работоспособности сервисов в начале следующего года, которая упростит понимание воздействия сервисов, и новую архитектуру системы поддержки клиентов.
Комментаторы сообщения признают, что работу сложных систем как AWS невозможно спрогнозировать, особенно когда входные данные не контролируются на стороне компании. Однако некоторые отметили, что Amazon должна была уведомить о проблеме вовремя и должным образом, так как у многих статусные панели демонстрировали рабочее состояние системы, но при этом выполнять операции было невозможно.
7 декабря пользователи сообщили о широкомасштабном сбое в работе Amazon Web Services. Он привел к падению веб-сайтов и служб, включая Associated Press, Disney +, Vice, Amazon Prime Video, Roku и Netflix. В результате сбоя автоматизированные складские боты остановили работу. Не работали приложения, обеспечивающие подключение сотрудников хранилища, доставки и Amazon Flex. Сбой повлиял и на пользователей устройств Ring, которые не могли подключиться к своим камерам. Не работали также динамики Alexa. Наконец, из-за неполадок пострадала dYdX, «децентрализованная биржа» криптовалютных деривативов, работающая на основе блокчейна Ethereum.
Amazon рассказала, почему в AWS «лежал» регион US-East-1
Amazon представила подробности сбоя сервисов AWS 7 декабря в регионе US-East-1 в Северной Вирджинии. Он оказался связан с некорректной работой оборудования. Компания отмечает, что, хотя большинство...
habr.com