Comments 11
>> Уменьшение облачных затрат должна стать вашей ежедневной рутинной процедурой!
То есть суть примерно такая — сначала купите наш неудобный продукт, а потом мы вам расскажем, что вложив много времени и денег в оптимизацию, вы сможете снизить стоимость нашего неудобного продукта аж на 20%.
Вменяемая статья должна содержать данные о независимой от амазона конфигурации, о её финансах и выхлопе для бизнеса. И только потом, для сравнения, можно приводить данные для того же самого, но на амазоне. Ну и, естественно, читатели должны увидеть разницу. Но проблема в том, что разница обычно отрицательная. Ибо неудобно = дорогая разработка. А дорогая разработка = большая часть стоимости системы. В общем — ни к чему весь этот рекламный хайп.
То есть суть примерно такая — сначала купите наш неудобный продукт, а потом мы вам расскажем, что вложив много времени и денег в оптимизацию, вы сможете снизить стоимость нашего неудобного продукта аж на 20%.
Вменяемая статья должна содержать данные о независимой от амазона конфигурации, о её финансах и выхлопе для бизнеса. И только потом, для сравнения, можно приводить данные для того же самого, но на амазоне. Ну и, естественно, читатели должны увидеть разницу. Но проблема в том, что разница обычно отрицательная. Ибо неудобно = дорогая разработка. А дорогая разработка = большая часть стоимости системы. В общем — ни к чему весь этот рекламный хайп.
Начинаешь читать про облака и амазон и аж глаза разбегются, ну типа всё, можно всё из кубиков собирать. Начинаешь подсчитывать стоимость и челюсть падает. К пример — бэкапы лучше хранить в васаби (ценник сопоставим с гласиром, так ещё и доступ нахаляву), видео пережимать телестримом, вместо вычислительных нод — hetzner. Вот и выходит, что облака полезны только если нагрузка появляется на 5-10% времени и нужно какой-нибудь отчёт сформировать (но и тут амазон обделался со своим редшифтом — куда выгоднее snowflake юзать и платить максимум за объём в S3… но и в нём — очереди стоят невменяемых денег, проще пачку серверов/виртуалок под kafka поставить).
Короче — если стоит задача сэкономить именно в AWS — статью нужно изучать. Но обычно стоит задача впринципе сэкономить, и тогда нужно просто поспрашивать по знакомым, чем кто пользуется (бывает дешевле купить башенок десктопных и гонять вычисления на них, эникейшики в РФ недорого берут)
Короче — если стоит задача сэкономить именно в AWS — статью нужно изучать. Но обычно стоит задача впринципе сэкономить, и тогда нужно просто поспрашивать по знакомым, чем кто пользуется (бывает дешевле купить башенок десктопных и гонять вычисления на них, эникейшики в РФ недорого берут)
Эта статья офигенна и спасибо за перевод!
Пытались использовать что-то из этих советов?
Пытались использовать что-то из этих советов?
У меня добавления по нищебродской экономии. Но, два доллара — это два доллара.
1. Новым пользователям слабенькую виртуалку дают на год бесплатно. Если на ней включить swap — она работает и держит как минимум 100К посетителей в день. Из системного диска можно сделать публичный образ и через год повторить.
НО исходящий трафик за деньги. Для VPN не подходит.
2. Резервированные инстансы это дешево и хорошо.
НО Амазон через год не шлёт никаких писем, и о том что резервирование давно тю-то — можно вспомнить через пол-года.
3. В S3 есть штатная функция удаления файлов по времени. Очень удобно для бекапов. Чуток покликал мышкой и у тебя есть бекапы за последние 30 дней. старые стираются сами.
НО диалоги работают не очень понятно и путь, указанный как "/", вовсе не означает верхний уровень. Нужно проверять как оно удаляется, иначе могут быть сюрпризы.
4. В том же S3 есть зеркалирование в другой регион. Это на случай, если мы с Америкой поссоримся а, с Сингапуром еще нет.
НО за трафик вы заплатите. проще лить с сервера в два региона по очереди.
5. Тип хранения, о котором говорит автор, в S3 можно задать при закачивании файла.
6. Амазон очень терпеливый. Три месяца не выключал машину, пытаясь списать деньги с уже не существующей карты. Истеричными письмами не забрасывал.
7. Неиспользуемые elastic-ip стоят денег. Несуразно больших.
8. В s3 есть версионность. Если она вам не нужна а вы ее включили — это экономически больно. Удалять старые версии файлов — через gui тоже трудновато…
9. Дисковые операции EBS учитываются. У меня что-то слетело и писало в логи десятками раз в секунду. Было ощутимо дорого.
1. Новым пользователям слабенькую виртуалку дают на год бесплатно. Если на ней включить swap — она работает и держит как минимум 100К посетителей в день. Из системного диска можно сделать публичный образ и через год повторить.
НО исходящий трафик за деньги. Для VPN не подходит.
2. Резервированные инстансы это дешево и хорошо.
НО Амазон через год не шлёт никаких писем, и о том что резервирование давно тю-то — можно вспомнить через пол-года.
3. В S3 есть штатная функция удаления файлов по времени. Очень удобно для бекапов. Чуток покликал мышкой и у тебя есть бекапы за последние 30 дней. старые стираются сами.
НО диалоги работают не очень понятно и путь, указанный как "/", вовсе не означает верхний уровень. Нужно проверять как оно удаляется, иначе могут быть сюрпризы.
4. В том же S3 есть зеркалирование в другой регион. Это на случай, если мы с Америкой поссоримся а, с Сингапуром еще нет.
НО за трафик вы заплатите. проще лить с сервера в два региона по очереди.
5. Тип хранения, о котором говорит автор, в S3 можно задать при закачивании файла.
6. Амазон очень терпеливый. Три месяца не выключал машину, пытаясь списать деньги с уже не существующей карты. Истеричными письмами не забрасывал.
7. Неиспользуемые elastic-ip стоят денег. Несуразно больших.
8. В s3 есть версионность. Если она вам не нужна а вы ее включили — это экономически больно. Удалять старые версии файлов — через gui тоже трудновато…
9. Дисковые операции EBS учитываются. У меня что-то слетело и писало в логи десятками раз в секунду. Было ощутимо дорого.
Ёжики кололись, плакали, но продолжали есть кактус…
Облако служит для того, чтобы перекладывать влияние энтропии и непредсказуемости среды на того, кто за счет объема и закона больших чисел готов ее погасить. Тут же люди научились сами нарываться на нереальную энтропию (дадут кредиты, или не дадут; будет хорошая сделка на маркетплейсе сегодня, или не в этот раз; когда отнимут виртуалку, предупредив за 2 минуты; даст выгоду переход на glacier для конкретного клиента, или нет?) гасить ее, и наваривать на этом 3 копейки. Они думают, что такие умные, что умнее Безоса, а по факту, делают за него грязную работу, сглаживая собой пики.
Жаль, что не написали, о каком объеме ресурсов шла речь. Жопой чувствую, что разработав настолько толерантную к непредсказуемости окружения систему, могли бы в хецнере захоститься на дедиках на i7 за половину итоговой суммы, и не иметь и десятой части геморроя.
Я уже не говорю, о том, что, возможно, вся их инфраструктура вообще бы поместилась на одном современном четырехпроцессорном сервере, и можно было бы за стоимость и скорость передачи данных между виртуалками и стоимостью операций с io не думать в принципе. Видел кейсы, когда внушительная облачная инфраструктура, тянущая на десятки тысяч долларов в месяц, со скрипом выполняла работу, которую с легкостью и многократным запасом тянет один современный сервер с установленной на него реляционной субд и запущенным на нем же сервисом.
Облако служит для того, чтобы перекладывать влияние энтропии и непредсказуемости среды на того, кто за счет объема и закона больших чисел готов ее погасить. Тут же люди научились сами нарываться на нереальную энтропию (дадут кредиты, или не дадут; будет хорошая сделка на маркетплейсе сегодня, или не в этот раз; когда отнимут виртуалку, предупредив за 2 минуты; даст выгоду переход на glacier для конкретного клиента, или нет?) гасить ее, и наваривать на этом 3 копейки. Они думают, что такие умные, что умнее Безоса, а по факту, делают за него грязную работу, сглаживая собой пики.
Жаль, что не написали, о каком объеме ресурсов шла речь. Жопой чувствую, что разработав настолько толерантную к непредсказуемости окружения систему, могли бы в хецнере захоститься на дедиках на i7 за половину итоговой суммы, и не иметь и десятой части геморроя.
Я уже не говорю, о том, что, возможно, вся их инфраструктура вообще бы поместилась на одном современном четырехпроцессорном сервере, и можно было бы за стоимость и скорость передачи данных между виртуалками и стоимостью операций с io не думать в принципе. Видел кейсы, когда внушительная облачная инфраструктура, тянущая на десятки тысяч долларов в месяц, со скрипом выполняла работу, которую с легкостью и многократным запасом тянет один современный сервер с установленной на него реляционной субд и запущенным на нем же сервисом.
Для тех, кто разворачивает Kubernetes в облаках вроде AWS, есть специальная утилита Kubecost, помогающая находить способы сэкономить постоянные затраты. На прошлой неделе здесь публиковали её обзор.
Как по мне так единственный способ реально экономить на AWS можно только увозя от туда перманентную пердсказуемую нагрузку и используя его для развёрки вслучаях краковременных слабо предсказуемых пиков.
Я увезя основную часть на реальное железо и оставив амазон под бурно развивающиеся проекты и пиковую нагрузку вкруг для компании съэкономил порядка 60% расходов на хостинг.
Я увезя основную часть на реальное железо и оставив амазон под бурно развивающиеся проекты и пиковую нагрузку вкруг для компании съэкономил порядка 60% расходов на хостинг.
если продукт построен из говна и палок потому что «нет времени объяснять» — то извините, «оно» будет прожорливо к ЦПУ, РАМ, network io и т.п.,
Вот пример из последней практики, два параллельных продукта одной и той же компании (название компании не скажу),
Первый продукт написан на simfony (php7+mysql), второй на golang+mysql, (я не топлю ни один яз ЯП, это лишь инструмент).
Так вот, количество микросервисов в каждом из продуктов примерно одинаково, около 10ти, но разница в архитектуре, когда первый был небрежно построен на фреймворке с чудовищной избыточностью, другой построили нативно, экономя скл, трафик и т.п., в результате получили следующие:
— первый продукт, который на симфони, живет на авс, расходы на «железо», ок, на облако, на данный момент 3-4к у.е.\мес,
— второй продукт, который на го, живет в vps, дешевая виртуалка DO (2я по стоимости), 1gb озу и стоит около 15у.е.\мес.
Но, опять же, разница в том, что разработчики первого продукта, в сравнении со вторым, не заморачивались с производительностью, так как го не панацея и все сервисы сидят в докере (7 сервисов и каждый с своей бд в отдельном контейнере и между ними репликация, уже 14 контейнеров на 1 гб озу + из 1гб остается около 750мб так как ОС отъедает), а мускл дефолтный докера жрет около 150мб озу, но после нехитрых манипуляций с конфигом — мускл контейнер с 150мб ограничился в среднем 50мб).
Я это к чему… повторюсь… если ПО построено из говна и палок без заморочек, то как на авс не экономь — не выйдет, ибо некоторые архитектурные решение сами по себе избыточны по цпу\озу\io…
Вот пример из последней практики, два параллельных продукта одной и той же компании (название компании не скажу),
Первый продукт написан на simfony (php7+mysql), второй на golang+mysql, (я не топлю ни один яз ЯП, это лишь инструмент).
Так вот, количество микросервисов в каждом из продуктов примерно одинаково, около 10ти, но разница в архитектуре, когда первый был небрежно построен на фреймворке с чудовищной избыточностью, другой построили нативно, экономя скл, трафик и т.п., в результате получили следующие:
— первый продукт, который на симфони, живет на авс, расходы на «железо», ок, на облако, на данный момент 3-4к у.е.\мес,
— второй продукт, который на го, живет в vps, дешевая виртуалка DO (2я по стоимости), 1gb озу и стоит около 15у.е.\мес.
Но, опять же, разница в том, что разработчики первого продукта, в сравнении со вторым, не заморачивались с производительностью, так как го не панацея и все сервисы сидят в докере (7 сервисов и каждый с своей бд в отдельном контейнере и между ними репликация, уже 14 контейнеров на 1 гб озу + из 1гб остается около 750мб так как ОС отъедает), а мускл дефолтный докера жрет около 150мб озу, но после нехитрых манипуляций с конфигом — мускл контейнер с 150мб ограничился в среднем 50мб).
Я это к чему… повторюсь… если ПО построено из говна и палок без заморочек, то как на авс не экономь — не выйдет, ибо некоторые архитектурные решение сами по себе избыточны по цпу\озу\io…
Добавлю свои 5 центов — это странно, но дешевле наращивать IOPSы в gp2 размером EBS диска (3 IOPS per GiB), чем покупать IOPSы в io1 EBS дисках.
Так что в большинстве случаев выгодней использовать gp2, а не io1 для SSD EBS volumes.
Не мог бы автор пояснить что имелось в виду под — «Соедините S3 endpoint с Cloudflare и другими CDN сервисами.»?
Так что в большинстве случаев выгодней использовать gp2, а не io1 для SSD EBS volumes.
Не мог бы автор пояснить что имелось в виду под — «Соедините S3 endpoint с Cloudflare и другими CDN сервисами.»?
Sign up to leave a comment.
Как сэкономить в AWS до полумиллиона долларов?