VPS Frankfurt: Latensi, DE-CIX, dan GDPR

Untuk siapa VPS hosting di Frankfurt cocok

VPS hosting di Frankfurt cocok untuk proyek yang penggunanya berada di Jerman, di pasar berbahasa Jerman yang lebih luas, atau tersebar di Uni Eropa. Frankfurt merupakan salah satu titik pertemuan jaringan Eropa, tempat jaringan tersebut saling bertukar trafik secara langsung. Karena itu, server di sana dapat menjangkau sebagian besar benua dengan waktu tempuh beberapa puluh milidetik. Jika sebagian besar pengguna Anda berada di Amerika Utara, server di Eropa akan terasa lambat bagi mereka secepat apa pun mesin tersebut, karena jarak menetapkan batas minimum yang tidak dapat dihilangkan dengan penyetelan.

Ada dua pertanyaan terpisah yang menentukan lokasi. Mencampur keduanya akan menghasilkan pilihan yang buruk. Pertama, di mana pengguna Anda berada. Ini merupakan pertanyaan tentang jarak dan waktu pulang-pergi. Kedua, di mana data Anda diizinkan untuk disimpan. Ini merupakan pertanyaan hukum dan kontraktual. Frankfurt memberikan jawaban yang kuat untuk pertanyaan pertama bagi audiens Eropa. Untuk pertanyaan kedua, Frankfurt hanya menghilangkan satu masalah tertentu dan tidak menyelesaikan masalah lainnya.

Mengapa Frankfurt memiliki konektivitas yang sangat baik?

Frankfurt menjadi lokasi DE-CIX (Deutsche Commercial Internet Exchange), sebuah IXP (internet exchange point) yang termasuk salah satu yang terbesar di dunia berdasarkan trafik puncak dan jumlah jaringan yang terhubung. IXP adalah fabric switching bersama di dalam pusat data. Di sana, jaringan independen saling terhubung tanpa harus membayar jaringan yang lebih besar untuk membawa trafik di antara jaringan tersebut. DE-CIX memublikasikan statistik trafik terkini pada situsnya sendiri. Angka tersebut berubah, jadi baca langsung di sana dan jangan mengandalkan angka yang disalin ke dalam artikel.

Dampak praktisnya berkaitan dengan jalur, bukan jumlah total. Jika jaringan provider Anda dan ISP (internet service provider) pengunjung Anda sama-sama terhubung ke exchange yang sama, trafik di antara keduanya melewati satu hop terarah pada exchange tersebut. Jika keduanya tidak melakukan peering secara lokal, trafik harus mencapai jaringan ketiga yang membawa trafik dari kedua jaringan tersebut. Titik serah-terima terdekat milik jaringan itu mungkin berada di negara lain. Dua jaringan Jerman yang bertukar trafik melalui Amsterdam atau London harus menempuh jarak tambahan dua kali, satu kali untuk setiap arah. Teknisi jaringan menyebut kondisi ini tromboning. Inilah alasan yang biasanya membuat server yang lokasinya dekat terukur seolah-olah berada jauh.

Anda dapat melihatnya, bukan sekadar mengasumsikannya. Jalankan mtr terhadap server Anda dari jaringan yang ingin diperiksa, lalu baca nama hop pada reverse DNS. Nama host router biasanya memuat kode bandara IATA. Karena itu, fra pada nama hop berarti Frankfurt, ams berarti Amsterdam, dan lhr berarti London. Jalur dari koneksi konsumen di Jerman ke server di Jerman yang menampilkan lhr di tengah menunjukkan secara tepat ke mana milidetik tambahan tersebut digunakan.

Seberapa jauh Frankfurt dari pengguna Anda?

Sinyal cahaya dalam serat optik bergerak dengan kecepatan kira-kira dua pertiga dari kecepatannya dalam ruang hampa, yaitu hampir 200,000 kilometer per detik. Perjalanan pulang-pergi menempuh jalur tersebut dua kali. Karena itu, waktu pulang-pergi tercepat yang mungkin untuk jarak d kilometer adalah d/100 milidetik. Nilai ini merupakan batas minimum dan berguna karena tidak ada yang dapat melampauinya.

[
  {
    "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
  }
]

Nilai ini dihitung berdasarkan jarak garis lurus, bukan hasil pengukuran. Anggap kolom terakhir sebagai kondisi terbaik yang diizinkan oleh hukum fisika. Hasil pengukuran nyata biasanya berada antara 1.5 dan 2 kali batas minimum tersebut. Serat optik mengikuti jalan dan lembah sungai, bukan lintasan lingkaran besar. Selain itu, setiap router di sepanjang jalur menambahkan sedikit latensi penerusan dan antrean.

Berlin berjarak 424 km dari Frankfurt, dengan batas minimum sebesar 4.2 ms. Madrid berjarak 1,419 km, dengan batas minimum sebesar 14.2 ms. Kota ini merupakan titik terjauh di Uni Eropa dari sini. New York berjarak 6,206 km, dengan batas minimum sebesar 62.1 ms. Karena itu, audiens lintas Atlantik memerlukan keputusan lokasi, bukan sekadar penyetelan.

Berapa biaya perjalanan pulang-pergi yang lambat terhadap waktu pemuatan halaman?

Satu perjalanan pulang-pergi jarang hanya berarti satu perjalanan pulang-pergi. Membuka koneksi HTTPS memerlukan satu perjalanan pulang-pergi untuk handshake TCP (transmission control protocol) dan satu lagi untuk handshake TLS (transport layer security) 1.3. Permintaan tersebut kemudian memerlukan perjalanan ketiga sebelum byte pertama respons diterima. TLS 1.2 menambahkan perjalanan keempat. Pencarian DNS (domain name system) yang belum tersimpan dalam cache menambahkan setidaknya satu perjalanan lagi, kali ini ke server yang berbeda.

[
  {
    "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
  }
]

Kolom perjalanan pulang-pergi di sini mengasumsikan jalur yang masuk akal menuju server Frankfurt, sedangkan kolom kedua merupakan perhitungannya: tiga perjalanan pulang-pergi sebelum byte pertama diterima. Pengguna di Frankfurt menunggu 15 ms. Pengguna di Singapura, dengan waktu perjalanan pulang-pergi 170 ms, menunggu 510 ms untuk respons yang sama, sebelum browser menampilkan apa pun.

Pengalinya adalah inti persoalannya. Setiap tambahan 1 ms RTT (round-trip time) menambah sekitar 3 ms sebelum byte pertama diterima, dan dampaknya terus berlanjut. HTML menyebutkan stylesheet, lalu stylesheet menyebutkan font, dan setiap penemuan tersebut memerlukan perjalanan pulang-pergi lain pada koneksi yang sama. Menambahkan jarak yang menghasilkan beberapa ratus milidetik dapat mengubah halaman yang sebelumnya terasa instan menjadi halaman yang terasa lambat, meskipun server melakukan pekerjaan yang sama dalam waktu yang sama persis.

Hal ini juga menunjukkan batas manfaat CDN (content delivery network). File statis yang disajikan dari cache dekat pengguna tidak perlu melewati jalur yang panjang. Dashboard untuk pengguna yang login dan harus meminta data dari database Anda tidak demikian: permintaan tersebut tetap menempuh seluruh jarak sebanyak dua kali. Menempatkan origin dekat dengan orang yang login adalah hal yang tidak dapat dilakukan oleh cache untuk Anda.

Bagaimana cara mengukurnya dari lokasi pengguna saya?

Jalankan perintah ini dari mesin di jaringan yang ingin Anda ukur, idealnya dari koneksi rumah atau kantor di negara tempat Anda melayani pengguna. Pengukuran dari server lain di pusat data yang berbeda hanya menunjukkan jalur menuju pusat data tersebut, bukan kondisi yang dialami pengguna. Perintah di bawah ini adalah contoh yang dapat Anda jalankan sendiri. Hanya angka latensi hasil pengukuran Anda yang layak dijadikan dasar tindakan.

ping -c 20 your-server.example.com

Baris ringkasan menampilkan rtt min/avg/max/mdev = .... Gunakan avg untuk melihat kondisi tipikal dan mdev untuk melihat jitter, yaitu variasi antar-paket. avg yang normal dengan mdev yang tinggi menunjukkan bahwa jalurnya tidak stabil. Kondisi ini lebih mengganggu pekerjaan interaktif seperti SSH atau komunikasi suara dibandingkan rata-rata latensi yang sedikit lebih tinggi.

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

-r menampilkan laporan, bukan tampilan langsung. -w mempertahankan hostname yang panjang secara utuh. -z menampilkan nomor AS (autonomous system) untuk setiap hop. -c 50 mengirimkan lima puluh siklus. Packet loss pada satu hop di tengah, tanpa loss pada hop terakhir, adalah kondisi normal dan bukan kesalahan. Banyak router membatasi laju balasan ICMP yang mereka hasilkan sendiri, tetapi tetap meneruskan trafik lain dengan baik. Loss yang dimulai pada suatu hop dan berlanjut pada setiap hop setelahnya adalah loss yang nyata.

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/

Setiap field menunjukkan jumlah detik kumulatif sejak permintaan dimulai, sehingga nilainya dibaca dengan pengurangan. time_namelookup adalah DNS. time_connect dikurangi nilai tersebut adalah TCP handshake, yang durasinya mendekati satu round trip. time_appconnect dikurangi time_connect adalah TLS handshake. time_starttransfer dikurangi time_appconnect adalah waktu pemrosesan aplikasi Anda sendiri ditambah satu round trip lagi. Jika selisihnya kecil dan total tetap besar, masalahnya ada pada kode Anda, bukan pada kota tersebut.

Untuk mengukur throughput, bukan latensi, jalankan iperf3 -s pada VPS, buka portnya pada firewall, lalu jalankan iperf3 -c your-server.example.com -R dari client untuk menguji arah download. Untuk mengukur dari lokasi yang tidak memiliki mesin, RIPE Atlas menyediakan probe di seluruh Eropa. Saat membandingkan dua server, bukan dua jaringan, gunakan metode yang tetap, bukan angka dari satu kali pengukuran. Itulah kegunaan benchmark VPS yang dapat diulang.

Apakah server di Frankfurt membuat proyek saya patuh terhadap GDPR?

Tidak, dan alasannya perlu dijelaskan secara tepat. GDPR (General Data Protection Regulation) berlaku berdasarkan data pribadi milik siapa yang Anda proses dan tempat organisasi Anda didirikan, bukan berdasarkan negara tempat perangkat keras berada. Memindahkan server ke Frankfurt tidak membuat Anda patuh, dan menjalankan server di luar Uni Eropa tidak otomatis berarti Anda melanggar. Lokasi hanyalah salah satu dari beberapa faktor.

Hosting di dalam Uni Eropa atau EEA (European Economic Area) yang lebih luas menghilangkan persoalan transfer internasional. Regulasi tersebut memiliki satu bab khusus tentang pengiriman data pribadi ke luar EEA, yang memerlukan instrumen hukum seperti keputusan kecukupan atau klausul kontrak standar. Data yang tetap berada di Frankfurt tidak sedang ditransfer, sehingga bab tersebut tidak berlaku untuk perpindahan itu. Ini merupakan penyederhanaan yang nyata, dan itulah manfaatnya secara tepat.

Hal lainnya tetap menjadi tanggung jawab Anda. Anda tetap memerlukan dasar hukum untuk setiap tujuan pemrosesan, mekanisme akses dan penghapusan yang berfungsi bagi orang-orang dalam basis data Anda, batas retensi yang benar-benar Anda terapkan, langkah keamanan yang sesuai dengan risikonya, serta laporan kepada otoritas pengawas dalam waktu 72 jam setelah mengetahui adanya pelanggaran data pribadi. Anda juga memerlukan perjanjian pemrosesan dengan penyedia hosting, yang di Jerman dikenal sebagai Auftragsverarbeitungsvertrag atau AVV. Perhatikan pula bahwa server di Frankfurt tetap dapat melibatkan transfer jika staf dukungan di luar EEA dapat mengaksesnya. Karena itu, periksa siapa yang memegang kunci kriptografis.

Jerman menambahkan lapisannya sendiri: BDSG (Bundesdatenschutzgesetz) federal melengkapi regulasi tersebut dengan aturan nasional, dan data karyawan merupakan area yang paling sering mengejutkan banyak orang. Bagian ini merupakan informasi umum, bukan nasihat hukum. European Data Protection Board menerbitkan pedoman resminya di edpb.europa.eu, dan hal apa pun yang memiliki konsekuensi nyata sebaiknya ditangani oleh penasihat yang berkualifikasi, bukan hanya berdasarkan tutorial.

Apa yang harus saya ubah langsung pada server?

Pertahankan jam sistem dalam UTC (coordinated universal time), lalu format timestamp di aplikasi Anda. Jerman menerapkan daylight saving time, sehingga waktu lokal bergeser satu jam dua kali setahun dan satu jam pada akhir Oktober berulang. Log yang ditulis dalam waktu lokal berisi dua entri 02:30 pada malam tersebut. Menghubungkan entri itu dengan log dari wilayah lain menjadi perkiraan. Jika Anda tetap ingin menggunakan waktu lokal pada server, tetapkan secara eksplisit dan periksa hasilnya:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Output harus menampilkan Time zone: Europe/Berlin (CEST, +0200) pada musim panas dan +0100 pada musim dingin.

Teks Jerman diurutkan secara keliru dalam locale C default karena pengurutan C membandingkan byte mentah. Buat locale tersebut dan amati perbedaannya:

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

Pengurutan pertama menempatkan Äpfel setelah Zebra karena byte pertamanya dalam UTF-8 lebih besar daripada byte huruf ASCII mana pun. Pengurutan kedua menempatkannya di sebelah Apfel, sesuai dengan urutan yang diharapkan pembaca bahasa Jerman. Hal ini lebih penting daripada kelihatannya karena PostgreSQL dan MySQL menetapkan collation saat database dibuat, dan mengubahnya nanti berarti membangun ulang indeks. Tentukan collation sebelum memuat data.

Mirror paket di Jerman memperpendek proses apt. Pada Ubuntu 24.04, sumber paket berada di /etc/apt/sources.list.d/ubuntu.sources dalam format deb822. Karena itu, ubah baris URIs: menjadi http://de.archive.ubuntu.com/ubuntu/, bukan menambahkan file kedua. Penambahan file kedua akan menghasilkan Target Packages ... is configured multiple times, yaitu error sumber duplikat deb822, dan menghentikan pembaruan sampai masalah tersebut diselesaikan.

Publikasikan record AAAA. Sebagian ISP Jerman memberikan koneksi konsumen dengan konfigurasi DS-Lite (dual-stack lite), sehingga pelanggan sama sekali tidak memiliki alamat IPv4 publik dan trafik IPv4 mereka melewati gateway translasi milik operator. Gateway tersebut menambah latensi dan mengalami kepadatan trafik pada jam sibuk, sedangkan trafik IPv6 langsung keluar. Periksa kedua jalur setelah Anda menetapkan record tersebut:

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

200 dari perintah kedua berarti IPv6 berfungsi dari ujung ke ujung. Could not resolve host atau error koneksi berarti record atau listener belum tersedia, sehingga pengunjung dengan DS-Lite menggunakan jalur yang lambat.

Kapan Frankfurt bukan pilihan yang tepat

• Pengguna Anda berada di Amerika Serikat. Layani mereka dari sana: VPS di Dallas berada dekat pusat negara tersebut, sedangkan hosting VPS di New York menawarkan rute yang lebih singkat ke pantai timur dan untuk trafik yang memang melintasi Atlantik.
• Pengguna Anda berada di Amerika Latin. Jarak Frankfurt ke São Paulo lebih jauh daripada jaraknya ke New York, sehingga VPS di Brasil merupakan pilihan yang tepat untuk pengguna tersebut.
• Data Anda harus tetap berada di negara tertentu di luar Uni Eropa. Pekerjaan sektor publik Kanada adalah kasus yang umum, dan hal yang sebenarnya penting dalam hosting VPS Kanada membahas lokasi penyimpanan data di negara tersebut.
• Anda menjalankan server game. Pemain merasakan setiap milidetik waktu pulang-pergi, sehingga kedekatan dengan mereka lebih penting daripada spesifikasi lainnya: memilih VPS untuk server game membahas hal ini.

Untuk pengguna di Eropa yang tersebar di beberapa negara, Frankfurt adalah pilihan tunggal yang aman. Pilihan ini tetap aman saat Anda berkembang karena jaringan yang perlu Anda jangkau sudah terhubung ke exchange tersebut. Ukur dari lokasi pengguna sebelum Anda berpindah dan ukur lagi setelahnya, lalu simpan kedua kumpulan angka tersebut.

FAQ

Apakah satu VPS di Frankfurt cukup untuk seluruh Eropa?

Untuk sebagian besar proyek, ya. Jarak garis lurus menghasilkan batas minimum 12.0 ms ke Stockholm dan 14.2 ms ke Madrid. Rute aktual biasanya memiliki latensi sekitar 1.5 hingga 2 kali batas minimum tersebut. Jadi, hampir seluruh wilayah Uni Eropa tetap berada dalam kisaran puluhan milidetik yang rendah dari satu server di Frankfurt. Tambahkan lokasi kedua jika Anda telah mengukur keluhan nyata dari negara tertentu atau memerlukan failover, bukan sekadar kecepatan.

Apakah hosting di Frankfurt membuat proyek saya mematuhi GDPR?

Tidak. GDPR berlaku berdasarkan data pribadi yang Anda proses dan lokasi pendirian Anda, bukan lokasi server. Hosting di Uni Eropa menghilangkan pertanyaan tentang transfer internasional pada hop tersebut. Ini merupakan penyederhanaan yang nyata dan merupakan seluruh manfaatnya. Anda tetap memerlukan dasar hukum, mekanisme hak subjek data yang berfungsi, batas retensi, langkah-langkah keamanan, pelaporan pelanggaran dalam 72 jam, serta perjanjian pemrosesan dengan provider Anda, yang disebut AVV di Jerman. Ini adalah informasi umum, bukan nasihat hukum.

Berapa latensi yang seharusnya saya perkirakan antara Frankfurt dan Berlin?

Kedua kota tersebut berjarak 424 km. Jarak ini menetapkan batas minimum waktu pulang-pergi sebesar 4.2 ms. Rute dengan peering yang baik biasanya mengukur 1.5 hingga 2 kali batas minimumnya. Konfirmasikan dengan ping -c 20 your-server.example.com dari koneksi di Berlin dan baca nilai avg pada baris rtt min/avg/max/mdev. Hasil yang jauh di atas kisaran tersebut biasanya berarti trafik keluar dari Jerman lalu kembali lagi. mtr -rwzc 50 akan menampilkannya pada nama hop.

Haruskah saya mengatur timezone server Frankfurt ke Europe/Berlin?

Biasanya tidak. Pertahankan sistem pada UTC agar log tetap mudah dibandingkan dan tidak ada timestamp yang ambigu. Jerman beralih ke CEST pada musim semi dan kembali ke CET pada musim gugur. Pada malam perubahan ke waktu musim gugur, satu jam lokal terjadi dua kali. Akibatnya, dua peristiwa berbeda dapat memiliki timestamp lokal yang sama. Format waktu dalam zona lokal di aplikasi Anda, karena aplikasi memiliki konteks untuk melakukannya dengan benar. Jika Anda ingin seluruh mesin menggunakan waktu lokal, jalankan sudo timedatectl set-timezone Europe/Berlin dan verifikasi dengan timedatectl.

Apakah server yang hanya menggunakan IPv4 akan menjadi masalah bagi pengunjung dari Jerman?

Server tersebut tetap dapat digunakan, tetapi bagi sebagian pengunjung koneksinya lebih lambat. Beberapa ISP di Jerman memberikan koneksi konsumen dengan konfigurasi DS-Lite tanpa alamat IPv4 publik. Akibatnya, pelanggan tersebut mengakses server yang hanya menggunakan IPv4 melalui gateway translasi milik operator. Gateway ini menambah latensi dan dapat mengalami kepadatan pada waktu sibuk. Publikasikan record AAAA dan aktifkan listening pada IPv6 agar mereka mendapatkan rute langsung. Uji dengan dig AAAA your-server.example.com +short dan request curl -6. Pastikan Anda mendapatkan HTTP 200 dari kedua keluarga alamat.