5 ошибок при разработке высоконагруженных сервисов18.07.2023 13:46

Высоконагруженный сервис в ИТ — это сервис, который должен обрабатывать большое количество запросов в реальном времени. Примеры высоконагруженных сервисов: социальные сети, поисковые системы, онлайн-магазины, онлайн-игры и т.д. При этом, если не уделить на старте достаточно внимания к проектированию архитектуры и инфраструктуры, сервис может не выдержать нагрузки и отказать либо сразу, либо в самый непредсказуемый момент. Сергей Фролов, СТО дивизиона «Помпеи» компании Notamedia.Integrator, рассказал о пяти самых распространенных ошибках, которые могут возникнуть при разработке высоконагруженных сервисов в ИТ:

1. Недостаточная оптимизация баз данных: При работе с большим объемом данных, необходимо правильно оптимизировать базы данных, чтобы ускорить операции чтения и записи и уменьшить нагрузку на сервер. Если этого не сделать, весь сервис будет тормозить даже с небольшим количеством пользователей.

2. Неэффективное использование кэша: Кэширование — это способ ускорения работы сервиса путем сохранения в памяти результатов предыдущих запросов. Однако неправильное использование кэша может привести к неконсистентности данных и ошибкам в работе сервиса.

3. Неправильная масштабируемость: Сервисы, которые не могут масштабироваться горизонтально (распределение нагрузки между несколькими серверами) или вертикально (добавление ресурсов к одному серверу), могут столкнуться с проблемами производительности и стабильности при росте нагрузки.

4. Неадекватное тестирование нагрузки: Тестирование высоконагруженных сервисов на производительность и стабильность при различных уровнях нагрузки является критически важным. Недостаточное тестирование может привести к проблемам при деплое на продакшн и потере пользователей из-за низкой производительности.

5. Игнорирование отказоустойчивости: Высоконагруженные сервисы должны быть спроектированы таким образом, чтобы они могли продолжать работать при возникновении отдельных сбоев и ошибок. Игнорирование этого аспекта может привести к потере данных или к недоступности сервиса для пользователей.

Недостаточная оптимизация баз данных

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

Вот несколько аспектов из нашей практики построения таких систем, которые следует учитывать при оптимизации баз данных.

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

Часто выручает нормализация данных, когда мы хотим уменьшить дублирование и улучшить структуру данных. Нормализация может оптимизировать производительность, но в некоторых случаях может быть полезно использовать денормализацию (объединение данных) для ускорения чтения данных. Это работает при условии, что это не вызовет проблем с целостностью данных.

Разделение данных на разные таблицы, схемы или даже базы тоже может помочь снизить нагрузку на отдельные компоненты системы и улучшить производительность. Сюда же относится анализ и оптимизация SQL-запросов, а также использование подзапросов, объединений или представлений для упрощения запросов.

Важная вещь, о которой все забывают, это регулярный мониторинг производительности базы данных и настройка параметров конфигурации. Исходя из практического опыта, такой подход может помочь в обнаружении и устранении возможных проблем с производительностью —, а это важно для высоконагруженных сервисов.

Неэффективное использование кэша

Кэширование — это процесс хранения результатов запросов или часто используемых данных в быстродействующей памяти для ускорения последующих запросов к этим данным. Это особенно полезно в таких сервисах, чтобы повторяющиеся запросы к одним и тем же данным не создавали значительной нагрузки на сервера баз данных.

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

С другой стороны, если кэш не инвалидируется (не очищается) при изменении данных, пользователи могут получать некорректную информацию. Стоит заранее продумать и настроить механизмы инвалидации кэша, чтобы избежать подобных ситуаций. Если кэширование используется неэффективно, например, при хранении больших объемов данных, которые редко запрашиваются, это может привести к тому, что данные часто используемых запросов будут вытесняться из кэша, что снижает производительность сервиса.

Неправильное использование кэша может усложнить архитектуру системы и затруднить отладку и поддержку сервиса.

Чтобы снизить вероятность появления ошибок оптимизации использования кэша, мы рекомендуем подойти к вопросу с разных сторон. Самое очевидное — оцените, какие данные или запросы используются чаще всего, и сосредоточьтесь вначале на их кэшировании. Это сразу снизит нагрузку на сервер и ускорит обработку запросов.

Определите оптимальные параметры кэширования, например размер кэша, время жизни кэшированных данных и алгоритмы вытеснения данных из кэша. Это поможет обеспечить актуальность данных и эффективное использование ресурсов. В зависимости от архитектуры системы и типа данных, можно использовать разные уровни кэширования — на уровне сервера, базы данных, приложения или даже на стороне клиента.

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

Неправильная обработка ошибок и исключений

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

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

Самый простой способ обработать ошибки и исключения — использовать стандартные механизмы обработки исключений: Каждый язык программирования предоставляет свои механизмы для этого (например, try-catch блоки). Используйте их вместо временных костылей или нестандартных решений. Также стандартными средствами записывайте информацию об ошибках и исключениях в журналы (логи) для последующего анализа и устранения проблем. Это может помочь разработчикам быстрее находить и исправлять ошибки, а также определить узкие места в системе.

Вместо того чтобы показывать технические детали ошибок пользователям, старайтесь предоставлять им понятные, дружественные сообщения, которые объясняют, что произошло и, по возможности, как исправить ситуацию. Также убедитесь, что ошибки и исключения обрабатываются на всех уровнях системы — от пользовательского интерфейса до базы данных.

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

Неадекватное тестирование нагрузки

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

Многих проблем с работой под нагрузкой можно избежать, если до запуска оценить производительность серверов, сети и других компонентов инфраструктуры. Так можно определить возможные узкие места, которые могут возникнуть при увеличении нагрузки и заранее их устранить. Здесь может помочь сбор и анализ данных о производительности, времени отклика и других показателях, которые характеризуют работу сервиса при различных уровнях нагрузки.

Можно оценить потенциальный объем на старте и потенциальный прирост данных в сущностях — например + 500 000 записей в месяц. Это поможет определить, какие нужны мощности на старте, а также оценить потенциально использование функционала. К примеру, можно предположить, что под нагрузкой будет 3000 пользователей в минуту на главной и на двух разделах, а на остальных страницах — по 100 в минуту. Потенциальный рост — +100 пользователей в минуту за месяц. Так можно предположить, с какими нагрузками столкнётся сервис на разных этапах и как к этому подготовиться.

Момент, который часто не учитывают — аспекты безопасности при тестировании нагрузки, так как увеличение нагрузки может привести к уязвимостям в системе. Проверяйте наличие защиты от DDoS-атак и других угроз, которые могут возникнуть при высокой нагрузке.

Самый полезный лайфхак в этом плане, который мы используем всегда — это когда тестировщики и разработчики находят общий язык, не конфликтуют между собой, а действительно сообща работают над запуском сервиса. Это позволяет обеим командам учитывать специфические особенности системы и архитектуры при проведении тестирования.
Также важно планировать и использовать очереди и фоновые задания с показом клиенту позиций в очереди. Не стоит пытаться выполнить все за один раз — в какой-то момент система может не выдержать и превратиться в тыкву. Также важно не делать долгих процессов — код должен уметь работать в пошаговом режиме, при этом одна итерация не должна длиться дольше минуты (это желательное поведение, но иногда от него можно отойти).

Игнорирование отказоустойчивости

Отказоустойчивость означает способность системы продолжать штатную работу при возникновении отдельных сбоев или ошибок. Важно учитывать отказоустойчивость на всех этапах разработки системы — от проектирования архитектуры до тестирования и эксплуатации.

Для обеспечения отказоустойчивости мы советуем сразу уделить внимание надёжности и дублированию аппаратного обеспечения, в том числе использование различных серверов, дисков и сетевых устройств. Также стоит размещать сервера в разных географических зонах, чтобы избежать проблем, связанных с местными сбоями или стихийными бедствиями.

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

Разработка отказоустойчивых систем также включает применение технологий, обеспечивающих бесперебойную работу приложений. Хорошо зарекомендовали себя горизонтальное и вертикальное масштабирование, балансировка нагрузки, кэширование и асинхронные операции. Сюда же — симуляция различных сбоев, таких как отключение серверов, сетевых устройств или других компонентов системы, чтобы оценить поведение сервиса в условиях аварийных ситуаций и определить возможные узкие места.

Помимо этого, необходимо регулярно мониторить работу сервиса, собирать и анализировать данные о его производительности и использовании ресурсов. Это позволит своевременно выявлять и устранять проблемы, потенциально связанные с отказоустойчивостью системы.

Что в итоге

При разработке высоконагруженных сервисов нужно уделять особое внимание мониторингу и логированию для быстрой диагностики проблем, оптимизации производительности, чтобы приложение работало стабильно даже при высоких нагрузках, а также заранее планировать ресурсы, чтобы была возможность удержать нагрузку в любых условиях. Если учитывать эти моменты, то можно создать стабильное и надежное приложение, которое будет выдерживать любые нагрузки.

В следующей статье мы подробно разберём системы мониторинга и логирования — как они помогают обслуживать сложные информационные системы и следить за тем, чтобы всё работало без сбоев.

Полный текст статьи читайте на CMS Magazine