Trading bot के लिए सही VPS कैसे चुनें: पूरी गाइड

ट्रेडिंग बॉट के लिए VPS की आवश्यकताएं

ट्रेडिंग बॉट्स के लिए VPS का मूल्यांकन चार बिंदुओं पर किया जाता है: क्या process बंद होने के बाद वापस शुरू होती है, क्या clock सही है, क्या API (application programming interface) keys को चुराना कठिन है, और क्या आपको पता चलता है कि बॉट कब रुक गया है। एक रिटेल बॉट के लिए raw speed इस सूची में बहुत नीचे आती है, क्योंकि आपके order path का धीमा हिस्सा आपका broker और उससे आपकी दूरी है, न कि वह host जिस पर आपका Python चल रहा है।

यह एक इंजीनियरिंग गाइड है। यहाँ दी गई कोई भी जानकारी वित्तीय सलाह नहीं है, और किसी भी रणनीति पर चर्चा नहीं की गई है।

Uptime का अर्थ restart discipline है, न कि sales page पर लिखा कोई नंबर

विज्ञापित uptime commitments अलग-अलग होते हैं। AWS एक single EC2 instance के लिए कम से कम 99.5 प्रतिशत और कई availability zones में योग्य deployments के लिए 99.99 प्रतिशत का वादा करता है। ये commitments infrastructure की उपलब्धता को कवर करते हैं, न कि आपके bot की सेहत को। एक bot unhandled exception, कभी न reconnect होने वाले websocket, या OOM (out of memory) killer के कारण बंद हो सकता है, जबकि सर्वर पूरा समय चालू रहता है। इसलिए, उपयोगी सवाल यह है कि आपके 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 वह लाइन है जिसे लोग अक्सर भूल जाते हैं। Upstream systemd defaults 10 सेकंड में 5 starts की अनुमति देते हैं, जिसमें initial start और manual starts शामिल हैं; manager configuration इन defaults को override कर सकता है। इस limit तक पहुँचने पर automatic restart के प्रयास रुक जाते हैं, लेकिन interval बीतने के बाद unit को मैन्युअल रूप से या timer या socket द्वारा start किया जा सकता है। इसे 0 पर सेट करने से rate limit disable हो जाती है, इसलिए 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 का मतलब reboot होता है। यह देखने के लिए कि क्या bot चुपचाप मर रहा है, systemd से restart counter मांगें:

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

NRestarts=0 पिछली बार counter reset होने के बाद से किसी भी automatic restart job की गिनती नहीं करता है; यह एक स्वस्थ या crash-free सप्ताह का प्रमाण नहीं है। Manual restarts और systemctl reset-failed counter को reset कर देते हैं, और एक hung bot भी शून्य दिखा सकता है। NRestarts=812 812 restart jobs की गिनती करता है, न कि सफल exchange reconnections या trades की, और यह इस बारे में कुछ नहीं बताता कि वे कब हुए। Timing और कारण के लिए journal की जाँच करें, जिसमें bot के connect होने से पहले की विफलताएं भी शामिल हैं। Unit file की पूरी संरचना, जिसमें दैनिक रिपोर्ट जैसी scheduled jobs के लिए timers शामिल हैं, systemd service के रूप में प्रोग्राम चलाना में कवर की गई है।

घड़ी को UTC पर सेट करें और सुनिश्चित करें कि यह सिंक्रोनाइज़्ड है

Exchange APIs हस्ताक्षरित अनुरोधों (signed requests) को मान्य करने के लिए टाइमस्टैम्प का उपयोग करते हैं; Binance Spot डिफ़ॉल्ट रूप से 5-सेकंड की रिसीव विंडो का उपयोग करता है और सर्वर समय से कम से कम 1 सेकंड आगे के टाइमस्टैम्प को अस्वीकार कर देता है। घड़ी में विचलन (drifting clock) से ऐसी त्रुटियाँ उत्पन्न होती हैं जो प्रमाणीकरण विफलताओं (authentication failures) जैसी दिखती हैं, इसलिए लोग समय की जाँच करने से पहले घंटों तक कुंजियों (keys) को रोटेट करते रहते हैं। Binance-शैली के APIs पर संदेश शाब्दिक होता है: Timestamp for this request was 1000ms ahead of the server's time।

सर्वर को UTC पर सेट करें। स्थानीय समय क्षेत्र (local time zones) प्रदर्शित समय में डेलाइट सेविंग जंप लाते हैं; APIs द्वारा उपयोग किए जाने वाले Unix टाइमस्टैम्प तब नहीं बदलते जब डिस्प्ले टाइमज़ोन बदलता है।

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu में 25.10 के बाद से डिफ़ॉल्ट रूप से chrony का उपयोग होता है; पुराने इंस्टॉलेशन systemd-timesyncd का उपयोग कर सकते हैं, जो एक SNTP (सिंपल नेटवर्क टाइम प्रोटोकॉल) क्लाइंट है। 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। एक छोटा मान chrony की NTP घड़ी में शेष छोटे सुधार को दर्शाता है; सटीकता का निर्णय लेने से पहले सिंक्रोनाइज़ेशन, Root delay और Root dispersion की भी जाँच करें। यदि यह Leap status : Not synchronised पढ़ता है, तो chrony सिंक्रोनाइज़्ड नहीं है, भले ही सर्वरों ने प्रतिक्रिया दी हो; मापों को बहुत गलत मानकर अस्वीकार किया जा सकता है। एक मिनट प्रतीक्षा करें, फिर फ़ायरवॉल नियमों को बदलने से पहले दोबारा जाँचें।

API keys को उन जगहों पर न रखें जहाँ आप copy करते हैं

एक लीक हुई exchange key, लीक हुई SSH key से अधिक खतरनाक होती है, क्योंकि withdrawal permission मिलते ही यह तुरंत पैसे के नुकसान में बदल सकती है। दो आदतें अधिकांश जोखिम को कवर कर लेती हैं।

सबसे पहले, कभी भी bot key को withdrawal permission न दें, और जहाँ exchange इसका समर्थन करता हो, key को अपने सर्वर के IP address से bind करें। यह एकमात्र ऐसा control है जो चोरी हुई key को लगभग बेकार बना देता है।

दूसरा, secret को code directory से बाहर रखें। /opt/tradingbot के अंदर मौजूद कोई भी चीज़ देर-सवेर git repository या backup archive में चली ही जाती है। इसे root-owned file में रखें जिसे 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

इस file में सादे KEY=value lines होते हैं, जिनमें कोई quotes और कोई export नहीं होता। Mode 640 root owner को read/write access देता है और group bot के सदस्यों को read access देता है, जबकि अन्य users के लिए कोई permission नहीं होती। sudo -u bot cat /etc/tradingbot/api.env के साथ verify करें और फिर group bot के बाहर के एक unprivileged user के साथ जाँचें, जहाँ इसे Permission denied के साथ fail होना चाहिए।

Bot को खुद root या आपके login user के रूप में नहीं चलना चाहिए। service शुरू करने या group bot के स्वामित्व वाली files बनाने से पहले, nologin shell और /var/lib/tradingbot को home directory के रूप में उपयोग करते हुए एक system account बनाएँ:

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

उनमें से प्रत्येक flag के पीछे का तर्क, और ProtectSystem=strict वास्तव में किस हद तक काम करता है, यह unprivileged user के रूप में services चलाना में दिया गया है। सर्वर baseline का शेष भाग, SSH keys और firewall, नए VPS पर पहले दस मिनट में शामिल है।

अपने ब्रोकर से पहले पता लगाएँ कि सेवा डाउन है

systemctl status यह बताता है कि process चल रही है। यह यह नहीं बताता कि bot वास्तव में काम कर रहा है। एक dead websocket के खिलाफ retry loop में फंसी हुई process ऊपर दिए गए unit checks को पास कर लेती है।

इसके बजाय heartbeat का उपयोग करें। Uptime Kuma में push monitors होते हैं: यह उम्मीद करता है कि आपका bot एक schedule पर URL को call करे, और call आना बंद होने पर alert भेजता है। इस call को अपने main loop के अंत में रखें, उस हिस्से के बाद जो यह साबित करता है कि bot जीवित है, जैसे कि market data का सफल read।

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

Monitor interval को अपने loop time से लगभग दोगुना रखें ताकि सामान्य jitter के कारण आपको अनावश्यक alert न मिले। Monitor को bot से अलग सर्वर पर चलाएं, क्योंकि जो monitor उस चीज़ के साथ मर जाता है जिसे वह watch कर रहा है, वह कुछ भी रिपोर्ट नहीं करेगा। Setup की जानकारी Uptime Kuma के साथ self-hosted status monitoring में दी गई है।

एक disk alert भी जोड़ें। verbose logs लिखने वाला bot कुछ ही हफ्तों में root filesystem को भर देगा, और full disk होने पर database write रुक जाता है, न कि network call, इसलिए इसके लक्षण अजीब होते हैं। journalctl --vacuum-time=14d और /etc/systemd/journald.conf में एक SystemMaxUse= लाइन journal को सीमित रखती है।

ईमानदारी की बात: latency का मुख्य कारण आपका host नहीं है

यहीं पर trading VPS उत्पादों का बाज़ार तकनीकी होने के बजाय केवल मार्केटिंग रह जाता है। मार्केटिंग पेजों पर sub-millisecond के आंकड़े दिए जाते हैं और यह संकेत दिया जाता है कि host ही वह बाधा है जो आपके और trade fill के बीच खड़ी है। लगभग सभी retail bots के लिए, ऐसा नहीं है।

आपका order bot से exchange या broker endpoint तक public internet के माध्यम से पहुँचता है। उस रास्ते पर भौतिक दूरी और आपके provider तथा उनके बीच की peering का सबसे अधिक प्रभाव पड़ता है। इसके बाद, broker के अपने सिस्टम अपनी queue, risk checks और rate limits जोड़ते हैं।

अनुमान लगाने के बजाय इसे मापें। curl एक वास्तविक endpoint के लिए connection और first-byte times की रिपोर्ट देता है:

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

किसी सर्वर को चुनने से पहले उसे candidate server से चलाकर देखें। यदि connect 0.180 seconds है, तो इसमें DNS resolution और TCP connection शामिल हैं; यह यह तय नहीं करता कि आप किस महाद्वीप पर हैं। यदि connect 0.004 seconds है और ttfb 0.140 seconds है, तो अंतर में TLS setup, request transmission, network delays और server processing शामिल हैं। host बदलने से इनमें से कुछ घटकों पर असर पड़ सकता है, इसलिए candidate locations से लिए गए मापों की तुलना करें।

तो host कब मायने रखता है? जब आप venue के साथ colocated या cross-connected हों और queue position के लिए प्रतिस्पर्धा कर रहे हों, जो कि एक अलग व्यवसाय है और जिसका बजट भी अलग है। और तब, जब आपका अपना code ही bottleneck हो: एक ऐसा bot जो हर tick पर पूरे इतिहास (history) के आधार पर indicators की पुनर्गणना करता है, वह हर loop में 200 milliseconds CPU खर्च कर सकता है, जो कि वास्तविक latency है जिसे आप मुफ्त में नियंत्रित कर सकते हैं। तेज़ सर्वर खरीदने से पहले अपने loop को profile करें।

आपके द्वारा चुने गए host में जो वास्तव में मायने रखता है, वह है भूगोल, स्थिर नेटवर्किंग, और पर्याप्त memory ताकि OOM killer को कभी हस्तक्षेप न करना पड़े। यदि आप tick history को local database में रखते हैं, तो memory बढ़ाएं।

प्री-लाइव चेकलिस्ट

1. systemctl is-enabled tradingbot कमांड enabled प्रिंट करता है, और सर्विस sudo reboot के बाद भी चलती रहती है।
2. chronyc tracking सिंक्रोनाइज़ेशन की रिपोर्ट देता है, सिस्टम टाइम ऑफसेट कुछ मिलीसेकंड से कम है, और रूट डिले तथा डिस्पर्शन आपके टाइमिंग बजट के भीतर हैं।
3. API key में ट्रेडिंग की अनुमति है, विड्रॉल की अनुमति नहीं है, और यदि एक्सचेंज सुविधा देता है तो IP अलाउलिस्ट सेट है।
4. sudo systemctl kill -s SIGKILL tradingbot के साथ प्रोसेस को किल करने पर, यह RestartSec डिले और स्टार्टअप समय के बाद वापस आ जाता है।
5. हार्टबीट मॉनिटर कॉन्फ़िगर किए गए अंतराल के बाद आपको पेज करता है, और जब आप जानबूझकर बॉट को रोकते हैं तो यह पुनः प्रयास (retry) करता है।
6. लॉग्स सीमित हैं और df -h में रूट फाइलसिस्टम के पास पर्याप्त जगह (headroom) है।

असली फंड्स का उपयोग करने से पहले, पूरे सेटअप को एक सप्ताह तक एक्सचेंज के सैंडबॉक्स या पेपर मोड में चलाएं। उस सप्ताह के दौरान ऊपर दी गई हर चीज़ कम से कम एक बार विफल होगी, और यही उस सप्ताह का मुख्य उद्देश्य है।

FAQ

क्या ट्रेडिंग बॉट को low-latency या bare metal सर्वर की आवश्यकता होती है?

केवल तभी, यदि आप उसी venue पर अन्य स्वचालित प्रतिभागियों के साथ execution speed के मामले में प्रतिस्पर्धा कर रहे हैं, जिसका अर्थ सामान्यतः general purpose VPS के बजाय colocation होता है। एक retail बॉट के लिए round trip मुख्य रूप से भूगोल और ब्रोकर की अपनी प्रोसेसिंग पर निर्भर करता है, इसलिए API endpoint के निकट एक सर्वर चुनें और किसी भी तेज़ विकल्प के लिए भुगतान करने से पहले curl और mtr के साथ मापें।

ट्रेडिंग बॉट को कितनी RAM और CPU की आवश्यकता होती है?

अधिकांश single-strategy बॉट network-bound होते हैं और घटनाओं के बीच idle रहते हैं। जब आप process में tick history रखते हैं या local database चलाते हैं, तब memory एक बाधा बन जाती है, इसलिए अनुमान लगाने के बजाय free -h और OOM kill संदेशों के लिए journal पर नज़र रखें।

मेरा exchange API timestamp error के साथ requests को reject क्यों करता है?

Request timestamp एक्सचेंज की स्वीकृत विंडो से बाहर है; clock drift और request delay दोनों ही मायने रखते हैं। chrony इंस्टॉल करें, पुष्टि करें कि chronyc tracking एक छोटा System time offset और एक synchronised leap status दिखाता है, और root delay तथा dispersion की भी जाँच करें। मशीन को UTC पर सेट करने से प्रदर्शित समय सुसंगत रहता है लेकिन clock drift ठीक नहीं होता है। API key को rotate करने से clock की समस्या ठीक नहीं होती है।

मैं अपने बॉट को बिना मेरी जानकारी के रात भर बंद होने से कैसे रोकूँ?

इसे Restart=always और StartLimitIntervalSec=0 के साथ systemd के अंतर्गत चलाएँ ताकि crash loop start rate limit तक पहुँचने के बजाय पुनः प्रयास करता रहे, फिर एक heartbeat जोड़ें जिसे बॉट प्रत्येक सफल लूप के अंत में भेजे। restart प्रक्रिया को संभाल लेता है। heartbeat उस स्थिति को पकड़ लेता है जहाँ प्रक्रिया जीवित तो है लेकिन अटक गई है।

क्या मैं बॉट और अपनी monitoring को एक ही VPS पर चला सकता हूँ?

आप ऐसा कर सकते हैं, लेकिन जिस दिन इसकी सबसे अधिक आवश्यकता होगी, monitoring आपको गलत जानकारी देगी, क्योंकि जो outage बॉट को बंद करता है, वह मॉनिटर को भी साथ ले जाता है। alerting को एक अलग मशीन पर रखें, आदर्श रूप से किसी भिन्न प्रदाता या क्षेत्र के साथ, और बॉट के सर्वर का उपयोग केवल बॉट और उसके logs के लिए करें।