Trading bot కోసం VPS ఎంచుకోవడంలో నిజంగా ముఖ్యమైనవి

ట్రేడింగ్ bot కు VPS నుంచి అవసరమైనవి

ట్రేడింగ్ bot కోసం VPS ను నాలుగు అంశాల ఆధారంగా అంచనా వేస్తారు: process ఆగిపోయిన తర్వాత తిరిగి ప్రారంభమవుతుందా, clock సరిగ్గా ఉందా, API (application programming interface) keys ను దొంగిలించడం కష్టమా, అది ఆగిపోయినప్పుడు మీకు తెలుస్తుందా. Retail bot కోసం raw speed ఈ జాబితాలో చాలా దిగువన ఉంటుంది. కారణం, మీ order path లో నెమ్మదైన భాగం broker మరియు దానికి ఉన్న network దూరం; మీ Python ను నడుపుతున్న host కాదు.

ఇది engineering guide. ఇందులోని సమాచారం financial advice కాదు. ఏ strategy గురించీ చర్చించలేదు.

Uptime అంటే sales pageలోని సంఖ్య కాదు, restart క్రమశిక్షణ

ప్రపంచంలోని ప్రతి host 99.9 percent uptimeను ప్రకటిస్తుంది. ఆ సంఖ్య hypervisorను సూచిస్తుంది, మీ botను కాదు. Unhandled exception, మళ్లీ connect కాని websocket లేదా OOM (out of memory) killer వల్ల bot ఆగిపోవచ్చు. ఆ సమయంలో server మొత్తం సమయం పనిచేస్తూనే ఉంటుంది. కాబట్టి మీ process exit అయిన తర్వాతి పది సెకన్లలో ఏమి జరుగుతుందనేదే ఉపయోగకరమైన ప్రశ్న.

Botను systemd serviceగా అమలు చేయండి. Restart బాధ్యతను init systemకు అప్పగించండి. 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 10 సెకన్లలో 5 restarts తర్వాత ప్రయత్నాన్ని ఆపి, unitను failed stateలో శాశ్వతంగా ఉంచుతుంది. 03:00 సమయంలో మీకు కావలసింది దీనికి పూర్తిగా విరుద్ధం. దీన్ని 0గా సెట్ చేస్తే rate limit నిలిపివేయబడుతుంది. అందువల్ల crash-loopలో ఉన్న bot నిశ్శబ్దంగా ఆగిపోకుండా మళ్లీ మళ్లీ ప్రయత్నిస్తుంది. RestartSec=10 ఆ loop వల్ల exchangeకు వరుస reconnectsతో అధిక భారం కలగకుండా ఆపుతుంది.

దానిపై నమ్మకం ఉంచే ముందు fileను తనిఖీ చేసి, ఆ తర్వాత start చేయండి:

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 వల్ల reboots జరుగుతాయి. Bot నిశ్శబ్దంగా ఆగిపోతుందో లేదో తెలుసుకోవడానికి systemdను restart counter కోసం అడగండి:

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

ఒక వారం తర్వాత NRestarts=0 కనిపిస్తే అది ఆరోగ్యకరమైన bot. NRestarts=812 అంటే రాత్రంతా reconnect అవుతున్న processపై మీరు trading చేస్తున్నారని అర్థం. Daily report వంటి scheduled jobs కోసం timersతో సహా పూర్తి unit file నిర్మాణం systemd serviceగా programను అమలు చేయడంలో వివరించబడింది.

గడియారాన్ని UTCకి సెట్ చేసి, అది సమకాలీకరించబడిందని నిర్ధారించండి

Exchange APIలు అభ్యర్థనలకు timestampతో సంతకం చేసి, నిర్ణయించిన సమయ పరిమితికి వెలుపల ఉన్నవాటిని తిరస్కరిస్తాయి. ఈ పరిమితి తరచుగా 5 seconds లేదా అంతకంటే తక్కువగా ఉంటుంది. గడియారం తప్పిపోతే authentication failureలా కనిపించే errors వస్తాయి. అందువల్ల సమయాన్ని పరిశీలించకుండా చాలామంది గంటల తరబడి keysను మార్చుతుంటారు. Binance-style APIలలో సందేశం స్పష్టంగా ఉంటుంది: Timestamp for this request was 1000ms ahead of the server's time.

Serverను UTCకి సెట్ చేయండి. Local time zones వల్ల daylight saving మార్పు వస్తుంది. అది trading session మధ్యలో సంభవించవచ్చు.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntuలో systemd-timesyncd ముందుగానే ఉంటుంది. ఇది SNTP (simple network time protocol) client. Logsకు ఇది సరిపోతుంది. అయితే కొన్ని milliseconds పరిమితిలో సమయాన్ని ఉంచాల్సిన సందర్భాలకు ఇది బలహీనంగా ఉంటుంది. కారణం, ఇది ఒక serverను poll చేస్తుంది. గడియారాన్ని నిరంతరం సరిచేయదు. అందుకు బదులుగా chrony ఉపయోగించండి:

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

chronyc tracking నుంచి చదవాల్సిన line System time. ఉదాహరణకు System time : 0.000031415 seconds fast of NTP time. కొన్ని milliseconds కంటే తక్కువ విలువ ఆరోగ్యకరమైనదే. అది Leap status : Not synchronisedగా కనిపిస్తే, chrony ఇంకా ఏ serverను చేరుకోలేదు. సాధారణంగా outbound UDP 123 నిరోధించబడటమే కారణం. ఒక నిమిషం వేచి ఉండి, firewall rulesను మార్చే ముందు మళ్లీ తనిఖీ చేయండి.

మీరు కాపీ చేసే ప్రదేశాల్లో API keys ఉంచవద్దు

లీకైన exchange key, లీకైన SSH key కంటే ప్రమాదకరం. ఎందుకంటే withdrawal permission ఉంటే అది వెంటనే డబ్బుగా మారుతుంది. రెండు అలవాట్లు ఎక్కువ శాతం ప్రమాదాన్ని నియంత్రిస్తాయి.

మొదట, bot key కు ఎప్పుడూ withdrawal permission ఇవ్వవద్దు. exchange దీనికి మద్దతు ఇస్తే, key ను మీ server యొక్క IP address కు పరిమితం చేయండి. దొంగిలించబడిన key దాదాపు పనికిరాకుండా చేసే ఏకైక నియంత్రణ ఇదే.

రెండవది, secret ను code directory వెలుపల ఉంచండి. /opt/tradingbot లోని ఏదైనా విషయం కొంతకాలానికి git repository లేదా backup archive లోకి చేరుతుంది. root యాజమాన్యంలోని, systemd మాత్రమే చదవగలిగే file లో దాన్ని ఉంచండి:

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

ఈ file లో quotes మరియు export లేకుండా plain KEY=value lines ఉంటాయి. group bot తో mode 640 ఉంటే, service user దాన్ని చదవగలదు; మరెవరూ చదవలేరు. sudo -u bot cat /etc/tradingbot/api.env తో ధృవీకరించండి. ఆ తర్వాత మరొక user తో కూడా పరీక్షించండి. అక్కడ అది Permission denied తో విఫలమవ్వాలి.

bot ను root గా లేదా మీ login user గా అమలు చేయవద్దు. shell మరియు login చేయడానికి home directory లేని system account ను సృష్టించండి:

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

ఆ flags లో ప్రతి దాని ఉద్దేశం, అలాగే ProtectSystem=strict వాస్తవంగా ఎంతవరకు ప్రభావితం చేస్తుందో ప్రత్యేక హక్కులు లేని user గా services ను అమలు చేయడం లో వివరించబడింది. మిగిలిన server baseline, SSH keys మరియు firewall, కొత్త VPS లో మొదటి 10 నిమిషాలు లో ఉండాలి.

మీ బ్రోకర్ గుర్తించేలోపు అది ఆగిపోయిందని తెలుసుకోండి

systemctl status ప్రక్రియ నడుస్తోందని చెబుతుంది. బాట్ ఏదైనా పని చేస్తోందని అది చెప్పదు. పనిచేయని websocket‌కు మళ్లీ మళ్లీ ప్రయత్నించే loop‌లో ఇరుక్కున్న ప్రక్రియ, systemd చేయగల ప్రతి తనిఖీలోనూ విజయవంతంగా కనిపిస్తుంది.

దానికి బదులుగా heartbeat ఉపయోగించండి. Uptime Kumaలో push monitors ఉన్నాయి. మీ బాట్ నిర్దిష్ట వ్యవధిలో ఒక URLను call చేయాలని ఇది ఆశిస్తుంది. ఆ call రావడం ఆగిపోతే ఇది alert పంపుతుంది. బాట్ సజీవంగా ఉందని నిరూపించే భాగం పూర్తైన తర్వాత, ఉదాహరణకు market data విజయవంతంగా చదివిన తర్వాత, మీ main loop చివర callను ఉంచండి.

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

మీ loop సమయానికి సుమారు రెండింతలుగా monitor intervalను సెట్ చేయండి. దీంతో సాధారణ jitter కారణంగా అనవసరంగా page రాదు. monitorను బాట్‌కు వేరే serverలో నడపండి. ఎందుకంటే అది పర్యవేక్షించే వస్తువుతో పాటు monitor కూడా ఆగిపోతే, అది ఏ సమాచారాన్నీ నివేదించదు. Setup వివరాలు Uptime Kumaతో స్వీయ-హోస్ట్ చేసిన స్థితి పర్యవేక్షణలో ఉన్నాయి.

డిస్క్ alertను కూడా జోడించండి. verbose logs రాస్తున్న బాట్ కొన్ని వారాల్లో root filesystemను నింపేస్తుంది. డిస్క్ పూర్తయితే network call కాకుండా database write ఆగిపోతుంది. అందువల్ల లక్షణాలు అసాధారణంగా కనిపిస్తాయి. journalctl --vacuum-time=14d మరియు /etc/systemd/journald.confలోని SystemMaxUse= line journal పరిమితిలో ఉండేలా చేస్తాయి.

నిజాయితీగా చెప్పాలంటే: జాప్యంలో ఎక్కువ భాగం మీ host వల్ల కాదు

ఇక్కడే ట్రేడింగ్ VPS ఉత్పత్తుల మార్కెట్ సాంకేతికతను వదిలేస్తుంది. మార్కెటింగ్ పేజీలు మిల్లీసెకండ్‌లోపు విలువలను చూపించి, మీకు ఆర్డర్ అమలు కావడానికి మీ host‌నే అడ్డంకిగా సూచిస్తాయి. దాదాపు ప్రతి రిటైల్ bot‌కు ఇది నిజం కాదు.

మీ ఆర్డర్ bot‌ నుంచి public internet ద్వారా exchange లేదా broker endpoint‌కు వెళ్తుంది. ఆ మార్గాన్ని భౌతిక దూరం, అలాగే మీ provider‌కి మరియు వారి provider‌కి మధ్య ఉన్న peering ప్రధానంగా నిర్ణయిస్తాయి. Frankfurt‌లోని server Tokyo‌లోని endpoint‌తో కమ్యూనికేట్ చేస్తే, CPU ఎంత వేగంగా ఉన్నా round trip‌కు సుమారు 250 milliseconds పడుతుంది. ఆ తర్వాత broker‌ యొక్క స్వంత systems queue, risk checks మరియు rate limits‌ను జోడిస్తాయి. రిటైల్ account‌కు ఇవి సాధారణంగా పదుల లేదా వందల milliseconds‌లో కొలవబడతాయి.

ఊహించకుండా కొలవండి. నిజమైన endpoint‌ కోసం connection మరియు first-byte సమయాలను 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

మీరు server‌ను ఖరారు చేసే ముందు candidate server‌ నుంచి దీన్ని అమలు చేయండి. connect 0.180 seconds అయితే, మీరు తప్పు ఖండంలో ఉన్నారు. దాన్ని సరిచేయడం ప్రయోజనకరం. connect 0.004 seconds మరియు ttfb 0.140 seconds అయితే, మిగిలిన జాప్యం broker‌ processing వల్ల వస్తుంది. ఏ host మార్పూ దాన్ని తగ్గించదు.

అయితే host ఎప్పుడు ముఖ్యమవుతుంది? మీరు venue‌కి colocated లేదా cross-connected అయి queue position కోసం పోటీ పడుతున్నప్పుడు. అది వేరే బడ్జెట్‌తో కూడిన వేరే వ్యాపారం. అలాగే మీ స్వంత code bottleneck‌గా ఉన్నప్పుడు కూడా host ముఖ్యమవుతుంది. ప్రతి tick‌కి పూర్తి historyపై indicators‌ను మళ్లీ లెక్కించే bot ప్రతి loop‌కి 200 milliseconds CPU సమయాన్ని వినియోగించవచ్చు. ఇది మీరు ఉచితంగా నియంత్రించగల నిజమైన జాప్యం. వేగవంతమైన server‌ కోసం వెతకడానికి ముందు loop‌ను profile చేయండి.

మీరు ఎంచుకునే host‌లో నిజంగా ముఖ్యమైనవి geography, స్థిరమైన networking, అలాగే OOM killer‌కి ఎప్పుడూ అవకాశం ఇవ్వని తగిన memory. July 2026 నాటికి, memoryలో కొన్ని వందల symbols‌ ఉంచే single-strategy Python bot 2 GB RAM మరియు 2 vCPUలో సౌకర్యవంతంగా నడుస్తుంది. tick historyని local databaseలో ఉంచితే memoryని పెంచండి.

ప్రత్యక్ష వినియోగానికి ముందు సంక్షిప్త తనిఖీ జాబితా

1. systemctl is-enabled tradingbot, enabled ను ముద్రిస్తుంది. సేవ sudo reboot తర్వాత కూడా కొనసాగుతుంది.
2. chronyc tracking, సిస్టమ్ సమయ ఆఫ్‌సెట్ కొన్ని మిల్లీసెకండ్ల కంటే తక్కువగా ఉందని నివేదిస్తుంది.
3. API key కు trading అనుమతి ఉంది. withdrawal అనుమతి లేదు. exchange అందిస్తే IP allowlist కూడా ఉంది.
4. sudo systemctl kill -s SIGKILL tradingbot తో process ను ఆపినప్పుడు, అది RestartSec లోపు తిరిగి ప్రారంభమవుతుంది.
5. మీరు bot ను ఉద్దేశపూర్వకంగా ఆపినప్పుడు, heartbeat monitor ఒక interval లోపు మీకు page పంపుతుంది.
6. Logs పరిమితిలో ఉంటాయి. df -h లో root filesystem లో తగినంత ఖాళీ ఉంటుంది.

నిజమైన నిధులను ఉపయోగించే ముందు, ఈ మొత్తం విధానాన్ని exchange యొక్క sandbox లో లేదా paper mode లో ఒక వారం అమలు చేయండి. ఆ వారంలో పై ప్రతి అంశం కనీసం ఒక్కసారి విఫలమవుతుంది. ఆ వారాన్ని నిర్వహించడంలోని ఉద్దేశ్యం అదే.

FAQ

ట్రేడింగ్ bot‌కు తక్కువ latency లేదా bare metal server అవసరమా?

అదే venueలోని ఇతర automated participants‌తో execution speed విషయంలో పోటీ పడుతున్నప్పుడు మాత్రమే ఇది అవసరం. అలాంటి సందర్భంలో సాధారణంగా general purpose VPS కంటే colocation అనుకూలంగా ఉంటుంది. Retail bot‌కు round trip‌ను geography మరియు broker యొక్క స్వంత processing ఎక్కువగా ప్రభావితం చేస్తాయి. అందువల్ల API endpoint‌కు సమీపంలోని server‌ను ఎంచుకోండి. వేగవంతమైన దేనికైనా చెల్లించే ముందు curl మరియు mtrతో కొలవండి.

ట్రేడింగ్ bot‌కు ఎంత RAM మరియు CPU అవసరం?

చాలా single-strategy bot‌లు network-bound‌గా ఉంటాయి. Events మధ్యలో అవి idleగా ఉంటాయి. July 2026 నాటికి, కొన్ని వందల instruments‌ను track చేసే Python bot‌కు 2 vCPU మరియు 2 GB RAM సరిపోతాయి. Tick historyని processలో ఉంచినప్పుడు లేదా local database నడిపినప్పుడు memory పరిమితిగా మారుతుంది. అంచనా వేయకుండా free -h మరియు journalలో OOM kill messages‌ను monitor చేయండి.

Timestamp error‌తో నా exchange API requests‌ను ఎందుకు తిరస్కరిస్తోంది?

Server clock drift అయి exchange యొక్క signing window వెలుపలికి వెళ్లింది. సాధారణంగా ఈ వ్యత్యాసం కొన్ని seconds ఉంటుంది. chronyను install చేయండి. chronyc trackingలో చిన్న System time offset మరియు synchronised leap status కనిపిస్తున్నాయో నిర్ధారించండి. Daylight saving మార్పు వల్ల clock మారకుండా machine‌ను UTCకు సెట్ చేయండి. API keyని మార్చడం వల్ల clock సమస్య పరిష్కారం కాదు.

నాకు తెలియకుండా bot రాత్రంతా ఆగిపోకుండా ఎలా నిరోధించాలి?

దాన్ని systemd కింద Restart=always మరియు StartLimitIntervalSec=0తో run చేయండి. అప్పుడు crash loop శాశ్వతంగా ఆగిపోకుండా మళ్లీ ప్రయత్నిస్తుంది. ప్రతి successful loop చివర bot పంపే heartbeatను కూడా జోడించండి. Restart process‌ను నిర్వహిస్తుంది. Process సజీవంగా ఉన్నా stuckగా ఉన్న సందర్భాన్ని heartbeat గుర్తిస్తుంది.

Bot మరియు monitoring‌ను ఒకే VPSలో run చేయవచ్చా?

చేయవచ్చు. కానీ అవసరమైన రోజున monitoring మీకు తప్పు సమాచారం ఇస్తుంది. ఎందుకంటే bot‌ను ఆపే outage monitoring‌ను కూడా ఆపుతుంది. Alerting‌ను వేరే machineలో ఉంచండి. సాధ్యమైనంతవరకు వేరే provider లేదా regionను ఉపయోగించండి. Bot server‌ను bot మరియు దాని logs కోసం మాత్రమే ఉపయోగించండి.