От автора
Данная статья ориентирована на широкий круг читателей и не описывает реализацию архитектуры с технической точки зрения (хотя это довольно интересная и обширная тема), поэтому, возможно, не оправдает надежд профессионалов в области информационных технологий, жаждущих технических подробностей и захватывающего чтива, изобилующего описанием новейших технологий, применяемых при проектировании высоконагруженных систем.
Во время проектирования архитектуры ПС Wooppay мы столкнулись с классической проблемой выбора между безопасностью и масштабируемостью.
С одной стороны, сервис с динамическим ростом нагрузки и требованием высокой доступности, с другой жесткие меры информационной безопасности. Проблему масштабируемости можно решить путем использования IaaS (проще говоря, облака), но размещать где-то, в каком-то облачном датацентре финансовую и конфиденциальную информацию деятельности ПС не хотелось (не по фэншую это как-то). Тогда, мы просто напросто возьмем и купим 6 серверов, 2 коммутатора и 2 маршрутизатора, засунем их в стойки в 2-х датацентрах и получим «офигительную» отказоустойчивую архитектуру — одним словом, как два пальца об асфальт.
Но, ПС Wooppay — классический пример высоконагруженной системы и поэтому, как любая система такого класса, в конце концов, исчерпает свободные ресурсы выделенных аппаратных средств. Понятно, что можно наращивать мощности вставляя планки памяти, диски, процессоры (вертикальное масштабирование) или купить и воткнуть в балансировщик новый сервер (горизонтальное масштабирование), но процесс покупки данных «обновлений» затягивается, затем идет доставка, установка, тестирование. Снижение производительности сервиса недопустимо даже в пиковые дни/часы нагрузки. Теперь немного логических рассуждений: мы видим, что нагрузка на сервис не больше 70%, но в конце декабря она уже составляет 120% (появляются длинные очереди, отказ в обслуживании и прочие прелести недостаточной производительности), мы быстро установили сервер и распределили нагрузку, тем самым справились в пик, но затем все возвращается к первоначальному состоянию: нагрузка уже ниже 40% и половина ресурсов простаивают, а это лишние расходы на колокейшн, электроэнергию, сопровождение. В нашем случае данный способ построения технической архитектуры неудобен — это раз; нерентабелен — это два.
А почему бы не рассмотреть вариант размещения веб и транзакционных серверов сервиса в «облаке», а серверов БД в ЦОДах (центр обработки данных)? Это позволит нам оперировать необходимыми вычислительными мощностями и «потреблять» ровно столько, сколько нужно. Еще одним плюсом является уменьшение парка обслуживаемой техники, повышение утилизации ресурсов в мировом масштабе (привет Гринпису =). Лишний сервер потребляет электроэнергию, а следовательно выделяет тепло, его необходимо охлаждать и т. п., а в ЦОД поставщика облачных сервисов ведутся постоянные работы по снижению тепловыделения, оптимизации охлаждения и т.п.). БД в ЦОД и на физическом сервере несомненно будет демонстрировать большую производительность, а собственные аппаратные фаерволы и маршрутизаторы CISCO позволяют достаточно хорошо защитить периметр изнутри.
Мы рассмотрели этот вариант и пришли к выводу, что для стартап проекта с динамической и труднопрогнозируемой нагрузкой и повышенным требованиям к информационной безопасности это будет наилучшим решением.
Важным фактором работоспособности платежной системы является система мониторинга: именно она помогает определить в какой момент времени необходимо запустить либо остановить дополнительный экземпляр сервера. Все необходимые инструменты мониторинга и масштабирования предлагаются поставщиком IaaS в виде сервисов и API.
ПС Wooppay постоянно совершенствуемая система, практически каждую неделю добавляются новые пользовательские функции, оптимизируются скрипты автомасштабирования, совершенствуются методы защиты информации. Для этих целей была «развернута» идентичная «тестовая» инфраструктура, позволяющая проводить полное функциональное тестирование всех нововведений. Для уменьшения времени загрузки контента и снижения нагрузки на основной канал связи, вся медиа информация была размещена на физическом сервере в датацентре на территории РК. Не буду перечислять все применяемые для повышения производительности технологии, дабы не утомлять уважаемого читателя кучей скучных терминов, лишь отмечу, что, конечно же, мы применяем интеллектуальные (насколько это возможно для программы) балансировщики, кэширование и т.п.
В конце концов, после долгой кропотливой работы, мы пришли к тому, что нам удалось построить достойный экземпляр высоконагруженной отказоустойчивой системы, способный незамедлительно реагировать на изменения функциональной среды и адаптироваться к ним, при этом экономя солидную сумму условных единиц на радость нашему финансовому директору и инвесторам.
Что же мы имеем в итоге:
- N (динамическое число) активных веб-серверов, работающих через балансировщик нагрузки;
- N активных серверов обработки транзакций, работающих через балансировщик нагрузки;
- N серверов для хранения сессий, неперсонифицированной и не финансовой информации;
- отказоустойчивый кластер БД с полным дублированием аппаратной части;
- VPN туннели из облака к ЦОДам через разных провайдеров доступа к интернет.
P.S. Как Вы уже заметили в данной статье никак не упоминаются меры и инструменты информационной безопасности, применяемые в облаке и в системе в целом. Полностью тема информационной безопасности будет раскрыта в другой статье.
Руководитель отдела технической инфраструктуры Александр Бондаренко.