Дарудар — известный на просторах Рунета проект, ставший связующим звеном между людьми, желающими что-то подарить, но не знающими кому, и теми, кто может этого захотеть. На сайте можно найти все, что угодно — от бытовых и не очень вещей до самых настоящих котов в мешках. О том, как работает сервис, где уже подарили более 3 миллионов даров, рассказывает один из основателей сервиса, Антон brutto Каракулов.
Дарудар — самый настоящий высоконагруженный проект. Размещенный в облаке и использующий полностью Linux-стек, в сутки он выдерживает ~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов. Подробности под катом.
Современного человека уже не нужно убеждать в преимуществах облачных платформ, использующихся в качестве основной инфраструктуры создания веб-сервиса, мобильного приложения, наконец — «обыкновенного» веб-сайта. Для фиксации фактов не лишним будет еще раз повторить основные преимущества облачных услуг хостинга:
— Широкий выбор операционных систем, ЯП, фреймворков, инструментов, БД и устройств.
— Широкие возможности интеграции: Linux-контейнеры в Docker; наравне с
созданием JavaScript, Python, .NET, PHP, Java и Node.JS приложений
— И, конечно, бэкэнд для приложений под iOS, Android и Windows
Отсутствие необходимости осваивать новые технологии или решения/инструменты, вкупе с биллингом в реальном времени и масштабируемой «по запросу» железной инфраструктурой — вот краеугольный камень, на котором стоят все современные облака, и Microsoft Azure здесь, конечно же, не исключение.
Пожалуй, еще одно немаловажное преимущество облачных платформ в целом и Microsoft Azure в частности — это возможность переноса существующего проекта и получения всех уже упомянутых преимуществ. Собственно, сейчас «перевезти» собственный бэк-энд из дата-центра, в котором вы, возможно, арендуете отдельные стойки, в облако не представляет никакого труда: гибридные базы данных, хранилища, безопасные способы подключения — всё это есть из коробки. А в случае Microsoft есть еще и Azure Stack, позволяющий принести модель разработки и выкатки (деплоя) приложений Azure в любой ЦОД или дата-центр.
Наконец, платить только за то, что вы используете, а не за «факт наличия», стало уже настолько неотъемлемой ценностью для разработчиков и владельцев виртуальных продуктов, что обратную модель никто даже не готов рассматривать всерьёз.
Про «почему?»
Мы, как и многие другие, получили грант от компании Microsoft по программе поддержки стартапов. На наш взгляд, это жирный плюс, особенно для начинающих проектов или проектов, которые хотели бы лишь испробовать облако. Хотя, конечно, нам повезло узнать о преимуществах Azure в один из самых трудных моментов (наша предыдущая площадка-хостер резко прекратила свою деятельность, и мы «спасали» собственную инфраструктуру). Наши предыдущие хостеры славно потрудились в своё время, и я не могу сказать о них ничего плохого, но из-за постоянной нехватки полноценного системного администратора (на зарплату которому у нас нет средств) — облако заметно упростило моменты, связанные именно с администрированием инфраструктуры.
Про архитектуру и технологии
У Дарудара вполне классический nix-стек: nginx, php, mysql, memcached, sphinx.
Встречает всё nginx, дальше запрос идёт на php-бекенд, который уже взаимодействует со всеми остальными как внутренними, так и внешними сервисами проекта.
В настоящий момент на Azure используется Cloud Services и виртуальные машины Ubuntu внутри одной сети. Для каждого внутреннего сервиса создан образ, который может быть использован для аварийного
восстановления/замены и планируется использовать также для возможности дальнейшего горизонтального масштабирования сервисов проекта не без помощи удобных инструментов платформы Azure Available Sets и Load Balancing set.
В планах стоит переезд медиа-хранилища на Azure Blob Storage, а также использование Azure Queue (проводим тестирование).
Про стереотипы
«Azure — это MS, а MS — это Windows» — у меня в голове тоже срабатывала такая связка. И это было первым, что я проверил, когда получил доступ к контрольной панели Azure.
Всё оказалось не так. Azure оказался лоялен к Nix-системам, и мы используем именно их.
Win-серверами мы на Дарударе никогда не пользовались и не пользуемся вообще. С виндовой технологией виртуализации знаком только понаслышке —в основном на винде для этого использую VMware какой-нибудь. В Azure есть, насколько мне известно, возможность разворачивать вин-сервер и подключаться к нему удалённо, вроде «удалённый рабочий стол», но сам лично с этим не работал и не пробовал даже (прим.ред: действительно, к Windows Server’у можно подключаться с помощью визуального интерфейса).
Если говорить отдельно о виртуализации nix-машин, то о самой технологии ничего сказать не могу — так глубоко не копал, но есть ряд «специфических» платформенных особенностей.
Минусы:
— При ресайзе (изменении конфигурации) VM (виртуальной машины) она полностью перезагружается.
— Системный диск VM крайне медленный и использовать его поэтому нужно осторожно или не использовать вовсе.
— Есть большой дополнительный диск, который присутствует у каждой машины и с хорошей скоростью, но он считается «временным» и при перезагрузке может обнуляться, поэтому использовать его под чувствительные данные крайне не рекомендуется (кстати, теперь Azure стал об этом писать везде, а не только в документации!).
— Неочевидная с первого раза для понимания структура Cloud Services.
Плюсы:
— Можно создавать, а затем использовать собственные образы (удобно для кластеризации и масштабирования).
— Любые диски можно добавить самостоятельно, можно даже образ сделать с нужным количеством дисков, которые будут затем «подниматься» и «цепляться» самостоятельно.
— Наличие консольной утилиты для управления инфраструктурой (удобно для автоматизации работ по включению/выключению, добавлению/удалению).
— Возможность создать VPN.
— Наличие инструментов для управления трафиком/нагрузкой (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).
Возможно, определённые вещи уже давно есть и у Амазона или Гугла, но я за ними пока перестал следить, а у Azure мы всем этим пользуемся и остаёмся с хорошими впечатлениями.
Про стоимость
Azure обходится нам сейчас в \~140 тыс. рублей в месяц. Этого нам хватает на 90%, так как для пиковых нагрузок всё же этого мало.
Думаю, конечная стоимость для полноценного обслуживания текущего положения дел будет порядка 160-180 тыс. Про нагрузку на “Дарударе” отвечу так:
~2.5 тыс даров и ~1.5 тыс благодарностей в сутки
~20 тыс. комментариев в сутки
~40 тыс. уведомлений в сутки
~4.5 тыс. файлов (изображений) в сутки
Что касается выбора для компаний, то для начала надо определиться с целями и масштабами.
Пробовать потому, что это модно и «все сейчас в облаках», не стоит. Для нас (Дарудар) ключевым при выборе переходить в облако или оставаться на collocation стало отсутствие в штате сисадмина, и поэтому, фактически, для нас стоимость облачного хостинга — это стоимость инфраструктуры + базовый администратор.
О том, стоит или нет вообще, можно рассуждать много, например, так:
— Хорошо для проектов прям только-только случившихся и которые только отрабатывают свою модель;
— Хорошо для проектов, которые рассчитывают жить только на инвестиции (имеется в виду, что при отсутствии инвестиций проект закрывается);
— Хорошо для проектов, которые могут зарабатывать самостоятельно и им интересен рост и развитие.
Про планы
Всё, что нам интересно и может планироваться к внедрению, так или иначе приводит к vendor lock’у, требуя, соответственно, аккуратного внедрения в проект.
1. Например, очень нужны очереди. Думаем над внедрением.
2. Надо решить вопрос с медиа-хранилищем. В итоге нужно будет перейти на полноценное облачное решение (а это 100% vendor lock).
3. Очень интересная штука, которая тоже нами запланирована и о которой говорил выше — управление траффиком/нагрузкой (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).
Про best practices
Проблема в очень медленном системном диске для Linux-инстансов, так что или не используем его вовсе или лишь для некоторого рода задач, где это не критично.
Локальный диск хоть и выглядит привлекательно с точки зрения размера и скорости, и даже, не смотря на предупреждение о том, что данные с него могут потеряться, может сохранять данные при перезагрузке инстансов (!), но хранить там критически важные данные всё же ошибка. Например при вертикальном масштабировании инстанса он по любому обнулится.
Случается, что VM может повиснуть так, что ему уже ничего не поможет, кроме перезагрузки. А иногда даже она может не помочь. Поэтому выделение каждого внутреннего сервиса в отдельный инстанс или группу на порядок облегчает управление инфраструктурой. В связи с этим даже мысли стали «облачными»: лучше перезагрузить, чем исправить. Если после перезагрузки не исправилось, лучше пересоздать.
Резюмируя
После боли и страданий при освоении платформы (были и такие моменты) теперь испытываю спокойствие за будущее инфраструктуры проекта. Появилась предсказуемость, которая позволяет полноценно заниматься планированием и развитием проекта. И что ещё очень ценно: появилась возможность управлять инфраструктурой, не обладая глубокими знаниями в области администрирования, и подключать к обслуживанию инфраструктуры дополнительных людей.
Комментарии (36)
zenn
13.04.2016 12:15+20Прочел вашу статью но так и не понял, как у вас так получается:
Azure обходится нам сейчас в \~140 тыс. рублей в месяц. Этого нам хватает на 90%, так как для пиковых нагрузок всё же этого мало
в сутки он выдерживает ~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов
это вроде бы даже близко не highload, с такими задачами вполне справиться средний сервер с несколькими дисками — парой ssd и hdd в разных рейдах (hdd под статику, ssd под бд/прочую динамику) + CDN сеть (услуги которых куда дешевле) еще и запас для роста будет. Стоить это естественно будет на порядки дешевле, но отказоустойчивость по сравнению с кластером конечно будет ниже.
Можете пояснить, как именно вам удается расходовать 140тыс рублей для подобной нагрузки?
deniskreshikhin
13.04.2016 12:42+3С другой стороны, наём квалифицированного специалиста который это все сделает и будет поддерживать тоже обойдется в 140 тыс. рублей в месяц.
Так что с точки зрения бизнеса, вполне разумно.zenn
13.04.2016 12:50+6А вы думаете в облаке azure знания как бы не нужны? Нажал кнопочку «сделать все хорошо» и все заработало? Отнюдь, хоть я имел и малый опыт работы с сервисами azure, но скажу вам заморочек там не меньше, чем в обслуживании рутованого сервера. Да и взгляните на текущих работников сферы «веб-разработка» — практически каждый достаточно неплохо (за некоторыми исключениями) может настроить рабочий сервер для разрабатываемого продукта (а многие еще и шишек граблями набили столько, что системные администраторы позавидуют ...).
По поводу суммы — если бы это было 14 тыс рублей я бы с вами согласился, но 140 тыс это, для меня лично, просто обдирательство, никак иначе (или владелец ресурса, рассматриваемого в данном посте, использует услуги azure из рук вон плохо и не рационально).
Alexufo
13.04.2016 16:41использует услуги azure из рук вон плохо и не рационально
Да не, дело то не в этом, там ценник экспоненциально растет по добавлению ресурсов. Посмотрите их калькулятор\
https://azure.microsoft.com/ru-ru/pricing/details/virtual-machines/#Windows
После курса $ я, кстати, заметил, что не вижу комментариев к постам микрософта про ажуру на хабре вообще.
Rathil
13.04.2016 23:35-1Согласен с Вами. Я когда прочёл эти цифры, тоже был удивлён, что подобное называют высокими нагрузками и что для этого прям так сильно нужно облако…
thelongrunsmoke
13.04.2016 12:47Загляните на их сайт. Если, в других частях проекта творится тоже самое, то удивляться нечему.
brutto
13.04.2016 14:48+2Текущая архитектура представлена в статье (на схеме). Всего в продакшене используется 11 инстансов (без тестовыx).
Самые толстые — под БД (3 шт), самые дешёвые — под почтой и кешем. Максимальная конфигуация — Standard_A7, минимальная — Standard_A2.
Примерно 15% стоимости уходит на оплату трафика.
Про CDN знаю и согласен, что можно при помощи него сэкнонмить и получить прирост по скорости загрузки статики, но пока голова и руки не дошли.
Признаться неясно что такое «средний сервер» и как он должен «справляться» в предлагаемой вами конфигурации. Есть ли какие-либо более явные примеры того, о чём вы говорите? Буду признателен.
Про «порядки» цен не согласен. Пересчитывали цены на collocation в Hetzner (правда в конце прошлого года) — получалось впритык (без запаса) примерно 1/3 текущей стоимости. И это только голое железо без какой-либо настройки. И как правильно заметили в комментарии, что грамотный специалист сейчас будет стоить прилично (сопоставимо с обсуждаемой конечной стоимостью).
PS: Вдруг подумал о том, чтобы в обозначенной цитате возможны разночтения. Тут речь идёт о кол-ве ежедневном приросте данных в сутки, а не общем их объёме. Верно?yetanotherman
13.04.2016 16:21+320000 в сутки — это 0.23 запроса в секунду. Я точно ничего не перепутал?
Лет 12 назад я занимался «хайлоадом». Пять серверов, по 200000 запросов на хост в сутки. Это только те, которые что-то меняли в БД — про статику и селекты сейчас не говорим. Сервера были средненькие и по ощущениям проглотили бы еще столько же. И это все без redis, mongodb, jQuery, node.js — этого тогда просто не было или было в зачаточной стадии.
Это я к чему. Вам все правильно говорят, либо цена сильно завышена, либо вы очень сильно недооптимизировали что-то.zenn
13.04.2016 16:30+3Я о том и говорю, что даже учитывая всю «нагрузку» в сутки на базу — это просто смехотворные данные для highload и подобной архитектуры. Возможно так же вопрос не в «недооптимизации» а в избыточной архитектуре. Как говорит автор, под БД используется 3 толстых инстанты на тарифе A7 (если не знакомы, то это: x8 core, 56ggb RAM) — под такую нагрузку в сутки это выглядит ужасающе — я просто ума не приложу зачем такие мощности для столь малой базы данных (по меркам highload). Выглядит так, будто обслуживание этой сложной архитектуры пожирает ресурсов больше, чем создают клиенты вашего сервиса.
Или в azure столь некачественные «ноды» (vps-ки) либо же у автора столь некачественная настройка всего этого зоопарка…brutto
13.04.2016 17:46+2Сорри, что ввёл в заблуждение по поводу кол-ва A7 и БД.
A7 у нас только один. Такой размер вынужденный из-за размера базы. Общий размер БД сейчас наверное уже >60Gb, а шаг доступной памяти в инстансах 14-28-52. Два других инстанса под БД на A5 и A3 соответственно. CPU нагрузка на них сейчас ~5-7%. Очевидно что это с явным запасом.
Но замечу, что даже если сразу размазывать данные равномерно и постепенно, то по себестоимости будет это равноценно, например, 1xA7 = 2xA6 = 4xA5 и т.д.
Про ресурсы, которые тратятся на обслуживание не понял, уточните пожалуйста.
brutto
13.04.2016 17:22Не перепутали, всё верно. И да, стоит признать, что некоторые ресурсы могут использоваться не на все 100%, об этом чуть ниже. Но я нигде не говорил, что узкое место в проекте — это БД и что упираемся мы именно в неё? Почему вдруг только это обсуждается в данном случае? Да и примеры о кол-ве запросов на хост хотелось бы видеть с учётом некоторых дополнительных данных: хотя бы общий размер БД и примерная стоимость такого решения (с учётом всех издержек). =\
Хинт: Все проблемы, которые возникали с БД были связаны только с тем, что размер базы переставал помещаться в память, а так как диски очень медленные для подобного рода задач, то приходилось вертикально масштабировать инстанс, чтобы решать эту проблему.
Чтобы не быть голословным вот стоимость Azure VM (https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux) в пересчёте на текущую архитектуру проекта (без учёта стоимости трафика ~15-20 тыс. руб. и стоимость использования хранилищ ~2-5 тыс. руб.):
a7 — 46.5 тыс. руб.
a5 — 11.6 тыс. руб
a3x4 — 44,8 тыс. руб
a2x5 — 28 тыс. руб
Средняя загрузка CPU от 5 до 60%
PS: Да согласен, что можно сэкономить довольно приличную сумму (думаю до 20 тыс. рублей), если перевести инстансы на D-серию, но они появились уже после того как проект был развёрнут и почему-то когда смотрел цены (в своё время!) — они были дороже A-серии. Как только дойдут руки до оптимизации инфраструктуры, обязательно подробно изучу этот момент.yetanotherman
13.04.2016 23:12Поймите меня правильно. Проект крутой и никто с этим не спорит.
По деньгам — аренда серверов обходилась в сумму порядка $1000. По ощущениям, учитывая разницу курса и инфляцию, эта цифра сопоставима с вашими затратами.
А по перфомансу и железу… Были у нас, кажись, четвертые пни и один селерон. Памяти точно уже не помню сколько, но не более гига. База более 60 Гб, размазывали по хостам. На каждый запрос апдейты в базу, вообще говоря, не сильно тривиальные были для такого потока. Не думаю, что проще добавления комментов. Потом удалось неплохо оптимизировать. CPU использовались тоже где-то в районе 50-60%
Конечно, в лоб сравнивать технологии/издержки и производительность в запросах в секунду — некорректно. Но все же, общее представление дает. В общем, странно как-то.
Скажем так, я ни на что не претендую — давно уже не в этой сфере, но я сильно удивлен разницы в несколько порядков.brutto
14.04.2016 10:30+2Спасибо за понимание. Вы всё верно говорите. Да, действительно колокейшен будет выходить дешевле, но в итоге на его полноценное обслуживание потребуется отдельный человек со своей стоимостью и итоговые цены на поддержку инфраструктуры окажутся сопоставимыми. Например текущую конфигурацию можно собрать и за половину цены, но тогда ещё же должен появиться человек, который всё это правильно соберёт, настроит и будет поддерживать.
По поводу возникающего недопонимания касательно стоимости и запросов (sic!): статистика запросов, которая приведена в статье, — это не общая статистика проекта, а кол-во прироста новых данных в сутки. Видимо это не так очевидно оказалось?yetanotherman
14.04.2016 11:45Нет, я вас правильно понял. В нашем случае это нельзя назвать напрямую скоростью прироста данных — ибо параллельно шел процесс ротейта/архивации — иначе бы в стораж не влезли, но каждый запрос осуществлял запись в БД и даже подсчет некоторой минимальной статистики (апдейтами по БД). Так что по вычислительной сложности сопоставлять эти данные можно — ну, хотя бы порядок цифр.
Про плюсы/минусы dedicated server vs. cloud разумеется, разговора нет. Кроме того, расходы сопоставимы в нашем и вашем случаях. Но не стоит забывать, что это было достаточно давно
strapony
13.04.2016 15:32Удвою. Есть один сайт, который в пике 300rps получает, так ему шести ядер и двадцати гигов памяти хватает, из которых процентов 80 потребляет MySQL.
bonv
13.04.2016 14:45А какая сервиса монетизация?
Из чего складывается 140 тыс. в месяц? Какие машины используете? Сколько?brutto
13.04.2016 14:53+2В настоящий момент используется грант BizSpark.
Что касается модели монетизации, то активно работаем в этом направлении. В настоящий момент есть:
— контекст (~75%)
— меценатские взносы (~20%)
— платные услуги (~5%)
Про конфигурацию сказал чуть выше в комментарии. Если нужно детальнее, то могу ответить в личке.Alexufo
13.04.2016 16:35когда грант закончится, скорее всего, вам придется переезжать, ажура и была не дешевая, а с баксом и их 2ггц cpu пришлось уходить. Сервис вместо обработки файла в 5-9 секунд на VPS работал там все 20-30. Понятно, что инфраструктура удобная — но капец она дорого выходит, просто капец. Эти 99.99% стабильности вместо 98% как бы не таких крутых контор стоят слишком дорого.
brutto
13.04.2016 17:55+2Надеюсь что не придётся. В целом сейчас добываемых денег почти хватит, как раз чтобы там остаться (за вычетом некоторых фич сервиса) + мы активно работаем в этом направлении.
Про медленные диски согласен — говорил об этом, — но в целом это решаемо.
В нашем случае ещё стоит помнить о том, что с Azure сейчас мы не тратимся на специалиста по обслуживанию и поддержке инфраструктуры (увы у нас не хватает собственных компетенций в этом). А если переезжать, то такой человек по-любому понадобится, а это получатся сопоставимые средства.Alexufo
13.04.2016 19:12+1Жаба вам через год все растолкует про всех этих специалистов на которых вы как бэ не тратитесь)) Вобщем, дискутируйте, встречайтесь, сотрудничайте, там уже и видно будет.
XaocCPS
14.04.2016 09:44В Azure цены в рублях, в отличии от некоторых других публичных облаков. Поэтому на скачки доллара с Azure можно внимания не обращать. Корректировка цен происходит как вверх так и вниз, на моей памяти один-два раза в год.
achekalin
13.04.2016 16:31+2Скажите, а аренда аппаратного сервера на паре Xeon v3 + 128 Гб ОЗУ + несколько SSD-дисков, тысяч за 30-40 в месяц — неужели бы такой мощности не хватило бы, чтобы выдержать "~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов"? Причем на такой машине отлично можно поднять свою виртуализацию (Hyper-V, KVM — да к чему душа лежит!), нарезать машинок и пускай оно работает.
На 100 тыс. в месяц дешевле названного вами месячного ценника.Alexufo
13.04.2016 16:38ажура адово стоит + бакс сыграл свое, из за этого и ушли с нее. Но у нее есть плюшки по типу защита от DDOS по умолчанию. В любом случае она крайне дорога, те 99.99% стабильности по мне не стоят переплаты в два три раза в мес.
achekalin
13.04.2016 17:33+1Так все облака стоят адово. Не в последнюю очередь от того, что программист стоит дороже сервера, поэтому никто не будет оплачивать неделю программера, чтобы на 3% ускорить работу и на 40% уменьшить нагрузку на сервер при выводе списка товаров, скажем. Когда сервер «твой» (аренда, владение), то тебя это не задевает (почти — мало кто точно отслеживает потребляемую электроэнергию в смысле выставления счета). А когда оно живет в облаке, то за каждый неоптимальный чих ты платишь, и это требует понимания, что и за что. При 140К руб. за хостинг(!) можно нанять одного-двух толковых ребят разбираться с косяками кода, чтобы в конце работ получить 100К :) Правда, тот же сайт, отрендеренный в html, наверняка даст 10К ;)) А можно, правда, взять машину железную, и быть себе хозяином.
Ключевое слово тут — «грант». Но авторам сайта с нагрузкой в «2.5 даров» можно, наверное, и задуматься, уж очень удельная затрата на один «дар» высоковата. Highload-ом при этом вроде как пахнуть не должно, это же не миллионы страниц в день.
Правда, если авторы научатся на донейтах и рекламе заработать хотя бы 140К в мес, то переход на выделенный сервер им покажется просто подарком )))
XaocCPS
14.04.2016 09:45В реальности все ровно наоброт, после скачков цен на Azure перешло множество клиентов с Amazon. Просто потому, что в Azure ценник рублевый.
brutto
13.04.2016 18:15+2Если рассчитывать коллокейшн с необходимым железом, то получается (рассчитывал в своё время) примерно 1/3 стоимости — это если брать всё впритык, если с запасом — уже ~1/2. И это только само железо, а ещё его настройка и конфигурация потребуют специалиста, которого у нас просто нет, а собственных знаний в этом деле, увы, недостаточно.
Это конечно вопрос холиварный: collocation vs cloud. =) Правда издержки на самом деле распределяются по разному. В одной песочнице они идут на специалиста(ов), который всё это поднимает, настраивает, обслуживает. А в другой на стоимость услуги. В итоге оно выходит примерно эквивалентно.
Что касается предложенной конфигурации, то сказать сходу не могу (в виртуализации не силён): тут наверное надо смотреть и сравнивать конкретные показатели. Что-то мне подсказывает, что может не хватить.
doublel
13.04.2016 23:02Как-то из "~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов", то есть всего из 70 000 вызовов, не складывается картина высоконагруженого сервиса. В сутках 86 400 секунд, получается, что у вас меньше одного вызова в секунду. Полагаю, что вы чего-то не договариваете, например, у вас в сотни раз больше простых просмотров страниц пользователями, не приводящих ни к одному из описаных вами действий (комментирование\дарение\etc..), но создающих нагрузку.
В любом случае, имеет смысл обратится для начала за консультацией к специалисту, часто можно простым тюнингом конфига значительно улучшить производительность и сэкономить на HW.
Успехов вам и вашему проекту!brutto
14.04.2016 10:19+3Повторюсь, статистика приведённая в статье — это примерная статистика ежедневного добавления записей в базу, а не суммарная нагрузка. Когда отвечал в этом интервью думал какие дать показатели для иллюстрации и решил для наглядности ограничиться дельтой прироста данных в сутки (к тому же это даёт ещё и представление об активности самого сервиса).
Rathil
13.04.2016 23:426 лет назад работал над одним проектом, простой тематический сайт о телефонах и их контенте. В сутки было около 3М запросов (это без запросов на отдачу статики), если я ничего не путаю, запросы только на PHP, БД был мускуль, пока запросов было до 1М, висел на том же тазике, но после решил вынести на отдельный, для увеличения стабильности. В итоге 3М запросов в сутки и всего 2 сервера! И это было более 6 лет назад! 6 лет как я там уже не работаю…
Извините, но озвученные Вами суммы и нагрузки просто смешные! Нам все обходилось порядка 1.2-1.5 К зелени…brutto
14.04.2016 13:46+2В интервью говорится о дельте новых данных в сутки, а не общей нагрузке. Если говорить о сопоставимых цифрах, то у нас запросов (в сутки) к БД сейчас ~25-30M.
remzalp
14.04.2016 12:44У меня возникает цепочка очень глупых вопросов — а нормализация данных производилась? шли ли когда-то на осознанную денормализацию? (и совсем глупый) А индексы точно правильно расставлены? Потому что размер базы данных в 60 гигабайт выглядит не сильно то и большим. Для достаточно быстрой работы достаточно, чтобы все индексы помещались в память и немного из активно используемых данных.
Можно как-то увидеть схему данных? Можно ли включить в БД логирование медленных и неоптимальных запросов?
Жуткие тормоза можно ожидать, если происходит полное сканирование огромной таблицы в результате поискового запроса. Сталкивался с тем, что в mysql запрос видa field LIKE "%test%" выполняется с игнорированием индексов. в то время как field LIKE «test%» отрабатывал почти мгновенно.
К счастью, в MySQL начиная с 5.6 появился полнотекстовый поиск и в InnoDB, что уже позволяет выполнять тяжелые поисковые запросы по тексту быстро и дополнительными плюшками.
Опять же — в архитектуре упомянут SPHINX, который чрезвычайно быстр в такой ситуации, если его использовать…
Я понимаю, что желание запрятать всё в оперативную память следует из упомянутого минуса
— Системный диск VM крайне медленный и использовать его поэтому нужно осторожно или не использовать вовсе.
Понятно, что там конкурентная среда и одним жестким диском разом могут пользоваться многие, но насколько же он медленный? Скорость 3.5" флопика? CD? IDE HDD 4400 RPM?
Если конкретно линуксовый инстанс работает медленно с жестким диском, почему сервер БД не поднять на Win? Почему не настроить master-slave реплику, причем рабочая реплика как раз будет на временном быстром диске?brutto
14.04.2016 13:37+3Буду отвечать по порядку.
0. Не очень ясно почему многих волнуют вопросы связанные именно с БД, т.к. нигде не говорится о том, что у нас это узкое место. Упираемся мы в настоящее другом месте, а именно забивание app-слоя и media-хранилища по CPU. Вопрос на который я пока, к сожалению, не могу дать ясного ответа. Итак.
1. Всегда начинаем с нормальной формы, а затем исходя из необходимости делаем денормализацию.
1. Индексы стараемся делать своевременно и по запросам. «Старые» таблицы уже точно полностью покрыты необходимыми индексами. Проверяем по explain и не стесняемся использовать force index.
2. Проблема размера заключается в том, что архивные данные (более полугода) также являются актуальными и могут быть использованы наравне с горячими (до полугода). Все проблемы, с которыми мы сталкивались касательно БД заключались именно в том, что она переставала помещаться в памяти и тогда начинали случаться дикие тормоза, особенно в те моменты, когда кто-то из пользователей решает внимательно полазить по архивам или профилям.
3. Схему данных выдать не смогу, долго рисовать. Могу сказать, что у нас сейчас используется более 100 таблиц. Практически не пользуемся left/inner join. Что касается логирования запросов, то есть возможность включить «дебаг-режим» для каждой страницы и увидеть лог её «сборки» (включая выполняемые на странице запросы, время их исполнения и общее время генерации). В настоящее момент среднее время генерации страниц 0.1-0.3 с. Время sql запросов исчисляется тысячными долями (исключение составляют фоновые неоптимизированные статистические методы). Для наиболее частых выборках реализовано кеширование.
4. Запросов с полным сканированием данных почти нет. Стараемся не допускать такие моменты или терпим до тех пор пока в таблице мало данных. Для полнотекстового поиска везде в проекте используется sphinx.
5. Расскажу как было. Когда переехали и всё настроили, протестировали — открылись. И тут же повисли. Начали разбираться в чём дело и увидели, что iostat показал загрузку системного диска в 100%. Притом, что нагрузка была такая же как и раньше или даже меньше, а «железо» вроде даже с небольшим запасом. Начали исследовать и получили следующие данные: системный диск ~3 Мб/c, «временный» ~300-400 Мб/c, подключаемый blob-storage ~50-100 Мб/c. Оговорюсь сразу, что это замеры 2-3 летней давности, сейчас может быть что-то поменялось. Когда разнесли всё на «временный» и подключаемый blob-storage — всё начало работать.
6. Не факт что БД на Win будет работать резвее, потому как вроде как системный и временные диски там используются те же. Плюс поддержка, настройка под продакшн: никогда с этим не сталкивался, только в локальных dev средах.
7. Делать репликацию на временный диск нецелесообразно, так как велика вероятность не восстановить slave после ребута/ресайза инстанса. Но как решение для экономии допустимо, если научиться slave плодить как кроликов с актуальными данными. Правда в таком случае всё равно, мне кажется, экономия скорее будет касаться blob-хранилища, а не размера инстанса.
istui
Как вы решаете проблему со скоростью системного диска? Где храните данные?
brutto
Чувствительные данные храним на подключаемых blob-storage дисках — там скорость выше. Если данные не критичные — то используем локальный диск. Кстати где-то на хабре недавно читал про use-case одного из проектов, где им удалось повысить производительность дисковой подсистемы путём «правильного» подбора параметров форматирования дисков. Это может быть интересно.