Un VPS pour un bot Telegram

Bien moins qu’on ne le vend habituellement. Un bot est un processus de longue durée qui passe presque tout son temps à attendre : un bot de commandes sans état occupe environ 60 MB, et un bot avec un ORM, un planificateur et un cache plutôt 150 MB. Une fois que le système d’exploitation a pris ses 300 MB environ, une machine de 1 GB a encore de la place pour 4 bots lourds ou 12 bots légers. Le nombre d’UTILISATEURS n’y change presque rien, car Telegram transmet les mises à jour une par une à votre processus, et non par une connexion par utilisateur. Ce qui change la réponse, c’est l’état que vous gardez vous-même en mémoire : un gros cache, une base de données dans le processus, un modèle.

Le long polling pour commencer, les webhooks quand cela compte. Avec le long polling, votre bot ouvre une connexion sortante vers Telegram et attend : il n’a besoin ni de domaine, ni de certificat, ni de port ouvert, ce qui lui permet de fonctionner derrière un NAT et en fait le moyen le plus rapide de démarrer. Avec un webhook, c’est Telegram qui se connecte à VOUS : il faut donc une adresse publique, un certificat TLS valide et un port ouvert sur Internet ; en échange, la boucle de polling disparaît entièrement et la montée en charge est meilleure quand le bot est réellement sollicité. Les deux fonctionnent bien sur la plus petite machine proposée ici. La vraie raison de changer, c’est la charge ou la latence, pas la mode.

Ce sont les limites de Telegram, pas les nôtres : un bot qui utilise la Bot API publique peut télécharger des fichiers jusqu’à 20 MB et en envoyer jusqu’à 50 MB. Faire tourner votre propre serveur Bot API porte cette limite à 2 GB et, surtout, fait arriver les fichiers sur le disque de votre serveur au lieu de passer par celui de Telegram. C’est le seul changement qui modifie réellement la machine dont vous avez besoin : le disque et le transfert comptent soudain, et c’est pourquoi le tableau ci-dessus place BD-8 face à cette ligne et non face aux autres.

Un bot texte, jamais. Un bot multimédia, peut-être, et cela vaut trente secondes de calcul : taille moyenne des fichiers × messages par jour × 30. Cinquante mille notes vocales par jour à 3 MB représentent environ 4.3 TB par mois, au-delà du forfait de la plupart des offres bon marché et bien loin des 32 TB de BD-8, ou de la gamme Unmetered, où la question ne se pose pas. Les deux sens comptent : un fichier reçu par votre bot et un fichier qu’il envoie sont tous deux du trafic.

Une unité systemd, pas une session screen. Écrivez un petit fichier de service avec Restart=always, activez-le, et le bot redémarre après un plantage et après un reboot sans que vous ayez à être réveillé. C’est la raison la plus fréquente pour laquelle un bot « tombe » sur un VPS, et ce n’est pas un problème d’hébergement : un processus lancé à la main meurt avec la session SSH qui l’a lancé. Docker avec une politique de redémarrage fait le même travail si vous préférez l’empaqueter ainsi.

Oui, et c’est ce que la plupart des gens devraient faire. Chacun est un processus distinct avec sa propre unité systemd et son propre jeton ; ils partagent la machine, la base de données si vous le souhaitez, et rien d’autre. Le calcul du tableau répond exactement à cette question : une machine de 4 GB accueille 25 bots lourds avant que la mémoire ne devienne la contrainte. Placez-les sur des ports et des utilisateurs distincts s’ils sont destinés à des personnes différentes.

N’importe où, tant que vos utilisateurs peuvent y accéder et que votre latence vers Telegram est raisonnable : le bot dialogue avec l’infrastructure de Telegram, pas directement avec vos utilisateurs, donc la règle habituelle « près de votre audience » compte moins ici que pour un site web. Si le bot sert aussi un tableau de bord web ou une API à ces mêmes utilisateurs, choisissez plutôt la région en fonction de cela. En cas de doute, déployez à l’heure dans deux régions, mesurez et supprimez celle qui perd : à $0.0113 de l’heure, l’expérience coûte peu.