20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов

Несколько кейсов
из жизни "больших" проектов
Виталий Гаврилов
Технический директор «Ленвендо»
info@lenvendo.ru
www.lenvendo.ru
2013 dev.it-portfolio.net

«Ленвендо» в приближении
тел.: +7 (812) 322-95-87 info@lenvendo.ru
Профессионал в области разработки сложных Интернет - решений и
высоконагруженных проектов

О чем мы сегодня поговорим?
Управляемое статическое кеширование
√ nginx + embed perl
√ Redis
√ RabbitMQ
Где и когда нужно использовать СУБД Oracle
Хитрости проекта с использованием СУБД PostgreSQL, оптимизированного
под высокие нагрузки
√ pl_proxy
√ embed perl
Резервное копирование высоконагруженного проекта: проблемы и решения
Особенности построения проекта, распределенного на 2 и более
датацентрах,
√ round-robin DNS
√ csync2
√ mysql multimaster replication
√ Memcached

Хитрости проекта с
использованием СУБД
PostgreSQL,
оптимизированного под
высокие нагрузки
Раздел 1.

Масштабирование проекта с использованием pl_proxy
 в каждой БД - полная копия всех данных
 использование встроенной WAL-PITR нативной репликации
 всего два кластера master и slave
 в кластере master: 2 сервера (можно больше). Основной
сценарий использования: RUN ON ALL
 в кластере slave: 4 сервера (можно больше, но должно быть
кратно двум). Основой сценарий использования: RUN ON ANY
Хитрости проекта с использованием СУБД
PostgreSQL

Хитрости проекта с использованием
СУБД PostgreSQL

СУБД PostgreSQL

Доступ к сессии пользователя через embed perl
 хранение сессий в memcached
 передача ключа сессии через сессию PostgreSQL
 доступ в систему полнотекстового поиска Sphinx через mysql интерфейс
непосредственно из plperl
СУБД PostgreSQL

Хитрости проекта с использованием СУБД
PostgreSQL

Хитрости при использовании СУБД
PostgreSQL

Резервное копирование
высоконагруженного проекта:
проблемы и решения
Раздел 2.

Типы контента:
 Файлы проекта
 Статический контент проекта
 База данных проекта
 Настройки виртуальных (и хостовых)
машин или образы виртуальных машин
Резервное копирование высоконагруженного
проекта: проблемы и решения

Много задач? Инструмент один – bacula
Файлы сайта:
 полная резервная копия - 1 раз в 1-2 недели,
 дифференциальная копия - 1 раз/день
Cтатические файлы:
 полная резервная копия - 1 раз/месяц,
 дифференциальная копия – 1 раз в 3-7 дней,
 инкрементальная копия – 1 раз/день
 резервная копия БД (бизнес-критичные таблицы) не реже 1
раз/день
 полная целостная резервная копия - не реже 1 раз/нед.
(http://www.bacula.org/en/)

Резервная копия БД – о чем надо помнить?
 должна выполнятся в наименее загруженное время со slave сервера, на
котором нет продуктивной нагрузки во время снятия копии
 должна быть логически целостной
 помните, резервная копия - это не спасение
 и дублирующий slave сервер тоже
Что можно сделать?
 Дублирующий slave сервер с отставанием во времени от 15 минут до
часа (зависит от квалификации службы поддержки)

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

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

Особенности построения
проекта, распределенного на 2
и более датацентрах
Раздел 3.

Особенности построения проекта,
распределенного на 2 и более датацентрах
Причины особенностей
 Скорость взаимодействия внутри датацентра гораздо выше, чем
между датацентрами
 Если взаимодействие между датацентрами идет по публичным
сетям, трафик должен цифроваться
 В общем случае невозможно предугадать в какой из датацентров
придет следующий запрос посетителя, поэтому каждый
датацентр должен содержать достаточно данных для подготовки
ответа, либо запрос должен быть прозрачно проксирован в
датацентр, где есть необходимые данные

Преимущества
 встроенная поддержка шифрования
 продуманные механизмы определения «кто прав» в случае
конфликтов синхронизации
 понятная структура конфигурационного файла
Недостатки
 критичен к стабильности соединения (может зависнуть, нужен
контроль)
 недостаточно документирован
 синхронизация требует большого числа дисковых операций и
достаточно много времени (до 15 минут на 50 Гб данных), при
этом одновременная двусторонняя синхронизация хотя и
возможна, но не рекомендуется
Синхронизация файлов – csync2

Основные настройки
 server_id = N
 log-bin = <путь к файлу журнала транзакций>
 relay-log = <путь к файлу журнала транзакций мастер-сервера>
 relay-log-index = <путь к индексному файлу журнала транзакций мастер-
сервера>
 auto_increment_increment определяет шаг изменения
AUTO_INCREMENT
 auto_increment_offset определяет начальное значение инкремента
 log_slave_updates логирует обновления с мастера
 slave_net_timeout таймаут получения данных с мастера перед сбросом
соединения
Multimaster репликация MySQL

Основные команды
 START SLAVE [IO_THREAD | SQL_THREAD]
 STOP SLAVE [IO_THREAD | SQL_THREAD]
 SET GLOBAL sql_slave_skip_counter=<N>
 CHANGE MASTER TO …
 RESET SLAVE
Multimaster репликация MySQL

Где хранить сессии? Конечно, в memcached
Преимущества
 общее хранилище для всех виртуальных машин кластера
 позволяет получить доступ к сессии
 достаточно быстро
Недостатки
 требует кастомных инструментов поддержания актуальности
данных между ДЦ
 нагружает канал большим числом мелких пакетов
 в случае падения службы все сессионные данные могут
оказаться потерянными
Особенности построения проекта,
распределенного на 2 и более датацентрах
http://www.memcached.org/

Управляемое статическое
кеширование, как
способ снижения нагрузки
Раздел 4.

Управляемое статическое кеширование, как

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

Использование заголовков “Cache-Control” и “Expires”
(дает разрешение браузеру не перезапрашивать содержимое
страницы, не спасает от «скачков» посещаемости)
Использование кеширующего прокси сервера в связке с
заголовками “Cache-Control” и “Expires”
(дает устойчивость к «скачкам» посещаемости, не позволяет
оперативно управлять обновлением кеша)
Использование управляемого статического
кеширования
(решает все поставленные задачи)

Сервера FE
 Принимают все входящие подключения
 Фактически самое ненагруженное звено в обработке запроса
посетителя
 Не обладает информацией о связи запроса с элементом
динамической информации
 В большинстве случаев это nginx (www.nginx.ru)

Nginx умеет
 Сохранять полученный ответ в файлах по заранее
определенному пути (директива proxy_store)
 Определять наличие сохраненной копии файла
 Отдавать готовые ответы из сохраненных копий
Nginx не умеет
 Отслеживать корректность отдаваемых данных

За ведение статического кеша отвечает nginx
Из nginx на уровень приложения (в случае если запрос посетителя
обрабатывается приложением, а не берется из закешированной копии,
передается путь к файлу, в который будет сохранен ответ (файл кеша))
На уровне приложения информация о связке информационных
элементов и файла кеша сохраняется в БД (лучше всего подходят
NoSQL базы данных)
При обновлении элемента информации на уровне приложения
отдается команда на удаление файлов кеша по обновленному
информационному элементу (можно делать это как прямой командой в
nginx, который посредством встроенного perl сможет удалять файлы, так и
через диспетчер очереди, в случае нескольких FE серверов)

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

Где и когда нужно использовать
СУБД Oracle?
Раздел 5.

Где и когда нужно использовать СУБД
Oracle?
 Требования заказчика по безопасности и надежности
хранения данных (при условии поддержки проекта
квалифицированным DBA)
 Специфика проекта, требующая тесного взаимодействия с
внутренними системами заказчика, построенными на
продуктах Oracle
 Наличие у заказчика развернутого RAC и команды
администраторов Oracle

 Если масштабы проекта не смогут окупить трудозатрат на
его поддержание
 Если желание сделать проект на Oracle вызвано тем, что
«Это же круто!», «А почему бы и нет?», «А вот у них
Oracle, а мы что хуже?»
 Заказчик не имеет возможности поддержки Oracle и не
представляет во что это выльется
 У вас в штате нет ни одного сотрудника, способного
сделать резервную копию БД Oracle
Когда не стоит переходить на Oracle?

www.lenvendo.ru
info@lenvendo.ru
III место в рейтинге Best in digital 2013
в номинации «Разработка Highload систем»
С удовольствием отвечу на ваши вопросы!

20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (16)

Ähnlich wie 20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов

Ähnlich wie 20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов (20)

Mehr von IT-Portfolio

Mehr von IT-Portfolio (12)

20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов