9월 22일 아침, torun.ai는 거의 기어가다시피 했습니다. 자동화된 브라우저 무리가 45분 동안 2,000개가 넘는 주소에서 공개 페이지를 하나씩 요청했고, 가장 나빴던 1분 동안은 초당 약 세 페이지였습니다. 웹사이트라면 대수롭지 않게 넘겨야 할 양입니다. 저희 사이트는 그러지 못했습니다. 가장 붐빈 구간에서 요청의 4분의 1 이상이 30초를 넘겼고, 수백 명의 방문객이 페이지가 뜨기 전에 떠났습니다.
생각했던 부하가 아니었습니다
뻔한 용의자는 크롤러와 프로세서였지만 둘 다 아니었습니다. 같은 초당 세 페이지를 사이트 사본에 재현하자, 1분도 버티지 못하고 그 뒤로는 아무것도 완료하지 못했습니다. 프로세서 사용률은 60%에서 1%로 떨어졌고, 스레드 수는 12에서 166으로 늘었습니다. 과부하 서버는 더 바쁘게 일합니다. 이 서버는 기다리고 있었습니다.
단어마다 한 번씩 오가는 요청
한 페이지를 만드는 동안 캐시 서버를 지켜보니 무엇을 기다리는지 보였습니다. 한 페이지가 캐시 서버에 명령 585개를 보냈고, 그중 428개는 같은 조회와 그 갱신의 반복이었습니다. 저희 사이트에서는 비어 있는 번역 테이블이었습니다. 페이지의 번역된 텍스트 하나하나가, 한 페이지에 수백 개가 있는데, 그것을 다시 요청했고, 요청마다 답이 돌아올 때까지 스레드 하나를 붙잡고 있었습니다. 초당 세 페이지에서 스레드가 바닥났고, 모든 것이 그 뒤에 줄을 섰습니다.
수정, 그리고 상한
이제 이 조회들은 1분씩 메모리에서 답하고, 만료될 때 한 번만 다시 가져오며, 번역을 바꾼 서버에서 지워집니다. 같은 페이지가 이제 명령을 585개가 아니라 31개 보냅니다. 페이지 생성 앞에는 상한도 두었습니다. 동시에 만드는 페이지 수는 정해져 있고, 짧은 대기열이 기다리며, 그 이상은 모든 페이지를 느리게 하는 대신 곧바로 ‘잠시 후 다시 시도해 주세요’를 받습니다.
운영 환경에서 측정
9월 23일 릴리스 후 운영 중인 사이트를 다시 측정했습니다. 페이지 생성의 중앙값은 249밀리초에서 42밀리초로, 스무 개 중 가장 느린 것은 거의 2초에서 72밀리초로 줄었습니다. 페이지당 214번 실행되던 조회는 이제 한 번 실행됩니다.
저희가 적어 둔 교훈은 단순합니다. 처리 용량 수치는 믿음이 아니라 측정입니다. 공개 사이트가 얼마나 버티는지 한 번도 시험해 본 적이 없었습니다. 이제는 해 봤고, 수치를 말하기 전에 다시 시험할 것입니다.