amoCRM: как мы организовали хранение и прыткое скачивание файлов из облака MCS | SEO кейсы: социалки, реклама, инструкция

24 июня 2019, 14:00

Новости

10/11/2024 Как купить игру в Steam с использованием Mastercard

10/11/2024 Способы пополнения кошелька Steam в России

31/10/2024 Документы для ипотеки на вторичное жилье с материнским капиталом

«Облака излишними не посещают, когда файлов много и клиенты желают, чтоб они были непрерывно доступны». Так решили в онлайн-сервисе amoCRM и сделали платформу Mail.ru Cloud Solutions (MCS) главной пасмурной площадкой для хранения файлов, уменьшили время доступа к ним и адаптировали работу под требования русского законодательства (152-ФЗ) . О переезде в скопление и выгоде, которую получили клиенты сервиса, ведает Никита Бессуднов, SRE-инженер amoCRM.

Что дает amoCRM? Эта система подсобляет выстроить прозрачные, действенные дела с клиентами и повысить эффективность отдела продаж. Она автоматом фиксирует заявки и запросы клиентов по всем каналам, поэтому клиенты не теряются, а коммуникации непрерывно под рукою.

Предыстория

Сначала пути мы работали с bare metal, но позднее избавились от физических серверов. Нам нравилось, что мы могли влиять на железо не зависели от виртуализации, но не устраивало, что у данной инфраструктуры не было ни гибкости, ни мобильности.

С тучами мы недалеко знакомы заключительные 6 лет. Ранее мы подсчитали: файлы на дисках обойдутся нам дороже, чем скопление. Ранее нашим пасмурным провайдером была компания Amazon, на мощностях которой мы берегли все файлы, которые загружают наши клиенты в систему. Параллельно мы работали с южноамериканским провайдером Rackspace. У него мы берегли и продолжаем беречь файлы наших клиентов из США.

Для чего нам очередной пасмурный провайдер

В первый разов мы задумались о новеньком провайдере с серверами в РФ, когда начались блокировки Telegram’a. Тогда под раздачу попали IP-адреса Amazon’а. Клиенты жаловались на недоступность данных, и мы сообразили, что необходимо оперативно решать эту делему. Amazon был не главной, а резервной площадкой, но ситуация оказалась чрезвычайно досадной и для нас, и для наших клиентов. Они не могли загрузить либо, напротив, скачать файлы со собственных аккаунтов. По временной ссылке, которую мы генерировали умышленно для Amazon, они не получали то, что им необходимо. Это 1-ая и главная причина, по которой мы начали мыслить о другом пасмурном провайдере.

2-ая причина – необходимость хранения данных на местности Русской Федерации. 152-ФЗ прикладывает определенные ограничения, и мы принуждены исполнять его требования. Соответственно, нужен был провайдер с серверами конкретно в РФ.

Третьей предпосылкой стали трудности с хранением статических файлов. Когда у Amazon’а возникли трудности с доступом, интерфейс amoCRM начал некорректно работать на клиентской стороне. К примеру, слетали шрифты не подтягивались изображения, которые тоже хранились в амазоновском облаке.

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

Как мы избирали наше третье облако

Мы учли все, что нам не нравилось в сложившейся ситуации, и выделили три приоритетных аспекта для выбора еще 1-го пасмурного провайдера.

1-ое: цена. Конечно, нам хотелось адекватной стоимости пасмурных услуг. Была главна не столько скорость загрузки файлов, сколько их неизменная доступность за ту стоимость, которая нас устроит.

2-ое: возможность прыткого переезда. У нас скопился достаточно великий размер файлов – 20 терабайт. Нам было главно перевезти их в новое скопление как можнож прытче, чтоб наши клиенты это не ощутили.

Третье: высочайшая доступность и нахождение на местности РФ. В идеале сервис обязан быть доступен 100 % медли, но это мистические характеристики. Amazon гарантировал нам доступность 99,8 %. Это много и превосходно, но трудности нагнали нас с местности РФ – начались блокировки. Плюс хранилища Amazon’а, которыми мы воспользовались, находились в Амстердаме, а этот вариант не подходил под требования закона «О индивидуальных данных».

Какие кандидатуры мы рассматривали

Сначала мы глядели в сторону облака нашего провайдера. Но нас предупредили, что оно находилось в тот момент в стадии тестирования. По различным причинам не подошло решение от Яндекса. В тот момент его скопление лишь запускалось, также находилось в стадии beta и сначала несло в себе пасмурные вычисления, нам же необходимо было скопление для файлов. И на 3-ем провайдере мы остановились конечно – это было скопление Mail.ru Cloud Solutions. Оно подошло под наши требования, плюс из документации мы узнали, что это хранилище совместимо с протоколом S3, который употребляется в Amazon. Означает, нас ожидал (в теории) более-менее безболезненный переезд.

Как мы перевезли 20 ТБ в скопление MCS…

Кейс вышел занимательным, поэтому расскажу о нем подробнее. Как я разговаривал, нам предстояло перевезти 20 терабайт. Наш обыденный интернет-канал не давал способности живо передавать такие объемы, поэтому мы договорились с провайдером о том, чтоб временно его расширить.

Далее был очередной занимательный момент. Вначале шла речь о том, чтоб передавать файлы из Амстердама в Москву, а позже обращать их на площадку MCS, которая находится где-то в центральной доли РФ. Но этот вариант нам не приглянулся – очень длинно и затратно по ресурсам. Поэтому мы отправь иным методом: брали промежный сервер нашего провайдера (нам подфартило, у него часть оборудования находилась как разов в Амстердаме) , который по выделенному внутреннему каналу сначала закачивал файлы из Amazon’а, передавал их на собственный сервер в Москву, а теснее оттуда – в скопление MCS.

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

А сейчас представьте: мы переехали за 6–7 дней (числа плавающие, потому что мы пару разов временно останавливали передачу данных) и сравнимо маленькие средства. Один рабочий день ушел на проверку целостности файлов – к счастью, колоченных посреди их не оказалось. Ежели бы мы перевозили данные на физических носителях, нам бы пригодилось 45 SSD-накопителей ценою 25 000–30 000 каждый, либо суммарно около 2 млн рублей!Выходит, мы превосходно сэкономили?

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

…И что из этого получилось

На данный момент у нас три пасмурных площадки для хранения клиентских файлов amoCRM и главная – это как разов Mail.ru Cloud Solutions. Нам нравится, что у нее высочайшая доступность, а данные хранятся на местности РФ, соответственно, мы не нарушаем закон. Площадка Amazon’а осталась резервной, а в Rackspace мы по-прежнему бережём файлы южноамериканских клиентов.

Опосля переезда в MCS клиенты стали прытче получать свои файлы. Ежели ранее для их скачивания приходилось обращаться к серверу в Амстердаме, то на данный момент хранилище размещено поближе, и время передачи данных сократилось.

Ежели перевести профит в числа, то получится, что мы убыстрили работу с файлами в 2–2,5 раза – это разница в скорости, с которой отдают файлы облака MCS и Amazon. Вспоминаем блокировки Telegram’a и связанные с ими трудности доступа к Amazon’у. Сейчас неувязка исчерпала себя, и нашим клиентам не приходится устраивать танцы с бубном и закачивать свои же файлы VPN лишь поэтому, что мы берегли их не в Рф.

Очередной приятный бонус – экономия. Мы не попросту получили подобное по стоимости решение, а сейчас расходуем на хранение и скачивание столько-же, сколько ранее уходило лишь на одно хранение в облаке Amazon.

Нам приятно, что удалось улучшить user experience при загрузке и скачивании файлов. Это превосходно приметно на большинстве файлов размерами 10–15 МБ. Ежели ранее для их загрузки требовалось от 1 до 5 секунд, то сейчас уходит не наиболее 0,5 секунды. На скачивание такового же размера ранее уходило до 15 секунд, на данный момент этот параметр не превосходит 1–2 секунды. Наиболее томные файлы весом до 1 ГБ – это быстрее исключение, и в их случае загрузка и скачивание продолжаются чуток длиннее.

Тучам быть!

Мы не новенькие в облаках, но поновой открыли для себя их превосходства опосля переезда на платформу MCS. Наш главной ценность – хранилище S3. Пасмурную инфраструктуру используем лишь для внутренних проектов. У нас пока нет настоящего сценария для ее внедрения в продакшене, но планы на будущее есть. Нам нравятся контейнеры: они эластичные, живо разворачиваются в облаке и сходу готовы к работе. На их мы экспериментировали с нейросетями для отработки событий в системе – обучались предвещать ответы на вопросцы в чате с юзерами. Пока это было разовое мероприятие, но есть возможность, что в дальнейшем мы опять вернемся к самообучающимся системам тогда и потребуются теснее настоящие пасмурные вычисления, в том числе на графических картах.

Онлайн-сервисам, одним из которых является наш продукт amoCRM, можнож начинать работать с облаком с самого начала – тогда, когда встает вопросец о хранении клиентских файлов. Применять для этого физические носители неловко и безвыгодно: они недешево стоят и их необходимо непрерывно докупать. То же самое для сервисов, которым необходимы вычисления – лучше переносить их в пасмурную инфраструктуру, которая дает больше мобильности. Мы в свое время пропустили пригодный момент для разворачивания инфраструктуры в облаке, что обернулось великими валютными и трудозатратами. Чтоб сделать это на данный момент, придется перепрограммировать систему и переработать под нее часть хранилищ, а это длинно и недешево.