시스템을 옮기고 나서 전보다 느려졌다는 말을 들었는데 전이 얼마였는지를 몰랐다. 측정한 적이 없었고 옮기는 데 급해서 옮기는 것만 했기 때문이다.
Table of contents
Open Table of contents
조치 — 옮기기 전에 재는 다섯
다음 이관부터는 옮기기 전에 다섯 가지를 쟀다. 주요 화면의 p50 과 p95 응답 시간과 시간당 요청 수와 CPU 와 메모리 사용률과 시간당 오류 수와 주요 테이블 건수다.
재는 데 한 시간이면 됐고 baseline.sh 로 만들어 두니 옮긴 뒤에 같은 것을 돌려 비교할 수 있었다. 측정 기간은 두 가지 방법이 있었는데 옮기기 전날 하루치를 재는 것과 일주일치를 시간대별로 나눠 남기는 것이다. 뒤쪽을 골랐다. 이유는 한 번만 재면 그날이 특이한 날일 수 있어서다. 대신 이관 일정을 일주일 뒤로 미루는 것을 감수했고 비교할 때 같은 시간대끼리 봤다.
배경 — 설정과 자료의 스냅숏
설정도 함께 덤프해 남겼는데 php -v 와 memory_limit 과 max_execution_time 과 innodb_buffer_pool_size 같은 것들이다. 옮긴 뒤 값이 다르면 그것이 원인일 수 있다.
실제로 한 번 찾았는데 새 서버의 innodb_buffer_pool_size 가 기본값이었고 옛 값을 알고 있어서 바로 맞췄다. 자료는 건수만이 아니라 SUM 과 MAX(id) 와 MIN(created_at) 및 MAX(created_at) 도 남겼는데 건수가 같아도 내용이 다를 수 있기 때문이다.
검증 — 무엇이 돌고 있었는지
crontab -l 과 systemctl list-units 와 ss -tlnp 도 덤프해 뒀다. 옮긴 뒤 안 도는 것이 있는지를 대조하기 위해서다.
배치 하나가 안 옮겨진 것을 이것으로 찾았는데 월 1회 도는 것이라 안 돌아도 한 달간 몰랐을 것이다. 목록이 없었으면 그 배치의 존재 자체를 잊었을 것이다.
원인 — 옮긴 뒤의 비교
옮긴 뒤 같은 스크립트를 돌려 비교하니 p50 은 조금 늘고 p95 는 줄었으며 오류와 자원 사용률은 함께 내려갔다. 대부분이 조금 느려지고 느리던 것이 빨라진 형태였다.
숫자가 있으니 느려졌다는 말에 정확히 답할 수 있었다. 기록을 baseline/ 폴더에 모아 두니 다음 이관에서 그 구조를 그대로 썼다.
주의 — 되돌릴 때 쓰인 기록
한 번은 옮기고 나서 큰 문제가 생겨 되돌려야 했다. 되돌리면서 옛 설정을 맞춰야 하는데 그 사이 며칠 동안 옛 서버 설정을 여기저기 바꿔 놓은 상태였다.
옮기면서 옛 서버 자원을 줄여 놓았던 것이라 되돌리려면 다시 올려야 했고 기록이 있어서 원래 값을 알 수 있었다. 옮기기 전 기록은 옮긴 뒤 비교용만이 아니라 되돌릴 때 원래 값을 아는 근거로도 쓰였다.
정리
- 옮긴 뒤 문제가 나면 전 상태와 비교해야 한다
- 옮기기 전에 응답 시간과 처리량과 자원과 오류와 건수를 잰다
- 한 번이 아니라 일주일치를 재고 시간대별로 남긴다
- 설정도 남겨야 값이 다를 때 원인으로 확인할 수 있다
- 건수만이 아니라 합계와 최대 최소도 남긴다
- 예약 작업과 서비스와 포트 목록을 남긴다
- 옮긴 뒤 같은 것을 재서 비교한다
- 그 기록이 되돌릴 때 원래 값의 근거가 된다