29장 빠르게 만드는 일은 기다림을 찾는 일

사용자는 검색 버튼을 누른 뒤 2초를 기다린다. 개발자는 데이터베이스 질의가 30밀리초라고 말하고 네트워크 담당자는 회선에 여유가 있다고 말한다. 둘 다 사실일 수 있다. 남은 시간에는 연결 풀 대기, 외부 API, 직렬로 실행되는 여러 호출, 큰 결과 전송, 브라우저의 화면 구성이 들어 있을 수 있다. 성능을 개선하려면 전체 시간의 영수증을 나누어 봐야 한다.

응답 시간에는 준비, 전송, 처리, 대기가 섞여 있다. 대역폭은 단위 시간에 얼마나 보낼 수 있는지와 관련되고 지연은 결과를 기다리는 시간과 관련된다. 넓은 회선은 큰 파일을 옮기는 데 도움이 되지만 왕복 지연 자체를 없애지는 않는다. 작은 요청을 멀리 있는 서버에 여러 번 순서대로 보내면 대역폭이 남아도 느릴 수 있다.

왕복을 줄이는 계산

각각 앞의 결과를 기다리는 네 번의 원격 호출이 있고 왕복 지연이 80밀리초라고 가정하자. 서버 처리와 전송량을 무시해도 네 번의 기다림은 약 320밀리초다. 독립적인 호출을 병렬화하거나 필요한 정보를 한 번에 받을 수 있다면 이 일부를 줄일 수 있다. 그러나 서로 의존하는 호출을 억지로 병렬화하면 결과의 정확성이 깨질 수 있다. 순서가 필요한 이유부터 확인한다.

큰 파일에서는 대역폭과 왕복 시간의 곱을 생각할 수 있다. 100 Mbps 경로와 80밀리초 왕복 시간을 단순 가정하면 곱은 8 Mb, 즉 약 1 MB다. 충분한 처리량을 내려면 확인을 기다리는 동안 그 정도의 데이터가 진행 중일 수 있어야 한다는 직관을 준다. 실제 속도는 혼잡 제어, 수신 윈도, 손실, 프로토콜 비용 등에도 영향을 받는다.

Illustrative bandwidth-delay product

Bandwidth = 100,000,000 bits / second
RTT       = 0.080 second
BDP       = 8,000,000 bits
          = 1,000,000 bytes

This is not a command to change every buffer to 1 MB.
Measure the actual path and the application first.

사용률이 끝에 가까워질 때

처리 능력에 여유가 있을 때는 요청이 곧바로 시작된다. 들어오는 일이 처리 가능한 양에 가까워지면 작은 변동에도 대기열이 길어질 수 있다. 평균 사용률이 100%가 되기 전부터 사용자 지연이 나빠질 수 있는 이유다. 자원을 끝까지 채우는 것이 언제나 효율적인 운영은 아니다. 빠른 응답을 유지하려면 변동을 흡수할 여유가 필요하다.

안정적인 조건에서 평균 진행 중 작업 수는 평균 도착률과 평균 체류 시간의 곱으로 연결된다. 초당 50건이 들어오고 시스템 안에 머무는 시간이 평균 0.2초라면 평균 10건이 진행 중인 셈이다. 이 관계는 관찰 범위와 단위를 맞춰야 의미가 있다. 큐에서 기다리는 시간까지 포함했는지, 외부에서 거절된 요청은 어떻게 셌는지 확인한다.

더 많이 처리하려다 더 느려지는 경우

작업자 수를 늘리면 동시에 시작할 수 있는 일은 늘어난다. 하지만 공통 데이터베이스가 병목이면 더 많은 작업자가 같은 자원을 기다리며 메모리와 연결을 차지한다. 적절한 동시성 제한과 대기열, 빠른 거절이 전체 성공률을 높일 수 있다. 모든 요청을 끝없이 받아 두는 것은 친절한 정책이 아니다. 사용자는 결국 더 오래 기다린 뒤 실패할 수 있다.

업로드가 회선을 채울 때 다른 요청의 반응이 느려지는 현상에는 대기열이 관련될 수 있다. 큰 버퍼는 순간적인 변동을 흡수하지만 과도한 큐는 지연을 늘린다. 회선 속도 숫자만 올리기 전에 부하 중 지연과 업로드 사용량을 측정한다. 장비의 큐 관리 기능을 검토할 때도 현재 모델과 펌웨어의 문서를 확인해야 한다.

벤치마크의 질문을 먼저 쓴다

시험을 시작하기 전에 무엇을 비교할지 적자. 같은 하드웨어에서 압축 전후의 파일 크기와 CPU 비용을 비교하는지, 같은 요청량에서 새 질의의 응답 분포를 비교하는지에 따라 방법이 달라진다. 입력 데이터와 캐시 상태, 동시성, 워밍업, 시험 시간을 기록한다. 가장 좋은 결과만 골라 발표하면 실제 운영의 나쁜 순간을 감출 수 있다.

부하 시험은 허가된 환경에서 제한을 정하고 수행한다. 공개 사이트나 운영 서비스에 임의로 많은 요청을 보내지 않는다. 시험 발생기 자체가 병목이 되거나 외부 유료 API 호출이 늘 수 있으므로 의존성과 비용도 확인한다. 작은 부하에서 시작하고 중단 조건을 마련한다. 성능을 알아보려다 다른 사람의 서비스를 방해해서는 안 된다.

최적화가 성공했는지는 사용자에게 필요한 결과와 자원 비용으로 판단한다. 코드가 더 짧아졌거나 새로운 캐시를 도입했다는 사실은 성능 지표가 아니다. 같은 조건에서 지연이 줄었는지, 실패가 늘지 않았는지, 유지 비용이 감당 가능한지 확인한다. 잘되지 않은 실험도 기록할 가치가 있다. 다음 사람이 같은 가설을 다시 시험하는 시간을 줄일 수 있다.