Сайт и мобильные приложения мультимедийного проекта Condé Nast Traveller запущены на веб-кластере 1С-Битрикс в Amazon

    Добрый день, коллеги!

    Condé Nast Digital Russia запустил мультимедийный проект для путешественников Condé Nast Traveller, который объединяет печатное издание, его цифровую версию, интернет-сайт и мобильное приложение. Проект стартовал 21 сентября 2011 года. В качестве веб-основы был выбран продукт компании 1С-Битрикс на веб-кластерной платформе, в качестве хостинг площадки, на основании наших рекомендаций — облако Amazon.

    Веб-сайт www.cntraveller.ru содержит статьи о путешествиях и, главное, дает возможность оперативно найти информацию об отелях, ресторанах, местах для развлечений в разных странах мира, добавить на сайт собственные объекты, фотографии и отзывы, составить путеводитель для будущего путешествия. Все данные об объектах используются и приложением для iPhone «Condé Nast Traveller – Мои адреса», с помощью которого можно не только составить маршрут путешествия, но и, определив свое местоположение на карте, увидеть ближайшие адреса, рекомендованные редакцией журнала и посетителями сайта.

    В целом, проект уникальный, большой и интересный – всего не расскажешь в одном абзаце – посмотрите сами, если интересно. А наша цель – заглянуть «под капот» проекта.
    Итак, критически оценим архитектуру и надежность решения. Взвесим плюсы и минусы облачного хостинга и использованных технологий кластеризации Битрикс.





    Архитектура высоконагруженного решения «на коробке»



    Статика вынесена в облако и раздается из CDN (CloudFront) с использованием функционала модуля «Облачные хранилища». Конечно, можно организовать работу с файлами с использованием FUSE-модуля, например, s3fs, однако внутренние «информационные деревья» проще выносить в облака используя встроенные инструменты платформы.

    Используется типовая MySQL master-slave репликация, однако балансирование нагрузки выполняет ядро платформы Битрикс — благодаря чему не нужно вносить изменения в существующее приложение, которому все равно — одна база данных или мастер + 20 слейвов.

    Видим кластеризованный кэш на базе memcached, встроенный в кластерную платформу Битрикс — который будет работать при выходе из строя любого своего узла, а также автоматически вытесняет «устаревшие» данные. Это особенно актуально для крупных, высоконагруженных проектов, в которых создается (иногда из-за ошибок) большой объем и число файлов кэша — если хранить такой кэш в файловой системе, то нужно постоянно мониторить его размер и периодически очищать устаревшие данные.

    Поисковый индекс, интенсивно используемый посетителями и внешними приложениями проекта, обращающихся к системе с помощью веб-сервисов, методом «вертикального шардинга», через мастер в админке — вынесен на отдельный сервер. При возрастании интенсивности использования поисковых сервисов — можно в течении пары минут (через API Amazon) перегрузить машину на более «мощном» железе.

    При возрастании нагрузки «Сервер 2» может подключиться автоматически и использоваться как сервер приложений.

    Надежность



    Бэкапы машин проекта делаются снепшотами EBS-дисков в S3. В случае попадания в датацентр (Availability Zone) самолета или баллистической ракеты — машины c дисками можно за считанные минуты поднять в другом датацентре (Availability Zone). Снепшоты хранятся в виде инкрементов с авто-консолидацией, поэтому их можно делать хоть раз в 10 минут. Для бэкапа БД путем снепшота EBS-диска она кратковременно лочится ("FLUSH TABLES WITH READ LOCK") и ее файловая система кратковременно замораживается (fsfreeze).

    Для быстрого восстановления доступа к самым актуальным данным в БД (если, допустим, рассыпалась файловая система на мастере БД) — слейв БД легко переключается в режим мастера и используется проектом. При желании можно автоматизировать этот процесс. Еще лучше — делать репиликацию в другой датацентр Amazon (Availability Zone) и тогда при «ударе молнии» в текущий датацентр можно будет в считанные минуты: а) поднять машины из снепшотов в другом датацентре, б) поменять аппаратную конфигирурацию слейв-БД (через АПИ Amazon) и перегрузить его, в) переключить DNS на использование другого балансировщика либо, при использовании встроенного в Amazon балансировщика — перенаправление трафика в другой датацентр произойдет автоматически либо потребует минимальной конфигурации ELB (для полной автоматики нужно настроить группу автомасштабирования AWS AutoScaling).

    Куда расти



    При возрастании объема чтений на БД можно, не прерывая работу проекта, добавлять серверы-слевы БД. Для обработки возросшего объема записей на мастере — можно увеличить мощность «железа» (через вызов API Amazon) «Сервера 1», либо вынести master БД на отдельный сервер.

    При увеличении нагрузки на сервер приложений PHP («Сервер 1») — можно добавить один или несколько серверов приложений (не переписывая код проекта), синхронизировав их файлы посредством, например, csync2 (в Amazon нельзя примонтировать один EBS-диск к нескольким серверам для организации кластерной ФС типа ocfs2). Разумеется, тогда серверы приложений должны быть «спрятаны» за балансировщиком нагрузки. В данном случае может идеально подойти встроенный отказоустойчивый и масштабируемый балансировщик Amazon ELB или маломощная машинка с nginx. Разумно вынести отработку SSL на балансировщик (Амазон это умеет делать) — чтобы не размазывать сертификаты по серверам приложений.

    P.S.



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

    А чтобы читать следующие записи в своей ленте, нажмите «Мне нравится» в профиле компании, и проверьте свою настройку ленты.
    • +44
    • 4,2k
    • 8

    1С-Битрикс

    73,00

    Компания

    Поделиться публикацией
    Комментарии 8
      +7
      Скорее буду заминусован, но, хорошо рассказали, много интересного, зашел на сайт, открыл код, увидел кучу js и css файлов, про автоматическую склейку файлов в один забыли?
        0
        Ну тогда и про спрайты тоже нужно не забывать, да ещё и html чистить от форматирования :)
        Не всё сразу. У этих техник есть свои плюсы и минусы.
        +4
        Хорошая статья.
        Интересно, а во сколько вылился это проект (количестве нулей в цене) если не секрет?
        Хороший подход про вынос поиска на отдельную БД на сервере. А можете немного рассказать про структуру БД для поиска, на основе какого подходя она реализована (хеши популярных запросов или что-то свое)?
          +3
          В Битрикс используется своя, достаточно сложная но эффективная реализация для построения поискового индекса, максимально подходящая как с точки зрения производительности, безопасности, так и морфологии для обслуживания запросов веб-проекта. Именно поэтому мы не используем для индексации внешние решения, и внутренние типа solr (lucene), shpinx.
            0
            Ясно, спасибо.
          0
          А какова нагрузка на этот проект? Просто интересно, на сайте «1562 ПОЛЬЗОВАТЕЛЕЙ» и судя по метрике всего 12к просмотров. Для этого и правда нужен амазон, облака, кластера, балансировшик и т.п.?
            0
            При такой посещаемости вряд ли, это, скорее всего сделано на перспективу роста…
            0
            Очень вкусно все описали, руки чешутся попробовать :) Ждем подходящего проекта. Еще очень мне нравится в амазоне возможность отслеживать нагрузку и автоматически запускать сервера в кластере и гасить их при снижении нагрузки. Ну, я думаю Александр как-нибудь сам расскажет.

            Реально, облачный хостинг амзона настолько крут и настраиваем, что все остальные варианты, похоже, будут потихоньку отмирать. Пока у облаков вроде цена повыше (а, кстати, каков порядок стоимости описанного облака?), но с распространением технологии будет падать.

            Еще мне показалось, что амазон проще администрировать по сравнению с выделенным сервером — это как конструктор из кубиков. Александр, как вы считаете?

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое