Почему мы перестали держать свои серверы и начали арендовать чужое «железо»
Многие считают, что держать свои серверы выгодней, дешевле и надежней. Но в каждом правиле есть исключения. И сегодня я расскажу вам о том, когда это правило не работает.
Меня зовут Алексей Тарасов, я директор компании ООО «Тендерлэнд», которая вот уже как 11 лет занимается разработками программного обеспечения для участников размещения государственных и коммерческих заказов. Проще говоря, тендерных агрегаторов и сервисов для компаний, которые участвуют в тендерах. Такая деятельность требует серьёзной IT-инфраструктуры. Мы работаем с большими базами данных, различными микросервисами, пользовательскими файлами, ведем бэкенд-разработки.
Начиналось всё с того, что мы покупали своё серверное оборудование и размещали его в стороннем дата-центре. Если вы слышали про услуги colocation, то знаете, как это работает. Поддержкой и обслуживанием занимались сами. Наши специалисты имели доступ в ДЦ и когда это было необходимо, приезжали туда — меняли комплектующие, апгрейдили, ремонтировали то, что выходило из строя.
А затем проект стал расти. И довольно стремительно. Появились новые технологии, а с ними — и новые требования к проекту. От инфраструктуры, которую мы создали на первых порах, потребовалась гибкость, которой не было. И мы столкнулись с целым рядом проблем.
Новая конфигурация — и быстро!
Представьте себе ситуацию. Вы купили сервер под конкретные задачи, уже подсчитали, как будете амортизировать его в течение двух лет. И вдруг появляется новая технология и для решения поставленных задач эта конфигурация уже не подходит.
Варианта всего два — либо надо внести изменения в существующую конфигурацию, что часто невозможно, либо отказываться от сервера и покупать новый…
Помню, собирали мы как-то сервер для работы с MySQL с максимальным объёмом оперативной памяти — 256 Гб. Под него, естественно, своя материнская плата, процессор соответствующий. А потом так вышло, что нужно было срочно переходить на поисковый движок Elasticsearch, который, к слову, сделан на Java. А Java больше 32 Гб «прожевать» не может. И это ещё не всё. Когда ты строишь отказоустойчивый кластер, то обязательно должен подумать о дублировании данных, их репликации. Это значит, что у тебя обязательно должен быть парк полностью одинаковых по конфигурации машин. И получается, что вместо одного сервера с оперативкой 256 Гб, тебе уже нужно, скажем, шесть серверов с памятью по 32 Гб. Плюс на каждом — мощный процессор и SSD-диски для быстродействия.
Вроде бы простая смена технологий, а влечет за собой катастрофическую смену оборудования.
И это не единичный случай. Меняться могут типы движков, баз данных или файловых хранилищ и прочее.
Кроме того, их нужно тестировать под конкретное «железо». Потому что не всегда с ходу понятно, подойдет ли выбранная конфигурация под новую технологию или нет. И по сути ты должен выкинуть свои серверы и купить новые, потому что продавать оборудование больно, долго и невыгодно. Именно в этот момент ты задумываешься о том, что арендовать проще — изначально это выходит дороже, но когда тебе требуется быстрая смена конфигурации, всё это окупается с лихвой.
Админ — тоже человек
Вторая проблема, с которой мы столкнулись в это время, — выросшие затраты на содержание и обслуживание растущего парка серверов. Чем больше у тебя машин, тем чаще они требуют внимания. Сгорел блок питания? Надо заменить. Истёк срок эксплуатации диска? Надо докупить. Вместе с ростом машин выросло и количество системных администраторов. А хорошие специалисты стоят дорого. Кроме того, они иногда болеют, уходят в отпуск или женятся. Да и человеческий фактор никто не отменял. Админы тоже люди — если работать без перерывов много часов, любой начнет ошибаться. Так, например, однажды нам довольно долго пришлось восстанавливать критичные данные с поврежденного харда — специалист ошибся и неверно настроил рэйд.
Получалось, что мы одновременно пытаемся усидеть на двух стульях — и разработкой программного обеспечения заниматься, и свой дата-центр развивать. Да, это в принципе возможно, но только при условии, что тебе не требуется внезапная смена всей инфраструктуры, потому что технологии в очередной раз изменились.
Если говорить о приоритетах, то для нас было важнее — и тогда, и сейчас — высвободить временные ресурсы технической команды и больше заниматься бизнесом, меньше думая об инфраструктуре.
Плюсы перехода на арендованные серверы
Так, помучившись какое-то время, мы пришли к тому, что арендовать чужие серверы в нашем случае будет гораздо выгоднее во всех смыслах. Хостинг-провайдера выбирали, в основном, по цене и отзывам. Из нескольких вариантов остановились на FirstDEDIC. Кроме основных параметров, на которые мы ориентировались, в их пользу говорили ещё два факта — дата-центр уровня надежности Tier III и наличие второго проекта FirstVDS, где мы могли арендовать и виртуальные серверы. Собственно, с них мы и начали.
Заказали несколько виртуальных серверов, нагружали, проверяли, тестировали. Разместили там несколько простеньких проектов. Постепенно стали переносить свои проекты и на выделенные серверы. И надо сказать, что такой переход со своего «железа» на арендованное здорово облегчил нам жизнь. Собственно, к чему мы пришли в итоге.
Во-первых, снизились расходы на строительство и обслуживание инфраструктуры. Конкретные цифры раскрывать по понятным причинам не могу, но примерно процентов на 15%. Арендовать у провайдера выходит ненамного дороже, чем если бы мы покупали и амортизировали сами. Это мы уже проходили, так что точно знаем, в какую копейку это «влетает». Кроме того, все задачи по обслуживанию парка — теперь не наша проблема. За исправностью оборудования следят специалисты хостинг-провайдера, которые работают посменно. И даже если кто-то уходит в отпуск и болеет, на нас это не отражается никак.
Во-вторых, решилась проблема с быстрой сменой конфигураций. За все время, что мы здесь хостимся, а это около пяти лет, еще ни разу мы не сталкивались с ситуацией, когда нет подходящей конфигурации. Всегда находился и находится какой-то оптимальный вариант. И даже если параметры выделенного сервера не совсем идеально попадают под наши требования, мы можем написать запрос в поддержку с просьбой, например, добавить накопитель или оперативки. И если есть техническая возможность и свободное «железо», нам не отказывают и идут навстречу.
В-третьих, у нас появилась возможность относительно безболезненно экспериментировать с конфигурациями. Например, я уже упоминал про поисковый движок Elasticsearch. Когда мы переносили сюда все проекты, выбрали под его размещение конфигурацию попроще на SSD SATA, понаблюдали, замерили показатели, решили перенести на серверы с SSD NVMe и получили существенный прирост скорости работы.
При этом нам не надо было закупать своё оборудование, а потом избавляться от того, что не подошло. Сейчас мы можем протестировать несколько разных конфигураций и выбрать сервер с оптимальными характеристиками, не тратя на это ни уйму времени, ни денег.
И наконец, отдельно хотелось бы сказать про VDS. У нас очень много разнообразных микросервисов. Для них мы используем виртуальные машины второго проекта того же провайдера. На них много что крутится. И это получается намного дешевле, чем облачная инфраструктура. Мы сравнивали по цене с Яндексом или Амазоном. По цене выгоднее с виртуалками, а по удобству практически то же самое. Я могу создать виртуальную машину, настроить ресурсы, как мне нужно, протестировать, а потом заказать ещё одну или несколько с такими же параметрами. По надёжности тоже не уступает. У провайдера есть тариф Атлант, облачные VDS с дублированием оборудования. Мы их используем под проекты, критичные к даунтайму.
Что в итоге
По своей сути наш проект представляет собой конгломерат различных систем, сервисов, баз данных и много чего ещё. Каждый его элемент требует определенного «железа» или виртуальных серверов. На одних серверах мы размещаем бэкенд, на других пользовательские файлы, на VDS пишутся логи, работают микросервисы. Самая нагруженная часть — БД и поисковый движок, их тоже размещаем на выделенных серверах. Своё оборудование пока частично оставили, но планируем в будущем отказываться и от него.
Мы стараемся придерживаться баланса между расходами на серверы и производительностью. Мониторим нагрузку, распределяем между машинами, а если не хватает серверов, оперативно добавляем. С арендованными серверами держать этот баланс получается гораздо проще и легче, чем на своём оборудовании. А кроме того, мы можем спокойно развивать и расширять сервис, потому что с одной стороны, есть возможность быстро и гибко достраивать инфраструктуру под новые требования и технологии, а с другой, мы не отвлекаемся на то, чтобы обслуживать и держать эту инфраструктуру в рабочем состоянии.
Если у хостера возникнут разногласия с партнерами или собственниками помещения, где расположено оборудование, то принадлежащее ему оборудование может быть изъято в качестве залога (обеспечения). Прецеденты в РФ были. В итоге, моментальная потеря всех данных и усилий потраченных на настройку ПО. Это серьезный риск для IT-компании арендующей чужое железо.
В посте конечно про это не скажут, ведь не надо ругать слона.
по такой логике надо и свой ДЦ, и своих поставщиков электроэнергии, интернета и т.д.
мало ли что там где не прописано и какие прецеденты в РФ могут случиться
Вы правы. Такие случаи действительно бывают и 100%-ной гарантии, что такого совсем никогда-никогда не случится, нет. Но в нашем случае все эти риски сведены к минимуму — оборудование полностью принадлежит нам, и в целом, мы делаем все, чтобы таких проблем не возникло. Один из двух дата-центров тоже наш полностью. А кроме того, эта ситуация вполне может коснуться и тех, кто не арендует, а использует свое “железо” и например, арендует под него помещение.
Бекапы спасут данные, распределенная балансированная система спасет от перебоев. Свое оборудование в чужом ДЦ это дорого, держать резервное железо еще дороже, обновлять железки больно, горячий ремонт никто не выполнит. Придумывать опасения нет нужды.
Бэкапиться надо от и до. Тогда не так критично будет. А с хостером может случиться абсолютно всё что угодно и случается. Я уже давно на них не надеюсь и любой свой или клиентский проект могу поднять за полдня в другом месте - благо днсы сейчас довольно быстро прописываются.
а еще могут возникнуть разные разногласия преразные. типа такого
https://www.kommersant.ru/doc/805282
А если взять сервер в 256гб и порезать на 5-6 виртуалок по 32гб?
Тоже самое хотел написать, не говоря о том, что тот же эластик можно запустить в докере, настроив ограничение ресурсов.
P.S. Если пробегут джависты мимо, то увидим комментарий на счет 32Гб, точно видел решения на Java, которые и больше потребляли.
"Вроде бы простая смена технологий, а влечет за собой катастрофическую смену оборудования."
Ясен пень! Когда меняешь базу данных на поисковый движок может потребоваться не только оборудование поменять, можно и сферу деятельности сменить.
Ну что же, жму руку! Вы, таки, заставили меня написать свой первый комментарий тут. И вот, что я хотел бы сказать:
1) теперь я никогда не воспользуюсь услугами вашей "хостинг" компании.
2) не торгуйтесь за качество текста на фриланс биржах, лучше было не мелочиться и заплатить больше 500 рублей но более грамотному автору за сочинение.
3) это не Яндекс.Дзен. Тут не сработает этот "ход" использования глупости и противоречий в авторском посте, дабы комментаторы подняли пост в топы и алгоритм подумал бы, что это интересно и стал прокачивать.
4) к вымышленному "клиенту" и иже с ним: лучше заплатить за консультацию немного денюшек, а не ставить MySQL обрабатывать big data.
5) 256Gb оперы.. Я вот, сходу, даже придумать не смог, чем её забить можно..
6) почему не использовать виртуализацию для деления 256Gb, как это те же хостеры делают, которым вы в любом случае переплачиваете? Да потому что вымышленный клиент не разбирается в технологиях.
7) вы так удивляетесь скорости работы SSD и NVM express SSD, хотя можно сперва прочитать разницу между ними, посмотреть тесты, бенчмарки, провести анализ.. О каком бизнесе идёт речь? Если вы не делаете банальных вещей при старте проекта и не продумываете наперёд последствия. А почему вы так же не удивляетесь, к примеру, дирижаблю и истребителю??
Короче, какой-то "Пупкин" узнал что "лучшим" продвижением компании являются авторские отзывы с линковкой, вот только автора выбрали неудачно.
Удачи Вам, о "чудо" хостинг в вашем нелёгком СЕО пути.
Забавно читать выводы без аргументов) Почему клиент вымышленный? Сайт по ссылке открывается, есть отзывы, вакансии, даже ООО в сбисе гуглится. То, что клиент делает не так, как вы считаете правильным, тоже хостер виноват? Аргументов то нет. Писать отзыв не основанный на опыте под статьей клиента, даже с линковкой, немного странно. Наверное все были в сговоре, зарегистрировали ООО 11 лет назад, чтобы вас заставить комментарий написать)) Ох уж эти теории заговоров на пустом месте)
Плюсую, тоже не понял этих моментов. До кучи еще могу с уверенностью сказать, что firstVDS отвратительный хостинг-провайдер, 2 года назад ушел от них из-за постоянных провалов в сети, бывало проект просто не грузился по несколько минут раз 5 в день. Буквально недавно нужен был недорогой конфиг, чтобы развернуть сервер для тестирования, решил проверить, как там дела у firstVDS, так вот ничего не поменялось. Слишком частых отвалов сети не было, но происходят до сих пор
ППКС
свои сервера сегодня - неумно, невыгодно и неперспективно
а мне нравится. во первых свои - потому что чужие хороши до поры до времени, например вот такой
https://www.kommersant.ru/doc/805282
во вторых - держится в тонусе скилл по работе с инфрой.
вот то что в статье верно указали - работа со своей инфрой это тоже работа. она не очень прям легкая. но и не особо сложная. Если ее делать то в команде/компании поддерживается какое-никакое ноу хау по этому вопросу.
а если это ноу хау утерять (полностью перейдя на аренду и посидев на ней, уволив свой персонал и отучившись работать со своим ДЦ) то набрать его заново уже сложновато.
А если оно есть то тут есть доп бонусы.
Не совсем понимаю какие могут быть недостатки в Вашем конкретном случае перехода на виртуальные сервера полностью? Просто переход на них - уже закрытие 80% указанных Вами проблем.
Комментарий недоступен
колокол - сколько воспоминаний! выбор и покупка комплектующих, конфигурация дебиан, шум вентиляторов... эх...
Пишу бэк 7 лет и ни разу не работал с физическим сервером. До этого поста описанная проблема была для меня чем-то из середины нулевых. Зачем свой сервер...
Недавнее падение Amazon Azure показало как надежно хранить данные на чужих серверах. Уронили один сервис пострадали все :)
А на внутренних так не происходит?)
абсолютно частный случай в виду специфики вашей работы. для большинства эти причины не актуальны.