본 내용은 현재의 상태와는 무관하게, 2005년 11월 경 KLDP 의 OS 를 Debian 에서 안녕 리눅스로 교체 하면서,
KLDP 관리자 업무를 시작하면서 겪은 사항들 입니다.
소프트웨어적인 tuning 기라고 볼 수도 있습니다.
2005년 11월 경 OS 교체시기 즈음해서 bot 들의 접근 (google ranky 를 높이기 위한 referrer 를 남기는 bot들) 이 많아지고, 때마침 rss feed 를 사용량이 늘어 나면서 kldp service 가 원할하지 못하게 돌아가는 상황이었습니다.
이 시기에 문제는 3가지가 있었습니다. 이 3가지의 처리 사항에 대해서 기록을 남겨 볼까 합니다.
1. phpBB 의 불합리한 검색 구조
phpBB 의 검색은 검색을 하면 search table 에 해당 resource 들 즉, 글 리스트에 대한 정보를 record 에 기록을 하게 됩니다. 그런데 문제는 검색을 할 때, session table 에서 리스트를 가져와서 session table 에 없는 record 들을 삭제를 하고 결과를 보여준다는 것에 문제가 있었습니다. 즉, bot 들의 접근이 많아지면서, session table 에 몇천개에서 몇만개의 record 가 쌓이게 되었는데, phpBB 의 검색 루틴은
DELETE FROM phpbb_search_results
WHERE session_id NOT IN ('da7d5512402628bc6691954af5128fb3',
'783185e8b1e575058b81bffd8ac54c84', ...);
와 같은 식을 IN 안에 몇천개 ~ 몇만개를 한꺼번에 넣어 버리는 불합리한 구조를 가지고 있었습니다. 그러다 보니, 위의 query 가 lock 이 걸리게 되고, 검색이 쌓이다 보면 mysql 이 memory 를 소진하고 swap 까지 다 사용하면서 모든 query 들이 lock 이 걸리는 문제를 발생 시키고 있었습니다.
그리하여, 이 delete 부분을 원 소스에서 comment 처리하고, 이 부분을 cronjob 으로 한꺼번에 IN() 을 하던 것을 하나씩 하게 처리하여 서버 로드및 리소스 사용률을 현저하게 낮추어 접속에 원할함을 제공할 수 있었습니다.
2. rss feed 의 환장하게 강력한 기능들..
KLDP 의 bbs 에서 제공하던 rss feed 는 phpBB 의 original 이 아닌 개량판이었습니다. 문제는 기능을 강화하다 보니, sql query 에서 join 이 남발하게 되었고, 이 feed 를 요청하는 query 가 많아짐에 따라, join 을 하다라 locking 이 되는 현상이 발생하여 mysql 응답 속도가 현저하게 느려지는 문제가 존재했습니다.
이를 해결하기 위하여, mysql 에서 join 을 요청마다 처리하기는 힘들기 때문에, 미리 backend 에서 join을 한 데이터를 sqlite 의 one table 에 넣어두고, feed 요청은 이 sqlite 를 통해서 index 를 탈수 있도록 변경하여 처리를 했습니다.
3. moniwiki 의 fulltext search 의 문제점
위의 2가지 문제가 동시에 발생하고 있어, 원인을 찾기가 어려웠었는데, KLDP 서버에서 여러가지 서비스를 하다 보니, moniwiki 에서도 하나의 문제점을 가지고 있었습니다.
위의 2가지 문제를 처리하고 나서, 계속 죽어나가던 서버들이 어느정도 복구가 되었지만, 그래도 resource 를 과다 사용하는 문제가 있었으며, apache process 1개의 size 가 100M 정도로 커지는 경우를 발견하게 되었습니다. 그래서 strace -p PID 로 열심히 지켜보던 중, wiki 의 fulltext search 에서 이러한 문제가 발생한다는 것을 찾게 되어, moniwki 관리자인 박원규님께 보고하여, 이 문제를 해결했던 부분이 있었습니다.
대략 2005년 하반기의 문제는 위의 3가지 문제가 동시에 원인이 되었고, 이 3가지 문제를 해결하면서 안정화를 이루어 내었었습니다.
이런 기록을 남기는 이유는, 대부분의 SE 들이 system (H/W) 과 O/S 레벨에서의 튜닝 (컴파일을 해야 하고, 정적으로 빌드해야 하고.. 등등) 에 강박관념을 가지고 있는 듯하여, 제 경험을 일부 내 놓아 봅니다. 실제 H/W 나 O/S 레벨의 튜닝보다 application 의 튜닝이 성능을 훨씬 높일 수 있다는 것을 체감할 수 있으며, SE 라고 해서 코드를 볼줄 모르면 도태될 수 밖에 없다는 것을 알려 주고 싶었습니다.
현재, 2006년 3월 현재, drupal 로의 개편이 이루어 지고 있습니다만, 역시 개편 초기의 모습은 상당이 안정적이지 않습니다. 하지만, 제가 어제 새벽에 짬을 내어 잠시 분석해 본 바로는, 엄청난 튜닝의 소지가 존재하고 있다는 것을 발견했습니다. 즉, drupal 이 검증을 받았을지 모르지만, 사용하는 많은 (그것도 널리 사용이 되는) 모듈들의 설계가 엄청나게 부실하다는 것을 발견 하였고.. (index 를 타지 못하게 설계된 table schema, join 을 남발하는 query 등등) 이 것들에 대한 대안을 만들 수 있도록 삽질(?) 을 할 수 있는 즐거움도 가질 수 있을 것 같군요.
모든 일은 재미(?)가 있어야 열심히 할 수 있습니다. 귀찮다고, 누가 알아줄까 하고, 왜 소득도 없는 닥질을 해야 하는지 하고 생각할지 모르겠지만, 이런 일들이 다들 일하시는데 훌륭한 밑천이 될 수 있다는 것을 느끼셨으면 합니다.
왠만한 분들은.. 아르바이트, 프리랜서 생활을 해 보셨을 것이고, 이 경력들을 인정 받지 못하신 적이 많으실 겁니다. 하지만, 이런 생활에서 얻은 노하우를 공개를 함으로서 해서 이 사람이 어느 정도의 능력을 가졌다는 것을 다른 사람들이 인식을 하게 되면, 이 경험들이 모두 경력으로 둔갑을 하게 됩니다.
하지만 가장 중요한 것은.. 위에서 언급을 했듯이 재미(?)를 가지고 해야지 버틸수가 있다는 겁니다.
only리눅스에 firefox 유저라 web developer toolbar는 잘 사용하고 있습니다만, tidy extension은 써보질 않았네요 
이유는 아직 파악중이지만 서버에 따라 희한한 동작을 보이는 경우가 있다고 하네요. 현재는 경우에 따라 소스의 그 부분을 수정하는 쪽을 권하고 있습니다. 태터 내부에 구현된 iconv를 이용해서 수동으로 파싱해 보는 것은 어떨까라는 생각도 해 보았습니다만, 속도가 걸려 다른 분들께 아직 이야기를 꺼내지는 못했습니다. (chester님의 목표는 태터 하나 설치한 후 mod_alias 전용 모드에서 10만명 이상 사용이 가능한 툴인것 같습니다 =_=)
Comments List
이번달에 하나 포스팅 하셔서 안하실줄 알았는데 못본사이 포스팅이 되어있었네요^^. 저만 음료수 먹어서 죄송했습니다. 드릴수도 없고 참~ 난감했습니다. 중간에 좀 사올걸 그랬습니다. ㅎㅎㅎ 얘기 듣다보니..