Scaling Out All Around Us, или Начнем масштабирование

Сегодняшний пост будет первой частью рассуждения вслух. О чем - увидите ;)

Часть первая. "Вы ничего не понимаете в //дизайне// масштабировании!"

В поисках интересных новостей забрел на rsdn'e в ветку "Форумы/архитектура ПО", и решил классифицировать решения задаваемых там вопросов касательно построения масштабируемых систем (в основном - веб), и всех сопутствующих проблем, что к этому относятся. Оказалось, что варианты ответа не поражают разнообразием, и я могу привести их все:

(в порядке убывания приоритетов)

• "читайте HiLoad и 'РИТ:Высокие нагрузки'" (кстати, зачем их разделили, кто-нибудь в курсе?)
• "http://www.insight-it.ru"
• "это конфиденциальная информация" (вариант: "это тянет на докторскую, а вы хотите, чтобы вам прямо так и рассказали, ага")
• "берут и строят.."

Последний вариант отметаем сразу - рекурсивные определения нам мало чем смогут помочь, если мы не знаем, что мы хотим получить. Предпоследний - по-моему, отдает маразмом :) Думаю, что те, кто отвечают в таком ключе, ни разу не решали данный вопрос на практике. "Говорить - не мешки ворочать", так сказать.

Едем дальше. При всем уважении к Ивану Блинкову (insight-it.ru) и нисколько не умаляя его способности донести сложное простым языком и выдать на-гора тонны полезных ссылок, начинающий "масштабироваться" программист в лучшем случае сможет построить копию одного из примеров архитектуры, которые Иван так подробно описывает, но не сможет победить всех "демонов", которых оная копия вызовет на свет. Видимо, надо начинать по-другому, с простого, с отдельных частей.

Это очевидно, что остается один, наиболее достоверный способ разобраться в вопросе - смотреть доклады конференций: полезные доклады, не очень полезные доклады, остальные доклады.

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

Специфика вводных:

• фактически 2х-звенная стуктура (БД + сервер приложений/он же веб-сервер). 3х звенка - ересь. N-tier - отсутствует как класс;
• БД - MySQL в "дефолтовой" комплектации, относительно плоская схема данных;
• для 80% систем большая нагрузка именно фронтенда системы.
• есть еще пункты, например, внесессионность (statelessness) и данные, доступные только для чтения

Специфика решений:

• Практически всегда для полного описания революционного решения достаточно 30-40 строк кода на php/python, реализующего тот или иной паттерн (GoF), иногда с продолжениями. Все. Враг повержен, апплодисменты из зала :)
• Практически всегда "революция" пишется "с нуля". Доведение существующего решения до "hi-load certified" - не наш метод :) А надо бы. А хотелось бы иметь такой опыт и видеть, что он существует.
• Практически всегда это решение невозможно "повторить". В наше время индустриальных технологий побеждает то, что может быть легко воспроизведено без потери качества. Этого нет;
• Практически всегда решение не является архитектурным новшеством, а использует некоторое специфическое знание о компонентах, на которых основано.

Второй неприятный момент - создается ощущение, что те, кто используют что-то отличное от nginx + php/python + mysql, не имеют права на то, чтобы сказать "мы масштабировались". "У вас nginx? Нет? А о каком масштабировании вы тогда говорите". "У вас php? Нет? Вы ничего не понимаете в масштабировании!". "MySql? Эээ, а что вы тогда хотите?". И это ощущение влияет ничуть не меньше на выбор технологии, чем сравнительный анализ самих технологий (Поднимите руки, кто когда-нибудь его делал. Чья рука поднялась? Опустите немедленно, вы слишком выделяетесь).

Нет, я согласен, "выжимание" производительности из системы - это ручная, штучная работа. Однако эта штучная работа начинается только на этапе, когда алгоритмическая и архитектурная база масштабируемости уже подведена, и начинается профилирование и специфические трюки. На остальной части работы хотелсь бы иметь фактическое, документированное, полновесное описание блоков/процессов, применение которых которых заложит основу для масштабирования в дальнейшем - так сказать - "путь к масштабируемости с нуля, и не только".

И не менее часто ставится задача увеличить производительность (или запланировать увеличение) - на слишком большую величину, чтобы ее можно было зарулить просто оптимизацией и профилированием, но малую, чтобы ковыряться с полновесными кластерами и NLB. И - джентельмены - вы не поверите, но у меня Tomcat и сервлеты. Или веб-сервиc asp.net и ms sql. Не php. Не nginx, не FastCGI. Видимо, оттого, что я ничего не понимаю в масштабировании. Видимо, именно оттого появляются мифы, что по-настоящему быструю систему на asp.net создать невозможно.

Как это сделать (вернее, как начать этот делать) - хотелось бы начать последовательно и неторопливо излагать себе на будущее. Интересно? Тогда себе и читателям.

На этом на сегодня все.