Глубокие погружения или исследование систем
Многим из нас всегда нравилось исследовать вещи, что угодно. Когда мы были детьми, мы хотели знать, как работают игрушки, разбирали и собирали автомобили, велосипеды, стереосистемы, компьютеры. Жили, пытаясь понять механические части, затем схемы и, наконец, программное обеспечение. Выросли с этим, что-то очень личное и всегда очень весело для каждого из нас. Не всем это нравится, даже, может быть, исключением являются люди, которые любят во всем разбираться, так что не чувствуйте себя виноватыми или плохими за то, что не любите или не хотите проводить такого рода расследования; позвоните человеку, которого вы знаете и знаете, что вам нравится, чтобы помочь вам, это будет для них удовольствием.
Все это введение, чтобы перейти к теме, о которой мы хотим поговорить: исследование по оптимизации затрат в AWS. Но дело не только в этом, это наша попытка показать, что исследование вещей нелинейно и не имеет волшебной формулы.
У нас есть учетная запись AWS, на которой работают некоторые системы, и стоимость шлюза NAT была довольно высокой. Шлюз NAT — это волшебная штука, которая транслирует соединения, поступающие из частной сети, в общедоступную сеть (т. е. в Интернет). Это есть в каждой частной сети, в вашем доме эту роль играет маршрутизатор, в AWS у нас есть шлюз NAT в качестве управляемого сервиса, мы платим, а AWS решает проблемы масштабирования, поддерживает систему в актуальном состоянии и т. д. — вы также можно сделать это непосредственно на EC2, но это не цель здесь. Еще одна интересная вещь, которую предоставляет AWS, — это конечные точки VPC, которые позволяют подключать сервисы из нескольких учетных записей без интеграции сети или прямого подключения к сервисам AWS (которые по-прежнему являются другими учетными записями, управляемыми только самой AWS).
В рассматриваемой сети был только шлюз NAT и не было конечной точки VPC, поэтому все используемые сервисы AWS проходили через шлюз для доступа к Интернету и сервису. Это работает, но имеет высокую стоимость, близкую к стоимости конечной точки VPC (0,045 долларов США/ГБ1 против 0,01 долларов США/ГБ2 для конечной точки VPC). Быстро выясняется, какие сервисы использовались в учетной записи: SQS, S3, SNS, EC2… пожалуй, самые распространенные сервисы AWS. Мы создали конечную точку VPC для SQS, и волшебным образом трафик NAT Gateway резко упал — неужели наступил момент паники, мы сделали что-то не так? Но нет, мы просто смотрели на метрики конечной точки, что весь трафик был там.
Уже одно это дало большую экономию, но мы не были счастливы, и это было слишком легко, нулевое обучение. Мы решили исследовать немного дальше, для этого пошли за другим сервисом AWS: VPC Flow Logs. Включение этого в VPC у нас есть доступ ко всем соединениям, которые существуют в сети, откуда они возникают, куда они идут, когда они начались, сколько байтов прошло через каждое соединение. Отличный инструмент для исследования сетей, но может иметь высокую стоимость в зависимости от сети. Чтобы избежать сюрпризов, мы включили службу, собрали данные в течение нескольких минут и выключили ее. Каждый сгенерированный файл имел около 10 МБ, сжатый, с чем-то около 1 миллиона записей. Время принести инструмент анализа данных: pandas.
Первым шагом было загрузить некоторые данные и посмотреть их формат, у нас есть несколько столбцов: исходный IP, целевой IP, исходный порт, экземпляр, сервис AWS, исходный IP пакета. Вся информация, необходимая для идентификации потоков данных. В документации AWS есть несколько примеров потоков и их значений: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html, с этим я уже знал, каким будет первый шаг: поскольку нас не интересовало, откуда взялся пакет, только то, что он вышел из шлюза NAT и направлялся в интернет, поэтому я отфильтровал данные с помощью внутреннего IP-адреса шлюза. Теперь у меня осталось намного меньше строк для работы, но все же большой объем, на который нужно смотреть вручную.
Мы сгруппировали IP-адреса назначения, отфильтровали те, которые нам уже были известны и которые меня не интересовали. Но у меня все еще была куча IP-адресов, которые мало что мне говорили. На ум пришли два инструмента: curl и host. Первый инструмент выполняет вызовы HTTP, а второй разрешает DNS и обратный DNS. Сначала мы попробовали второй инструмент, и у нас не очень получилось, он просто указал, что это машина AWS (мы уже знали, что AWS владеет блоком 3.128.0.0/9).
host 3.239.232.234
234.232.239.3.in-addr.arpa domain name pointer ec2-3-239-232-234.compute-1.amazonaws.com.Если нам не нужно выяснять, какая система, тогда давайте перейдем к curl. Но как HTTP поможет мне идентифицировать ваш IP? Бом, сейчас 2023 год, более двух систем проходят сертификацию и работают по протоколу HTTPS. Мы не всегда можем подтвердить, что эта система отвечает.
curl -v https://3.239.232.234
...
* Server certificate:
* subject: CN=queue.amazonaws.com
...Отлично, теперь мы знаем, что IP 3.239.232.234 - это SQS. Что значит? Мы создали для него конечную точку VPC, она больше не должна проходить через шлюз NAT. Мы сделали что-то не так? что происходит? Много вопросов... но у него было больше сервисов для идентификации и использования host, а curl вручную не масштабируется. Пришло время написать код3, который имитирует работу инструментов в python, чтобы передать столбец фрейма данных и оставить работать. Через несколько попыток у нас есть то, что нам нужно, мы переходим к IP-адресам назначения таблицы, группирую по найденному имени и там в первую очередь SQS, но есть и другие сервисы AWS. Я вижу, какие из них имеют смысл добавлять конечные точки VPC, создаю их и буду доволен следующей задачей? Мы не можем, мне нужно знать, почему SQS продолжает проходить через шлюз. Перед этим я взгляну на графики, и новые конечные точки VPC имели смысл и действительно снизят затраты.
Можно вернуться к попыткам понять, что случилось с SQS. Посмотрим на имя queue.amazonaws.com и видим, что он отличается от sqs.<region>.amazonaws.com что я привык видеть, я смотрю документацию AWS: https://docs.aws.amazon.com/general/latest/gr/sqs-service.html и я понимаю проблему, у нас есть приложения, использующие устаревший адрес службы. Мне в голову приходит поток вопросов: какие приложения? Где они? Какие языки? Может быть, это устаревшие системы, которые мы хотим отключить?
Первый шаг-выяснить, есть ли у нас какие-либо репозитории с кодом, напрямую вызывающим этот адрес. Быстрый поиск в системе управления версиями и ничего актуального, поэтому пришло время провести более глубокий анализ. При поднятии отношения доступных сервисов уже сгенерировали список имен и IP-адресов, поэтому я только отфильтровал список и получил все IP-адреса, которые обслуживают queue.amazonaws.com; да, их несколько, это сервис AWS с очень высокой доступностью. Теперь мы можем фильтровать потоки, ища исходные адреса, поступающие на любой из IP — адресов в этом списке, что привело к короткому списку внутренних IP-адресов-где-то около 25 адресов.
Отфильтруем экземпляры EC2, которые у нас работают, с помощью этого списка внутренних IP-адресов, и, к нашему удивлению, все они являются узлами кластера Kubernetes. «Да, приложение будет не так просто найти», — думаем мы, ища, как составить список pod’ов данного узла кластера. Еще одна гигантская командная строка, и мы получаем список приложений, а их много! Мы пробуем некоторые фильтры в командной строке, даже cat | cut | sort | unique -c. Мы увидим некоторые системы, которые работают на всех узлах: стандартные штуки kube, пара больших приложений и огромный список маленьких приложений. Мы ищем исходный код самых больших приложений и ничего необычного, и они даже не используют SQS! Следим за списком, но без особой надежды найти хоть одно применение. Начинает вырисовываться закономерность: многие приложения написаны на питоне, но это пока мало что нам говорит. Версия boto3 (библиотека python для доступа к сервисам AWS) была относительно новой во всех проектах; ничего похожего на устаревшие системы без обслуживания; это казалось тупиком, поэтому мы отступили, но сохраним некоторую информацию: «python», «устаревшие адреса SQS».
Возьмем ту небольшую информацию, которая у нас была, и вернулись в Google, даже не надеясь что-то найти. И вот, мы находим выпуск на Github botocore (библиотека, которая делает большую часть вещей для boto3): https://github.com/boto/botocore/issues/1418 вот в чем проблема, о которой сообщалось в 2018 году! Библиотека генерирует и использует старые адреса из-за некоторой несовместимости python 2.6, который уже много лет устарел. Мы пришли к решению, решения нет! Но нас это не устраивало, и посмотрели на связанные проблемы, некоторые дубликаты, некоторые с дополнительной информацией, и нашли другую: https://github.com/boto/botocore/issues/2705 у этого был запрос на вытягивание от 1 ноября, и в нем говорилось, что проблема решена в botocore >= 1.29.0. Мы идем прямо в терминал, устанавливаем библиотеку и тестируем. Проблема решена! Вероятно, нам не нужно было смотреть на все приложения, которые были запущены — даже если путем выборки, как мы, более точный поиск мог бы решить нашу проблему быстрее. Но как мы могли быть более точным, если мы не знали, что ищем?
После стольких взад и вперед все, что нам оставалось сделать, это сообщить times, что библиотеки botocore и boto3 должны быть обновлены до последней версии и что это поможет сократить расходы. Это были большие американские горки, полные кругов,но в итоге все получилось. В других случаях мы просто не можем найти причину, либо из-за нехватки времени (то есть. основная причина не стоит усилий расследования) или из-за незнания проблемы, с которой мы имеем дело. Всегда просите о помощи! Еще одна пара глаз (или ушей) очень помогает. Иногда просто объяснение того, на какую стену мы попали и как мы туда попали, уже помогает нам думать о других решениях проблемы.
Предоставляется часть кода используемого Python для анализа https://gist.github.com/pedrokiefer/3e8f4103f1094de6018256e0088cf8d8
