VPS для Telegram-бота

Намного меньше, чем обычно продают. Бот это долгоживущий процесс, который почти всё время ждёт: бот без состояния, отвечающий на команды, занимает около 60 MB, а бот с ORM, планировщиком и кешем ближе к 150 MB. После того как операционная система заберёт свои примерно 300 MB, на машине с 1 GB остаётся место для 4 тяжёлых ботов или 12 лёгких. Число ПОЛЬЗОВАТЕЛЕЙ почти не влияет, потому что Telegram доставляет обновления вашему процессу по одному, а не открывает соединение на каждого пользователя. Ответ меняет то состояние, которое вы сами держите в памяти: большой кеш, встроенная в процесс база данных, модель.

Для начала long polling, webhook тогда, когда это важно. При long polling бот сам открывает исходящее соединение к Telegram и ждёт: ему не нужны ни домен, ни сертификат, ни открытый порт, поэтому он работает за NAT, и это самый быстрый способ что-то запустить. При webhook Telegram подключается к ВАМ, поэтому нужен публичный адрес, действительный TLS-сертификат и открытый в интернет порт, а взамен полностью исчезает цикл опроса, и бот лучше масштабируется, когда он действительно загружен. Оба варианта нормально работают на самой маленькой машине из списка. Честная причина перейти: нагрузка или задержка, а не мода.

Это ограничения Telegram, а не наши: бот на публичном Bot API может скачивать файлы до 20 MB и загружать до 50 MB. Собственный сервер Bot API поднимает лимит до 2 GB и, что важнее, файлы оказываются на диске вашего сервера, а не проходят через Telegram. Это единственное изменение, которое действительно меняет требования к машине: внезапно становятся важны диск и трафик, поэтому в таблице выше BD-8 стоит напротив этой строки, а не других.

Текстовый бот: никогда. Медиабот: возможно, и тут стоит потратить тридцать секунд на арифметику: средний размер файла × сообщений в день × 30. Пятьдесят тысяч голосовых сообщений в день по 3 MB дают около 4.3 TB в месяц. Это больше лимита большинства дешёвых тарифов и намного меньше 32 TB на BD-8, а на линейке без учёта трафика такой вопрос вообще не возникает. Считаются оба направления: и файл, который бот получает, и файл, который он отправляет, это трафик.

Юнит systemd, а не сессия screen. Напишите небольшой файл службы с Restart=always, включите его, и бот будет подниматься после сбоя и после перезагрузки, даже если вы спите. Это самая распространённая причина, по которой бот на VPS «падает», и это не проблема хостинга: процесс, запущенный вручную, умирает вместе с SSH-сессией, из которой его запустили. Docker с политикой перезапуска делает то же самое, если вам удобнее упаковать бот так.

Да, и большинству так и стоит делать. Каждый бот это отдельный процесс со своим юнитом systemd и своим токеном; у них общие машина и, если хотите, база данных, и больше ничего. Арифметика в таблице отвечает ровно на этот вопрос: машина с 4 GB вмещает 25 тяжёлых ботов, прежде чем память станет ограничением. Если боты для разных людей, держите их на разных портах и под разными пользователями.

Где угодно, куда могут дотянуться ваши пользователи и где задержка до Telegram разумная. Бот общается с инфраструктурой Telegram, а не напрямую с пользователями, поэтому привычное правило «ближе к аудитории» здесь значит меньше, чем для сайта. Если бот также отдаёт этим же пользователям веб-панель или API, выбирайте регион под них. Если сомневаетесь, разверните сервер почасово в двух регионах, измерьте и удалите проигравший: при $0.0113 в час это дешёвый эксперимент.