대용량도 아닌 거대 용량 아키텍처

이베이 이야기가 나왔으니, 지난 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도 없고, 데이터베이스도 활용하지 못하는 상황에서 손수 해야 할 일이 얼마나 많을지, 이베이 개발자들이 불쌍하다.

솔직히 이것 외에도 의문점이 한 두 개가 아닌데, 당장 이 문제로 이야기 나눌 사람이 주변에 없으니 답답하다.

이어지는 글. 거대 용량 시스템에서의 설계 이슈

최 재훈

블로그, 페이스북, 트위터 고성능 서버 엔진, 데이터베이스, 지속적인 통합 등 다양한 주제에 관심이 많다.
Close Menu