Brazil मध्ये VPS hosting कधी घ्यावे?

तुमचा सर्व्हर Brazil मध्ये असावा का?

तुमचे बहुतेक वापरकर्ते Brazil मध्ये असतील आणि तुमच्या अॅप्लिकेशनच्या कार्यक्षमतेवर round trip time चा परिणाम होत असेल, तर Brazil मधील VPS hosting साठी पैसे देणे योग्य ठरते. तुमचे प्रेक्षक प्रामुख्याने North America किंवा Europe मध्ये असतील, तर हा चुकीचा पर्याय आहे, कारण São Paulo मधील सर्व्हर त्या वापरकर्त्यांसाठी प्रतिसादाचा वेळ वाढवतो. तुम्ही कोणत्या परिस्थितीत आहात हे ओळखण्याची आणि कोणीतरी प्रकाशित केलेल्या आकड्यावर विश्वास ठेवण्याऐवजी स्वतः उत्तर तपासण्याची पद्धत या पृष्ठाच्या उर्वरित भागात दिली आहे.

Virtual private server किंवा VPS म्हणजे विशिष्ट शहरातील विशिष्ट इमारतीत असलेल्या physical machine चा एक स्वतंत्र भाग. हा शब्द नवीन असल्यास, VPS प्रत्यक्षात काय आहे ते आधी समजून घ्या आणि नंतर येथे परत या. त्या इमारतीचे स्थान migration केल्याशिवाय नंतर बदलता येत नाही. त्यामुळे त्याचा विचार करण्यासाठी एक तास देणे योग्य आहे.

Brazil ला सेवा देणारे बहुतेक संघ Miami किंवा Dallas येथून सेवा चालवतात. या default मागे ठोस कारण आहे. दोन दशकांपर्यंत South America मधून बाहेर जाणाऱ्या जवळजवळ सर्व submarine cables Florida येथे येऊन जोडल्या जात होत्या. त्यामुळे संपूर्ण प्रदेशासाठी Miami हे network hub बनले आणि प्रत्येक provider तेथून सेवा विकू लागला. Latin America मधील काही भागांसाठी हा आजही योग्य पर्याय आहे. मात्र Brazil साठी तो आपोआप योग्य पर्याय राहिलेला नाही.

ब्राझीलमध्ये सर्व्हर कोणाला आवश्यक आहे

चार गटांना देशांतर्गत hosting मधून प्रत्यक्ष फायदा होतो.

• तुमचे वापरकर्ते ब्राझीलमध्ये मोठ्या प्रमाणावर आहेत. काही ग्राहक ब्राझिलियन आहेत असे अस्पष्ट अनुमान पुरेसे नाही. तुमच्या analytics मधील country breakdown उघडा. तुमच्या sessions पैकी ब्राझीलचा वाटा एक-पंचमांश असेल, तर जागतिक latency च्या दृष्टीने हा नगण्य फरक आहे. पण त्यांचा वाटा 70 percent असेल, तर तुमच्या infrastructure संदर्भातील हीच मुख्य बाब आहे.
• प्रत्येक वापरकर्ता कृतीसाठी round trip लागतो. Live chat, multiplayer game sessions, video call signalling आणि प्रत्येक click वर query चालवणारे dashboards. या सेवांना अंतराचा परिणाम थेट जाणवतो. कितीही caching केले तरी तो परिणाम लपवता येत नाही.
• तुम्ही Southern Cone प्रदेशालाही सेवा देता. Argentina, Uruguay, Paraguay आणि Chile ही सर्व ठिकाणे United States मधील कोणत्याही शहरापेक्षा São Pauloच्या जवळ आहेत.
• ब्राझिलियन ग्राहक किंवा auditor डेटा कुठे ठेवला आहे असे विचारतो. खालील LGPD विभाग पहा. ही अट कायद्यात असण्यापेक्षा contract मध्ये नमूद केलेली असण्याची शक्यता अधिक असते.

Bandwidth क्वचितच समस्या असते. Connection स्थिर झाल्यानंतर 2 MB पृष्ठ Miamiहून किंवा São Pauloहून जवळपास समान वेगाने download होते. त्यापूर्वी होणाऱ्या round trips मध्ये खरा खर्च असतो. नवीन HTTPS connection उघडताना TCP handshake साठी एक round trip आणि TLS handshake साठी आणखी एक round trip लागतो (TLS म्हणजे transport layer security; https मागील encryption). त्यानंतर request आणि त्याच्या response साठी आणखी एक round trip लागतो. त्यामुळे पहिला byte येईपर्यंत browser साधारण तीन round trips ची वाट पाहतो. Round trip time, म्हणजे RTT, 12 ms असेल तर हा वेळ साधारण 36 ms असतो. RTT 120 ms असेल तर तो साधारण 360 ms असतो. या वेळेत तुमच्या application ने अद्याप कोणतेही काम केलेले नसते. Twenty dependent API calls करणाऱ्या single-page app ला हेच RTT आणखी twenty वेळा भरावे लागते.

अंतरामुळे प्रत्यक्षात किती खर्च होतो

काचेच्या फायबरमध्ये प्रकाशाचा वेग साधारण 200,000 km प्रति सेकंद असतो. निर्वातातील प्रकाशाच्या वेगाच्या हा सुमारे दोन-तृतीयांश आहे. त्यामुळे मनात करता येईल असा एक नियम मिळतो: फायबरच्या प्रत्येक 1,000 km अंतरासाठी round trip time साधारण 10 ms असतो. फायबर सरळ रेषेत टाकले जात नाही. त्यामुळे दोन शहरांमधील प्रत्यक्ष मार्ग साधारणपणे त्यांच्या सरळ रेषेतील अंतराच्या 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 ला या मर्यादेपेक्षा वेगाने पाठवू शकत नाहीत, कारण ही मर्यादा काचेतील प्रकाशाच्या वेगामुळे ठरते. मोजलेला RTT नेहमी या किमान आकड्यापेक्षा जास्त असतो. Router hops आणि घरगुती किंवा mobile connection पर्यंतचा last mile यामुळे तो साधारणपणे 1.2 ते 1.6 पट जास्त असतो.

आलेखाचा अर्थ असा समजा. Rio मधील user São Paulo मधील server शी संवाद साधत असेल, तर तो साधारण 5 ms पेक्षा कमी RTT मिळवू शकत नाही. तोच user Miami मधील server शी संवाद साधत असेल, तर RTT साधारण 92 ms पेक्षा कमी मिळू शकत नाही. प्रत्यक्षात तो सहजपणे 100 ms पेक्षा जास्त RTT पाहील. नवीन HTTPS connection साठी लागणाऱ्या तीन round trips ने हा फरक गुणला, तर पहिल्या page load मध्ये जवळपास एक पूर्ण सेकंद जातो. Frankfurt साठी किमान आकडा 137 ms आहे. त्यामुळे हा मुद्दा सूक्ष्म राहातच नाही.

स्वतः मोजमाप करा; प्रकाशित तक्त्यावर विश्वास ठेवू नका

महत्त्वाची संख्या म्हणजे तुमच्या वापरकर्त्यांना प्रत्यक्ष मिळणारी संख्या. ती तुम्ही एका दुपारी मिळवू शकता.

• वापरकर्ते जिथे आहेत तिथून मोजमाप करा. Berlin मधील तुमचा laptop Recife मधील फोनबद्दल काहीही सांगत नाही. दोन वास्तविक वापरकर्त्यांना चाचणी चालवण्यास सांगा किंवा RIPE Atlas सारखे probe network वापरा. त्याचे probes Brazilian ISP networks मध्ये असतात आणि विनंती केल्यावर तेथून ping किंवा traceroute चालवतात.
• नेहमी median वापरा; एका packet वर अवलंबून राहू नका. ping -c 100 चालवा आणि median वाचा. एका packet मुळे एका queue ची स्थिती दिसते; connection बद्दल त्यातून काहीही निष्पन्न होत नाही.
• traceroute पेक्षा mtr ला प्राधान्य द्या. ते सतत चालते आणि प्रत्येक hop साठी packet loss व latency दाखवते. त्यामुळे 90 ms विलंब नेमक्या कोणत्या hop मुळे जोडला गेला हे दिसते.
• केवळ ping नव्हे, तर first byte मिळेपर्यंतचा वेळ मोजा. curl -w DNS, connect, TLS आणि first-byte timings स्वतंत्रपणे दाखवते. यातील शेवटचा वेळ म्हणजे एखादी व्यक्ती प्रत्यक्षात वाट पाहत असलेला वेळ.
• peak वेळेत चाचणी करा. Brazilian residential networks मध्ये स्थानिक वेळेनुसार साधारण 20:00 ते 23:00 दरम्यान सर्वाधिक व्यस्तता असते. 03:00 वाजता केलेले मोजमाप प्रत्येक provider चे चित्र अनावश्यकपणे चांगले दाखवते.
• migration करण्यापूर्वी भाड्याने घेऊन पाहा. एका महिन्यासाठीचा सर्वात लहान plan घेऊन त्यावर तुमच्या अॅपची प्रत चालवा. कोणत्याही website वरील chart पेक्षा यामुळे निर्णय अधिक स्पष्ट होतो.

हीच शिस्त route ऐवजी machine साठीही लागू होते. VPS चे योग्य benchmarking मध्ये disk आणि CPU संदर्भातील बाबी दिल्या आहेत. हा network distance पेक्षा वेगळा प्रश्न आहे. एका महिन्यापेक्षा मोठ्या कालावधीसाठी काहीही निश्चित करण्यापूर्वी दोन्ही तपासा.

ब्राझीलमध्ये कुठे होस्ट करावे

जवळजवळ नेहमीच São Paulo.

Brazilian networks एकमेकांशी NIC.br द्वारे चालवल्या जाणाऱ्या राष्ट्रीय internet exchange IX.br येथे जोडले जातात. Internet exchange point किंवा IXP ही अशी जागा आहे जिथे networks एकमेकांशी थेट connect होतात. त्यामुळे त्यांच्या दरम्यान traffic वाहून नेण्यासाठी तृतीय पक्षाला पैसे द्यावे लागत नाहीत. São Paulo येथील site ही traffic आणि participants च्या संख्येनुसार जगातील सर्वात मोठी IXP आहे. June 2026 मध्ये तिचा peak 30 Tbps पेक्षा जास्त होता. जवळजवळ प्रत्येक Brazilian consumer ISP येथे उपस्थित आहे. São Paulo peering मागे असलेला server Brazilian users पर्यंत एका लहान hop मध्ये पोहोचतो.

Rio, Recife किंवा Porto Alegre मधील server देखील बहुतेक Brazilian users पर्यंत São Paulo मार्गेच पोहोचतो. त्यामुळे तुम्ही अतिरिक्त hop साठी पैसे देता, पण त्यातून काही विशेष फायदा मिळत नाही. Fortaleza हा लक्षात ठेवण्यासारखा अपवाद आहे. तेथे submarine cables land होतात. त्यात EllaLink चा समावेश आहे. हा cable 2021 पासून Fortaleza ते Sines in Portugal दरम्यान थेट चालतो आणि Europe route मधील North American detour काढून टाकतो. तुमचा 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 चे packets Miami मार्गे जाऊन परत येऊ शकतात. हे केवळ सैद्धांतिक शक्यता नाही. Brazilian connection वरून provider ने प्रकाशित केलेल्या test IP कडे mtr चालवा. Hop list तीस seconds मध्ये प्रत्यक्ष मार्ग दाखवते.

LGPD संबंधी विचार

LGPD म्हणजे Lei Geral de Proteção de Dados. हा ब्राझीलचा सामान्य data protection कायदा आहे. तो 2020 पासून लागू आहे आणि ANPD (Autoridade Nacional de Proteção de Dados, राष्ट्रीय data protection प्राधिकरण) त्याची अंमलबजावणी करते. हा कायदा युरोपच्या GDPR वर मोठ्या प्रमाणात आधारित आहे.

लोकांकडून होणारी मुख्य चूक येथे आहे. LGPD नुसार personal data ब्राझीलमध्येच ठेवणे आवश्यक नाही. त्यामध्ये सर्वसाधारण data localisation नियम नाही. मात्र articles 33 ते 36 मध्ये international transfer चे नियमन केले आहे. August 2024 मध्ये प्रकाशित Resolution 19/2024 द्वारे ANPD ने standard contractual clauses सह international transfer regulation मंजूर केले. Existing contracts मध्ये बदल करण्याची मुदत August 2025 मध्ये संपली. आता contract वर आधारित ब्राझीलबाहेरील transfer साठी या clauses वापरणे आवश्यक आहे. किंवा त्या विशिष्ट प्रकरणासाठी ANPD ने मंजूर केलेल्या clauses वापराव्या लागतात.

म्हणून याचे अचूक स्वरूप कायदेशीर प्रश्न नसून procurement संबंधी प्रश्न आहे. Brazil मध्ये hosting केल्यास त्या data साठी transfer चा प्रश्न निर्माण होत नाही. त्यामुळे देखरेखीसाठी ठेवायचा एक document कमी होतो आणि audit वेळी दाखवायचे एक control कमी होते. Brazilian enterprise किंवा public-sector buyer सर्व्हर कुठे आहेत असे विचारतो, तेव्हा बहुतेक वेळा त्याचा खरा प्रश्न हाच असतो. त्यांची requirement सामान्यतः statute मधून नव्हे, तर त्यांच्या स्वतःच्या contract मधून येते. येथे दिलेली माहिती legal advice नाही. तुमच्या विशिष्ट प्रकरणाचे उत्तर Brazilian data protection lawyer एका call मध्ये देऊ शकतो.

जेव्हा Brazil मधील VPS hosting निवडणे चुकीचे ठरते

इंटरनेटवरील बहुतेक workload साठी ही चुकीची निवड आहे. हे स्पष्टपणे सांगा आणि पुढे जा.

• तुमचे प्रेक्षक प्रामुख्याने North American किंवा European आहेत. São Paulo मधील server त्यांच्यासाठी सुमारे 100 ms अतिरिक्त latency निर्माण करतो आणि कोणताही फायदा देत नाही. Dallas मधील VPS संपूर्ण United States साठी मध्यवर्ती स्थान देते, तर Toronto मधील VPS Canada आणि ईशान्य भागासाठी योग्य आहे.
• तुमचे Latin American users equator च्या उत्तरेस आहेत. Bogotá हे São Paulo पासून साधारण 4,300 km आणि Miami पासून साधारण 2,400 km अंतरावर आहे. Mexico City हे Brazil मधील कोणत्याही ठिकाणापेक्षा Dallasच्या जवळ आहे. याचा निर्णय continent label घेत नाही; अंतर घेतो.
• तुमच्या workload मध्ये कोणतेही काम round trip ची वाट पाहत नाही. CI builds, backup targets, scrapers आणि nightly cron jobs कोणत्या शहरात चालतात याने त्यांना फरक पडत नाही. ते जिथे स्वस्त असतील तिथे खरेदी करा.
• तुमचा bottleneck तुमचा स्वतःचा code आहे. 800 ms घेणारी query वेगळ्या देशात हलवल्याने जलद होत नाही. आधी profile करा. slow application वापरकर्त्यांच्या जवळ हलवल्याने ती वापरकर्त्यांच्या जवळ असलेली slow applicationच राहते.

देशांतर्गत क्षमता खर्च

समान specifications साठी Brazil मध्ये अधिक पैसे मोजावे लागतील, अशी अपेक्षा ठेवा. यामागे दोन प्रमुख कारणे आहेत. Brazil मध्ये आयात केलेल्या server hardware वर import duty आणि state level tax लागू होतो. त्यामुळे मशीन rack मध्ये ठेवण्यापूर्वीच operator साठी तिची किंमत वाढते. IP transit चा खर्चही Ashburn किंवा Amsterdam पेक्षा जास्त असतो. त्या ठिकाणी bandwidth जवळपास commodity मानली जाते. हा अतिरिक्त खर्च संरचनात्मक आहे. तो कोणीतरी मनमानीने लावलेला markup नाही.

फक्त headline price न पाहता एकूण खर्चाची तुलना करा. परदेशातील स्वस्त plan मुळे content delivery network आणि दुसरा region घ्यावा लागत असेल, तर तो plan स्वस्त नाही. VPS च्या वास्तविक खर्चाचे सविस्तर विभाजन यामध्ये pricing page वर कधीही दिसत नसलेल्या बिलाच्या घटकांचा समावेश आहे. तुमच्या निर्णयामागे speed पेक्षा compliance posture महत्त्वाचे असेल, तर टाळता येणाऱ्या paperwork चा खर्चही मोजा.

दुपारीच निर्णय घ्या

1. तुमचे analytics उघडा आणि देशानुसार sessions पहा. Brazil मधून येणारे sessions एक-चतुर्थांशपेक्षा कमी असतील, तर येथेच थांबा आणि सध्याची रचना कायम ठेवा.
2. सध्याच्या server च्या तुलनेत, Brazil मधील connection वर स्थानिक वेळेनुसार 21:00 वाजता first byte मिळेपर्यंतचा वेळ मोजा.
3. अॅप्लिकेशनची एक प्रत लहान São Paulo plan वर ठेवा आणि अगदी त्याच पद्धतीने पुन्हा मोजमाप करा.
4. त्या दोन मोजमापांमधील फरकाची तुलना एका वर्षातील किंमतीच्या फरकाशी करा आणि निर्णय घ्या.

दोन्ही मोजमापे हातात आल्यानंतर उत्तर बहुतेक वेळा स्पष्ट असते. तो निर्णय नकाशाबद्दल नसून तुमच्या users बद्दल असतो.

FAQ

Miami वरून São Paulo येथे स्थलांतर केल्यावर प्रत्यक्षात किती latency वाचेल?

अंतरामुळे ठरणारी किमान मर्यादा Miami पर्यंत सुमारे 92 ms आहे. São Paulo आणि Rio corridor मध्ये ती सुमारे 5 ms आहे. त्यामुळे प्रत्यक्ष routing धरल्यास round trip time मध्ये साधारण 80 ते 110 ms बचत होते. हा फरक अपेक्षेपेक्षा अधिक महत्त्वाचा आहे. नवीन HTTPS connection मध्ये page चा पहिला byte मिळण्यापूर्वी handshake साठी साधारण तीन round trips लागतात. हा range गृहीत धरू नका. peak hour मध्ये Brazilian connection वरून दोन्ही servers साठी curl -w चालवा. दहा मिनिटांत तुमच्याकडे स्वतःचा आकडा असेल.

LGPD नुसार मला Brazil मध्येच host करणे आवश्यक आहे का?

नाही. LGPD मध्ये data localisation साठी कोणताही सामान्य नियम नाही. Articles 33 ते 36 मध्ये international transfer चे नियमन केले आहे. Resolution 19/2024 नंतर contract वर आधारित transfer साठी ANPD ने मंजूर केलेल्या standard contractual clauses वापरणे आवश्यक आहे. त्यासाठीची adaptation window August 2025 मध्ये बंद झाली. Brazil मध्ये hosting केल्यास त्या data साठी transfer चा प्रश्नच निर्माण होत नाही. हा paperwork आणि audit साठीचा लाभ आहे; कायदेशीर बंधन नाही. एखादा Brazilian customer local hosting वर आग्रह धरत असल्यास, ही अट जवळजवळ नेहमीच त्यांच्या contract मधून येते. तुमच्या प्रकरणाची पुष्टी Brazilian lawyer कडून करा.

CDN पुरेसे आहे का, की server देखील Brazil मध्ये असणे आवश्यक आहे?

Content delivery network (CDN) तुमच्या users जवळील शहरांमध्ये files च्या copies cache करते. त्यामुळे images आणि scripts सारख्या static assets ची समस्या सुटते. मात्र ज्या request ला database पर्यंत पोहोचावे लागते, त्यासाठी CDN काहीही करत नाही. तुमची pages प्रामुख्याने static असल्यास, Brazilian points of presence असलेला CDN origin हलवण्यापेक्षा खूप कमी खर्चात समस्या सोडवतो. प्रत्येक page view मध्ये query किंवा payment call चालत असल्यास, user ला जाणवणारा फरक origin server च्या location मुळे ठरतो. निवड करण्यापूर्वी तुमच्या response time पैकी dynamic भाग किती आहे ते मोजा.

Brazil मधील कोणते शहर निवडावे?

जवळजवळ प्रत्येक प्रकरणात São Paulo निवडा. Brazilian networks येथे peer करतात आणि IX.br São Paulo हे traffic आणि participants यांच्या संख्येनुसार जगातील सर्वात मोठे internet exchange point आहे. Brazil मधील इतर ठिकाणी असलेला server सामान्यतः Brazilian users पर्यंत São Paulo मार्गेच पोहोचतो. त्यामुळे अतिरिक्त hop चा खर्च होतो, पण त्यातून कोणताही लाभ मिळत नाही. Fortaleza हा एक महत्त्वाचा अपवाद आहे. ते submarine cable landing point आहे आणि direct Fortaleza to Sines cable मुळे Europe कडे जाणारा मार्ग कमी आहे. तुमचा traffic मुख्यतः transatlantic असल्यासच Fortaleza निवडा.

Brazil मधील VPS ची किंमत United States मधील त्याच plan पेक्षा जास्त का असते?

Brazil मध्ये imported server hardware वर import duty आणि state level tax लागतो. त्यामुळे machine सुरू करण्यापूर्वीच operator चा खर्च वाढतो. तसेच IP transit ची किंमत मोठ्या United States आणि European hubs पेक्षा जास्त असते. हा अतिरिक्त खर्च Brazilian data centre मधून विकल्या जाणाऱ्या प्रत्येक plan च्या किमतीत येतो. Dallas मधील plan च्या sticker price शी तुलना करण्याऐवजी, अन्यथा घ्याव्या लागणाऱ्या उपायांच्या खर्चाशी तुलना करा. उदाहरणार्थ, CDN आणि second region यांचा एकत्रित खर्च विचारात घ्या.