카산드라의 저주

디그 (Digg.com) 에 카산드라 도입했다가 망하고, 도입 추진한 CTO 가 잘렸다는 라는 얘기를 들었다. 이런 기사를 읽으면, “카산드라는 천하에 몹쓸 물건이구나” 라고 생각하기 쉽다.

하지만 현실을 직시하자. 어떤 플랫폼을 사용했다는 이유 만으로 서비스가 망가지는 경우는 없다. 주위에 몇 번이나 얘기했던거 같은데, “악마는 디테일 속에 살기 때문” 이다. 뒤집어 감히 얘기하자면 악마의 주소는 “큰 개념” 안에는 없다고 해도 좋다. 사용한 “플랫폼” 이라든가 “툴” 이라든가 심지어 “설계 개념” 마저도.
프렌드피드의 예를 들어보자. 이 사람들은 요즘 뜨는 NoSQL 이 아니라, 유행을 넘어 구린내가 나기 시작했다고 해도 과언이 아닌 MySQL 을 사용했다. 우와 진짜 구려. 근데 어떻게 늘어나는 트래픽을 감당했을까 (나처럼 개판치지 않고?)
자세히 들여다 보면 NoSQL 이 배격하는 “Relational Tuple Algebra” 를 사용하지 않고, MySQL 을 단순 키-값 스토리지로 사용했음을 알 수 있다. 심지어 InnoDB 의 정렬 약점을 해결하기 위해 “진짜” Primary Key 는 AUTO_INCREMENT 로 두고 “어플리케이션용” Primary Key 는 따로 넣었다.
게다가 “인덱스” 를 MySQL 에 의존하지 않았다. 애초에 그건 불가능했다. 키에 대한 “값” 을 관계형 튜플 (Relational Tuple, 아트리뷰트) 로 넣지 않고, 몽땅 합쳐서 (DB 전공자들은 화장실로 달려가 솟아오르는 욕지기에 대비하시라) 파이쏜 (Python) 의 자체 마샬링 프로토콜인 pickle 을 사용했기 때문이다 (심지어 이걸 zlib 로 압축까지 했다.) 이러하니, 인덱스는 당연히 DB 레이어가 아니라 어플리케이션 레벨에서 처리하는 수밖에 없다. 각 인덱스를 일반 테이블로 생성하고, 매번 저장할 때 마다 어플리케이션이 처리해야 하는거다. 당연히 ACIDity 는 물건너 간거다.
대신에 새로운 어트리뷰트가 생겨도 스키마를 바꿀 필요가 없다. 새 인덱스-테이블을 생성하고 어플리케이션 코드를 바꾸면 된다. 대신에 예전 튜플들에 대한 인덱스는 따로 생성해야 하고, 이게 완료되기 전엔 “Consistent” 한 결과는 나오지 않는다. (이것이 NoSQL 진영에서 얘기하는 “Eventual Consistency” 라고 얘기할 수도 있다) (24/7 돌아가는 인터넷 서비스의 어플리케이션 로직 버전 & 형상 관리 문제도 머리 아픈 얘기지만 여기선 일단 넘어가자.)
서비스 품질이 사용한 플랫폼만으로 결정되지 않는다는 예는 찾아보면 많다. 프렌드피드보다 보다 훨씬 쓰기 트래픽이 많을 것이 틀림없는 트위터도 MySQL 로 잘 살고 있다. 그러니 디그에서 CTO 가 잘린건 매우 당연한 일이지만, 그렇다고 카산드라를 욕하진 말았으면 좋겠다. 미리 얘기해 두지만 나는 카산드라 제대로 벤치마크 해 본 적도 없다. 다만, 악마는 디테일 속에 살고 있다는 경구를 잊지 말라는 얘기다.

명필은 붓을 가리지 않는다는 얘긴 할 필요도 없다…