Trading Botları İçin VPS Seçerken Ne Önemli?

Bir trading botun VPS'den gereksinimleri

Trading botları için kullanılan bir VPS dört ölçüte göre değerlendirilir: işlem sonlandığında yeniden başlatılabiliyor mu, sistem saati doğru mu, API (application programming interface) anahtarlarının çalınması zor mu ve bot durduğunda bundan haberdar olunuyor mu. Perakende bir bot için ham hız bu listede oldukça alt sıralardadır. Bunun nedeni, emir akışındaki yavaşlığın VPS'yi çalıştıran ana bilgisayardan değil, brokerdan ve brokerla arasındaki mesafeden kaynaklanmasıdır.

Bu bir mühendislik kılavuzudur. Buradaki hiçbir bilgi finansal tavsiye niteliğinde değildir ve herhangi bir strateji ele alınmamaktadır.

Kullanılabilirlik, satış sayfasındaki bir sayı değil, yeniden başlatma disiplinidir

Dünyadaki her sunucu 99.9 yüzde kullanılabilirlik oranı vadeder. Bu oran botunuzu değil, hypervisor'ı tanımlar. Bot, işlenmeyen bir istisna, hiç yeniden bağlanmayan bir websocket veya OOM (out of memory) killer nedeniyle durabilir ve sunucu bu süre boyunca çalışmaya devam eder. Bu nedenle asıl sorulması gereken soru, işleminiz sonlandıktan sonraki 10 saniyede ne olduğudur.

Botu bir systemd hizmeti olarak çalıştırın ve yeniden başlatma işlemini init sistemine bırakın. Bir unit dosyası bunu 6 satırda yapar.

[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 çoğu kişinin gözden kaçırdığı satırdır. Varsayılan olarak systemd, 10 saniye içinde 5 yeniden başlatma sonrasında vazgeçer ve unit'i kalıcı olarak failed durumunda bırakır. Bu, 03:00'te istemediğiniz davranıştır. Bu değerin 0 olarak ayarlanması hız sınırını devre dışı bırakır. Böylece sürekli çöken bir bot sessizce durmak yerine yeniden denemeye devam eder. RestartSec=10, bu döngünün exchange'e yeniden bağlantı istekleriyle aşırı yüklenmesini önler.

Dosyaya güvenmeden önce dosyayı doğrulayın, ardından hizmeti başlatın:

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

enable yeniden başlatmadan sonra da geçerli olan yarıdır; kernel güncellemeleri yeniden başlatma gerektirir. Botun sessizce durup durmadığını görmek için systemd'den yeniden başlatma sayacını isteyin:

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

Bir hafta sonrasındaki NRestarts=0 sağlıklı bir botu gösterir. NRestarts=812, bütün gece yeniden bağlanan bir işlem üzerinde alım satım yaptığınız anlamına gelir. Günlük rapor gibi zamanlanmış işler için timer'lar da dahil olmak üzere unit dosyasının tüm yapısı bir programı systemd hizmeti olarak çalıştırma bölümünde açıklanır.

Saati UTC olarak ayarlayın ve eşitlendiğini doğrulayın

Borsa API'leri istekleri zaman damgasıyla imzalar ve belirli bir zaman penceresi dışındaki istekleri reddeder. Bu pencere çoğu zaman 5 saniye veya daha kısadır. Saatteki sapma, kimlik doğrulama hatasına benzeyen hatalara yol açar. Bu nedenle zaman kontrol edilmeden önce saatlerce anahtarlar yenilenebilir. Binance tarzı API'lerde ileti doğrudandır: Timestamp for this request was 1000ms ahead of the server's time.

Sunucuyu UTC olarak ayarlayın. Yerel saat dilimleri, bir işlem oturumunun ortasında gerçekleşecek yaz saati uygulaması geçişine neden olur.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu, bir SNTP (simple network time protocol) istemcisi olan systemd-timesyncd yazılımını içerir. Günlükler için yeterlidir. Ancak birkaç milisaniyelik doğruluğun korunması gereken durumlar için uygun değildir. Bunun nedeni, tek bir sunucuyu sorgulaması ve saati sürekli olarak düzenlememesidir. Bunun yerine chrony kullanın:

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

chronyc tracking içinden okunması gereken satır System time değeridir; örneğin System time : 0.000031415 seconds fast of NTP time. Birkaç milisaniyenin altındaki değerler sağlıklıdır. Değer Leap status : Not synchronised olarak okunuyorsa chrony henüz bir sunucuya ulaşmamıştır. Bunun nedeni genellikle giden UDP 123 trafiğinin engellenmesidir. Bir dakika bekleyin. Ardından güvenlik duvarı kurallarını değiştirmeden önce yeniden kontrol edin.

API anahtarlarını kopyaladığınız konumların dışında tutun

Sızdırılmış bir borsa anahtarı, sızdırılmış bir SSH anahtarından daha tehlikelidir. Bunun nedeni, para çekme yetkisinin anahtarı anında paraya dönüştürmesidir. İki alışkanlık riskin büyük bölümünü azaltır.

İlk olarak, bir bot anahtarına hiçbir zaman para çekme yetkisi vermeyin. Borsa destekliyorsa anahtarı sunucunuzun IP adresine bağlayın. Bu, çalınan bir anahtarı neredeyse kullanılamaz duruma getiren en önemli kontroldür.

İkinci olarak, gizli bilgiyi kod dizininin dışında tutun. /opt/tradingbot içindeki her şey er ya da geç bir git deposuna veya yedek arşivine girer. Gizli bilgiyi yalnızca systemd tarafından okunabilen, root sahipliğindeki bir dosyaya koyun:

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

Dosya, tırnak işareti ve export içermeyen düz KEY=value satırlarını barındırır. bot grubuyla 640 modu, hizmet kullanıcısının dosyayı okuyabilmesini ve başka hiç kimsenin okuyamamasını sağlar. sudo -u bot cat /etc/tradingbot/api.env ile doğrulayın. Ardından başka bir kullanıcıyla da doğrulayın; bu deneme Permission denied ile başarısız olmalıdır.

Bot root veya oturum açma kullanıcınız olarak çalıştırılmamalıdır. Oturum açmak için kabuğu ve ana dizini olmayan bir sistem hesabı oluşturun:

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

Bu seçeneklerin her birinin gerekçesi ve ProtectSystem=strict seçeneğinin gerçekte ne kadar etkili olduğu hizmetleri ayrıcalıksız kullanıcı olarak çalıştırma bölümünde açıklanır. SSH anahtarlarını ve güvenlik duvarını içeren sunucu temel yapılandırmasının geri kalanı yeni bir VPS üzerindeki ilk on dakika bölümünde yer alır.

Aracı kurumdan önce çalışmadığını öğrenin

systemctl status işlemin çalıştığını belirtir. Botun herhangi bir işlem yaptığını belirtmez. Çalışmayan bir websocket'e karşı yeniden deneme döngüsünde takılı kalan bir işlem, systemd'nin gerçekleştirebileceği tüm denetimleri geçer.

Bunun yerine heartbeat kullanın. Uptime Kuma push monitor'larını destekler: botun belirli aralıklarla bir URL'yi çağırmasını bekler ve çağrılar kesildiğinde uyarı gönderir. Çağrıyı ana döngünüzün sonuna, botun çalıştığını kanıtlayan bölümden sonra ekleyin. Örneğin başarılı bir piyasa verisi okumasından sonra ekleyebilirsiniz.

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

Normal zamanlama sapmalarının alarm oluşturmasını önlemek için monitor aralığını döngü sürenizin yaklaşık iki katı olarak ayarlayın. Monitor'ü bottan farklı bir sunucuda çalıştırın. Çünkü izlediği bileşenle birlikte duran bir monitor hiçbir şey bildiremez. Kurulum Uptime Kuma ile kendi sunucunuzda durum izleme bölümünde açıklanmaktadır.

Disk için de bir alarm ekleyin. Ayrıntılı günlükler yazan bir bot, root dosya sistemini birkaç hafta içinde doldurabilir. Disk dolduğunda ağ çağrısı değil, veritabanına yazma işlemi durur. Bu nedenle belirtiler yanıltıcı olur. journalctl --vacuum-time=14d ve /etc/systemd/journald.conf içindeki bir SystemMaxUse= satırı journal boyutunu sınırlar.

Dürüst kısım: gecikmenin çoğu sunucunuzdan kaynaklanmaz

Trading VPS ürünleri pazarı bu noktada teknik olmaktan çıkar. Pazarlama sayfaları milisaniyenin altındaki değerleri öne çıkarır ve sunucunun sizinle emir gerçekleşmesi arasındaki temel unsur olduğunu ima eder. Neredeyse tüm bireysel kullanıcı botları için bu doğru değildir.

Emriniz, botunuzdan borsanın veya broker uç noktasının adresine public internet üzerinden gider. Bu yol, fiziksel mesafe ve sağlayıcınız ile karşı tarafın sağlayıcısı arasındaki peering tarafından belirlenir. Frankfurt'taki bir sunucu Tokyo'daki bir uç noktayla iletişim kurduğunda, CPU ne kadar hızlı olursa olsun gidiş-dönüş için yaklaşık 250 milisaniye gerekir. Ardından brokerın kendi sistemleri kuyruk, risk kontrolleri ve hız sınırlarını ekler. Bireysel hesaplarda bu süreler genellikle onlarca veya yüzlerce milisaniye olarak ölçülür.

Tahmin etmek yerine ölçüm yapın. curl, gerçek bir uç nokta için bağlantı ve ilk bayt sürelerini raporlar:

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

Bunu, karar vermeden önce aday bir sunucudan çalıştırın. connect değeri 0.180 saniyeyse yanlış kıtadasınız ve bunu düzeltmek gerekir. connect değeri 0.004 saniye, ttfb değeri 0.140 saniyeyse kalan gecikme brokerın işlem süresinden kaynaklanır. Hiçbir sunucu değişikliği bunu etkilemez.

Peki sunucu ne zaman önem taşır? Borsa sistemiyle aynı tesiste barındırıldığınızda veya borsaya cross-connect üzerinden bağlandığınızda ve kuyruk konumu için rekabet ettiğinizde önem taşır. Bu, farklı bütçeye sahip farklı bir iştir. Kendi kodunuz darboğaz oluşturduğunda da önem taşır. Her tick işleminde göstergeleri tüm geçmiş üzerinde yeniden hesaplayan bir bot, döngü başına 200 milisaniye CPU süresi harcayabilir. Bu, ücretsiz olarak kontrol edebileceğiniz gerçek bir gecikmedir. Daha hızlı bir sunucu aramadan önce döngünün profilini çıkarın.

Seçtiğiniz sunucuda önemli olan unsurlar coğrafi konum, kararlı ağ bağlantısı ve OOM killer'ın hiçbir zaman devreye girmemesini sağlayacak yeterli bellektir. Temmuz 2026 itibarıyla, bellekte birkaç yüz sembol tutan tek stratejili bir Python botu 2 GB RAM ve 2 vCPU ile rahatça çalışır. Tick geçmişini yerel bir veritabanında tutuyorsanız daha fazla bellek ekleyin.

Canlı kullanıma geçiş öncesi kısa kontrol listesi

1. systemctl is-enabled tradingbot, enabled çıktısını verir ve hizmet sudo reboot sonrasında çalışmaya devam eder.
2. chronyc tracking, sistem saati farkının birkaç milisaniyenin altında olduğunu bildirir.
3. API key işlem yapma iznine sahip olmalıdır. Para çekme izni olmamalıdır. Borsa destekliyorsa bir IP allowlist tanımlanmalıdır.
4. sudo systemctl kill -s SIGKILL tradingbot ile işlemi sonlandırmak, işlemi RestartSec içinde yeniden başlatır.
5. Botu kasıtlı olarak durdurduğunuzda heartbeat monitor, bir aralık içinde sizi uyarır.
6. Logların boyutu sınırlandırılmıştır ve root dosya sisteminde df -h içinde yeterli boş alan vardır.

Gerçek para kullanmadan önce sistemi bir hafta boyunca borsanın sandbox ortamında veya paper mode ile çalıştırın. Yukarıdaki maddelerin her biri bu hafta içinde en az bir kez başarısız olur. Haftanın amacı budur.

FAQ

Bir trading botu düşük gecikmeli veya bare metal sunucuya ihtiyaç duyar mı?

Yalnızca aynı venue üzerinde diğer otomatik katılımcılara karşı işlem yürütme hızı açısından rekabet ediliyorsa gerekir. Bu durumda genellikle genel amaçlı bir VPS yerine colocation kullanılır. Perakende kullanım amaçlı bir botta gidiş-dönüş süresini coğrafi konum ve broker'ın kendi işlemleri belirler. Bu nedenle daha hızlı bir hizmet için ödeme yapmadan önce API endpoint'ine yakın bir sunucu seçilmeli ve curl ile mtr kullanılarak ölçüm yapılmalıdır.

Bir trading botu ne kadar RAM ve CPU gerektirir?

Tek strateji kullanan botların çoğu ağ ile sınırlıdır ve olaylar arasında boştadır. Temmuz 2026 itibarıyla 2 vCPU ve 2 GB RAM, birkaç yüz enstrümanı izleyen bir Python botu için yeterlidir. Tick geçmişi işlem içinde tutulduğunda veya yerel bir veritabanı çalıştırıldığında bellek kısıt haline gelir. Bu nedenle tahmin yürütmek yerine free -h ve journal izlenmeli, OOM kill mesajları aranmalıdır.

Borsa API'si istekleri neden timestamp hatasıyla reddediyor?

Sunucu saatinin sapması, borsanın imzalama penceresinin dışına çıkmıştır. Bu genellikle birkaç saniyelik bir sapmadır. chrony kurulmalı, chronyc tracking çıktısında küçük bir System time offset değeri ve senkronize edilmiş leap durumu doğrulanmalıdır. Ayrıca daylight saving değişikliğinin saati kaydırmaması için makine UTC olarak ayarlanmalıdır. API key döndürmek saat sorununu çözmez.

Botun gece boyunca bilgim dışında durmasını nasıl önleyebilirim?

Bot, Restart=always ve StartLimitIntervalSec=0 kullanılarak systemd altında çalıştırılmalıdır. Böylece crash loop kalıcı olarak durmak yerine yeniden denemeye devam eder. Ardından botun her başarılı loop'un sonunda gönderdiği bir heartbeat eklenmelidir. Restart işlemi süreci yönetir. Heartbeat ise sürecin çalışır durumda olmasına rağmen takıldığı durumu yakalar.

Botu ve izleme sistemimi aynı VPS üzerinde çalıştırabilir miyim?

Çalıştırılabilir, ancak kritik gün geldiğinde izleme sistemi yanıltıcı olur. Çünkü botu durduran bir kesinti, izleme sistemini de devre dışı bırakır. Alerting ayrı bir makinede tutulmalıdır. İdeal olarak farklı bir provider veya region kullanılmalıdır. Botun sunucusu yalnızca bot ve logları için kullanılmalıdır.