Высоконагруженные системы что это
О высокой нагрузке
В последнее время все чаще говорят о высоконагруженных приложениях. Нельзя не заметить что это теперь очень популярная, можно даже сказать модная, область знаний. Сам же термин “высоконагруженная система” при этом не имеет в нашей отрасли четкого определения. В этой заметке я хочу привести свои рассуждения по этому вопросу. Я не ставлю перед собой цель дать исчерпывающее определение этого термина. Моя цель, предоставить читателю ключевую информацию о системах такого рода, которая определяет стиль мышления при работе с ними.
Итак, что такое высоконагруженная система? Ответ на этот вопрос стоит начать с описания качественных свойств такого рода систем.
Традиционные качества высоконагруженной системы
Как правило, к таким качествам относят большое количество пользователей и данных. В целом это правда, но тут есть несколько загвоздок:
Ниже на основании предпосылки “много пользователей, много данных” я сформирую список качественных факторов присущих высоконагруженным системам. Начнем с самого простого.
Многопользовательская система
Конечно же высоконагруженное приложение в первую очередь является многопользовательским. То есть в один момент времени с ним работает более чем один человек. Сейчас, в эру стремительного развития Интернета, это тысячи и сотни тысяч человек.
Устойчивая ассоциация высоконагруженных систем с большим количеством пользователей в нашей индустрии появилась давным давно. Ничего принципиально неверного в такой связи нет. Но если высокая нагрузка подразумевает большое количество пользователей, то большое количество пользователей совсем не обязательно подразумевает высоконагруженную систему.
Определенно у метрополитена более высокие требования к пропускной способности. Но значит ли это что Московский метрополитен можно считать более “высоконагруженным” чем StackOverflow? Вряд ли, в частности потому что эти две системы оперируют несравнимыми объемами информации, о чем мы поговорим позже.
Я намерено в обоих случаях привел оценку пропускной способности, так как она дает больше информации о нагрузке чем количество пользователей системы. Две разные системы могут подталкивать пользователей к разным паттернам их использования. Это может приводить к абсолютно разным требованиям по пропускной способности для этих систем. Пропускная способность точнее описывает количество работы которую должна уметь выполнять система в единицу времени.
Распределенная система
Высоконагруженные системы являются системами распределенными, то есть работают более чем на одном сервере. Зачастую это десятки и сотни серверов. Требование распределенности вытекает из следующих причин:
Но обо всем по порядку…
Я наверное не ошибусь если скажу что большинство высоконагруженных приложений являются Интернет-приложениями (позже мы еще вернемся к состоятельности этой гипотезы). А отличительной особенностью современного Интернета основанного на концепции Web 2.0 является тот факт, что сами пользователи генерируют данные, которые они сами же в итоге и потребляют. Это приводит к тому, что чем больше у вас пользователей, тем больше потенциальный объем хранимых данных.
Требование обработки больших объемов данных может существенно осложнить жизнь. Под “большим объемом” я подразумеваю такой объем информации, который не может эффективно обработать одна машина. В большинстве случаев, это объем превышающий объем доступной на сервере оперативной памяти. То есть приходится тем или иным образом распределять данные между несколькими машинами, каждая из которых обрабатывает свой небольшой кусочек данных, но делает это эффективно, без page fault’ов (не используя swap) и прочих неприятностей. Необходимость эффективной обработки данных диктуется другим очень важным качеством высоконагруженных систем, – интерактивностью, о котором будет сказано ниже.
Но большие объемы данных – это не все. Ко всему к этому хочется чтобы система работала в режиме 24×7 без остановок и перерывов. Но вот незадача, любое даже самое надежное оборудование иногда выходит из строя. Встает естественная задача обеспечения доступности системы в случаях отказа оборудования.
Тут мы вступаем в область знания распределенных систем, эксплуатация которых редко бывает безоблачной, даже когда вы используете готовые решения. Тем не менее распределенные системы, не смотря на сложность их разработки и поддержки, пожалуй единственный подход позволяющий обеспечить вышеизложенные требования в полной мере.
Позитивная динамика по пользователям и данным
Если ваше приложение представляет хоть какой-то интерес, то даже если ничего не делать, ваша аудитория будет расти просто с ростом аудитории Интернета. Поэтому характерной чертой высоконагруженных систем является не просто большое количество пользователей, но и позитивная динамика количества пользователей.
В контексте реалий Web 2.0 растущее количество пользователей может привести к тому, что такую же позитивную динамику вы будете иметь и по данным. Поэтому в контексте высоконагруженных систем корректней говорить не о большом, а о растущем количестве пользователей и данных.
Интерактивность
И тут мы подходим к своеобразной финальной ноте в аккорде качеств highload систем, если позволите так выразиться. Интерактивность – одно из основополагающих качеств высоконагруженной системы. Интерактивность подразумевает, что пользователь после того как послал запрос сидит и ждет ответа, а люди как известно ждать не любят. При этом большинство Интернет-приложений о которых мы говорим не являются критическими важными в жизни людей. Twitter, Flickr, Facebook и т.д. это все круто конечно, но если они будут отвечать непомерно долго, я найду чем занятся еще. Наша жизнь от них не зависит (прогрессирующие формы задротства у некоторых особо аддиктивных индивидов не в счет), а это значит что эти приложения должны занимать минимум нашего времени. То есть отвечать за приемлимое время. Это контрастирует, например, с системами пакетной обработки данных, в которых время ответа системы вторично.
Из этого правила безусловно есть исключения. Представьте что вы только что совершили покупку в Интернете сообщив свою платежную информацию третьим лицам. Скорее всего вы дождетесь ответа системы, даже если она будет отвечать дольше минуты. Но как известно исключение из правила лишний раз подверждает само правило.
Управление ресурсами
Качество интерактивности очень важно для понимания сути высоконагруженных приложений, потому что по вышеобозначенным причинам разрабатывая такую систему вы должны быть уверены вот в чем:
Каждый раз когда приложение получает очередной запрос, у него должно быть достаточно свободных ресурсов (CPU, память, диск, сеть) для обработки запроса за приемлимое время.
Возможно это и звучит тривиально, но именно данное требование приводит нас к основному посылу данной заметки:
Контроль за ресурсами является неотъемлимой частью работы с высоконагруженным проектом.
Необходимо также учитывать тот факт, что из-за позитивной динамики свободных ресурсов становится меньше с течением времени. В этом заключается “парадокс” высоконагруженных систем. Если вы возьмете высоконагруженный проект и заморозите его разработку (отправите всех разработчиков в бессрочный отпуск), то рано или поздно он перестанет работать.
Высоконагруженная система – это интерактивная распределенная система которая требует постоянного контроля за собственными ресурсами. В противном случае она перестает работать.
Это противоречит обывательскому опыту. Как может само по себе поломаться то, чего не меняли? У программного кода нет срока годности. Причина в том, что со временем системе просто перестанет хватать ресурсов. А нехватка ресурсов провоцируется факторами, часть из которых мы уже рассмотрели:
Если посмотреть темы докладов на конференциях посвященных тематике разработки высоконагруженных систем (например, тот же highload), то большинство тем с которыми выступают докладчики можно свести к двум основополагающим направлениям:
Эту дихотомию я уже затрагивал ранее в заметке Performance vs. Scalability.
Фактически речь на таких конференциях идет в основном о различных способах адекватного управления аппаратными ресурсами в контексте баз данных, языков программирования, операционных систем, алгоритмов, моделей ввода/вывода, вычислительных парадигм и т.д.
Просто подумайте над этим. Большая часть пропогандируемых в настоящее время баз данных под эгидой NoSQL, не предоставляет качественно новых возможностей для разработчиков. Реляционная модель позволяет относительно легко все это реализовать не выходя за рамки одной парадигмы. В этом, я полагаю, и заключается одна из причин почему реляционки приобрели такую популярность и до сих остаются самым распространенным типом БД. Так называемые, пост-реляционные базы данных не являются инструментом для решения качественно новых задач, всего лишь инструментом для более эффективного решения существующих. Именно важность эффективной траты ресурсов стала катализатором популярности NoSQL тематики.
Высоконагруженный проект – это Интернет приложение
Если исходить из того что неотъемлемой частью высоконагруженного проекта является постоянный рост данных и аудитории, то становится понятно почему высоконагруженные проекты – это поголовно Интернет приложения.
В реальной жизни всегда есть некий предел, который не позволяет использовать систему все возрастающему количеству людей. В том же метрополитене человеку требуется некоторое время, чтобы пройти через турникет. Исходя из этого времени, а также общего количества турникетов можно достаточно точно расчитать верхний предел возможной нагрузки. Выглядит очень невероятным чтобы за секунду через один турникет могло пройти 10 человек.
В сфере High Performance Computations приложения могут выполнять просто гигансткое количество операций в единицу времени. Больше чем любое Интернет-приложение. Но это количество зависит только от объема входных данных, а также алгоритма обработки (например, от точности моделирования, если речь идет о моделировании динамических систем). Тяжело придумать причину почему нагрузка на такую систему может вырасти сама по себе без вмешательства персонала ее сопровождающего.
Похоже, что Интернет-приложения это единственная сфера в которой нагрузка есть переменная не имеющая верхнего предела.
Работая в Highload проекте
Но не стоит возводить данный тип проектов на какой-то особый пьедестал. Highload проект это в первую очередь такой же самый проект как и все остальные. Проект в котором бывают и гонки за фичами и deadline’ы и сложности межличностных отношений и все прочие “прелести” процесса разработки ПО. Но говоря о “высоконагруженной составляющей” проекта, работа над ней сводится к тому, что постоянно приходится искать ответы на ресурсно-ориентированные вопросы:
Не удивительно что в такого рода проектах гигантское значение имеет система мониторинга. Она предоставляет массу информации для ответа на такого рода вопросы. Сопровождать и развивать высоконагруженный проект без мониторинга хотя бы основных метрик по всему серверному парку это безрассудство.
Это приводит нас к cписку первостепенных задач которые стоят перед разработчиками в контексте высокой нагрузки:
В состоянии гонки
У вас как у инженера нет прямого влияния на количество пользователей и есть опосредованое влияние на объемы данных. В конце концов, чем больше данных и чем шире аудитория, тем лучше для бизнеса. Больше пользователей – больше возможностей для монетизации. Больше данных – больше конкурентное преимущество, а так же потенциально более высокие темпы роста проекта. Необходимо смирится с непрерывным ростом этих двух метрик.
Что же остается? Не так много на самом деле. Сделать так чтобы возможности системы были всегда на шаг впереди ее потребностей.
ITSource
Высоконагруженные системы: введение в highload
Высоконагруженные системы (highload) стали трендом еще в 2012-ом году. По крайней мере, мы занялись ими именно тогда=) Но вот незадача – четкого определения термина нет до сих пор. Где проходят границы высоких нагрузок? 10 запросов с секунду – это уже хайлоад или еще нет? А 100, 1000? Мы вас удивим, но дело здесь совсем не в цифрах.
Высокая нагрузка – это сколько?
Для начала нужно понять одну простую аксиому: высокие нагрузки – понятие относительное. Их нельзя измерить количеством запросов, которые поступают на сервер, или скоростью работы веб-сайта. Ведь некого «среднего» количества запросов, как и «среднего» сайта, не существует. Один веб-ресурс сможет нормально обрабатывать тысячу запросов в секунду, а другой обвалится на сотом коннекте. Так что дело тут вовсе не в количественных показателях.
Мы собрали самые популярные определения highload от IT-специалистов и просто разбиравшихся в этой теме пользователей:
Хайлоад – это когда IT-система перестает справляться с текущей нагрузкой.
Хайлоад – это когда традиционных подходов к работе IT-инфраструктуры уже не хватает.
Хайлоад – это когда одного сервера становится мало для обслуживания клиентов.
Хайлоад – это когда железо не справляется с выросшими нагрузками.
Хайлоад – это когда возникающие проблемы нельзя решить имеющимися средствами.
Хайлоад – это когда инфраструктуру нужно срочно масштабировать.
Последнее определение позволяет посмотреть на определение highload под новым углом:
Это система, которая постоянно масштабируется и ресурсов которой хватает для работы с текущими нагрузками.
Таким образом, из описания состояния мы переходим к описанию качеств системы, которая растет вместе с потребностями бизнеса.
5 качеств высоконагруженной системы
Это система с огромной аудиторией
Если говорить о веб-приложениях (а именно их большинство специалистов относят к категории highload), то это тысячи, а иногда и сотни тысяч человек. Конечно, конкретную цифру назвать нельзя. Но понятно, что интернет-магазин, обрабатывающий 10 заявок в день, хайлоадом не назовешь. А вот Facebook, Amazon, Flickr, MySpace или Youtube – да, конечно.
Это распределенная система
Если приложению приходится обрабатывать огромные объемы данных, которые еще и постоянно растут, одного сервера не хватит. Самые крупные хайлоады (например, Google или тот же Facebook) работают на сотнях серверов.
Но огромное количество машин обусловлено не только высокими нагрузками. Точнее, не только большим количеством запросов, которые приходится обрабатывать в режиме нон-стоп. При таки темпах сервера быстро выходят из строя, поэтому чем их больше, тем выше вероятность, что система быстро восстановится после сбоя.
Это система с позитивной динамикой
Если интернет-предложение представляет ценность для пользователей, его аудитория растет. Поэтому хайлоад – это не просто система с большим количеством пользователей, а система, которая интенсивно наращивает аудиторию.
Это интерактивная система
Если человек вводит поисковый запрос в Google, загружает ролик на YouTube или оформляет покупку на eBay, он ожидает, что мгновенно получит результат. Если система будет долго отвечать, скорее всего, он найдет себе другое занятие. Поэтому мгновенный отклик – отличительная и очень важная черта хайлоад-системы.
Это высокоресурсная система
Этот пункт напрямую связан с предыдущим. Чтобы давать мгновенный отклик, системе проходится задействовать много ресурсов – CPU, оперативную память, место на диске и т.д. А для этого нужно, чтобы ресурсы: а) были свободными и б) были в достаточном количестве (лучше даже с запасом).
Здесь мы подходим к парадоксу высоконагруженных систем: чем стремительнее они растут, тем жестче приходится контролировать ресурсы. Когда приложение наращивает аудиторию, закономерно растет и количество запросов. А с ними – объемы ресурсов, которые нужно тратить для поддержания интерактивности.
То есть, хайлоад – это система, которую нужно постоянно масштабировать. Настроить ее работу таким образом довольно сложно, но с точки зрения бизнеса оно того стоит.
Лекции Технопарка. 3 семестр. Проектирование высоконагруженных систем
И снова в эфире наша постоянная рубрика «Лекции Технопарка». На этот раз предлагаем вам ознакомиться с материалами курса «Проектирование высоконагруженных систем». Цель курса — получение студентами навыков проектирования высокоэффективных программных систем.
Лекция 1. Введение в Highload
В начале лекции даётся определение — что можно считать высоконагруженной системой и в каких единицах измеряется нагрузка. Объясняются особенности подобных систем, вкратце говорится о Slashdot-эффекте. Приводятся критерии высокой доступности сайта с точки зрения времени простоя за месяц и год. Описываются различные архитектуры веб-серверов, устройство типичного веб-сайта, LAMP-технология. Далее рассказывается о методах подключения динамического содержимого: CGI, FastCGI, UWSGI, mod_perl, mod_php, самописных модулей, node.js, content_by_lua. Рассматривается понятие блокирующих операций и способы неблокирующей обработки.
Лекция 2. Сетевая подсистема
Начинается лекция с объяснения того, какие факторы влияют на пропускную способность системы: сетевые задержки, скорость света и расстояние между ДЦ, устройство TCP-handshake, packetloss и TCP-retransmit. Объясняется, как выявить узкие места с точки зрения пропускной способности. Рассматривается понятие Looking Glass в качестве одного из инструментов для диагностики проблем с пропускной способностью. Далее говорится о модели OSI применительно к TCP/IP, о нюансах маршрутизации. Затем рассказывается о возможных сетевых проблемах и различных способах их решения (UDP, multicast, Jumbo-frames, socket на процесс, многопоточные сетевые карты). Существенная часть лекции посвящена оптимизации TCP/IP-стека под высокую нагрузку.
Лекция 3. Протокол HTTP и веб-оптимизация
Перечисляются некоторые правила веб-оптимизации. Рассматриваются особенности браузеров, используемые для оптимизации времени загрузки страницы. Затрагиваются вопросы сжатия данных gzip, уменьшения количества запросов, минимизации количества запросов к DNS, а также файлы скриптов и CSS принудительного кеширования статики. Объясняется, как анализировать информацию, полученную с помощью Conditional GET. После этого рассказывается о возможностях по оптимизации редиректов, о CSS-спрайтах. Затем даётся информация о keep-alive, chunked, о грамотном использовании cookies. Объясняются преимущества нескольких соединений на домен, вынос долгих запросов в AJAX или iframe.
Лекция 4. Масштабирование нагрузки
Сначала даётся определение масштабирования нагрузки и ее видов (вертикального и горизонтального). Далее подробно рассказывается об алгоритмах балансировки нагрузки (random, round-robin, weighted round-robin, least connections, least response time, load-based). Рассматриваются инструменты для балансировки: Round-Robin DNS, xixi DNS, L4-балансеры (Cisco CSS, LVS), L7-балансеры (Cisco ACE, LVS, nginx).
Лекция 5. Оперативная память
Разбирается аппаратная конфигурация типичного сервера, объясняются устройство физической памяти и причины снижения общей производительности системы. Рассказывается, как организуется кэширование на аппаратном уровне, а также рассматриваются практические способы ускорения работы с памятью сервера (последовательное чтение с запасом, чтение без перескоков между рядами, prefetching).
Лекция 6. Базы данных и дисковая подсистема
Сначала рассказывается о развитии жёстких дисков и текущем состоянии в плане производительности при линейном, случайном и конкурентном доступе. Сравниваются особенности, преимущества и недостатки разных видов дисковых массивов, в том числе программных. Затем рассматриваются файловые системы Ext4 и XFS. Упоминается третий уровень виртуализации жёстких дисков — LVM (Logical volume manager). Вторая часть лекции посвящена базам данных. Сначала подробно раскрываются достоинства и недостатки СУБД MySQL и PostgreSQL. Разбирается структура расходов на выполнение запроса, а также планирование самогó запроса. Также рассказывается о методах ускорения систем, построенных на базах данных: тюнинг, репликация, шардинг, минимизация сетевой задержки, NoSQL, написание специализированной БД.
Лекция 7. Типовые архитектурные решения
В начале лекции объясняется, чем отличаются frontend- и backend-серверы, рассматривается создание специализированных групп серверов по типам нагрузки (по функциям, по важности, по стабильности, по шардам). Перечисляются критерии сложности и надёжности тех или иных архитектурных решений, даются советы по выбору компонентов, технологий и языков программирования. Далее рассказывается о способах оптимизации (замена оборудования, использование другого алгоритма, переписка кода, распараллеливание задач на разные серверы и т.д.). После этого обсуждаются способы обработки ошибок при выполнении запросов, способы кэширования данных для снижения нагрузки в пиковые часы. Затем рассказывается о записи и обработке логов, о мониторинге нагрузки и работы как всей системы, так и её компонентов.
Чем стандартная архитектура отличается от архитектуры высоконагруженных приложений?
Что обозначает выражение высоконагруженная система? Давайте попробуем разобраться, что же такое highload.
Так сложилось, что в нашей стране термин «highload» используют в основном в отношении веб-сервисов, то есть многопользовательских интернет-сайтов. Но это только часть высоконагруженных систем, к ним еще относятся и различные управляющие и бизнес-приложения. В чем отличительные особенности системы highload?
Highload – это приложение с высокой нагрузкой, которая возникает ввиду:
Все вышеперечисленные факторы как вместе, так и по отдельности характеризуют высоконагруженное приложение. Для работы такой системе требуется много ресурсов.
Высоконагруженное приложение характеризуется большим количеством данных, пользователей и расчетов
Отличительные особенности высоконагруженных систем
Чтобы понять, чем highload-приложения отличаются от обычных, остановимся подробнее на их особенностях.
Такую систему невозможно сделать гибкой. Здесь можно привести пример строительства моста. Вы можете себе вообразить, чтобы одна из опор моста была гибкая? Нет, так и в highload-приложении.
Сложно сделать универсальным все, что связано с доступом к данным. Чтобы система функционировала стабильно, нужно четко понимать, с какой базой данных она будет работать. И использовать при реализации проекта преимущества этой БД, исходя из объемов данных и частоты обращений.
Если в высоконагруженной системе попытаться что-то сделать гибко, потребуется неоправданно большое количество ресурсов.
Существует два пути масштабирования:
Вертикальное масштабирование не бесконечно, поэтому, когда речь идет о highload-системах, многие считают второй подход более предпочтительным. Но полностью отказываться от вертикального масштабирования не стоит. Оно быстрее и дешевле – перестал сервер справляться с нагрузкой, проще купить новый, более мощный, и запустить его в работу, чем переписывать программу.
Разработка высоконагруженного приложения предполагает гибкий подход к масштабированию
Рассмотрим такой пример: система обрабатывает пользовательские анкеты и самая нагруженная часть – вывод фамилий. Наша задача сделать так, чтобы один и тот же модуль исполнялся на разных серверах. То есть раздать сложную задачу на решение разным ресурсам, запараллелить эту функцию.
Решение отличное, после его внедрения система начинает справляться быстрее. Но, как и в случае с вертикальным, горизонтальное масштабирование не бесконечно. Как только мы вводим параллельную обработку, получается, что на каждом из серверов, в каждом потоке, свои данные. Они перестают быть синхронными.
С ростом нагрузки и распараллеливания мы получаем многосистентное состояние данных: параллельно два пользователя начинают менять одну и ту же сущность, а так быть не должно. Введение синхронизатора убирает параллельность, но синхронизатор становится сильно загруженным. Лучше обособить те части, которые должны выполняться синхронно, и с ними идти по пути увеличения производительности сервера.
Как показал пример, для высоконагруженных приложений выполнить масштабирование не так просто, как это описано в учебниках. Оптимальное решение – грамотно совмещать вертикальный и горизонтальный подходы в зависимости от уникальных особенностей системы и изменений требований.
По сути никому не нужны отдельные модули, нужна качественно работающая система в целом. Если мы «распилим» ее на 2 модуля, то будет одна коммуникация – между первым и вторым модулями. Все достаточно просто и есть выигрыш – 2 модуля могут параллельно выполняться и легко масштабироваться. Если же мы разобьем систему на 3 модуля, между ними будет уже 3 коммуникации, на 4–6 коммуникаций и т. д. С увеличением модульности системы сложность коммуникаций и нагруженность интеграционного слоя растут в геометрической прогрессии.
Архитектура высоконагруженных приложений: особенности проектирования highload
Архитектура – это фундамент приложения. И как в строительстве от прочности фундамента зависит качество дома, так в разработке – успешность и жизнеспособность системы.
В своих решениях мы ориентируемся на то, что нужно конкретному бизнесу. Но есть еще и проектирование – то, что бизнес не видит и от чего не получает прямой выгоды. Когда речь идет о высоконагруженных приложениях, недостаточно разработать грамотную архитектуру, нужно еще построить рядом систему мониторинга, которая будет отслеживать жизнеспособность компонентов, скорость реакции, формировать и выводить данные для контроля работоспособности highload-системы.
Стоимость разработки системы мониторинга может занимать до трети всей стоимости создания высоконагруженного приложения. Но без нее сложно построить надежно работающую highload-систему.
Бизнес, к сожалению, не всегда понимает, для чего это нужно. Зачем платить деньги за дополнительный функционал, который не требуется для работы и не приносит прибыль? Возникает вполне оправданное желание сэкономить, но экономить на мониторинге, когда речь идет о highload, – это не лучшая идея.
Система мониторинга – обязательная составляющая высоконагруженного приложения
Что будет, если не внедрить систему мониторинга?
Высоконагруженное приложение может повести себя непредсказуемо и перестать работать в самом неожидаемом месте. Причем система это сделает в момент пиковой нагрузки: в то время, когда бизнес больше всего зарабатывает. Поэтому экономия на системе мониторинга иллюзорна. Отказавшись от нее, в итоге можно потерять много денег.
Можно ли восстановить работоспособность системы без мониторинга?
Это реально, но все зависит от квалификации специалистов. Опытные программисты найдут проблемное место, вопрос в другом: сколько на это уйдет времени и нервов?
Если какой-то модуль не справляется, его можно оперативно перенести на сервер помощнее, добавить память, расширить интернет-каналы, выделить места под БД или добавить дополнительные диски в массив. И все это заранее, не допуская краха highload и финансовых потерь для бизнеса.
Можно ли «прикрутить» мониторинг к готовой системе?
Нет. В готовую highload-систему мониторинг не встроишь. Высоконагруженное приложение изначально должно проектироваться со «свободными местами», куда впоследствии будут вставлены датчики мониторинга. Это можно заложить только на этапе разработки приложения.
Преимущества подхода компании HHI к разработке высоконагруженных систем
Почему это важно? Рассмотрим на примере неверной стратегии, когда решено в случае возникновения необходимости горизонтально масштабировать какую-то часть системы бесконечно.
Вроде бы ничего плохого в таком подходе нет. Но если сначала потребуется сервер за 0,5 млн, то потом более мощный – за 3 млн, в дальнейшем – за 30 млн, а система все равно не будет справляться. И даже если вы согласитесь платить дальше, то рано или поздно не найдется технического способа решения проблемы.
Итог: вы выкинули кучу денег, а в финале остались без решения и будете вынуждены делать систему с нуля. Именно поэтому стратегию – понимание того, как будет дорабатываться система, – наши специалисты разрабатывают заранее.
Здесь работает правило 95-процентный процентиль. Суть: не стоит стараться решить все проблемы, работать нужно над 95 % функций, а 5 % рассматривать как частные случаи, которые ведут к усложнению и удорожанию системы.
Мы помогаем нашим клиентам отделять зерна от плевел, чтобы получить максимально полезный продукт и сэкономить их деньги.