Comments 6
А как там с бекапами и ДР? Уже тестили?
А ЯО практически и не дешевле, как ни странно. В одно время выбирал облако для нового проекта и убедился в этом.
А экономия, подозреваю, получилась за счет банальных рефакторинга и (ре)инвенторизации инфраструктуры. У меня был опыт, когда расходы сокращались и в 3 раза за счет этого
Привет. Касательно Deckhouse — тут сравнение некорректное, так как в рамках данной цены рассматривается не стоимость инфраструктуры в AWS, а ее поддержка со стороны Фланта: мы берем на себя ответственность за работоспособность кластера, клиент получает полный доступ к модулям Deckhouse из EE версии так далее. Это в целом отдельный вопрос для диалога и я не хотел бы на нем останавливаться сейчас.
Стоимость миграции в данном случае не оценивали, так как клиент использовал программу https://cloud.yandex.ru/cloud-boost. Поэтому для клиента стоимость переезда из AWS в ЯО была если не бесплатной, то намного более дешевой по сравнению с вариантом без гранта со стороны ЯО с необходимостью оплачивать обе инфраструктуры.
И я видел несколько вопросов по поводу ре-инвентаризации и удалении лишних хостов/сервисов — хотел бы и на них ответить в этом комментарии. Перед моим разбором отмечу, что у меня нет на руках детального сравнения инвойсов от AWS и ЯО, поэтому я сейчас в большей степени рассказываю свои воспоминания и предположения:
Мы не могли использовать некоторые Managed решения от самого ЯО (в статье я рассказывал про Redis), в процессе переезда они были либо заменены на self-managed решения, что несомненно повлияло на стоимость в меньшую сторону — использовались ресурсы текущего кластера.
В AWS использовался Amazon CloudFront, после переезда мы начали использовать другое аналогичное решение — расходы тоже сократились.
Одна из задач переезда — не потерять в производительности приложения. Поэтому мы мигрировали 90% ресурсов в аналогичной конфигурации: ВИ, Managed решения, диски и так далее.
Клиент принципиально не рассматривал долгосрочную резервацию, не использовал Spot-инстансы. Поэтому для примера можем посчитать стоимость одинаковых виртуальных машин в Amazon и Яндексе с гарантированным CPU:
AWS:
Регион — Europe (Frankfurt)
Instance type — GP
Name — m5.xlarge (4 vCPU, 16 Gib RAM)
Pricing — $0.23/h.
Следовательно, в месяц получается ~$165.6 (12,159 рублей).
ЯО:
Гарантированная доля vCPU — 100%
vCPU — 4
RAM — 16 Gib
Публичный адрес — добавлен в стоимость
Исходящий трафик — 100Гб
Диск — SSD, включен в стоимость, 100Gb
В месяц выходит 5374,59 рублей.
С помощью какого инструмента описывали (IaC) инфраструктуру, Deckhouse ?
Если да, то в двух словах - это что-то похожее на Terraform (можно просто линк на детальное описание, на странице проекта заглушка).
Восстановление БД из бекапов тестили, все прошло успешно, какие объемы БД\бекапов ?
В качестве PostgreSQL connection pooler не думали использовать odyssey или в этом нет необходимости в случае использования PG как сервис ?
Переезд клиента с Yandex Cloud был мотивирован только экономией или были какие-то другие особенности ?
Отвечая на вопрос с Deckhouse - и да, и нет :)
Deckhouse поддерживает возможность установки на разную инфраструктуру; ЯО — один из вариантов такой инфраструктуры. Инсталлятору передается конфиг с настройки по облаку, а дальше уже идёт управление ресурсами в рамках Kubernetes. Сайт проекта (с документацией) совсем скоро станет публичным (анонс будет у нас в блоге). Я отправил тебе ключ c инструкцией -- как попасть в документацию. В ней будет более подробно рассказано про Deckhouse и там ты сможешь узнать, как поставить себе для тестирования.
Восстановление БД с помощью функционала ЯО тестировали, но пока что недостаточно данных, чтобы дать точную оценку. В целом, проблем не наблюдаем. Если говорить о размерах, то в каждом проекте по разному, в основном мы говорим о БД с размером больше 250Гб и до нескольких терабайт.
В планах внедрить pgBouncer в рамках данного проекта, но пока что до реализации не дошли из-за некоторых ограничений со стороны приложения.
Говоря о мотивации переезда — экономия была одной из основных целей, но не единственной. В целом, о таких целях я говорил в начале статьи — для этого проекта это тоже было актуально.
Опыт миграции инфраструктуры клиента из AWS в Яндекс.Облако