เลือกเช่า VPS ใน New York ดีไหม? ปัจจัยสำคัญที่ควรทราบ

สิ่งที่คุณได้รับจริงจากการใช้ VPS ใน New York

VPS ใน New York ตั้งอยู่ในหนึ่งในตลาด interconnection ขนาดใหญ่สองแห่งบนชายฝั่งตะวันออกของสหรัฐอเมริกา อีกแห่งหนึ่งคือ Ashburn รัฐ Virginia สิ่งที่คุณได้รับคือระยะเวลา round trip ที่สั้นสำหรับผู้ใช้ระหว่าง Boston และ Washington รวมถึงเส้นทางไฟเบอร์ที่สั้นที่สุดจากอเมริกาเหนือไปยังยุโรป หากผู้ใช้ของคุณกระจายตัวอยู่ทั่วทวีปอย่างสม่ำเสมอ ตำแหน่งที่ตั้งส่วนกลางมักจะให้บริการได้ดีกว่า การแยกแยะความแตกต่างระหว่างสองกรณีนี้ควรใช้วิธีการวัดผลแทนการคาดเดา

เหตุใดบริการ VPS ในนิวยอร์กส่วนใหญ่จึงเป็นบริการในนิวเจอร์ซีย์

แมนฮัตตันเป็นที่ตั้งของอาคารศูนย์รวมโครงข่ายโทรคมนาคม (carrier hotel) อาคาร 60 Hudson Street คืออาคารที่มีชื่อเสียงที่สุด ซึ่งเป็นอาคารสไตล์อาร์ตเดโคในย่าน Tribeca สร้างเสร็จในปี 1930 ภายในอาคารมีผู้ให้บริการโครงข่ายและผู้ให้บริการคลาวด์มากกว่า 300 ราย รวมถึงจุดแลกเปลี่ยนข้อมูลที่ให้บริการในภูมิภาคนี้ เช่น DE-CIX New York และ NYIIX นอกจากนี้ยังมีอาคาร 32 Avenue of the Americas ที่ทำหน้าที่เดียวกันโดยตั้งอยู่ห่างออกไปเพียงไม่กี่ช่วงตึก ส่วนในฝั่งนิวเจอร์ซีย์จะมีอาคาร 165 Halsey Street ในเมือง Newark ที่ทำหน้าที่เทียบเท่ากัน

อาคารเหล่านี้คือจุดที่เครือข่ายต่างๆ มาเชื่อมต่อกัน แต่ไม่ใช่สถานที่สำหรับติดตั้งระบบประมวลผลขนาดใหญ่ เนื่องจากค่าไฟฟ้าและพื้นที่ในแมนฮัตตันมีราคาสูงและขยายพื้นที่ได้ยาก ศูนย์ข้อมูลขนาดใหญ่จึงตั้งอยู่ฝั่งตรงข้ามแม่น้ำฮัดสันในเมือง Secaucus, Weehawken, Carteret, Piscataway และ Newark ผู้ให้บริการที่ขาย VPS ในชื่อ "New York" มักหมายถึงตู้แร็คที่ตั้งอยู่ในวงแหวนดังกล่าว ซึ่งอยู่ห่างจากใจกลางเมืองไม่เกิน 40 กิโลเมตร ค่าความหน่วงจากการส่งข้อมูลผ่านสายไฟเบอร์ส่วนเกินนั้นต่ำกว่า 1 มิลลิวินาทีมาก ดังนั้นภาระงานบนเว็บจึงไม่ได้รับผลกระทบแต่อย่างใด คุณควรสอบถามชื่ออาคารก็ต่อเมื่อต้องการการเชื่อมต่อโดยตรง (cross-connect) ไปยังเครือข่ายเฉพาะเจาะจงเท่านั้น

ปัจจัยที่ดึงดูดขีดความสามารถมาสู่เขตเมืองนี้

มีสี่ปัจจัยหลัก และแต่ละปัจจัยช่วยเสริมความแข็งแกร่งให้กันและกัน

• เคเบิลใต้น้ำข้ามมหาสมุทรแอตแลนติกขึ้นฝั่งที่นี่ Wall Township และ Manasquan บนชายฝั่ง New Jersey เป็นกลุ่มพื้นที่ที่มีการใช้งานหนาแน่นที่สุดในประเทศ เคเบิล Havfrue ซึ่งจำหน่ายในชื่อ AEC-2 เชื่อมต่อจาก Wall ไปยัง Blaabjerg ในเดนมาร์ก โดยมีสาขาแยกไปยังไอร์แลนด์และนอร์เวย์ เคเบิล Seabras-1 เชื่อมต่อจากสถานีเดียวกันไปยังบราซิล และ TGN Atlantic เชื่อมต่อไปยังยุโรป ส่วนเคเบิล Apollo ขึ้นฝั่งที่ Manasquan จาก Bude ในอังกฤษและ Lannion ในฝรั่งเศส นอกจากนี้ เคเบิล Grace Hopper ของ Google ยังขึ้นฝั่งที่ Bellport บน Long Island และรับส่งข้อมูลไปยัง Bude ตั้งแต่เดือนกันยายน 2022
• ศูนย์แลกเปลี่ยนข้อมูลย้ายออกจาก Wall Street ระบบจับคู่คำสั่งซื้อขาย (matching engine) ของ NYSE ทำงานอยู่ที่ Mahwah, ของ Nasdaq อยู่ที่ Carteret และของ Cboe อยู่ที่ Secaucus เทรดเดอร์เรียกพื้นที่เหล่านี้ว่าสามเหลี่ยมหุ้น (equity triangle) บริษัทที่ต้องการข้อมูลตลาดภายในระดับไมโครวินาทีจำเป็นต้องเช่าพื้นที่ใกล้กับศูนย์เหล่านี้ และความต้องการดังกล่าวได้กลายเป็นเงินทุนสำหรับโครงข่ายไฟเบอร์ที่เราทุกคนใช้งานร่วมกันในปัจจุบัน
• สื่อและการโฆษณาตั้งอยู่ที่นี่ การประมูลโฆษณาแบบเรียลไทม์ (real-time bidding) ต้องส่งคำตอบกลับมาก่อนที่หน้าเว็บจะโหลดเสร็จ ดังนั้นศูนย์แลกเปลี่ยนโฆษณาจึงถูกสร้างขึ้นใกล้กับเครือข่ายเอเจนซีที่พวกเขาขายบริการให้
• เครือข่ายมักขยายตัวไปยังจุดที่มีเครือข่ายอยู่แล้ว เมื่อผู้ให้บริการหลายร้อยรายใช้งานอาคารเดียวกัน อาคารถัดไปจะได้รับค่าบริการรับส่งข้อมูล (transit) ที่ถูกลงและมีประสิทธิภาพการเชื่อมต่อ (peering) ที่ดีขึ้นจากการเข้าร่วมกลุ่ม มากกว่าการไปสร้างในพื้นที่อื่น

สำหรับผู้ซื้อ VPS ปัจจัยเหล่านี้ไม่ใช่เรื่องของชื่อเสียง แต่หมายถึงการแข่งขันด้านราคา transit ที่สูง, การเชื่อมต่อ peering ที่หนาแน่น และเส้นทางไปยังยุโรปที่สั้นเนื่องจากเริ่มต้นจากจุดที่เคเบิลวางตัวอยู่จริง

ต้นทุนที่แท้จริงของ round trip

แสงที่เดินทางในแก้วมีความเร็วประมาณ 200,000 กิโลเมตรต่อวินาที ซึ่งคิดเป็นประมาณสองในสามของความเร็วแสงในสุญญากาศ นั่นหมายถึงเวลา round-trip time 1 ms สำหรับสายไฟเบอร์ทุกๆ 100 กิโลเมตร ก่อนที่ router จะประมวลผล packet ใดๆ เส้นทางจริงมักยาวกว่าระยะทางบนแผนที่ เนื่องจากสายไฟเบอร์ต้องวางตามแนวเขตทางและเส้นทางใต้ทะเล ไม่ใช่เส้นตรง

ต้นทุนไม่ได้มีแค่ round trip เดียว แต่ขึ้นอยู่กับจำนวน round trip ที่โปรโตคอลของคุณต้องการ การเชื่อมต่อ HTTPS ใหม่ต้องใช้ 1 round trip สำหรับ TCP (transmission control protocol) handshake, อีก 1 round trip สำหรับ TLS (transport layer security) 1.3 handshake และอีก 1 round trip เพื่อส่งคำขอและรับไบต์แรกกลับมา นั่นคือ 3 round trips ก่อนที่เบราว์เซอร์จะเห็น HTML ใดๆ ส่วน TLS 1.2 จะเพิ่ม round trip ที่ 4 เข้าไป

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

คอลัมน์เหล่านั้นเป็นค่าจากการคำนวณไม่ใช่การวัดจริง: ไบต์แรกใช้ 3 round trips และคอลัมน์ chain คือหน้าเว็บที่เรียก API 6 รายการต่อกันเป็นทอดๆ ภายในเขตเมืองที่ 5 ms การตั้งค่าการเชื่อมต่อแทบไม่ส่งผลกระทบ แต่เมื่อข้ามมหาสมุทรแอตแลนติกที่ 78 ms หน้าเว็บเดียวกันต้องรอ 234 ms กว่าจะได้ HTML ไบต์แรก และการเรียก API 6 รายการต้องเสียเวลา 468 ms ไปกับการรอเพียงอย่างเดียว จากนิวยอร์กไปสิงคโปร์ที่ 230 ms chain ดังกล่าวจะมีต้นทุนสูงถึง 1380 ms

โปรดอ่านคอลัมน์ chain ก่อนตัดสินใจย้ายเซิร์ฟเวอร์ การนำการเชื่อมต่อกลับมาใช้ใหม่ (connection reuse) และการทำ TLS session resumption ช่วยลด round trip ที่คุณต้องจ่ายซ้ำแล้วซ้ำเล่า การเปลี่ยนการเรียก API 6 รายการที่ต้องรอกันเป็นทอดๆ ให้เหลือเพียง 2 ชุดที่ทำงานขนานกัน ช่วยประหยัดเวลาได้มากกว่าการย้ายเซิร์ฟเวอร์ให้ใกล้ขึ้นข้ามทวีป ให้ย้ายเซิร์ฟเวอร์ก็ต่อเมื่อ round trip เหล่านั้นไม่สามารถลดลงได้อีก เช่น การล็อกอิน หรือการเขียนข้อมูลลงฐานข้อมูลที่ client ไม่สามารถทำ batch ได้

ค่า Round trip time ทั่วไปจาก VPS ในเขตมหานครนิวยอร์ก

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

ให้ถือว่าตัวเลขเหล่านี้เป็นค่ามาตรฐานที่เผยแพร่ทั่วไป ไม่ใช่การวัดผลจากเครื่องใดเครื่องหนึ่งโดยเฉพาะ นี่คือช่วงค่าที่มักอ้างอิงสำหรับโฮสต์ที่มีการเชื่อมต่อดีบนโครงข่ายปกติ ซึ่งเส้นทางเครือข่ายของคุณอาจมีค่าที่สูงหรือต่ำกว่านี้ได้ Ashburn อยู่ห่างออกไปประมาณ 8 ms ซึ่งใกล้พอที่ VPS ในนิวยอร์กจะเรียกใช้บริการในคลัสเตอร์ที่ Virginia ได้โดยไม่เกิดความหน่วงที่ส่งผลกระทบอย่างมีนัยสำคัญ Toronto อยู่ที่ประมาณ 14 ms ส่วน London อยู่ที่ประมาณ 78 ms และ Frankfurt อยู่ที่ประมาณ 88 ms นี่คือเหตุผลที่เซิร์ฟเวอร์ฝั่ง East Coast สามารถให้บริการผู้ใช้ในยุโรปได้อย่างยอมรับได้ ในขณะที่เซิร์ฟเวอร์ฝั่ง West Coast ไม่สามารถทำได้

เมื่อการเลือกตำแหน่งเซิร์ฟเวอร์ในฝั่ง East Coast คือทางเลือกที่เหมาะสม

• ผู้ใช้งานส่วนใหญ่ของคุณอยู่ในแนวระเบียงเมืองตั้งแต่ Boston ถึง Washington พื้นที่ดังกล่าวมีสัดส่วนความต้องการใช้งานอินเทอร์เน็ตสูงมากในสหรัฐอเมริกา และทุกจุดอยู่ห่างจากเขตเมืองเหล่านี้เพียงไม่กี่มิลลิวินาที
• คุณให้บริการแก่ผู้ใช้ในฝั่งตะวันออกของสหรัฐอเมริกาและยุโรปด้วยเครื่องเดียว New York เป็นจุดประสงค์ที่ประนีประนอมได้ดีที่สุดเนื่องจากเป็นจุดเริ่มต้นของเส้นทางข้ามมหาสมุทรแอตแลนติก
• คุณต้องพึ่งพาสิ่งที่มีอยู่ในเขตเมืองนั้นอยู่แล้ว เช่น ข้อมูลตลาด (market data feed), ระบบแลกเปลี่ยนโฆษณา (ad exchange) หรือ API ของพันธมิตรใน Secaucus หรือ Ashburn
• คุณต้องการเส้นทางที่สั้นในการเชื่อมต่อไปยัง Canada โดยไม่จำเป็นต้องโฮสต์เซิร์ฟเวอร์ที่นั่น Toronto มีค่า RTT อยู่ที่ประมาณ 14 ms หากข้อกำหนดเรื่องการจัดเก็บข้อมูลใน Canada (data residency) เป็นเงื่อนไขบังคับ นั่นถือเป็นการตัดสินใจในอีกรูปแบบหนึ่ง ซึ่งเนื้อหาใน สิ่งที่สำคัญจริง ๆ ในการเลือกโฮสต์ VPS ใน Canada จะช่วยอธิบายรายละเอียดในส่วนนี้

เมื่อตำแหน่งศูนย์กลางในสหรัฐฯ ให้ผลลัพธ์ดีกว่าชายฝั่งตะวันออก

จงออกแบบเพื่อรองรับกรณีที่เลวร้ายที่สุดแทนที่จะเป็นค่าเฉลี่ย ผู้ใช้ที่อยู่ชายฝั่งไกลออกไปจะสังเกตเห็นความหน่วง แต่ผู้ใช้ในรัฐใกล้เคียงจะไม่รู้สึกถึงความแตกต่าง

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

เซิร์ฟเวอร์ใน New York มีค่าความหน่วง 70 ms เมื่อเชื่อมต่อไปยัง Los Angeles ในขณะที่เซิร์ฟเวอร์ใน Dallas มีค่าความหน่วง 38 ms เมื่อเชื่อมต่อไปยัง New York และ 35 ms เมื่อเชื่อมต่อไปยัง Los Angeles ดังนั้นกรณีที่เลวร้ายที่สุดในการเชื่อมต่อข้ามประเทศจึงมีค่าเพียงประมาณครึ่งหนึ่งของ New York เมื่อแผนผังการใช้งานของคุณครอบคลุมทั่วประเทศอย่างแท้จริง ตำแหน่งนี้จึงเป็นจุดที่ได้เปรียบกว่า และ เหตุผลในการเลือกใช้ VPS ใน Dallas ได้อธิบายรายละเอียดเกี่ยวกับตลาดนี้ไว้อย่างครบถ้วน ส่วน Chicago เป็นอีกหนึ่งจุดศูนย์กลางที่สมเหตุสมผล แต่จะมีทำเลค่อนไปทางฝั่งตะวันออกมากกว่า

ยังมีอีกสองสถานการณ์ที่ทำให้การเลือก New York ไม่ใช่ตัวเลือกที่ดีที่สุด หากผู้ใช้ของคุณกระจุกตัวอยู่ใน Ontario หรือ Quebec การเลือกใช้ VPS ใน Toronto จะช่วยให้บริการแก่ผู้ใช้เหล่านั้นได้โดยตรง แทนที่จะต้องเสียเวลาเพิ่มอีก 14 ms ในการส่งข้อมูลจาก New York และหากทราฟฟิกเกือบทั้งหมดของคุณเป็นการสื่อสารระหว่างเซิร์ฟเวอร์ของคุณเอง ให้เก็บเซิร์ฟเวอร์เหล่านั้นไว้ในภูมิภาคเดียวกันและไม่ต้องคำนึงถึงเรื่องภูมิศาสตร์อีกต่อไป เพราะการส่งข้อมูลข้ามภูมิภาคจะทำให้ประสิทธิภาพที่ได้จากการวางเซิร์ฟเวอร์ใกล้ผู้ใช้หมดไปทันที

วัดผลจริง อย่าเชื่อแผนที่ทางการตลาด

แผนที่ความครอบคลุมบอกได้เพียงว่าอาคารตั้งอยู่ที่ใด แต่ไม่ได้บอกว่าแพ็กเก็ตเดินทางไปถึงอาคารนั้นอย่างไร เส้นทางดังกล่าวถูกกำหนดโดยสัญญาการส่งผ่านข้อมูล (transit contracts) และข้อตกลงการเชื่อมต่อ (peering agreements) ไม่ใช่ระยะทาง ดังนั้นให้วัดผลจากจุดที่ผู้ใช้งานของคุณอยู่จริง แล็ปท็อปที่เชื่อมต่อบรอดแบนด์ในบ้านเป็นเครื่องมือวัดผล (probe) ที่ดีกว่าตัว VPS เอง ซึ่งมักตั้งอยู่ในจุดที่เครือข่ายมีประสิทธิภาพสูงอยู่แล้ว

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

เริ่มต้นด้วยการทดสอบ round trip แบบปกติ และส่ง probe จำนวน 20 ครั้งแทนที่จะเป็น 4 ครั้ง ให้แทนที่ hostname ด้วยเซิร์ฟเวอร์ของคุณเอง

ping -c 20 your-server.example.com

บรรทัดสุดท้ายจะรายงาน rtt min/avg/max/mdev ค่าเฉลี่ยเป็นตัวเลขที่มีประโยชน์น้อยที่สุดในนั้น mdev คือค่า jitter ซึ่งหากมีค่าสูงจะทำให้การสื่อสารด้วยเสียงและเซสชันแบบโต้ตอบ (interactive sessions) ขัดข้อง แม้ว่าค่าเฉลี่ยจะดูปกติก็ตาม บนเส้นทางแบบใช้สาย (wired path) การสูญเสียแพ็กเก็ต (packet loss) ใดๆ ที่มากกว่าศูนย์ถือเป็นความผิดปกติ ไม่ใช่สัญญาณรบกวน

จากนั้นให้ตรวจสอบว่าเวลาสูญเสียไปที่จุดใด

mtr -rwzbc 100 your-server.example.com

mtr จะส่ง probe 100 ครั้งไปยังทุก hop และแสดงผลการสูญเสียและ latency ในแต่ละ hop ส่วน -z จะเพิ่มหมายเลข AS (autonomous system) เพื่อให้คุณเห็นว่าเครือข่ายใดเป็นเจ้าของแต่ละ hop การสูญเสียที่รายงานใน hop กลางทางแล้วหายไปใน hop ถัดไปไม่ใช่การสูญเสียที่แท้จริง เนื่องจากเราเตอร์ตัวนั้นจำกัดอัตราการตอบกลับ ICMP ที่มันต้องสร้างขึ้นเอง ซึ่งไม่ได้ส่งผลกระทบต่อทราฟฟิกของคุณ แต่การสูญเสียที่เริ่มจาก hop หนึ่งและต่อเนื่องไปยังทุก hop หลังจากนั้นถือเป็นการสูญเสียที่แท้จริง

ICMP ยังเป็นโปรโตคอลที่ไม่เหมาะสมสำหรับการประเมินบริการเว็บ เนื่องจากหลายเครือข่ายให้ความสำคัญกับมันต่ำ ให้วัดเวลาจากสิ่งที่คุณให้บริการจริงแทน

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

แต่ละค่าคือวินาทีสะสมตั้งแต่เริ่มต้น ดังนั้นคุณต้องนำมาลบกันเพื่ออ่านค่า time_connect ลบด้วย time_namelookup คือหนึ่ง round trip time_appconnect ลบด้วย time_connect คือการทำ TLS handshake time_starttransfer ลบด้วย time_appconnect คืออีกหนึ่ง round trip บวกกับเวลาที่แอปพลิเคชันของคุณใช้ในการตอบกลับ การลบครั้งสุดท้ายนี้คือการวินิจฉัย หากค่าใกล้เคียงกับหนึ่ง round trip แสดงว่าเครือข่ายเป็นข้อจำกัด และการย้ายเซิร์ฟเวอร์ให้ใกล้ขึ้นจะช่วยได้ แต่หากค่าสูงกว่า round trip หลายเท่า แสดงว่าแอปพลิเคชันของคุณทำงานช้า และการย้ายเซิร์ฟเวอร์จะไม่ช่วยอะไรเลย

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

ให้ทำการทดสอบแบบเดียวกันกับ instance ทดลองในแต่ละตำแหน่งที่เลือกไว้ก่อนที่คุณจะตัดสินใจเลือกที่ใดที่หนึ่ง วิธีการเต็มรูปแบบสำหรับการทำ benchmarking VPS จะครอบคลุมถึงดิสก์และ CPU นอกเหนือจากเครือข่าย เพื่อให้คุณไม่ได้เลือกเพียงแค่ค่า latency เท่านั้น

มีอะไรเปลี่ยนแปลงบ้างเมื่อใช้ที่อยู่ใน New York

ราคาคือสิ่งแรกที่เปลี่ยนไป ค่าไฟฟ้าและพื้นที่ในเขตเมือง New York มีราคาสูงกว่าใน Texas หรือแถบ Midwest ผู้ให้บริการบางรายจะเรียกเก็บค่าธรรมเนียมเพิ่มเติมตามสถานที่ตั้ง ในขณะที่บางรายจะใช้วิธีเฉลี่ยราคาจากทุกศูนย์ข้อมูล ณ เดือนสิงหาคม 2026 ยังไม่มีกฎเกณฑ์ที่เป็นมาตรฐานเดียวกัน ดังนั้นควรตรวจสอบราคาของสเปกเดียวกันในสองสถานที่ผ่านหน้าสั่งซื้อของผู้ให้บริการก่อนจะสรุปว่ามีการคิดค่าธรรมเนียมเพิ่ม ค่าใช้จ่ายจริงของ VPS ต่อเดือน จะครอบคลุมรายละเอียดส่วนที่เหลือของบิล

กฎหมายไม่ได้ผูกติดอยู่กับตัวเซิร์ฟเวอร์ กฎหมาย SHIELD Act ของ New York กำหนดหน้าที่ในการแจ้งเตือนเมื่อเกิดการรั่วไหลของข้อมูลและหน้าที่ในการใช้มาตรการป้องกันที่เหมาะสมสำหรับทุกคนที่ถือครองข้อมูลส่วนบุคคลของผู้อยู่อาศัยใน New York ไม่ว่าข้อมูลนั้นจะถูกจัดเก็บไว้ที่ใด การย้ายเซิร์ฟเวอร์ของคุณไปที่ Dallas ไม่ได้ทำให้หน้าที่นี้หมดไป และการย้ายไปที่ Manhattan ก็ไม่ได้ทำให้เกิดหน้าที่นี้ขึ้นมาเช่นกัน หลักการเดียวกันนี้ใช้กับ GDPR (กฎหมายคุ้มครองข้อมูลส่วนบุคคลทั่วไป) และผู้ใช้งานในยุโรปของคุณ สถานที่ตั้งจะมีความสำคัญก็ต่อเมื่อสัญญาหรือกฎระเบียบเฉพาะภาคส่วนระบุถึงประเทศ ซึ่งเป็นเรื่องปกติในอุตสาหกรรมสาธารณสุขและบริการทางการเงินบางประเภท

ความเสี่ยงด้านพลังงานและน้ำท่วมควรได้รับการพิจารณาเป็นพิเศษ เมื่อพายุเฮอริเคน Sandy พัดถล่มในเดือนตุลาคม 2012 อาคารผู้ให้บริการหลายแห่งในย่าน Lower Manhattan ต้องหยุดให้บริการเนื่องจากปั๊มน้ำมันในชั้นใต้ดินถูกน้ำท่วมและเครื่องปั่นไฟที่อยู่ชั้นบนน้ำมันหมด การมีไซต์งานเพียงแห่งเดียวในเขตเมืองใดก็ตามถือเป็นจุดเดียวที่อาจทำให้ระบบล้มเหลว (single point of failure) คุณควรสำรองข้อมูลไว้ในโครงข่ายไฟฟ้าที่ต่างกัน และทดสอบการกู้คืนข้อมูลในสถานที่อื่นอย่างน้อยหนึ่งครั้งเพื่อให้มั่นใจว่ากระบวนการกู้คืนใช้งานได้จริง

FAQ

VPS ใน New York เร็วกว่า VPS ในพื้นที่ตอนกลางของสหรัฐฯ สำหรับผู้ใช้ในยุโรปหรือไม่?

เร็วขึ้นจริง และสามารถคาดการณ์ส่วนต่างความเร็วได้ โดยปกติแล้ว London จะมีค่า RTT อยู่ที่ประมาณ 78 ms จากเขตเมือง New York เนื่องจากสายเคเบิลข้ามมหาสมุทรแอตแลนติกขึ้นฝั่งที่ชายฝั่ง New Jersey และ Long Island เซิร์ฟเวอร์ใน Dallas จะต้องส่งข้อมูลไปยังชายฝั่งตะวันออกก่อนเพื่อเชื่อมต่อไปยัง London จึงต้องเสียเวลาเพิ่มอีกประมาณ 38 ms สำหรับช่วงการเชื่อมต่อจาก Dallas ไปยัง New York หากคุณจำเป็นต้องให้บริการทั้งผู้ใช้ในฝั่งตะวันออกของสหรัฐฯ และยุโรปด้วยเครื่องเดียว การเลือก New York ถือเป็นจุดสมดุลที่สูญเสียประสิทธิภาพน้อยที่สุด

ทำไม VPS ที่ระบุว่าเป็น "New York" ถึงตั้งอยู่ใน New Jersey จริงๆ?

เนื่องจากพื้นที่สำหรับวางตู้ Rack และระบบไฟฟ้าส่วนใหญ่อยู่ที่นั่น อาคารใน Manhattan เช่น 60 Hudson Street ทำหน้าที่เป็นศูนย์กลางการเชื่อมต่อ (interconnection hub) มากกว่าจะเป็นห้องประมวลผลขนาดใหญ่ ดังนั้นตู้ Rack จึงมักตั้งอยู่ใน Secaucus, Weehawken, Carteret, Piscataway หรือ Newark ระยะทางของสายไฟเบอร์ที่เพิ่มขึ้นมานั้นทำให้เกิดความหน่วงไม่ถึง 1 มิลลิวินาที ซึ่งไม่มีภาระงานบนเว็บใดที่จะสังเกตเห็นความแตกต่างนี้ได้ คุณควรระบุสถานที่ตั้งที่แน่นอนก็ต่อเมื่อต้องการทำ cross-connect ไปยังเครือข่ายเฉพาะภายในอาคารนั้นๆ เท่านั้น

ฉันจะทราบได้อย่างไรว่าความหน่วง (latency) คือปัญหาที่แท้จริงของฉัน?

ให้รันการวิเคราะห์เวลาด้วย curl แล้วนำมาคำนวณส่วนต่าง ช่องว่างระหว่าง time_appconnect และ time_starttransfer คือผลรวมของเวลาการรับส่งข้อมูลเครือข่ายหนึ่งรอบ (round trip) บวกกับเวลาที่เซิร์ฟเวอร์ของคุณใช้ประมวลผล หากช่องว่างนี้มีค่ามากกว่าเวลา round trip ที่คุณวัดได้ด้วย ping อย่างมาก แสดงว่าความล่าช้าเกิดขึ้นภายในแอปพลิเคชันของคุณเอง และการย้ายไปใช้ศูนย์ข้อมูลที่ใกล้ขึ้นก็ไม่ช่วยแก้ปัญหานี้ หากช่องว่างดังกล่าวใกล้เคียงกับเวลา round trip หนึ่งรอบแต่หน้าเว็บยังคงโหลดช้า ให้ตรวจสอบจำนวนคำขอ (request) ที่หน้าเว็บเรียกใช้งานแบบเรียงลำดับ เพราะทุกคำขอจะต้องเสียเวลา round trip เพิ่มขึ้นในทุกครั้ง

การโฮสต์เซิร์ฟเวอร์ใน New York ส่งผลต่อกฎหมายความเป็นส่วนตัวที่บังคับใช้กับฉันหรือไม่?

โดยส่วนใหญ่แล้วไม่ส่งผล กฎระเบียบอย่าง SHIELD Act ของ New York หรือ GDPR จะยึดตามข้อมูลของใครที่คุณถือครอง ไม่ใช่สถานที่ที่ฮาร์ดดิสก์ตั้งอยู่ สถานที่ตั้งของเซิร์ฟเวอร์จะกลายเป็นปัจจัยตัดสินก็ต่อเมื่อสัญญาหรือกฎระเบียบเฉพาะภาคส่วนระบุชื่อประเทศไว้อย่างชัดเจน ซึ่งมักพบในอุตสาหกรรมสาธารณสุขและบริการทางการเงินบางประเภท โปรดอ่านข้อกำหนดจริงก่อนตัดสินใจเลือกสถานที่ตั้งเพื่อตอบสนองต่อกฎระเบียบเหล่านั้น

CDN สามารถทดแทน VPS ที่วางตำแหน่งไว้อย่างเหมาะสมได้หรือไม่?

สำหรับไฟล์แบบ static นั้นทำได้ CDN (content delivery network) จะทำหน้าที่แคชรูปภาพและสคริปต์ไว้ใกล้กับผู้ใช้ของคุณ ซึ่งช่วยลดระยะทางสำหรับคำขอเหล่านั้นได้เกือบทั้งหมด อย่างไรก็ตาม CDN ไม่สามารถแคชหน้า dashboard ที่ต้องล็อกอินหรือการเขียนข้อมูลลงฐานข้อมูลได้ ดังนั้นข้อมูลส่วนนี้ยังคงต้องเดินทางไปยังเซิร์ฟเวอร์ต้นทาง (origin server) และต้องเสียเวลา round trip เต็มจำนวนอยู่ดี คุณควรวางเซิร์ฟเวอร์ต้นทางไว้ใกล้กับผู้ใช้ที่ทำหน้าที่เขียนข้อมูล และปล่อยให้ CDN จัดการส่วนที่เหลือ