เลือก VPS ใน Frankfurt ดีไหม? วิเคราะห์ความเร็วและกฎหมาย

VPS hosting ใน Frankfurt เหมาะกับใคร

VPS hosting ใน Frankfurt เหมาะสำหรับโปรเจกต์ที่มีผู้ใช้งานอยู่ในประเทศเยอรมนี ในตลาดที่ใช้ภาษาเยอรมัน หรือกระจายตัวอยู่ทั่วสหภาพยุโรป Frankfurt เป็นหนึ่งในจุดเชื่อมต่อเครือข่ายหลักของยุโรปที่ส่งต่อ traffic ระหว่างกันโดยตรง เซิร์ฟเวอร์ที่ตั้งอยู่ในจุดนี้จึงสามารถเข้าถึงพื้นที่ส่วนใหญ่ของทวีปได้ภายในเวลาเพียงไม่กี่สิบมิลลิวินาที หากผู้ใช้งานของคุณส่วนใหญ่อยู่ในอเมริกาเหนือ เซิร์ฟเวอร์ในยุโรปจะให้ความรู้สึกที่ช้าสำหรับพวกเขาไม่ว่าเครื่องจะเร็วเพียงใดก็ตาม เนื่องจากระยะทางเป็นข้อจำกัดพื้นฐานที่การปรับแต่งใดๆ ก็ไม่สามารถแก้ไขได้

การตัดสินใจเลือกสถานที่ตั้งเซิร์ฟเวอร์ขึ้นอยู่กับคำถามสองข้อที่แยกจากกัน และการนำมารวมกันมักนำไปสู่การตัดสินใจที่ผิดพลาด ข้อแรกคือผู้ใช้งานของคุณอยู่ที่ไหน ซึ่งเป็นคำถามเกี่ยวกับระยะทางและ round-trip time ข้อที่สองคือข้อมูลของคุณได้รับอนุญาตให้จัดเก็บที่ใด ซึ่งเป็นคำถามทางกฎหมายและสัญญา Frankfurt ให้คำตอบที่ชัดเจนสำหรับข้อแรกในกรณีของกลุ่มผู้ใช้งานในยุโรป ส่วนในข้อที่สองนั้น Frankfurt ช่วยแก้ปัญหาเฉพาะจุดได้หนึ่งอย่าง แต่ไม่ได้ครอบคลุมประเด็นอื่นทั้งหมด

เหตุใด Frankfurt จึงมีการเชื่อมต่อที่ดีเยี่ยม

Frankfurt เป็นที่ตั้งของ DE-CIX (Deutsche Commercial Internet Exchange) ซึ่งเป็น IXP (internet exchange point) ที่มีขนาดใหญ่ที่สุดแห่งหนึ่งของโลกทั้งในด้านปริมาณ traffic สูงสุดและจำนวนเครือข่ายที่เชื่อมต่อ IXP คือโครงสร้างพื้นฐานการสลับสัญญาณร่วมภายในศูนย์ข้อมูลที่เครือข่ายอิสระต่างๆ เชื่อมต่อเข้าหากัน แทนที่จะต้องจ่ายเงินให้เครือข่ายขนาดใหญ่เพื่อรับส่งข้อมูลระหว่างกัน DE-CIX เผยแพร่สถิติ traffic ปัจจุบันไว้บน เว็บไซต์ของตนเอง และเนื่องจากตัวเลขเหล่านี้มีการเปลี่ยนแปลงอยู่เสมอ คุณควรตรวจสอบจากแหล่งข้อมูลดังกล่าวโดยตรงแทนการเชื่อตัวเลขที่คัดลอกมาไว้ในบทความ

ผลลัพธ์ในทางปฏิบัติขึ้นอยู่กับเส้นทาง ไม่ใช่ปริมาณรวม เมื่อเครือข่ายของผู้ให้บริการของคุณและ ISP (internet service provider) ของผู้เข้าชมเชื่อมต่อที่จุดแลกเปลี่ยนเดียวกัน traffic ระหว่างทั้งสองจะผ่านการ routing เพียง hop เดียวที่จุดแลกเปลี่ยนนั้น แต่หากไม่มีการเชื่อมต่อกันในระดับท้องถิ่น traffic จะต้องวิ่งไปหาเครือข่ายที่สามที่เชื่อมต่อกับทั้งสองฝ่าย ซึ่งจุดส่งต่อที่ใกล้ที่สุดของเครือข่ายนั้นอาจอยู่ในประเทศอื่น เครือข่ายในเยอรมนีสองแห่งที่แลกเปลี่ยน traffic ผ่าน Amsterdam หรือ London จะต้องเสียค่าใช้จ่ายจากระยะทางที่เพิ่มขึ้นถึงสองเท่าในแต่ละทิศทาง วิศวกรเครือข่ายเรียกปรากฏการณ์นี้ว่า tromboning และเป็นสาเหตุปกติที่ทำให้เซิร์ฟเวอร์ที่อยู่ใกล้เคียงมีค่า latency สูง

คุณสามารถตรวจสอบได้ด้วยตนเองแทนการคาดเดา ให้รัน mtr ไปยังเซิร์ฟเวอร์ของคุณจากเครือข่ายที่คุณต้องการทดสอบ แล้วอ่านชื่อ hop ใน reverse DNS โดยปกติ hostname ของ router มักจะระบุรหัสสนามบิน IATA ไว้ ดังนั้นหากพบ fra ในชื่อ hop หมายถึง Frankfurt, ams หมายถึง Amsterdam และ lhr หมายถึง London เส้นทางจากเครือข่ายผู้ใช้งานในเยอรมนีไปยังเซิร์ฟเวอร์ในเยอรมนีที่แสดง lhr อยู่ตรงกลาง จะบอกคุณได้อย่างชัดเจนว่าค่ามิลลิวินาทีที่เพิ่มขึ้นนั้นมาจากที่ใด

แฟรงก์เฟิร์ตอยู่ห่างจากผู้ใช้ของคุณเท่าใด

แสงในสายไฟเบอร์เดินทางด้วยความเร็วประมาณสองในสามของความเร็วในสุญญากาศ หรือใกล้เคียงกับ 200,000 กิโลเมตรต่อวินาที การเดินทางไปกลับต้องใช้เส้นทางสองรอบ ดังนั้นการเดินทางไปกลับที่เร็วที่สุดที่เป็นไปได้ในระยะทาง d กิโลเมตร คือ d/100 มิลลิวินาที ค่านี้ถือเป็นขีดจำกัดต่ำสุด (floor) ซึ่งมีประโยชน์เพราะไม่มีสิ่งใดสามารถเร็วกว่านี้ได้

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

ค่าเหล่านี้คำนวณจากระยะทางเส้นตรง ไม่ใช่การวัดจริง ให้ถือว่าคอลัมน์สุดท้ายคือกรณีที่ดีที่สุดตามหลักฟิสิกส์ การวัดจริงมักจะอยู่ที่ 1.5 ถึง 2 เท่าของขีดจำกัดต่ำสุด เนื่องจากสายไฟเบอร์มักวางตามแนวถนนและหุบเขามากกว่าเส้นทางวงกลมใหญ่ และเนื่องจากเราเตอร์ทุกตัวบนเส้นทางจะเพิ่มความหน่วงในการส่งต่อและคิวเล็กน้อย

เบอร์ลินอยู่ห่างจากแฟรงก์เฟิร์ต 424 กม. ซึ่งมีขีดจำกัดต่ำสุดอยู่ที่ 4.2 มิลลิวินาที มาดริดอยู่ห่างออกไป 1,419 กม. มีขีดจำกัดต่ำสุดอยู่ที่ 14.2 มิลลิวินาที และถือเป็นมุมที่ไกลที่สุดของสหภาพยุโรปจากจุดนี้ นิวยอร์กอยู่ห่างออกไป 6,206 กม. โดยมีขีดจำกัดต่ำสุดที่ 62.1 มิลลิวินาที ซึ่งเป็นเหตุผลว่าทำไมกลุ่มผู้ชมข้ามมหาสมุทรแอตแลนติกจึงเป็นเรื่องของการตัดสินใจเลือกทำเลที่ตั้ง ไม่ใช่ปัญหาของการปรับจูนระบบ

การเดินทางไป-กลับที่ล่าช้าส่งผลต่อการโหลดหน้าเว็บอย่างไร

การเดินทางไป-กลับ (round trip) เพียงหนึ่งครั้งมักไม่ได้หมายถึงการเดินทางเพียงครั้งเดียว การเปิดการเชื่อมต่อ HTTPS ต้องใช้การเดินทางไป-กลับหนึ่งครั้งสำหรับ TCP (transmission control protocol) handshake และอีกหนึ่งครั้งสำหรับ TLS (transport layer security) 1.3 handshake จากนั้นคำขอจะต้องใช้การเดินทางครั้งที่สามก่อนที่ไบต์แรกของการตอบกลับจะส่งกลับมา ส่วน TLS 1.2 จะเพิ่มการเดินทางครั้งที่สี่เข้าไปอีก การค้นหา DNS (domain name system) ที่ไม่ได้อยู่ในแคชจะเพิ่มการเดินทางไป-กลับอย่างน้อยอีกหนึ่งครั้งไปยังเซิร์ฟเวอร์อื่นอีกแห่ง

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

คอลัมน์การเดินทางไป-กลับในที่นี้เป็นการสมมติเส้นทางที่เป็นไปได้ไปยังเซิร์ฟเวอร์ใน Frankfurt และคอลัมน์ที่สองเป็นการคำนวณจากค่าดังกล่าว ซึ่งคือการเดินทางไป-กลับสามครั้งก่อนที่จะได้รับไบต์แรก ผู้ใช้ใน Frankfurt จะต้องรอ 15 ms ส่วนผู้ใช้ใน Singapore ซึ่งมีเวลาการเดินทางไป-กลับอยู่ที่ 170 ms จะต้องรอ 510 ms สำหรับการตอบกลับเดียวกัน ก่อนที่เบราว์เซอร์จะแสดงผลใดๆ ออกมา

ตัวคูณคือประเด็นสำคัญของเรื่องนี้ RTT (round-trip time) ที่เพิ่มขึ้นทุกหนึ่งมิลลิวินาทีจะทำให้ต้องเสียเวลาเพิ่มขึ้นประมาณสามมิลลิวินาทีก่อนที่จะได้รับไบต์แรก และยังคงส่งผลต่อเนื่องไปเรื่อยๆ ไฟล์ HTML จะระบุชื่อไฟล์ stylesheet และไฟล์ stylesheet จะระบุชื่อฟอนต์ ซึ่งการค้นพบแต่ละรายการนั้นถือเป็นการเดินทางไป-กลับอีกครั้งบนการเชื่อมต่อเดิม การเพิ่มระยะทางที่ทำให้เกิดความล่าช้าอีกสองสามร้อยมิลลิวินาทีจะเปลี่ยนหน้าเว็บที่เคยรู้สึกว่าโหลดได้ทันทีให้กลายเป็นหน้าเว็บที่รู้สึกว่าโหลดช้า ทั้งที่เซิร์ฟเวอร์ทำงานทุกอย่างเหมือนเดิมและใช้เวลาเท่าเดิมทุกประการ

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

ฉันจะวัดค่านี้จากจุดที่ผู้ใช้งานของฉันอยู่ได้อย่างไร

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

ping -c 20 your-server.example.com

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

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r จะพิมพ์รายงานออกมาแทนการแสดงผลแบบเรียลไทม์ -w จะคงชื่อโฮสต์ที่ยาวไว้โดยไม่ตัดทอน -z จะแสดงหมายเลข AS (autonomous system) ของแต่ละ hop และ -c 50 จะส่งข้อมูลจำนวน 50 รอบ การสูญเสียข้อมูลที่แสดงใน hop กลางโดยไม่มีการสูญเสียที่ hop สุดท้ายถือเป็นเรื่องปกติและไม่ใช่ความผิดพลาด เนื่องจากเราเตอร์จำนวนมากจะจำกัดอัตราการตอบกลับ ICMP ที่สร้างขึ้นเอง แต่ยังคงส่งต่อข้อมูลอื่น ๆ ได้ตามปกติ การสูญเสียข้อมูลที่เริ่มขึ้นที่ hop ใด hop หนึ่งและต่อเนื่องไปยังทุก hop หลังจากนั้นถือเป็นการสูญเสียที่แท้จริง

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

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

สำหรับการวัดปริมาณข้อมูล (throughput) แทนที่จะเป็นความหน่วง ให้รัน iperf3 -s บน VPS เปิดพอร์ตที่ firewall แล้วรัน iperf3 -c your-server.example.com -R จากฝั่งไคลเอนต์เพื่อทดสอบความเร็วในการดาวน์โหลด หากต้องการวัดค่าจากสถานที่ที่คุณไม่มีเครื่องคอมพิวเตอร์อยู่ RIPE Atlas มีโพรบให้ใช้งานทั่วทวีปยุโรป เมื่อคุณต้องการเปรียบเทียบเซิร์ฟเวอร์สองเครื่องแทนที่จะเปรียบเทียบเครือข่ายสองเครือข่าย ให้ใช้วิธีการที่กำหนดไว้ตายตัวแทนการใช้ตัวเลขที่วัดเพียงครั้งเดียว ซึ่งนั่นคือจุดประสงค์ของ การทำ benchmark VPS ที่ทำซ้ำได้

การมีเซิร์ฟเวอร์ใน Frankfurt ทำให้โปรเจกต์ของฉันสอดคล้องกับ GDPR หรือไม่?

ไม่ และเหตุผลนั้นควรระบุให้ชัดเจน GDPR (General Data Protection Regulation) มีผลบังคับใช้โดยพิจารณาจากข้อมูลส่วนบุคคลของใครที่คุณประมวลผลและองค์กรของคุณจัดตั้งขึ้นที่ใด ไม่ใช่พิจารณาจากประเทศที่ฮาร์ดแวร์ตั้งอยู่ การย้ายเซิร์ฟเวอร์ไปที่ Frankfurt ไม่ได้ทำให้เกิดความสอดคล้องตามกฎหมาย และการใช้งานเซิร์ฟเวอร์นอก EU ก็ไม่ได้หมายความว่าผิดกฎหมายโดยอัตโนมัติ สถานที่ตั้งเป็นเพียงปัจจัยหนึ่งในหลายปัจจัยเท่านั้น

สิ่งที่การโฮสต์ภายใน EU หรือ EEA (European Economic Area) ช่วยได้จริงคือการตัดประเด็นเรื่องการโอนย้ายข้อมูลระหว่างประเทศออกไป กฎหมายฉบับนี้มีบทบัญญัติทั้งบทที่ว่าด้วยการส่งข้อมูลส่วนบุคคลออกนอกเขต EEA ซึ่งจำเป็นต้องมีเครื่องมือทางกฎหมายรองรับ เช่น การตัดสินใจเรื่องความเพียงพอ (adequacy decision) หรือข้อสัญญามาตรฐาน (standard contractual clauses) ข้อมูลที่เก็บไว้ใน Frankfurt จะไม่ถือว่าถูกโอนย้าย ดังนั้นบทบัญญัติดังกล่าวจึงไม่มีผลกับข้อมูลส่วนนี้ นี่คือการลดความซับซ้อนที่แท้จริงและเป็นประโยชน์เพียงข้อเดียวที่ได้รับ

ส่วนที่เหลือทั้งหมดเป็นหน้าที่ของคุณ คุณยังคงต้องมีฐานทางกฎหมายสำหรับแต่ละวัตถุประสงค์ ต้องมีระบบจัดการสิทธิ์ในการเข้าถึงและลบข้อมูลสำหรับบุคคลในฐานข้อมูลของคุณ ต้องมีกำหนดระยะเวลาการจัดเก็บข้อมูลที่คุณบังคับใช้จริง ต้องมีมาตรการรักษาความปลอดภัยที่เหมาะสมกับความเสี่ยง และต้องรายงานต่อหน่วยงานกำกับดูแลภายใน 72 ชั่วโมงหลังจากทราบว่ามีการละเมิดข้อมูลส่วนบุคคล นอกจากนี้ คุณยังต้องมีข้อตกลงการประมวลผลข้อมูล (processor agreement) กับผู้ให้บริการโฮสต์ของคุณ ซึ่งในเยอรมนีเรียกว่า Auftragsverarbeitungsvertrag หรือ AVV โปรดทราบด้วยว่าเซิร์ฟเวอร์ใน Frankfurt อาจยังคงเกี่ยวข้องกับการโอนย้ายข้อมูลหากทีมสนับสนุนที่อยู่นอกเขต EEA สามารถเข้าถึงเซิร์ฟเวอร์นั้นได้ ดังนั้นควรตรวจสอบว่าใครเป็นผู้ถือกุญแจเข้าถึงข้อมูล

เยอรมนียังมีกฎหมายเพิ่มเติมเฉพาะของตนเอง คือ BDSG (Bundesdatenschutzgesetz) ซึ่งเป็นกฎหมายระดับสหพันธรัฐที่เสริมกฎระเบียบด้วยข้อกำหนดระดับชาติ โดยข้อมูลพนักงานเป็นประเด็นที่มักสร้างความประหลาดใจให้ผู้คนมากที่สุด เนื้อหาส่วนนี้เป็นเพียงข้อมูลพื้นฐานทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย European Data Protection Board ได้เผยแพร่แนวทางปฏิบัติอย่างเป็นทางการไว้ที่ edpb.europa.eu และสำหรับเรื่องที่มีผลกระทบทางกฎหมายอย่างจริงจัง คุณควรปรึกษาผู้เชี่ยวชาญที่มีคุณสมบัติเหมาะสมแทนการอ่านจากบทช่วยสอนนี้

สิ่งที่ควรปรับเปลี่ยนบนเซิร์ฟเวอร์

ให้ตั้งค่านาฬิกาของระบบเป็น UTC (Coordinated Universal Time) และจัดรูปแบบ timestamp ภายในแอปพลิเคชันของคุณ ประเทศเยอรมนีมีการปรับเวลาตามฤดูกาล (Daylight Saving Time) ซึ่งทำให้เวลาท้องถิ่นเลื่อนไปหนึ่งชั่วโมงปีละสองครั้ง และมีช่วงเวลาหนึ่งชั่วโมงในช่วงปลายเดือนตุลาคมที่เกิดขึ้นซ้ำ หากบันทึก log ด้วยเวลาท้องถิ่น จะทำให้มีรายการเวลา 02:30 ปรากฏขึ้นสองครั้งในคืนนั้น และการเปรียบเทียบข้อมูลข้ามภูมิภาคจะกลายเป็นการคาดเดา หากคุณยังต้องการใช้เวลาท้องถิ่นบนเซิร์ฟเวอร์ ให้ตั้งค่าอย่างชัดเจนและตรวจสอบดังนี้:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

ผลลัพธ์ควรแสดง Time zone: Europe/Berlin (CEST, +0200) ในช่วงฤดูร้อน และ +0100 ในช่วงฤดูหนาว

ข้อความภาษาเยอรมันจะถูกจัดเรียงลำดับผิดพลาดภายใต้ locale เริ่มต้นแบบ C เนื่องจาก C จะเปรียบเทียบข้อมูลแบบ raw bytes ให้สร้าง locale ขึ้นมาใหม่และสังเกตความแตกต่าง:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

การเรียงลำดับแบบแรกจะวาง Äpfel ไว้หลัง Zebra เนื่องจากไบต์แรกในรูปแบบ UTF-8 มีค่าสูงกว่าตัวอักษร ASCII ใดๆ ส่วนการเรียงลำดับแบบที่สองจะวางไว้ถัดจาก Apfel ซึ่งเป็นตำแหน่งที่ผู้อ่านภาษาเยอรมันคาดหวังไว้ เรื่องนี้มีความสำคัญมากกว่าที่เห็น เนื่องจาก PostgreSQL และ MySQL จะกำหนด collation ไว้ตั้งแต่ตอนสร้างฐานข้อมูล และการเปลี่ยนในภายหลังหมายถึงการต้องสร้างดัชนีใหม่ทั้งหมด ดังนั้นควรตัดสินใจให้เรียบร้อยก่อนนำข้อมูลเข้า

การใช้ mirror ของแพ็กเกจในเยอรมนีช่วยให้การรัน apt เร็วขึ้น บน Ubuntu 24.04 แหล่งที่มาของซอฟต์แวร์จะอยู่ที่ /etc/apt/sources.list.d/ubuntu.sources ในรูปแบบ deb822 ดังนั้นให้แก้ไขบรรทัด URIs: เป็น http://de.archive.ubuntu.com/ubuntu/ แทนการเพิ่มไฟล์ที่สองเข้าไป การเพิ่มไฟล์ใหม่จะทำให้เกิด Target Packages ... is configured multiple times ซึ่งเป็น ข้อผิดพลาด deb822 duplicate sources และจะหยุดการอัปเดตจนกว่าคุณจะแก้ไขให้เรียบร้อย

ประกาศ AAAA record ของคุณ ผู้ให้บริการอินเทอร์เน็ตในเยอรมนีบางรายใช้การเชื่อมต่อแบบ DS-Lite (Dual-Stack Lite) ให้กับผู้ใช้งานตามบ้าน ซึ่งลูกค้าจะไม่มี public IPv4 address เลย และทราฟฟิก IPv4 จะต้องผ่านเกตเวย์แปลงข้อมูลของผู้ให้บริการ เกตเวย์ดังกล่าวจะเพิ่มความหน่วงและเกิดความแออัดในช่วงเวลาที่มีการใช้งานสูง ในขณะที่ทราฟฟิก IPv6 จะออกสู่ภายนอกได้โดยตรง ให้ตรวจสอบทั้งสองเส้นทางหลังจากตั้งค่า record แล้ว:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

ผลลัพธ์ 200 จากคำสั่งที่สองหมายความว่า IPv6 ทำงานได้แบบ end-to-end ส่วน Could not resolve host หรือข้อผิดพลาดในการเชื่อมต่อหมายความว่า record หรือ listener หายไป และผู้เยี่ยมชมที่ใช้ DS-Lite กำลังใช้งานผ่านเส้นทางที่ช้ากว่า

เมื่อ Frankfurt ไม่ใช่ตัวเลือกที่เหมาะสม

• ผู้ใช้งานของคุณอยู่ในสหรัฐอเมริกา: ควรให้บริการจากที่นั่น โดย VPS ใน Dallas ตั้งอยู่ใกล้ศูนย์กลางของประเทศ และ VPS hosting ใน New York เป็นเส้นทางที่สั้นกว่าสำหรับฝั่งตะวันออกและสำหรับ traffic ที่ต้องข้ามมหาสมุทรแอตแลนติกอยู่แล้ว
• ผู้ใช้งานของคุณอยู่ในละตินอเมริกา: Frankfurt อยู่ไกลจาก São Paulo มากกว่าเมื่อเทียบกับ New York ดังนั้น VPS ใน Brazil จึงเป็นคำตอบที่ตรงไปตรงมาสำหรับกลุ่มเป้าหมายดังกล่าว
• ข้อมูลของคุณต้องถูกเก็บไว้ภายในประเทศใดประเทศหนึ่งนอกกลุ่ม EU: งานภาครัฐของแคนาดาเป็นกรณีที่พบบ่อย และ สิ่งที่สำคัญจริงสำหรับการทำ VPS hosting ในแคนาดา จะครอบคลุมถึงข้อกำหนดเรื่องถิ่นที่อยู่ของข้อมูลในประเทศนั้น
• คุณรันเซิร์ฟเวอร์เกม: ผู้เล่นจะรู้สึกได้ถึงทุกมิลลิวินาทีของ round-trip time ดังนั้นความใกล้ชิดกับผู้เล่นจึงสำคัญกว่าสเปกอื่นใดทั้งหมด โดย การเลือก VPS สำหรับเซิร์ฟเวอร์เกม จะช่วยอธิบายรายละเอียดในส่วนนี้

สำหรับกลุ่มผู้ชมในยุโรปที่กระจายตัวอยู่หลายประเทศ Frankfurt ถือเป็นตัวเลือกเดียวที่ปลอดภัย และยังคงปลอดภัยเมื่อคุณขยายระบบ เนื่องจากเครือข่ายที่คุณต้องเชื่อมต่อมีจุดแลกเปลี่ยนข้อมูลอยู่ที่นั่นอยู่แล้ว ให้ทำการวัดค่าจากตำแหน่งที่ผู้ใช้งานของคุณอยู่ก่อนที่จะย้ายระบบ และวัดซ้ำอีกครั้งหลังจากย้ายเสร็จสิ้น พร้อมทั้งเก็บข้อมูลตัวเลขทั้งสองชุดไว้เปรียบเทียบกัน

FAQ

VPS หนึ่งเครื่องใน Frankfurt เพียงพอสำหรับทั้งยุโรปหรือไม่?

สำหรับโปรเจกต์ส่วนใหญ่ถือว่าเพียงพอ ระยะทางตามแนวเส้นตรงทำให้ค่าความหน่วงต่ำสุดอยู่ที่ 12.0 ms ไปยัง Stockholm และ 14.2 ms ไปยัง Madrid โดยเส้นทางจริงจะมีค่าความหน่วงประมาณ 1.5 ถึง 2 เท่าของค่าต่ำสุด ดังนั้นเกือบทั้งสหภาพยุโรปจะยังคงอยู่ในระยะความหน่วงระดับหลักสิบมิลลิวินาทีจากเซิร์ฟเวอร์ใน Frankfurt เพียงเครื่องเดียว ให้เพิ่มตำแหน่งที่สองเมื่อคุณได้รับข้อร้องเรียนจริงจากประเทศใดประเทศหนึ่ง หรือเมื่อคุณต้องการระบบ failover มากกว่าความเร็ว

การโฮสต์ใน Frankfurt ทำให้โปรเจกต์ของฉันสอดคล้องกับ GDPR หรือไม่?

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

ฉันควรคาดหวังค่าความหน่วงระหว่าง Frankfurt และ Berlin ไว้ที่เท่าใด?

ทั้งสองเมืองห่างกัน 424 km ซึ่งกำหนดค่าต่ำสุดของ round-trip time ไว้ที่ 4.2 ms เส้นทางที่มีการเชื่อมต่อที่ดีมักจะมีค่าความหน่วงอยู่ที่ 1.5 ถึง 2 เท่าของค่าต่ำสุด ให้ตรวจสอบด้วย ping -c 20 your-server.example.com จากการเชื่อมต่อใน Berlin และอ่านค่า avg ในบรรทัด rtt min/avg/max/mdev หากผลลัพธ์สูงกว่าช่วงดังกล่าวมาก มักหมายความว่าทราฟฟิกออกนอกประเทศเยอรมนีแล้ววนกลับมา ซึ่ง mtr -rwzc 50 จะแสดงให้คุณเห็นในชื่อของ hop ต่างๆ

ฉันควรตั้งค่า timezone ของเซิร์ฟเวอร์ใน Frankfurt เป็น Europe/Berlin หรือไม่?

โดยปกติแล้วไม่ควร ให้คงระบบไว้ที่ UTC เพื่อให้ log สามารถเปรียบเทียบกันได้และไม่มีความกำกวมของ timestamp ประเทศเยอรมนีมีการปรับเวลาเป็น CEST ในฤดูใบไม้ผลิและกลับเป็น CET ในฤดูใบไม้ร่วง ซึ่งในคืนฤดูใบไม้ร่วงจะมีช่วงเวลาหนึ่งชั่วโมงที่เกิดขึ้นซ้ำสองครั้ง ทำให้เหตุการณ์ที่ต่างกันสองเหตุการณ์อาจมี timestamp เดียวกันได้ ให้จัดรูปแบบเวลาตามโซนท้องถิ่นในแอปพลิเคชันของคุณ ซึ่งเป็นที่ที่คุณมีบริบทเพียงพอที่จะจัดการได้อย่างถูกต้อง หากคุณต้องการให้ทั้งเครื่องใช้เวลาท้องถิ่นจริงๆ ให้รัน sudo timedatectl set-timezone Europe/Berlin และตรวจสอบด้วย timedatectl

เซิร์ฟเวอร์ที่มีเฉพาะ IPv4 จะเป็นปัญหากับผู้เข้าชมในเยอรมนีหรือไม่?

เซิร์ฟเวอร์จะทำงานได้ แต่จะช้าลงสำหรับผู้เข้าชมบางกลุ่ม ผู้ให้บริการอินเทอร์เน็ตในเยอรมนีหลายรายให้การเชื่อมต่อแบบ DS-Lite แก่ผู้ใช้ตามบ้านโดยไม่มี public IPv4 address ดังนั้นลูกค้าเหล่านั้นจึงเข้าถึงเซิร์ฟเวอร์ที่มีเฉพาะ IPv4 ผ่าน gateway การแปลที่อยู่ของเครือข่าย ซึ่งจะเพิ่มความหน่วงและเกิดความแออัดในช่วงเวลาที่มีการใช้งานสูง การประกาศ AAAA record และเปิดรับการเชื่อมต่อบน IPv6 จะช่วยให้พวกเขามีเส้นทางที่ตรงไปถึงเซิร์ฟเวอร์ได้ ทดสอบด้วย dig AAAA your-server.example.com +short และคำขอ curl -6 โดยคาดหวังว่าจะได้รับ HTTP 200 จากทั้งสอง address family