Я был и остаюсь ярым сторонником «облака». Я создал Have I Been Pwned (HIBP) как cloud-first сервис, в котором использовались преимущества современных облачных парадигм, таких как Azure Table Storage, для значительного снижения затрат при сумасшедшем уровне производительности, которого я никогда раньше не мог достичь. Я написал много статей о том, как делать большие дела за небольшие деньги, и говорил по всему миру о большом успехе, которого я добился с помощью этих подходов. Один из таких докладов был «Как я поимел свои облачные расходы», поэтому кажется уместным, что сегодня я пишу о полной противоположности — о том, как мои облачные затраты поимели меня.
Все началось с моего ежемесячного счета за Azure за декабрь, который был намного выше обычного. Потребовалось всего несколько минут, чтобы найти проблему:
Этот счет пришел 10 января, но из-за того, что все члены моей семьи, кроме меня, заболели COVID (к счастью, все от бессимптомного до очень легко), прошло еще 10 дней, прежде чем я посмотрел счет. Ой!
Время исследования, и первое, на что я смотрю, — это анализ затрат Azure, который разбивает строку, подобную приведенной выше, на все отдельные службы, использующие ее. HIBP состоит из множества различных компонентов, включая веб-сайт, базу данных, бессерверные «функции» и хранилище. Сразу же один сервис всплыл на самый верх:
Эта первая позиция составляет 98% моих расходов на все службы. Не только все службы HIBP, но и все остальное, что я запускаю в Azure, от Hack Yourself First до Why No HTTPS. Здесь мы говорим об исходящем трафике, отправке данных из инфраструктуры Microsoft Azure (по цене 0.014 австралийских доллара за ГБ), нормальная вещь для веб-сайта. Но это просто учетная запись хранения данных — почему столько исходящего трафика? Начнем с того, когда использование начало стремительно расти:
20 декабря. Я сразу понял, с чем это связано — с запуском конвейера приема Pwned Passwords для ФБР вместе с сотнями миллионов новых паролей, предоставленных NCA. Что-то изменилось тогда; был ли это первый релиз открытого исходного кода? Что-то другое? Мне пришлось копнуть глубже, начав с более детального изучения использования полосы пропускания. Вот 4 часа:
Соответственно, каждый из этих всплесков составлял 17.3 Гб. Не совсем линейное распределение, а довольно регулярные всплески. К настоящему времени я начал получать довольно хорошее представление о том, что выжирает пропускную способность — скачиваемые хэши в Pwned Passwords. Но они всегда должны кэшироваться на граничном узле Cloudflare, поэтому я мог предоставить услугу бесплатно, и я проделал большую работу с людьми, чтобы убедиться, что исходящий трафик незначителен. Это действительно было проблемой? Давайте еще раз углубимся, вплоть до уровня отдельных запросов, включив диагностику в учетной записи хранения:
{ "time":"2022-01-20T06:06:24.8409590Z", "resourceId":"/subscriptions/[subscription id]/resourceGroups/default-storage-westus/providers/Microsoft.Storage/storageAccounts/pwnedpasswords/blobServices/default", "category":"StorageRead", "operationName":"GetBlob", "operationVersion":"2009-09-19", "schemaVersion":"1.0", "statusCode":200, "statusText":"Success", "durationMs":690285, "callerIpAddress":"172.68.132.54:13300", "correlationId":"c0f0a4c6-601e-010f-80c2-0d2a1c000000", "identity":{ "type":"Anonymous" }, "location":"West US", "properties":{ "accountName":"pwnedpasswords", "userAgentHeader":"Mozilla/5.0 (Windows NT; Windows NT 10.0; de-DE) WindowsPowerShell/5.1.14393.4583", "etag":"0x8D9C1082643C213", "serviceType":"blob", "objectKey":"/pwnedpasswords/passwords/pwned-passwords-sha1-ordered-by-count-v8.7z", "lastModifiedTime":"12/17/2021 2:51:39 AM", "serverLatencyMs":33424, "requestHeaderSize":426, "responseHeaderSize":308, "responseBodySize":18555441195, "tlsVersion":"TLS 1.2" }, "uri":"https://downloads.pwnedpasswords.com/passwords/pwned-passwords-sha1-ordered-by-count-v8.7z", "protocol":"HTTPS", "resourceType":"Microsoft.Storage/storageAccounts/blobServices" }
Ну, есть проблема. Эти запросы регулярно появлялись в логах, каждый раз прожигая дыру в 17.3 ГБ в моем кошельке. Этот IP-адрес тоже принадлежит Cloudflare, поэтому трафик определенно направлялся через их инфраструктуру и, следовательно, должен был кэшироваться. Давайте посмотрим, что об этом говорит панель инструментов Cloudflare:
Всего за 24 часа источник обслужил большой объем данных, давайте углубимся еще глубже:
И снова те же заархивированные хэши. Черт. На этом этапе я понятия не имел, почему это происходит, я просто знал, что это сильно ударило по моему кошельку, поэтому я добавил правило брандмауэра в Cloudflare:
И сразу же трафик упал:
Симптом был очевиден — Cloudflare не кэшировал то, что должен был, — но основная причина была непонятна. Я начал возвращаться ко всем своим настройкам, например к правилу страницы, которое определяло политики кэширования для поддомена «downloads»:
Все хорошо, ничего не изменилось, все выглядело хорошо. Итак, я посмотрел свойства самого файла в хранилище BLOB-объектов Azure:
Да, нет значения «CacheControl». Но ни в одном из предыдущих zip-файлов его не было, и приведенное выше правило страницы Cloudflare должно переопределять что-либо здесь в силу настройки TTL граничного кэша в любом случае. В отчаянии я связался с другом в Cloudflare, и вскоре после этого настало прозрение:
Я быстро просмотрел и могу с уверенностью подтвердить, что CF не кэширует эти zip-файлы. Теперь я нашел настройку в вашем плане, которая устанавливает максимальный размер кэшируемого файла на 15 ГБ, и похоже, что ваш zip-файл имеет размер 18 ГБ. Возможно ли, что размер вашего файла превышает 15 ГБ?
Конечно! Я вспомнил дискуссию несколько лет назад, когда Cloudflare увеличила кэшируемый размер, но с тех пор я не думал об этом. Я перешел к Azure Storage Explorer и сразу увидел проблему и почему она началась:
Вот и все — оба файла SHA-1 имеют размер более 15 ГБ. Черт. Теперь, точно зная, в чем была основная причина, я изменил правила Cloudflare:
Я удалил прямые ссылки для скачивания с веб-сайта HIBP и просто оставил торренты, в которых было много сидов, поэтому данные было легко получить. С тех пор Cloudflare увеличил этот лимит в 15 ГБ, и я восстановил ссылки для людей, которые не в состоянии получить торрент. Кризис закончился.
Итак, каков был общий ущерб? Э… плохим:
Помимо обычного использования в тот период, это стоило мне более 11 тысяч австралийских долларов. Упс! Для людей в других частях мира, это около 8 тысяч долларов США, 6 тысяч фунтов стерлингов или 7 тысяч евро. Это около 350 австралийских долларов в день в течение месяца. Это было очень больно, и этого не должно было случиться. Я должен был заметить это раньше и принять меры, чтобы этого не произошло. Это моя вина. Однако так же, как я рассказывал ранее о том, насколько экономически эффективными могут быть облака, эта история о том, как сильно они могут вас подставить, заслуживает того, чтобы ее рассказали. Но вместо того, чтобы просто рассказывать о горе, давайте также поговорим о том, что я сейчас сделал, чтобы это больше не повторилось.
Во-первых, я всегда знал, что пропускная способность в Azure стоит дорого, и я должен был лучше отслеживать ее, особенно в учетной записи хранения, обслуживающей наибольшее количество данных. Если вы посмотрите на первый график в этом посте до того, как трафик сошел с ума, пропускная способность исходящего трафика никогда не превышала 50 ГБ в день при обычном использовании, что составляет 0.70 австралийских доллара для исходящих данных. Давайте настроим оповещение в учетной записи хранения при превышении этого порога:
График в верхней части этого изображения показывает пунктирную черную линию в нижней части оси Y, где должна быть моя пропускная способность (максимум), но мы все еще видим остатки моей ошибки, отраженные слева , где использование полосы пропускания было сумасшедшим. После настройки вышеперечисленного осталось только определить действие, чтобы уведомить меня по электронной почте, и все — работа сделана. Как только я настроил оповещение, оно сработало, и я получил электронное письмо:
Если бы у меня было это на месяц раньше, всей этой неразберихи можно было бы избежать.
Во-вторых, есть предупреждения о стоимости. Я действительно должен был сделать это намного раньше, так как это помогает защититься от любого ресурса в Azure, который внезапно увеличивает стоимость. Это включает в себя начальный шаг создания бюджета для моей подписки:
Далее, для этого требуется определить условия, и я решил предупреждать, когда прогнозируемая стоимость достигает заданного бюджета, или когда фактическая стоимость достигает половины бюджета:
Я полагаю, что хорошо знать, когда я пройду половину пути, и я всегда могу настроить это в будущем. Стоимость — это то, что постепенно увеличивается, даже если вы этого не замечаете. Например, я знал еще до этого инцидента, что плачу слишком много за прием логов из-за того, что App Insights хранит слишком много данных для часто используемых служб, а именно HIBP API. Мне уже нужно было лучше следить за этим, и я должен был настроить оповещения о расходах и действовать в соответствии с ними гораздо раньше.
Думаю, я смотрю на это так же, как в прошлый раз, когда я потерял данные из-за сбоя жесткого диска. Я всегда знал, что существует риск, но до тех пор, пока это не произошло, я не предпринимал необходимых шагов для защиты от этого риска нанесения реального ущерба. Но эй, это могло быть намного хуже; это число могло быть в 10 раз выше, и я мог бы узнать об этом позже.