5 советов для разработчиков HighLoad-систем
Предлагаем вашему вниманию несколько полезных советов. Они могут пригодиться тем, кто разрабатывает и поддерживает высоконагруженные системы.
Совет № 1: помните, что сломаться может любой компонент
Рано или поздно что-нибудь откажет, причём сломаться может всё — не забывайте об этом, когда проектируете высоконагруженную систему. А цитата из закона Мерфи должна висеть у вас на стене напротив рабочего места. Ведь если есть вероятность, что какая-нибудь неприятность может случиться, она обязательно произойдёт.
Ваша задача — подстелить соломку везде, где это возможно. Что имеется в виду: 1. Зеркалирование 100 % серверов баз данных. 2. Ежедневное резервное копирование. 3. Механизм round robin DNS для балансировки нагрузки. 4. Несколько серверов приложений обеспечит масштабирование и позволит обновлять их поочерёдно, не прерывая обслуживание. 5. Серверы доменных имён располагайте в разных корневых зонах сети. Например, .com, .net, .org, .ru. В результате вы получите дополнительный уровень надежности, ведь если вся доменная зона .ru будет по каким-либо причинам недоступна в DNS, клиенты всё равно смогут работать с вашим сервисом.
Также обратите внимание, что зеркала должны быть расположены не просто в разных дата-центрах, а в разных странах. Дело в том, что в дата-центрах систематически проводятся регламентные работы, а ваш сервис прерывать свою работу не должен. Вдобавок к этому, следует регулярно устанавливать обновления безопасности, что иногда требует перезагрузки. И горячее переключение на резервный сервер будет как нельзя кстати.
Совет № 2: преждевременная оптимизация вредна
Как правило, в процессе роста нагрузки приходится покупать память (RAM) и оптимизировать приложение. Но если у вас есть предположения, что нужно что-то ускорить, не спешите это делать, предварительно не выполнив точных замеров. Очень велика вероятность, что ваши предположения ошибочны. То есть вы не можете точно знать, где находится «узкое место» вашего приложения.
Как же понять, какая конкретно функция работает недостаточно быстро? Профайлер на боевом сервере? Можно, но слишком много накладных расходов, плюс сервис начинает тормозить. Сложно судить о проблемных местах и по синтетическим замерам в тестах на машине разработчика…
Как вариант — добавление в код контрольных точек и оценка скорости приложения по времени исполнения программы между этими точками. В результате вы сможете выяснить то, о чём и не предполагали. И создать решение, которое будет быстрее, чем у конкурентов на рынке.
Совет № 3: тестируйте всё
Необходимо тестировать все изменения, причём делать это следует на объёмах данных, которые максимально приближены к боевым. А запуск сотен автоматических тестов при каждой сборке приложения обеспечит отсутствие фатальных ошибок.
Представьте, что вам надо изменить структуру таблицы в БД. Такая процедура потребует остановки сервиса, поэтому выполнять её придётся в наименее нагруженное время — в выходные ночью. И скорость выполнения технических работ будет чрезвычайна важна. Естественно, вы сделали предварительные тесты на маленькой таблице, которые показали, что на процедуру уйдёт не более минуты. Однако остановив сервис и запустив процедуру на боевом сервере, вы обнаруживаете, что процедура не закончила свою работу ни через минуту, ни через десять, ни через час. А всё потому, что стал перестраиваться кластерный индекс в таблице большого объёма, чего не происходило в маленькой таблице.
Совет № 4: обеспечьте высокую скорость тестирования
Не жалейте денег на ресурсы для команды и приобретайте высокопроизводительные сервера для автоматизированных тестов, ведь их число постоянно растёт.
Несмотря на тестирование, иногда в релиз попадает ошибка. Да, никто не любит откатывать релизы, но в некоторых случаях без этого не обойтись. А исправления надо вносить очень быстро, чего можно достичь за счёт автосборки, автоматизированных тестов и распараллеливания. При медленном тестировании ошибки исправляются дольше со всеми вытекающими отсюда репутационными и финансовыми потерями.
Совет № 5: должна использоваться каждая функция продукта
Развитие требует жертв, а хороший продукт — многих итераций. Причём речь идёт не только о добавлении новых функций, но и об удалении старых и ненужных, т. к. они: — занимают лишнее место на экране; — потребляют ресурсы на поддержку; — не несут никакой ценности, ведь их не используют.
Как хороший садовник обрезает молодые побеги каждую весну, так и вы должны «обрезать» ненужную функциональность, формируя правильную, здоровую и красивую «крону дерева».
Да, кому-то это не понравится, ведь даже непопулярные фичи использует не менее 2 % пользователей. Но, как уже было сказано выше, развитие требует жертв. К тому же, всегда предоставляйте возможность сделать то же самое (быстрее и удобнее), но несколько по-другому. Правда, всё равно не все останутся довольны, ведь, к сожалению, привычки оказываются сильнее…
Статья подготовлена по материалам блога компании Pyrus.
