Сколько можно потратить на содержание собственного сервера Mastodon на AWS

Я около месяца содержал собственный однопользовательский сервер Mastodon на AWS. В этой статье я расскажу, во сколько мне это обошлось.

Предисловие:

Для начала нужно сказать пару слов. Во-первых, я работаю на AWS в должности Solutions Architect. Однако поскольку это мой личный проект, я запустил его на своём собственном аккаунте AWS, за который плачу без скидок сотрудникам и особых условий. Все мои идеи и взгляды при создании этого проекта были моими собственными и необязательно отражают рекомендации и инструкции моего работодателя.

Кроме того, я занялся этим проектом, чтобы достичь нескольких целей. Во-первых, я просто хотел узнать о Mastodon и о том, как настроить его небольшой собственный однопользовательский инстанс. Эта статья не является руководством по управлению сервером в продакшен-среде для тысяч пользователей. Это просто моё хобби. Тем не менее, я знаю, что многих интересуют подобные вещи, поэтому надеюсь, что информация окажется полезной.

Наконец, есть несколько провайдеров хостинга ^[1], которые платно настроят и будут управлять вашим собственным сервером Mastodon. Но это совсем другое. Мой эксперимент будет сложным и запутанным, я попытаюсь пойти своим путём и буду менять маршрут так, как мне покажется нужным. Если вы просто хотите содержать собственный сервер, то, вероятно, лучше начать с провайдеров хостинга ^[1]!

▍ Архитектура

Я уже писал несколько постов ^[2] о настройке Mastodon и о том, почему остановился на той архитектуре, которую выбрал. С тех пор кое-что изменилось, но в целом архитектура осталась прежней.

1. Для compute — один инстанс Elastic Compute Cloud (EC2) t4g.small, на котором запущен Mastodon, его база данных PostgresSQL и Redis.
2. Для хранения — я перешёл от статических образов на Amazon Simple Storage Service (S3), а для их доставки использую Amazon CloudFront.
3. В рамках AWS я использую множество других мелких сервисов для мониторинга, изучения своих счетов и резервного копирования.

▍ Затраты

На момент написания статьи на проект потрачено $52,74. Как видно на графике ниже, $32 из этой суммы потрачено в первый день на регистрацию доменного имени micah.social ^[3]. На мой взгляд, это дороговато за доменное имя, но я очень хотел его, чтобы хвастаться.

Если вычесть оплату доменного имени регистратору (которую придётся отдавать ежегодно), то я потратил $20,74 на дополнительные сервисы AWS, выходящие за рамки бесплатного тарифа и бесплатных пробных версий.

▍ Никаких затрат на compute до 2024 года

Здесь важно упомянуть, что придётся тратиться ещё и на compute. Хотя на самом деле это не совсем так. Вы видите небольшой всплеск затрат на compute в первый день, когда я экспериментировал с другим типом инстанса, но в целом я пока ничего не тратил на compute. Это связано с тем, что выбранный мной тип инстанса Graviton2 ARM based t4g.small ^[4] имеет бесплатную пробную версию до конца 2023 года ^[5] при использовании до 750 часов в месяц. Это значит, что после завершения 2023 года с моего инстанса начнут взымать почасовую оплату. Когда это произойдёт, у меня будет два варианта:

1. Я могу начать платить почасовой тариф On-Demand $0,0168 в час, то есть примерно $12,26 в месяц
2. Я могу купить Compute or EC2 Instance Savings Plan ^[6]. Вероятно, так я и поступлю. Трёхлетний тарифный план EC2 Instance Savings Plan с полной предоплатой стоит $165,56, что равно $4,60 в месяц. Это позволит мне использовать его с другим типом инстанса в том же семействе, если я решу выполнить апгрейд до t4g.medium.

▍ Упс, затраты на CloudWatch!

Наверно, вы заметили всплеск затрат посередине показанного выше графика. В своём посте о мониторинге ^[7] я говорил, что установил в инстанс Amazon CloudWatch Agent, чтобы отслеживать ключевые метрики. Однако я не смог отфильтровать все ненужные мне метрики, поэтому оказалось, что в CloudWatch отправляется полный пакет данных, что довольно дорого. Как только я понял это, то отключил агент. Разобравшись с ним, я вернулся к нему и добавил правильную конфигурацию фильтров.

▍ EBS Snapshots

Это подробный график затрат на хранилище снэпшотов EBS Snapshots. В течение месяца он рос, однако на основании моего графика бэкапов я рассчитываю, что он выровняется.

Когда я приступил к этому проекту, я искал простой способ выполнения резервного копирования данных в своём инстансе EC2. Мне хотелось чего-то простого в настройке и управлении, поэтому я решил выбрать EBS Snapshots. Я в курсе, что существуют другие, потенциально более дешёвые способы для этого. В основном меня волновало создание бэкапов для данных, хранящихся в PostgresSQL. Все статические ресурсы теперь хранятся в S3, поэтому на самом сервере находятся только кодовая база, конфигурации и база данных.

Однако мой график создания снэпшотов слегка чрезмерен для этого проекта. Сейчас я создаю снэпшоты каждый час, каждый день и каждый месяц. Ежечасные снэпшоты утилизируются через 24 часа, ежедневные через 30 дней, а ежемесячные хранятся примерно в течение двух лет. Кроме того, я выполняю резервное копирование всего тома, и даже при инкрементальных бэкапах объём может нарастать довольно быстро из-за данных, которые, скорее всего, мне не нужны.

Лучше было бы просто делать бэкапы самой базы данных PostgresSQL с похожим графиком и с правильной блокировкой базы данных, но это уже проект на будущее.

▍ Слон S3

Самые существенные затраты, на данный момент сравнимые с затратами на EBS Snapshots — это расходы на S3. И с ними же сложнее всего разобраться, но я постараюсь!

Вот несколько заметок о моей настройке S3:

1. Mastodon не только хранит ваши собственные загруженные статические ресурсы, но и ресурсы для всех аккаунтов и меток, на которые вы подписаны. Мне не совсем понятно, когда он решает делать их копии, однако это, скорее всего, источник наибольшего объёма сохраняемых данных.
2. В параметрах Mastodon есть настройки для ограничения этих кэшируемых ресурсов, но пока я их не включал, потому что мне было любопытно узнать, о каких объёмах данных мы говорим. Сейчас их примерно 180 ГБ.
3. Что касается самого хранения, Mastodon загружает ресурсы при помощи S3 Standard tier. Я не нашёл способа изменить это, однако отправил issue ^[8], сообщив, что эту возможность неплохо было бы добавить в конфигурацию. Это позволило бы мне загружать ресурсы напрямую в Intelligent-Tiering ^[9], что, на мой взгляд, имеет больше смысла.
4. Я настроил Lifecycle Policy ^[10], чтобы спустя день перемещать все мои данные в S3 Intelligent Tiering. Это немного спорное решение, поэтому мне нужно будет подождать и посмотреть, чем он обернётся. S3 Intelligent-Tiering должен автоматически перемещать мои данные из одного tier в другой на основании паттернов доступа. Однако он не учитывает объекты меньше 128 КБ и за него взимается небольшая оплата мониторинга данных. Чтобы понять, оправдывает ли он себя, потребуется несколько месяцев.
5. Скрытыми затратами хранения данных для Mastodon на S3 являются Requests. Запросов так много! Я наблюдаю по сорок-пятьдесят тысяч запросов в день! В основном это запросы PUT, а запросов GET в день происходит меньше двух тысяч. Поначалу это меня удивило, но разобравшись, как работает Mastodon, я понял, что это логично. Думаю, это во многом связано с настроенным мной Relay ^[11] и количеством аккаунтов и меток, на которые я подписан, но за этим определённо стоит следить и глубже изучать. Пока я настроил Amazon S3 Storage Lens ^[12] с расширенной конфигурацией, что позволило мне с лёгкостью исследовать аспекты активности моих данных в S3.

В целом мои затраты на хранение в S3 за первые 30 дней составили $9. Это чуть больше, чем я ожидал, и мне кажется, наверняка существуют возможности снизить эти затраты в последующих месяцах. Я передаю все свои ресурсы через Amazon CloudFront ^[13], имеющий щедрый бесплатный тариф ^[14], который пока ничего мне не стоил.

▍ Бюджеты и неожиданные расходы

В дальнейшем я планирую контролировать всё при помощи AWS Budgets ^[15].

Если вы поддерживаете собственный сервер Mastodon на AWS (да и вообще что угодно на AWS), то сделайте себе одолжение и обратите внимание на AWS Budgets, настроив его под себя. Там можно настраивать различные пороговые показатели для отправки алертов на электронную почту в случае превышения бюджета на месяц. Мои настройки достаточно просты. Я установил бюджет $50 в месяц с алертом на 50% ($25), чтобы как только я потрачу $25, мне приходил алерт по почте.

На самом деле, это чуть расточительнее, чем мне бы хотелось. В идеале я бы хотел, чтобы затраты были меньше $20 (и в течение этого года так и будет, потому что пока я нахожусь для своего сервера на бесплатном тарифе). Это можно сделать, урезав хранение данных в S3 и снизив количество снэпшотов EBS Snapshots или изменив принцип их создания. Но пока на несколько месяцев я оставлю всё как есть, чтобы получить больше данных для анализа, прежде чем вносить новые изменения.

В идеальном мире было бы здорово, если бы затраты на всё это суммарно не превышали $25 в месяц. Это не сильно дороже, чем синяя галочка Twitter Blue!