Robert Kisteleki가 RIPE Atlas 앵커를 VM에 넣었다. 랙은 멀쩡했다

Summary

• Kisteleki의 2017년 계획은 공용 클라우드와 지역 협력자가 제공하는 VM을 두 갈래 실험 대상으로 삼았다. 2018년 5월 진행 보고에는 초기 설치가 기록됐다.
• 7월 결과 보고는 서로 가까운 가상·물리 앵커의 분석된 자료에서 뚜렷한 성능 차이를 찾지 못했다. RIPE Labs의 비교 분석은 일주일의 측정값을 살폈고, RIPE NCC의 2019년 보고서는 가상 앵커가 Atlas의 범위를 넓혔다고 기록했다.

측정 지도의 점 하나는 작다. 그 점을 만들 장비를 보내고 설치하고 지킬 일은 훨씬 크다. Kisteleki는 2017년 제안에서 물리 장비를 들이기 어려운 네트워크를 바라봤다. 그곳에 VM을 놓으면 새로운 관측 위치를 얻을 수 있었다.

실험은 두 길로 나뉘었다. 하나는 공용 클라우드, 다른 하나는 자기 네트워크의 VM을 내놓는 협력자였다. 가상 앵커도 기존 앵커 메시 안에서 다른 앵커의 측정을 받고 스스로 측정한다. 별도 태그를 달아 연구자가 포함하거나 제외할 수도 있다. 화면에는 같은 점으로 보여도 클라우드와 현장 네트워크의 관측 위치는 서로 다르다.

2018년 5월에는 RIPE NCC 자체 VM과 Sander Steffann, Jared Mauch, Amazon의 설치 사례가 등장했다. DigitalOcean은 가까이 놓인 물리 앵커와 VM을 제공했다. Kisteleki의 7월 결산은 분석한 자료에서 알아볼 만한 성능 차이가 없다고 했다. Iñigo Ortiz de Urbina Cazenave, Michela Galante, Alun Davies의 기여도 함께 적었다. 자원한 호스트들이 실험 장소를 맡았다.

Stephen Strowes는 RIPE Atlas 측정 분석에서 약 300개의 다른 앵커가 만든 일주일치 자료를 들여다봤다. HTTP 응답의 중앙값 차이는 거의 없었고 ping에는 작은 차이가 있었다. IPv4와 IPv6, 네트워크 경로의 상태가 더 두드러진 경우도 있었다. 이 결과는 특정 두 장비와 일주일이라는 경계 안에서 쓸모 있었다.

이제 성능표 밖의 질문이 시작됐다. VM을 호스트가 준비할까, RIPE NCC가 필요한 곳에 직접 놓을까? 남의 네트워크에 둘 수 있을까? 저장과 처리 비용을 감당하며 몇 대를 받을까? 상자를 사지 않은 호스트도 몇 해 뒤 기꺼이 관리할까? Kisteleki는 먼저 호스트가 VM을 제공하는 부담이 작은 방식을 제안하고, 위치와 수량과 관리에 대한 의견을 구했다.

RIPE NCC의 2019년 연례 보고서는 가상 앵커가 Atlas의 관측 범위를 넓혔다고 적었다. 시험이 운영으로 이어졌다. 랙 공간은 아꼈지만, 돌볼 사람의 자리는 비워 둘 수 없었다.