얼마전 마이크로소프트는 CodePlex를 통해 SaaS 샘플 애플리케이션(LitwareHR)을 공개하였다.

이 애플리케이션에 구현된 SaaS의 아키텍처 면에서의 특징을 살펴보기로 한다.
아키텍처 관점에서 SaaS 애플리케이션의 가장 큰 특징은 single-instance multi-tenancy이다. 한 애플리케이션의 동일한 인스턴스로부터 다양한 사용자의 요구를 만족시키는 서비스를 제공하기 위해서는 애플리케이션의 각 Tier를 설계할 때 이에 대한 충분한 고려가 선행되어야 한다. 이점이 기존의 ASP (Application Service Provider)가 실패한, 혹은 비효율적이라고 얘기되어 지는 부분이다.

SaaS 애플리케이션이 3 Tier 아키텍처로 구현된다고 가정할 경우, single-instance multi-tenancy를 제공하기 위해서는 애플리케이션의 각 Tier 마다 해당 사용자에 맞게 customize가 일어나야 하는데, 이를 위해서 metadata-driven 아키텍처가 필요하다. 즉, 로그인한 사용자의 metadata 정보에 근거하여 사용자 고유한 애플리케이션처럼 동작하여야 하며, 이를 위해 presentation tier, business tier, data tier에서 customize를 제공할 수 있어야 한다.(엄밀히 말하며, customizable이라기보다는 configurable이라고 할 수 있다.)

presentation tier에서의 customization에 대해 살펴보면...
사용자마다 고유한 ui를 제공할 수 있는 방법은 다양하겠으나 가장 손쉬운 방법은 css를 적용하여 사용자가 자신의 화면을 디자인하여 업로드할 수 있도록 하거나 ASP.NET 2.0부터 지원하는 theme이나 skin 기능을 이용하여 손쉽게 제공할 수 있다. 좀 더 고차원적인 방법을 제공한다면, 사용자가 화면 디자인을 할 수 있는 페이지를 제공하는 것이다. 다만, 사용자가 계약한 레벨에 따라, 즉, 사용하고 있는 서비스 레벨에 따라 사용자가 이용할 수 있는 메뉴나 화면의 다양성 측면에서 차등을 주는 것이다. 고급 서비스를 이용하는 사용자는 좀 더 많은 부가 기능을 갖춘 화면 디자이너를 이용하여 차별화된 ui를 디자인하여 사용할 수 있게 하고, 반대의 경우는 제약이 가해진 화면 디자이너를 통해 제한된 기능 및 사용자 경험을 갖도록 한다. LitwareHR에서는 사용자가 자신이 원하는 ui를 css로 작성하여 업로드하는 것으로 하고 있다.

business tier에서의 customization에 대해 살펴보면...
business tier에서 사용자별 metadata에 근거하여 사용자에 고유한 비지니스 로직을 제공한다는 것은 쉬운 일이 아니다. 이를 가능하게 하는 기술이 바로 workflow이다. 마이크로소프트는 .NET Framework 3.0의 핵심 요소 중 하나로 WF (Windows Workflow Foundation)을 제공하고 있다. .NET Framework 3.0은 비스타에 기본 내장되어 출시되며 따라서 OS에 이미 Workflow 엔진이 탑재되게 된다. 따라서 비스타 이후의 OS에서는 애플리케이션 레벨의 Workflow 기능은 간단히 OS에서 제공하는 기능을 사용할 수 있다.
business tier에서의 customization은 WF에서 제공하는 rule set과 policy를 이용하여 서로 다른 권한을 가진 사람들에 대해서 서로 다른 workflow을 타도록 할 수 있다. 즉, 모든 비지니스 로직을 workflow에 의해 customize하는 것이 아니라, workflow를 구성하는 단위 activity로 분해/조립이 효과적인 업무에 적용하는 것이 바람직하다. 말 그래로 OLTP성이 아니라 사람이든 기계든 workflow 개념이 포함되는 업무에 적합한 customization이다. SaaS 샘플 애플리케이션의 경우 Interview 단계를 뽑고자 하는 사람의 레벨에 따라 사용자가 설정할 수 있도록 하는 기능을 WF를 통해 구현하고 있다.
마이크로소프트가 웹 싸이트나 혹은 책으로 제공하고 있는 Pattern & Practices 시리즈 중에 "Application Architecture for .NET : Designing Application and Services"가 있는데, 이 책에서 제시하는 Tier별 구성 요소가 본 LitwareHR 설계에 그대로 사용되고 있다. 특히 비지니스 로직을 customize하기 위해 workflow을 사용하고 있고 이 workflow에서는 필요한 로직의 조합을 통해 원하는 flow을 구성하도록 하고 있다. LitwareHR 샘플 애플리케이션 외에도 Remend에서 제공하는 SaaS 서비스도 P&P에서 제시하는 아키텍처 설계 가이드를 충실히 구현하고 있다. 물론 P&P가 제시하는 것은 신주단지 모시듯 그대로 따라야 하는 것이 아니라, 아키텍처 설계시 참고할 가이드를 제공하는 것 뿐이다.


data tier에서의 customization에 대해 살펴보면...
사용자가 새로 서비스 이용 계약을 하게 되면, 서비스 제공하는 측에서는 사용자마다 테이블을 새로 생성하여 사용자 전용으로 사용하게 할 수도 있고, 하나의 테이블에 구분자를 두어 같이 사용하게 할 수도 있다. 혹시라도 커뮤니티 싸이트에서 커뮤니티 생성/관리 로직을 구현해 봤거나, 웹 호스팅 업체의 서비스 신청 로직을 구현해 본 독자라면 한번쯤은 고민해봤을 것이다. 이 같은 예보다 더 심각한 경우는, 같은 서비스를 이용하는 사용자라도 큰 차이가 없지만 데이터 스키마가 다른 경우이다. 즉, 기본적으로 제공되거나 사용하는 데이터가 존재하고 여기에 몇가지 필드가 추가되어 사용자 입장에서는 자기만의 데이터 스키마를 가지고 있다고 생각하게 하는 경우이다. 이 경우도 지금껏 여러분이 비슷한 경우에 처해본 적이 있다면 SaaS의 경우도 다르지 않다는 것을 말해 두고 싶다. 즉, 기본 정보를 제공하는 테이블이 있고, 그 외 사용자별로 고유한 필드가 함께 제공되어야 한다면, 해당 필드는 별도의 테이블에서 제공되어야 한다. 이 필드를 나타내기 위해서는 타입을 기술하는 테이블이 있어야 하고 실제 값을 가지고 있는 테이블이 있어야 한다. 즉, main 테이블외에 최소 두 개 이상의 테이블을 조인하여 사용자 고유의 데이터 스키마 처럼 착각하게 만드는 것이다. 
한 가지 고려해야 할 사항은 여러 사용자가 한 테이블에 데이터를 저장하고 읽게 될 경우, 혹시라도 있을지 모를 보안이나 개인 정보 유출에 대비하여 구현하여야 한다. 즉, 모든 sql 문장이 직접 테이블을 건드리는 것이 아니라 그 앞에 해당 customize된 view에 대해 작업을 진행하도록 하여야 한다. 이를 "Tenant View Filter" 패턴이라고도 한다.

전반적으로 LitwareHR 샘플 애플리케이션은 production 환경에서 바로 사용할 수 있는 코드를 제공하기 위함이 아니라, Microsoft가 SaaS의 아키텍처 관점에서 줄곧 제시해 온 Technical Guide의 사상이 실제로 구현될 수 있음을 예시하고자 함이다. 즉, 아키텍처 관점에서 multi-tier 환경의 애플리케이션이 metadata-driven한 방식으로 사용자별로 각 tier에서 customize가 일어나서 서로 다른 화면과 로직과 데이터를 사용할 수 있음을 보여주고 있다. 참고로 LItwareHR은 SaaS maturity model에서 level 3 까지 구현하고 있다. 즉, maturity model을 구분하는 아키텍처적인 특징인 "configurable, muti-tenant efficient, scalable" 중에서 "scalable"을 제외한 기능이 구현되어 있는 것이다. 자세한 것은 마이크로소프트 SaaS 싸이트를 참고하길 바란다.

Posted by 장현춘

댓글을 달아 주세요