중국 성능 측정에서 우리가 틀린 여덟 가지 — 그리고 그중 일곱 가지가 우리에게 유리하게 작용한 이유

우리는 중국 전송 인프라를 구축하고 운영하므로, 남의 측정이 아니라 우리 자신의 측정이 필요했습니다. 상하이에 헤드리스 브라우저를 세우는 데는 한나절이면 충분했습니다. 하지만 우리가 발표할 만한 숫자를 얻는 데는 훨씬 더 오래 걸렸습니다 — 성능 측정이 네트워크에 대해 전제하는 대부분이 중국 국경에서 더 이상 참이 아니게 되기 때문이며, 그것도 뻔한 방식으로가 아니기 때문입니다. 지연 시간이 높아지리라는 것은 누구나 예상합니다. 하지만 자기 도구 밑에 깔린 실패 산수가 조용히 작동을 멈춘다는 것은 거의 아무도 예상하지 못합니다.

이것은 무엇이 잘못되었는지의 목록입니다. 우리는 수정이 아니라 실패를 발표하는데, 그 이유는 마지막에 다시 다루겠습니다.

전체 모양을 먼저 볼 수 있도록 목록 전체를 먼저 제시합니다. 오른쪽 열이 핵심입니다: 이 오류들 거의 전부가 결과를 우리가 선호했을 방향으로 밀었습니다.

#	우리가 틀린 것	오류가 결과를 어느 쪽으로 밀었나
1	브라우저가 취소한 요청을 네트워크 실패로 집계	우리에게 불리
2	아예 응답되지 않은 요청을 집계하지 않음	우리에게 유리
3	오류들이 서로 독립이라고 가정	우리에게 유리
4	컨테이너가 오류 페이지를 계속 서빙하게 둔 배포	우리에게 유리
5	데이터센터 위치를 IP 지오로케이션으로 신뢰	중립이지만 신뢰도에 치명적
6	프로브를 한쪽 엔드포인트와 같은 네트워크에 둠	우리에게 유리
7	”도달 가능”을 “사용 가능”과 같은 것으로 취급	우리에게 유리
8	단일 샘플로 결론을 도출	예측 불가

1. 취소된 요청은 실패한 요청이 아니다

무슨 일이 있었나. 우리 리소스 집계는 브라우저가 완료하지 않은 모든 요청을 실패로 셌습니다. 처음 측정한 사이트 중 하나는 0.4초 만에 완전한 페이지를 반환했는데 — 리소스 손실률은 100%였습니다.

왜 틀렸나. net::ERR_ABORTED는 브라우저가 요청을 취소했다는 뜻입니다: 내비게이션이 페이지를 교체했거나, 프리로드가 쓰이지 않았거나, 리다이렉트가 발생한 것입니다. 이는 네트워크 이벤트가 전혀 아닙니다. 브라우저 보안 정책인 ERR_BLOCKED_BY_ORB도 마찬가지입니다. 이들을 실제 네트워크 실패와 뭉뚱그리면 발표하는 모든 손실 수치가 부풀려집니다.

왜 놓치기 쉬운가. 아무것도 오류를 내지 않습니다. 숫자가 나오고, 그 숫자가 중국치고는 그럴듯하며, 확증 편향이 나머지를 합니다. 우리가 이를 잡아낸 것은 0.4초와 100% 손실이 둘 다 참일 수는 없기 때문이었습니다.

어느 쪽으로 틀리나. 우리에게 불리 — 이 오류는 인터넷을 실제보다 나빠 보이게 했습니다. 여덟 가지 중 그렇게 한 것은 이것뿐입니다.

2. 방화벽은 대개 패킷을 떨어뜨린다. 거절하지 않는다.

무슨 일이 있었나. (1)을 고친 뒤, 도달 불가능한 제3자 호스트의 집계가 0으로 나왔습니다 — 같은 페이지 로드에서 임베드된 동영상과 폼의 인증 위젯이 둘 다 실패하고 있었는데도 말입니다.

왜 틀렸나. 차단된 요청은 흔히 아무 이벤트도 내지 않습니다. 연결 리셋도, 타임아웃 오류도, loadingFailed도 없습니다. 요청은 그저 보내지고 영영 응답되지 않습니다. 오류 이벤트를 세는 것 — 브라우저 개발자 도구의 실패 카운터를 포함해 — 은 무엇이든 아무것도 차단되지 않았다고 보고할 것입니다.

왜 놓치기 쉬운가. 이것은 중국을 측정하는 것과 다른 어디를 측정하는 것 사이의 가장 중요한 차이이며, 시끄럽게 실패하는 네트워크만 측정해 봤다면 보이지 않습니다. 보통의 네트워크에서는, 응답하지 못하는 호스트가 그렇다고 말해 줍니다.

어느 쪽으로 틀리나. 우리에게 유리 — 최적화되지 않은 기준선을 실제보다 훨씬 건강해 보이게 합니다.

3. (1)을 고친 것이 (2)를 드러나게 했다

이것들은 체크리스트 위의 서로 독립된 여덟 항목이 아닙니다. 오류 분류를 바로잡은 것이 바로 조용한-실패 문제를 수면 위로 드러냈습니다. 취소된 요청의 잡음이 제거되기 전까지는, 그 0이 빤히 보이는 곳에 숨어 있었기 때문입니다.

이 패턴은 반복되었습니다. 아래 오류 중 몇 개는 앞의 오류가 고쳐진 뒤에야 비로소 드러났고, 그중 하나는 다른 하나를 적극적으로 감춥니다. 그것이 이 작업의 실제 모양입니다: 한나절에 처리할 수 있는 함정 목록이 아니라, 발견하는 순서가 대체로 운에 달린, 서로 맞물린 실패 양상의 집합입니다.

4. 삭제된 디렉터리가 계속 서빙하고 있었다

무슨 일이 있었나. 재배포가 아름다운 결과를 냈습니다: 세 전송 경로 중 두 개가 갑자기 약 200밀리초에 로딩을 완료했고, 세 번째는 여전히 타임아웃이 났습니다.

왜 틀렸나. 그것들은 153바이트짜리 오류 페이지를 서빙하고 있었습니다. 배포 스크립트가 실행 중인 컨테이너가 마운트해 둔 디렉터리를 삭제하고 다시 만들었고, 컨테이너는 삭제된 원본을 계속 가리키며 아무것도 서빙하지 않았습니다. 그 200밀리초짜리 “페이지 로드”는 오류 문서였습니다.

왜 놓치기 쉬운가. 측정은 성공적으로 완료되었습니다. 우리가 확인하던 계층에서 상태 코드는 멀쩡했습니다. 그것은 우리가 바라던 바로 그 결과를 냈는데, 바로 그럴 때 가장 의심해야 합니다. 우리가 잡아낸 것은 임베드 동영상이 담긴 페이지가 200밀리초에 로드될 수는 — 어디서도, 결코 — 없기 때문이었습니다.

어느 쪽으로 틀리나. 우리에게 유리, 그것도 극적으로. 이것은 발표된 거짓말이 될 뻔했습니다.

5. IP 지오로케이션은 데이터센터가 있는 곳이 아니다

무슨 일이 있었나. 서로 독립된 세 IP 지오로케이션 서비스가 우리 프로브 대상이 베이징에 있다는 데 일치했습니다. 클라우드 제공자 자신의 인스턴스 메타데이터는 그것이 장자커우 — 약 200km 떨어진, 다른 성에 속한 다른 도시 — 에 있다고 했습니다.

왜 중요한가. 발표하는 모든 수치는 그 측정 위치를 담고 있습니다. “베이징에서 측정”은 사실 주장이며, 독자가 이를 권위 있는 출처와 대조해 틀렸다면, 그 밖에 쓴 모든 것도 이제 의심스러워집니다.

어느 쪽으로 틀리나. 중립이지만 신뢰도에 치명적.

6. 어디서 측정하느냐가 승자를 정한다

무슨 일이 있었나. 우리는 니어쇼어 전송 경로를 국내 경로와 비교했습니다. 중립적인 제3자 네트워크에서 측정했을 때, 국내 경로는 첫 바이트까지의 시간에서 1.19배 더 빨랐습니다. 국내 대상과 같은 클라우드 제공자에 올라앉은 프로브에서 측정했을 때, 같은 비교가 2.82배로 나왔습니다.

왜 틀렸나. 한 제공자의 네트워크상 두 머신 사이의 트래픽은 그 제공자의 내부 백본을 타며, 실제 사용자가 지나는 공용 중국 인터넷에는 결코 닿지 않습니다. 우리 비교의 두 엔드포인트가 마침 같은 제공자에 있었기에, 그 제공자 위의 프로브는 한쪽에 홈그라운드 이점을 주고 동시에 다른 쪽에 불이익을 주었습니다.

왜 놓치기 쉬운가. 프로브에는 잘못된 구석이 전혀 없어 보입니다. 올바른 나라에, 실제 네트워크 위에 있고, 안정된 숫자를 냅니다. 왜곡은 전적으로 라우팅 안에 삽니다.

어느 쪽으로 틀리나. 우리에게 유리 — 우리 자신의 대표 차별점을 두 배 넘게 부풀렸습니다.

7. “도달 가능”과 “빠르다”는 다른 질문이다

무슨 일이 있었나. 우리는 여러 제3자 호스트가 중국 내부에서 도달 가능한지를, 그것들에 요청을 보내 상태 코드를 확인하는 식으로 테스트했습니다. 몇몇은 약 100밀리초 만에 돌아왔고 우리는 그것들을 사용 가능으로 기록했습니다.

왜 틀렸나. 그것들은 아주 작은 응답이었습니다. 같은 호스트 중 하나에서 실제 에셋을 요청했을 때, 그것은 14.9 KB/s로 도착했습니다 — 도달성 점검이 시사한 것보다 대략 세 자릿수 낮은 처리량 수치입니다. 호스트는 응답합니다. 다만 전송하지 못할 뿐입니다.

왜 놓치기 쉬운가. 우리 것을 포함한 모든 도달성 도구는 이진값을 보고합니다. 그 이진값은 옳았습니다. 그리고 동시에 쓸모없었습니다.

어느 쪽으로 틀리나. 우리에게 유리 — 최적화되지 않은 경로가, 실은 그렇지 않은데, 작동하는 것처럼 보입니다.

8. 단 한 번의 측정은 측정이 아니다

무슨 일이 있었나. 우리는 같은 에셋을 같은 경로로 10분 간격을 두고 두 번 측정했습니다. 첫 샘플: 첫 바이트까지 449ms, 5.5 MB/s. 두 번째 샘플: 첫 바이트까지 3,135ms, 43 KB/s. 같은 파일, 같은 경로, 같은 프로브, 같은 오후였습니다.

왜 틀렸나. 중국의 국경 간 처리량은 하루 사이에 두 자릿수 배 이상 요동칩니다. 실무자들은 저녁이 악화되는 때라고 말할 것입니다 — 간헐적으로 도달 가능하다가, 느려집니다. 단일 샘플 숫자는 그것이 측정된 순간의 산물일 뿐이며, 일 평균을 보고하는 것은 그곳에서 사이트를 운영하는 누구에게나 가장 중요한 바로 그 패턴을 지워 버립니다.

어느 쪽으로 틀리나. 당신이 마침 어느 쪽에서 샘플링했든 그쪽으로. 그것이 문제입니다.

---

이 목록이 실제로 말하는 것

이 여덟 오류 중 일곱이 우리 자신의 전송 제품을 실제보다 좋아 보이게 했습니다. 우리가 그것들을 고친 이유는, 자신을 치켜세우는 측정은 측정이 아예 없는 것보다 가치가 덜하기 때문입니다 — “어떻게 측정했나?”라고 묻는 첫 번째 구매 담당 팀이 우리가 발견한 것을 발견할 것이고, 우리가 발표한 나머지 전부가 그와 함께 무너집니다.

하지만 수정이 아니라 목록을 발표하는 두 번째 이유가 있습니다.

이 중 어느 것도 이국적이지 않습니다. 하나하나는 같은 측정을 충분히 많이, 충분히 다양한 조건에서 돌리다 보면 모순이 드러나기 시작하며 발견하게 되는 종류입니다: 0.4초에 로드되면서 리소스의 100%를 잃는 페이지; 동영상이 재생되지 않는 페이지에서 차단된 호스트가 0인 상황; 임베드 동영상이 담긴 페이지의 200밀리초 로드. 오류들은 숫자가 어떤 모습이어야 하는지를 이미 알고 있어야만 스스로를 드러냅니다.

그 앎은 기법이 아닙니다. 그것은 반복해서 틀려 본 데서 남은 잔여물이며, 그래서 우리는 실패 양상을 정확히 기술할 수 있고, 그래서 첫 시도는 여전히 그 대부분을 — 다른 순서로 — 맞닥뜨릴 것입니다.

중국 내부에서 자기 사이트를 측정하고 있다면, 이 페이지에서 가장 유용한 단 하나는 항목 2입니다: 당신의 도구가 아예 응답되지 않은 요청을, 실패한 요청과 구분해 집계하는지 확인하라. 대부분의 도구는 그러지 않으며, 그 두 숫자의 차이가 대개 이야기의 전부입니다.

다음에 우리가 측정할 것

다섯 가지 제3자 리소스 범주를 가로질러, 직접 경로 대 우리 네트워크를 거친 경로를, 평균이 아니라 중국 현지 시간의 시간대별로 쪼갠 24시간 샘플링 실행입니다 — 특히 항목 8에서 기술한 저녁 악화를 특성화하기 위해서입니다. 그다음에는, 같은 기준 사이트를 데이터센터가 아니라 중국 사무실 광대역 회선에서 측정합니다. 데이터센터의 국제 회선은 실제 사용자가 가진 것보다 현저히 좋아서, 지금까지 우리가 발표한 모든 수치는 최악의 경우가 아니라 하한이기 때문입니다.

두 결과 모두 — 우리에게 유리하지 않은 부분까지 — 여기에 발표하겠습니다.

지금 당장 중국 본토 안에서 당신의 사이트가 어떻게 동작하는지 보고 싶다면, 우리의 중국 방화벽 테스트와 중국 속도 테스트는 모두 본토 안의 프로브에서 실행됩니다. 그리고 중국 내부에서 서빙되는 것 자체가 해법인지 궁금하다면, 그것도 측정해 보았습니다: 아닙니다.