Как стать автором
Обновить

Комментарии 6

А как там с бекапами и ДР? Уже тестили?

Что я могу сказать. Не верю, что Яндекс прям на 30% дешевле оказался. Опять же - не знаю как вы свой " Deckhouse" позиционируете, но у вас в минимальном конфиге кластер в AWS начинается от $500. Хотя на $500 можно крутить созданный нативными инструментами достаточно мощный кластер. Плюс еще Saving plans, Spots, Reserved instances, Lifecycle policies - всего хватает. Плюс еще стоимость самой миграции тоже не учтена, а слить несколько терабайт - это тоже денег стоит.

А ЯО практически и не дешевле, как ни странно. В одно время выбирал облако для нового проекта и убедился в этом.

А экономия, подозреваю, получилась за счет банальных рефакторинга и (ре)инвенторизации инфраструктуры. У меня был опыт, когда расходы сокращались и в 3 раза за счет этого

Привет. Касательно Deckhouse — тут сравнение некорректное, так как в рамках данной цены рассматривается не стоимость инфраструктуры в AWS, а ее поддержка со стороны Фланта: мы берем на себя ответственность за работоспособность кластера, клиент получает полный доступ к модулям Deckhouse из EE версии так далее. Это в целом отдельный вопрос для диалога и я не хотел бы на нем останавливаться сейчас.

Стоимость миграции в данном случае не оценивали, так как клиент использовал программу https://cloud.yandex.ru/cloud-boost. Поэтому для клиента стоимость переезда из AWS в ЯО была если не бесплатной, то намного более дешевой по сравнению с вариантом без гранта со стороны ЯО с необходимостью оплачивать обе инфраструктуры.

И я видел несколько вопросов по поводу ре-инвентаризации и удалении лишних хостов/сервисов — хотел бы и на них ответить в этом комментарии. Перед моим разбором отмечу, что у меня нет на руках детального сравнения инвойсов от AWS и ЯО, поэтому я сейчас в большей степени рассказываю свои воспоминания и предположения:

  1. Мы не могли использовать некоторые Managed решения от самого ЯО (в статье я рассказывал про Redis), в процессе переезда они были либо заменены на self-managed решения, что несомненно повлияло на стоимость в меньшую сторону — использовались ресурсы текущего кластера.

  2. В AWS использовался Amazon CloudFront, после переезда мы начали использовать другое аналогичное решение — расходы тоже сократились.

  3. Одна из задач переезда — не потерять в производительности приложения. Поэтому мы мигрировали 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 в рамках данного проекта, но пока что до реализации не дошли из-за некоторых ограничений со стороны приложения.

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

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