Тема высоконагруженных приложений у всех на слуху. Тоже решил вставить свои 5 копеек и поделиться опытом создания высоконагруженного приложения на инфраструктуре AWS.
Сначала, буду банален и повторю всем известные истины. Есть 2 пути масштабирования приложения:
1) вертикальное масштабирование — это увеличение производительности каждого компонента системы (процессор, оперативная память, прочие компоненты);
2) горизонтальное, когда соединяют несколько элементов воедино, а система в целом состоит из множества вычислительных узлов, решающих общую задачу, тем самым увеличивая общую надежность и доступность системы. А увеличение производительности достигается добавлением в систему дополнительных узлов.
Первый подход неплох, но есть существенный минус — ограниченность мощности одного вычислительного узла — невозможно бесконечно увеличивать частоту вычислительного ядра процессора и пропускную способность шины.
Поэтому горизонтальное масштабирование значительно выигрывает у своего вертикального брата, ведь при недостатке производительности можно добавить в систему узел (или группу узлов).
Недавно мы в очередной раз постигали все прелести горизонтального масштабирования на практике: строили высоконадежный социальный сервис для болельщиков американского футбола, выдерживающий пиковую нагрузку в 200 000 запросов в минуту. Поэтому хочу рассказать о нашем опыте создания высокомасштабируемой системы на инфраструктуре Amazon Web Services.
Обычно, архитектура веб приложения выглядит следующим образом:
Рис. 1. Типичная архитектура веб приложения
Чаще всего узкими местами системы являются код приложения и база данных, следовательно, стоит предусмотреть возможности их распараллеливания. Мы использовали:
Сначала, буду банален и повторю всем известные истины. Есть 2 пути масштабирования приложения:
1) вертикальное масштабирование — это увеличение производительности каждого компонента системы (процессор, оперативная память, прочие компоненты);
2) горизонтальное, когда соединяют несколько элементов воедино, а система в целом состоит из множества вычислительных узлов, решающих общую задачу, тем самым увеличивая общую надежность и доступность системы. А увеличение производительности достигается добавлением в систему дополнительных узлов.
Первый подход неплох, но есть существенный минус — ограниченность мощности одного вычислительного узла — невозможно бесконечно увеличивать частоту вычислительного ядра процессора и пропускную способность шины.
Поэтому горизонтальное масштабирование значительно выигрывает у своего вертикального брата, ведь при недостатке производительности можно добавить в систему узел (или группу узлов).
Недавно мы в очередной раз постигали все прелести горизонтального масштабирования на практике: строили высоконадежный социальный сервис для болельщиков американского футбола, выдерживающий пиковую нагрузку в 200 000 запросов в минуту. Поэтому хочу рассказать о нашем опыте создания высокомасштабируемой системы на инфраструктуре Amazon Web Services.
Обычно, архитектура веб приложения выглядит следующим образом:
Рис. 1. Типичная архитектура веб приложения
- первым пользователя “встречает” веб-сервер, на его плечи возлагаются задачи отдачи статических ресурсов и передачи запросов приложению;
- далее эстафета передается приложению, где протекает вся бизнес-логика и взаимодействие с базой данных.
Чаще всего узкими местами системы являются код приложения и база данных, следовательно, стоит предусмотреть возможности их распараллеливания. Мы использовали:
- development language and core framework — java 7 and rest jersey
- application server — tomcat 7
- database — MongoDB (NoSQL)
- cache system — memcached
В эту среду наши разработчики, выпускники МФТИ, проведут встречу со студентами МФТИ и расскажут как создаются большие проекты и как сделать Badoo своими силами. 
Эта статья является продолжением статьи 
