Pull to refresh

Comments 27

Ок, сейчас изменю хостинг
Изменил на хабрасторадж
Спасибо за труд. Однозначно в закладки. Теперь только осталось сравнить с предложениями других поставщиков.
Офигенный пост, спасибо. В закладки :-)
Есть вопрос — на какое количество трафика рассчитаны ваши суммы? На одно и то же вне зависимости от утилизации, или как?
Это цена одного сервера за конкретный период. То есть предполагается, что вы проанализировали возможности и ресурсозатраты вашего решения, ожидаете определенное к-во запросов, архитектуру на листике набросали, и вы +- понимаете, сколько каких серверов вам потребуется :-)
Снова не понял — а вы на какое решение рассчитывали, неужели на John наше все The Ripper? 8-)

Одно дело, когда у вас легкий микроинстанс и выдает он тьфу и растереть — пару гигабайт трафика «в мир» в месяц. А если это хорошо нагруженный сервер, то тут пора думать о терабайтах.

У вас этот момент как-то в расчетах отражался?

Или рассматривалась числодробилка и только?
Вы хотите узнать, сколько конкретно будет стоить инфрастукрура для меня, или что? Типы серверов, к-во запросов, размер статических/динамических данных, результаты load тестов для моего стека?
Если вы говорите про стоимость EBS, CloudFront CDN или внутреннюю передачу данных, то это отдельный разговор. Тут рассматривалась цена сервера и выбор тарифа в зависимости от времени, которое планируется использовать. И я не ставил перед собой задачу посчитать здесь, сколько будет стоить какое-то абстрактное НЛОшное решение, хотя бы потому, что каждая технология отличается в ресурсопотреблении. Может, он у меня вообще MapReduce просчитывает и не выплевывает ничего наружу?
Нет, мне интересна ваша методика подсчетов.

Для своих проектов я и сам могу посчитать, у амазона и калькулятор есть ;-)

Вот именно это я и хотел услышать — «у меня мап с редьюсом, наружу трафик = константа».
Я сказал «может». Таких юз кейсов бесконечное к-во. В случае MapReduce, мне нужно много CPU. Если мне нужен сервер для NoSQL базы или кеша, то я думаю больше о раме, чтобы уместить все индексы в нем. Или, скажем, мне нужен сервер исключительно для веб-сокетов, чтобы держал 50k параллельных соединений. В приведенных выше примерах трафик не является ключевым фактором, но это никак не говорит о загруженности серверов.

Если вас интересует конкретно мой случай, то я сделал аппликацию для фейсбука из трех компонентов: Nginx для статических файлов (порядка 16mb, все кэшируется браузерами), Nodejs для динамической бизнес логики и MongoDB для постоянного хранения. Честно сказать, я абсолютно не могу предсказать, к-во запросов, и чтобы не переплачивать собираюсь все поместить на одном сервере, но архитектуру спроектировал таким образом, чтобы проект легко масштабировался.

Если трафик поползет вверх, то я первым делом выношу статические файлы на Amazon CloudFront CDN (снимаю 80% трафика), выделяю дополнительный сервер с большим рамом для MongoDB, такой же сервер для репликаций, беру много маленьких инстансов для NodeJS и спользую Nginx только как load balancer. Сколько это будет стоить? Откуда мне знать, все зависит от к-ва запросов.
Я согласен с вами, в принципе, можно сделать load тесты для различных комбинаций и посмотреть, сколько и чего будет генерироваться, нарисовать график цен в зависимости от к-ва запросов. Но лично мне кажется, лучше инвестировать это время в first user experience, иначе этих проблем просто никогда не возникнет :-)
Без сравнения с нашими хостингами (клодо или селектел например) как-то грустно и не совсем понятно.
Сравнение будет очень не в пользу aws (по цене).
Неправильно сравнивать танк с палкой-копалкой.

С нашими облаками можно работать только по двум причинам — 1) цены хочется скосить радикально 2) карточки нет и не будет, платим безналом.
Производительность инстанса у Clodo с ценой 0,77 руб/час выше чем у AWS High-CPU On-Demand Instances Medium за 0,25$/час (с лиц. RHEL).
А вот аптайм у clodo — г… но полное, так что держу мелкие проекты на aws micro-Instances, а ресурсо-жадный проект на clodo (изредко с матами поднимая резервный инстанс у aws и ожидая окончания проблем у этого долбаного Клодо).
1. Ну так а зачем платить за сервис, который не работает?
2. Если сравнивать обычные Xen инстансы с AWS EC2, они также будут в большом выигрыше — погуглите сравнения по производительности RackSpace Cloud Servers vs EC2, даже тот же Linode vs EC2. Просто там берст :-) Надеяться, что на вашей хост машине еще долго никого не будет неправильно для планирования.
Можете уточнить как сравнивали?

0,77 руб/час на clodo это 512mb RAM и невнятные 4 Core CPU. Насколько у вас нетребовательные к RAM процессы, что это выходит «мощнее» чем 1.7gb RAM и 5ECU???

Почму вы сравниванете машину на clodo без RHEL с ценой AWS с лицензионным RHEL?
У clodo (выключаю всегда шейп на io)
dd if=/dev/xvda1 of=/dev/null bs=1M count=1024 iflag=direct
1073741824 bytes (1.1 GB) copied, 3.91784 s, 274 MB/s


UNIX Benchmarks
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 28438737.9 2436.9
Double-Precision Whetstone 55.0 3560.1 647.3
Execl Throughput 43.0 758.8 176.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 261309.4 659.9
File Copy 256 bufsize 500 maxblocks 1655.0 67326.5 406.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 833120.4 1436.4
Pipe Throughput 12440.0 392569.1 315.6
Pipe-based Context Switching 4000.0 73235.1 183.1
Process Creation 126.0 1576.8 125.1
Shell Scripts (1 concurrent) 42.4 2066.2 487.3
Shell Scripts (8 concurrent) 6.0 1041.7 1736.2
System Call Overhead 15000.0 404615.1 269.7
========
System Benchmarks Index Score 486.8


Все четыре ядра

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 107926868.7 9248.2
Double-Precision Whetstone 55.0 13936.5 2533.9
Execl Throughput 43.0 5113.3 1189.1
File Copy 1024 bufsize 2000 maxblocks 3960.0 434546.7 1097.3
File Copy 256 bufsize 500 maxblocks 1655.0 113729.2 687.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 1414535.9 2438.9
Pipe Throughput 12440.0 1537265.0 1235.7
Pipe-based Context Switching 4000.0 313820.6 784.6
Process Creation 126.0 10011.2 794.5
Shell Scripts (1 concurrent) 42.4 8937.2 2107.8
Shell Scripts (8 concurrent) 6.0 1224.4 2040.7
System Call Overhead 15000.0 1586651.5 1057.8
========
System Benchmarks Index Score 1541.2


Для одного сайта мне достаточно 512 мб озу тк nginx+php-fpm (при LAMP думаю да скушает все 1-1,5Гига), а вот cpu часть скриптов кушает очень сильно.
У clodo CentOS, это тотже rhel, а amazon-linux с связкой nginx+php-fpm настраиваю только с бубном, rhel без проблем, разница в цене за инстанс между amazon-linux и rhel небольшая 0.186 и 0,25$/час.
AWS 5ECU этак в 1,5 раза оказались слабее (на глаз), а вот цифры:

dd if=/dev/xvde1 of=/dev/null bs=1M count=1024 iflag=direct
1073741824 bytes (1.1 GB) copied, 10.2821 s, 104 MB/s

Данные UNIX Benchmarks делал, но сейчас не найду.
Скажу что тяжелый php скрипт у клодо сейчас отрабатывает 5,5 сек, на aws 7,6 сек

Есть тесты у scalaxy, но они давно начали резать ресурсы, сейчас dd у них 25 MB/s на инстансе с 512 мб озу, а cpu (во всяком случае кратковременно) примерно на уровне aws High-CPU Medium, цена у них процентов так на 20-30 выше чем у клодо.
А кто запрещает CentOS на aws пускать?
Классный анализ.

Я смотрел на medium instance для себя, для долговременного сервера, и добавил расходы на предполагаемые диски, трафик и т.п. — они выходят константные для любого размера инстанса.

С этими раходами стоимость small instance подскакиваыет почти до стоимости medium instance.

А вот такой вопрос — если я оплачу план на 3 года, и в течении этих 3 лет мне надо будет что-то масштабное сделать с этим инстансом (пересоздать заново), то мне типа придется заново за 3 года платить? Кто знает?
Вы можете включать, выключать и пересоздавать с нуля, сколько душе угодно. В случае light и medium utilization неиспользованные часы не оплачиваются. Если у вас, к примеру, оплачен 1 зарезервированный инстанс, и он запущен, и вы в то же время настраиваете второй, то за второй, пока настраиваете, будете платить On Demand. Как только остановите первый, второй автоматически перейдет на Reserved тариф.
Математика, конечно же, представляет собой ценность, но предположение о равномерной загрузке на протяжении трех (!) лет само по себе сомнительно.
В моем опыте:
1) меняется ТЗ
2) улучшается алгоритм (за год мы улучшили время работы в одном проекте раза в 4е, в другом — раз в двадцать). Т.е. одна и та же мощность может обслуживать всё большее количество клиентов
3) меняется схема развертывания — проект/его части переписывается на другие технологии, которые могут менять желаемую конфигурацию, выделяются компоненты, и их тоже удобно размещать на отдельных серверах.
4) А вот объем информации и трафик растёт постоянно. И это тут не учитывается.

Возможно, вы там кодируете видео, либо занимаетесь каким-то другими задачми, где алгоритмы особо не меняются, но это скорее исключения.

Если год назад 1.5 терабайт трафика (обычный + cloudfront) влетел нам в usd250, то с сегодняшней посещаемостью это была бы примерно тысяча долларов в месяц, и превысило бы затраты на вычислительную мощность раза в два.

Как следствие, оказалось выгоднее перенести проект на банальный dedicated server, с тарификацией порядка $10/TB вместо $150 у амазона. Скорость выросла в 3 раза. затраты снизились в 4 раза.

Для надёжности информация реплицируется в amazon, в котором есть snapshot приложения, которое можно стартонуть (15 минут), пользователи получат доступ к проекту в течении обновления dns (ttl у нас 15 минут). Да, не так красиво, но реальная экономия более 10 тысяч долларов в год.
Я думаю, мы все тут будем благодарны, если вы можете описать детальнее, допустим, в отдельной статье ваш юз кейс, стек технологий, к-во юзеров, к-во запросов, среднее к-во килобайт в запросе и ответе, и как росла ваша цена для статического и динамического контента. :-)
Справедливо. А для начала можно все держать на собственном сервере (даже не шипко мощном и собранном из хлама), но подключенном на хорошем канале. А там посмотреть как пойдет с трафиком. Трафик часто критичнее, и как только это выяснится решать ставит все это в стойку или кочевать в облака.
У меня устойчивое ощущение, что использовать хостеров использующих OpenStack будет дешевле, и все чудеса масштабирования по требованию сохранятся… Не сочтите за рекламу, но мне вот хостер в послежднее вреся очень рекомендует, но мне хватает виртуального сервера… dreamhost.com/cloud/
Sign up to leave a comment.

Articles