ROA (REST 아키텍쳐)의 완성

고객사 차세대 아키텍쳐에 대한 Blue Print를 Research하다가 NoSQL (Cassandra, HBase)등을 reference했는데, 결과적으로 ROA 아키텍쳐의 완성은 NoSQL DBMS가 있어야 하는게 아닌가 싶다.

보고용 Article을 좀 쓰다가 정리가 안되서 blog에 포스팅하는데,

ROA에서 문제는 기존의 RDBMS는 ROA의 Resource구조와 맵핑이 잘 안된다.

ROA는 1 resource가 하나의 저장소에 저장되는 형태가 좋은데, (하나의 ROW라던지). RDBMS는 여러개의 Table에 걸쳐서 데이타가 나누어 저장되고, Key 구조도 FK를 이용하거나해서 복합 키가 생겨 버려서 Key 정의에도 모호성이 보인다.

반면에 NoSQL DB, 특히 Column형 DB는 Key & Value형태를 가지고 Value는 Schmeless로 아무 데이타형이나 들어갈 수 있기 때문에, (마치 HashTable에 VO를 Object 형으로 넣으면 모든 데이타 타입을 다 넣을 수 있는것 처럼) ROA 에 딱 맞아 떨어진다. 그것도 아주!! 기가막히게...

벌써 Facebook,Digg,Twitter들도 MySQL에서 Cassandra로 많이 전환하였다.

성능과 안정성 대용량 데이타 모두 지원하니 최고이기는 한데,

문제는 이런 SNS 애플리케이션들은 데이타 구조가 엔터프라이즈 애플리케이션에 비해서 많이 간단하다는 것이다. Reference관계가 없더라도 구현이 가능하다는 것이다.

반면 엔터프라이즈 애프리케이션은 각 엔터티간 관계 복잡한 관계 설정이 필요하다.

내린 결론은 ROA의 가장 이상적인 아키텍쳐는(본인 생각에)

ESB를 통한 유연성을 제공해주는 진입부분, REST 컴포넌트 그리고 NoSQL DBMS이다.

단 복잡도가 높은 엔터프라이즈 애플리케이션에는 적용하기가 어렵고 복잡도가 상대적으로 낮은 SNS성에 적합하다

결국 엔터프라이즈는 SOAP을 경량화해서 구현하는게 정답이 아닐까 싶다.