지금 하루 평균 9천명 정도 오는 사이트를 XE로 운영하고 있습니다. 사이트 규모가 작다고는 말 못하는데 엄청 큰것도 아닌 좀 어중간한 크기입니다. 사이트 특성상 교체되는 그림 파일의 용량이 많고-대충 50기가-, DB에 쌓이는 글의 양도 많아서-대충 1기가- 쿼드코어 CPU로 돌아가는 서버 호스팅을 받고 있습니다.

 

그런데 순전히 XE 때문에, 쿼드코어 CPU 서버가 못 받쳐줘서 사이트 접속 장애가 일어난 일이 3번 있었습니다. 그 서버에 올려진게 단순히 제 사이트 한개밖에 없는데도 말이지요. 지극히 개인적인 경험이긴 하지만, XE를 쓰시는 분들과 같이 공유하여, 저처럼 삽질하시는 분을 단 한명이라도 줄일 수 있다면, 이렇게 글을 두드린 시간이 아깝지 않을듯 합니다.

 

여기서 소개하는 사례는 규모가 작은 사이트라면 해당 사항이 별로 없겠지만, 그 경우에는 대부분 웹 호스팅을 사용중이실테니, 호스팅 회사에서 '니네 사이트 때문에 서버 부하가 많아 다른 사이트에도 영향을 주니 사이트를 내려버리겠다' 이런 말을 들으실 가능성도 있습니다. 그러니 참고해 두셔도 나쁘지 않을 것입니다.

 

저는 컴퓨터는 어중간하게 알지만 서버 운영이나 그런건 꽝이고, PHP나 MYSQL 같은 것도 모릅니다. 그러니까 그렇게 고생을 했겠지요. 잘 아시는 분들은 이런거 안 읽으셔도 되겠고, 저처럼 이쪽에 익숙하지 않으신 분들을 위해 설명하려고 합니다.

 

 

1. 위젯

 

어느날 밤이었습니다. 사이트 특성상 밤 10시부터 2시까지가 사람들이 제일 많이 몰리는데, 사이트가 엄청나게 느려진 것입니다. 서버에 ssh로 원격 접속해서 top 명령어로 프로세스 상황을 찍어보니 mysqld, MYSQL 데이터베이스 데몬의 점유율이 미친듯이 폭주하여 전체 CPU 점유율이 99%를 찍고 있습니다? 이러니 안 느려지면 더 이상하겠지요.

 

mysqld니까 문제는 무조건 데이터베이스 쪽인데, 딱히 데이터베이스에 뭔가를 한 적도 없고, 새로운 기능을 추가한 적도 없었습니다. 그런게 갑자기 널뛰기를 하고 있으니 돌아버릴 지경이었지요. MYSQL을 껐다가 재시작해도 소용이 없고, 서버를 내렸다가 다시 켜도 소용이 없고, 결국 딱히 해결을 하지 못하고 천천히 사그라 들었습니다만, 다음날도, 그 다음날도, 이 증상은 계속 되었습니다.

 

여기저기 찾아보니 데이터베이스가 문제가 생기면 슬로우 퀴리가 쌓이고, 이 로그를 찾아보면 문제를 해결할 수 있다는군요. 어떻게 삽질해서 문제가 발생했을 당시의 로그를 뽑아보니, 전부 xe_comment로 도배가 되어 있습니다. 그러니까, 코멘트를 뽑아오는 데에 문제가 있었다는 말이지요.

 

일반 문서에 딸린 코멘트 출력이 문제를 일으켰을까요? 그렇진 않겠지요. 일반 문서가 아닌 다른 곳에서 코멘트를 뽑아 오는 곳이 단 한 부분 있었으니, 그것은 바로 사이트 레이아웃 오른쪽에 표시되는 위젯중에 '최근 댓글 출력'이었습니다. 이 최근 댓글 출력의 캐시를 0분(실시간)에서 1분으로 바꿔보니 언제 말썽이 생겼느냐는 듯이 바로 잠잠해지더군요. 너무 허탈했었습니다.

 

결론은 사이트 규모가 좀 된다 싶으시면 모든 위젯의 캐시를 1분으로 설정해 놓으세요. 레이아웃, 메인 페이지. 전부 다요. 단, 가가라이브 채팅 위젯은 제외입니다. 이걸 캐시 1분으로 설정해 뒀더니 캐시가 생성될때 로그인한 사람의 정보가 1분동안 계속 남더군요. ...제가 캐시 생성될때 로그인했더니, 챗방에 접속한 사람이 전부 관리자가 되는 무서운 상황이 발생했었습니다.

 

XE가 제로보드 4보다 무겁다는 소리가 나올만한 이유가... XE로 건너오기 전에 썼었던 제로보드 4에서는 똑같이 최근 댓글을 실시간으로 뽑아 오도록 했었지만 이런 부하가 걸리지 않았었기 때문입니다. DB의 구조 때문이려나요.

 

 

2. 애드온

 

2번은 사소한 실수 같은 것이겠지만. 사이트를 잘 쓰다가 버전업을 한 후에 아파치 웹서버의 점유율이 미친듯 올라가 99%를 찍었던 적이 있었습니다. 1번에서 있었던 일 때문에 DB 서버 점유율이 폭주하는 것이 아니라는 점에 안도하고, 원인을 찾아 보았는데 이것도 쉽게 찾아지진 않더군요.

 

결국 찾아낸 것은 어떤 애드온이었습니다. 사이트에 적용된 애드온을 하나씩 꺼보니까 어떤 한 애드온을 끄자마자 바로 서버 점유율이 평탄하게 변하더군요. 켜니까 다시 올라가고. 지금은 이 애드온 제작자 분께서 해당 문제가 수정된 새 버전을 출시하였으니 전혀 문제될 것은 없습니다.

 

결론은 애드온을 꼭 필요한 것만 사용하시고, XE 코어 버전업이나 새로운 애드온을 깔았을때 사이트에 문제가 생기면 바로 애드온을 으리심해 보시라는 것입니다. 비단 애드온에 국한되는 것이 아니라, 모듈이나 위젯도 마찬가지겠지요.

 

 

3. 회원 그룹

 

가장 최근에 겪은 일입니다. XE에서 정말 오랬동안 해결되지 않았던 레벨-그룹 연동 버그가 드디어 해결되자마자, 저는 바로 그 기능을 적용시키기 위해 노가다를 좀 했습니다. 모든 회원들의 그룹을 일일이 '수동'으로 조정했던 것이지요. 한 6천명 정도 했나 -_-a 그래서 회원들을 잘게 그룹으로 나누고, 그룹에 따라 사용 가능한 게시판들도 전부 차등화 하였습니다. 소스를 좀 고쳐서 이미지마크나 이미지네임 같은 것도 특정 그룹에서만 가능하게 바꾸고요.

 

하지만 그 기능에는 여전히 문제가 존재하는데, 여기(http://xe.xpressengine.net/?document_srl=18260763)에 등록된 대로, "설정된 그룹 초기화 후 새 그룹 부여" 기능이 정상적으로 동작하지 않고, "새 그룹만 부여"만 되고 있다는 것입니다. 그러니까 회원이 렙업을 계속할 수록 그룹은 계속 쌓여가게 되지요. 사용하는 그룹이 한두개라면 모르겠지만 저는 상당히 많은 그룹으로 나눠 적용하고 있었습니다.

 

그러던 중에 일이 터졌습니다. 서버의 점유율은 CPU만 약간 높은 수준인데, 하드디스크 I/O 요구가 엄청나게 늘어나면서 서버가 엄청나게 느려지고, 대부분의 경우는 DB 에러를 뱉거나, 아예 페이지를 표시할 수 없습니다가 뜨던 것입니다. 하드디스크 I/O가 많은 것을 보고, 서버 하드디스크가 맛이 간 것으로 판단하고, 서버를 바꾸는 대출혈을 하였지만 어째 서버 이전 후에도 여전했습니다.

 

호스팅 업체에 연락해봐도 대단히 친절한 말투로(진짜 친절했습니다) 로그에서 보시다시피 슬로우 쿼리 때문이며 서버는 멀쩡하니 우리가 뭔가 더 해줄 수 있는건 없고, 개발자에게 문의해봐라. ...그렇게 따져보면 내가 개발잔데?

 

그제서야 하드웨어적인 문제가 아니라 소프트웨어적인 문제였음을 알고, 다시 로그를 살펴보니 이번에도 슬로우 쿼리. 데이터베이스의 로그를 보니 select a.title as `title`,a.group_srl as `group_srl` from `xe_member_group` as a,`xe_member_group_member` as b where로 도배가 되어 있었습니다. 설마 회원 그룹 때문에 생긴 일인가? 해서 그 몇날 몇일에 거쳐 일일이 수동 조정했던 그룹을 전부 싹 지우고 나니.

 

... 잘 되더라구요. 그룹 재지정을 전부 수동으로 하느라 날린 시간과 노력, 그리고 서버 이전에 들인 비용과 시간과 노력, 마지막으로 사이트가 불안정하여 회원들에게 정신적인 피해만 남긴 채로 말입니다.

 

결론은 회원 그룹을 너무 잘게 나누지 마시라는 것입니다. 회원 그룹을 많이 나눠 쓰실 거라면 새 버전에서 저 이슈가 해결될 때까지 참으세요.

 

 

이상입니다. 저 문제들 때문에 나름대로 엄청 고생했었지만, 그건 겪어본 사람이 아니라면 모를 일이지요. 부디 이 문제들 때문에 저처럼 고생하시는 분들이 다시는 없었으면 합니다.

 

 

----추가내용-----

 

4. 통합 검색

 

바로 위에 3번 현상으로 모든 문제가 해결되는줄 알았으나(왜냐하면 그룹 다 지우자 마자 바로 서버 점유율이 급락했으니). 불행히도 그게 아니었습니다. 바로 다음날 밤에 또 그러더군요 -_-

 

열받아서 슬로우 쿼리 또 찍어보니 여전합니다. 막 몇백씩 쌓이고 있어요. 최대 6천까지 찍어봤던가. 하여간 또 로그 보니 이번에는 당장 눈에 들어오는게 extra_vars였습니다.

select * from `xe_document_extra_vars` as extra_vars   where (extra_vars.module_srl >= -1 and extra_vars.document_srl in (2996188,2995342,2995032,2994991,2994968,2994943,2994923,2994919,2994821,2994801,2994769,2994613,2994415,2994398,2994330,2994326,2994319,2994287,2994274,2994260,2993925,2993849,2993807,2993734,2993134,2992653,2988719,2987066,2985273) and extra_vars.var_idx >= -2);

확장변수잖아? 확장변수 쓰는 게시판이 5개인가밖에 없는데 그나마 딸랑 입력도 1개 뿐입니다. 사실 큰 의미는 없고, 그래서 가차없이 지워버리고 다시 만들었지요.

 

...그런데 확장변수를 안 쓰는 게시판에서도 저런 요청이 들어오더군요. 여전히 그룹 에러도 많고. 그래서 이건 좀 아닌데... 하고 다음날 머리를 식히고 로그를 천천히 다시 뜯어보니.. 더 수상한 내용이 있습니다.

select * from `xe_comments` as comments   where (module_srl not in (266,263,296468,270,1115682,1796544,2122817,644767,645003,259,1115681)) and (content like '%변속질%') and list_order < 2100000000  order by list_order asc limit 0, 10;

db 구문 같은건 모르지만, 저건 그 누가 봐도 '무슨무슨 모듈에서만 빼고' '변속질'이라는 내용을 코멘트에서 찾아봐라라는 것이라고 감이 딱 옵니다. 다행히도 '무슨 모듈만 빼고'라는 글을 보자마자 이것이 어디서 쓰이는 것인지를 파악했습니다. 저런 검색을 지원하는건 바로 통합 검색밖에 없지요.

 

통합 검색의 소스는 통합 검색 부분에서 만들어 준걸 그대로 사용하고 있었는데, 한번 서버 점유율 창을 띄워놓은 상태에서 ㅁㄴㅇㄹ라고 통합 검색을 해 봤습니다. ....바로 CPU 사용량 뒤에 0이 더 붙어서 60%가 되더군요. 가차없이 통합검색을 빼버리고 지금 이틀이 지났는데 에러가 없습니다. 이제서야 겨우 두 다리 뻗고 잘 수 있을듯 합니다.

 

결론은 간헐적으로 서버 사용량이 폭주한다면 통합 검색도 의심해 보시라는 것입니다. 슬로우 쿼리 유발하는 로그 찾아보시면 되겠지요. 아마 슬로우 쿼리가 지속적으로 쌓이면 시간이 흐름에 따라 결국 디비 데몬이 맛이 가는게 아닌가 의심되는데.

 

 

xe 공식 사이트의 통합 검색은 부하가 얼마나 걸리는지 모르겠군요. 그리고 xe 공식 사이트의 서버/데몬 각종 설정은 또 어떻게 되는지도요. xe 공식 사이트가 규모(누적된 글이나 접속자 수 등)가 꽤 크니까 이런걸 공개하신다면 직접 서버를 돌리시는 분들이나, xe로 서비스해야 할 웹 호스팅 업체 분들께서 상당히 반가워 하시지 않을까 싶습니다만. zero님에게만 너무 많은걸 요구하는 것이려나요? 비록, 내가 당장 원하는 것을 만들고 계시진 않아도, 다른 사람에게는 유용한 것을 준비하느라 바쁘실 테니까 말입니다.