Добрый день, уважаемые коллеги!

Меня зовут Анкин Николай и это мой первый пост. На текущий момент я тружусь в должности 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 после применения нашего решения в трехмесячной перспективе:

Как сэкономить деньги на Interzone Egress. Part 1