"이베이 아키텍쳐요? DB를 SAM파일 수준으로만 사용하고 그 위에 OR매핑 올린거 말씀이죠? 몇년전에는 몰라도 지금은 시대에 뒤떨어인 아키텍쳐지요. 이런 아키텍쳐의 근본적인 사상은 옛날 TP모니터 시절, 모든 트랜잭션은 TP모니터에서 관리해야 한다는 사상에서 나온건데 이건 너무 이상적인 것이죠.
이거 만들 때 SUN에서 이베이에 상당 금액을 펀딩해서 레퍼런스 한번 만들 작정으로 밀어붙인거지, 그게 아니었으면 못했을겁니다. 일년 반정도 걸린걸로 알고 있습니다. 요즘의 추세는 용도별/업무별로 DB를 분리하고, 이건 똑같습니다만, EAI를 도입해서 업무가 비동기적으로 처리될 수 있도록 하는겁니다. 여러 DB를 참조하는 요구사항은 최대한 쳐내긴 하지만, 그렇지 못한 것들은 EAI 를 태워서 비동기적으로 처리합니다. 그렇게 했을 때 만족할만한 응답시간을 보이지 못하는 것들은 가끔 분산트랜잭션을 써서라도 동기적으로 처리하기도 합니다. 물론 성능에 희생이 약간 있습니다. MSDTC를 켜놓으면 관리상 어려움도 있죠. 하지만 이베이 수준의 OR매퍼 새로 만드는 것보다는 훨씬 쉽습니다..
KT NeOSS사이트가 2004년 당시 완전 재구축할 때 저런 아키텍쳐를 기반으로 했습니다. 당시로써는 MS플랫폼하에 세계에서 몇손가락 안에 꼽히는 규모였죠."
덧붙이자면 KT NeOSS 는 KT의 네트워크 관련된 고객 영업지원 시스템인데, 메가패스, ADSL 전용망 전화 관련된 기기 관리 회선 관리 고객 관리 뭐 그런 것들 해준다. 김 수석 얘기로는 회선이 2억 넘고 고객숫자도 거의 1억(개인,기업고객들..) 서비스 사용기록 등등의 데이터는 상상을 초월한다고 한다. 이런 사이트는 각 업무별로 DB를 분리하고(슈퍼돔 64way 16대가 들어가 있다) EAI로는 BizTalk을 썼다고 한다. 잘 돌아간다네~
그리고 Scalibility 관련하여 마이스페이스 DBA랑 같이 교육받으면서 들었다면서 마이스페이스 사례도 얘기해줬다. 마이스페이스의 트래픽은 정말 상상을 초월한다. 이베이보다도 훨씬 크다. 여기는 SQL서버 인스턴스가 500개가 돌아간다고 한다. 당연히 용도별로 DB분리되어 있는데, 여기 아키텍쳐에서 신기한 것은 캐쉬 데이터베이스가 있다는거다. 자주 사용되는 데이터를 별도의 DB서버에 갖다놓고 거기서 읽어가게 한다는거지. 그런 서버가 메인DB앞단에 수십대가 있다고 한다. 캐쉬할 데이터는 전날치 트래픽을 분석해서 자주 요청되는 데이터들을 모아서 하루에 한번씩 각 서버에 배치시켜 놓는다고. 여기에 SQL2005 의 Shared database 기술이 쓰였고, 데이터 갖다놓는 알고리즘은 자체적으로 만들었다는구먼. 아 신기한 아키텍쳐다...
아, 오라클 10g의 RAC에 대한 의견도 피력함. 실제 헤비한 로드가 들어오는 운영상황에서는 8 node 정도가 한계이고 더 이상 붙이면 아무리 메모리 공유를 한다고 하더라도 노드들끼리 메모리 동기화시키는 로드 때문에 성능향상이 별로 없다고.... 따라서 이베이나 마이스페이스급 트래픽을 보이는 곳에서는 먹히지 않는 방법이라고 한다. 이에 대해 나름 한국 오라클 출신 울팀 권대리는 "MS사람답게 얘기하네요" 라는 짤막한 촌평을... ㅎㅎㅎ 오라클 구루들은 이에 대해 뭐라 그럴지 궁금하군....
--------------
DB가 용도별로 쪼개져 있는거 좋다. 그런데 비즈니스 로직은 어떻게 되어야 할까? DB에 sp의 형태로 들어가 있어야 하나? 도메인 레이어가 있어야 하나? 시스템 아키텍쳐와는 별개로 SW아키텍쳐를 구성하는 것도 참 문제다. 정답이 없는건 당연한데, 정답에 접근하는 방법조차도 나와 있는게 너무 없다. 아키텍쳐는 역시 어렵다.
--------------
MCA:Database 라는게 생겼다. Microsoft Certified Architect : Database 이다. 국내엔 한명도 없다. 한국MS에도 없다. 전세계에는 100명 정도란다. MS 프로덕트 그룹하고 바로 컨택을 할 수 있는 거의 유일한 통로라는군. 미국가서 5주 교육받는데 2만5천 달러다. 교육받고 셤보는데 드럽게 어렵다고 한다. MS홈페쥐가서 찾아보자.
Posted by maceo
