Видимо, студия выбрала такую стратегию из-за потрясающей расширяемости проектов, написанных на ruby и большей динамичности кода.
Вносить в проект изменения(как маленькие, так и крупные доработки) очень легко; код так же легко поддается рефакторингу, который нужен довольно реже, чем в php, потому что на ruby быдлокодить сложно.
Смотрел dstat, с диском все хорошо.
Меня интересует одно: это нормально, что вдска работает не во всю силу реальных cpu? xen автоматически выделяет процессорное время под вдску по мере надобности?
При этом из memcached контент может брать сам nginx, а какой-нибудь демон будет проверять нагрузку и ставить флаг в тот же memcached. Но вообще, как уже сказали выше, защиту нужно строить на уровне логов и netstat-а.
Еще момент: если у вас высокая нагрузка, то не нужно писать в базу каждый раз при получении новой строчки от команды tail. Сделайте буфер с оптимальным для вас числом строк.
Парсить вы можете с помозью grep, awk, чтобы очистить логи от мусора(или ведите отдельный лог в нужно формате для картинок). А скрипт должен получиться очень тривиальный.
Да, а еще в одном подпроекте для каждого юзера свой набор данных в своей базе couchdb — там задачи так поставлены, что это очень удобно.
В общем, нет ничего зазорного в том, чтобы использовать сразу несколько средств, нужно только разумно к их выбору подходить.