Яндекс.Облако открыто для всех: наш опыт построения инфраструктуры
Теперь каждый желающий может получить доступ к Яндекс.Облаку для хостинга своих сайтов, навыков под Алису и решения заоблачного количества других задач.
Мы приглашаем всех протестировать наше Облако и его возможности. А чтобы тестирование было заведомо удачным, хотим поделиться с вами нашим опытом построения оптимальной инфраструктуры веб-проекта.
Вот как выглядит оптимальная конфигурация:
Инфраструктура веб-сервиса на базе платформы Яндекс.Облако.
Опыт 1. Новая инфраструктура в параллель со старой
Никто не хочет проверять новые инфраструктурные решения, какими бы хорошими они ни казались, сразу на реальных пользователях. Именно поэтому важна возможность собрать новую инфраструктуру параллельно с действующим проектом. Затем должно быть реализовано практически бесшовное переключение, которое бы прошло незаметно для ваших пользователей.
Опыт 2. Конфигурация должна быть масштабируемой
Об этом много говорят, но часто забывают при реализации проектов. У любого хорошего проекта есть грандиозные планы на резкий рост и миллионы пользователей. Именно подобные амбиции позволяют ему динамично развиваться, но не стоит отбрасывать и экономическую составляющую. Если сейчас речь идёт лишь о нескольких тысячах или даже сотнях пользователей в день, нет смысла платить за сервер, который способен принять многомиллионную аудиторию. Однако нужно сразу выбрать инфраструктуру, которая была бы легко масштабируемой при резком росте. Облачные решения лучше всего подходят для легкого масштабирования, так как не требуют от владельца проекта покупки дополнительных физических серверов, их встраивания в старую инфраструктуру и настройки распределения нагрузки на новые блоки.
Опыт 3. Фронтенд- и бэкенд-сервера + балансировщик
О том, что сайт живёт на сервере, кажется, известно уже практически всем. Но вот о том, что бывают фронтенд- и бэкенд-сервера, даже сейчас задумываются очень немногие. Когда пользователь заходит на ваш сервис, в его браузер или WebView необходимо передать HTML-документ с интерфейсом вашего сервиса. Обычно за формирование и отправку HTML как раз отвечает фронтенд-сервер. Чаще всего он представляет из себя Node.js-приложение, но в простейших случаях может содержать и статическую веб-страницу. Если сервис не требует серьёзной бизнес-логики, то весь спектр взаимодействия процессов внутри проекта допустимо поднять на этом же сервере. В противном случае выделяют отдельный бэкенд-сервер для обработки данных и их отправки на фронтенд — например, в формате JSON.
Передача данных между клиентом, фронтенд- и бэкенд-серверами может регулироваться за счёт балансировщиков нагрузки. Балансировщики несложно запустить на программном уровне — достаточно взять за основу HAProxy, nginx или другое ПО. Балансировщики вкупе с правильной инфраструктурой фронтенд- и бэкенд-серверов помогут защитить проект от внезапных возрастаний нагрузки, перегрузок серверов и «неответов».
Опыт 4. Работа с файлами через совместимое хранилище
На рынке существует несколько хорошо зарекомендовавших себя решений для размещения данных в облаке. Поэтому при выборе убедитесь, что хранилище поддерживает работу с наиболее распространёнными библиотеками, чтобы потом можно было безболезненно сменить одно хранилище на другое. Например, в Amazon Web Services реализовано хранилище под названием S3, которое совместимо с множеством API и SDK. Под него создана масса полезных программ и фреймворков. Их же можно использовать и при работе с Яндекс.Облаком, так как у него S3-совместимое объектное хранилище. Кроме того, оно обладает свойством отказоустойчивости и обеспечивает постоянный доступ к файлам по прямым ссылкам. На такие детали всегда стоит обращать внимание.
Опыт 5. Защита от сетевых атак и нештатных ситуаций
Сейчас история о том, что когда-то Яндекс начинался с сервера, который простая уборщица могла случайно выдернуть из розетки, кажется историческим анекдотом. Однако в случае с нештатными ситуациями или DDoS-атаками небольшого выделенного сервера может быть недостаточно — и такая ситуация очень близка к истории про сервер, незащищенный от уборщицы. Такой одинокий сервер гораздо проще «уронить» или «отключить» от хостинга, чем полноценную облачную инфраструктуру, способную выдерживать гораздо более масштабную нагрузку. Облако умеет отсекать «роботные» запросы и проводить учения по нештатным отключениям.
Отказоустойчивость хранилища ещё не гарантирует защиту от сбоев для всего сервиса. Чтобы обезопасить все компоненты, можно дополнительно:
• Продублировать каждую из перечисленных машин в несколько дата-центров (зон доступности).
• Настроить репликацию облачной БД между двумя или тремя зонами доступности.
Мы постарались переложить наш опыт не только в теоретическое описание в этом тексте, но и в инструментарий Облака. Оно содержит все перечисленные сервисы: виртуальные машины для хостинга серверов, объектное хранилище и сервис контроля за СУБД.
Верим, что наш опыт поможет вам ещё быстрее развивать ваши проекты!
С вами в Облаке
P.S. Подписывайтесь на наши каналы
Блог Яндекса для Вебмастеров
Канал Яндекса о продвижении сайтов на YouTube
Канал для владельцев сайтов в Яндекс.Дзене
Мы приглашаем всех протестировать наше Облако и его возможности. А чтобы тестирование было заведомо удачным, хотим поделиться с вами нашим опытом построения оптимальной инфраструктуры веб-проекта.
Вот как выглядит оптимальная конфигурация:
Инфраструктура веб-сервиса на базе платформы Яндекс.Облако.
Опыт 1. Новая инфраструктура в параллель со старой
Никто не хочет проверять новые инфраструктурные решения, какими бы хорошими они ни казались, сразу на реальных пользователях. Именно поэтому важна возможность собрать новую инфраструктуру параллельно с действующим проектом. Затем должно быть реализовано практически бесшовное переключение, которое бы прошло незаметно для ваших пользователей.
Опыт 2. Конфигурация должна быть масштабируемой
Об этом много говорят, но часто забывают при реализации проектов. У любого хорошего проекта есть грандиозные планы на резкий рост и миллионы пользователей. Именно подобные амбиции позволяют ему динамично развиваться, но не стоит отбрасывать и экономическую составляющую. Если сейчас речь идёт лишь о нескольких тысячах или даже сотнях пользователей в день, нет смысла платить за сервер, который способен принять многомиллионную аудиторию. Однако нужно сразу выбрать инфраструктуру, которая была бы легко масштабируемой при резком росте. Облачные решения лучше всего подходят для легкого масштабирования, так как не требуют от владельца проекта покупки дополнительных физических серверов, их встраивания в старую инфраструктуру и настройки распределения нагрузки на новые блоки.
Опыт 3. Фронтенд- и бэкенд-сервера + балансировщик
О том, что сайт живёт на сервере, кажется, известно уже практически всем. Но вот о том, что бывают фронтенд- и бэкенд-сервера, даже сейчас задумываются очень немногие. Когда пользователь заходит на ваш сервис, в его браузер или WebView необходимо передать HTML-документ с интерфейсом вашего сервиса. Обычно за формирование и отправку HTML как раз отвечает фронтенд-сервер. Чаще всего он представляет из себя Node.js-приложение, но в простейших случаях может содержать и статическую веб-страницу. Если сервис не требует серьёзной бизнес-логики, то весь спектр взаимодействия процессов внутри проекта допустимо поднять на этом же сервере. В противном случае выделяют отдельный бэкенд-сервер для обработки данных и их отправки на фронтенд — например, в формате JSON.
Передача данных между клиентом, фронтенд- и бэкенд-серверами может регулироваться за счёт балансировщиков нагрузки. Балансировщики несложно запустить на программном уровне — достаточно взять за основу HAProxy, nginx или другое ПО. Балансировщики вкупе с правильной инфраструктурой фронтенд- и бэкенд-серверов помогут защитить проект от внезапных возрастаний нагрузки, перегрузок серверов и «неответов».
Опыт 4. Работа с файлами через совместимое хранилище
На рынке существует несколько хорошо зарекомендовавших себя решений для размещения данных в облаке. Поэтому при выборе убедитесь, что хранилище поддерживает работу с наиболее распространёнными библиотеками, чтобы потом можно было безболезненно сменить одно хранилище на другое. Например, в Amazon Web Services реализовано хранилище под названием S3, которое совместимо с множеством API и SDK. Под него создана масса полезных программ и фреймворков. Их же можно использовать и при работе с Яндекс.Облаком, так как у него S3-совместимое объектное хранилище. Кроме того, оно обладает свойством отказоустойчивости и обеспечивает постоянный доступ к файлам по прямым ссылкам. На такие детали всегда стоит обращать внимание.
Опыт 5. Защита от сетевых атак и нештатных ситуаций
Сейчас история о том, что когда-то Яндекс начинался с сервера, который простая уборщица могла случайно выдернуть из розетки, кажется историческим анекдотом. Однако в случае с нештатными ситуациями или DDoS-атаками небольшого выделенного сервера может быть недостаточно — и такая ситуация очень близка к истории про сервер, незащищенный от уборщицы. Такой одинокий сервер гораздо проще «уронить» или «отключить» от хостинга, чем полноценную облачную инфраструктуру, способную выдерживать гораздо более масштабную нагрузку. Облако умеет отсекать «роботные» запросы и проводить учения по нештатным отключениям.
Отказоустойчивость хранилища ещё не гарантирует защиту от сбоев для всего сервиса. Чтобы обезопасить все компоненты, можно дополнительно:
• Продублировать каждую из перечисленных машин в несколько дата-центров (зон доступности).
• Настроить репликацию облачной БД между двумя или тремя зонами доступности.
Мы постарались переложить наш опыт не только в теоретическое описание в этом тексте, но и в инструментарий Облака. Оно содержит все перечисленные сервисы: виртуальные машины для хостинга серверов, объектное хранилище и сервис контроля за СУБД.
Верим, что наш опыт поможет вам ещё быстрее развивать ваши проекты!
С вами в Облаке
P.S. Подписывайтесь на наши каналы
Блог Яндекса для Вебмастеров
Канал Яндекса о продвижении сайтов на YouTube
Канал для владельцев сайтов в Яндекс.Дзене
Ещё новости по теме:
18:20