Telegram 봇 운영을 위한 VPS

흔히 판매되는 것보다 훨씬 적습니다. 봇은 오래 실행되는 프로세스로 거의 모든 시간을 대기하며 보냅니다. 상태 없는 명령 봇은 약 60 MB, ORM·스케줄러·캐시를 갖춘 봇은 150 MB 안팎입니다. 운영 체제가 300 MB 정도를 사용한 뒤에도 1 GB 서버에는 무거운 봇 4개 또는 가벼운 봇 12개를 실행할 여유가 있습니다. 사용자 수는 거의 영향을 주지 않습니다. Telegram은 사용자마다 연결을 여는 것이 아니라 업데이트를 하나씩 프로세스에 전달하기 때문입니다. 결과를 바꾸는 것은 직접 메모리에 보관하는 상태, 즉 대용량 캐시, 프로세스 내 데이터베이스, 모델 등입니다.

처음에는 롱 폴링으로, 필요해지면 웹훅으로 전환하십시오. 롱 폴링에서는 봇이 Telegram으로 연결을 열고 대기합니다. 도메인, 인증서, 열린 포트가 필요 없으므로 NAT 뒤에서도 작동하며, 가장 빠르게 시작할 수 있는 방법입니다. 웹훅은 Telegram이 사용자 측으로 연결하므로 공개 주소, 유효한 TLS 인증서, 인터넷에 열린 포트가 필요합니다. 대신 폴링 루프가 완전히 사라지고 봇이 실제로 바쁠 때 확장성이 더 좋습니다. 두 방식 모두 이 페이지의 가장 작은 서버에서 문제없이 실행됩니다. 전환할 정당한 이유는 유행이 아니라 부하나 지연 시간입니다.

저희가 아니라 Telegram의 한도입니다: 공개 Bot API를 사용하는 봇은 최대 20 MB까지 파일을 다운로드하고 최대 50 MB까지 업로드할 수 있습니다. 자체 Bot API 서버를 운영하면 한도가 2 GB로 늘어나며, 더 중요한 점은 파일이 Telegram을 거쳐 가는 대신 서버 디스크에 저장된다는 것입니다. 이것이 필요한 서버를 실제로 바꾸는 유일한 변화입니다. 갑자기 디스크와 전송량이 중요해지므로, 위 표에서 다른 행이 아닌 이 행에 BD-8을 배치했습니다.

텍스트 봇이라면 절대 그럴 일이 없습니다. 미디어 봇이라면 그럴 수도 있으며, 30초만 계산해 볼 가치가 있습니다: 평균 파일 크기 × 하루 메시지 수 × 30. 3 MB짜리 음성 메시지를 하루 5만 개 처리하면 월 약 4.3 TB로, 대부분의 저가 플랜 허용량을 넘지만 BD-8의 32 TB에는 한참 못 미칩니다. 트래픽 미계량 라인이라면 이런 고민 자체가 필요 없습니다. 양방향 모두 집계됩니다. 봇이 받는 파일과 보내는 파일 모두 트래픽입니다.

screen 세션이 아니라 systemd 유닛을 사용하십시오. Restart=always를 넣은 간단한 서비스 파일을 작성하고 활성화하면, 봇이 충돌하거나 서버가 재부팅된 후에도 직접 대응하지 않아도 자동으로 다시 시작됩니다. 이는 VPS에서 봇이 "다운"되는 가장 흔한 원인이며 호스팅 문제가 아닙니다. 직접 실행한 프로세스는 그것을 실행한 SSH 세션이 끝나면 함께 종료됩니다. 컨테이너로 패키징하는 편을 선호한다면 재시작 정책을 설정한 Docker도 같은 역할을 합니다.

예, 그리고 대부분은 그렇게 하는 것이 좋습니다. 각 봇은 자체 systemd 유닛과 자체 토큰을 가진 별도 프로세스이며, 서버와 (원한다면) 데이터베이스만 공유하고 그 외에는 아무것도 공유하지 않습니다. 표의 계산이 바로 이 질문에 대한 답입니다. 4 GB 서버는 메모리가 제약이 되기 전까지 무거운 봇 25개를 실행할 수 있습니다. 서로 다른 사람을 위한 봇이라면 포트와 사용자를 분리하십시오.

사용자가 접근할 수 있고 Telegram까지의 지연 시간이 적당한 곳이라면 어디든 괜찮습니다. 봇은 사용자와 직접 통신하지 않고 Telegram 인프라와 통신하므로, 일반적인 "사용자와 가까운 곳" 원칙이 웹사이트보다 덜 중요합니다. 봇이 같은 사용자에게 웹 대시보드나 API도 제공한다면 그것을 기준으로 리전을 정하십시오. 확신이 없다면 두 개 리전에 시간 단위로 배포해 측정한 뒤, 결과가 나쁜 쪽을 삭제하십시오. 시간당 $0.0113이므로 저렴한 실험입니다.