- PVSM.RU - https://www.pvsm.ru -
Мы делаем самую лучшую в России и ближнем зарубежье систему обнаружения заимствований. В идеальном мире мы бы занимались только разработкой и развитием системы. Но, увы, Антиплагиат работает не в вакууме, и для того, чтобы нашим пользователям было удобно и комфортно использовать наши разработки, нам необходимо также развивать среду, окружающую наш сервис. Наш софт пока не работает без железа, пользователям нужно оказывать техническую поддержку, получать оплату от пользователей необходимо без нарушения законодательства и т.д. Словом, рутины хватает.
Эта статья – первая из серии производственных драм историй о том, как мы делали наш сервис лучше при помощи аутсорса. Делимся реальными проблемами и выводами.
(откуда-то из интернета, впервые увидел тут [1].)
Нагрузка на нашу систему сильно неравномерна: во-первых, в течение суток нагрузка меняется в 5 раз. Во-вторых, есть и ярко выраженная сезонность. Суточный максимум проверок после окончания летней сессии уменьшается в 10 раз! Зимняя сессия не столь яркая, но тоже не подарок. Плюс каждая последующая летняя сессия тяжелее (по числу проверок) и сложнее (новые технологии поиска и функциональность) предыдущей. Поэтому, с одной стороны, хочется иметь хороший запас по ресурсам, с другой – не платить лишнего во время спада активности. В сессию можно развернуть побольше серверов, а летом сократить объем потребляемых ресурсов. Очевидно, что это как раз случай облачных провайдеров. В этой статье я расскажу о различных аспектах взаимодействия с несколькими облачными провайдерами (AWS, ИТ-Град, MCS, YC). Если кому-то покажется, что это крик души, он не сильно ошибется. Итак, поехали!
Мы начали использовать облачные ресурсы в феврале 2013 года, когда арендовали наш первый сервер в AWS. Фактически, Amazon – это первый и самый продолжительный опыт Антиплагиата с «облаками». Тогда мы начинали с одной машины, а сейчас наш бюджет в AWS на порядок выше, чем бюджет на все российские облака. Первая любовь, как известно, не забывается никогда. Все проблемы и возможности с другими облаками в этой статье я рассматривал с учетом опыта использования AWS.
Правда, своя ложка дегтя в отношениях с Amazon тоже была. Ниже перечислены особенности или неудобства, которые возникали у нас с Амазоном:
В принципе, жить с указанными недостатками было можно. Однако именно в тот момент, когда Амазон наконец заметил российский рынок, наш счет стал не очень удобным для оплаты с карты. К счастью, Амазон быстро исправил ситуацию и выделил нам аккаунт-менеджера, который помог нам перейти с оплаты через карту на прямой договор и оплату по счету и оформить разного рода соглашения. Вообще он регулярно приезжает в Россию, и, когда заходит к нам, рассказывает о возможностях по оптимизации инфраструктуры и оплаты. Иногда он привозит с собой Solution Architect'a, с которым можно обсудить текущую архитектуру нашего решения, рассказать о «хотелках» и проблемах и получить несколько вариантов решения, причем не только через сервисы AWS. Сотрудники Амазона декларируют, что их цель не в том, чтобы впарить услуг побольше, а сделать так, чтобы купленные услуги приносили пользу бизнесу. Похоже, что это действительно правда. Количество сервисов, скорость их разработки и глубина взаимной интеграции впечатляют. В AWS есть все для организации как процесса разработки, так и эксплуатации высоконагруженных систем любого масштаба. Глобальная проблема пока что только одна – дорого!
В 2015 году мы решили, что нам пора полностью отказаться от собственного железа. Хотелось возложить проблемы по надежности именно оборудования на других и больше сконцентрироваться на улучшении процессов собственной разработки. По нашим прогнозам, в 2016 году нам бы впритык хватило имеющегося у нас оборудования, и хотелось бы иметь запас на всякий пожарный случай. Мы подошли к выбору провайдера основательно: подготовили нагрузочный тест и анкету с важными для нас вопросами и придирчиво выбирали из пяти провайдеров: ActiveCloud, Cloud4Y, CloudOne, ИТ-Град, Softline.
В итоге остановили выбор на облаках ИТ-Град. Их преимущества:
В 2016 году мы переехали на ИТ-Град. Вот что случилось за неполные три года нашей совместной жизни:
Пожив некоторое время в съемном жилище и столкнувшись со всем вышеперечисленным, в 2017 мы решили, что в гостях хорошо, но дома лучше, и стали делать облако с быстрыми NVMe дисками и возможностью полностью все контролировать. Сказано – сделано: перевезли прод в свое облако корпов и модули поиска (суммарно более 90% нагрузки), оставив в ИТ-Граде мониторинг, статистику и частных клиентов. В 2018 еще раз все посчитали и получилось, что выгоднее разделить продакшен: часть держать в арендуемом облаке, а часть – в своем. Что из этого вышло – рассказываем дальше.
Честно говоря, хотелось, как в AWS, но в России. Поэтому мы начали смотреть в сторону облаков со схожими наборами сервисов (кого я обманываю, хотя бы с аналогом EC2 и S3). Поиски были недолгими – мы нашли «русский амазон» в лице MCS [6]. Большая компания с широким спектром разнообразных сервисов, по всем признакам они должны уметь готовить облака!
Начало знакомства было прекрасным. К нам в офис приехал аккаунт-менеджер, все подробно рассказал, описал текущие возможности и планы на ближайшее будущее. На выходе получалась замечательная картина: низкие цены на вычислительные ресурсы, есть объектное хранилище и скорый выход в продакшен баз данных (аналог 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 декабря) мы поняли следующее:
Итак, мы быстро соорудили тест, который достигает того же результата, что мы видели воочию. Пошли к поддержке MCS выяснять, а не выедаем ли мы какой-нибудь лимит CPU, а вообще он наш безраздельно или нет, а все ли в порядке с сетью. На второй вопрос нам не ответили до сих пор, на третий нашли что-то и порекомендовали нам сделать изменения для многоядерных систем. В общем, мы развили бурную деятельность, конец года близок, и всем хочется уйти на праздники с чувством выполненного плана.
Вот с чем в итоге столкнулись в процессе работы с MCS:
Пока работали с MCS, параллельно начали смотреть еще одно облако.
Первым из других оказался Яндекс. В конце 2018 у них были только виртуалки и объектное хранилище, своя оболочка системы виртуализации, открытый API. Плагин для terraform'а находился в альфе и согласовывался HashiCorp. Поддержка, как водится, через телеграмм, но она менее активная, чем в MCS. Тестовый денежный лимит достаточно мал и не позволял нам провести нормальное тестирование. Пришлось спешно заключать договор (3 рабочих дня) и оплачивать тестирование. По результатам теста получили то же самое, что и на MCS. Нам стало казаться, что проблем две: у всех слишком медленные диски, а у нас слишком суровый тест.
Вообще мы поставили себе дедлайн по переезду аж 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 Запускаем копирование данных!
Мы организовали тестовый стенд на новом месте. Результат оказался удивительным – тест не прошел, симптомы такие же, как и на MCS. Вероятно, на текущем проде в пылу битв за сессию были изменены какие-то настройки ОС, которые не дают фризится системе, но какие, теперь уже не восстановить. Чтобы такое не повторялось, мы и внедряем IaC. Мы провели еще 2 теста: создали новые машины из чистых образов операционных систем текущего прода – провал; на действующих машинах продакшена – успех. Таким образом, подтвердилось, что мы сделали какую-то настройку в ОС или БД, но не помним какую. К этому моменту подоспело и решение от нашей разработки: фризы прекращаются, если отключить reliable сессии в WCF.
Прогнали нагрузочный тест с рекомендуемыми разработчиками настройками параллельно на MCS (2 ГГц, Xeon v4) и ИТ-Град (3 ГГц, Xeon v2) – количество ядер и памяти одинаковое. На MCS тест прошел быстрее (на четверть) и глаже (на ИТ-Граде тест шел рывками, то быстрее, то медленнее).
Больше всего нас заботила производительность дисков для баз данных и индексов, поэтому мы тестировали в основном SSD. Не судите строго за тесты, когда нам нужно было понять производительность облаков, на habr.com не было нескольких тестов дисков, процессоров, памяти (раз [9], два [10]) облачных провайдеров. Мы были ограничены во времени и нам было нужно быстро сравнить производительность, чтобы получить представление о разнице в производительности. Поэтому требование к тесту было одно – его можно быстро повторить на любой площадке. Мы использовали максимально близкие по параметрам машины, которые у нас уже были развернуты, fio – для тестирования производительности дисков и pgbench – для оценки производительности БД на этом диске. В качестве эталона мы взяли замеры с текущего продакшена – MARS (потому что наше оборудование названо именами героев мультсериала про мышей-рокеров с марса [11].
Обычно производительность дисков зависит от их размеров. Мы наблюдали такое поведение в ИТ-Граде и в 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
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
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
Xeon v4, 2ГГЦ
CPU: 8, RAM: 8GB, HDD: 20GB, SSD: 50GB
Мы посчитали 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 публикует цены [12] без НДС. Поэтому для к стоимости AWS добавляем 20%, среднегодовой курс доллара закладываем в 70 рублей. Диски считаются достаточно просто по ценам EBS [13] (мы используем разные типы 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. У нас очень мало опыта работы с этим провайдером, сложно утверждать что-то конкретное. Есть аналоги [14] EC2, S3, RDS, DS, SQS(alfa), ELB (alfa), свои уникальные сервисы: SpeechKit, Translate.
Плюсы: диски быстрее, чем в MCS.
Минусы: провайдер к terraform сыроват; свой софт оболочки виртуализации с открытым api, комьюнити не очень большое, а это значит, что пока можно рассчитывать только на силы команды YC в развитии провайдера для terraform.
Особенности: оплата за трафик.
Помимо переезда в облака, в течении последних нескольких месяцев у нас получилось понаступать на грабли и в других областях. Как это было – расскажем чуть позже.
Автор: andyray
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/tehpodderzhka/309462
Ссылки в тексте:
[1] тут: https://pikabu.ru/story/izbalovannost_pokupatelya_v_raznyikh_stranakh_6478602
[2] резервирования: https://aws.amazon.com/ru/ec2/pricing/reserved-instances/
[3] спотовых инстансов: https://aws.amazon.com/ru/ec2/spot/
[4] эфемерные диски: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/InstanceStorage.html
[5] Гибкий биллинг: https://www.it-grad.ru/services/iaas/billing/
[6] MCS: https://mcs.mail.ru/
[7] вошел в составе МТС: https://www.vedomosti.ru/technology/articles/2019/01/09/790984-mts
[8] VMware vCloud Director Provider 2.0: https://www.terraform.io/docs/providers/vcd/index.html
[9] раз: https://habr.com/ru/company/itsumma/blog/438240/
[10] два: https://habr.com/ru/post/439690/
[11] мышей-рокеров с марса: https://www.kinopoisk.ru/film/229381/
[12] цены: https://aws.amazon.com/ru/ec2/pricing/
[13] ценам EBS: https://aws.amazon.com/ru/ebs/pricing/
[14] аналоги: https://cloud.yandex.ru/services
[15] Источник: https://habr.com/ru/post/440912/?utm_campaign=440912
Нажмите здесь для печати.