Life is wonder-ful

웹어플리케이션은 보통 집중 모델로 개발 된다. 소프트웨어의 논리적 구조(Layer Model)을 물리적 구조에도 그대로 반영해 놓았다. 이 모델은 시스템 전체 크기가 커지면 DBMS가 항상 병목 지점이 된다. HTTPD, Application 등은 분산을 쉽게하는데 필요한 '상태'를 가지지 않게 만들 수 있는데 반해 DBMS는 '상태' 그 자체이기 때문에 여러 요청 간의 간섭이 발생해 규모를 늘이기가 쉽지 않다. Master-Master, Master-Slave 리플리케이션을 한다 해도 한계가 있다. 또 SQL DBMS의 관계형 데이터 모델은 현대 웹어플리케이션의 데이터를 모델링하기에는 그다지 적합하지 않다. 부하 분산을 위해 DB를 쪼개어 놓아서 JOIN도 못쓰고 쿼리 하나로 필요한 정보를 다 가져오지도 못하는 등 데이터 모델 자체도 많이 제약을 받게 되는데 굳이 기능 빵빵한 관계형 DBMS가 필요한지 의문이다. 운영 중인 시스템을 중단 없이 수정하거나 규모를 늘이는 것도 쉽지 않다. HTTPD 서버 추가하려면 L4에 등록해줘야 하고, 어플리케이션 서버 늘이려면 아파치 설정 수정하고 재시작하고, DBMS 늘이려면... 이건 어떻게 하는지 모르겠는데 아마 안될거다.

분산 모델은 하나의 노드에 HTTPD, Application, Cache, DB 등 필요한 요소가 모두 갖추어져 있고 규모를 늘일 때는 똑같이 구성된 노드를 하나씩 추가하기만 하면 된다. 뇌만 있는 사람, 폐만 있는 사람, 발만 있는 사람이 모여서 사회를 구성하지 않고 사람들이 사회에서 각기 역할을 나누어 가지듯 각 노드는 균질하게 구성하고 한 노드가 문제가 생기면 그 역할을 다른 노드가 넘겨 받는 모델이다. 집중 모델보다는 변화에 더 안정적인 모델이라고 생각한다. 말로 하니 구현이 아주 쉽다. Erlang 분산 프로그래밍은 말로 하는 것 처럼 쉬우니 충분히 구현 가능하리라 생각된다. Mnesia도 있으니 ㅎㅎ.

기존 웹어플리케이션이 사용자와 서비스 제공자 사이의 데이터 흐름이 주였다면 요즘 뜨는 웹 어플리케이션들은 사용자와 사용자 사이의 데이터 흐름이 주다. 사용자:서비스는 N:1이지만 사용자:사용자는 N:M이 되니 데이터 흐름이 그 만큼 많고 복잡할 것이다. 기존 모델로는 점점 늘어나는 데이터 흐름을 적절한 비용으로 감당하기 어렵다고 생각된다. 물론 특별한 기술 없이도 몸빵하면 되겠지만 그러면 몸은 몸 대로 망가지고 머리는 쓸모가 없어져 자연 퇴화 되어 버릴지도 모른다.

이제 증명을 위해서 구현을 해야 한다. 1차 목표는 단일 노드 단일 사용자 블로그, 2차 목표는 단일 노드 다중 사용자 블로그, 3차 목표는 다중 노드, 4차 목표는 단일 노드 장애 허용, 5차 목표는 무정지 시스템 업그레이드, 6차 목표는 동적 부하 분산 등으로 계획은 거창하다. 일단은 시작이다.