사이트가 느려지면 가장 먼저 떠오르는 해결책이 요금제 상향입니다. 클릭 몇 번이면 되고, 무언가 했다는 느낌도 듭니다. 그런데 느림의 원인 상당수는 서버 용량이 아닙니다. 원인을 두고 용량만 늘리면 돈은 나가고 체감은 그대로입니다.
이 회차의 목적은 하나입니다 — 증설이 답인 상황과 아닌 상황을 구분하는 것. 구분만 되면 예산의 상당 부분이 절약됩니다.
증설로 해결되는 것과 안 되는 것
왼쪽 항목들이 흔한 이유는 단순합니다. 서버는 대개 놀고 있고, 시간을 잡아먹는 것은 파일 전송과 낭비되는 계산이기 때문입니다. 이 상태에서 CPU 와 메모리를 두 배로 늘리면, 놀던 서버가 더 크게 놀 뿐입니다.
진짜 신호는 이렇게 생겼습니다
증설이 필요한 상황은 “느리다” 가 아니라 구체적인 실패로 나타납니다. 다음 중 하나라도 반복된다면 그때는 용량이 부족한 것이 맞습니다.
용량 부족이 맞는 신호는 셋입니다. 접속이 몰릴 때 페이지가 아예 열리지 않는 것, 작업 중에 프로세스가 중단되어 화면이 하얗게 남는 것, 그리고 디스크 여유가 계속 줄어 경고가 뜨는 것. 셋 다 “조금 느리다” 가 아니라 “실패한다” 로 나타난다는 공통점이 있습니다.
반면 헷갈리기 쉬운 두 가지가 있습니다 — 방문자 수와 무관하게 관리자 화면만 느린 것과 한밤중처럼 방문자가 없는 시간대에도 응답이 흔들리는 것입니다. 이 둘은 다르게 읽습니다. 관리자 화면만 느린 것은 대체로 캐시가 듣지 않는 영역의 데이터베이스 문제이므로, 서버를 올리기 전에 불필요한 데이터부터 정리하는 편이 낫습니다. 방문자가 없는 시간대에도 흔들리는 것은 공유 환경의 이웃이나 예약 작업이 원인인 경우가 많습니다.
증설 전에 반드시 지나갈 세 칸
증설이 필요해 보여도, 아래 순서를 먼저 지나가면 필요 없어지는 경우가 많습니다. 그리고 지나가야 하는 더 중요한 이유가 있습니다 — 이 셋을 안 한 채 증설하면, 다음 성장 구간에서 같은 문제를 더 비싼 요금제에서 다시 만납니다.
순서에는 이유가 있습니다. 이미지 정리는 돈이 들지 않고 효과가 크며, 캐시는 같은 서버로 훨씬 많은 방문자를 받게 해 줍니다. 이 둘을 마친 뒤에도 위의 “진짜 신호” 가 남아 있다면, 그때의 증설은 확신을 갖고 하는 지출이 됩니다.
이미지와 자산 정리 순서는 적은 돈으로 속도를 가장 많이 얻는 자리에서 다뤘습니다. 성능 전반은 성능 최적화 아카이브에 있고, 무엇이 병목인지 측정부터 하고 싶다면 작업 과정에 우리가 실제로 어떤 순서로 재고 고치는지 공개돼 있습니다.
다음 회차
연재의 마지막 회차입니다. 지금까지 정한 것들이 시간이 지나면 낡습니다 — 반기마다 30분으로 그것을 되돌리는 점검 루틴을 다룹니다.