Telegram ボット向けの VPS

一般に販売されている量よりはるかに少なくて済みます。ボットはほとんどの時間を待機に費やす常駐プロセスです。ステートレスなコマンドボットは約 60 MB、ORM・スケジューラー・キャッシュを備えたボットは 150 MB 程度です。オペレーティングシステムが約 300 MB を使用した後でも、1 GB のマシンには重いボット 4 個、または軽いボット 12 個を動かす余裕があります。ユーザー数はほとんど影響しません。Telegram はユーザーごとに接続するのではなく、更新を 1 件ずつプロセスに届けるためです。答えを変えるのは、お客様自身がメモリに保持する状態（大きなキャッシュ、プロセス内データベース、モデルなど）です。

最初はロングポーリング、必要になったら Webhook です。ロングポーリングでは、ボットが Telegram への接続を開いて待機します。ドメインも証明書も開放ポートも不要なので、NAT の内側でも動作し、最も早く稼働させられる方法です。Webhook では Telegram がお客様に接続するため、パブリックアドレス、有効な TLS 証明書、インターネットに開放されたポートが必要です。その代わりにポーリングループが完全になくなり、ボットが本当に忙しいときによりスケールします。どちらもここにある最小のマシンで問題なく動作します。移行する正当な理由は負荷やレイテンシーであり、流行ではありません。

これは当社ではなく Telegram 側の制限です。公開 Bot API を使う bot は、ダウンロードが最大 20 MB、アップロードが最大 50 MB です。独自の Bot API サーバーを運用するとこれが 2 GB に引き上げられ、さらに重要な点として、ファイルは Telegram のディスクを経由するのではなく、お使いのサーバーのディスクに保存されます。必要なマシンを実際に変えるのはこの一点だけです。急にディスクと転送量が重要になるため、上の比較表ではこの行にだけ BD-8 を割り当てています。

テキストボットであれば、決してありません。メディアボットであれば可能性があり、30 秒の計算をする価値があります：平均ファイルサイズ × 1 日のメッセージ数 × 30。1 日 5 万件の 3 MB のボイスメッセージは月に約 4.3 TB となり、多くの安価なプランの転送量枠を超えますが、BD-8 の 32 TB には遠く及びません。また、Unmetered ラインではこの問題自体が生じません。送受信の両方が計上されます。ボットが受信するファイルも送信するファイルも転送量です。

screen セッションではなく systemd ユニットを使います。Restart=always を指定した小さなサービスファイルを作成して有効にすれば、クラッシュ後も再起動後も、お客様が起きていなくてもボットは復帰します。これは VPS でボットが「停止する」最も一般的な理由であり、ホスティングの問題ではありません。手動で起動したプロセスは、起動元の SSH セッションとともに終了します。その形でパッケージ化したい場合は、再起動ポリシーを設定した Docker でも同じことができます。

はい。多くの方はそうすべきです。各 bot は独自の systemd ユニットと独自のトークンを持つ別プロセスで、共有するのはマシンと、必要であればデータベースだけです。比較表の計算はまさにこの問いへの答えです。4 GB のマシンは、メモリが制約になるまでに重い bot を 25 個収容できます。別々の人向けの bot であれば、ポートとユーザーを分けてください。

ユーザーがアクセスでき、Telegram へのレイテンシーが妥当な場所であればどこでも構いません。ボットはユーザーと直接ではなく Telegram のインフラと通信するため、通常の「利用者の近くに」という原則はウェブサイトほど重要ではありません。ボットが同じユーザーにウェブダッシュボードや API も提供する場合は、そちらに合わせて地域を選んでください。迷う場合は、二つのリージョンで時間単位でデプロイして測定し、劣るほうを削除してください。1 時間あたり $0.0113 なので、安価に試せます。