* 이 글의 작성 목적은 특정 회사를 비난하는 목적이 아닌 기술자로서 원인에 대한 접근 후 좋은 방향으로 개선되는 것을 목적으로 합니다.
쏭군과 메신저를 하다보면 이따금씩 들려오는 메시지가 있습니다. '아...놔.. 티스토리 또 안되네.. ToT' 라는 메시지. 쏭군의 증언(?)에 의하면 오늘도 새벽내내 접속이 안되는 일이 발생했다고 합니다.
수백만개의 카페를 관리하고 TVPOT이라는 UCC 서비스를 원활하게 관리하고 있는 DAUM이 왜 유독 'TISTORY'에서만 그 관리능력을 발휘하지 못하고 있는지 궁금합니다.
여러가지 생각과 고민을 하던 끝에 문득 예전에 쏭군의 서버를 관리해주면서 있었던 일이 생각이 났습니다. 쏭군의 서버는 코어2듀오 6300에 램 2기가 하드 250기가 달린 나름 고사양의 서버 입니다. 현재 MONOEYES.COM 외에는 이렇다하게 돌아가는 서비스가 없습니다.
2007년 9월 1일에 쏭군과 관련해서 작은 사건이 하나 있었습니다. 워낙 글을 간드러지게 쓰는 쏭군이라서 그런지 블로거뉴스에 글이 게재되었고 엄청난 인파가 몰려들게 되었죠. 전날 밤을 샜던 저는 완전 피로에 쩔은 모습으로 자고 있다가 쏭군의 다급한 목소리를 듣게 되었습니다.. '아.. 준철아.. 블로거뉴스에 글 올라갔는데.. 서버에 접속이 안되... 미치겠네... ToT'
'어라? 그럴리가 없는데 몇명이나 접속했는데요?' 라고 물은뒤 IDC에 연락해 리붓을 때린 후 확인해 본 결과 2-3시동안 1만명 정도가 접속했던 것을 확인할 수 있었고 혹시나 DB튜닝이나 아파치셋팅을 잘못한 것일까라는 생각에 몇차례 튜닝을 시도 했었습니다. ( 사실 그정도 트래픽은 여러개 사이트를 호스팅해주고 있는 동일 사양의 제 서버에서 늘 일어나는 일입니다. )
그 당시만 하더라도 블로거뉴스를 통해서 트래픽이 늘어나면 여러가지 이득이 있었습니다. '악플보다 무플이 무서워요' 또는 '나홀로 외로운 블로그'에 새로운 사람과 만날 수 있는 기회를 주고 또 유명세를 탈 수 있는 소중한 기회를 주었죠- '간만에 기회를 얻었는데 서버가 죽었다' 라며 징징대는 쏭군의 입을 막기 위해서 저는 머리회전을 빨리 돌려야 했습니다.
일반적으로 3-4000명이 1시간동안 접속하려면 분당 66명 , 초당 1명이 접속을 해야 하는데 그 정도의 트래픽을 아파치가 못 견딘다고 하면 그건 MSX-II 에서 돌아가는 서버이거나 800RPM짜리 하드를 갖고 있는 서버라고 생각합니다.
그렇다면 그 다음 문제는 MYSQL인데 DB접속을 막은 뒤 HTML 페이지 하나만 띄웠을 떄 서버가 얼마나 버텨줄 것인가에 대해서 테스트를 해봤습니다. ( 블로거뉴스의 올라갔던 문제의 글을 HTML로 변환해서 FTP로 업로드하고 .HTACCESS 파일을 수정해서 특정 주소로 접근하면 해당 HTML을 읽어가도록 수정을 하고 경과를 지켜봤습니다. )
결과는 대성공이었습니다. DB에서 불러오는 일반 글들도 잘 작동했고, 얼마전까지 계속 서버를 다운시켰던 문제의 글들도 아주 쾌적하고 원활하게 작동하고 있었습니다.
여기서 제가 발견한 태터툴즈의 문제점은 '모든 글을 읽어올때 DB에 호출을 한다는 것' 이었습니다. 혹 똑똑한 블로거 분께서 이런 이야기를 하실 수 있습니다. 'DB 캐시를 돌리면 되지 않냐? 니가 서버를 못만져서 그래 XX야 ' 라고, 글쎄요... 프로그램을 개발할때는 파워유저가 아니라 초보자도 쉽게 사용할 수 있도록 해야하는데 '특정 프로그램을 사용하려면 DB튜닝법과 캐싱 방법을 배워야만 해!' 라고 말하긴 좀 어렵지 않을까요?
제가 처음 블로그를 운영할 때 사용했던 Movable Type의 경우에는 글을 작성하고 난 후에 Publish를 누르면 해당 글이 HTML로 재생성되는 형식의 블로그였습니다. 이와 같은 방식을 사용하게 되면 누군가 블로그에 접속했을때 몇키로바이트 안되는 HTML과 CSS, JS 같은 것들과 이미지들만 전송하면 되기 때문에 블로그에 접속하는 속도도 매우 빠르게 되죠. ( 호스팅 업체 입장에서도 전체서버에 영향을 미치지 않기 때문에 환영할 일이죠 )
전세계를 통틀어서 자신의 나라를 위해서 최적화된 블로그를 만들어 내는 나라는 몇 없습니다. 그 중에서 텍스트큐브나 태터툴즈는 제가 생각하기에 '매우 잘만들었다'고 자랑할 수 있는 툴임에 분명합니다. 다만 DB효율 문제나 HTML 생성 부분에 대한 개선은 확실히 시급한 상황이라고 볼 수 있습니다.
"가장 피해를 보고 있는 'DAUM' 도 조용히 하고 있는데 니가 뭔데 나서"라고 말씀하시는 분들도 있을지 모르겠지만 올해로 햇수만 5년째 블로그를 운영하고 있는 저로서는 네이버나 다음 자체에서 운영하고 있는 블로그 서비스의 트래픽도 만만치 않을텐데 매번 죽어나가는 티스토리를 보면서 제가 경험했던 것을 토대로 이슈화를 시키지 않을 수 없었습니다. 그 이유는 HTML 생성이 가장 간단한 해결방법이라고 생각하기 때문이죠.
이 글에 대한 여러 전문가님들의 의견과 티스토리측 입장이나 TNC측의 입장도 들어볼 용의가 있습니다. 저는 키보드워리어가 아니라 건전하고 솔직한 토론을 지향하는 사람입니다.
2시 35분 추가 글
티스토리 닷컴에서 트랙백으로 장애의 원인과 앞으로의 개선계획을 보내주셨습니다-
많은 분들이 덧글을 남겨주셨고 티스토리 쪽에서도 제 글을 확인해 주신 것 같습니다.
고객의 의견을 반영해주는 티스토리 분들께 진심으로 감사드립니다.
쏭군과 메신저를 하다보면 이따금씩 들려오는 메시지가 있습니다. '아...놔.. 티스토리 또 안되네.. ToT' 라는 메시지. 쏭군의 증언(?)에 의하면 오늘도 새벽내내 접속이 안되는 일이 발생했다고 합니다.
수백만개의 카페를 관리하고 TVPOT이라는 UCC 서비스를 원활하게 관리하고 있는 DAUM이 왜 유독 'TISTORY'에서만 그 관리능력을 발휘하지 못하고 있는지 궁금합니다.
여러가지 생각과 고민을 하던 끝에 문득 예전에 쏭군의 서버를 관리해주면서 있었던 일이 생각이 났습니다. 쏭군의 서버는 코어2듀오 6300에 램 2기가 하드 250기가 달린 나름 고사양의 서버 입니다. 현재 MONOEYES.COM 외에는 이렇다하게 돌아가는 서비스가 없습니다.
2007년 9월 1일에 쏭군과 관련해서 작은 사건이 하나 있었습니다. 워낙 글을 간드러지게 쓰는 쏭군이라서 그런지 블로거뉴스에 글이 게재되었고 엄청난 인파가 몰려들게 되었죠. 전날 밤을 샜던 저는 완전 피로에 쩔은 모습으로 자고 있다가 쏭군의 다급한 목소리를 듣게 되었습니다.. '아.. 준철아.. 블로거뉴스에 글 올라갔는데.. 서버에 접속이 안되... 미치겠네... ToT'
'어라? 그럴리가 없는데 몇명이나 접속했는데요?' 라고 물은뒤 IDC에 연락해 리붓을 때린 후 확인해 본 결과 2-3시동안 1만명 정도가 접속했던 것을 확인할 수 있었고 혹시나 DB튜닝이나 아파치셋팅을 잘못한 것일까라는 생각에 몇차례 튜닝을 시도 했었습니다. ( 사실 그정도 트래픽은 여러개 사이트를 호스팅해주고 있는 동일 사양의 제 서버에서 늘 일어나는 일입니다. )
그 당시만 하더라도 블로거뉴스를 통해서 트래픽이 늘어나면 여러가지 이득이 있었습니다. '악플보다 무플이 무서워요' 또는 '나홀로 외로운 블로그'에 새로운 사람과 만날 수 있는 기회를 주고 또 유명세를 탈 수 있는 소중한 기회를 주었죠- '간만에 기회를 얻었는데 서버가 죽었다' 라며 징징대는 쏭군의 입을 막기 위해서 저는 머리회전을 빨리 돌려야 했습니다.
일반적으로 3-4000명이 1시간동안 접속하려면 분당 66명 , 초당 1명이 접속을 해야 하는데 그 정도의 트래픽을 아파치가 못 견딘다고 하면 그건 MSX-II 에서 돌아가는 서버이거나 800RPM짜리 하드를 갖고 있는 서버라고 생각합니다.
그렇다면 그 다음 문제는 MYSQL인데 DB접속을 막은 뒤 HTML 페이지 하나만 띄웠을 떄 서버가 얼마나 버텨줄 것인가에 대해서 테스트를 해봤습니다. ( 블로거뉴스의 올라갔던 문제의 글을 HTML로 변환해서 FTP로 업로드하고 .HTACCESS 파일을 수정해서 특정 주소로 접근하면 해당 HTML을 읽어가도록 수정을 하고 경과를 지켜봤습니다. )
결과는 대성공이었습니다. DB에서 불러오는 일반 글들도 잘 작동했고, 얼마전까지 계속 서버를 다운시켰던 문제의 글들도 아주 쾌적하고 원활하게 작동하고 있었습니다.
여기서 제가 발견한 태터툴즈의 문제점은 '모든 글을 읽어올때 DB에 호출을 한다는 것' 이었습니다. 혹 똑똑한 블로거 분께서 이런 이야기를 하실 수 있습니다. 'DB 캐시를 돌리면 되지 않냐? 니가 서버를 못만져서 그래 XX야 ' 라고, 글쎄요... 프로그램을 개발할때는 파워유저가 아니라 초보자도 쉽게 사용할 수 있도록 해야하는데 '특정 프로그램을 사용하려면 DB튜닝법과 캐싱 방법을 배워야만 해!' 라고 말하긴 좀 어렵지 않을까요?
제가 처음 블로그를 운영할 때 사용했던 Movable Type의 경우에는 글을 작성하고 난 후에 Publish를 누르면 해당 글이 HTML로 재생성되는 형식의 블로그였습니다. 이와 같은 방식을 사용하게 되면 누군가 블로그에 접속했을때 몇키로바이트 안되는 HTML과 CSS, JS 같은 것들과 이미지들만 전송하면 되기 때문에 블로그에 접속하는 속도도 매우 빠르게 되죠. ( 호스팅 업체 입장에서도 전체서버에 영향을 미치지 않기 때문에 환영할 일이죠 )
전세계를 통틀어서 자신의 나라를 위해서 최적화된 블로그를 만들어 내는 나라는 몇 없습니다. 그 중에서 텍스트큐브나 태터툴즈는 제가 생각하기에 '매우 잘만들었다'고 자랑할 수 있는 툴임에 분명합니다. 다만 DB효율 문제나 HTML 생성 부분에 대한 개선은 확실히 시급한 상황이라고 볼 수 있습니다.
"가장 피해를 보고 있는 'DAUM' 도 조용히 하고 있는데 니가 뭔데 나서"라고 말씀하시는 분들도 있을지 모르겠지만 올해로 햇수만 5년째 블로그를 운영하고 있는 저로서는 네이버나 다음 자체에서 운영하고 있는 블로그 서비스의 트래픽도 만만치 않을텐데 매번 죽어나가는 티스토리를 보면서 제가 경험했던 것을 토대로 이슈화를 시키지 않을 수 없었습니다. 그 이유는 HTML 생성이 가장 간단한 해결방법이라고 생각하기 때문이죠.
이 글에 대한 여러 전문가님들의 의견과 티스토리측 입장이나 TNC측의 입장도 들어볼 용의가 있습니다. 저는 키보드워리어가 아니라 건전하고 솔직한 토론을 지향하는 사람입니다.
2시 35분 추가 글
최근 tistory 사이냅펄스 통계
10시 18분 추가 글티스토리 닷컴에서 트랙백으로 장애의 원인과 앞으로의 개선계획을 보내주셨습니다-
많은 분들이 덧글을 남겨주셨고 티스토리 쪽에서도 제 글을 확인해 주신 것 같습니다.
고객의 의견을 반영해주는 티스토리 분들께 진심으로 감사드립니다.
좋은 글.. 잘 읽었습니다.. ^^;
확실히 티스토리의 문제는 잦은 서버 다운인데 다음도 나름 노력은 하고있는듯 싶지만 잘 안되는거 같습니다.
예전에 TNC 관계자분에게 물어보니 티스토리 소스와 태터툴즈의 소스에 차이가 많이 있다고 하시더군요.
어떤 차이일련지는 모르겠지만 그래도 현재 인기절정을 달리고 있는 블로그 서비스니 튜닝에도 좀 신경을 써줬으면 하는 바램입니다.
소스의 차이가 MYSQL -> ORACLE의 차이인지 정확히 어떻게 소스가 달라졌는지는 모르겠지만 서비스를 운영하고 있는 입장에서 인기가도를 달리고 있는 티스토리의 잦은 섭다는 좀 곤란하다고 생각합니다.
한국에선 잦은 섭다를 겪으면서 조바심을 내느니 돈내고 호스팅을 사용하겠다고 생각하는 사람들이 더 많은게 사실이니까요 ^^
다 알아듣긴 힘들지만..(컴퓨터공학도를 꿈꾸는데 큰일났군요 OTL)
옵티마이징을 조금 더 해야 원할해진다 라는 것이군요. 그럼 서버증설을 한다고 해서 해결 될 일이 아니네..
DAUM은 10년이 넘도록 대형 서비스를 운영해온 회사입니다.
서버증설 및 최적화에 대한 튼튼한 노하우가 있는 회사가 어려움을 겪고 있는 부분에 대해서 부족하지만 제가 겪었던 것을 토대로 문제제기를 해보는 것 입니다.
DAUM 과 TNC 양사에 대한 믿음이 없다면 이런 글을 작성하기 어렵겠죠-
결국 태터툴즈 근본적인 문제로
애꿎은 다음이 고생하고 있다는 글이네..
나도 개인적인 바램으로...
포스팅 열릴때마다 DB 호출하는것보다.. HTML 로 파싱 되게하면 좋겠다는 생각이
TNC 잘못이냐, DAUM 잘못이냐 라는 부분 보다는 제가 겪었던 경험을 토대로 문제 제기를 하는거죠-
무엇보다도 형 블로그에서 있었던 일이 형이 제일 잘 알자나요~ 블로그에 글 올라가서 사람이 많이 봐주기 시작했는데 서버 다운되었을때 느낌을~
한가지 궁금한게 있습니다. 포스팅된글을 HTML로 만든다면 그에 따르는 댓글들은 어떻게 되는건가요? 역시 마찬가지로 댓글도 포스팅된글과 붙여서 HTML로 만들어 버리나요?
댓글이던 포스팅이던 수정 하거나 추가 되지 않는한 같은 내용을 뿌리도록 되어 있기 때문에 마찬가지로 그때그때 이벤트가 발생되었을때 HTML로 만드는 것이 효율적입니다.
Iframe을 사용하는것도 괜찮을것 같은데요...
실시간이 필요한 부분은 Iframe으로..
그러면 전체적으로 리프래쉬되지도 않을테고..^^
그냥 허접이 한마디 해봤습니다.
제가 알기로는 티스토리와 텍스트큐브에는 페이지 캐시 기능이 작동중인걸로 압니다만...
어째튼 태터계열은 DB를 자주 접속하는 블로그 툴이니 여러모로 무겁지요.
아무리 캐싱을 한다 하더라도 불필요한 DB접속을 많이하게 되는 것은 문제가 있죠 중소규모 서버의 경우에는 DB CONNECTION도 제한이 될텐데.
호.. 어려운 내용이네요..
잘 접근하신듯 합니다..
^^ 제 허접한 내공에서 접근한 내용이라 좀 더 기다리시면 고수님들의 내공을 들으실 수 있을거라고 생각합니다.
덧글 남겨주셔서 감사합니다-
그런 이유가 있었군요
유용한글 재미나게 읽고가요! 저는 공짜로 무제한 서비스를 해주는 티스토리에게 항상 감사하며 지내는지라 불평할 신세가 못되는것 같아요 ㅎㅎ
저는 이 글을 불평 보다는 문제 제기를 통해서 좋은 해결점이 나오고 그러한 해결점들을 통해서 티스토리에도 도움이 되고 제 자신도 많이 배우기 위해서 포스팅 했습니다. ^^
혹 DB분산이나 로드밸런싱등 고급기술에 대해서 이야기 하고 싶은 분들께는 DAUM과 같이 대형서비스 하는 곳이 그러한 DB분산이나 병렬처리를 못할 이유가 없다는 점에서 접근을 시작했다는 것을 말씀 드리고 싶습니다. ^^
전 소소한 서버를 관리하고 있는 사람이지 고급 서버기술자는 아닙니다
익명의 제보자님의 말씀 중에 참고하실만한 내용이 있어서 적어봅니다.
그분 말씀에 의하면
'대용량 서버와 소용량 서버의 데이터 처리는 완전히 다른 방식으로 해결을 해야 하며, DB에서 인덱스 구조를 짜는 것 자체도 소규모랑 대규모의 방식이 다르다.'
또 제가 말한 HTML 방식으로 처리를 하게 될 경우
서버가 분산되어 있기 때문에 '캐싱 데이터의 공유 문제' 와 스토리지 집중 방식으로 할 경우 '분산 서버에 대한 I/O 로드' 가 될 수 있다
라고 하시네요 ^^
다른 입장이 있으시거나 첨언해주실 내용이 있으신 분들은 편하게 남겨주세요- ( 위 내용은 N 사나 D 사가 아닌 서버전문가께서 의견 주셨습니다. )
그러게요 티스토리 베타를 그렇게 오래하고도
서버다운을 해결 못하는것 같네요...
DAUM과 TNC 모두 베타테스팅 기간 동안 노력을 했을거라고 생각 됩니다. 하지만 TISTORY가 사람들한테 이렇게 환호받을 줄은 예상을 못했을 수도 있죠 ^^
어느 누구를 비난하고 싶어서 쓰는 글이 아니라 모두가 피해를 보는 이 상황이 안타까워서 기술적인 대안들이 모여졌으면 하고 글을 썼습니다.
허접한 저의 대안과 함께 ^^
단일 블로그를 운영하는거와 이런 대용량 블로그 시스템을 운영하는 거와는 많은 차이점이 있습니다.
DB설계부터 대용량 아키텍쳐로 제작되지 않으면, 문제가 참 많아지죠.
backend에서 사용자가 알지못하는 많은 일이 벌어집니다.
search에 데이타를 보내기 위해 주기적으로 계속 사용자 데이타를 긇어와야하고,
업데이트,삭제,블로그폐쇄. 모두 고려해주어야합니다. 이외에 참 많습니다.
게다가 tistory의 관리의 어마마한 플러그인들. 설정사항등..그만큼 페이지당 DB select가 많아지고 update가 많아지겠죠. 사실 포탈블로그개발자가 본다면 토나올 정도일것 같습니다.;;;;(힘들단얘기^^)
전 tistory를 사용안하기 때문에 어떤 장애 였는지는 모르지만.
전면 장애였다면. NFS로물린 filer가 다운됐거나..
Global DB의 과부하였을지도 모릅니다. 사실 2개가 가장 의심.
현재 MYSQL로 클러스터링이 구현되는지는 모르겠지만 대부분의 mysql 어플리케이션들이
Master:Slave(n)으로 운영이 될거라 생각됩니다.
고트래픽상화에서 master에 DML(update,delete,insert)작업은 대단한 부담이 됩니다.
새벽시간대 발생한 일이라면 backend batch작업시 master에 대한 부하가 상당했을 거란 의심...
그냥 퍼뜩 생각나는건 제로보드를 포탈뉴스게시판에 붙였다면... 비슷하지 않았을까;; 합니다.
티스토리와 다음카페를 보고 비교하는건 무리가 있습니다. 카페는 태생적으로 대용량 설계가 됐을테니까요..
기술적인 문제에 대해서 자세히 설명해주시고 좋은 말씀 해주셔서 감사합니다.
다음카페와 티스토리를 비교하는 것에는 무리가 있다는 점에 대해서 제 생각을 말씀 드리자면 티스토리가 애초에 '오픈소스 상용화'라는 명분으로 DAUM과 함께 진행했던 프로젝트라면 기반 자체를 대용량으로 재설계 했어야 하는 것은 아니었을지 생각해 봅니다.
티스토리는 2시 13분 현재도 다운상태 입니다.
혹시 위 HTML 생성 관련된 내용에 대해서는 기술적으로 판단해 주실 수 없으실까요? 제가 막연히 생각해본 것 이라서
말씀하신 "HTML 생성 "에 관한 기술은 보편화된 방법이고
이미 티스토리에서도 사용하고 있을지 모릅니다.
전체 페이지 generation을 안하더라도 특정 모듈별 gen을 하고 붙여 넣고있을지 모르죠..
하지만 양날의 검입니다. 무수한 file gen은 그만큼 disk i/o를 증가시키거든요..
생각해보시면 file을 만들어야할 시점이 참 많습니다.
댓글이 달릴때, 삭제될때, 변경될때, 표시되는 숫자가 올라거가나 내려갈때.. 참 변수가 많죠.
당연히 프로그램 복잡도도 늘어나게 되고요.
미천한 경험상 잘 설계된 db 처리가 file gen방식보다 낫습니다.
다른 포탈 블로그들도 어느정도 절충해 쓰고 있다고 알고 있습니다.
잘 설계된 DB처리가 FILE GEN 방식보다 낫다는 점에 대해서 MINEOUT님의 말씀에 동의 합니다.
혹 이런건 어떨까요?
1. 자주 바뀌지 않는 글 같은 것들은 HTML로 생성.
2. 자주 바뀌는 카운터나 덧글들만 XML이나 DB 처리.
지금 티스토리가 HTML생성과 병행을 하고 있다면 덧글이나 이런 모듈들의 부하로만 서버가 다운되고 있다는 것 일텐데..
저도 미천한 지라 이렇다하게 확 답을 내리기는 어렵네요-
좋은 말씀 감사드립니다-
지금 다시 티스토리 서버 다운됬네효 ㅠㅠ
글올려서 한창 방문자 오고있는 상황이였는뎁 -_-
티스토리 또 죽었어요 ㅠ_ㅠ
먼가 어려운 이야기인데 레이님 글 보니 알아들을 것 같아요..ㅋㅋ
요즘 정신이 없어서 섭다 된지도 몰랐다는;;
티스토리 10대 블로거 선정 축하드려요-
완전 킹왕짱 -_-)b
제가 알기로는 tisotry는 모양만 태터툴즈일뿐, 거의 모든 부분을 새로 대용량 시스템에 맞도록 새로 짠것이나 다름없다고 알고 있습니다. 따라서 태터툴즈의 문제점이 그대로 티스토리에 적용된다는 것은 섣부른 추측이 아닐까 생각이 됩니다만..
어쨌든, 다운되면 기분 나쁜 것은 다 마찬가지더군요. ^^
만약 대용량시스템에 맞게 수정된 버전임에도 불구하고 현재와 같은 상황이 지속된다면 제가 제안해본 HTML 생성 방법을 시도해보는게 좋을 것 같네요.
대용량에 맞춰 재설계했는데 잦은 섭다를 일으키고 있다는 것은.. 좀 난감한 문제가 아닐런지..
말씀하신 것에 전적으로 동의하며, "서버 운영 측면"에서 볼때 태터툴즈(텍스트큐브)를 평가하자면 하급 프로그램이라 할 수 있습니다.(극단적으로 폄하해서 죄송합니다.)
호스팅 회사에서는 위에 글 쓰신 분이 분석하신 내용과 같은 이유를 가진 잘못 짜여진 카운터 프로그램, 태터툴즈 등을 싫어하는 이유라고 들었습니다.
저는 시스템 개발자로서 우리나라 웹프로그래머들이 서버운영환경을 고려하고 개발하는 프로그램이 적은 것에 많은 아쉬움을 가집니다.
간혹(전부가 그렇단 소리는 아닙니다.) 외국 프로그머들이 짠 소스를 보면 서버의 부하를 고려한 코딩을 접할 때마다 경탄을 하곤 합니다.
잘 짜여진 프로그램은 사용자에게 사용하기 쉬운 UI와 다양한 기능을 제공하는 것만은 아닙니다.
운영되는 환경에서 가볍게 구동할 수 있도록 만드는 것이 가장 중요한 요소란 것을 잊지 말아 주셨으면 합니다.
저는 사람을 탓하기 보다는 환경을 탓하고 싶습니다.
주변에 웹프로그래머들을 보면 LAMP 가 뭔지도 모르는 경우가 많은데 이 것은 학교교육부터 시작되는 문제라고 봅니다.
나무를 보여주고 그 나무가 하나의 열매에서 나무로 가기까지의 과정에 대해서 가르쳐줘야 하는데 대부분 나무를 보여준 채 나무를 똑같이 그려내는 것만 가르치고 있는 현실이라고 해야 될까요?
시스템 프로그래밍은 전체를 보고 짜임새가 맞게 만들지 않으면 바로 에러를 내기 때문에 그렇지만, 웹프로그래밍은 상대적으로 관대한게 사실이다보니 문제가 되는 것 같습니다.
예전에 ~티스토리의 잦은섭다는 광고수익을 노리고 온갖 펌질과 검색 엔진 스팸을 일삼는 '스팸 티스토리'들 때문이다.~ 라는 내용의 글을 읽어본 적이 있는 것 같은데..
역시 우리가 티스토리에 대해서 확실하게 알고 있지 못하는 이상 단순히 기술적인 문제일 뿐이라고 추측하는 것은 조금 섣부른 것일지도 모르겠습니다.
네이버 블로그는 1000만개가 넘는데.. 별 문제 없이 잘 돌아갑니다만
티스토리에 대해서 확실히 모르니까 그저 경험에 비춰서 이야기를 꺼낸 것이고 이 부분에 대한 비난이 아니라 입장을 밝혀달라고 요청하는 글 입니다. ^^
스팸도 문제고 DB도 문제인 것 같아요-
티스토리가 다운되면
파일 다운로드는 잘되는데
블로그는 먹통이 됩니다.
DB서버 문제가 아닐지.
글쓴이의 지적이 옳은 것 같습니다만?
^^ 누군지 모르겠지만 첨언은 실명으로 해주실때 가장 공신력이 있습니다.
트랙백이 안되는군요;;
관련하여 몇글자 코멘트 합니다.
요점은 HTML pregeneration으론 처리가 힘들것이라는 것입니다.
아마도 복잡한 문제일것이라고만 짐작이 됩니다.
감사합니다.
http://ideafactory.tistory.com/69
EAS가 TISTORY에서 오는걸 스팸처리하더군요- 복구했습니다 ^^
좋은 말씀, 좋은 의견 감사드립니다. ^^
미국이라서 안되는걸로만 알고는 미국 인터넷만 드립다 욕했던 1人 =_=;;;
수재님- 오랜만에 뵙네요 ^^
미국생활은 어떠세요? 저도 미국가고 싶습니다.
잦은 섭다는 노무현 탓이다. - 한나라당
웃자고 해 본 소리입니다.^^
ㅋㅋㅋ 완전 안습이네요-
전 한가지만 생각해볼게요.
HTML로 만든다면,
블로그 백업에 대한 측면은 접어버려야 하는거 아닌가요...?(이사에 관해서.)
HTML로 된 페이지는 다른 블로그 서비스로의 이사가 무척 힘들것 같은데요.
티스토리는 OPEN된 서비스이기에 티스토리를 쓰다가도 맘에 안들거나 다른 좋은곳을 발견해 이사를 하고 싶은사람들에게 그렇게 하라고, 표준을 지켜주려고 노력하는것으로 알고 있습니다.
음...글구... 페이지를 HTML로 생성시키는 방식이 어느정도까지 HTML화를 시키는것인지 잘 모르겠으나, 그렇게 된다면... 스킨을 어두운 스킨쓰다가.... 밝은 스킨으로 바꿨을때...그럼 어떻게 되는거죠??ㅎ;; 테두리는 밝은데 본문내용은 검은색...??^^;;
그런 측면에서 봤을때, HTML로 페이지를 생성시키는것은 닫힌서비스를 만드는것이 되지 않을까 싶으네요. 티스토리의 지향점은 속도나 안정성보다는 사용자의 편의성과 자율성을 조금더 중시하고 있는것은 아닌가...하는 생각을 해봅니다.
그래서 저 또한 개발자로서... 티스토리를 너무 좋아하구요. 티스토리를 제 홈페이지 처럼 만들어서 온갓 장난도 쳐보고 서비스도 매쉬업해보고,, 하는 그런용도로도 쓸 수 있으니까요.ㅎㅎ;
HTML로 전환한다고 해서 DB 내용이 사라지는게 아닙니다. XML 백업도 지금과 같이 되는 것이지요.
전체가 DB -> HTML 전환이 아니라 외부 접속시 보여지는 방식이 HTML로 전환되었으면 하는 것 입니다.
즉 글을 쓰면
1. DB에 저장된다 (기존처럼)
2. DB에 저장된 내용을 기초로 HTML을 생성한다.
3. 외부 사용자가 접속하면 HTML을 보여준다.
이렇게 되는거죠
기존에는 외부 사용자가 접속하면 DB에서 내용을 가져다 뿌렸습니다.
스킨을 변경했을때는 HTML을 RE-GEN 하면 되는 부분이죠 ^^
핀노트는 트래픽에 무방비하겠다는 걱정이 듭니다.
말씀하신 방법대로 HTML로 저장해두는 것이 맞는지 참 고민이 되는군요.
원래 두번클릭을 자유롭게 해가며 컨텐츠를 하루에도 수십번씩 (실제로 수정하지 않아도) 저장하게 되는데 그렇다보니 그것을 파일로 저장하는 것이 오히려 서버에 부담이 될텐데...
dynamic하게 만들다보니 dB에 손을 자주 대게 되는것도 당연하고..
대박나질 않길 바래야하는건가요? ㅎㅎ
핀노트는 AJAX가 생명인데 HTML로 생성하면 안되지-
블로그의 경우에는 컨텐츠가 Dynamic 하게 변경되는 것이 아니기 때문에 HTML로 생성하는 것이 이득이지만 핀노트가 HTML로 생성을 시키게 된다면 그 본연의 의미를 잃어버리는게 아닐까-
좀 더 많이 공부하고 연습하는 것만이 대박을 쫓는 자의 모습이 아닐까 싶다~ 결국 영원한 튜닝도 없고, 영원한 딜레이도 없다-