Практически любой бизнес сталкивается с плавающей нагрузкой: то тишина, то шквал. За примерами далеко ходить не надо:

• посещаемость интернет-магазина может значительно колебаться в зависимости от времени суток или сезона;
• внутренние сервисы компаний могут «пустовать» неделями, а накануне сдачи квартального отчета их посещаемость резко подскочит.

Photo by Victor Rodriguez on Unsplash

Часто мы получаем от клиентов (включая даже крупных) сообщения, в которых сквозит общий мотив: «У %provider_name% нам не хватало 192 ядер, а у вас и 120 достаточно. Почему так?». Причем в последнее время из-за пандемии таких запросов стало больше. То ли потому что клиенты вышли в онлайн и почувствовали нехватку ресурсов из-за ажиотажного спроса и у других клиентов тоже, то ли потому что некоторые провайдеры из-за все того же высокого спроса на услуги стали плотнее «упаковывать» в облаке заказчиков.

Вот эта переподписка, которая обострилась, судя по всему, из-за Covid-19, сейчас волнует очень многих облачных пользователей. Поэтому мы постараемся ответить на наиболее распространенные вопросы и рассказать про инструмент, который позволит проверить наличие переподписки у вашего провайдера.

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

Для Hadoop и Greenplum есть возможность получить готовый SaaS. И если Хадуп — известная штука, то Greenplum (он лежит в основе продукта АrenadataDB, про который далее пойдёт речь) — интересная, но уже менее «на слуху».

Arenadata DB — это распределённая СУБД на базе опенсорсного Greenplum. Как и у других решений MPP (параллельной обработки данных), для массивно-параллельных систем архитектура облака далека от оптимальной. Это может снижать производительность аж до 30 % (обычно меньше). Но, тем не менее, эту проблему можно нивелировать (о чём речь пойдёт ниже). Кроме того, стоит покупать такую услугу из облака, часто это удобно и выгодно в сравнении с развёртыванием собственного кластера.

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

Если у вас есть хранилище данных больше 1 ТБ и транзакционные системы — не ваш профиль по нагрузке, то ниже — рассказ, что можно сделать как вариант. Почему 1 ТБ? Начиная с этого объёма использование MPP эффективнее по соотношению производительность/стоимость, если сравнивать с классическими СУБД.

В большой компании часто очень тяжело согласовывать выделение ресурсов под рабочие задачи. Весь Agile с хрустом разбивается о стену трёхнедельного согласования с ИБ новой инфраструктуры. Поэтому к нам часто приходят запросы на перевод инфраструктуры на контейнеры, чтобы выкатывать изменения не раз в три месяца, а когда нужно бизнесу. Просят при этом настроить/внедрить Kubernetes как самый популярный инструмент оркестрации, хотя, как показывает практика, из 10 проектов он нужен максимум в трёх. А по факту стоит или использовать не Kubernetes, а OpenShift, или работать с ним не в своей инфраструктуре, а в публичном облаке, например. Я попробую рассказать про реальные бизнес-кейсы, которые мы решали, опишу основные различия между Kubernetes и OpenShift. А ещё о том, как мы согласование ИБ до 30 минут урезали, и все остались живы.

У нас было несколько интересных внедрений, в которых мы разгребали накопившиеся проблемы заказчика. Например, к нам пришла розничная компания, которой надо было выкатывать новые фишки непрерывно. Конкуренция дикая! А у них только инфраструктура под разработку каждый раз готовится от шести до десяти дней, из-за чего возникают простои. Решать вопрос с помощью закупки нового железа для тестирования и разработки — дорого и путь в никуда. В итоге мы перевели ИТ-инфраструктуру на контейнерную виртуализацию. В результате благодаря контейнерам нагрузка сократилась на 40 %, а инфраструктура под новую разработку теперь готовится от одного до четырёх часов. Бонус — экономия, так как все процессы можно было продолжать вести на базе имеющихся мощностей без покупки новых.

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

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

Только универсально, чтобы можно было настраивать на любой интерфейс и делать это мог бы любой человек, даже далёкий от программирования.



Вот так они это сделали.

Коллеги из Европы попросили включить эти статьи в договор на предоставление облачных услуг.

Когда вступил в силу закон о хранении персональных данных в России, к нам в облако начали массово стучать иностранные заказчики, у которых было здесь локальное подразделение. Это крупные компании, и им был нужен оператор услуг в нашей стране.

Тогда у меня был не лучший бизнес-английский, но было ощущение, что на английском изъясняться из технических специалистов по облакам не умеет вообще никто. Потому что наше положение большой известной компании плюс мой вот этот базовый английский в ответах на вопросы были явно на голову лучше других предложений на рынке. Это потом уже появилась конкуренция между российскими облачными провайдерами, но в 2014-м выбора просто не было. 10 из 10 обращавшихся заказчиков выбирали нас.

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

У нас тут масса историй, начиная с того, как мы переманили MS-разработчика в Питон, и заканчивая тем, как разработка поставила тикет найти бутсы для президента Федерации футбола Уганды. Но я бы хотел рассказать не только их, а, скорее, то, на что похожа работа внутри большой компании.

9 лет назад мы начали развивать облачное направление. Потом выделились в такой автономный чукотский округ, что-то вроде компании в компании.

У нас свои кабинеты на этаже инженеров, свои выделенные маркетологи, свои команды разработки и поддержки, частично своя бухгалтерия. Мы пользуемся всеми благами компании (можем даже иногда поманить печеньками к себе в направление инженеров из других отделов), но при этом работаем почти отдельно.

Хочу рассказать, на что это похоже. Потому что, с одной стороны, у нас есть доступ к ресурсам, которых никогда не будет у отдельной компании, а с другой — есть и ограничения.

«Все отделы от серваков отказались, а на Авито их никто не купил — шеф сказал, это теперь тестовая среда».

Компания на 20 разработчиков жила с плотно упакованной серверной стойкой. В стойке (по сегодняшним меркам) стоит уже старый отстой, который не тянет. Когда-то он был новым и красивым, но время безжалостно. Подключились к облаку, затащили туда сначала тестовые среды, потом продакшн. А стойка пригодилась ещё для пары мелких задач по офису и тестов. Мы хорошо видим, как у них погибают старые сервера в ней: по мере отказов они заводят новые виртуальные машины в облаке.


Эта штука умеет пробрасывать аппаратные ключи 1С в разные подсети

Исторически к нам заходил ритейл, потом интернет-проекты, затем подтянулись и банки. Теперь же активно переезжают и вполне обычные компании, которые готовы вынести в облако бизнес-критичные задачи. Ниже — несколько типовых историй, которые, возможно, будут вам полезны, даже если вы ещё не планируете никаких облаков. Хотя деваться уже особо-то и некуда — это обыденность, а не новая непонятная фича.

В какой-то момент российские организации остро ощутили, что отправлять файлы через иностранные сервера — не самая хорошая идея. Дальше три варианта: либо решать административно и «бить ногами» тех, кто отправляет не на флешке фельдъегерской почтой, либо делать глобальное хранилище данных (например, на базе ECM Documentum, OpenText или Alfresco), либо же сразу разворачивать облачный аналог Дропбокса у себя на серверах в РФ.

Первые два пути работают, но самый простой и эффективный — третий. Поэтому нам пришлось сделать свой сервис обмена файлами для крупного бизнеса. Из приятных примочек — аутентификация через LDAP, шифрование, саморазрушающиеся ссылки и прочие прелести паранойи. Самое смешное — получилось вполне сопоставимо по конечным ценам с бизнес-лицензией на Дропбокс. Да, мы делаем дешевле Dropbox Business для средних и больших компаний.