...или как не надо масштабировать интернет-проекты
Недавно наткнулся на полу-поучительный и полу-юмористический материал по масштабируемости интернет-проектов. Кому-то он может показаться, как и мне, забавным, а кому-то - в таком формате может оказаться легче воспринимать информацию. Надеюсь тебе тоже понравится, так что спешу поделиться как переводом, так и оригинальным видео =)
На конференции O'Reilly MySQL CE 2011 выступил Josh Berkus c пламенной речью о том, как быть уважаемым и известным, при этом не уделяя ни капли внимания масштабируемости. Его очень сильно удивляет, почему самыми популярными, известными и инвестиционно-привлекательными интернет-компаниями становятся именно те, чей интерфейс неработающего состояния (в частности "киты" и "роботы" у Twitter), известен больше, чем когда они работают. Так что Josh предлагает всем придерживаться следующей стратегии:
- Всегда следуй трендам: используй только те технологии, которые навели больше всего шумихи в Интернете: NoSQL, "облака", MapReduce, Rails, RabbitMQ. Основным инструментом для выбора технологий должен быть Reddit (или Хабр, если адаптировать к российским реалиям). За что больше голосуют - то и используйте.
- Не следите за текущей ситуацией: математика и статистика - абсолютно бесполезны. Мониторинг использования ресурсов, нагрузочное тестирование, отслеживание трафика, тестирование производительности и тонкая настройка - да кому оно надо? Лучше доверять интуиции - с какими проблемами мы сталкивались на предыдущей работе, с такими же столкнемся и в этот раз
- Ни о чем не беспокойтесь: параллельное программирование не в моде, даже не смотря на то, что Erlang позволяет приложениям работать на кластере из тысяч серверов. Крутые ребята не заботятся об оперативной памяти и управлении потоками. Нужно не париться и использовать однопоточные приложения с кучей блокировок, игнорируя области видимости и контексты памяти. Часто обновляющиеся таблицы из одной строки и мастер-очередь, в которую попадают все задания - лучшие паттерны из всех существующих.
- Каждый запрос должен попадать напрямик в базу данных: кэширование - твой смертный враг. Каждый запрос должен идти напрямую к СУБД, ни шага в сторону!
- Масштабировать нужно невозможные вещи: масштабирование простых и очевидных вещей - для слабаков! Это совершенно не круто заниматься масштабированием веб-серверов, кэшей (хотя ими пользоваться и так категорически запрещено) и серверов предложений.
- Создавайте точки отказа: вне зависимости от того, насколько большой ваш проект, в нем обязательно должно быть место, при отказе которого перестанет работать вся система. Лучшие кандидаты на эту роль: балансировщик нагрузки, очередь задач и мастер база данных.
Если следовать этим правилам, то ты станешь самым крутым и уважаемым техническим специалистом в команде: ведь у тебя всегда будут истории, где ты как настоящий герой, несмотря на все преграды, проработав все выходные напролет решил-таки поставленную задачу! В противном же случае, если твой код всегда работает и позволяет легко масштабироваться, то, парадоксально, ты будешь просто старым-добрым Васей или Петей, который просто работает и на которого никто не обращает внимания до тех пор, пока он в один прекрасный день не уволится.
Если все нормально с устным восприятием английского, очень рекомендую посмотреть видео - с эмоциями и более лаконичным техническим английским выглядит намного более впечатляюще:
Если вы еще не читаете Insight IT регулярно, настоятельно рекомендую подписаться на RSS.
