Brazil-এ VPS Hosting: কখন দেশেই Server রাখবেন?

আপনার server কি Brazil-এ হওয়া উচিত?

আপনার অধিকাংশ user যদি Brazil-এ থাকেন এবং আপনার application round-trip time-এর প্রতি সংবেদনশীল হয়, তাহলে Brazil-এ VPS hosting-এর জন্য অর্থ দেওয়া যুক্তিযুক্ত। আপনার audience-এর অধিকাংশ যদি North America বা Europe-এ থাকে, তাহলে এটি ভুল পছন্দ। কারণ São Paulo-তে থাকা server ওই user-দের জন্য response ধীর করে। এই page-এর বাকি অংশে দেখানো হয়েছে, আপনি কোন পরিস্থিতিতে আছেন তা কীভাবে বুঝবেন এবং অন্য কেউ প্রকাশ করা কোনো সংখ্যার ওপর নির্ভর না করে নিজেই উত্তরটি কীভাবে যাচাই করবেন।

Virtual private server বা VPS হলো একটি নির্দিষ্ট শহরের নির্দিষ্ট building-এ থাকা physical machine-এর একটি ভাগ। এই term নতুন হলে, VPS আসলে কী, তা দিয়ে শুরু করুন এবং পরে এখানে ফিরে আসুন। Migration ছাড়া পরে VPS-এর building-এর location পরিবর্তন করা যায় না। তাই এটি নিয়ে এক ঘণ্টা ভেবে সিদ্ধান্ত নেওয়া উচিত।

Brazil-কে সেবা দেওয়া অধিকাংশ team Miami বা Dallas থেকে তা করে। এই default-এর বাস্তব কারণ আছে। দুই দশক ধরে South America থেকে বের হওয়া প্রায় সব submarine cable Florida-তে এসে উঠেছে। ফলে Miami পুরো region-এর network hub হয়ে ওঠে এবং প্রতিটি provider সেখান থেকে service বিক্রি করত। Latin America-এর কিছু অংশের জন্য এটি এখনও যুক্তিযুক্ত পছন্দ। তবে Brazil-এর জন্য এটি আর স্বয়ংক্রিয়ভাবে সঠিক উত্তর নয়।

ব্রাজিলের ভিতরে কার সার্ভার প্রয়োজন

চারটি গোষ্ঠী ব্রাজিলের ভেতরে hosting করলে বাস্তব সুবিধা পায়।

• আপনার ব্যবহারকারীরা ব্রাজিলে কেন্দ্রীভূত। কিছু customer ব্রাজিলের, এমন অস্পষ্ট ধারণার ওপর নির্ভর করবেন না। আপনার analytics-এ country breakdown খুলুন। Brazil যদি আপনার sessions-এর এক-পঞ্চমাংশ হয়, তাহলে এটি global latency-এর ক্ষেত্রে সামান্য প্রভাব। Brazil যদি sessions-এর 70 percent হয়, তাহলে এটি আপনার infrastructure-এর প্রধান বিবেচনা।
• প্রতিটি user action-এর জন্য একটি round trip লাগে। Live chat, multiplayer game session, video call signalling এবং প্রতিটি click-এ query চালানো dashboard। এগুলোতে দূরত্বের প্রভাব সরাসরি পড়ে। কোনো পরিমাণ caching এই প্রভাব পুরোপুরি আড়াল করতে পারে না।
• আপনি Southern Cone-এও service দেন। Argentina, Uruguay, Paraguay এবং Chile-এর সবগুলোই United States-এর যেকোনো শহরের তুলনায় São Paulo-এর কাছাকাছি।
• কোনো Brazilian customer বা auditor জানতে চান data কোথায় থাকে। নিচের LGPD section দেখুন। এই requirement আইন অপেক্ষা contract-এ বেশি লেখা থাকে।

Bandwidth সাধারণত সমস্যা নয়। Connection স্থিতিশীল হওয়ার পরে Miami থেকে একটি 2 MB page download করার গতি São Paulo থেকে download করার গতির প্রায় সমান। আসল খরচ হয় তার আগের round trip-গুলোতে। একটি নতুন HTTPS connection খোলার সময় TCP handshake-এর জন্য একটি round trip এবং TLS handshake-এর জন্য আরেকটি round trip লাগে (TLS-এর অর্থ transport layer security, অর্থাৎ https-এর পেছনে থাকা encryption)। এরপর request এবং তার response-এর জন্য আরও একটি round trip লাগে। তাই প্রথম byte আসার আগে browser প্রায় তিনটি round trip-এর জন্য অপেক্ষা করে। Round trip time বা RTT যদি 12 ms হয়, তাহলে সময় লাগে প্রায় 36 ms। RTT 120 ms হলে সময় লাগে প্রায় 360 ms। এই সময়ে আপনার application এখনো কোনো কাজ করেনি। বিশটি পরস্পরনির্ভর API call করা একটি single-page app-কে আরও বিশবার এই RTT-এর খরচ দিতে হয়।

দূরত্বের প্রকৃত খরচ

কাচের ভেতর আলো প্রতি সেকেন্ডে প্রায় 200,000 km বেগে চলে, যা vacuum-এর ভেতর আলোর গতির প্রায় দুই-তৃতীয়াংশ। তাই মাথায় হিসাব করার মতো একটি নিয়ম হলো: fibre-এর প্রতি 1,000 km-এ round trip time প্রায় 10 ms। Fibre সরলরেখায় স্থাপিত হয় না। তাই বাস্তব পথ সাধারণত দুটি শহরের মধ্যকার সরল দূরত্বের 1.3 থেকে 1.5 গুণ হয়। নিচের হিসাবগুলোতে 1.4 ধরা হয়েছে।

[
  {
    "label": "Rio de Janeiro, 360 km",
    "straight_line_ms": 3.6,
    "real_path_ms": 5
  },
  {
    "label": "Porto Alegre, 850 km",
    "straight_line_ms": 8.5,
    "real_path_ms": 12
  },
  {
    "label": "Buenos Aires, 1680 km",
    "straight_line_ms": 16.8,
    "real_path_ms": 24
  },
  {
    "label": "Fortaleza, 2370 km",
    "straight_line_ms": 23.7,
    "real_path_ms": 33
  },
  {
    "label": "Miami, 6570 km",
    "straight_line_ms": 65.7,
    "real_path_ms": 92
  },
  {
    "label": "Dallas, 7670 km",
    "straight_line_ms": 76.7,
    "real_path_ms": 107
  },
  {
    "label": "Lisbon, 7930 km",
    "straight_line_ms": 79.3,
    "real_path_ms": 111
  },
  {
    "label": "Frankfurt, 9800 km",
    "straight_line_ms": 98.0,
    "real_path_ms": 137
  }
]

এগুলো ন্যূনতম সীমা, পূর্বাভাস নয়। কোনো ক্রয় করা সরঞ্জাম packet-কে এই সীমার চেয়ে দ্রুত পাঠাতে পারে না, কারণ সীমাটি glass-এর ভেতর আলোর গতির দ্বারা নির্ধারিত। Router hop এবং বাড়ি বা mobile connection-এ পৌঁছানোর last mile-এর কারণে মাপা RTT সাধারণত এই সীমার চেয়ে 1.2 থেকে 1.6 গুণ বেশি হয়।

চার্টটি এভাবে পড়ুন। Rio-এর কোনো user São Paulo-এর server-এর সঙ্গে যোগাযোগ করলে প্রায় 5 ms-এর চেয়ে কম latency পাওয়া সম্ভব নয়। একই user Miami-এর server-এর সঙ্গে যোগাযোগ করলে প্রায় 92 ms-এর চেয়ে কম latency পাওয়া সম্ভব নয়, এবং বাস্তবে latency সহজেই 100 ms-এর বেশি হবে। নতুন HTTPS connection-এর তিনটি round trip-এ এই পার্থক্যকে গুণ করলে প্রথম page load-এ মোট সময়ের প্রায় এক সেকেন্ড চলে যায়। Frankfurt-এর ক্ষেত্রে ন্যূনতম সীমা 137 ms, তাই এখানে যুক্তিটি আর সূক্ষ্ম থাকে না।

নিজে পরিমাপ করুন, প্রকাশিত টেবিলের ওপর নির্ভর করবেন না

গুরুত্বপূর্ণ একমাত্র সংখ্যা হলো আপনার ব্যবহারকারীরা যে ফল পান। এটি জানতে একটি বিকেলই যথেষ্ট।

• ব্যবহারকারীরা যেখান থেকে সংযোগ করেন, সেখান থেকে পরিমাপ করুন। Berlin-এ থাকা আপনার laptop Recife-এ থাকা কোনো phone-এর সংযোগ সম্পর্কে কিছুই জানায় না। দুইজন প্রকৃত ব্যবহারকারীকে একটি test চালাতে বলুন। অথবা RIPE Atlas-এর মতো একটি probe network ব্যবহার করুন। এতে Brazilian ISP network-এর ভেতরে probe থাকে। অনুরোধ করলে সেগুলো থেকে ping বা traceroute চালানো যায়।
• কখনো একটি packet-এর ওপর নির্ভর করবেন না; median ব্যবহার করুন। ping -c 100 চালিয়ে median পড়ুন। একটি packet একটি নির্দিষ্ট queue-এর অবস্থা ধরে, কিন্তু connection সম্পর্কে নির্ভরযোগ্য তথ্য দেয় না।
• traceroute-এর পরিবর্তে mtr ব্যবহার করুন। এটি ধারাবাহিকভাবে চলে এবং প্রতিটি hop-এর loss ও latency জানায়। ফলে কোন hop 90 ms যোগ করছে, তা নির্দিষ্টভাবে দেখা যায়।
• শুধু ping নয়, first byte পাওয়া পর্যন্ত সময়ও পরিমাপ করুন। curl -w DNS, connect, TLS এবং first-byte timing আলাদাভাবে দেখায়। শেষের timing-ই ব্যবহারকারী বাস্তবে যতক্ষণ অপেক্ষা করেন, তার কাছাকাছি।
• peak সময়ে test করুন। Brazilian residential network-এ স্থানীয় সময় আনুমানিক 20:00 থেকে 23:00 পর্যন্ত সবচেয়ে বেশি ব্যস্ততা থাকে। 03:00-এ করা measurement সব provider-কেই বাস্তবের চেয়ে ভালো দেখায়।
• migrate করার আগে ভাড়া নিয়ে পরীক্ষা করুন। এক মাসের জন্য সবচেয়ে ছোট plan নিয়ে তাতে আপনার app-এর একটি copy চালান। যেকোনো website-এর chart-এর চেয়ে এটি সিদ্ধান্ত নিতে বেশি কার্যকর।

route-এর পরিবর্তে machine পরীক্ষা করার ক্ষেত্রেও একই পদ্ধতি প্রযোজ্য। VPS সঠিকভাবে benchmark করা-এ disk ও CPU সংক্রান্ত বিষয় ব্যাখ্যা করা হয়েছে। এটি network distance থেকে আলাদা একটি প্রশ্ন। এক মাসের বেশি সময়ের কোনো চুক্তি করার আগে দুটিই পরীক্ষা করুন।

ব্রাজিলে কোথায় হোস্ট করবেন

প্রায় সব ক্ষেত্রেই São Paulo বেছে নিন।

ব্রাজিলের নেটওয়ার্কগুলো NIC.br পরিচালিত জাতীয় Internet Exchange IX.br-এ একে অপরের সঙ্গে সংযুক্ত হয়। Internet Exchange Point বা IXP হলো এমন একটি স্থান, যেখানে নেটওয়ার্কগুলো তৃতীয় পক্ষকে traffic বহনের জন্য অর্থ না দিয়ে সরাসরি একে অপরের সঙ্গে সংযুক্ত হয়। São Paulo site traffic এবং participant-এর সংখ্যার হিসাবে বিশ্বের বৃহত্তম IXP। 2026 সালের June মাসে এখানে traffic 30 Tbps ছাড়িয়ে peak করেছিল। ব্রাজিলের প্রায় সব consumer ISP এখানে উপস্থিত। São Paulo peering-এর পেছনে থাকা একটি server খুব কম hop-এ ব্রাজিলের user-দের কাছে পৌঁছায়।

Rio, Recife বা Porto Alegre-তে থাকা server সাধারণত São Paulo-এর মাধ্যমে ব্রাজিলের অধিকাংশ user-এর কাছে পৌঁছায়। তাই অতিরিক্ত hop-এর জন্য খরচ হয়, কিন্তু এর বিনিময়ে কোনো সুবিধা পাওয়া যায় না। Fortaleza একটি গুরুত্বপূর্ণ ব্যতিক্রম। এখানেই submarine cable-গুলো land করে। এর মধ্যে EllaLink-ও রয়েছে, যা 2021 সাল থেকে Fortaleza থেকে Portugal-এর Sines পর্যন্ত সরাসরি সংযোগ চালু রেখেছে এবং Europe route থেকে North America হয়ে যাওয়ার অতিরিক্ত পথ সরিয়ে দিয়েছে। আপনার traffic যদি প্রধানত transatlantic হয়, Fortaleza São Paulo-এর চেয়ে ভালো হতে পারে। আপনার traffic যদি Brazilian হয়, তাহলে তা হবে না।

কেনার আগে যেকোনো provider-কে একটি প্রশ্ন করুন। আপনি কি IX.br São Paulo-এ peering করছেন, নাকি একটি upstream থেকে transit কিনছেন? একটি transit provider দ্বারা পরিচালিত São Paulo address থেকেও Brazilian user-এর packet Miami ঘুরে আবার ফিরে আসতে পারে। এটি কেবল তাত্ত্বিক বিষয় নয়: Brazilian connection থেকে provider প্রকাশিত test IP-তে mtr চালান। hop list ত্রিশ সেকেন্ডের মধ্যে প্রকৃত routing দেখিয়ে দেবে।

LGPD বিবেচনা

LGPD হলো Lei Geral de Proteção de Dados, অর্থাৎ Brazil-এর সাধারণ data protection আইন। এটি 2020 সাল থেকে কার্যকর এবং ANPD (Autoridade Nacional de Proteção de Dados, national data protection authority) আইনটি প্রয়োগ করে। এটি Europe-এর GDPR-এর সঙ্গে ঘনিষ্ঠভাবে সামঞ্জস্যপূর্ণ।

এখানেই সাধারণত ভুল বোঝাবুঝি হয়। LGPD অনুযায়ী personal data Brazil-এর ভেতরে রাখতেই হবে—এমন কোনো বাধ্যবাধকতা নেই। এতে কোনো সাধারণ data localisation rule নেই। তবে articles 33 থেকে 36-এ international transfer নিয়ন্ত্রণ করা হয়েছে। August 2024-এ প্রকাশিত Resolution 19/2024-এর মাধ্যমে ANPD একটি international transfer regulation এবং standard contractual clauses অনুমোদন করেছে। বিদ্যমান contract-গুলো মানিয়ে নেওয়ার সময়সীমা August 2025-এ শেষ হয়েছে। এখন contract-এর ভিত্তিতে Brazil-এর বাইরে data transfer করতে হলে ওই clauses ব্যবহার করতে হবে, অথবা নির্দিষ্ট ক্ষেত্রে ANPD অনুমোদিত clauses ব্যবহার করতে হবে।

তাই বিষয়টি আইনগত প্রয়োজনের চেয়ে procurement হিসেবে ব্যাখ্যা করাই সঠিক। Brazil-এ hosting করলে ওই data-এর ক্ষেত্রে transfer-এর প্রশ্ন ওঠে না। ফলে একটি document রক্ষণাবেক্ষণ এবং audit-এর সময় একটি control-এর প্রমাণ দেওয়ার প্রয়োজন কমে। কোনো Brazilian enterprise বা public-sector buyer server কোথায় রয়েছে জানতে চাইলে সাধারণত তারা এই বিষয়টিই জানতে চান। তাদের requirement সাধারণত statute নয়, নিজেদের contract থেকে আসে। এখানে কোনো legal advice দেওয়া হচ্ছে না। আপনার নির্দিষ্ট ক্ষেত্রে Brazilian data protection lawyer একটি call-এই উত্তর দিতে পারবেন।

যেসব ক্ষেত্রে Brazil-এ VPS hosting বেছে নেওয়া সঠিক নয়

Internet-এর অধিকাংশ workload-এর ক্ষেত্রে এটি ভুল পছন্দ। বিষয়টি স্পষ্টভাবে বলুন এবং এগিয়ে যান।

• আপনার audience মূলত North American বা European। São Paulo-এর server তাদের জন্য প্রায় 100 ms latency যোগ করে, কিন্তু কোনো সুবিধা দেয় না। মাঝামাঝি অবস্থানের Dallas VPS United States কভার করে, আর Toronto VPS Canada এবং উত্তর-পূর্বাঞ্চল কভার করে।
• আপনার Latin American user-রা equator-এর উত্তরে। Bogotá São Paulo থেকে প্রায় 4,300 km এবং Miami থেকে প্রায় 2,400 km দূরে। Mexico City Brazil-এর যেকোনো স্থানের তুলনায় Dallas-এর কাছাকাছি। Continent-এর নাম নয়, দূরত্বই এখানে সিদ্ধান্ত নির্ধারণ করে।
• Workload-এর কোনো অংশ round trip-এর জন্য অপেক্ষা করে না। CI build, backup target, scraper এবং nightly cron job কোন শহরে চলে, তা নিয়ে চিন্তা করে না। যেখানকার খরচ কম, সেখানেই এগুলো চালান।
• Bottleneck আপনার নিজের code। 800 ms সময় নেওয়া কোনো query অন্য দেশে নিলেই দ্রুত হয় না। আগে profile করুন। ধীর application-কে user-দের কাছাকাছি সরালে এমন একটি ধীর application পাওয়া যায়, যা কেবল user-দের কাছাকাছি চলে।

দেশের অভ্যন্তরে সক্ষমতার খরচ

একই specification-এর জন্য Brazil-এ বেশি খরচ করার প্রস্তুতি রাখুন। এর পেছনে দুটি কারণ কাজ করে। Brazil-এ আমদানি করা server hardware-এর ওপর import duty এবং state level tax প্রযোজ্য হয়। তাই rack-এ বসানোর আগেই operator-এর কাছে machine-এর খরচ বেড়ে যায়। IP transit-এর খরচও Ashburn বা Amsterdam-এর তুলনায় বেশি। ওই স্থানগুলোতে bandwidth প্রায় commodity-এর মতো সুলভ। এই অতিরিক্ত খরচ কাঠামোগত। এটি কারও মনগড়া markup নয়।

শুধু headline price নয়, মোট খরচের ভিত্তিতে তুলনা করুন। বিদেশের সস্তা plan ব্যবহার করে যদি content delivery network এবং দ্বিতীয় region কিনতে হয়, তাহলে সেটি আসলে সস্তা নয়। একটি VPS-এর প্রকৃত খরচের বিস্তারিত হিসাব-এ pricing page-এ দেখা যায় না এমন বিলের অংশগুলো ব্যাখ্যা করা হয়েছে। আপনার আগ্রহের একটি অংশ যদি speed-এর বদলে compliance posture নিয়ে হয়, তাহলে যে paperwork এড়াতে পারবেন তার খরচও হিসাব করুন।

এক বিকেলেই সিদ্ধান্ত নিন

1. আপনার analytics খুলে দেশ অনুযায়ী session দেখুন। Brazil থেকে আসা session এক-চতুর্থাংশের কম হলে এখানেই থামুন এবং বর্তমান সেটআপই রাখুন।
2. 21:00 স্থানীয় সময়ে Brazil-এর একটি connection থেকে বর্তমান server-এ time to first byte মাপুন।
3. application-এর একটি copy ছোট একটি São Paulo plan-এ রাখুন এবং ঠিক একইভাবে আবার মাপুন।
4. দুইটি সংখ্যার পার্থক্যকে এক বছরের price difference-এর সঙ্গে তুলনা করে সিদ্ধান্ত নিন।

দুইটি measurement হাতে থাকলে উত্তরটি সাধারণত স্পষ্ট হয়ে যায়। তখন সিদ্ধান্তটি কোনো map নয়, আপনার user-দের ভিত্তিতে নেওয়া হয়।

FAQ

Miami থেকে São Paulo-এ সরালে বাস্তবে কত latency কমবে?

দূরত্বের কারণে ন্যূনতম latency প্রায় 92 ms Miami পর্যন্ত, যেখানে São Paulo ও Rio corridor-এর ভেতরে এটি প্রায় 5 ms। তাই বাস্তব routing ধরলে round-trip time সাধারণত 80 থেকে 110 ms কমে। এর প্রভাব ধারণার চেয়ে বেশি, কারণ নতুন HTTPS connection-এ page-এর প্রথম byte পাওয়ার আগে handshake-এর জন্য প্রায় তিনটি round trip লাগে। এই range যাচাই না করে গ্রহণ করবেন না। peak hour-এ Brazilian connection থেকে উভয় server-এর বিরুদ্ধে curl -w চালান। দশ মিনিটের মধ্যে নিজের পরিমাপ পেয়ে যাবেন।

LGPD কি আমাকে Brazil-এ host করতে বাধ্য করে?

না। LGPD-তে সাধারণ data localisation-এর কোনো নিয়ম নেই। এটি articles 33 থেকে 36-এ international transfer নিয়ন্ত্রণ করে। Resolution 19/2024-এর পর contract-নির্ভর transfer-এর ক্ষেত্রে ANPD অনুমোদিত standard contractual clauses ব্যবহার করতে হয়। এই clauses মানিয়ে নেওয়ার সময়সীমা August 2025-এ শেষ হয়েছে। Brazil-এর ভেতরে hosting করলে ওই data-এর transfer সংক্রান্ত প্রশ্ন ওঠে না। এটি paperwork ও audit-এর সুবিধা, আইনি বাধ্যবাধকতা নয়। কোনো Brazilian customer local hosting চাইলে সেই requirement প্রায় সব ক্ষেত্রেই তাদের contract থেকে আসে। আপনার নির্দিষ্ট পরিস্থিতি Brazilian lawyer-এর সঙ্গে নিশ্চিত করুন।

CDN কি যথেষ্ট, নাকি server-ও Brazil-এ রাখতে হবে?

Content delivery network (CDN) আপনার file-এর copy ব্যবহারকারীদের কাছের শহরে cache করে। তাই এটি image ও script-এর মতো static asset-এর সমস্যা সমাধান করে। কিন্তু যে request-কে database পর্যন্ত যেতে হয়, তার ক্ষেত্রে CDN কিছু করে না। আপনার page যদি প্রধানত static হয়, তাহলে Brazilian point of presence-সহ CDN origin সরানোর চেয়ে অনেক কম খরচে সমস্যার সমাধান করতে পারে। প্রতিটি page view যদি query বা payment call চালায়, তাহলে user যে latency অনুভব করেন, তা origin server-এর অবস্থান নির্ধারণ করে। সিদ্ধান্ত নেওয়ার আগে আপনার response time-এর কত অংশ dynamic কাজের কারণে হচ্ছে তা মাপুন।

Brazil-এর কোন শহর বেছে নেওয়া উচিত?

প্রায় সব ক্ষেত্রেই São Paulo। কারণ Brazilian network-গুলো সেখানে peer করে, এবং IX.br São Paulo traffic ও participant-এর হিসাবে বিশ্বের বৃহত্তম internet exchange point। Brazil-এর অন্য কোথাও থাকা server সাধারণত São Paulo হয়েই Brazilian user-দের কাছে পৌঁছায়। ফলে অতিরিক্ত hop আপনার latency বাড়ায়, কিন্তু কোনো সুবিধা দেয় না। প্রকৃত ব্যতিক্রম Fortaleza। এটি submarine cable landing point এবং সরাসরি Fortaleza থেকে Sines cable-এর মাধ্যমে Europe-এ যাওয়ার সংক্ষিপ্ততর পথ। আপনার traffic প্রধানত transatlantic হলেই Fortaleza বেছে নিন।

Brazil-এর একটি Brazilian VPS একই plan-এর United States সংস্করণের চেয়ে বেশি খরচ হয় কেন?

Brazil-এ imported server hardware-এর ওপর import duty ও state level tax আছে। তাই machine চালু করার আগেই operator-এর খরচ বেড়ে যায়। বড় United States ও European hub-এর তুলনায় IP transit-ও বেশি ব্যয়বহুল। এই অতিরিক্ত খরচ Brazilian data centre থেকে বিক্রি হওয়া প্রতিটি plan-এর দামে যোগ হয়। Dallas-এর কোনো plan-এর তালিকামূল্যের সঙ্গে তুলনা না করে, অন্যথায় যে workaround কিনতে হতো—যেমন CDN এবং দ্বিতীয় region—তার খরচের সঙ্গে তুলনা করুন।