Комментарии 12
Ага, всего 4 запроса…
Вы не перевели очень важный апдейт, в котором автор рассказал о багнутом NewRelic. Эта штука со временем начинала отжирать более 60% процессора на всех инстансах, и автор признаёт, что графики нагрузки, которые он привёл в статье, могут быть абсолютно невалидны.
вы правы, могу добавить что в этой статье автор дает пару ценных советов
www.troyhunt.com/2014/09/your-azure-website-cpu-is-going-nuts.html
самое интересно из этого, в выводах автора:
2.In a modern cloud environment, you could pay for other peoples’ mistakes! The increased CPU almost certainly caused Azure to scale out earlier than it should and me to scale it up when it probably wouldn’t have needed to with the non-buggy library. This costs money.
www.troyhunt.com/2014/09/your-azure-website-cpu-is-going-nuts.html
самое интересно из этого, в выводах автора:
2.In a modern cloud environment, you could pay for other peoples’ mistakes! The increased CPU almost certainly caused Azure to scale out earlier than it should and me to scale it up when it probably wouldn’t have needed to with the non-buggy library. This costs money.
Особенно мне понравился комментарий NewRelic: “Oh, you’re running the latest version 3.6.177.0? Yeah, that one kinda has a bug.”
And you're kinda sorta paying for our screw-up. Whoopsie! :))
And you're kinda sorta paying for our screw-up. Whoopsie! :))
Интересный вывод автора.
Использование в проекте сервиса (в данном случае подразумеваю любую облачную платформу как конечный сервис для той системы, которую создаете) отличается от привычного ранее использования в системе коробочного ПО и серверов. Конечно, увеличение ресурсов в ответ на нагрузку и ранее всегда планировалось для систем, но обычно планировалось немного в другом ключе — не мгновенный ввод дополнительных серверов, а скорее заранее создание фермы, по которой равномерное распределяется нагрузка (с невысокой утилизацией каждого отдельного узла, а как только утилизация приближается к 70%-75%, то обычно вводятся n-новых узлов «на последующий рост»). В облаке же схема другая, и она иногда порождает свои интересные вещи. Но здесь есть и плюсы, тк с подобной проблемой в традиционной серверной модели можно бороться (и искать ее) очень долго и иногда единолично (хотя и существует референсные дизайны архитектур, тк. конфигурации практически разные у всех, особенно в связке железо + ПО). А в облаке провайдер этого облака видит целостную картину ото всех клиентов, которые используют сервисы. И выявить (и отследить, тк железо в ЦОДе если не одинаковое, тк существуют разные поколения, то точно соответствует ожиданиям и спецификации) аномалию становится зачастую проще =) и устранить их тоже, соответственно.
Использование в проекте сервиса (в данном случае подразумеваю любую облачную платформу как конечный сервис для той системы, которую создаете) отличается от привычного ранее использования в системе коробочного ПО и серверов. Конечно, увеличение ресурсов в ответ на нагрузку и ранее всегда планировалось для систем, но обычно планировалось немного в другом ключе — не мгновенный ввод дополнительных серверов, а скорее заранее создание фермы, по которой равномерное распределяется нагрузка (с невысокой утилизацией каждого отдельного узла, а как только утилизация приближается к 70%-75%, то обычно вводятся n-новых узлов «на последующий рост»). В облаке же схема другая, и она иногда порождает свои интересные вещи. Но здесь есть и плюсы, тк с подобной проблемой в традиционной серверной модели можно бороться (и искать ее) очень долго и иногда единолично (хотя и существует референсные дизайны архитектур, тк. конфигурации практически разные у всех, особенно в связке железо + ПО). А в облаке провайдер этого облака видит целостную картину ото всех клиентов, которые используют сервисы. И выявить (и отследить, тк железо в ЦОДе если не одинаковое, тк существуют разные поколения, то точно соответствует ожиданиям и спецификации) аномалию становится зачастую проще =) и устранить их тоже, соответственно.
НЛО прилетело и опубликовало эту надпись здесь
Рассказ про масштабирование увлекает (кроме как «нерусским русским» — обороты иных фраз все же напоминают перевод от Bing, в лучшем значении этого слова), мол, кинул сайт в облако, согласился заплатить меньше доллара, чтобы юзеры не испытывали боль — опа, и «ты взял их боль на себя!» (органная музыка)
Но но как-то скромно пропущен момент о том, что масштабирование путем создания экземпляров минимум должно делаться только с сайтами, которые умеют работать с более чем одного сервера. Скажем, если сайт — чисто HTML-страничка, то его хоть с 1000 серверов отдавай, проблем не будет. Иначе — надо обязательно ставить балансеры, надо думать, надо планировать.
То же и к CDN, и к alert-ам, и к массе всего. Не бывает решения «включил и радуйся». Да, есть CloudFlare, который многим помогает, но он не всегда оптимален. Если твой сайт должен стать популярным, проектируй его заранее с пониманием этого, и точка!
При этом Azure у тебя будет, или облако Амазона, или даже тот же CloudFlare тебе будет помогать — не суть важно. Они — всего лишь инструменты, которыми все равно надо уметь владеть. Выбираешь их сам себе, по цене, виду веб-интерфейса, широте функционала… но это, опять же, не серебряная пуля.
Теперь о грустном. Хорошо рассказывать, как облако MS (как и любое другое) помогло людям со всего мира в чем-то там. Но часто нужно привязываться к расположению потенциальных клиентов/посетителей. Какие облака из мировых имеют ДЦ в России? Какие из них готовы работать с российскими потребителями в смысле бумаг? Что с хранением данных юзеров на их серверах, не создает ли это риски для бизнеса (скажем, персональные данные, если не хотеть поиметь с законом РФ вопросы, лучше все же за границу не выносить)… И вот тут садимся, и начинаем думать. И опять утыкаемся в российских «грандов» оверсела :(
Но но как-то скромно пропущен момент о том, что масштабирование путем создания экземпляров минимум должно делаться только с сайтами, которые умеют работать с более чем одного сервера. Скажем, если сайт — чисто HTML-страничка, то его хоть с 1000 серверов отдавай, проблем не будет. Иначе — надо обязательно ставить балансеры, надо думать, надо планировать.
То же и к CDN, и к alert-ам, и к массе всего. Не бывает решения «включил и радуйся». Да, есть CloudFlare, который многим помогает, но он не всегда оптимален. Если твой сайт должен стать популярным, проектируй его заранее с пониманием этого, и точка!
При этом Azure у тебя будет, или облако Амазона, или даже тот же CloudFlare тебе будет помогать — не суть важно. Они — всего лишь инструменты, которыми все равно надо уметь владеть. Выбираешь их сам себе, по цене, виду веб-интерфейса, широте функционала… но это, опять же, не серебряная пуля.
Теперь о грустном. Хорошо рассказывать, как облако MS (как и любое другое) помогло людям со всего мира в чем-то там. Но часто нужно привязываться к расположению потенциальных клиентов/посетителей. Какие облака из мировых имеют ДЦ в России? Какие из них готовы работать с российскими потребителями в смысле бумаг? Что с хранением данных юзеров на их серверах, не создает ли это риски для бизнеса (скажем, персональные данные, если не хотеть поиметь с законом РФ вопросы, лучше все же за границу не выносить)… И вот тут садимся, и начинаем думать. И опять утыкаемся в российских «грандов» оверсела :(
А есть ли какая-нибудь информация о нагрузке, которая давала new relic на приложение?
Статья интересная, однако смущает один момент: человек написал приложение вся суть которого что оно смотрит по ключу (email) какое-то значение из базы данных и говорит как круто он его оптимизировал/смаштабировал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О том, как сайт Have I been pwned? масштабировался под высокой нагрузкой и сколько это стоило (<$25)