Такая боль, такая боль, сервис на аутсорсе 1:0

Мы делаем самую лучшую в России и ближнем зарубежье систему обнаружения заимствований. В идеальном мире мы бы занимались только разработкой и развитием системы. Но, увы, Антиплагиат работает не в вакууме, и для того, чтобы нашим пользователям было удобно и комфортно использовать наши разработки, нам необходимо также развивать среду, окружающую наш сервис. Наш софт пока не работает без железа, пользователям нужно оказывать техническую поддержку, получать оплату от пользователей необходимо без нарушения законодательства и т.д. Словом, рутины хватает.

Эта статья – первая из серии производственных драм историй о том, как мы делали наш сервис лучше при помощи аутсорса. Делимся реальными проблемами и выводами.

Облака, белогривые лошадки...

^{(откуда-то из интернета, впервые увидел тут.)}

Нагрузка на нашу систему сильно неравномерна: во-первых, в течение суток нагрузка меняется в 5 раз. Во-вторых, есть и ярко выраженная сезонность. Суточный максимум проверок после окончания летней сессии уменьшается в 10 раз! Зимняя сессия не столь яркая, но тоже не подарок. Плюс каждая последующая летняя сессия тяжелее (по числу проверок) и сложнее (новые технологии поиска и функциональность) предыдущей. Поэтому, с одной стороны, хочется иметь хороший запас по ресурсам, с другой – не платить лишнего во время спада активности. В сессию можно развернуть побольше серверов, а летом сократить объем потребляемых ресурсов. Очевидно, что это как раз случай облачных провайдеров. В этой статье я расскажу о различных аспектах взаимодействия с несколькими облачными провайдерами (AWS, ИТ-Град, MCS, YC). Если кому-то покажется, что это крик души, он не сильно ошибется. Итак, поехали!

AWS

Мы начали использовать облачные ресурсы в феврале 2013 года, когда арендовали наш первый сервер в AWS. Фактически, Amazon – это первый и самый продолжительный опыт Антиплагиата с «облаками». Тогда мы начинали с одной машины, а сейчас наш бюджет в AWS на порядок выше, чем бюджет на все российские облака. Первая любовь, как известно, не забывается никогда. Все проблемы и возможности с другими облаками в этой статье я рассматривал с учетом опыта использования AWS.

Правда, своя ложка дегтя в отношениях с Amazon тоже была. Ниже перечислены особенности или неудобства, которые возникали у нас с Амазоном:

1. Через браузер нельзя получить доступ консоли виртуальной машины. А иногда это прямо вот очень нужно! Однажды мы по ошибке удалили сетевой интерфейс, и пропал доступ на одной из машин. Повезло, что кто-то уже сталкивался с такой проблемой, за полчаса мы нашли и успешно применили решение. Через консоль такую операцию можно было бы проделать за минуту.
2. Расходы в долларах, а зарабатываем мы в рублях. Соответственно, рентабельность зависит от курса доллара.
3. Отсутствует дата центр в России, ближайший, когда мы начинали, был в Ирландии. Это значит большой пинг и некоторые ограничения в хранении данных, возникающие из-за требования российского законодательства.
4. Роскомнадзор регулярно блокирует адреса AWS. В настоящий момент с разных наших площадок разная доступность серверов в AWS. По непонятным причинам может отвалиться соединение до машины. Обычно помогают смена IP адреса, VPN и прокси.
5. Амазон существенно дороже, чем российские облака. Правда, можно уменьшать стоимость через гибкую программу резервирования и использование спотовых инстансов. И тем, и другим мы активно пользуемся. Увы, такого функционала в отечественных облаках мы пока что не встречали (upd: YC в новостной рассылке 18 февраля анонсировал «прерываемые ВМ», ждем подробностей).
6. Проблема с недостаточно информативными сообщениями. При переходе с 3-его поколения машин на 4-ое или 5-ое серьезно менялось виртуальное железо, в частности, способ подключения дисков, и машины просто не стартовали после смены типа. Интерфейс управления инстансами выдавал лаконичное сообщение: insufficient capacity. Лимитов на создание машин нужных типов хватало с запасом, и где-то полгода мы безуспешно пытали бесплатную техподдержку на счет изменения лимитов. Не помогло. В итоге нагуглили решение сами – помогает банальное пересоздание машин.
7. Пару раз мы стирали SSD до дыр: диски просто пропадали из системы вместе со всеми данными. С учетом того, что это были эфемерные диски, т.е. данные теряются при остановке машины, мы не хранили на них что-то невосполнимое.

В принципе, жить с указанными недостатками было можно. Однако именно в тот момент, когда Амазон наконец заметил российский рынок, наш счет стал не очень удобным для оплаты с карты. К счастью, Амазон быстро исправил ситуацию и выделил нам аккаунт-менеджера, который помог нам перейти с оплаты через карту на прямой договор и оплату по счету и оформить разного рода соглашения. Вообще он регулярно приезжает в Россию, и, когда заходит к нам, рассказывает о возможностях по оптимизации инфраструктуры и оплаты. Иногда он привозит с собой Solution Architect'a, с которым можно обсудить текущую архитектуру нашего решения, рассказать о «хотелках» и проблемах и получить несколько вариантов решения, причем не только через сервисы AWS. Сотрудники Амазона декларируют, что их цель не в том, чтобы впарить услуг побольше, а сделать так, чтобы купленные услуги приносили пользу бизнесу. Похоже, что это действительно правда. Количество сервисов, скорость их разработки и глубина взаимной интеграции впечатляют. В AWS есть все для организации как процесса разработки, так и эксплуатации высоконагруженных систем любого масштаба. Глобальная проблема пока что только одна – дорого!

ИТ-Град 2016

В 2015 году мы решили, что нам пора полностью отказаться от собственного железа. Хотелось возложить проблемы по надежности именно оборудования на других и больше сконцентрироваться на улучшении процессов собственной разработки. По нашим прогнозам, в 2016 году нам бы впритык хватило имеющегося у нас оборудования, и хотелось бы иметь запас на всякий пожарный случай. Мы подошли к выбору провайдера основательно: подготовили нагрузочный тест и анкету с важными для нас вопросами и придирчиво выбирали из пяти провайдеров: ActiveCloud, Cloud4Y, CloudOne, ИТ-Град, Softline.

В итоге остановили выбор на облаках ИТ-Град. Их преимущества:

1. Активная жизненная позиция, на наши вопросы ответы давались быстро, общаться было просто.
2. Наличие быстрых SSD дисков, до 30 IOPS на Гб. Количество операций случайного чтения – очень важный для нас показатель, поскольку высокие значения позволяют размещать в облаке наши модули проверки.
3. Платформа vCloud с возможностью управления машинами и наличием консоли к каждой машине.
4. Возможность увеличивать ресурсы виртуальной машины без ее перезагрузки.
5. Гибкий биллинг – оплата производится за ресурсы, которые были в использовании в день посередине отчетного периода (14-15 числа каждого месяца). Кроме того, есть вариант «Pay-As-You-Go», правда, он дороже и вычисление объема потребляемых ресурсов производится по средней загрузке CPU и RAM каждые 2 часа.

В 2016 году мы переехали на ИТ-Град. Вот что случилось за неполные три года нашей совместной жизни:

1. Как-то раз у нас появилась проблема. Ровно в 21:00 начиналась странная просадка по производительности. Число проверок, которое могла делать система, падало с 150 до 20-30 в минуту, при этом через пару часов все восстанавливалось и на скорости 600 проверок в минуту рассасывалось. Мы неделю искали проблему у себя, проверяли пользователей, ловили ботов и DDoS, но так ничего и не нашли. Обратились к саппорту ИТ-Града, выяснили, что «ой, а мы тут бекап делаем». В итоге разнесли нас с источником проблем на разные дисковые системы и наладили работу.
2. Обычно (особенности использования продукта), во время сессии наш трафик превышает 100 мегабит в секунду. Это значение, кстати, часто ставится по умолчанию для нерезервированного канала во многих облачных провайдерах. Когда впервые мы вышли за эту границу, возник целый ряд проблем: встроенный Edge не справлялся с VPN между точкой входа, расположенной на нашем оборудовании, и виртуальной машиной веб-сервера, расположенного в облаке. Как положено, обратились в саппорт, там нам предложили увеличить ресурсы на Edge. Ок, не вопрос, заменили ему конфигурацию со small на large, а также расширили канал до размера нашего пикового трафика с запасом. Не помогло. В общем, так и не смогли найти оптимальное решение, пришлось снижать объемы трафика выносом части продакшена на другие площадки.
3. VPN соединение до площадки ИТ-Града иногда рвется на 1-2 минуты. На вопрос, почему так происходит, ответ не можем найти ни мы, ни техподдержка. Пока приходится жить с этой проблемой.
4. Плохо работает механизм изменения размеров ресурсов, причем как «на лету», так и в выключенном состоянии. Думается мне, правда, что это скорее проблема у вендора платформы (VMware). Тем не менее мы уже столкнулись с тем, что для надежного применения всех расширений необходимо было перезагрузить гостевую машину (Windows Server 2012 R2). После изменения размеров машина сама несколько раз не загружалась. Один раз саппорт чинил эту проблему с 2 до 4 утра в период сессии – самый наш сезон. Жарко было даже ночью!
5. В 2016 году у нас был огромный, как Эверест, монолит, которому требовалось очень много ресурсов. Настолько много, что нам иногда нужно было превысить максимальные рекомендуемые для данного хоста размеры гостевых машин. Саппорт настойчиво просил нас снизить размер виртуалок хотя бы до половины объема хоста. Надо отдать ИТ-Граду должное – нам предлагали выехать на отдельное железо с возможностью использования его целиком, правда, за несколько другие бОльшие деньги, да и гибкость облака терялась.
6. Выставление счета по измерениям объема потребляемых ресурсов раз в месяц дважды сыграло с нами злую шутку. В самом начале мы прямо спросили про возможность уменьшать ресурсы 14-15 числа месяца, чтобы платить меньше. Нам прямо ответили, что это так и работает. Первый раз это больно ударило по нам во время переноса части прода в свое облако. Сработал человеческий фактор – пытались быстро все закончить до 14 числа, разгребали потом знатно. Второй раз мы воспользовались этой возможностью через почти 3 года сотрудничества, после чего нам выставили счет по среднему 5, 15, 20 числа. Тогда человеческий фактор сработал у них – после звонка обнаружилось, что допустили ошибку в свою сторону (перерасчет был сделан вручную), извинились, дали скидку.
7. Производительность дисков и машин в целом отвечала заявленным характеристикам. Тем не менее несколько раз мы не могли понять, почему все так медленно работает, даже интерфейс тормозил нещадно. Поддержка уверяла, что все в порядке и проблем с оборудованием у них не было. Что там происходило – сервер наш в этот момент мигрировал на соседний хост или же кто-то делал бекап дисковой подсистемы – для нас осталось загадкой.
8. Диски самостоятельно переключать между машинами можно только через саппорт. На старте использования нельзя было иметь в машине диски разных типов, приходилось выкручиваться (iSCSI, Samba и NFS). Через некоторое время использовать диски разных типов в одной машине стало возможными сначала через саппорт, а потом уже и самостоятельно (видимо, сделали в vCloudDirector'е). К слову, обновление системы управления виртуализацией происходит регулярно. Нам 1-2 раза в месяц приходит письмо о том, что на час-другой система управления виртуальными машинами уходит на технические работы и некоторое время будет недоступна, сами машины продолжают работу в это время.
9. 16 февраля 2018 года часть нашего прода, расположенная в ИТ-Граде, лежала из-за проблем электропитания дата-центра, в котором находилось оборудование. Об инциденте мы узнали де-факто, с техподдержкой связаться не удавалось. Пришлось звонить нашему аккаунт-менеджеру, тот за минуту сразу рассказал, что и как, и отключился, видимо, рассказывать остальным. Из приятного – мы лежали рядом со ВКонтакте.

Пожив некоторое время в съемном жилище и столкнувшись со всем вышеперечисленным, в 2017 мы решили, что в гостях хорошо, но дома лучше, и стали делать облако с быстрыми NVMe дисками и возможностью полностью все контролировать. Сказано – сделано: перевезли прод в свое облако корпов и модули поиска (суммарно более 90% нагрузки), оставив в ИТ-Граде мониторинг, статистику и частных клиентов. В 2018 еще раз все посчитали и получилось, что выгоднее разделить продакшен: часть держать в арендуемом облаке, а часть – в своем. Что из этого вышло – рассказываем дальше.

Mail Cloud Solutions

Честно говоря, хотелось, как в AWS, но в России. Поэтому мы начали смотреть в сторону облаков со схожими наборами сервисов (кого я обманываю, хотя бы с аналогом EC2 и S3). Поиски были недолгими – мы нашли «русский амазон» в лице MCS. Большая компания с широким спектром разнообразных сервисов, по всем признакам они должны уметь готовить облака!

Начало знакомства было прекрасным. К нам в офис приехал аккаунт-менеджер, все подробно рассказал, описал текущие возможности и планы на ближайшее будущее. На выходе получалась замечательная картина: низкие цены на вычислительные ресурсы, есть объектное хранилище и скорый выход в продакшен баз данных (аналог RDS). Также нам дали солидный денежный лимит для тестирования (даже больше, чем дает Azure).

К тому моменту у нас уже был готова часть IaC по разворачиванию всех машин через terraform. В MCS был openstack, и он отлично поддерживался! К слову, техподдержка ведется через телеграмм-канал – «живое» общение и видно, что хотят помочь. Есть и тикет-система, но мы ею пока так и не воспользовались. SLA техподдержки относится к запросам, создаваемым в тикет-системе.

К декабрю 2018 года мы написали скрипты развертывания инфраструктуры через terraform. Подошло время переезжать. Для начала решили перенести систему с частными клиентами, которая все это время прожила на оборудовании в ИТ-Граде. Дальше все как в кино:

7 декабря (пятница), 18:00 Запускаем репликацию данных частных клиентов. Данных много, по расчету как раз все выходные на это и уйдут.
10 декабря (понедельник), 10:00 Ожидания оправдались – все скопировалось на новое место.
12 декабря (среда) – время переезда.
10:00 Создаем виртуальную инфраструктуру через terraform. Все сервера с настроенными ОС, введены в домен, разворачиваем за пару часов.
12:00 Разворачиваем систему ansible'ем. Проводим нагрузочное тестирование. Готовы к переезду!
15:30 Начинаем переезд. По плану нам должно хватить простоя сервиса в 30 минут, но мы на всякий случай предупреждаем пользователей о возможной недоступности до 16:30.
15:45 Завершается репликация данных после выключения системы. Начинаем включение системы на новом месте.
15:55 Запускаем систему для функционального тестирования. Блокирующая проблема на ровном месте: тест показывает, что совсем не загружаются документы.
16:20 Обнаруживаем, что немного ошиблись в конфигурировании сервиса хранения. Была включена настройка, характерная для корпоративных клиентов. Исправляем, но это не помогает - система получила данные в двух разных форматах и нормально работать не хочет.
17:30 Пытаемся решить проблему своими силами, не получаем хорошего результата, откатываемся на исходную позицию.
18:00 Запускаем систему для частных клиентов на прежнем месте. Итого задержались от обещанного времени на 1,5 часа.


Выявленная проблема с разными форматами при новой попытке не должна была проявиться, но мы ее нашли и на всякий случай устранили.

17 декабря (понедельник), вторая попытка переезда.
15:30 Начинаем вторую попытку переезда. На этот раз переезд проходит штатно, внутреннее функциональное тестирование проблем не выявляет.
16:00 Запускаем систему для частных клиентов на новом месте. Она не взлетает.
16:30 Сразу после запуска еле ворочается сайт, бекэнд нагружен далеко не на 100%. В чем дело-то? Тормозить там нечему!
17:00 Все штатные телепаты собираются в одной комнате, крутим разные ручки, смотрим дашборды, логи, iotop, top, ProcessExplorer, PerformanceMonitor. Не помогает.
21:45 Принимаем решение откатиться назад, на этот раз, к сожалению, с потерей результатов 2000 проверок.
22:00 Сильно озадаченные, уходим домой.


Старый прод на ИТ-Граде легко удовлетворил отложенный спрос проверок от пользователей, никаких проблем.

На следующий день (18 декабря) мы поняли следующее:

1. Мы не знали, что конкретно тормозило систему. Перед фризом нагрузки практически нигде не было. Да, у нас все еще есть глубокие блокирующие вызовы внутрь системы и скорее всего где-то происходит блокировка, но где именно, мы не смогли придумать, надо было дополнительно исследовать.
2. Наш текущий нагрузочный тест не соответствовал профилю нагрузки на прод. Это было удивительно, т.к. благодаря этому тесту мы готовились к прошлой сессии, выявили и устранили большое количество узких мест. Но такова реальность – надо переделывать тест с учетом полученного опыта.
3. Продакшен на ИТ-Граде при сопоставимых ресурсах CPU и RAM легко справляется с вдвое большей нагрузкой.

Итак, мы быстро соорудили тест, который достигает того же результата, что мы видели воочию. Пошли к поддержке MCS выяснять, а не выедаем ли мы какой-нибудь лимит CPU, а вообще он наш безраздельно или нет, а все ли в порядке с сетью. На второй вопрос нам не ответили до сих пор, на третий нашли что-то и порекомендовали нам сделать изменения для многоядерных систем. В общем, мы развили бурную деятельность, конец года близок, и всем хочется уйти на праздники с чувством выполненного плана.

Вот с чем в итоге столкнулись в процессе работы с MCS:

1. Еще на этапе выбора нам присылали таблицу с характеристиками виртуального железа и SLA по дискам. Один из плюсов был в том, что они обещали 50 IOPS/Гб (ИТ-Град: 30 IOPS/Гб) для SSD. В договоре оказалось другое: «чтение: 5000 IOPS, запись: 2000 IOPS», и мы это пропустили, не ожидали такого. Таблицы идентичные, различие только в одном месте! Кстати, зависимости производительности от объема диска мы не увидели. Когда мы тестировали, у нас даже получалось, что при увеличении диска скорость падает. Секрет таких маленьких показателей в том, что у MCS гео-распределенный ceph, а это значит, что пока удаленная нода не скажет, что данные записала, клиенту не ответят, что запись завершена. Кстати, такой надежности «из коробки» среди провайдеров, с которыми мы общались, вроде ни у кого нет. Но нам такая надежность только вставляет палки в колеса! Нам надо в случае чего быстро перебраться в другой ДЦ при возникновении проблем, и поэтому у нас есть собственная асинхронная репликация. У нас есть DRP, и мы готовы к потерям небольшого объема данных в случае аварии. Надо отдать должное MCS, они ускорили ввод в эксплуатацию локального массива SSD, производительность которого была заметно выше.
2. Что касается параметров машин, то они не произвольные. Есть определенный набор CPU-RAM-{SSD/HDD} (почти как в AWS), а другие типы машин можно создать только через саппорт. Весь процесс занимает около 2 часов, нет ограничения на количество типов, главное, чтобы число ядер было не более половины гипервизора ~40-48 процессоров. Во время создания машины можно добавлять диски самостоятельно и переключать их между машинами.
3. После включения локальных SSD изменение параметров машины приводило к невозможности ее старта. Запустить их можно было только через саппорт. Где-то за месяц проблему решили.
4. Впервые столкнулись с техподдержкой по телеграмму. В целом это удобно, особенно на старте, когда много вопросов и идет притирка к сервису. Но чем дальше, тем сложнее оказывались вопросы и потихоньку снижались скорость ответа и информативность. К концу года, когда, естественно, сроки у всех горели, низкая скорость ответов страшно бесила. В какой-то момент даже про SLA спросили. Тут-то и пришло понимание того, что SLA – это в тикет-системе, а не в телеграмме! На момент 19 февраля в этом канале висит несколько наших вопросов без ответа, заданных 24 декабря...
5. Техподдержка через тикет-систему не учитывает, что мы залогинены, и требует дополнительно сообщить номер договора. В ответ присылает письмо «мы обязательно свяжемся с вами», при этом не указывает ни номера тикета, ни статуса.

Пока работали с MCS, параллельно начали смотреть еще одно облако.

Yet another Cloud (Яндекс Облако)

Первым из других оказался Яндекс. В конце 2018 у них были только виртуалки и объектное хранилище, своя оболочка системы виртуализации, открытый API. Плагин для terraform'а находился в альфе и согласовывался HashiCorp. Поддержка, как водится, через телеграмм, но она менее активная, чем в MCS. Тестовый денежный лимит достаточно мал и не позволял нам провести нормальное тестирование. Пришлось спешно заключать договор (3 рабочих дня) и оплачивать тестирование. По результатам теста получили то же самое, что и на MCS. Нам стало казаться, что проблем две: у всех слишком медленные диски, а у нас слишком суровый тест.

ИТ-Град 2019 год

Вообще мы поставили себе дедлайн по переезду аж 22 декабря, чтобы была еще неделя для выявления и решения скрытых проблем нового места жительства. Потеряв надежду переехать до дедлайна и немного устав от обилия новой информации в лице MCS и YC, мы решили, что на их фоне и ИТ-Град не так уж и плох. Мы даже немного поностальгировали и подумали, что все новое – это хорошо отлаженное старое. Уж на ИТ-Граде-то мы точно будем работать нормально – прецедент-то есть. Плюс ИТ-Град прокачались: появился московский датацентр, Tier III, аптайм на текущий момент у него так и вовсе 100% (ни разу еще не отказывал), а оборудование внутри – 4-х сокетные Intel Xeon Scalable (вплоть до 42 ядра x 3 ГГц Xeon Gold 6154). Чем черт не шутит, дадим второй шанс!

28 декабря (пятница), 18:10 Согласуем с аккаунт-менеджером заявку на создание нового vDC в московском ДЦ на новом оборудовании, запрашиваем квоту по дискам, достаточную для предварительного копирования всех данных частных и корпоративных клиентов.
29 декабря (рабочая суббота), 17:04 Приходит сообщение о том, что можно работать. Вечером заливаем .iso образ операционки, но так и не получается подключить его к виртуальной машине. Попробуем взять один из уже имеющихся в системе только для того, чтобы запустить копирование. Получается криво, выхода в сеть нет. Спросили у техподдержки, как воспользоваться своим образом.
30 декабря (воскресенье), 22:00 Оказывается, что при загрузке образа в его имени обязательно надо указать расширение .iso, иначе этот файл в хранилище уже никогда не будет восприниматься как образ диска. Заканчиваем развертывание нормальной машины из проверенного дистрибутива, но интернета по-прежнему нет.
31 декабря (понедельник), 3:15 Заканчиваем сравнение конфигураций Edge на новом vDC и на работающем vDC. Оказалось, что пару экранов у нас не заполнено настройками и мы их ввести не можем. Пишем заявку с просьбой проверить настройки.

Тут шампанское, салют и оливье.

2 января (среда), 15:30 К машине перестает подходить пароль для входа.
2 января (среда), 21:50 Оказывается, что это Guest OS Customization поменял пароль.
3 января (четверг), 18:05 Запускаем копирование данных!

1. Сейчас, при подготовке статьи, обнаружили, что в тикет-системе не отражается точное время запросов и ответов. Вместо этого написано «около 2 месяцев назад», точное время показывается только во всплывающей подсказке. По почте тоже тяжело восстановить последовательность событий. Сообщения на почту приходят по неочевидной логике и не содержат описания действия. Тикеты создаются в системе спустя некоторое время от лица сотрудника техподдержки ИТ-Града.
2. Посмотрев повнимательнее на оборудование после праздников, увидели там Xeon v2. То есть не то, о чем договаривались. Ладно, решили и этот вопрос с аккаунт-менеджером. Были некоторые сложности в связи с тем, что в новый 2019 год ИТ-Град вошел в составе МТС, и прямо после праздников чувствовалась легкая неразбериха. Из vDC на новом оборудовании в московском ДЦ не был виден vDC, созданный перед новым годом. Только через открытый интернет техподдержка нас «порадовала», что скорость переезда не превышает 1Тб/сут. А мы данных уже залили 7Тб! В итоге создали заявку на переезд вечером в четверг. Через сутки, вечером в пятницу, спросил, как дела и когда они планируют начать (ждать то почти неделю!)? Еще через сутки, вечером в субботу, нам сказали, что все машины переехали. Не понравилось, что 2,5 дня не было информации о ходе работ и что оценки по переезду были слишком пессимистичны.
3. В сентябре 2018 года, когда мы начали внедрять IaC, поняли, что terraform очень плохо работает с vCloudDirector (upd: во время написания статьи узнали, что появился VMware vCloud Director Provider 2.0, но пока еще не пробовали его). Поначалу нам не удавалось даже создать машину из-за того, что vCloud сообщал нам об ошибке в духе «что-то пошло не так, у вас ошибка в 512 символе 136 строки (строка была короче!) xml конфигурации машины». Мы попросили помочь саппорт. Вопрос переадресовали инженерам, в итоге нам сообщили, что terraform не поддерживается – разбирайтесь сами. Худо-бедно разобрались, что виноват был пакер, которым мы собирали образ машины, он не смог справиться с проприетарным форматом конфига VMware. У terraform очень плохо с vCloudDirector, все однопоточно медленно, а коннектор давно заброшен и не развивается. Доступа же к vSphere нам никто бы не дал. Если оставаться на VMware, то надо пилить свою автоматизацию через их api.

Мы организовали тестовый стенд на новом месте. Результат оказался удивительным – тест не прошел, симптомы такие же, как и на MCS. Вероятно, на текущем проде в пылу битв за сессию были изменены какие-то настройки ОС, которые не дают фризится системе, но какие, теперь уже не восстановить. Чтобы такое не повторялось, мы и внедряем IaC. Мы провели еще 2 теста: создали новые машины из чистых образов операционных систем текущего прода – провал; на действующих машинах продакшена – успех. Таким образом, подтвердилось, что мы сделали какую-то настройку в ОС или БД, но не помним какую. К этому моменту подоспело и решение от нашей разработки: фризы прекращаются, если отключить reliable сессии в WCF.

Прогнали нагрузочный тест с рекомендуемыми разработчиками настройками параллельно на MCS (2 ГГц, Xeon v4) и ИТ-Град (3 ГГц, Xeon v2) – количество ядер и памяти одинаковое. На MCS тест прошел быстрее (на четверть) и глаже (на ИТ-Граде тест шел рывками, то быстрее, то медленнее).

Сравнение производительности дисков

Больше всего нас заботила производительность дисков для баз данных и индексов, поэтому мы тестировали в основном SSD. Не судите строго за тесты, когда нам нужно было понять производительность облаков, на habr.com не было нескольких тестов дисков, процессоров, памяти (раз, два) облачных провайдеров. Мы были ограничены во времени и нам было нужно быстро сравнить производительность, чтобы получить представление о разнице в производительности. Поэтому требование к тесту было одно – его можно быстро повторить на любой площадке. Мы использовали максимально близкие по параметрам машины, которые у нас уже были развернуты, fio – для тестирования производительности дисков и pgbench – для оценки производительности БД на этом диске. В качестве эталона мы взяли замеры с текущего продакшена – MARS (потому что наше оборудование названо именами героев мультсериала про мышей-рокеров с марса.

Обычно производительность дисков зависит от их размеров. Мы наблюдали такое поведение в ИТ-Граде и в AWS, а вот в MCS такой зависимости мы не видели, в SLA ее также нет, а тесты дали парадоксальный (а, возможно, и неточный) результат – производительность уменьшается при увеличении диска.

Мы считали iops'ы для HDD и SSD дисков, а также tps (transactions per second) для postgres-базы на SSD дисках. В MCS есть два типа дисков – обычные гео-распределенные ceph SSD и HDD и локальные (только в одном ДЦ) SSD (их производительность приведена в скобках). Также в январе 2019 года в рассылке от MCS мы прочли, что они увеличили производительность дисков на 20%, результат перетестирования также есть в таблице (MCS 2019). В феврале сообщалось еще об одном ускорении, но тут уже тесты мы не проводили.

Результаты:

	HDD, iops		SSD, iops		SSD, tps
	read	write	read	write	read write
MARS	1336	445	17196	5729	2000
ИТ-Град	4544	1515	13231	4407	3063
MCS	1185	395	8931 (22857)	2980 (7637)	497 (1402)
MCS 2019	3229	1080	9334 (22270)	3113 (7418)	463 (1342)
YC	2202	735	5522	1843	1824

Методика тестирования

iops рассчитывался как среднее 4 прогонов fio:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps, как среднее 3 прогонов pgbench:
pgbench -c 10 -j 2 -t 10000 example

Описание стендов

MARS

Xeon v4, 2ГГц; HDD: ceph, 3 Ноды по 9x 2Tb ST2000NX0253, replica 2; SSD: ceph, 3 ноды по 2Tb NVMe Intel DC P4600, replica 2

CPU: 4, RAM: 8GB, HDD: 32GB, SSD: 150GB; Параллельно крутится продакшен.

ИТ-Град

Xeon v4/v2, 2ГГц; HDD: 0,1 IOPS/Гб; SSD: 30 IOPS/Гб

CPU: 4, RAM: 4GB, HDD: 250GB, SSD: 200GB

MCS

Xeon v4; HDD: r/w: 1500/1000 IOPS; SSD: r/w: 5000/2000 IOPS

Для тестирования HDD: CPU: 2, RAM: 4GB, HDD: 50GB

Для тестирования SSD, TPS: CPU: 8, RAM: 16GB, SSD: 600GB

YС

Xeon v4, 2ГГЦ

CPU: 8, RAM: 8GB, HDD: 20GB, SSD: 50GB

Сравнение оценок TCO за год

Мы посчитали TCO для четырех вариантов. Относительные значения приведены в таблице ниже. Надо сказать, что это расчет для нашего конкретного случая и у вас все может оказаться по-другому.

MCS	YC	ИТ-Град	AWS
1	1,23	1,37	2,28

Мы делали расчет следующим образом. Год был разбит на две части: сессии (с повышенной нагрузкой) и остальное время. Для каждой части было посчитано необходимое количество ресурсов CPU и RAM. Требуемый объем дисков, из-за постоянного роста сервиса, только растет со временем, поэтому для оценки брали среднее между началом и концом года.

Небольшая сложность в оценке была с AWS, т.к. там нет прямой стоимости за ядро и гигабайт памяти. Мы взяли 3 минимальных машины c5.large, r5.large и m5.large и рассчитали их стоимость по ценам MCS (пропорционально изменяя стоимость ядра CPU, т.к. в MCS частота 2 ГГц). Получилось так: в среднем стоимость простых инстансов AWS больше стоимости MCS в 2,5-2,8 раза. AWS публикует цены без НДС. Поэтому для к стоимости AWS добавляем 20%, среднегодовой курс доллара закладываем в 70 рублей. Диски считаются достаточно просто по ценам EBS (мы используем разные типы gp2, sc1, st1). Кое-где нам нужны NVMe диски с инстансов семейства i3. Их цена за гигабайт вычисляется очень просто: разница в стоимости между i3 и аналогичным по процессору и памяти инстансом семейства r4, деленная на объем NVMe. Получается 3,1 рубля за гигабайт в 30 суток.

Еще в разговоре про бюджеты хочется отметить разницу в стоимости лицензии Windows на одно ядро в месяц для всех облачных провайдеров. На AWS разница между стоимостью Linux OnDemand и Windows OnDemand инстансов, деленная на число ядер, – это константа, примерно равная 2800 рублей в месяц. В YC лицензия Windows на ядро стоит в 3 раза дешевле, около 900 рублей в месяц, а в MCS почти в 9(!) раз дешевле, около 300 рублей в месяц. У нас пока еще велика зависимость от Windows: сейчас, благодаря .net core, мы начинаем делать Антиплагиат кроссплатформенным, в том числе и для удешевления стоимости эксплуатации.

В совокупной стоимости YC также заложена и стоимость трафика.

Выводы

По облакам:

AWS. Говорят, что в России есть 4 хороших облачных провайдера: AWS, GCP, Azure и DO, и все они не в России.
Плюсы: классный сервис, качественное современное оборудование, хорошие конфиги в EC2, огромное количество сервисов.
Минусы: дорого (плюс курсовые риски) и не в России (РКН, великий российский файрвол на горизонте). Очень хочется, чтобы наши облака тянулись за этим примером для подражания.
Особенности: Бесплатная техподдержка может решить минимум вопросов, но если честно, то мы к ней обращались только для расширения лимитов использования. Платная, к слову, стоит около 10% от счета.

ИТ-Град. Хороший сервис для корпоративного облака. Есть аналоги EC2 и S3 на основе Swift.
Плюсы: хорошая производительность (CPU 1-2-3 ГГц, SSD, HDD), свежее оборудование (в одном из ДЦ) среди отечественных облаков, произвольные конфигурации машин.
Минусы: непонятный биллинг, VMware (плохо автоматизируется, интерфейс на флеше), немного хаоса и раздолбайства в техподдержке.
Особенности: заточен скорее под корпоративное использование (один раз настроил, потом редкие изменения), чем под высоконагруженную публичную систему (частые обновления, постоянные изменения). С 2019 года продали IaaS бизнес вместе с людьми и оборудованием в МТС, сейчас все может измениться в любую сторону. Общение через тикет-систему и телефон, хотелось бы более быстрой реакции и сообщения ожидаемых сроков выполнения работ.

MCS. Есть аналоги сервисов EC2 (Есть GPU), S3, ECS, RDS, EMR, свои сервисы: Machine Learning, Cloud Disaster Recovery, Cloud Backup
Плюсы: недорого, активно развиваются, есть GPU (Tesla V100 и Grid K2).
Минусы: медленные диски, сыроваты, плохая карма у материнской компании.
Особенности: техподдержка на старте полезная, включается большое количество сотрудников, ощущается помощь, однако затем наблюдается заметный спад активности (с 24 декабря ничего не ответили, даже волнуюсь за ребят).

YC. У нас очень мало опыта работы с этим провайдером, сложно утверждать что-то конкретное. Есть аналоги EC2, S3, RDS, DS, SQS(alfa), ELB (alfa), свои уникальные сервисы: SpeechKit, Translate.
Плюсы: диски быстрее, чем в MCS.
Минусы: провайдер к terraform сыроват; свой софт оболочки виртуализации с открытым api, комьюнити не очень большое, а это значит, что пока можно рассчитывать только на силы команды YC в развитии провайдера для terraform.
Особенности: оплата за трафик.

Выученные уроки:

1. Мы поняли, что нагрузочные тесты морально устаревают. Актуализировали тест, нашли новые узкие места, исправили их, сделали продукт лучше. Запомнили, что нагрузочный тест должен быть адекватным и должны существовать конфигурации, на которых он точно не проходит, чтобы можно было видеть границу его применимости.
2. Вопреки распространенному убеждению, что сейчас софт не оптимизируют, а все узкие места заливают ресурсами, нам пришлось разобраться и оптимизировать свою систему. Получилось лучше, чем было, новый вариант Антиплагиата требует меньше ресурсов и работает быстрее. Уже наметили еще несколько мест, где можно сократить потребление ресурсов.
3. Мы сделали IaC, развертывание и обновление через ansible, научились переезжать из облака в облако (при предварительной реплиакации данных) практически за 10-15 минут. Если данные скопированы и настроена регулярная репликация, то вот он Disaster Recovery Plan: переезд за полчаса с потерей данных за последние 15 минут.

Что нам хочется от облаков:

1. Оперативные ответы от технической поддержки. К сожалению, не пользоваться ею, как в AWS, мы пока не можем – слишком мало доступной информации.
2. Поддержка автоматизации развертывания инфраструктуры силами свободных средств (terraform).
3. Предсказуемость в характеристиках. Это относится к биллингу, производительности CPU, RAM, дисков.
4. Наличие уже сейчас функциональных аналогов EC2, S3, RDS. В ближайшей перспективе нам нужна поддержка k8s и расчетов на GPU (уже используем на AWS).

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

Автор: andyray

Источник