Интервью: проблемы географически распределенной инфраструктуры и как их решить

Один из трендов современного мира — глобализация. Сегодня можно встретить всё больше компаний, которые работают одновременно с пользователями из нескольких стран. О том, какие проблемы в области распределения трафика могут у них возникать и как их решать, сегодня говорим с Дмитрием Плотниковым, экспертом по автоматизации бизнес-процессов (Microsoft MVP).

Почему вообще возникает проблема с географическим распределением трафика и данных, разве облака не решают ее полностью?

Облака — модная вещь, которая позволяет компаниям не задумываться о том, как на низком уровне работают нужные им инструменты. Разработчики сервисов для бизнеса стараются решить для пользователей проблемы с распределением трафика, дата-центрами, синхронизацией данных, поддержкой серверов и т. п. Это замечательно, но иногда бывает так, что подобные решения даже при всей своей универсальности не подходят, и бизнесу приходится работать с возникающими сложностями самостоятельно.

Например, однажды мне удалось поучаствовать в проекте, в ходе которого нужно было создать систему географического распределения трафика для интернациональной компании с офисами в нескольких регионах — от Австралии до Канады. Компания в своем нынешнем виде появилась в результате цепочки слияний и поглощений, поэтому изначально такие возможности не закладывались в корпоративную инфраструктуру: компания, с которой всё началось, базировалась в Канаде и ядро ее систем всегда располагалось там.

В результате могли возникать ситуации с неодинаковой доступностью сервисов для пользователей из разных регионов — например, нередко один из них отказывал исключительно у жителей Австралии.

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

Они есть, но везде свои нюансы. К примеру, тот же SharePoint не предназначен для использования в географически распределенной инфраструктуре. Для собственных продуктов Microsoft реализует распределение трафика на региональной основе. К примеру, пользователи Office 365 из Европы и США попадают на разные серверы, в дальнейшем данные синхронизируются между разными серверами, чтобы обеспечить их доступность.

То есть, если нужен офисный пакет, можно взять и готовое решение. Если же компании нужен распределенный SharePoint, или база данных, или распределенная интеграция со сторонней системой, то здесь всё далеко не так просто, готовыми решениями тут не обойтись.

Что за распределенные интеграции, как это может выглядеть?

Ну, например, может появляться необходимость интегрировать какой-то программный продукт с биллингом от стороннего поставщика. В таком случае важно, чтобы у этого вендора была реализована возможность распределения нагрузки. Иначе могут возникать неприятные ситуации, когда, допустим, вы для своей инфраструктуры распределение реализовали — и клиентам в Канаде и Австралии сервис доступен одинаково быстро и качественно, а вендор биллинга этого не сделал. Если у этой компании серверы только в Канаде, то финансовые транзакции пользователей из Австралии будут обрабатываться только на другом конце мира, что может ухудшать user experience всей системы.

В результате могут возникать и проблемы вроде тех, с которыми недавно столкнулась компания «1С-Битрикс». Тогда сервис «Битрикс24» оказался недоступен для 30% пользователей из-за проблем на стороне хостинг-провайдера российской части инфраструктуры. По причине ошибки конфигурирования сети сломался коммутатор, в результате чего отключились сразу два дата-центра компании: резервирование ЦОД здесь не помогло, поскольку по цепочке дальше оставалось слабое звено.

И что делать в таких ситуациях?

Всегда должен быть запасной план. По всей видимости, в случае с «Битрикс24» он сработал не до конца, поэтому сбой коснулся части пользователей, но зато эта часть вообще не смогла пользоваться сервисом. Сейчас, как я понимаю, компания от своего провайдера «переезжает» на продукты вроде Amazon AWS.

Такие сервисы нельзя назвать абсолютной панацеей: иногда и у Amazon бывают сбои. Но уровень надежности там вполне приличный. Поэтому, если вам необходимо создавать распределенную систему, лучше в качестве строительных блоков для нее использовать такие максимально надежные элементы. С ними еще и проще работать: в AWS при создании очередного сервиса нужно лишь указать, что он должен быть геораспределенным, и всё.

Есть ли какие-то базовые правила или рекомендации по созданию распределенных систем?

Самый главный совет: думать о подобных вещах нужно с самого начала. Даже если в текущей инфраструктуре потребности в распределенности как таковой нет, это не значит, что она не понадобится в будущем.

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