Python-сообщество

Приветствую всех друзья!

Закралась у меня в голове мысль, сделать с товарищами свой проект, который, как я надеюсь в недалёком будущем (год, два, три) может вырости до среднего уровня. Так как мне всегда было интересно возиться с django выбор естественно пал на неё, с версией ещё не определился, но наверное возьму 1.6 собственно не это важно.

Мой вопрос заключается в том, как бы лучше организовать инфраструктуру, что бы потом не было мучительно больно?

Я понимаю, что по этому поводу есть много информации, и так же понимаю, что одназначного ответа дать нельзя. Но если предположить средненагруженный по функционалу сайт и посетителей в перспективе порядка 30-50 тысяч человек в день (просмотры страниц, комментарии, голосования, просмотры изображений, внутренние сообщения на основе django-messages ну и тп.).

В моих безумных мыслях летает мысль взять две виртуалки (к примеру линод) и разместить на одной СУБД а на другой приложение. Проблема в том, что в случае возрастания нагрузки (которую мы будем ждать), у меня нет целостной картины, как всё это потом правильно маштабировать?

Я не могу назвать себя не разбирающимся человеком, но большого опыта работы с django приложениями в таком ключе у меня просто не было, вот и хочу узнать вашего совета ну или хотя бы простых примеров на пальцах.

Спасибо!

Если правильно, тестить и считать нужно.

Для начала можно все на одном сервере разместить с большим объемом памяти для нормальной работы СУБД. Просто делайте все настройки и модули так, чтобы потом достаточно было изменить параметр, IP адрес, порт на другой.

Запускаете мониторинг.

Потом эмулируете работу с помощью утилит для нагрузочного тестирования с разным кол-вом пользователей (соединений) и строите график для ваших критериев (латенси, скорость работы и пр.).
Когда график перестает быть линейным - вот первое узкое место в системе появилось.

Смотрите на мониторинг на ресурс, которого не хватает.
Смотрите кто этот ресурс жрякает как не в себя - вот претендент на оптимизацию.

Используете стандартные для этого проглота механизмы оптимизации и выполняете их.
Это может быть: кеширование (MemCache, MemCached - если нужно), индексы в БД, настройка СУБД (правильное администрирование дает до 20% прироста производительности), шардинг БД, очередь асинхронных заданий (если не заложена изначально в систему) и пр.

На каждом этапе оптимизации снова прогоняете тесты, чтобы знать когда снова что-то оптимизировать нужно.
По тестам можно определить приблизительную нагрузку, которую выдержит сервис.
Берите от 50% до 75% нагрузки на железо - это ваш максимальный рабочий диапазон. Оставляете небольшой запас для административных целей и пиков нагрузки. Это число выбираете по мониторингу, самый расходуемый ресурс.

Если нагрузка выше 80% - при пиках будет DoS. Пора апгрейдиться и/или оптимизироваться.

Что тестировать?
Выделяете несколько разноплановых активностей: регистрация пользователя, логин, отправка сообщения, загрузка изображения, видео и т.п.
Если разные активности одинаковы по воздействию на систему, берете одну из них.
Прогоняете тест по каждой уникальной (по воздействию) активности.
Это даст картину для режима работы с перекосами и позволит:
- своевременно обратить внимание на взлом или другую несанкционированную активность пользователей/скриптов (помните шум с сообщениями ВКонтакте на прошлой неделе?),
- прикинуть момент начала оптимизации или апгрейда при изменении поведения пользователей.

Например, добавление кучи видео увеличивает нагрузку на сеть, диск и процессор (если конвертируете).
А подключение кучи мобильных клиентов вызывает множество неустойчивых соединений и увеличение латенси со стороны клиента (открытые соединения висят дольше, их общее кол-во ограничено).
Индексация гуглом/яндексом и прочими внешними скриптами может внезапно увеличить нагрузку на СУБД, если запрашиваемые данные из широкого временного диапазона и поэтому не закешированы.

Прогоняете тест по нескольким активностям одновременно в том процентном соотношении, какое актуально для вашей системы.
Это даст картину для обычного режима работы.
Если со временем она начала меняться, значит пользователи начали по другому использовать вашу систему и нужно быть к этому готовым.

Спасибо за кучу дельнх советов, есть над чем подумать

И действительно начну лучше с одного сервера, а так же прикручу на отдельном (уже существующем) сервере sentry. Далее буду смотреть по мере увелечения количества функционала.

Пока меня посещают интересные размышления по поводу кеширования и по поводу СУБД, что использовать?

По поводу кеша, уж очень мне хочется под эти цели использовать redis.
По поводу СУБД до сих пор в муках выбора postgres или mysql, активно использую оба, но в таких маштабах не могу понять с какой из них будет удобнее жить.

ssv1
По поводу кеша, уж очень мне хочется под эти цели использовать redis.

Хороший выбор. У них на сайте есть спец. раздел типа best practics по работе с памятью. Весьма полезный для проектирования системы.
Не забудьте ограничить ей память, а то скушает всю и не подавится.
Следите за оставшимся свободным объемом памяти, выделенным под Редис. После ухода в своп начинает ощутимо тормозить.

ssv1
По поводу СУБД до сих пор в муках выбора postgres или mysql, активно использую оба, но в таких маштабах не могу понять с какой из них будет удобнее жить.

Указанные масштабы легко скушают обе.
Если брать MySQL, то смотрите сразу как минимум на MariaDB.
Postgres даст возможность из коробки работать в пределах одной базы с разнородными данными (реляционные, документы, JSON, географические и т.п.) и использовать нативные запросы на них - весьма полезно. По первичной настройке поищите в сети выступление на прошлогодней Django конференции одного из спецов. Он давал хорошие практические советы, после которых СУБД вообще можно не трогать год-два.

Читаю про MariaDB, это же отличная штука! Существующие СУБД буду мигрировать на неё, уже решил. За одно возьму её за основу данного проекта. Спасибо!

Основные проблемы возникнут не в том, какую архитектуру выбрать, а в том, как сделать, так чтобы на сайт заходило 30-50 тыщ человек, как не разосраться с товарищами, как не забить на проект, как выбрать правильную нишу и стратегию развития проекта.

Что правда, то правда, описанные вами вопросы я уже решил, осталось решить только один - “чтобы на сайт заходило 30-50 тыщ человек”