VPS สำหรับบอตเทรด ควรดูอะไรบ้าง

สิ่งที่บอตซื้อขายต้องการจาก VPS

VPS สำหรับบอตซื้อขายควรพิจารณา 4 เรื่อง ได้แก่ กระบวนการกลับมาทำงานหรือไม่หลังหยุดทำงาน, เวลาของระบบถูกต้องหรือไม่, คีย์ API (application programming interface) ป้องกันการขโมยได้ดีเพียงใด และคุณจะทราบหรือไม่เมื่อบอตหยุดทำงาน ความเร็วโดยตรงมีความสำคัญน้อยกว่าปัจจัยเหล่านี้มากสำหรับบอตของผู้ใช้ทั่วไป เนื่องจากส่วนที่ช้าที่สุดในเส้นทางคำสั่งซื้อขายคือโบรกเกอร์และระยะทางไปยังโบรกเกอร์ ไม่ใช่โฮสต์ที่เรียกใช้ Python

คู่มือนี้เป็นแนวทางด้านวิศวกรรม เนื้อหานี้ไม่ใช่คำแนะนำทางการเงิน และไม่มีการกล่าวถึงกลยุทธ์ใด ๆ

Uptime คือวินัยในการรีสตาร์ท ไม่ใช่ตัวเลขบนหน้าเว็บขายของ

ข้อตกลงเรื่อง uptime ที่โฆษณานั้นแตกต่างกัน AWS ระบุไว้ที่อย่างน้อย 99.5 เปอร์เซ็นต์สำหรับ EC2 instance เดียว และ 99.99 เปอร์เซ็นต์สำหรับการปรับใช้ที่ผ่านเกณฑ์ในหลาย availability zone ข้อตกลงเหล่านั้นครอบคลุมถึงความพร้อมใช้งานของโครงสร้างพื้นฐาน ไม่ใช่สถานะสุขภาพของบอทของคุณ บอทอาจหยุดทำงานจาก unhandled exception, websocket ที่ไม่ยอมเชื่อมต่อใหม่ หรือ OOM (out of memory) killer ในขณะที่เซิร์ฟเวอร์ยังคงทำงานอยู่ตลอดเวลา ดังนั้นคำถามที่มีประโยชน์คือจะเกิดอะไรขึ้นในสิบวินาทีหลังจาก process ของคุณหยุดทำงาน

ให้รันบอทในฐานะ systemd service และปล่อยให้ระบบ init เป็นผู้จัดการการรีสตาร์ท ซึ่ง unit file สามารถทำหน้าที่นี้ได้

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 คือบรรทัดที่คนมักมองข้าม ค่าเริ่มต้นของ systemd อนุญาตให้เริ่มทำงานได้ 5 ครั้งใน 10 วินาที ซึ่งรวมถึงการเริ่มครั้งแรกและการเริ่มด้วยตนเอง การตั้งค่า manager สามารถกำหนดค่าทับค่าเริ่มต้นเหล่านี้ได้ การถึงขีดจำกัดจะทำให้การพยายามรีสตาร์ทอัตโนมัติหยุดลง แต่ unit สามารถเริ่มใหม่ได้ด้วยตนเอง หรือผ่าน timer หรือ socket หลังจากช่วงเวลาดังกล่าวผ่านไป การตั้งค่าเป็น 0 จะเป็นการปิดการจำกัดอัตรา เพื่อให้บอทที่ติดลูปการ crash ยังคงพยายามทำงานต่อไปแทนที่จะเงียบหายไป RestartSec=10 จะช่วยหยุดลูปดังกล่าวไม่ให้ส่งคำขอเชื่อมต่อซ้ำไปยัง exchange จนเกินไป

ตรวจสอบไฟล์ก่อนที่คุณจะใช้งานจริง จากนั้นจึงเริ่มการทำงาน:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable คือส่วนที่ยังคงอยู่หลังจากการรีบูต และการอัปเดต kernel หมายถึงการต้องรีบูต เพื่อดูว่าบอทได้หยุดทำงานไปอย่างเงียบๆ หรือไม่ ให้สอบถาม systemd เพื่อดูตัวนับการรีสตาร์ท:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 จะนับจำนวนงานรีสตาร์ทอัตโนมัติที่เกิดขึ้นนับตั้งแต่การรีเซ็ตตัวนับครั้งล่าสุด มันไม่ได้เป็นเครื่องพิสูจน์ว่าระบบมีสุขภาพดีหรือไม่มีการ crash ตลอดทั้งสัปดาห์ การรีสตาร์ทด้วยตนเองและ systemctl reset-failed จะรีเซ็ตตัวนับนี้ และบอทที่ค้างอยู่ก็อาจยังคงแสดงค่าเป็นศูนย์ได้ NRestarts=812 จะนับงานรีสตาร์ทไปแล้ว 812 ครั้ง ไม่ใช่จำนวนการเชื่อมต่อกับ exchange หรือการเทรดที่สำเร็จ และไม่ได้ระบุว่าเหตุการณ์เหล่านั้นเกิดขึ้นเมื่อใด ให้ตรวจสอบ journal เพื่อดูเวลาและสาเหตุ รวมถึงความล้มเหลวก่อนที่บอทจะเชื่อมต่อได้ โครงสร้างที่สมบูรณ์ของ unit file รวมถึง timer สำหรับงานตามกำหนดการ เช่น รายงานประจำวัน ได้อธิบายไว้ใน การรันโปรแกรมในฐานะ systemd service

ตั้งค่านาฬิกาเป็น UTC และตรวจสอบการซิงโครไนซ์

Exchange API ใช้การประทับเวลา (timestamp) เพื่อตรวจสอบความถูกต้องของคำขอที่มีการลงลายมือชื่อ โดย Binance Spot กำหนดค่า receive window เริ่มต้นไว้ที่ 5 วินาที และจะปฏิเสธการประทับเวลาที่เร็วกว่าเวลาของเซิร์ฟเวอร์ตั้งแต่ 1 วินาทีขึ้นไป นาฬิกาที่คลาดเคลื่อนจะทำให้เกิดข้อผิดพลาดที่ดูเหมือนความล้มเหลวในการยืนยันตัวตน ส่งผลให้ผู้ใช้งานเสียเวลาหมุนเวียนคีย์ (rotate keys) อยู่หลายชั่วโมงก่อนที่จะตรวจสอบเวลา สำหรับ API ในรูปแบบของ Binance ข้อความที่ได้รับจะเป็นไปตามตัวอักษรคือ Timestamp for this request was 1000ms ahead of the server's time

ตั้งค่าเซิร์ฟเวอร์ให้เป็น UTC เขตเวลาท้องถิ่นอาจทำให้เกิดการกระโดดของเวลาในช่วง Daylight Saving Time ในการแสดงผล แต่ Unix timestamp ที่ API ใช้จะไม่เปลี่ยนแปลงตามเขตเวลาที่แสดง

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu ใช้ chrony เป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 25.10 เป็นต้นไป ส่วนการติดตั้งรุ่นเก่าสามารถใช้ systemd-timesyncd ซึ่งเป็นไคลเอ็นต์ SNTP (Simple Network Time Protocol) ได้ โดย systemd-timesyncd จะทำหน้าที่ปรับนาฬิกา แต่ไม่สามารถดึงข้อมูลจากหลายเซิร์ฟเวอร์พร้อมกันเพื่อตรวจหาแหล่งเวลาที่ไม่ถูกต้องได้ ดังนั้นควรใช้ chrony แทน:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

บรรทัดที่ต้องอ่านจาก chronyc tracking คือ System time ตัวอย่างเช่น System time : 0.000031415 seconds fast of NTP time ค่าที่น้อยแสดงถึงการแก้ไขเวลาที่เหลืออยู่เพียงเล็กน้อยสำหรับนาฬิกา NTP ของ chrony ให้ตรวจสอบการซิงโครไนซ์ด้วย Root delay และ Root dispersion ก่อนที่จะตัดสินความแม่นยำ หากค่าที่อ่านได้คือ Leap status : Not synchronised แสดงว่า chrony ยังไม่ได้ซิงโครไนซ์ แม้ว่าเซิร์ฟเวอร์จะตอบกลับมาแล้วก็ตาม เนื่องจากค่าที่วัดได้อาจถูกปฏิเสธเพราะมีความแม่นยำไม่เพียงพอ ให้รอสักครู่แล้วตรวจสอบอีกครั้งก่อนที่จะไปแก้ไขกฎของไฟร์วอลล์

เก็บ API keys ให้ห่างจากจุดที่คุณคัดลอก

การรั่วไหลของ exchange key นั้นร้ายแรงกว่าการรั่วไหลของ SSH key เพราะสิทธิ์ในการถอนเงินจะเปลี่ยนให้มันกลายเป็นเงินสดได้ทันที นิสัยสองประการต่อไปนี้ช่วยลดความเสี่ยงได้เกือบทั้งหมด

ประการแรก อย่าให้สิทธิ์ในการถอนเงินแก่ bot key และหาก exchange รองรับ ให้ผูก key เข้ากับ IP address ของเซิร์ฟเวอร์ นี่คือมาตรการควบคุมเพียงอย่างเดียวที่ทำให้ key ที่ถูกขโมยไปแทบจะใช้งานไม่ได้

ประการที่สอง เก็บ secret ไว้ภายนอกไดเรกทอรีของโค้ด เพราะทุกสิ่งที่อยู่ภายใน /opt/tradingbot จะหลุดเข้าไปอยู่ใน git repository หรือไฟล์สำรองข้อมูลไม่ช้าก็เร็ว ให้เก็บไว้ในไฟล์ที่ root เป็นเจ้าของและ systemd สามารถอ่านได้แทน:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

ไฟล์นี้จะเก็บข้อมูลในรูปแบบ KEY=value โดยไม่มีเครื่องหมายคำพูดและไม่มี export การตั้งค่า mode 640 จะให้สิทธิ์ root ในการอ่าน/เขียน และให้สมาชิกของกลุ่ม bot มีสิทธิ์อ่าน โดยที่ผู้ใช้อื่นจะไม่มีสิทธิ์ใดๆ ให้ตรวจสอบด้วย sudo -u bot cat /etc/tradingbot/api.env จากนั้นทดสอบด้วยผู้ใช้ที่ไม่มีสิทธิ์ซึ่งอยู่นอกกลุ่ม bot ซึ่งจะต้องล้มเหลวด้วยข้อความ Permission denied

ตัว bot ไม่ควรทำงานในฐานะ root หรือในฐานะผู้ใช้ที่คุณล็อกอินอยู่ ให้สร้าง system account ที่ใช้ nologin shell และมี /var/lib/tradingbot เป็น home directory ก่อนที่จะเริ่ม service หรือสร้างไฟล์ที่กลุ่ม bot เป็นเจ้าของ:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

เหตุผลเบื้องหลังของแต่ละ flag เหล่านั้น และขอบเขตที่ ProtectSystem=strict ทำงานได้จริง อยู่ใน การรัน service ในฐานะผู้ใช้ที่ไม่มีสิทธิ์ ส่วนพื้นฐานอื่นๆ ของเซิร์ฟเวอร์ เช่น SSH keys และ firewall อยู่ใน สิบนาทีแรกบน VPS ใหม่

ตรวจพบว่าระบบล่มก่อนที่โบรกเกอร์ของคุณจะทราบ

systemctl status ระบุว่าโพรเซสกำลังทำงานอยู่ แต่ไม่ได้ยืนยันว่าบอทกำลังทำงานจริง โพรเซสที่ติดอยู่ในลูปการพยายามเชื่อมต่อใหม่ (retry loop) กับ websocket ที่ตายไปแล้ว ยังคงผ่านการตรวจสอบสถานะโพรเซสใน unit ด้านบนได้

ให้ใช้ heartbeat แทน Uptime Kuma มีฟีเจอร์ push monitors ซึ่งจะรอรับการเรียก URL จากบอทของคุณตามกำหนดเวลา และจะแจ้งเตือนเมื่อไม่มีการเรียกเข้ามา ให้ใส่การเรียกนี้ไว้ที่ท้ายลูปหลักของโปรแกรม หลังจากส่วนที่ยืนยันว่าบอททำงานปกติแล้ว เช่น หลังจากอ่านข้อมูลตลาดสำเร็จ

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

ตั้งค่าช่วงเวลาการตรวจสอบ (monitor interval) ให้เป็นประมาณ 2 เท่าของเวลาที่ใช้ในลูป เพื่อป้องกันการแจ้งเตือนที่เกิดจากความล่าช้าเล็กน้อย (jitter) ตามปกติ ให้รันตัวตรวจสอบบนเซิร์ฟเวอร์แยกต่างหากจากตัวบอท เพราะหากตัวตรวจสอบตายไปพร้อมกับสิ่งที่มันเฝ้าดูอยู่ คุณจะไม่ได้รับรายงานใดๆ การตั้งค่าครอบคลุมอยู่ใน การทำ self-hosted status monitoring ด้วย Uptime Kuma

ควรเพิ่มการแจ้งเตือนพื้นที่ดิสก์ด้วย บอทที่เขียน log อย่างละเอียดจะทำให้ root filesystem เต็มภายในไม่กี่สัปดาห์ และเมื่อดิสก์เต็มจะทำให้การเขียนฐานข้อมูลหยุดลง แต่การเรียกเครือข่ายอาจยังทำงานอยู่ ทำให้เกิดอาการที่ผิดปกติ journalctl --vacuum-time=14d และบรรทัด SystemMaxUse= ใน /etc/systemd/journald.conf จะช่วยจำกัดขนาดของ journal ไม่ให้ใหญ่เกินไป

ความจริงที่ต้องยอมรับ: ความหน่วงส่วนใหญ่ไม่ได้มาจากโฮสต์ของคุณ

นี่คือจุดที่ตลาดผลิตภัณฑ์ VPS สำหรับการเทรดไม่ได้เป็นเรื่องทางเทคนิคอีกต่อไป หน้าเว็บโฆษณามักอ้างตัวเลขความหน่วงระดับต่ำกว่ามิลลิวินาทีและทำให้เข้าใจว่าโฮสต์คือปัจจัยชี้ขาดระหว่างคุณกับการส่งคำสั่งซื้อขายสำเร็จ สำหรับบอทเทรดรายย่อยเกือบทั้งหมด ความจริงไม่ใช่เช่นนั้น

คำสั่งซื้อของคุณเดินทางจากบอทไปยังปลายทางของตลาดหลักทรัพย์หรือโบรกเกอร์ผ่านอินเทอร์เน็ตสาธารณะ เส้นทางดังกล่าวถูกกำหนดโดยระยะทางทางกายภาพและการเชื่อมต่อระหว่างผู้ให้บริการของคุณกับผู้ให้บริการของพวกเขา จากนั้นระบบของโบรกเกอร์เองจะเพิ่มคิว การตรวจสอบความเสี่ยง และการจำกัดอัตราการส่งคำสั่ง (rate limits) เข้าไป

จงวัดค่าแทนการคาดเดา curl จะรายงานเวลาการเชื่อมต่อและเวลาที่ได้รับไบต์แรกสำหรับปลายทางจริง:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

ให้รันคำสั่งดังกล่าวจากเซิร์ฟเวอร์ที่คุณสนใจก่อนตัดสินใจเลือก หาก connect มีค่า 0.180 วินาที ค่านี้จะรวมถึงการทำ DNS resolution และการเชื่อมต่อ TCP ซึ่งไม่ได้ระบุว่าคุณอยู่ในทวีปใด หาก connect มีค่า 0.004 วินาที และ ttfb มีค่า 0.140 วินาที ผลต่างที่เกิดขึ้นจะรวมถึงการตั้งค่า TLS, การส่งคำขอ, ความล่าช้าของเครือข่าย และการประมวลผลของเซิร์ฟเวอร์ การเปลี่ยนโฮสต์อาจส่งผลต่อองค์ประกอบบางส่วนเหล่านี้ ดังนั้นควรเปรียบเทียบค่าที่วัดได้จากตำแหน่งที่ตั้งต่างๆ ที่คุณพิจารณา

แล้วโฮสต์มีความสำคัญเมื่อใด? เมื่อคุณทำ colocation หรือเชื่อมต่อโดยตรงกับสถานที่ตั้งของตลาดและต้องแข่งขันกันที่ลำดับคิว ซึ่งเป็นธุรกิจที่แตกต่างและมีงบประมาณที่ต่างออกไป และเมื่อโค้ดของคุณเองคือคอขวด: บอทที่คำนวณตัวชี้วัดใหม่จากประวัติทั้งหมดในทุกๆ tick อาจใช้เวลา CPU ถึง 200 มิลลิวินาทีต่อรอบ ซึ่งเป็นความหน่วงจริงที่คุณสามารถควบคุมได้โดยไม่ต้องเสียค่าใช้จ่ายเพิ่ม จงทำ profiling ลูปการทำงานก่อนที่จะเลือกซื้อเซิร์ฟเวอร์ที่เร็วขึ้น

สิ่งที่สำคัญจริงสำหรับโฮสต์ที่คุณเลือกคือภูมิศาสตร์, เครือข่ายที่เสถียร, และหน่วยความจำที่เพียงพอจน OOM killer ไม่มีโอกาสได้ทำงาน ให้เพิ่มหน่วยความจำหากคุณเก็บประวัติ tick ไว้ในฐานข้อมูลภายในเครื่อง

รายการตรวจสอบสั้นๆ ก่อนเริ่มใช้งานจริง

1. systemctl is-enabled tradingbot แสดงผล enabled และบริการยังคงทำงานได้ปกติหลังจาก sudo reboot
2. chronyc tracking รายงานสถานะการซิงโครไนซ์ โดยมีค่าความคลาดเคลื่อนของเวลาในระบบต่ำกว่าไม่กี่มิลลิวินาที และมีค่า root delay กับ dispersion อยู่ภายในงบประมาณเวลาที่กำหนด
3. API key มีสิทธิ์ในการเทรด แต่ไม่มีสิทธิ์ในการถอนเงิน และมีการตั้งค่า IP allowlist หากกระดานเทรดรองรับ
4. การหยุดกระบวนการทำงานด้วย sudo systemctl kill -s SIGKILL tradingbot จะทำให้ระบบกลับมาทำงานใหม่ได้หลังจากผ่านช่วงเวลาหน่วง RestartSec และเวลาในการเริ่มต้นระบบ
5. ระบบ heartbeat monitor จะแจ้งเตือนคุณหลังจากครบช่วงเวลาที่กำหนด และจะพยายามเชื่อมต่อใหม่เมื่อคุณหยุดการทำงานของบอทโดยเจตนา
6. มีการจำกัดขนาดของ log และระบบไฟล์ root ยังมีพื้นที่ว่างเพียงพอใน df -h

ให้รันระบบทั้งหมดในสภาพแวดล้อม sandbox ของกระดานเทรดหรือในโหมดจำลอง (paper mode) เป็นเวลา 1 สัปดาห์ก่อนที่จะใช้เงินจริง ทุกรายการข้างต้นจะล้มเหลวอย่างน้อยหนึ่งครั้งในช่วงสัปดาห์นั้น ซึ่งนั่นคือจุดประสงค์ของการทดสอบตลอดทั้งสัปดาห์นี้

FAQ

บอทเทรดจำเป็นต้องใช้เซิร์ฟเวอร์ที่มีความหน่วงต่ำ (low-latency) หรือ bare metal หรือไม่?

จำเป็นก็ต่อเมื่อคุณต้องแข่งขันด้านความเร็วในการส่งคำสั่งกับผู้เล่นอัตโนมัติรายอื่นในตลาดเดียวกัน ซึ่งโดยปกติแล้วหมายถึงการทำ colocation ไม่ใช่การใช้ VPS ทั่วไป สำหรับบอทรายย่อย ระยะเวลาการรับส่งข้อมูล (round trip) ส่วนใหญ่ขึ้นอยู่กับตำแหน่งทางภูมิศาสตร์และการประมวลผลของโบรกเกอร์ ดังนั้นให้เลือกเซิร์ฟเวอร์ที่อยู่ใกล้กับ API endpoint และวัดผลด้วย curl และ mtr ก่อนที่จะตัดสินใจจ่ายเงินเพื่อบริการที่เร็วขึ้น

บอทเทรดต้องการ RAM และ CPU มากน้อยเพียงใด?

บอทส่วนใหญ่ที่รันกลยุทธ์เดียวมักถูกจำกัดด้วยความเร็วเครือข่ายและมักจะว่างงานระหว่างรอเหตุการณ์ หน่วยความจำจะกลายเป็นข้อจำกัดเมื่อคุณเก็บประวัติราคา (tick history) ไว้ในหน่วยความจำหรือรันฐานข้อมูลในเครื่อง ดังนั้นให้เฝ้าดู free -h และตรวจสอบ log เพื่อหาข้อความ OOM kill แทนการคาดเดาเอาเอง

ทำไม API ของตลาดแลกเปลี่ยนถึงปฏิเสธคำขอของฉันด้วยข้อผิดพลาดเรื่อง timestamp?

เนื่องจาก timestamp ของคำขออยู่นอกช่วงเวลาที่ตลาดแลกเปลี่ยนยอมรับ ซึ่งเกิดได้จากทั้งความคลาดเคลื่อนของเวลา (clock drift) และความล่าช้าในการส่งคำขอ ให้ติดตั้ง chrony ตรวจสอบว่า chronyc tracking แสดงค่า System time offset ที่น้อยและสถานะ leap เป็นแบบ synchronised รวมถึงตรวจสอบค่า root delay และ dispersion ด้วย การตั้งค่าเครื่องเป็น UTC ช่วยให้เวลาที่แสดงผลสอดคล้องกัน แต่ไม่ได้ช่วยแก้ไขปัญหา clock drift และการเปลี่ยน API key ใหม่ก็ไม่สามารถแก้ปัญหาเรื่องเวลาได้

ฉันจะป้องกันไม่ให้บอทหยุดทำงานในตอนกลางคืนโดยที่ฉันไม่รู้ได้อย่างไร?

ให้รันบอทภายใต้ systemd โดยใช้ Restart=always และ StartLimitIntervalSec=0 เพื่อให้ระบบพยายามเริ่มการทำงานใหม่หากเกิด crash loop แทนที่จะติดขัดจนเกินขีดจำกัดการเริ่มทำงาน (start rate limit) จากนั้นให้เพิ่มระบบ heartbeat ที่บอทจะส่งสัญญาณออกมาเมื่อจบการทำงานในแต่ละรอบที่สำเร็จ การ restart จะช่วยจัดการเรื่องตัว process ส่วน heartbeat จะช่วยตรวจจับในกรณีที่ process ยังทำงานอยู่แต่เกิดการค้าง

ฉันสามารถรันบอทและระบบตรวจสอบ (monitoring) บน VPS เดียวกันได้หรือไม่?

คุณสามารถทำได้ แต่ระบบตรวจสอบจะให้ข้อมูลที่เชื่อถือไม่ได้ในวันที่เกิดปัญหาจริง เพราะหากเกิดเหตุขัดข้องที่ทำให้บอทหยุดทำงาน ระบบตรวจสอบก็จะหยุดทำงานไปด้วย ให้แยกการแจ้งเตือนไว้บนเครื่องอื่น โดยควรเป็นผู้ให้บริการหรือภูมิภาคที่ต่างออกไป และใช้เซิร์ฟเวอร์ของบอทสำหรับรันบอทและเก็บ log เท่านั้น