독자에게 마켓플레이스에서 판매해 온 웹 애플리케이션이 있다고 하자. 독자는 불길한 징조를 느끼고 클라우드 인프라를 기반으로 하는 SaaS가 업계에서 지향하는 방식이라는 점을 깨닫는다. 또한, SaaS가 필요하며 이미 해당 제품의 SaaS 버전을 제공해 주도록 자신의 고객이 압력을 가하고 있다는 것을 인식한다.

문제는 수익성을 유지하거나 높이는 방식으로 신속하고 효과적으로 애플리케이션을 SaaS로 변환하는 데 있다.

SaaS 애플리케이션과 일반 웹 애플리케이션을 비교하려면 많은 차이점을 고려해야 한다. 이러한 차이점 중 일부는 기술적인 부분이며 일부는 비즈니스 모델의 변화와 관계가 있다.

일반적인 웹 애플리케이션 vs. SaaS

정의된 주요 특성에서 알 수 있듯이 SaaS에는 고객이 사용한 만큼 비용을 지불하는 방식으로 소프트웨어 애플리케이션을 사용하는 기능이 있다. 소프트웨어 라이센스를 받으려고 할 필요가 없으며 소프트웨어를 설치하고 호스트하고 관리하려고 준비할 필요도 없다. 이러한 운영 특성은 SaaS 애플리케이션을 제공하는 조직에서 담당한다.

성공적인 SaaS를 위한 핵심은 멀티테넌시이다.

애플리케이션에 등록하는 기능이 최소한 기본적인 SaaS 기준을 만족시킬 정도는 된다고 하더라도 실질적으로는 부족하다. 실제로 SaaS 애플리케이션은 멀티테넌트 애플리케이션이기도 해야 한다.

이러한 사실은 단순히 경제적인 문제로 귀결되는 요인과 관계가 있다. 업계를 선도하는 SaaS 회사의 CEO도 멀티테넌시가 없으면 SaaS 비즈니스는 성장할 수 없다는 점에 동의한다. (관련 기사를 참조한다.)

멀티테넌시는 효과적인 SaaS 레벨이다.

효율성은 모든 애플리케이션을 사용할 수 있다는 점을 사용자에게 명확히 인식시키면서 다양한 애플리케이션 사용자를 수용하는 기능인 멀티테넌시에서 주로 비롯된다. 이러한 개념을 하나의 시스템에서 개별 사용자에게 적용함으로써 사용했지만, 이러한 환경은 SaaS 환경과는 약간 차이가 있다. 일반적인 엔터프라이즈 SaaS 애플리케이션에서는 사용자가 특정 조직의 직원으로 구성된 그룹이며 이러한 조직을 테넌트라고 한다. 이러한 상황은 조직에서 애플리케이션을 구입한 경우에 간단한 웹 애플리케이션에서 발견하게 되는 상황과 비슷하며 애플리케이션의 경우에는 애플리케이션을 사용하는 직원으로 구성된 그룹이 있으며 해당 조직은 소유자가 된다. SaaS 모델에서는 조직이 소유자가 아니라 테넌트이지만 직원 그룹은 여전히 사용자이다. 각 사용자는 특정 테넌트(조직)과 연관되어 있으며 SaaS는 각 테넌트에게 그들의 사용자가 사용할 수 있는 애플리케이션 사본을 자체적으로 소유하는 데 필요한 경험을 제공한다.

클라우드 활용 SaaS에서의 가상화

간단한 웹 애플리케이션과 클라우드 기반 SaaS 애플리케이션 간의 차이는 현재 IT 분야에서 사용되고 있는 다음과 같은 대표적인 두 가지 용량 활용 기능에 있다.

• 멀티테넌시(앞서 소개한)
• 하드웨어 가상화

애플리케이션 효율성은 주로 애플리케이션 아키텍처라는 멀티테넌시로부터 비롯되며 그 다음은 하드웨어 가상화의 결과이다. 클라우드는 일반적인 데이터 센터의 실제 시스템 방식을 사용했을 때 발생되는 불필요한 용량을 가상화 기술을 사용하여 줄여서 하드웨어 용량의 활용도를 증대함으로써 가치를 활용하는 작업을 우수하게 수행한다.

또한, 클라우드는 자원에 대한 필요성을 기반으로 애플리케이션에 하드웨어를 동적으로 재할당할 수 있는 기능을 제공한다. 이러한 탄력성은 단기(몇 분)간에 끝날 수도 있고 장기(몇 개월)간 지속될 수도 있으며 하드웨어에 관한 의사결정을 하나의 애플리케이션에서 탈피하여 다수의 애플리케이션으로 범위를 넓히고 변화를 제거하여 하드웨어에 대한 투자를 더욱 예측 가능하고 관리하기 쉽게 한다.

이제 기존 웹 애플리케이션을 SaaS 기반 애플리케이션으로 변환하는 일반적인 단계를 살펴보도록 하자.

위로

웹 애플리케이션을 SaaS로 변환

웹 애플리케이션을 SaaS 애플리케이션으로 변환하려면 다음과 같은 7가지 기능이 만족되어야 한다.

1. 애플리케이션이 멀티테넌시를 지원해야 한다.
2. 애플리케이션에 일정 레벨의 셀프 서비스 등록 기능이 있어야 한다.
3. 적절한 등록/결재 메커니즘이 있어야 한다.
4. 애플리케이션을 효과적으로 확장할 수 있어야 한다.
5. 애플리케이션과 테넌트를 모니터하고 구성하고 관리할 수 있는 적절한 기능이 있어야 한다.
6. 고유 사용자 ID와 인증을 지원하는 적절한 메커니즘이 있어야 한다.
7. 각 테넌트에게 일정 레벨의 사용자 정의 기능을 지원하는 적절한 메커니즘이 있어야 한다.

각 사항을 좀 더 자세히 살펴보도록 하자.

멀티테넌시 지원

멀티테넌시는 SaaS의 효율성을 결정하는 주요 요소이다. 일반적으로 애플리케이션은 다수의 사용자를 지원하지만, 모든 사용자가 하나의 조직에 소속되어 있다는 것을 전제로 한다. 이 모델은 조직에서 그 구성원이 사용할 소프트웨어 애플리케이션을 구입하는 경우(SaaS 이전 시대)에 적합하다. 그러나 SaaS와 클라우드 시대에는 대부분의 조직에서 이 조직에 소속된 모든 사용자가 애플리케이션에 액세스할 수 있지만, 각 조직의 자체 구성원만 자신이 속한 조직의 데이터에 액세스할 수 있는 애플리케이션을 사용하게 된다.

데이터 보안을 손상시키지 않으면서 다수의 조직(SaaS 명명법에서는 테넌트라고 함)을 동일한 애플리케이션상에서 수용하는 이러한 기능을 멀티테넌트 애플리케이션으로 정의할 수 있다.

다음 목록 이후에 있는 그림에 표시된 바와 같이 멀티테넌시 레벨은 여러 가지가 있다.

1. 하드웨어만을 공유하는 클라우드에서의 단순한 가상화
2. 테넌트마다 데이터베이스가 분리된 단일한 애플리케이션
3. 단일한 애플리케이션과 공유 데이터베이스(고효율성, 진정한 멀티테넌시)

첫째 모델이 진정 멀티테넌시가 아니라는 점에는 논쟁의 여지가 있지만, 가상화된 서버가 있고 멀티테넌시 형태로 활성화된 클라우드에서는 이 모델이 자주 사용된다. 그러나 사실상 이 모델은 기능이 부족하며 전용 하드웨어를 사용하는 이전의 ASP 모델에 비해 약간의 이점만 있을 뿐이다.

가장 효과적인 레벨은 애플리케이션이 데이터베이스와 애플리케이션 비즈니스 논리를 완전히 공유하는 레벨이다. 이렇게 하는 것이 데이터베이스 스키마를 변경하여 모든 테이블과 뷰에 테넌트 ID를 추가하고 모든 SQL 액세스를 다시 작성하여 테넌트 기준을 필터에 추가해야 하는 성가신 프로세스일 수 있다. 이러한 작업이 필요한 코드에서 한 부분이 누락되면 애플리케이션의 데이터 보안이 손상될 수 있다.

애플리케이션에서 발생하는 데이터 액세스 인스턴스 외에도 보고서 작성자나 유틸리티 애플리케이션과 같은 기타 애플리케이션이 있을 수 있으며 이러한 애플리케이션을 수정하여 개별 테넌트의 데이터를 특정 테넌트만 액세스할 수 있게 테넌트 필터링을 삽입할 수 있다. 그러나 애플리케이션 자체에서 직접 액세스하지 않는 유형은 통제해야 하는 문제가 있다. 권한이 부여된 모든 사용자가 보고서를 작성할 수 있는 경우에는 이러한 사용자가 소속된 테넌트에 속하지 않은 데이터는 액세스할 수 없도록 차단해야 한다.

셀프 서비스 등록

단순히 애플리케이션에 테넌트를 추가하는 비즈니스 프로세스가 필요한 요청 메커니즘인 경우에도 애플리케이션에서 일정 레벨의 셀프 서비스 등록이 사용 가능해야 한다.

등록 및 결재

등록 및 결재 메커니즘을 제공해야 한다. SaaS 애플리케이션은 테넌트당 사용자 수, 애플리케이션 옵션 및 사용 기간과 같은 요인을 기반으로 하는 일련의 결재가 계획적으로 수반되기 때문에 애플리케이션의 사용량을 추적, 관리하는 방법과 테넌트 관리자가 액세스할 수 있는 결재 정보를 생성하는 방법이 있어야 한다.

애플리케이션의 확장 및 관리

등록이 늘어남에 따라 애플리케이션을 확장할 수 있는 기능이 있어야 한다. 클라우드 인프라에는 애플리케이션을 효과적이고 효율적으로 확장하는 데 필요한 많은 기능이 있기 때문에 클라우드 인프라는 이러한 기능을 수행할 수 있는 필수 방식이라고 할 수 있다.

또한, 애플리케이션과 모든 테넌트를 모니터하고 구성하고 관리하는 관리 기능과 애플리케이션 관리 기능을 제공해야 한다.

사용자 ID와 인증

사용자 고유 ID를 허용하는 인증과 사용자 ID를 지원하는 메커니즘을 제공해야 한다. 멀티테넌시에서는 시스템에 사인온하는 모든 사용자를 식별하여 사용자가 어느 테넌트에 속하는지 판별해야 하기 때문에 특정 테넌트에 속하는 사용자를 식별할 수 있는 일정한 관계가 있어야 한다. 사용자와 테넌트 간의 이러한 관계는 사용자가 액세스할 수 있는 데이터를 제한하는 데 사용되는 핵심 정보이다.

고유성이 보장되고 개인이 인식할 수 있으며 특정 테넌트에 속하는지 식별할 수 있기 때문에 일반적으로 이메일 주소를 사용하여 이러한 작업을 수행한다.

이메일 주소가 통합된 인증 메커니즘과 방법이 많이 있으므로 사용자를 식별할 수 있는 유연한 메커니즘을 선택해야 한다. 특정 테넌트가 그들이 기존에 사용하던 LDAP이나 기타 디렉토리 서비스 또는 인증 메커니즘을 활용하여 SaaS 애플리케이션에 싱글 사인온을 지원해야 하는 경우도 있다. 사용자에 대한 이러한 외부 인증이 중요하긴 하지만, 식별된 사용자가 사용자가 주장하는 테넌트의 구성원인지 인정하는 것은 SaaS 애플리케이션이 담당한다.

테턴트별 사용자 정의

테넌트에게 고유 URL, 방문 페이지, 로고, 색상 스킴, 폰트 및 언어를 지정할 수 있도록 각 테넌트에게 적합한 기본적인 사용자 정의 레벨을 지원하는 메커니즘을 제공해야 한다.

이러한 기본적인 레벨의 테넌트별 구성이 예상되지만, 다양한 테넌트의 요구를 진정으로 충족시키려면 기본적인 레벨보다 더 세부적인 테넌트별 사용자 정의 기능이 필요하다.

일반적으로 필요한 사용자 정의는 테넌트가 애플리케이션의 사내용 버전을 사용하여 수행하게 되는 사용자 정의 유형과 비슷하다. 이러한 사용자 정의에는 필드나 테이블을 추가하고 특정 비즈니스 논리를 설정하거나 다른 애플리케이션과 통합하는 과정이 수반된다. 멀티테넌트 디자인의 효율성을 손상시키는 별도의 인스턴스를 설정하지 않으면서도 테넌트별로 이러한 사용자 정의를 수행할 수 있는 기능이 고용량 SaaS 아키텍처의 특징이다.

위로

고려해야 할 성능상의 문제점

멀티테넌트 SaaS 애플리케이션의 성능상의 문제점은 활동 레벨이 같은 동일한 수의 사용자를 수용하는 모든 웹 애플리케이션에서 확인할 수 있는 문제점과 일반적으로 같다. 웹 애플리케이션에서의 늘어나는 용량 수요를 처리하는 데 필요한 우수 사례는 많으며 일반적으로 이러한 사례는 멀티테넌트 SaaS 애플리케이션에도 적용될 수 있다. 이러한 기술에는 일반적으로 전체 서버 세트로의 로드 밸런싱과 수평적/수직적 확장이 포함된다.

수평적/수직적 확장

클라우드 인프라 기능은 이러한 확장을 동적으로, 자동화된 방식으로 수행하고 필요할 때는 자원을 제공하며 더 적은 자원으로 성능 SLA(Service Level Agreement)를 충족시킬 수 있을 때는 자원을 축소할 수 있는 많은 기회를 제공한다. 이러한 탄력적인 기능은 충분히 활용되지 않을 자원은 제공하지 않으면서 서비스를 제공할 수 있는 방식으로 정확하게 대응하게 조정할 수 있다.

• 수평적 확장은 애플리케이션 서버 티어에서 일반적으로 사용된다.
• 수직적 확장은 데이터베이스 티어에서 일반적으로 사용된다.

데이터베이스 클러스터링

성공적인 제품의 경우에는 SaaS 애플리케이션을 사용하는 총 사용자 수가 매우 높으며 어떤 시점에서는 데이터베이스의 수직적 확장이 최적의 솔루션이 아닐 수도 있다. 대부분의 데이터베이스 기술에는 같은 데이터베이스에서 더 많은 용량을 제공할 수 있는 클러스터 데이터베이스 모델을 제공하는 기능이 있다. DB2®에는 이러한 모델과 잘 작동하는 몇 가지 옵션이 있으며 이러한 옵션을 데이터베이스 클러스터를 작성하는 데 사용할 수 있다.

배치, 파티션 분할 및 동기화

그러나 SaaS 애플리케이션과 그 사용자 수에 따라 더욱 적합할 수 있는 다른 기술이 있다. SaaS는 본질적으로 어느 곳에서나 액세스할 수 있기 때문에 전체 사용자가 멀리 떨어져 있을 수 있으며 거리가 멀면 네트워크 토폴로지가 길어져서 성능이 저하될 수 있다.

이러한 경우에는 다른 지역에 있는 클라우드를 사용하고 데이터를 파티션하거나 일관성을 유지하도록 동기화를 사용하는 것이 유익하다. 이러한 옵션 중 어느 것이 적합한지는 특정 애플리케이션의 특성에 따라 다르다. 어떤 애플리케이션은 장거리 동기화에 부적합하다.

데이터베이스 분리

물론 데이터베이스 용량이 수요를 충족시키지 못하는 경우에는 별도의 데이터베이스를 설정하는 것이 사용할 가장 근본적인 방법(적어도 SaaS 애플리케이션의 경우에는)이 된다. 멀티테넌트 SaaS 애플리케이션을 원하는 사람이면 누구나 이 옵션으로 인해 테넌트마다 데이터베이스를 지원해야 하는 지킬 수 없는 상황이 발생할 수 있으며 이러한 상황은 멀티테넌시에서 피해야 하는 이러한 비효율성을 직접적으로 야기한다는 사실을 고려해야 한다.

그리고 데이터베이스 하나만을 서비스하도록 애플리케이션 서버를 분리해야 하는 경우에는 멀티테넌시의 효율성이 더 손상된다. 경쟁이 치열한 시장에서는 멀티테넌시에 대한 이러한 효율성이 SaaS 회사의 중요한 성공 요인이 된다.

로드 밸런싱 기능을 활용할 수 있는 멀티테넌시 설계

어떤 이유로, 분리된 데이터베이스를 사용해야 하는 경우에도 가능한 효율성을 동일하게 유지하기 위한 방법은 멀티테넌시를 설계하여 데이터베이스가 다수인 경우에도 로드 밸런스된 클러스터에 있는 모든 애플리케이션 서버가 해당 데이터베이스에 액세스할 수 있게 하는 것이다. 이 방식에서는 애플리케이션 서버에서 지원하는 사용자 세션용 데이터베이스에 연결할 수 있는 모든 애플리케이션 서버를 사용하여 로드 밸런스된 클러스터를 효과적으로 유지보수할 수 있다. 이렇게 하면 데이터베이스가 여러 개라는 제한조건 내에서 효율성 레벨을 가장 높게 유지할 수 있다.

용량이 유일한 요구사항은 아니다.

보안 레벨이 높은 특정 테넌트에게 맞는 암호화된 데이터베이스 버전에 대한 요구하는 경우와 같이 용량 외에도 데이터베이스가 다수 있어야 하는 합당한 이유가 있을 수 있다. 용량은 문제가 되지 않으므로 본질적으로 효율성이 적은 모델이 필요한 경우에도 가능한 효율성을 최대화하는 설계를 하는 것이 중요하다.

위로

고려해야 할 보안상의 문제점

여러 차례의 설문조사에서 일반적으로 보안은 SaaS 애플리케이션 등록자가 가장 중요시하는 문제이거나 적어도 거의 최상위에 근접한 문제인 것으로 나타났다. SaaS 제공자는 아무도 보안을 무시하지 않는다. 그러나 데이터 보안의 개념은 SaaS 애플리케이션 자체의 컨텍스트 내에서만 고려된다.

대부분의 SaaS 애플리케이션 아키텍처에서는 기본적인 요구사항으로 한 테넌트가 또 다른 테넌트의 데이터를 보는 것을 차단하는 데이터 보안 조치를 취한다. 그러나,

• SaaS 애플리케이션에 있어야 하는 핵심 기능은 다른 애플리케이션과 통합되고 상호작용하는 기능이다.
• 이러한 애플리케이션 중 일부는 애플리케이션 외부(SaaS 제공자의 제어를 받지 않는)에 있을 수도 있다.
• 모든 SaaS 아키텍처가 애플리케이션 외부에서의 액세스를 고려하여 설계된 것은 아니다.

이러한 애플리케이션은 데이터를 액세스하거나 공유하는 데 필요한 사내용 애플리케이션이며, 경향을 파악하기 위해 데이터를 조사하는 분석 도구와 보고서 작성 도구이다. 테넌트가 데이터베이스 관리자가 사용하는 유틸리티 도구를 사용하여 자신에게 속하지 않은 데이터를 액세스하거나 심지어 데이터를 조작하는 경우에는 이러한 도구도 보안에 문제가 될 수 있다.

SaaS 아키텍처 우수 사례에서는 데이터에 대한 모든 액세스가 애플리케이션의 제어 하에 있는 것은 아니며 데이터가 SaaS 애플리케이션을 통해 액세스되건, 어떤 외부 애플리케이션을 통해 액세스되건 관계없이 각 테넌트의 데이터를 보호할 수 있는 적절한 메커니즘이 있어야 한다는 점을 고려해야 한다.

위로

기술 스택 선택

기술 스택에 관한 의사결정을 할 때는 언제나 상충관계가 있으며 의사결정은 모든 테넌트를 대상으로 이루어지기 때문에 SaaS 애플리케이션에서는 이점이 특히 두드러진다. 이러한 고려사항 중 일부를 살펴보도록 하자.

운영 체제 고려사항

웹 애플리케이션과 사용자의 상호작용은 브라우저를 통해 수행되기 때문에 웹 애플리케이션의 운영 체제는 사용자와는 관련이 가장 적다고 할 수 있다. 그러나 다음과 같은 재정 및 기술적 문제를 고려해야 한다.

• 특정 코드가 운영 체제에 종속된 경우에는 선택이 제한된다.
• 또한, 일반적으로 외부 애플리케이션과 통합할 필요가 있고 특정 운영 체제에서 더 잘 수행되는 경우에도 선택이 제한된다.

클라우드에의 경제적인 문제로 인해 언제나 라이센스 비용이 낮고 성능이 우수한 운영 체제를 선택하게 된다. 웹 애플리케이션을 확장하는 데는 기본적으로 수평적 확장이 수반된다. 따라서 SaaS 애플리케이션이 성장함에 따라 웹 애플리케이션 서버 인스턴스의 총 수가 증가하게 되고 결국 직접적인 운영 비용이 늘어나게 된다.

데이터베이스 고려사항

일반 사용자에게는 웹 애플리케이션의 데이터베이스가 중요한 문제가 되지는 않는다. 웹 애플리케이션과의 상호작용은 브라우저를 통해 이루어지고 애플리케이션이 일반 사용자의 데이터를 저장하고 검색할 수 있는 한, 데이터베이스는 일반 사용자와는 별로 관련이 없기 때문이다.

또한, 애플리케이션 개발자는 재정 및 기술적 문제를 고려해야 한다. 애플리케이션이 데이터베이스의 특정 기능에 종속된 경우에는 선택이 제한된다.

애플리케이션 설계상의 여러 가지 이유로 데이터베이스를 선택하는 문제가 중요하다고 할 수 있으며, SaaS 환경에 요구되는 특성 때문에 데이터베이스를 선택하는 데 영향을 받을 수 있다.

데이터베이스에 대한 이러한 요구는 단순히, 궁극적으로 수용하게 될 사용자 수로 인해 SaaS 애플리케이션에서 더 높아지기 때문에 데이터베이스 확장성이 매우 중요하다. 점점 더 요구되는 애플리케이션을 처리하기 위한 데이터베이스 확장은 일반적으로 더욱 강력한 데이터베이스 서버가 사용된 단일 인스턴스에서 수행된다. 그러나 SaaS 애플리케이션에 필요한 확장성에는 수직적 확장 기능을 능가하는 잠재력이 있다. 따라서 데이터베이스 확장성의 다음 단계는 클러스터링 기능을 갖추는 데 있다.

클라우드 환경에서 이러한 클러스터링을 수행하는 기능이 데이터베이스를 선택하는 데 영향을 줄 수 있다. 다시 말해서, 수직적 확장 기능을 제공하는 다양한 운영 체제에서 실행하는 기능과 다중 인스턴스 클러스터링과 중복을 통해 확장성을 유연하게 선택할 수 있다는 점 때문에 DB2를 선택할 수 있다. 예를 들면, 클라우드에서 DB2 HADR(High Availability Disaster Recovery) 클러스터를 설치할 수 있다.

애플리케이션 서버 고려사항

다른 기술 스택에 대한 의사결정과 마찬가지로 일반 사용자는 브라우저를 통해서만 상호작용을 하기 때문에 애플리케이션 서버를 선택하는 문제도 주로 SaaS 애플리케이션 개발자의 의사결정에 달려있다. 그러나 애플리케이션 설계상의 여러 가지 이유로 여기에는 중요한 차이가 있으며 SaaS 환경에 요구되는 특성 때문에 데이터베이스를 선택하는 데 영향을 받을 수 있다.

WebSphere®와 같은 애플리케이션 서버의 특정 기능이나 애드온 컴포넌트를 활용하는 애플리케이션은 클라우드에 있는 해당 애플리케이션 서버를 사용해야 한다.

애플리케이션에 특정 기능이 일부 필요할 수 있고 그렇지 않으면 애플리케이션에 중요한 써드파티 애드온이나 통합 기능이 있을 수 있기 때문에 애플리케이션 서버를 선택하는 근거는 일반적으로 애플리케이션 라이프사이클의 초기에 마련된다. 때로는 단순히 조직의 전문 기술과 내부 표준에서 기술 스택의 특정 컴포넌트를 사용하도록 하기 때문인 경우도 있다.

SaaS/클라우드 환경에서 사용할 기술 스택을 선택하고 구성하는 데 있어 의사결정의 핵심은 기술과 경제력의 균형을 맞추어 좋은 결과를 달성하는 데 있다.

위로

유연성은 기술 혁신의 핵심이다.

사용할 기술 스택과 관련하여 의사결정을 하고 상충관계에 있는 사항을 교환하는 기능과 이러한 의사결정을 나중에 다시 재확인하는 기능은 SaaS 아키텍처에서는 가치 있는 기능이다. 기술이 변화하면서 업계를 선도하는 클라우드 제공자가 새로운 미들웨어 애플리케이션과 기능을 통합하게 된다. 그리고 SaaS 애플리케이션에서 이러한 기능을 채택할 수 있는 것이 하나의 장점이 된다.

SaaS 애플리케이션 아키텍처로 인해 특정 기술 스택에 한정된 의사결정을 하게 되기 때문에 SaaS 애플리케이션의 기능이 진화하고 적응하는 데 어려움이 있다. 서비스 지향 아키텍처의 핵심 개념은 사실상 SaaS 애플리케이션에 필요한 민첩성과 유연성을 제공하는 데 적합하다. 느슨하게 결합되어 있기 때문에 유연성이 있으며 유연성은 전략적, 전술적 혁신을 가능하게 한다.

이 기사의 나머지 부분에서는 최소한의 노력으로 Java™ 오픈 소스 결재 웹 애플리케이션을 멀티테넌트 SaaS 버전으로 변환하는 방법을 보여주는 예제를 Corent의 Multi-Tenant Server™를 사용하여 살펴본다.

위로

Corent의 Multi-Tenant Server를 사용하여 웹 애플리케이션을 SaaS 애플리케이션으로 자동으로 변환하기

클라우드 제공자는 광범위한 기능을 제공하며 거의 모든 웹 애플리케이션을 수용할 수 있다. 애플리케이션을 완전히 멀티테넌트 SaaS 애플리케이션으로 변환하려면, 애플리케이션을 대폭 수정하고 데이터베이스를 다시 설계하고 재구성하는 과정이 필요하다.

Corent의 Multi-Tenant Server를 사용하면 ISV가 다른 방식, 즉 미들웨어 계층을 사용하여 중요한 멀티테넌시를 제공하는 방식을 시도할 수 있다. 따라서 기존 코드를 변경할 필요가 없다. 일반적인 싱글테넌트 애플리케이션으로 표현된 인기 있는 오픈 소스 Java 웹 애플리케이션인 jBilling을 멀티테넌트 SaaS 버전으로 변환하는 데 필요한 네 가지 단계를 살펴보도록 하자.

1단계. 데이터베이스 스키마를 추상 모델로 변환

일반적인 웹 애플리케이션 스택은 그림 1과 같다. 애플리케이션은 Hibernate와 같은 데이터 지속성 계층을 통해 데이터베이스와 통신한다.

애플리케이션을 멀티텐넌트 애플리케이션으로 변환하려면, 테넌트로 데이터를 필터링하는 데 필요한 테넌트 식별 데이터를 관리하기 위한 필드가 추가되도록 데이터베이스를 다시 설계해야 한다.

SaaS-Factory™ 애플리케이션을 사용하여 기존 애플리케이션 데이터베이스의 스키마를 읽는다. 이 애플리케이션은 그 후에 테이블에 TenantID 필드가 추가된 새로운 MySQL 데이터베이스를 생성하기 위해 사용되는 데이터베이스의 모델을 작성한다. 이 시점에서 테넌트 정보용 테이블 하나를 포함하여 Multi-Tenant Server에서 사용하는 몇 개의 추가 테이블이 생성된다.

MetaModel 데이터베이스는 테이블과 필드가 같은 원본 애플리케이션과 정확히 동일하기 때문에 원본 애플리케이션은 MySQL 데이터베이스와 했던 것과 정확히 동일하게 MetaModel 데이터베이스와 계속해서 상호작용할 수 있다. 모델의 기초를 이루는 실제 데이터베이스는 멀티테넌트 애플리케이션에 필요한 추가 TenantID 필드를 사용하여 생성할 수 있다.

MetaModel 데이터베이스는 추상용으로만 사용되며 사실상 아무런 데이터도 보유하지 않는 모델일 뿐이다. 따라서 실제로 데이터베이스를 생성하게 되면, 지원되는 어떤 RDBMS(Relational Database Management System)에서도 데이터베이스가 생성된다. 이러한 기능은 ISV가 일부 기능이나 더 나은 애플리케이션 성능을 활용하기 위해 다른 RDBMS(아마도 DB2)를 선택하여 기술 스택을 변경하려고 하는 경우에 유용하다.

2단계. 사용자 인증 프로세스 확장

모든 멀티테넌트 SaaS 애플리케이션에는 인증된 사용자가 속한 테넌트를 정할 수 있도록 인증된 사용자의 필수 세션 정보를 관리하는 기능이 있어야 한다. 애플리케이션에 필요한 인증 방식은 여러 가지가 있다. 따라서 변환될 모든 애플리케이션을 분석하여 그 인증 방식을 이해해야 한다.

1단계에서는 테넌트 테이블을 설정하고 애플리케이션 데이터에서 이러한 관계를 유지할 수 있도록 사용자 테이블을 추가하는 방법을 살펴보았다. 목표는 사용자가 로그온하면 자신이 속한 테넌트와 짝을 이루고 해당 TenantID가 세션 정보에 포함되도록 애플리케이션의 사용자 인증 프로세스를 확장하는 방법을 구현하는 데 있다.

이러한 방법을 구현하는 방식은 다양하며 애플리케이션을 어떻게 구현하느냐에 따라 달라진다. Tomcat을 애플리케이션 서블릿 컨테이너로 사용하는 경우에는 Multi-Tenant Server에서 실행되어 사용자의 연관 TenantID를 검색하는 비즈니스 규칙을 컨테이너 관리형 인증을 활용하여 초기화할 수 있다. 또한, 서블릿 필터를 사용하여 스레드 로컬 변수 TenantID를 찾아서 설정할 수 있다. jBilling을 사용한 이 예제에서는 애플리케이션이 해당 사용자 테이블의 유효성을 검증하여 인증을 직접 처리한다. 그러므로 향상된 인증 기능을 제공하기 위해 사용한 방법에서는 새 테이블에 저장된 사용자의 테넌트 정보를 검색하는 프로세스에 추가할 인증 코드에서 몇 가지를 간단히 변경해야 한다.

인증된 사용자가 있고 이 사용자가 속한 TenantID를 알면 해당 테넌트에 속한 데이터만 액세스할 수 있게 데이터를 필터링할 수 있다.

3단계. 데이터베이스 연결 구성

Corent Multi-Tenant Server는 1단계에서 설명한 MetaModel 데이터베이스를 사용하는 서비스 지향 아키텍처를 기반으로 구축된다. 이 MetaModel은 애플리케이션의 원본 데이터베이스를 모델링하기 위해 추상 레벨로 사용하며 애플리케이션의 데이터베이스 통신은 구현된 실제 데이터베이스 대신 MetaModel 추상으로 리디렉션된다. 이러한 과정은 실제 MySQL 데이터베이스 대신 MetaModel 데이터베이스를 액세스하도록 jBilling의 JDBC 연결을 간단히 재구성함으로써 수행된다. Hibernate를 사용하는 애플리케이션의 경우에는 Corent 버전의 Hibernate가 구성된다.

이렇게 변경하게 되면, 애플리케이션 데이터베이스 호출이 MetaModel 데이터베이스로 향하게 된다. Corent Agile Controller™는 이러한 SQL 이벤트를 가로채서 Corent의 ADBC™(Agile DataBase Connector)로 전달한다. 애플리케이션 SQL문을 MetaModel 데이터베이스로 제출했으므로 ADBC는 SQL문을 받아서 구문 분석한 다음, SQL을 제출한 세션 사용자의 TenantID에 맞는 필터 기준(예: TenantID = <myTenantID>)을 추가한다. 이렇게 하면 공유 데이터베이스에서의 데이터 보안이 언제나 엄격하게 유지된다. ReportWriter와 같은 외부 애플리케이션이 연결되는 경우에도 이 애플리케이션이 액세스할 수 있는 데이터는 여전히 해당 테넌트에 적합한 데이터로 제한된다. 누가 로그인했는지 알 수 있기 때문에 로그인할 때 사용한 애플리케이션에 관계없이 이 사용자가 어느 테넌트에 속하는지 그리고 적당한 필터가 적용되었는지 알 수 있다.

SQL문을 조작하는 작업은 이 SQL문이 MetaModel 데이터베이스에 제출되고 사용자의 테넌트가 알려진 이후에 수행되므로 Corent Agile Controller는 특정 테넌트를 위한 프로세스와 구성을 검색하는 것을 포함하여 더욱 복잡한 조작을 가로채어 수행할 수 있다. 그러므로 테넌트별로 특정 조치를 수행할 수 있으며 데이터베이스 연결을 다양하게 대체하여 다른 모든 테넌트가 MySQL 데이터베이스를 사용하는 경우에도 한 테넌트는 DB2 데이터베이스를 사용하게 할 수 있다. 또는 추가 SQL 조작을 통해 한 테넌트가 검색할 수 있는 데이터를 90일 이전에 입력된 레코드로 제한할 수 있다. 이러한 모든 테넌트별 사용자 정의는 Multi-Tenant Server로 빌드된 Agile Rules Engine™을 통해 수행되며 원본 애플리케이션 코드를 변경하지 않아도 된다.

jBilling 애플리케이션의 전체적인 변환은 애플리케이션에서 단지 몇 가지 사소한 변경을 하는 것만으로도 완료되었으며 인증을 강화하고, 세션 정보에 테넌트 정보를 삽입하고, 데이터베이스 연결을 변경하여 Multi-Tenant Server를 가리키게 하는 과정과 주로 관계가 있다. jBilling에서 변경된 사항의 요약된 내용을 아래에서 확인할 수 있다.

• 원본 애플리케이션
  • 소스 파일 수: 897(Java 및 jsp)
  • 코드의 총 행 수: 76,621
• 변환된 애플리케이션
  • 추가된 소스 파일 수: 2(표준 템플리트)
  • 수정된 코드의 행 수: 100 미만
  • 애플리케이션 비즈니스 논리 변경: 없음

코드에서 수정해야 할 위치를 판별하기 위한 모든 분석과 준비를 포함하여 jBilling을 변환하는 데는 1주일도 걸리지 않았다. 이러한 변경은 대부분 JDBC 액세스에 필요한 일련의 Java 코드에서 단순히 한 행을 반복해서 변경하는 것이었으며, 이러한 작업은 Hibernate와 같은 데이터베이스 지속성 계층을 사용하는 경우에는 불필요하다.

4단계. 새 멀티테넌트 SaaS 애플리케이션을 클라우드에 배치

이제 SaaS-Factory를 사용하여 SaaS 애플리케이션을 지정된 서버(클라우드에 있는 서버 포함)에 배치할 수 있다.

애플리케이션과 데이터베이스에 필요한 서버를 선택하고 나면, 대상 데이터베이스가 생성되며(jBilling 애플리케이션의 경우에는 Windows®에서 MySQL 데이터베이스로 생성) 완전히 구성된 Multi-Tenant Server 애플리케이션이 선택된 애플리케이션 서버에 .WAR 파일 세트로 배치된다. Multi-Tenant Server는 최신 J2EE 서블릿 컨테이너와 함께 작동하며 WebSphere Application Server용으로 인증되었다.

이제는 배치된 애플리케이션이 다수의 테넌트를 처리할 수 있다. 그러나 원본 애플리케이션에는 테넌트를 관리하거나 멀티테넌트 애플리케이션을 모니터할 수 있는 관리 인터페이스가 없다.

또한, SaaS-Factory도 기본적인 멀티테넌트 서비스를 제공하는 컴패니언 애플리케이션인 SaaS-Cockpit™을 생성하고 설치할 수 있다. SaaS-Factory는 동일한 기본 애플리케이션으로서 MetaModel 데이터베이스에 액세스할 수 있으며 테넌트를 준비하고, Tenant Administrator 계정을 할당하고, 사용 가능한 다양한 테너트별 애플리케이션 구성의 기본 매개변수를 구성할 수 있는 관리 화면을 갖추고 있다. 또한, 테넌트와 그 사용자를 모니터하여 보고할 수 있는 관리 기능이 있다. SaaS 애플리케이션의 일반적인 특성 중 하나는 테넌트의 등록 및 결재를 추적할 수 있는 기능이므로 결재하는 기능이나 외부 결재 시스템과의 통합이 사용 가능해야 한다.

이러한 배치 레벨은 SaaS 애플리케이션 배치와 관련해서는 매우 기본적인 것이다. 클라우드 관리 도구를 사용하여 템플리트를 작성하고 애플리케이션 인스턴스를 전달하는 과정이 포함된 변환 및 표준 배치 시나리오 유형을 사용하여 확장성, 탄력성, 복원성 및 중복에 대한 애플리케이션의 요구를 만족하는 운영 아키텍처를 배치한 후에도 애플리케이션의 특성은 변하지 않는다.

일반적으로 SaaS 애플리케이션에서는 일련의 애플리케이션 서버가 로드 밸런서를 통해 액세스되고 데이터베이스 서버에 연결되도록 할 수 있다. 데이터베이스 서버 자체를 중복과 확장성을 제공하는 다수의 데이터베이스 서버로 된 클러스터로 배치할 수도 있다.

IBM DB2는 데이터베이스의 로드를 분산할 수 있는 기능뿐만 아니라 복원성과 보장된 복구 시간을 성취하기 위해 사용할 수 있는 여러 가지 기술과 구성을 제공한다.

• DB2 HADR(High Availability Disaster Recovery) 구성을 통해 2차 모드를 읽기 전용 데이터베이스로 사용함으로써 가용성의 복원과 일부 로드 밸런싱을 모두 제공할 수 있다.
• IBM pureScale 기술과 TSA(Tivoli System Automation)를 이용하면 처리 로드를 공유하는 다수의 노드로 된 클러스터 데이터베이스 환경을 구성할 수 있지만, 이러한 환경에서는 하드웨어와 운영 체제 구성이 더욱 제약을 받게 된다.

시스템의 중단으로 영향을 받는 고객과 테넌트의 수가 기존 온프레미스 소프트웨어의 사용자 수보다 많아졌기 때문에 SaaS 애플리케이션에서는 데이터베이스 가용성과 장애 복구가 더욱 복잡해지는 경향이 있다(그림 5).

이러한 경향은 오프라인 상태에서 데이터를 재구성하고, 스키마를 전개하고, 버전을 업그레이드하고, 로드가 심하게 변화하는 경우에도 계속해서 애플리케이션을 실행할 수 있게 하기 위함이다. IBM의 pureScale 기술은 z 시스템에서 AIX®와 Linux®로 마이그레이션되고 있으며 이전에 전용 메인프레임 환경을 위해 예약된 가동시간과 용량 처리를 가능하게 한다.

위로

결론

SaaS에 대한 정보 기술 산업의 혁신은 진행 중이며, 짐작하겠지만 이 분야에서는 몇 가지 중요한 변화가 이미 일어나고 있다. 클라우드 컴퓨팅은 다른 IT 분야의 발전보다 더 빠른 속도로 성장하고 있으며 SaaS는 이러한 성장의 중심에 있다. 이러한 변화로 인해 회사에서는 비즈니스 조직을 다시 생각해 보게 되고 클라우드 중심의 IT 분야에서 서비스를 제공하는 것에 관해 새롭게 생각하게 된다. 소프트웨어 벤더의 경우에는 이러한 변화를 이해하고 준비하고 따라야 하는 상황이 점점 더 시급해지고 있으며 그렇지 않으면 역사의 뒤안길에 남겨지게 될 것이다.

클라우드 기반 SaaS 모델은 기존의 소프트웨어 벤더 모델과는 비즈니스 및 기술적 고려사항에서 차이가 있다. 이러한 차이로 인해 ISV에게는 SaaS로 변화하는 것이 더욱 위험한 시도가 된다. 위험을 줄이고 타임투마켓(Time to market)을 촉진하기 위해 ISV는 입증된 기술, 제품 그리고 이러한 변화를 도와줄 파트너를 활용할 수 있다.

감사의 인사

이 기사를 검토하고, 아이디어를 제공하고, 의견을 제시해 준 Mike Oliver, Rob Brown, Mark Joncich, Kaiser Saeed 및 Feyzi Fatehi에게 감사 드린다.

참고자료

교육

• Create dynamically scripted multi-tenant applications using WebSphere sMash 시리즈는 멀티테넌트 애플리케이션 배치 패턴을 빌드하는 데 도움이 된다.
  
  
• Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware 시리즈에서는 애플리케이션에서 멀티테넌시를 사용할 수 있게 하는 기능을 다루는 다양한 패턴을 설명한다.
  
  
• 오래 전에 작성된 기사인 Securing a multitenant SaaS application에서는 멀티테넌트 Java 애플리케이션을 보호할 수 있는 실행 가능한 실용적인 방식을 제공한다.
  
  
• Corent Technology의 Multi-Tenant Server에 관해 자세히 배우자.
  
  
• 이 기사에서 언급한 다른 기술에 관한 자세한 정보는 다음 목록을 참고한다.
  • JDBC와 J2EE 서블릿 컨테이너를 사용하는 방법에 관한 자세한 정보는 Java at developerWorks를 참고한다.
  • 오픈 소스 jBilling을 무료로 다운로드하여 사용할 수 있다.
  • Hibernate를 사용하여 데이터베이스를 공유하는 방법을 배우자.
  • DB2 puerScale을 확인하자.
  • HADR에 관해 배우자.
  
  
• developerWorks cloud developer resources에서는 클라우드 배치 프로젝트를 개발 중인 애플리케이션 개발자와 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
  
  

제품 및 기술 얻기

• IBM Smart Business Development and Test on the IBM Cloud 사이트에서는 클라우드 애플리케이션 개발을 시작하는 방법에 대한 정보를 볼 수 있다.
  
  
• IBM Cloud에서 사용 가능한, 늘어나는 소프트웨어 이미지 목록을 참조한다.
  
  

토론

• developerWorks 커뮤니티의 클라우드 컴퓨팅 그룹에 참여하자.
  
  
• developerWorks 커뮤니티에 있는 우수한 클라우드 블로그를 모두 읽어보자.
  
  
• 연결, 공유 및 협업을 위한 전문가 네트워크이며 통합 커뮤니티 도구 세트인 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 일반적인 웹 애플리케이션 vs. SaaS
• 웹 애플리케이션을 SaaS로 변환
• 고려해야 할 성능상의 문제점
• 고려해야 할 보안상의 문제점
• 기술 스택 선택
• 유연성은 기술 혁신의 핵심이다.
• Corent의 Multi-Tenant Server를 사용하여 웹 애플리케이션을 SaaS 애플리케이션으로 자동으로 변환하기
• 결론
• 참고자료
• 필자소개
• 의견