Доклад Алексея Строева, технического директора ADV/web-engineering, на секции ADV на Russian Digital Week 2013 (http://conf.tagline.ru/program/7/mgmt-prod-hr). Секция была посвящена повышению качества производимых студиями интернет-проектов.

1. Масштабирование решений:
проекты, которые растут вместе с
клиентом
Строев Алексей
Технический директор
ADV / web-engineering co.

2. Кто я?
Строев Алексей
Технический директор
ADV/web-engineering co.
stroev@adv.ru
facebook.com/alex.stroev.m

3. Путь к совершенству – вечность.

4. Для чего нужно масштабирование?
• Расширение бизнес-предложений
• Увлечение хранимой информации
• Рост посещаемости
• Расширение спектра возможностей
• …

5. Инструменты масштабирования

6. Кластеризация vs Шардинг vs
Репликация
• Решение проблем разрастания данных
• Решение проблем нагрузки на сервера
• Перенос части логики на БД

7. Шардинг

8. Цель должна оправдывать средства
• Не спешите покупать новый дорогой сервер
• Анализируйте и изолируйте проблемные места
(большие таблицы, тяжелые запросы)
• Решений горизонтального масштабирования БД
несколько — выбирайте оптимальное
• Репликация — не единое доступное решение,
анализируйте проблему
• Шардинг — горизонтально масштабируемое
решение, которое практически не имеет
ограничений, но требует грамотного архитектурного
решения
• Продумайте возможность гибридного решения
(совмещение вертикального шардинга и
репликации)

9. Используйте облака!

10. Что это дает?
• Минимальные первоначальные затраты
• Высокая доступность и надежность
• Отсутствие эксплуатационных затрат
• Гибкость IT-инфраструктуры
• Мобильность

11. Кэширование

12. Что кэшируем?
• Кэширование запросов
– Хранение результатов запроса
• Кэширование статики
– Инструменты – nginx, iis etc…
– Изображения, стили, javascript
• Кэш – хранилища
– MemCache
– APC

13. Изолирование компонентов

14. Варианты изолирования
компонентов
• Программные
– Использование IoC
– Реализации:
• Dependency Injection
• Factory Method
• Service locator
• Аппаратные
– Геораспределение

15. А что дальше?

16. Рефакторим….
Причины:
– Новый функционал, непредусмотренный
архитектурой
– Необходимо исправить ошибку, причины
возникновения которой сразу не ясны
– Преодоление трудностей в командной
разработке, которые обусловлены сложной
логикой решения

17. Рефакторим….
Признаки:
– Дублирование кода
– Длинный метод
– Большой класс
– Длинный список параметров
– «завистливые» функции — это метод, который
чрезмерно обращается к данным другого
объекта
– Избыточные временные переменные
– Классы данных
– Не сгруппированные данные

18. Закончили рефакторинг
• Цель достигнута – сделать код легче для
понимания
• Удален «мертвый код»
• Готова «почва» для реинжинирнга
• Не забываем оборачивать в unit-тесты

19. Промежуточный итог
• Проект растет…
И начинается
• Масштабирование в ширь (лень)
• Масштабирование в глубь (проще)

20. Масштабирование за счет мобильности

21. Чего стоит избегать или типичные
ошибки
• Слепое следование модным на данный момент
трендам и технологиям
• Отсутствие средств мониторинга и планирования
нагрузки
• Принятие решений, основываясь на предыдущем
опыте, абсолютно не связанным с текущим проектом
• Непонимание основных принципов масштабирования
• Масштабирование невозможного
• Single Point of Failure
• Нездоровое стремление использовать
повсюду облачные технологии

22. Повторенье — мать ученья

23. Разработчик должен разрабатывать

24. Анализируйте нагрузки, падения ресурса (площадки) - это
риски, которые можно просчитать.

25. Находите узкие места до, того как
они найдут вас

26. Стройте план(карту) проекта
Предлагайте варианты развития клиенту

27. Документация наше всё…

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

29. ?

30. Спасибо за
внимание.

31. Контактная информация:
Строев Алексей
Технический директор
ADV/web-engineering. co
stroev@adv.ru
facebook.com/alex.strove.m
Спасибо за внимание!