Добрый день, уважаемые коллеги!
Меня зовут Анкин Николай и это мой первый пост. На текущий момент я тружусь в должности DevOps Engineer в компании Altenar. История о том , как я сэкономил денег своему любимому работодателю.
На что мы тратим 3k$ в месяц ?
Во время очередной оценки наших затрат на услуги GCP мы обратили внимание , что платим 3k$ на Inter Zone Egress. Как у любознательных и бережливых инженеров у нас возникло 2 вопроса:
что такое Inter Zone Egress ?
как нам минимизировать его использование ?
Ваш покорный слуга взял на себя расследование первого вопроса.
Гугловая документация нам подсказывает , что это любой исходящий трафик между VM (в том числе в рамках k8s) , и в зависимости от местоположения источника и получателя трафика - он имеет разную стоимость:
Итого: мы узнали , что за исходящий трафик в гугле надо платить, осталось найти источники этого трафика и по возможности угомонить их.
Для того чтобы найти источник трафика нам нужно включить VPC логирование в гугле для наших сетей. После этого мы можем пойти в Log Explorer и внимательно изучить logName:("projects/your-project/logs/compute.googleapis.com%2Fvpc_flows").
В логах вы увидите большое количество сообщений:
Как понять, какие из них являются Egress , т. е. исходящими ? Здесь нам на помощь придет jsonPayload.reporter:
Он имеет 2 значения «DEST» для входящего и SRC для исходящего, добавляем условие в запрос и получаем весь Egress трафик:
logName:("projects/yourproject/logs/compute.googleapis.com%2Fvpc_flows") AND jsonPayload.reporter = SRC
Количество сообщений уменьшилось в 2 раза и это значит мы на правильном пути.
Далее нам стоит внимательнее изучить jsonPayload , возможно умные гугловые инженеры прикрутили туда полезную инфу , чтобы точнее идентифицировать наш трафик ?
И слава инженерной мысли — в блоках dest_instance и src_instance содержится информация об источнике и получателе пакета, в том числе , в каких зонах они находятся. Наш пример как раз показывает, что трафик между разными зонами присутствует. Увы движок Log Explorer не смог удовлетворить моим потребностям к формату выходных данных. Чтобы проанализировать данные на предмет количества подобных сообщений и объем трафика я использовал Log Analytics. Давайте же подготовимся к передаче лога в этот замечательный инструмент.
По умолчанию использование Log Analytics отключено для Log Bucket и у меня не было желания включать его для текущего — я создал новый Log Bucket и настроил на него SINK нужного лога.
Далее включаем функцию Log Analytics для созданного бакета и ждем накопления данных.
Ну и самый вкусный этап - создание sql запроса для получения желаемых данных, какой же объем трафика передается и откуда и куда ?
Меня в частности интересовала сумма переданного трафика (json_payload.bytes_sent) , под источник/получателя (json_payload.src_gke_details.pod.pod_name)/(json_payload.dest_instance.zone) , зона источника/получателя (json_payload.src_instance.zone)/(json_payload.dest_instance.zone) и главные условия выборки — Egress Traffic ((json_payload.reporter) = "SRC") и что у источника и получателя разные зоны.
Пропустив эти вводные через призму суммирования и группировки получаем следующий запрос:
SELECT
sum(cast(JSON_VALUE(json_payload.bytes_sent) as int)) / 1024/1024/1024 as Gb, JSON_VALUE(json_payload.dest_gke_details.pod.pod_name) as dest_pod , JSON_VALUE(json_payload.dest_instance.zone) as dest_zone ,JSON_VALUE(json_payload.src_gke_details.pod.pod_name) as src_pod, JSON_VALUE(json_payload.src_instance.zone) as src_zone
FROM
`yourproject.global.VPC-logs._AllLogs`
WHERE
JSON_VALUE(json_payload.src_instance.zone) <> JSON_VALUE(json_payload.dest_instance.zone)
AND JSON_VALUE(json_payload.reporter) = "SRC"
AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)
group by dest_pod, src_pod, dest_zone, src_zone
orderby Gb desc
и не менее интересный вывод:
Т.е. поды нашего приложения ходят за данными в БД из другой зоны , генерируя при этом достаточно дорогой трафик.
Для понимания происходящего ниже представлена схема движения трафика:
На этом расследование завершено, далее обучаем приложение ходить в БД в своей зоне , об этом подробнее расскажем во второй части.
На затравку сравнение расходов на Inter Zone Egress после применения нашего решения в трехмесячной перспективе:
