Кейс: перенос локальной инфраструктуры клиента в облако AWS
Компания Cyber Finance LTD - это компания из Южной Африки, которая занимается юридическим и брокерским обслуживанием.
В связи с карантином 2020 руководство компании приняло решение перевести всех сотрудников компании на удаленную работу, закрыть офис за ненадобностью и перенести развернутую локально инфраструктуру в облако. Было выбрано облако AWS.
Так выглядела инфраструктура компании:
1) Террабайт данных на файловом сервере (Clear OS)
2) Внутренний портал для управления задачами и CRM система Битрикс24, 600Г пользовательских файлов, база данных на том же сервере, что и приложение, занимала около 25Г. К внутреннему порталу были подключены диски файлового сервера, была интегрирована офисная АТС (Астериск).
3) Сервер Астериск - офисная АТС.
Клиент обозначил, что мы можем ни в чем себе не отказывать в рамках 200$ в месяц. Уложиться в данный бюджет было сложно, потому что по нашим изначальным расчетам необходимо хотя бы 400$ в месяц, а лучше 500$ (датацентр в Кейптауне открыт недавно, и цены в нем намного выше, чем, в Вирджинии, для многих сервисов не доступны маленькие EC2 инстансы). В этом посте я расскажу подробно, как мне удалось решить задачи клиента и уложиться в бюджет, не в ущерб производительности системы.
Для начала необходимо было определить план переезда, потому что он должен был быть бесшовным - без простоя работы пользователей. К счастью, сотрудники в данной компании не работают на выходных, и в это время мы могли приостанавливать любые сервера.
Первым этапом в ночь с пятницы на понедельник мы провели предварительный тест: развернули предполагаемые ресурсы:
EC2 для Битрикс24;
EC2 для Астериска;
S3 для файлов папки upload Битрикс24;
RDS для БД Битрикс24;
Auto Scaling групп на 1 инстанс для автоматического восстановления сервера Битрикс24 в случае падения.
Далее мы перенесли все в тестовом режиме (не забирая все файлы, и взяв только срез по 3000 записей из каждой таблицы БД), чтобы понять, в каком порядке нужно действовать и сколько времени потенциально может занимать каждый этап. Той же ночью все входящие на старый Астериск транки были отключены, подключены на новый Астериск - чтобы убедиться, что провайдеры телефонии не блокируют ip-адрес нового Астериска, к понедельнику транки снова были подключены на старом Астериске.
Основная проблема, которая вскрылась в ходе тестового переезда, заключалась в том, что RDS с 5м Mysql в Кейптауне никак не вписывалась в бюджет (даже в минимальной конфигурации) из-за отсутствия в регионе возможности взять маленький инстанс. Были проработаны несколько вариантов:
использовать 8й Mysql;
разместить базу данных в другом регионе (оказалось запрещено законом);
разместить базу данных на MySql совместимой БД Aurora Serverless (такой вариант оказался недоступным для региона);
разместить базу данных на одном инстансе с приложением Битрикс24, взяв инстанс помощнее и EBS-оптимизированный;
Было перепробовано несколько вариантов RDS инстансов с MySQL 8, которые позволяли вписаться в бюджет: t3.small, t3.medium, t3.large, но ни один из них не давал требуемой производительности (получалось 11-18 попугаев) из-за низкого IOPS на маленьком 100G SSD. Даже замена диска на Provision 1000 IOPS 100Г не дала результата, а диск большего размера, который разгонялся бы до больших IOPS уже не вписывался в бюджет.
Поэтому было принято решение разместить базу данных на одном инстансе с приложением Битрикс24, взяв EBS-оптимизированный инстанс m5d.large, отказавшись при этом от Auto Scaling Group (отказавшись от автоматического восстановления сервера после возможного сбоя) и отказавшись от возможности увеличивать размер жесткого диска автоматически. Производительность же получилась даже выше требуемой (60-70 попугаев)
В понедельник, поняв, что в бюджет, в принципе, можно уложиться, мы включили синхронизацию файлов внутреннего портала Битрикс24 с S3 бакетом в облаке. Битрикс24 поддерживает хранение пользовательских файлов в S3 бакете, поэтому мы включили синхронизацию новых загружаемых файлов его средствами, а старые файлы синхронизировали через консоль ssh командой aws s3 sync. Для этого на старый сервер приложения был установлен aws cli. Средствами Битрикс файлы переносились в облако со скоростью 1G в час, из консоли получалось 4-5G в час. В последствии на таблице файлов b_file был выполнен запрос, помечающий флаг, что файлы должны тянуться из соответсвующего бакета.
В середине недели телефония старого Битрикс24 и все софтфоны были переключены на новый Астериск.
В следующую ночь с пятницы на понедельник, когда почти все файлы папки upload строго Битрикс24 уже были синхронизированы с S3 бакетом, мы закрыли доступ пользователям к старому Битрикс24, сняли бекап с базы данных и перенесли ее в облако, новый Битрикс24 был подключен к новому Астериску, общие диски для хранения файлов все еще подтягивались со старого файлового сервера, когда пользователи начали использовать Битрикс24, установленный в облаке AWS. Со старого сервера Битрикс24 еще продолжали загружаться файлы.
Последним этапом были синхронизированы нужные файлы с файлового сервера.
Далее были настроены автоматические снапшоты серверов с использованием AWS EC2 Lifecycle Manager, межрегиональная репликация файлового хранилища S3, настроены уведомления об использовании ежемесячного запланированного бюджета и о доступности/здоровье развернутых ресурсов.
Первоначально в попытке вписать в бюджет базу данных на RDS, планировалось распределить 200$ следующим образом (но 200$ слишком мало для подобной архитектуры): https://calculator.aws/#/estimate?id=2b7e505cf75079271bbec60bf1c0a6d1a4b21e27
В итоге пришлось перераспределить 200$ так, получив отличную производительность, но отказавшись от возможности автоматического восстановления и автоматического масштабирования:
https://calculator.aws/#/estimate?id=d80de3b1271a238c42cc2bd428511766f717f648
А вот такой вариант мы предложим тому клиенту, для которого великолепная производительность, высочайшая надежность, автоматическое масштабирование, автоматическое восстановление - все сразу и одновременно - важнее цены:
https://calculator.aws/#/estimate?id=891fde270ac1854a8ca0d229171fb52cb10b9f73
(первичная передача данных в AWS не включена в данные калькуляции)
Комментарии