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

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

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

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

ความพร้อมใช้งานคือวินัยในการเริ่มบริการใหม่ ไม่ใช่ตัวเลขบนหน้าขาย

โฮสต์ทุกเครื่องทั่วโลกโฆษณาความพร้อมใช้งาน 99.9 เปอร์เซ็นต์ ตัวเลขนี้อธิบาย hypervisor ไม่ใช่ bot ของคุณ bot หยุดทำงานได้จากข้อยกเว้นที่ไม่ได้จัดการ, websocket ที่ไม่เชื่อมต่อใหม่, หรือ OOM (out of memory) killer ขณะที่เซิร์ฟเวอร์ยังทำงานอยู่ตลอด ดังนั้นคำถามที่มีประโยชน์คือ หลังจาก process ของคุณสิ้นสุดลง 10 วินาทีจะเกิดอะไรขึ้น

เรียกใช้ bot เป็นบริการ systemd และให้ระบบ init เป็นผู้จัดการการเริ่มบริการใหม่ ไฟล์ unit ทำเช่นนี้ได้ใน 6 บรรทัด

[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 วินาที และปล่อยให้ unit อยู่ในสถานะ failed ตลอดไป ซึ่งเป็นพฤติกรรมที่คุณไม่ต้องการให้เกิดขึ้นในเวลา 03:00 การตั้งค่าเป็น 0 จะปิดการจำกัดอัตรา ดังนั้น bot ที่ crash-loop จะพยายามทำงานต่อแทนที่จะหยุดทำงานเงียบ ๆ 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 คือส่วนที่ทำให้บริการยังทำงานหลัง reboot และ kernel updates หมายถึงต้อง reboot หากต้องการตรวจสอบว่า bot หยุดทำงานเงียบ ๆ หรือไม่ ให้ขอค่า restart counter จาก systemd:

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

NRestarts=0 หลังผ่านไป 1 สัปดาห์หมายถึง bot ทำงานได้ดี NRestarts=812 หมายความว่าคุณทำการซื้อขายโดยใช้ process ที่เชื่อมต่อใหม่ตลอดทั้งคืน รายละเอียดโครงสร้างของ unit file ทั้งหมด รวมถึง timers สำหรับงานตามกำหนดเวลา เช่น รายงานประจำวัน อธิบายไว้ใน การเรียกใช้โปรแกรมเป็นบริการ systemd

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

Exchange API จะลงลายมือชื่อคำขอด้วย timestamp และปฏิเสธคำขอที่อยู่นอกช่วงเวลาที่กำหนด ซึ่งมักอยู่ที่ 5 วินาทีหรือน้อยกว่า นาฬิกาที่คลาดเคลื่อนทำให้เกิดข้อผิดพลาดที่ดูเหมือนปัญหาการยืนยันตัวตน ผู้ดูแลระบบจึงเปลี่ยน key อยู่นานหลายชั่วโมงก่อนตรวจสอบเวลา สำหรับ API รูปแบบ Binance ข้อความจะแจ้งอย่างตรงไปตรงมาว่า Timestamp for this request was 1000ms ahead of the server's time

ตั้งค่า server เป็น UTC เขตเวลาท้องถิ่นอาจทำให้เวลาเปลี่ยนแบบ daylight saving และการเปลี่ยนนี้อาจเกิดขึ้นระหว่างช่วงการซื้อขาย

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu มาพร้อมกับ systemd-timesyncd ซึ่งเป็นไคลเอ็นต์ SNTP (simple network time protocol) เหมาะสำหรับ log แต่ไม่เหมาะกับงานที่ต้องรักษาความคลาดเคลื่อนให้อยู่ภายในไม่กี่มิลลิวินาที เนื่องจากจะสอบถาม server เพียงเครื่องเดียวและไม่ปรับเทียบ clock อย่างต่อเนื่อง ให้ใช้ 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 ค่าที่ต่ำกว่าไม่กี่มิลลิวินาทีถือว่าปกติ หากแสดง Leap status : Not synchronised แสดงว่า chrony ยังเชื่อมต่อ server ไม่สำเร็จ โดยมักเกิดจาก outbound UDP 123 ถูกบล็อก ให้รอ 1 นาที แล้วตรวจสอบอีกครั้งก่อนแก้ไขกฎ firewall

API key ควรอยู่นอกตำแหน่งที่คุณคัดลอก

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

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

ข้อสอง เก็บ secret ไว้นอกไดเรกทอรีของโค้ด ทุกอย่างภายใน /opt/tradingbot จะลงเอยใน git repository หรือ backup archive ในที่สุด ให้เก็บไว้ในไฟล์ที่ 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 โหมด 640 และกลุ่ม bot หมายความว่า service user สามารถอ่านไฟล์ได้ และผู้ใช้อื่นไม่สามารถอ่านได้ ตรวจสอบด้วย sudo -u bot cat /etc/tradingbot/api.env จากนั้นตรวจสอบด้วยผู้ใช้อื่น ซึ่งต้องล้มเหลวด้วย Permission denied

บอตไม่ควรทำงานในฐานะ root หรือผู้ใช้ที่คุณใช้เข้าสู่ระบบ ให้สร้าง system account ที่ไม่มี shell และไม่มี home directory สำหรับเข้าสู่ระบบ:

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

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

ตรวจสอบให้ทราบเมื่อระบบหยุดทำงานก่อนโบรกเกอร์ของคุณ

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

ให้ใช้ heartbeat แทน Uptime Kuma มี push monitors โดยคาดว่า bot จะเรียก URL ตามกำหนดเวลา และจะแจ้งเตือนเมื่อไม่มีการเรียกเข้ามาอีก ให้ใส่การเรียกนี้ไว้ท้าย main loop หลังส่วนที่ยืนยันว่า bot ยังทำงานอยู่ เช่น การอ่านข้อมูลตลาดสำเร็จ

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

ตั้งค่า interval ของ monitor ให้ยาวประมาณ 2 เท่าของเวลาที่ใช้ใน loop เพื่อไม่ให้ jitter ตามปกติทำให้เกิดการแจ้งเตือน เรียกใช้ monitor บนเซิร์ฟเวอร์คนละเครื่องกับ bot เพราะหาก monitor หยุดทำงานพร้อมกับสิ่งที่เฝ้าดู ก็จะไม่รายงานอะไร การตั้งค่ามีอธิบายไว้ใน การตรวจสอบสถานะที่โฮสต์เองด้วย Uptime Kuma

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

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

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

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

ให้วัดผลแทนการคาดเดา 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 วินาที แสดงว่าเซิร์ฟเวอร์อยู่ผิดทวีป และควรแก้ไข หาก connect มีค่า 0.004 วินาที และ ttfb มีค่า 0.140 วินาที ความล่าช้าที่เหลือเกิดจากการประมวลผลของนายหน้า การเปลี่ยนเซิร์ฟเวอร์จะไม่ช่วยลดความล่าช้าส่วนนี้

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

สิ่งที่สำคัญสำหรับเซิร์ฟเวอร์ที่คุณเลือกคือทำเลที่ตั้ง เครือข่ายที่เสถียร และหน่วยความจำที่เพียงพอเพื่อไม่ให้ OOM killer มีโอกาสทำงาน ณ เดือน July 2026 บอต Python ที่ใช้กลยุทธ์เดียวและเก็บข้อมูลของ symbols จำนวนไม่กี่ร้อยรายการไว้ในหน่วยความจำ สามารถทำงานได้อย่างเหมาะสมบน 2 GB ของ RAM และ 2 vCPU หากเก็บประวัติ tick ไว้ในฐานข้อมูลภายในเครื่อง ให้เพิ่มหน่วยความจำ

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

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

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

FAQ

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

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

บอทเทรดต้องใช้ RAM และ CPU เท่าใด

บอทที่ใช้กลยุทธ์เดียวส่วนใหญ่ใช้เครือข่ายเป็นข้อจำกัดหลัก และจะอยู่ในสถานะว่างระหว่างเหตุการณ์ต่าง ๆ ณ เดือน July 2026, 2 vCPU และ RAM 2 GB เพียงพอสำหรับบอท Python ที่ติดตามตราสารไม่กี่ร้อยรายการ หน่วยความจำจะกลายเป็นข้อจำกัดเมื่อคุณเก็บประวัติ tick ไว้ในโปรเซสหรือใช้งานฐานข้อมูลภายในเครื่อง ดังนั้นให้ตรวจสอบ free -h และ journal เพื่อหาข้อความ OOM kill แทนการคาดเดา

เหตุใด exchange API จึงปฏิเสธคำขอพร้อมข้อผิดพลาดเกี่ยวกับ timestamp

นาฬิกาของเซิร์ฟเวอร์คลาดเคลื่อนเกินช่วงเวลาที่ exchange อนุญาตสำหรับการลงลายเซ็น โดยปกติคลาดเคลื่อนไม่กี่วินาที ติดตั้ง chrony ตรวจสอบว่า chronyc tracking แสดงค่าออฟเซ็ต System time ขนาดเล็กและสถานะ leap ที่ซิงโครไนซ์แล้ว และตั้งค่าเครื่องเป็น UTC เพื่อไม่ให้การเปลี่ยนเวลาออมแสงทำให้เวลาเคลื่อน การหมุนเวียน API key ไม่สามารถแก้ปัญหานาฬิกาได้

จะหยุดไม่ให้บอทหยุดทำงานข้ามคืนโดยที่ฉันไม่ทราบได้อย่างไร

ให้เรียกใช้บอทภายใต้ systemd พร้อม Restart=always และ StartLimitIntervalSec=0 เพื่อให้การหยุดทำงานเป็นวงจรยังคงพยายามเริ่มใหม่แทนที่จะหยุดถาวร จากนั้นเพิ่ม heartbeat ที่บอทส่งเมื่อจบรอบการทำงานที่สำเร็จแต่ละรอบ การเริ่มใหม่จะจัดการกรณีที่โปรเซสหยุดทำงาน ส่วน heartbeat จะตรวจจับกรณีที่โปรเซสยังทำงานอยู่แต่ติดค้าง

สามารถเรียกใช้บอทและระบบ monitoring บน VPS เดียวกันได้หรือไม่

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