Мы постоянно делимся опытом оптимизации служебных систем нашего IaaS-провайдера:
Сегодня наше внимание привлек кейс Ticketmaster. Попробуем кратко его проанализировать.
/ Фото Ginny / CC
Оден Эспиноса (Audyn Espinoza) рассказывает, что команда Ticketmaster постоянно занимается мониторингом. ИТ-отдел проекта любит оптимизировать сервис, но решать ИТ-проблемы приходится по ходу их появления.
В данном случае все началось с того, что один из запросов получил необычно высокое число тайм-аутов. Обращение к логам мониторинга показало, что проблема характерна для всего кластера в целом. Тайм-ауты здесь наблюдались ежеминутно.
Дополнительная оценка обстановки с помощью tcpdump показала, что проблему можно локализовать на стадии прохождения через брандмауэр. Для более детального расследования было решено применить OPNET и Wireshark.
Данные инструменты показали, что пакет SYN без проблем проходит, но его приятелю SYN/ACK этого сделать не удается. При направлении пробного пакета в обратную сторону результат был аналогичным.
В итоге команда вернулась к рассмотрению работы брандмауэра. Они выяснили, что при достижении допустимого времени простоя TCP-соединения начиналась повторная передача пакета SYN, а SYN/ACK так и не проходил через виртуальный брандмауэр.
Окончательный вердикт: SNMP монополизировал ЦП каждые 60 секунд, что и показывал мониторинг брандмауэра. Дело было в баге на уровне кода. Для решения проблемы команда отключила систему SNMP-опроса.
P.S. Немного о работе нашего IaaS-провайдера:
Сегодня наше внимание привлек кейс Ticketmaster. Попробуем кратко его проанализировать.
/ Фото Ginny / CC
Оден Эспиноса (Audyn Espinoza) рассказывает, что команда Ticketmaster постоянно занимается мониторингом. ИТ-отдел проекта любит оптимизировать сервис, но решать ИТ-проблемы приходится по ходу их появления.
В данном случае все началось с того, что один из запросов получил необычно высокое число тайм-аутов. Обращение к логам мониторинга показало, что проблема характерна для всего кластера в целом. Тайм-ауты здесь наблюдались ежеминутно.
Дополнительная оценка обстановки с помощью tcpdump показала, что проблему можно локализовать на стадии прохождения через брандмауэр. Для более детального расследования было решено применить OPNET и Wireshark.
Данные инструменты показали, что пакет SYN без проблем проходит, но его приятелю SYN/ACK этого сделать не удается. При направлении пробного пакета в обратную сторону результат был аналогичным.
В итоге команда вернулась к рассмотрению работы брандмауэра. Они выяснили, что при достижении допустимого времени простоя TCP-соединения начиналась повторная передача пакета SYN, а SYN/ACK так и не проходил через виртуальный брандмауэр.
Окончательный вердикт: SNMP монополизировал ЦП каждые 60 секунд, что и показывал мониторинг брандмауэра. Дело было в баге на уровне кода. Для решения проблемы команда отключила систему SNMP-опроса.
P.S. Немного о работе нашего IaaS-провайдера:
