요즘 뜨는 화두중 하나가 바로 클라우딩 컴퓨터다.
인터넷을 통해 각종 서비스를 제공하는 일종의 ASP 같은 형태인데, 기존 ASP와는 다르게, 동작을 위한 Platform을 제공한다는 것이다. 그렇다고 웹 호스팅 업체 처럼 운영체제 단을 제공하는 것은 아니고, .NET 환경의 응용 프로그램이 동작하기 위한 기초 서비스들을 제공한다는 의미이다.

사실 획기적인 사업 아이템은 아니라 생각된다. 호스팅 업체 잡고 하거나, IP 업체와 Join 해서 네트워크 선을 사내에 끌고 들어와 사내 서버실에서 하면 되었고, 사실 지금도 그렇게 하고, 계속 그렇게 진행될 것이다.
하지만, 작은 업체에서 자체적인 서버실은 무리가 있고, 그렇다고 비싼 호스팅 업체에 네트워크 비용 뿐만 아니라, Rack이나 서버 임대료등은 역시나 무리가 있다. 그렇다고 운영체제에 SQL 까지 사다 보면, 어느새 돈 천만원이 넘어가버린다. 얼마로 책정될지는 모르겠지만, 최소한 호스팅 업체보다 싸다고 한다면, 분명 이런 클라우드 컴퓨터 시스템은 나름 괜찮은 비용으로 훌륭하게 서비스 받지 않을까 싶다.

일단 .NET 기반의 어셈블리등을 배포 할 수 있고, SQL의 기본적인 데이터형은 대부분 지원한다. 게다가 IIS 7에 ASP.NET 3.5 그리고 각종 Workflow에 WCF의 기본 구성까지 모두 가능하다.
그런데 국내 각종 소개 자료를 보면, 지금까지 글로 쓴 내용 처럼 무언가 비지니스 적으로 좋거나, 기존 기술 보다 낫다는 수준에 불과해 내가 이해하기가 애매 했다.
그러다가 하나씩 문서를 보면서 문득 이 Azure 서비스가 바로 MVC를 기반으로 제공된 또하나의 프로그래머들의 놀이터라는 생각이 들었다.


 
복잡허니 무언가 무척 많았지만, 사실 저 3가지의 형태를 갖춘 것이 바로 Azure였다.
사용자와 직접 맞부닥치는 웹 페이지나, 웹 서비스는 모두 Web Role에서 관장한다.
그리고 Worker 부분에서는 데이터를 조작하거나, 변경, 계산하는 작업을 하게 된다.
이 때 Worker는 마치 윈도우의 서비스 처럼 주기적을고 계속 뱅뱅이를 도는 구조로
되어 있다. 즉 Web에서 사용자의 Action이 없어도 알아서 무언가를 처리하려 할 때
바로 이 Worker를 사용한다.
Storage 부분에서 데이터를 저장하게 된다. 기본적으로 DB의 구조를 따르고 있지만,
굉장히 추상적으로 구성되어 있는데, 아직까지 상세한 내용은 잘 모르겠다.

이 때, 괄목할만한 사항이 있는데, 바로 Web과 Worker간의 통신이다.
물론 Web쪽에서 Worker를 직접 부를 수도 있겠지만, 여기서는 직접 부르기 보다,
Queue라는 비동기 로직을 통해 주고 받는 구조로 되어 있다.
즉 View와 Control의 직접적인 커플링을 최소화 하겠다는 의지인 것이다.

실시간으로 데이터를 업데이트 하는데는 조금 무리수가 있지만,
비동기적으로 처리하려 할 때 이보다 좋은 구조가 없으리라 생각된다.

지금 계획적인 개인적인 프로젝트가 있는데, 한번 이 Auzre를 이용해 구현 해봐야 겠다.
728x90

.NET Framework의 대가와 MOSS 2007 프로그래밍의 대가들이 구축한 소스에 특정 사이트에 맞게 일부 커스터마이징되고 알지 못할 사람들이 이런 저런 업데이트를 가한 소스를 보고 있다. 이 코드가 Package라는 이름이 붙은게 조금 웃기는 사실이긴 하지만, base가 대가들이 만든거니 뭔가 특이하고 신기하긴 하다.

그런데, 도통 이해가 안되는 것 있다.
MOSS 2007 프로젝트를 하다가 보니 공통이라는 모듈 개념에 DAC(Data Access Component)와 BIZ(Business Logic Module)이 포함되어 이 둘이 Component 라는 형태로 붙어 있다. 그런데 이 모듈을 업데이트 하신 분은 DAC는 반드시 BaseDAC을 상속 받아야 되고 BIZ는 BaseBIZ에 상속 받아야 하는 강박관념에 빠지신 것 같다.

물론 DAC의 특성상 Database와 연관되는 작업이 많으니 BaseDAC을 상속 받아 기본 데이터베이스 연결에서는 반드시 쓸 필요가 있을지 모르겠다. 그런데 이 BIZ 부분은 도통이해가 안된다. 최소한 내가 예전에 배웠던 MVC(Model - View - Control) 부분의 Control 정도로 알고 있다. Workflow가 될 수 있고, 단순 계산 처리도 있을 수 있다. 그런데, 꼭 BaseBIZ를 상속 받고 Transaction을 태워야 될까? 크리티컬한 데이터라면, 반드시 All or Nothing을 추구해야 하는 데이터라면 반드시까지는 아니지만 태워야 하는게 기본이라고 생각한다. 하지만 단순한 계산이나 단순한 데이터인데 꼭 태워야 될까?

지금 로직들을 보고 있으면 참 답답한 마음이 그지 없다. 그냥, 적당히 분류해서 계통에 맞게 분리해서 모듈을 구성했으면 간단한 것을 이리 꼬아 저리 꼬아 놓으니 어느 순간에 순환 참조(참조가 계속 연결되어 자기 자신으로 돌아오는 참조)가 되어 그 고리를 끊기 위해 어셈블리(DLL)를 분리하는 불상사가 벌어진 것 같다. ( 해당 어셈블리(DLL)에 클래스 달랑 2개 들어 있다. 굳이 분리해서 따로 구성할 필요도 없는 그런 모듈인데....)
더 웃긴건, DAC이 있는데, Database 접근하는 모듈이 View에 해당하는 어셈블리에 담겨 있다. 왜 DAC을 만든건지.....

대가들이 만든걸 어설픈 누군가가 망친건지.. 아니면 대가 분들이 너무 오바해서 생각들을 하신 건지... 단순하게 만들어서 간단하게 끝낼 수 있는 것을 무쟈게 힘들게 짜놨다. 이제 슬슬 어느정도 그림이 그려지고 있는 판국이라 다행이긴 한데, 이걸 언제 정리해야 하는지는 도통 모르겠다.

UPDATE :
처음에는 프로젝트 수정작업을 할까 했지만, 이미 관계가 얽히고 섥혀 있어 대규모 공사가 되버릴 것 같다. 이 공사 하면 10중 8,9는 PM이 버럭 모드 들어갈 것 같다. GG. GG. 내비두자. 내버려 두자.

728x90

+ Recent posts

728x90