암스테르담 VPS 호스팅 선택 시 고려할 핵심 요소

암스테르담 VPS 호스팅을 선택하는 이유

암스테르담 VPS 호스팅은 무엇보다 네트워크 결정의 문제입니다. 암스테르담은 유럽의 주요 상호 연결 지점 중 하나이며, 이는 수많은 독립 네트워크가 이곳에서 만나 서로 트래픽을 직접 주고받는다는 것을 의미합니다. 해당 대도시 지역에 위치한 서버는 영국, 북유럽, 독일, 프랑스 및 베네룩스 국가들로 짧은 경로를 통해 적은 수의 네트워크를 거쳐 도달하는 경향이 있습니다.

이것이 선택의 근거입니다. 이 가이드의 나머지 부분은 이러한 이점이 귀하의 사용자에게도 유효한지 확인하는 방법에 관한 것입니다. 모든 사용자에게 해당되는 것은 아니기 때문입니다. 암스테르담은 북서부 유럽 전역에 고객 기반이 퍼져 있는 경우 좋은 기본 선택지입니다. 하지만 트래픽의 대부분이 바르샤바, 이스탄불, 상파울루 또는 토론토에서 발생한다면 좋은 선택이 아닙니다. 네덜란드에서의 우수한 피어링이 해당 지역까지의 거리를 단축해주지는 않기 때문입니다.

인터넷 익스체인지의 실체

인터넷 익스체인지 포인트(IXP)는 공유 스위칭 패브릭입니다. 독립적인 네트워크들이 이곳의 포트를 임대하여 한 번 연결하면, 다른 회원들과 직접 트래픽을 교환할 수 있습니다. 암스테르담에서 가장 잘 알려진 곳은 AMS-IX(Amsterdam Internet Exchange)입니다. 이 도시에는 다른 익스체인지도 존재하지만, 그 개수가 중요한 것은 아닙니다.

익스체인지가 지연 시간을 변화시키는 이유를 이해하려면 패킷이 네트워크 사이를 이동하는 두 가지 방식을 알아야 합니다. 첫 번째는 트랜짓(transit)으로, 더 큰 네트워크에 비용을 지불하고 인터넷의 나머지 부분으로 트래픽을 전달하는 방식입니다. 두 번째는 피어링(peering)으로, 두 네트워크가 서로 직접 트래픽을 전달하기로 합의하는 방식이며 보통 금전 거래는 발생하지 않습니다. 여기서 각 네트워크는 고유한 번호와 라우팅 정책을 가진 자율 시스템(AS)입니다.

트랜짓 경로는 지리적 요인만큼이나 비즈니스 관계에 의해 결정됩니다. 유럽의 한 도시 서버에서 다른 도시의 광대역 고객에게 전달되는 패킷은 제3의 도시로 이동하여 네트워크를 변경한 뒤 다시 돌아올 수도 있습니다. 이는 고장 난 것이 아닙니다. 단지 비용과 라우팅 정책에 의해 생성된 경로일 뿐입니다. 익스체인지에서는 두 네트워크가 패킷을 현지에서 직접 전달할 수 있으므로 경로가 짧아지고, 관여하는 네트워크 수가 줄어들며, 혼잡이 발생할 지점도 감소합니다.

여기서 간과하기 쉬운 부분이 있습니다. 도시에 익스체인지가 있다고 해서 귀하의 VPS가 자동으로 그곳에 연결되는 것은 아닙니다. 중요한 것은 귀하의 제공업체가 보유한 자체 네트워크입니다. 즉, 어떤 트랜짓 제공업체로부터 서비스를 구매하는지, 어떤 익스체인지에 가입했는지, 사용자가 속한 소비자 및 모바일 네트워크와 피어링을 맺고 있는지, 그리고 각 경로에 대한 용량이 얼마나 되는지가 중요합니다. 같은 건물에 있는 두 서버라도 외부로 나가는 경로는 매우 다를 수 있습니다. 제공업체에 AS 번호를 문의한 뒤, PeeringDB에서 해당 번호를 조회해 보십시오. 이곳에서 네트워크들은 자신들이 위치한 시설과 익스체인지 정보를 공개합니다. 아래 측정 섹션에서 설명하는 것처럼 실시간 경로에서 AS 번호를 직접 확인할 수도 있습니다.

암스테르담인가 프랑크푸르트인가: 지도가 아닌 사용자를 보고 결정하십시오

대부분의 독자가 실제로 직면하는 현실적인 선택이며, 두 도시 모두 주요 상호 연결 지점입니다. 프랑크푸르트는 DE-CIX가 위치하며 중부, 동부, 남동부 유럽과 빈, 바르샤바, 프라하, 중동으로 향하는 경로의 일반적인 선택지입니다. 암스테르담은 영국, 아일랜드, 스칸디나비아, 베네룩스 지역에 적합하며 북서부 유럽에 상륙하는 해저 케이블을 사용하는 트래픽에 유리합니다. 이 두 가지를 측정값이 아닌 경향성으로 간주하십시오. 라우팅은 변경되고 공급자는 업스트림을 바꾸며, 귀하의 공급자가 맺은 피어링은 도시 단위의 일반화보다 훨씬 구체적이기 때문입니다.

따라서 귀하의 데이터를 바탕으로 결정하십시오.

1. 사용자가 실제로 어디에 있는지 기록하십시오. 웹 서버 접근 로그, 분석 도구 또는 고객 목록에 이미 이 정보가 있습니다.
2. 봇에 의해 부풀려진 단순 조회수 대신 수익이나 활성 계정과 같이 중요한 지표를 기준으로 목록에 가중치를 부여하십시오.
3. 각 후보 도시에서 가장 작은 플랜을 한 달간 임대하여 실제 사용자 연결을 통해 두 곳 모두를 측정하십시오.
4. 마케팅 페이지에 적힌 숫자가 아닌, 직접 수집한 숫자를 비교하십시오.

이 작업에 일주일을 투자하기 전에 한 가지 솔직한 주의 사항을 말씀드립니다. 서유럽 내의 사용자 기반이라면, 잘 연결된 두 유럽 대도시 간의 차이는 애플리케이션 자체가 추가하는 지연 시간보다 작은 경우가 많습니다. 데이터베이스 쿼리를 순차적으로 10번 실행하는 페이지는 왕복 지연 시간을 10번 지불하게 되므로, 쿼리 패턴이 도시 선택보다 더 큰 비용을 발생시킬 수 있습니다. 애플리케이션도 함께 측정하십시오. 반대편에서 질문하는 내용은 프랑크푸르트 VPS 선택 가이드에 있으며, 결정적인 요소는 종종 필요한 플랜 크기와 디스크를 갖춘 위치가 어디인지와 같은 사소한 부분인 경우가 많습니다.

암스테르담까지의 지연 시간을 직접 측정하는 방법

사용자가 사용하는 연결 환경에서, 혹은 그와 최대한 유사한 환경에서 다음 명령을 실행하십시오. 맨체스터의 사무실 광랜은 모바일 연결을 대변하지 못합니다.

Debian이나 Ubuntu에서는 먼저 도구를 설치하십시오.

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

왕복 횟수 측정부터 시작하십시오.

ping -c 20 ams.example.com

마지막 요약 정보는 rtt min/avg/max/mdev로 표시됩니다. avg 값은 밀리초 단위의 일반적인 왕복 시간이며, mdev은 그 변동 폭인 지터(jitter)입니다. 같은 블록에서 패킷 손실률을 확인하십시오. 목적지에서의 손실은 실제 문제입니다. 중간 홉 하나에서만 손실이 보고되고 그 이후의 모든 홉에서 수치가 정상이라면, 이는 보통 문제가 아닙니다. 라우터는 자신에게 전달된 패킷에 대한 응답을 낮은 우선순위로 처리하기 때문입니다.

그다음 경로 자체를 확인하십시오.

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

각 줄은 하나의 홉을 나타내며, --aslookup는 AS 번호를 출력하므로 패킷이 어떤 네트워크를 거치고 어디에서 공급자를 떠나는지 확인할 수 있습니다. 왕복 시간이 증가한 뒤 그 이후의 모든 홉에서도 높게 유지되는 지점을 찾으십시오. 그곳이 지연이 발생하는 지점입니다. raw socket을 열 수 없어 mtr이 종료된다면 sudo 플래그를 사용하여 실행하십시오. 일부 네트워크는 ICMP의 우선순위를 낮게 설정하거나 차단하므로, 사용자가 연결하는 방식인 TCP를 사용하여 서비스 포트로도 측정하십시오.

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

그다음 네트워크와 서버를 분리하여 확인하십시오.

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

모든 값은 요청 시작 후 경과한 초 단위이므로, 값 사이의 간격이 곧 지연 시간입니다. connect에서 dns를 뺀 값은 대략 한 번의 왕복 시간인 TCP 핸드셰이크 시간입니다. tls에서 connect를 뺀 값은 TLS(transport layer security) 핸드셰이크 시간이며, 이는 더 많은 왕복을 필요로 하므로 거리 증가에 따라 다른 요소보다 더 빠르게 늘어납니다. ttfb에서 tls을 뺀 값은 주로 서버의 처리 시간입니다. 이러한 세부 분석이 가능한 덕분에 구매 결정을 내릴 때는 ping보다 curl이 더 유용합니다. 총 시간은 긴데 ttfb 간격이 작다면 서버가 물리적으로 멀리 있는 것입니다. ttfb 간격이 큰데 연결 속도가 빠르다면 서버는 가까이 있지만 애플리케이션이 느린 것입니다.

지연 시간은 혼잡도에 따라 시간대별로 변합니다. 한 번의 실행 결과만 믿지 말고 하루 동안 여러 번 샘플링하십시오.

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

네트워크는 구매 결정의 절반입니다. 나머지 절반은 디스크와 CPU입니다. 과도하게 할당된 노드에 위치한 서버는 잘 배치된 서버라도 느리게 느껴질 수 있으므로, 1년 약정을 하기 전에 적절한 VPS 벤치마크를 통해 체험 플랜을 테스트하십시오.

EU 데이터 레지던시의 쉬운 이해

데이터 레지던시는 데이터가 저장되고 처리되는 물리적 위치를 의미합니다. 네덜란드는 유럽 연합(EU) 및 유럽 경제 지역(EEA)에 속하므로, 암스테르담에 있는 서버는 귀하의 데이터를 EU 인프라 내에 보관합니다. 이는 위치 문제를 해결해주지만, 위치는 규정 준수(compliance)를 위한 여러 요소 중 하나일 뿐입니다.

GDPR(일반 데이터 보호 규정)은 개인 데이터가 EU 밖으로 나가는 것을 금지하지 않습니다. 대신 데이터 전송에 대한 조건을 설정하며, 귀하를 대신하여 데이터를 처리하는 다른 기업들에게도 적용됩니다. 따라서 "서버가 EU에 있는가"라는 질문보다 "이 데이터의 모든 복사본이 최종적으로 어디에 도달하는가"를 파악하는 것이 훨씬 유용합니다.

레지던시 주장이 흔히 실패하는 지점이 바로 여기입니다. VPS는 암스테르담에 있고 데이터베이스도 그 위에 있습니다. 하지만 백업은 다른 지역의 오브젝트 스토리지로 전송되고, 애플리케이션 로그는 호스팅된 검색 서비스로 스트리밍되며, 오류 추적 정보는 모니터링 업체로 전달되고, 트랜잭션 이메일은 제3자를 통해 발송되며, 사용자 텍스트는 요약을 위해 API로 전송됩니다. 이들 각각은 개인 데이터를 어딘가로 이동시킵니다. 위치 요구 사항은 귀하가 의도적으로 선택한 장비뿐만 아니라 이 모든 경로를 포괄합니다.

두 가지 동기를 분리하십시오. 각각 다른 설계 방식을 요구하기 때문입니다. 계약, 규제 기관 또는 고객이 EU 인프라를 요구한다면 이는 규정 준수 요구 사항이며, 문서로 명시되어 있고 특정 지역 내에 머물도록 강제할 수 있습니다. 사용자와 가까운 곳에 서버를 두어 페이지 로딩 속도를 높이려는 것이라면 이는 지연 시간(latency) 요구 사항이며, 지역을 추가하도록 유도할 수 있습니다. 성능 결정을 정당화하기 위해 규정 준수 용어를 사용하면 나중에 두 질문 모두에 제대로 답변할 수 없게 됩니다.

제공업체에 누가 장비에 접근할 수 있는지, 지원 인력은 어디에 위치하는지, 해당 기업이 어떤 법률의 적용을 받는지, 그리고 EEA 외부의 하위 처리자가 있는지 문의하십시오. 이러한 답변은 데이터 처리 계약(DPA)에 포함되어야 합니다. 감사인은 서명된 문서를 요구하며, 지원 티켓은 증빙 자료가 되지 않기 때문입니다. 전체적인 방법론은 캐나다 데이터를 위해 작성된 레지던시 프레임워크를 그대로 적용할 수 있습니다. 데이터를 나열하고, 데이터를 다루는 모든 처리자를 기록하고, 충족해야 할 규칙을 적은 다음, 마지막으로 위치를 선택하십시오. 이 내용은 질문해야 할 사항에 대한 설명이며 법률 자문이 아닙니다.

암스테르담을 선택해도 해결되지 않는 문제

• 다른 지역과의 물리적 거리. 신호는 진공 상태 빛 속도의 약 3분의 2 정도로 광섬유를 통과하며, 케이블 경로는 항상 직선거리보다 깁니다. 따라서 싱가포르의 사용자는 유럽의 어느 도시를 선택하든 거리로 인한 지연 시간을 감수해야 합니다.
• 통신이 잦은 애플리케이션. 이전 요청이 완료되기를 기다리는 모든 요청은 왕복 지연 시간을 매번 지불해야 합니다.
• 단일 리전 위험. 한 도시의 VPS 하나는 하나의 장애 도메인입니다. 네트워크 피어링이 아무리 좋아도 실수로 볼륨을 삭제하는 상황을 막을 수는 없습니다.
• 과도하게 할당된 하드웨어. 네트워크 연결이 좋은 도시의 노드라도 부하가 높으면 성능 저하가 발생합니다.

사용자가 여러 대륙에 분산되어 있는 경우

규칙은 간단합니다. 사용자와 가장 가까운 거점에 서버를 배치하십시오. 사용자가 여러 대륙에 나뉘어 있다면, 중간 지점에 서버를 두는 것은 양쪽 그룹 모두에게 느린 경험을 제공할 뿐입니다. 어느 쪽도 서버와 가깝지 않기 때문입니다.

실질적인 해결책은 두 가지입니다. 캐시 가능한 모든 콘텐츠는 CDN(content delivery network) 뒤에 배치하십시오. 이렇게 하면 원본 서버는 Amsterdam에 유지하면서 이미지, 스타일시트, 스크립트, 캐시된 페이지는 각 사용자와 가까운 노드에서 제공할 수 있습니다. 또는 다른 지역에 두 번째 서버를 운영하고 데이터 문제를 의도적으로 해결하십시오. 읽기 전용 복제본을 사용하거나, 지연 시간을 측정하고 기록해 둔 복제 방식을 활용해야 합니다. 두 방법 모두 서버 한 대를 운영하는 것보다 비용이 많이 듭니다. 이것이 분산된 사용자를 대상으로 서비스를 운영할 때 치러야 할 정직한 대가입니다.

트래픽의 상당 부분이 북미 지역에서 발생한다면, Toronto에 위치한 VPS가 유럽의 어떤 도시보다 해당 사용자들에게 더 나은 서비스를 제공할 것입니다. 남미 사용자의 경우 Brazil에서 호스팅되는 VPS를 사용하면 모든 요청마다 대서양을 횡단하는 왕복 시간을 피할 수 있습니다. Amsterdam을 선택하는 것은 사용자가 유럽, 그중에서도 주로 북부와 서부에 있을 때 적합합니다. 이는 구체적인 주장이며, 위에 제시된 명령어들은 자신의 트래픽을 기준으로 이를 확인하는 방법입니다.

FAQ

암스테르담의 VPS가 프랑크푸르트의 VPS보다 더 빠른가요?

사용자 위치에 따라 다를 수 있습니다. 두 도시 모두 주요 상호 연결 지점이므로, 속도 차이는 도시 이름이 아니라 사용자의 위치와 각 제공업체가 어떤 네트워크와 피어링을 맺고 있는지에 따라 결정됩니다. 암스테르담은 영국, 아일랜드, 스칸디나비아, 베네룩스 지역에 적합한 경향이 있으며, 프랑크푸르트는 중부 및 동부 유럽에 적합한 경향이 있습니다. 결정하기 전에 각 지역에서 가장 작은 월간 플랜을 임대하여 mtr --report --aslookup를 실행하고, 실제 사용자 연결을 통해 일주일 동안 curl -w 타이밍 테스트를 수행해 보십시오.

암스테르담에 호스팅하면 서비스가 GDPR을 준수하게 되나요?

아닙니다. 데이터를 EU 인프라에 두는 것은 준수 사항 중 한 가지 질문에 답하는 것일 뿐입니다. 규정 준수는 법적 근거, 처리자, 백업, 로그, 그리고 개인정보를 전송하는 모든 제3자 서비스를 포함합니다. 암스테르담에 있는 서버라도 오류 추적 정보를 EEA 외부의 공급업체로 전송한다면 해당 데이터는 외부로 반출된 것입니다. 서버 위치는 가장 쉬운 부분이며, 많은 사람이 이 단계에서 멈춥니다.

AMS-IX란 무엇이며 제 VPS에 영향을 미치나요?

AMS-IX는 암스테르담 인터넷 교환소(Amsterdam Internet Exchange)로, 독립적인 네트워크들이 서로 직접 연결하여 트래픽을 주고받는 공유 스위칭 패브릭입니다. 이를 통해 네트워크들은 중간 전송 제공업체에 비용을 지불하지 않고도 데이터를 교환할 수 있습니다. 이 교환소는 귀하의 제공업체를 통해서만 VPS에 영향을 미칩니다. 해당 도시에 있는 교환소는 귀하의 제공업체가 그곳에 참여하고 있으며, 귀하의 사용자가 사용하는 네트워크와 피어링을 맺고 있을 때 도움이 됩니다. 제공업체의 AS 번호를 문의한 뒤 PeeringDB에서 해당 번호가 어디와 피어링되어 있는지 확인하십시오.

1년 치를 결제하기 전에 VPS 네트워크를 어떻게 테스트하나요?

먼저 가장 작은 월간 플랜을 구매하십시오. 왕복 시간과 패킷 손실을 확인하기 위해 ping -c 20을 실행하고, 경로가 거치는 네트워크를 확인하기 위해 mtr --report --report-wide --aslookup --report-cycles 100를 실행하십시오. 그다음 실제 HTTPS 페이지를 대상으로 curl -w을 실행하여 물리적 거리와 서버 속도를 구분하십시오. 네트워크 혼잡도는 시간대별로 다르므로 다양한 시간대에 테스트를 반복하고, 사무실뿐만 아니라 실제 사용자가 사용하는 연결 환경에서 테스트를 수행하십시오. 기록된 수치를 비교할 수 있도록 로그를 보관하십시오.