웹사이트 튜닝

박제권

2008-04-05

요 며칠 ….

아쿠아 웹사이트를 튜닝했다.

점심시간 쯤에 시간당 페이지뷰가 10000~20000 정도 되는 사이트였는데, 이상하게 느렸다.

하고 있었다. 그래도, 느린 거였다.

이 정도로 접속이 많은 웹사이트를 까보기는 처음이니까, 이게 맞는 걸까, 하드웨어를 더 늘려야 하는 걸까, 잘 모르는 일이었다.

호스팅회사에 자문을 구했더니, 그쪽에서는

그래서….

소스는 php, 구조적이지 않은, 역사가 쌓이고 쌓인 소스더미들이었다. 안쓰는 소스가 태반이겠지만, 함부로 지울수는 없었다. 그저 grep, grep.

이상하게 한시간 단위로 슬로우쿼리(10초이상)들이 증가했는데, 혹시나 해서 cron을 뒤져보니, 역시 거기에서 느릴만한 쿼리들을 만들고 있었다. 클라이언트와 협의해서 삭제해버렸다.

사이트에서 3번째로 많이 호출되는 페이지에는 10000개나 되는 레코드를 얻어와서 그중 18개만 표시하는 코드가 있었다. 이게 DB와 웹서버 사이에 트래픽을 증가시키는 주원인이었다.

거의 쓰지 않는 테이블에 계속해서 사용자 접속 기록을 적어두는 곳도 있었다. 이 부분은 daum의 웹로그 분석기로 대체했다. 내부적으로 awstat같은 것을 달아주는 것이 DB에 쌓는 것보다 좋을 것 같고…

데이터베이스 백업때문에 새벽 5시에 서비스가 완전히 멈추는 경우가 종종 있었는데, 쓸데없는 파일들을 지우고 나니 조금은 빨라졌다.

지금은….

결국. 웹서버 속도는 평균 20 배정도 빨라졌다. DB서버와 웹서버간 통신은 100Mbps 에서 36Mbps 로 줄어들었다.

고치지 못한 문제중에는 루프돌면서 쿼리를 던지는 페이지도 있는데, 건드리지 않고 넘어가기로 했다. 모두 다하고 싶지만 기간이 너무 늘어질 것 같았다.

남은 문제는…

새벽에 백업할 때만이라도 로드밸런서가 백업중인 기계를 안건드리면 좋을 텐데, 전체적으로 데몬들 버전이 낮아서인지 잘 처리되지 않고 있다.

루프돌면서 쿼리던지는 코드를 그냥 두면… 아마 나중에 발목을 잡겠지만, 어쨌든 올여름은 날 수 있겠지.

교훈은…

내부구조를 개선하지 않고 기능추가만 계속 하다보면 생기는 현상들이다. 위에 나온 문제들 중에 기술적으로 아주 어려운 문제는 없었다. (뭐.. 웹사이트 코딩이 어려워봐야.. 양이 많은 게 문제지..) 어쨌든, 자주 때를 벗겨야 한다. 안그러면.. 때가 낀다.. ㅜㅜ

기능을 추가하면, 개발자만 힘든 것이 아니다. 한번 비용을 받으면 그것으로 개발자는 끝이다. 하지만… 클라이언트로써는 그후에 유지보수비용이 지속적으로 증가한다. 꼭 필요한 기능인지, 현재구조에 맞는 기능인지 개발자는 클라이언트에 정확하게 리포트 해야한다.

물론, 그런 리포트에 귀기울이는 클라이언트는 거의 없긴 하지만..

김석준 : 아.. 그 모모(?) 사이트 튜닝 시작하신 거군요. 튜닝 다 하시면 제게도 한번 노하우 좀 전수해 주세요. 벌써 다 하신건가?? _{(2008-04-05 09:27:53)}