-
거대용량 시스템 아키텍쳐, 가늘어도 긴놈이 장땡
-
무섭고도 어려운 Scalibility, 겐도사마의 재림
이베이 이야기가 나왔으니, 지난 1월에 SK 아이미디어 상반기 워크숍 생각이 난다. 김용오 이사님께서 한참 사업 방향과 비전에 대해 연설하고 있을 때, 나는 R&D 센터장님과 다른 이야기에 열중하고 있었다. 주변의 따가운 시선도 눈치 못 채고, 갑자기 떠오른 구상에 대해 의견을 주고 받았다. 자세히 말하긴 곤란하지만, 이를테면 분산형 아키텍처를 어떻게 구현하면 좋을지에 관한 이야기였다. (나중에 허락 맡으면 공개할 수 있을지도. 어차피 지금쯤 원래 구상과 많이 달라졌을 것이다.)
워크숍에 다녀온 후, R&D 센터에선 그 날 제안했던 구상을 진지하게 고려하기 시작했다. 이미 프로토타이핑 작업에 들어간 팀도 있었기 때문에 아키텍처 상의 변화는 최대한 빨리 마무리 지어야 했다. 하지만 난데없이 아키텍처를 설계하려고 해도 경험이 있어야 말이다. 확장성 좋고(Scalable), 개방적이며, 확장성 있는 아키텍처라고 제안하긴 했지만, 이게 현실적인 구상인지 확신하기 힘들었다. 당장 필요한 건 개념 수준의 아키텍처 설계안일뿐이었지만, 이게 옳다고 확신하려면 뭔가 더 필요했다. 이때 조양환씨가 Flickr Architecture를 찾아 보여주셨다.
- Flickr and PHP, Cal Henderson
인터넷을 뒤져보면 이베이나 Flickr 외에도 다양한 사례가 나와 있다. 국내에선 자사의 시스템 구조를 공개하는 법이 드물다. 보통 보안 상의 이유를 댄다. 한편으론 사례 발표를 할만한 국내 컨퍼런스가 적은 탓인지도 모르겠다. 이유야 어쨌든 해외 유수의 기업들이 간략하게나마 자사의 아키텍처를 공개하고 논의를 이끌어내는 모습을 보면 부럽기만 하다.
이베이 아키텍처를 본 소감
-
No business logic in database
-
No stored procedures
-
Only very simple triggers (default value population)
-
-
Move CPU-intensive work to applications
-
Referential Integrity
-
Joins
-
Sorting
-
하루에 2페타바이트가 쌓이고, 한 달에 30억 건의 API 호출이 발생하는데다가, 하루에 260억건의 SQL이 실행되면 이런 극단적인 설계가 필요한 걸까? 그리고 보니 2년 전쯤 경제 잡지 포브스에 유망 기업으로 소개된 곳이 생각난다. 인도계 엔지니어가 설립한 이 회사에선 특별한 데이터베이스 솔루션을 팔았다.
오라클이나 MSSQL 등은 사실상 하드웨어 독립적이다. 좋은 점도 있지만, 아무래도 성능을 더 개선시키기 쉽지 않다. 그래서 이 곳에선 대용량 데이터를 처리하기 위해 하드웨어와 소프트웨어를 결합시키기로 결정했다. 이를테면 하드디스크 컨트롤러마다 분신이라 할만한 데이터베이스 소프트웨어가 설치되어 있어서, 중앙의 본체가 하는 일을 돕는 식이다. 내가 기억하기론 BC 카드에서 이 제품을 구매했다고 하는데, 세계적인 카드 회사이다 보니 하루에 수십억 건의 거래가 발생한다고 한다. 그러니 극단적인 제품이 필요했던 것 같다.
솔직히 이베이의 시스템은 개발자 입장에선 피곤하기 짝이 없다. 데이터베이스의 핵심 기능을 모조리 쓰지 못할 정도라면 굳이 데이터베이스가 왜 필요한지 의문이다. 그럴 바엔 구글처럼 자신만의 파일 시스템을 갖추는 게 낫지 않나 싶다. J2EE도 없고, 데이터베이스도 활용하지 못하는 상황에서 손수 해야 할 일이 얼마나 많을지, 이베이 개발자들이 불쌍하다.
솔직히 이것 외에도 의문점이 한 두 개가 아닌데, 당장 이 문제로 이야기 나눌 사람이 주변에 없으니 답답하다.
이어지는 글. 거대 용량 시스템에서의 설계 이슈
거대 용량 아키덱처 설계 시의 데이터베이스의 역할
KAISTIZEN님의 블로그에 재미있는 글이 올라와서 해당 글에 대해서 제 개인적인 의견을 몇 자 적어봅니다. 대용량도 아닌 거대 용량 아키텍처 저의 경우 말씀하신 사양 정도의 크기는 아니더라도 어느 정도 규모의 시스템을 SE로써 프로젝트 기간 동안 설계 및 운영을 해본 적이 있습니다. 단지 제가 설계를 했던 부분은 기간계 시스템이 아닌 정보계 시스템임으로 상황은 많이 다를…
http://kldp.org/node/82799 에 관련해서 몇 자 적었는데 저희는 트랙백을 지원하지 않으므로 수동으로 남깁니다…
KLDP 운영자시군요. 동아리 리눅스 서버를 맡고 몇 년간 정말 자주 들리곤 했습니다. 근래엔 윈도우 플랫폼에서 주로 작업하는 바람에 간간히 들렸을 뿐이지만요. ^^
게임쪽에서 Web만큼은 아니지만 비슷한 문제로 고민하고 있습니다.
저를 포함함 몇몇 사람들은 인터넷 서비스처럼 장애가 일어나도 서비스에 지장이 거의 없거나 사용자가 눈치를 채지 못하는 게임 서비스가 필요하다고 생각하고 있습니다. (http://www.zdnet.co.kr/services/story/print/0,39035309,39134344,00.htm)
그리고 그렇게 해서 고객을 만족시키면 결국은 우리들에게 이익이 될 것이라고 말이지요.
게임 퍼블리셔의 입장에선 외부 스튜디오가 개발한 게임이 관건이겠네요. 안정적인 서비스 플랫폼이 있어도 외부 스튜디오가 쉽게 받아들일 수 없는 것이라면 문제가 될테니까요. 쉬운 문제가 없네요. ^^
예, 맞는 말씀입니다. 하지만 공감대가 형성되고, 노하우가 전파되고 그러면 언젠가는 실현되지 않을까요?