Trading bot-এর VPS-এ আসলে কী গুরুত্বপূর্ণ?

একটি trading bot-এর VPS থেকে যা প্রয়োজন

trading bot-এর জন্য VPS সাধারণত চারটি বিষয়ের ভিত্তিতে মূল্যায়ন করা হয়: process বন্ধ হয়ে গেলে সেটি কি আবার চালু হয়, clock কি সঠিক থাকে, API (application programming interface) key চুরি করা কি কঠিন, এবং bot বন্ধ হলে আপনি কি তা জানতে পারেন। retail bot-এর ক্ষেত্রে raw speed এই তালিকায় অনেক নিচে থাকে। কারণ order path-এর ধীরতম অংশ হলো আপনার broker এবং তার সঙ্গে দূরত্ব, Python চালানো host নয়।

এটি একটি engineering guide। এখানে কোনো financial advice নেই এবং কোনো strategy নিয়ে আলোচনা করা হয়নি।

Uptime হলো restart discipline, sales page-এ লেখা কোনো সংখ্যা নয়

Advertised uptime commitment একেক provider-এর জন্য একেক রকম। AWS একটি EC2 instance-এর জন্য কমপক্ষে 99.5 percent এবং একাধিক availability zone জুড়ে qualifying deployment-এর জন্য 99.99 percent নির্দিষ্ট করে। এই commitment infrastructure availability কভার করে, আপনার bot-এর health নয়। Unhandled exception, কখনো reconnect না করা 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 হলো সেই line, যা অনেকে উপেক্ষা করেন। Upstream systemd-এর default অনুযায়ী 10 সেকেন্ডে 5টি start অনুমোদিত, যার মধ্যে initial start এবং manual start-ও অন্তর্ভুক্ত; manager configuration এই default পরিবর্তন করতে পারে। Limit-এ পৌঁছালে automatic restart attempt বন্ধ হয়, তবে interval পার হওয়ার পরে unit-কে manualভাবে অথবা timer বা socket-এর মাধ্যমে start করা যায়। এটিকে 0 সেট করলে rate limit বন্ধ হয়। ফলে crash-loop করা bot নীরব হয়ে না থেকে restart করার চেষ্টা চালিয়ে যায়। RestartSec=10 সেই loop-কে exchange-এ অতিরিক্ত reconnect পাঠানো থেকে থামায়।

বিশ্বাস করার আগে 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 update-এর কারণে 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-এর সংখ্যা দেখায় না; এটি healthy বা crash-free এক সপ্তাহের প্রমাণ নয়। Manual restart এবং systemctl reset-failed counter reset করে, আর hung bot এখনও 0 দেখাতে পারে। NRestarts=812 812টি restart job গণনা করে, সফল exchange reconnection বা trade নয়, এবং এগুলো কখন ঘটেছে সে সম্পর্কে কিছু বলে না। Timing এবং কারণ জানতে journal পরীক্ষা করুন। Bot connect করার আগের failure-গুলোও এতে অন্তর্ভুক্ত করুন। Daily report-এর মতো scheduled job-এর timer-সহ সম্পূর্ণ unit file anatomy systemd service হিসেবে একটি program চালানো-এ ব্যাখ্যা করা হয়েছে।

সিস্টেমের ঘড়ি UTC-তে সেট করুন এবং এটি সিঙ্ক্রোনাইজড আছে প্রমাণ করুন

স্বাক্ষরিত অনুরোধ যাচাই করতে Exchange API-গুলো timestamp ব্যবহার করে। Binance Spot-এর ডিফল্ট receive window 5-second এবং server time-এর চেয়ে অন্তত 1 second এগিয়ে থাকা timestamp প্রত্যাখ্যান করে। ঘড়িতে drift থাকলে authentication failure-এর মতো error দেখা যায়। ফলে অনেকে সময় পরীক্ষা করার আগে ঘণ্টার পর ঘণ্টা key পরিবর্তন করেন। Binance-ধরনের API-তে বার্তাটি সরাসরি: Timestamp for this request was 1000ms ahead of the server's time।

সার্ভারকে UTC-তে সেট করুন। Local time zone পরিবর্তন করলে প্রদর্শিত সময়ে daylight saving-এর jump দেখা দিতে পারে। কিন্তু API-তে ব্যবহৃত Unix timestamp display timezone পরিবর্তনে jump করে না।

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu 25.10 থেকে ডিফল্টভাবে chrony ব্যবহার করে। পুরোনো installation-এ systemd-timesyncd ব্যবহার করা যায়। এটি একটি SNTP (simple network time protocol) client। systemd-timesyncd ঘড়ি সামঞ্জস্য করে। তবে ভুল time source শনাক্ত করতে এটি একসঙ্গে একাধিক 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। ছোট value chrony-এর NTP clock-এ অবশিষ্ট correction কম থাকার ইঙ্গিত দেয়। নির্ভুলতা বিচার করার আগে synchronization, Root delay এবং Root dispersion-ও পরীক্ষা করুন। যদি এটি Leap status : Not synchronised দেখায়, তাহলে chrony synchronised নয়, server-গুলো response দিলেও। Measurement অতিরিক্ত inaccurate হওয়ায় প্রত্যাখ্যাত হতে পারে। এক মিনিট অপেক্ষা করুন। তারপর আবার পরীক্ষা করুন। এর আগে firewall rule পরিবর্তন করবেন না।

আপনি যে স্থানগুলোতে কপি করেন, সেখানে API key রাখবেন না

leaked exchange key, leaked SSH key-এর চেয়েও বেশি ঝুঁকিপূর্ণ। কারণ withdrawal permission থাকলে এটি সঙ্গে সঙ্গে অর্থে পরিণত হতে পারে। দুটি অভ্যাসে ঝুঁকির অধিকাংশ নিয়ন্ত্রণ করা যায়।

প্রথমত, কোনো bot key-কে withdrawal permission দেবেন না। Exchange এটি সমর্থন করলে key-টিকে আপনার server-এর IP address-এর সঙ্গে bind করুন। চুরি হওয়া 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-টিতে quote ছাড়া এবং কোনো export ছাড়া সরল KEY=value line থাকবে। Mode 640 অনুযায়ী root owner-এর read/write access এবং bot group-এর সদস্যদের read access থাকে; অন্য user-এর কোনো permission থাকে না। sudo -u bot cat /etc/tradingbot/api.env দিয়ে যাচাই করুন। এরপর bot group-এর বাইরে থাকা unprivileged user দিয়ে পরীক্ষা করুন। সেখানে operation-টি Permission denied দিয়ে ব্যর্থ হওয়া আবশ্যক।

Bot-টি root বা আপনার login user হিসেবে চালাবেন না। Service start করার বা bot group-এর মালিকানাধীন file তৈরি করার আগে nologin shell এবং home directory হিসেবে /var/lib/tradingbot-সহ একটি system account তৈরি করুন:

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

প্রতিটি flag-এর কারণ এবং ProtectSystem=strict আসলে কতটা সুরক্ষা দেয়, তা unprivileged user হিসেবে service চালানো অংশে ব্যাখ্যা করা হয়েছে। Server-এর বাকি baseline, SSH key এবং firewall, নতুন VPS-এ প্রথম দশ মিনিট অংশে রয়েছে।

আপনার broker-এর আগে এটি বন্ধ হয়ে গেছে কি না তা শনাক্ত করুন

systemctl status দেখায় যে process চলছে। এটি দেখায় না যে bot কোনো কাজ করছে। মৃত websocket-এর বিরুদ্ধে retry loop-এ আটকে থাকা একটি process আগের unit-এর process check পাস করে।

এর পরিবর্তে heartbeat ব্যবহার করুন। Uptime Kuma-তে push monitor আছে। এটি ধরে নেয় যে আপনার bot নির্দিষ্ট সময় অন্তর একটি URL কল করবে, এবং সেই কল আসা বন্ধ হলে alert পাঠায়। আপনার main loop-এর শেষে কলটি রাখুন। এমন অংশের পরে রাখুন যা প্রমাণ করে যে bot সচল, যেমন সফলভাবে market data পড়ার পরে।

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

Monitor interval আপনার loop time-এর প্রায় দ্বিগুণ নির্ধারণ করুন। এতে স্বাভাবিক jitter-এর কারণে অপ্রয়োজনীয় page হবে না। Bot থেকে আলাদা server-এ monitor চালান। কারণ যে monitor যাকে পর্যবেক্ষণ করছে তার সঙ্গেই বন্ধ হয়ে গেলে কোনো report দিতে পারবে না। Setup-এর বিস্তারিত Uptime Kuma দিয়ে self-hosted status monitoring-এ আছে।

একটি disk alert-ও যোগ করুন। Verbose log লিখতে থাকা bot কয়েক সপ্তাহের মধ্যে root filesystem পূর্ণ করে ফেলতে পারে। Disk পূর্ণ হলে network call নয়, database write বন্ধ হয়। তাই লক্ষণগুলো অস্বাভাবিক দেখায়। journalctl --vacuum-time=14d এবং /etc/systemd/journald.conf-এ থাকা একটি SystemMaxUse= line journal-এর আকার সীমাবদ্ধ রাখে।

সৎ কথাটি হলো: latency-এর বেশিরভাগই আপনার host নির্ধারণ করে না

এখানেই trading VPS পণ্যের বাজার technical বিষয় থেকে সরে যায়। Marketing page-গুলো sub-millisecond পরিমাপ দেখায় এবং এমন ধারণা দেয় যে আপনার order fill হওয়ার পথে host-ই প্রধান বাধা। প্রায় সব retail bot-এর ক্ষেত্রে এটি সত্য নয়।

আপনার order bot থেকে public internet-এর মাধ্যমে exchange বা broker endpoint-এ যায়। এই পথ মূলত physical distance এবং আপনার provider ও তাদের provider-এর মধ্যে peering দ্বারা নির্ধারিত হয়। এরপর broker-এর নিজস্ব system queue, risk check এবং rate limit যোগ করে।

অনুমান না করে মাপুন। curl একটি বাস্তব endpoint-এর connection এবং first-byte time দেখায়:

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 অন্তর্ভুক্ত থাকে; তবে আপনি কোন continent-এ আছেন, তা এটি নির্ধারণ করে না। যদি connect 0.004 seconds এবং ttfb 0.140 seconds হয়, তাহলে এই পার্থক্যের মধ্যে TLS setup, request transmission, network delay এবং server processing অন্তর্ভুক্ত থাকে। host পরিবর্তন করলে এসব component-এর কিছুতে প্রভাব পড়তে পারে। তাই candidate location-গুলো থেকে measurement তুলনা করুন।

তাহলে host কখন গুরুত্বপূর্ণ? যখন আপনি venue-এর সঙ্গে colocated বা cross-connected এবং queue position নিয়ে প্রতিযোগিতা করছেন। এটি ভিন্ন budget-এর ভিন্ন business। আপনার নিজের code bottleneck হলেও host গুরুত্বপূর্ণ। যেমন, একটি bot প্রতি tick-এ সম্পূর্ণ history-এর ওপর indicator পুনরায় গণনা করলে প্রতি loop-এ CPU-এর 200 milliseconds ব্যবহার করতে পারে। এটি এমন latency, যা আপনি বিনামূল্যে নিয়ন্ত্রণ করতে পারেন। আরও দ্রুত server খোঁজার আগে loop profile করুন।

আপনার বেছে নেওয়া host-এ যেগুলো গুরুত্বপূর্ণ, সেগুলো হলো geography, stable networking এবং পর্যাপ্ত memory, যাতে OOM killer কখনো সিদ্ধান্ত নেওয়ার সুযোগ না পায়। Local database-এ tick history সংরক্ষণ করলে অতিরিক্ত memory যোগ করুন।

লাইভে যাওয়ার আগের সংক্ষিপ্ত checklist

1. systemctl is-enabled tradingbot `enabled প্রদর্শন করে এবং service sudo reboot` পার হওয়ার পরও চালু থাকে।
2. chronyc tracking synchronization, কয়েক milliseconds-এর কম system time offset এবং আপনার timing budget-এর মধ্যে root delay ও dispersion রিপোর্ট করে।
3. API key-তে trading permission আছে, withdrawal permission নেই এবং exchange এই সুবিধা দিলে IP allowlist configured আছে।
4. sudo systemctl kill -s SIGKILL tradingbot দিয়ে process বন্ধ করলে RestartSec delay এবং startup time পার হওয়ার পর এটি আবার চালু হয়।
5. নির্ধারিত interval পার হলে heartbeat monitor আপনাকে alert পাঠায় এবং আপনি bot ইচ্ছাকৃতভাবে বন্ধ করলে monitor retry করে।
6. Logs-এর আকার সীমাবদ্ধ থাকে এবং df -h-এ root filesystem-এ পর্যাপ্ত free space থাকে।

Real funds ব্যবহারের আগে পুরো প্রক্রিয়াটি এক সপ্তাহ exchange-এর sandbox অথবা paper mode-এ চালান। ওই সপ্তাহে উপরের প্রতিটি বিষয় অন্তত একবার ব্যর্থ হবে। এক সপ্তাহ চালানোর উদ্দেশ্যই এটি শনাক্ত করা।

FAQ

একটি trading bot-এর কি low-latency বা bare metal server প্রয়োজন?

শুধু তখনই, যখন একই venue-তে অন্য automated participant-এর সঙ্গে execution speed নিয়ে প্রতিযোগিতা করছেন। সে ক্ষেত্রে সাধারণত general purpose VPS নয়, colocation প্রয়োজন হয়। Retail bot-এর ক্ষেত্রে round trip-এ geography এবং broker-এর নিজস্ব processing-এর প্রভাব বেশি থাকে। তাই API endpoint-এর কাছাকাছি একটি server বেছে নিন। দ্রুততর কিছুতে অর্থ ব্যয় করার আগে curl এবং mtr ব্যবহার করে পরিমাপ করুন।

একটি trading bot-এর কত RAM এবং CPU প্রয়োজন?

বেশিরভাগ single-strategy bot network-bound থাকে এবং event-এর মধ্যবর্তী সময়ে idle থাকে। Tick history process-এর মধ্যে ধরে রাখলে বা local database চালালে memory সীমাবদ্ধতা হয়ে দাঁড়ায়। তাই অনুমান না করে free -h এবং journal-এ OOM kill message পর্যবেক্ষণ করুন।

timestamp error দিয়ে আমার exchange API request প্রত্যাখ্যান করছে কেন?

Request timestamp exchange-এর গ্রহণযোগ্য window-এর বাইরে রয়েছে। Clock drift এবং request delay—দুটিই গুরুত্বপূর্ণ। chrony install করুন। chronyc tracking-এ একটি ছোট System time offset এবং synchronised leap status দেখাচ্ছে কি না নিশ্চিত করুন। এছাড়া root delay এবং dispersion-ও পরীক্ষা করুন। Machine-কে UTC-তে সেট করলে displayed time সামঞ্জস্যপূর্ণ থাকে, কিন্তু clock drift সংশোধন হয় না। API key rotate করলেও clock problem ঠিক হয় না।

আমাকে না জানিয়ে bot-এর রাতের বেলা বন্ধ হয়ে যাওয়া কীভাবে প্রতিরোধ করব?

Restart=always এবং StartLimitIntervalSec=0 ব্যবহার করে bot-কে systemd-এর অধীনে চালান। এতে crash loop start rate limit-এ পৌঁছানোর পরিবর্তে retry করতে থাকবে। এরপর প্রতিটি সফল loop-এর শেষে bot যে heartbeat পাঠায়, তা যোগ করুন। Restart process সামলায়। Heartbeat এমন পরিস্থিতি শনাক্ত করে, যেখানে process জীবিত আছে কিন্তু আটকে গেছে।

একই VPS-এ কি bot এবং monitoring চালাতে পারি?

পারেন। তবে যেদিন monitoring সবচেয়ে বেশি প্রয়োজন হবে, সেদিন এটি আপনাকে ভুল তথ্য দেবে। কারণ bot বন্ধ করে দেওয়া কোনো outage monitor-কেও বন্ধ করে দেবে। Alerting একটি আলাদা machine-এ রাখুন। সম্ভব হলে ভিন্ন provider বা region ব্যবহার করুন। Bot-এর server শুধু bot এবং তার log-এর জন্য ব্যবহার করুন।