오픈소스의 확장성에 대한 고민
블로그를 읽다가 꽤나 흥미있는 프리젠테이션을 발견하였습니다. 아래는 인터넷 사진 공유 사이트인 flickr가 어떻게 구성되어 있는가에 대한 프리젠테이션입니다. 전형적인(?) PHP, MySQL 레퍼런스 사이트라고도 할 수 있겠습니다. 다만 사용자가 늘다 보니 그에 대응하기 위해서 해야 했던 작업들과 노하우들이 좀더 자세히 기술되어 있습니다.
KLDP도 아주 간단한 static html로 시작해서 cgi, shtml, perl 등을 거쳤고 최근 수년간은 PHP와 MySQL에 많이 의존하고 있습니다. (phpbb(기존 KLDP BBS), drupal(현 KLDP), moniwiki(KLDP Wiki 등)) KLDP는 아직까지 위의 프리젠테이션에 해당하는 정도의 작업(DB replication 등)은 행하지 않았고, 관리의 문제로 오픈소스를 최대한 그대로 가져다 쓰는 것을 선호해 왔기 때문에 Application 단에서는 최대한 수정을 피해 왔습니다. 전담 개발자를 확보하는 것이 불가능하기 때문에 그래야만 유지보수/관리가 가능하기 때문입니다.
그 대신 김정균님, dormael님 등의 노력으로 하드웨어 확장, Apache 최적화, 커널 최적화, DB Table Format 변경(MyISAM --> InnoDB) 등등... Application은 최대한 피하면서 확장을 해 왔는데 결국 Application 단에서 Query 등을 손대야 하는 날이 온다면 완전히 새로운 형태의 고민을 해야겠지요. 기존에도 김정균님이 phpbb에서 부하를 많이 주던 RSS 부분을 따로 떼어낸 적이 있었고, 현재 이곳에서 사용중인 drupal은 다양한 기능 확장을 위해 DB Query가 상대적으로 많이 나뉘어져 있어 간단한 작업도 불필요하게(?) 많은 DB Query가 날아다니고 있습니다.
만약 지금 시점에서 또 성능 저하가 일어난다면 DB 단에서의 Replication이나 클러스터 구성 등을 통해서 여전히 Application의 수정은 잠시 피할 수 있을텐데 그 수준도 넘어서는 고민을 해야 한다면 정말 어려운 시간이 되겠지요. 위의 슬라이드는 그 시점에 참고할 수 있는 좋은 자료가 될 것으로 생각해서 겸사겸사 적어 둡니다. 확장성 관련해서 더 읽어보고 싶은 분들은 아래 블로그들을 참고하시기 바랍니다.
http://kaistizen.net/EE/index.php/weblog/comments/very_very_high_scalable_architecture/
http://mbastory.tistory.com/150
댓글
감사합니다... ^^
부족한 제 글에 링크를 걸어주셔서 감사합니다... ^^
글을 읽어보니 운영상의 고민이 많으신 것 같습니다. 전담 엔지니어나 개발자가 있으면 더 좋으시겠지만, 그렇게 되지 않는 상황에서 KLDP와 같이 큰 사이트를 운영하시는 것은 참 어려울 것 같습니다.
추신: 권순선님이 쓰신 글을 보다가 갑자기 생각이 난 것인데, KLDP 사이트의 Tuning History를 한번 만들어 보시면 어떨까 생각이 듭니다. 일반적인 기업은 튜닝에 대해서 공개를 하지 않기 때문에 다른 분들이 튜닝에 대해서 배울 기회가 없는데, 서버를 운영하시다가 문제가 발생했을 때 이렇게 해결했다든지 하는 Tuning History가 있으면 오픈 소스로 다른 사이트를 운영하시는 분들에게도 큰 도움이 되고, 오픈소스를 확산하는데도 기여하는 부분이 있지않을까 생각을 해 봅니다.
"기업이 Linux를 택하지 않는 이유" (http://mbastory.tistory.com/139)
아래 중복된 댓글은
아래 중복된 댓글은 삭제했습니다. 익명 사용자에 대해서는 캐쉬 형태로 동작하므로 글을 올리고 나서 바로 보이지 않습니다. 이 또한 성능을 위해서 불편을 감수하고 있는 또다른 사례이지요. :-)
그동안의 튜닝 관련 히스토리는 공지사항에 가장 많이 나와 있고, 김정균님, dormael님, 소타님 등 staff들의 공지/게시판 글에도 여기저기 흩어져 있습니다. phpbb나 drupal 등 특정 application에 한정된 이야기도 있고, db 튜닝, apache 튜닝 등 좀더 일반적인 이야기도 있습니다. 아마도 system engineer 분들의 know how에 해당하는 부분이기도 하고, 튜닝 그 자체가 재미있는 것이지 그 결과를 문서화(?) 하는 것은 아무래도 덜 매력적인 일이라 구조적으로 공유가 되기 어려운 것 같습니다만... 이 글타래에서라도 많은 이야기를 주고받을 수 있으면 좋겠네요.
별도의 history를 만드는 것은 현재로서는 저 역시 상당히 귀찮네요. ^^;
댓글 달기