단일 인스턴스(Single Instance) - SaaS 업그레이드의 비밀

 

◈ 들어가는 말

SaaS 의 선두 주자 Salesforce 는 보통 겨울, 봄, 그리고 여름 이렇게 연간 3회의 업그레이드를 실시하는데 한 번쯤은 어떻게 이것이 가능할까 하는 의문을 가져볼 필요가 있다. 지난 기고에서 다룬대로 대부분의 사용자가 SaaS 의 특징인 Multi-Tenancy 의 이점을 살려 각자의 목적에 따라 다양한 형태로 맞춤설정을 할텐데 어떻게 모든 사용자에 대한 단일 업그레이드가 문제없이 가능할까? SaaS의 필수 조건 Multi-Tenancy 에 또 다른 필수 조건인 단일 인스턴스(Single Instance) 를 더하면 이는 쉽게 이해할 수 있게 된다. 그렇다면 단일 인스턴스(Single Instance) 라는 개념을 더했을 때, SaaS에서 어떤 것들이 가능해 지는지 알아보자.

 

◈ Single Instance for All

먼저 전제할 것은 단일 인스턴스(Single Instance) 이란 개념이 어디까지나 논리적인 접근 이라는 것이다. 당연히 동일한 애플리케이션이라고 하더라도 물리적으로 데이터센터가 분리되어 있어 다른 데이터센터/서버/포드(Pod)에서 실행된다면 정확하게 동일한 인스턴스라고 보기 어려운 경우도 있기 때문이다. 그렇다면 단일 인스턴스(Single Instance) 의 의미는 무엇일까.

[단일 인스턴스(Single Instance)]

 

위의 그림에 따르면 단일 인스턴스(Single Instance)는 모든 사용자들이 억세스/사용하는 애플리케이션이 말 그대로 하나라는 것이다. 즉, 이 애플리케이션이 다운되면 모든 사용자들이 동시에 사용할 수 없게 된다. 이러한 단일 인스턴스(Single Instance)라는 개념에 이전 기고에서 짚어본 Multi-Tenancy 의 개념을 연결해 보면 다음과 같은 그림으로 설명할 수 있다.

[클라우드 솔루션 모델]

 

간단히 설명하자면, Multi-Tenant 모델을 기반으로 수행되는 애플리케이션과 데이터 베이스를 단일한 인프라스트럭처 위에서 논리상 하나로 통합하는 것이다. 이런 아키텍처로 클라우드 기반 시스템/SaaS 를 구성하면 많은 이익이 생긴다. 서문에서 밝힌 업그레이드 관점에서의 이익을 중점적으로 생각해보자.

 

◈ 설정 변경 (Configuration Change)

앞선 기고에서 밝힌 바와 같이 SaaS/PaaS 환경에서는 사용하는 시스템, 즉 인스턴스(Instance)를 사용자의 목적에 따라 변경할 수 있다. Salesforce.com 의 Platform 을 예로 들자면, 새로운 데이터 테이블과 그 세부 필드를 정의하고, 이를 표시하는 화면의 레이아웃을 원하는 형태로 구성할 수 있다. 이는 사용자가 새로 생성하는 테이블 또는 사용자 정의 개체(Custom Objects) 뿐만 아니라 시스템에서 제공하는 표준 개체(Account, Contacts 와 같은 Standard Objects)에도 동일하게 적용된다. 설정 변경의 범위는 데이터베이스에 국한되지 않고 데이터 접근 보안, 사용자의 프로필 등 수많은 설정을 아우른다. 그렇다면 모든 사용자들이 다양한 형태로 바꾼 수많은 설정을 어떻게 매 업그레이드마다 에러없이 모든 사용자들에게 새로운 버전으로 이관 및 제공할 수 있는걸까?

 

Salesforce의 아키텍처를 예시로 살펴보자면 우선 Salesforce 는 아래와 같은 설정화면에서 필요한 모든 사항을 변경을 할 수 있게 해준다.

[Salesforce.com 의 Setup 화면]

다시 말해, Salesforce.com 의 데이터베이스에 테이블과 필드를 생성하기 위해서 물리적인 데이터베이스 접근을 위한 도구나 SQL 클라이언트를 사용할 필요가 없다. 모든 사용자는 위의 화면에서 필요한 테이블 및 필드를 생성할 수 있고 기능에 대한 사용자들의 권한을 변경하기 위해서도 다른 도구를 사용할 필요가 없다. 물론 Salesforce.com 에서도 SOQL (Salesforce Object Query Language) 이라는 DML(Data Manipulation Language) 체계가 있지만 개발자가 아닌 시스템 관리자가 설정 변경을 위해 SQL 클라이언트와 같은 도구를 사용할 필요가 없다는 의미다. 즉, 모든 사용자가 동일한 환경 및 도구를 사용해 설정 변경을 하는 단일 인스턴스(Single Instance) 를 제공하는 것이다.

 

즉 Salesforce 와 같은 SaaS 에서는 하부의 인프라 구조(Infrastructure) 를 가상화 시켜 사용자들에게 제공한다. 이를 논리적인 그림으로 표현하여 아래와 같다.

 

다시 말해, 사용자의 클라이언트에서 이뤄지는 각종 설정 변경은 메타데이터를 생성/변경하는 것이며, 이를 저장하는 시점에서 메타데이터 엔진에 의해 물리적인 인프라를 제어할 수 있는 실제 명령어로 번역되어 수행된다. 덧붙이자면, Salesforce 의 테이블, 필드, 화면 레이아웃 등의 모든 요소가 도구를 사용하여 들여다 보면 XML 로 구성 되어 있는데 결국 사용자들의 모든 설정 변경이 XML 파일의 요소로 저장되고 실행 시 런타임 엔진에 의해 번역되어 실행된다는 것을 알 수 있는 셈이다.

 

다시 말해, 모든 사용자들의 설정과 구성은 거대한 XML 파일로 만들어져 각 사용자에게 배정된 물리적인 데이터베이스 공간에 저장/관리된다. 따라서 새로운 버전의 환경에서 현재 시스템의 모든 XML 파일을 수행해보면 업그레이드 시 발생할 수 있는 문제를 미리 알 수 있는데, 설정 변경도 결국 데이터에 불과하기 때문에 이로 인한 에러는 거의 미미할 것이라 예측할 수 있다.

 

결론적으로, 단일 인스턴스(Single Instance) 에 ‘메타데이터 아키텍처’를 더하면 모든 사용자들의 설정이 하나의 애플리케이션에서와 같은 개념으로 관리되기 때문에 단일 인스턴스의 업그레이드로 오류 없이 모든 사용자를 동시에 업그레이드 시킬 수 있게 된다.

 

◈ 코딩을 이용한 추가 개발 요소들 (Customization)

설정 변경을 Salesforce 가 제공하는 데이터의 수정으로 이해한다면 단일 인스턴스(Single Instance) 상에서의 업그레이드는 크게 어렵지 않다. 하지만 다음으로 생각해볼 수 있는 문제는 각 사용자가 플랫폼이 제공하는 개발 언어인 APEX 나 Visualforce 를 이용하여 코딩하고 개발한 기능들이다. (APEX 는 99% JAVA 와 같은 구조를 가진 개발 언어며, Visualforce 는 HTML 또는 XML 과 거의 동일한 구조를 가진 마크업 기반의 UI 개발 도구이다.)

 

가령, 특정 데이터가 입력되는 경우 동시에 복수의 테이블이 많은 레코드를 처리하는 요구 사항이 있어 이를 위한 기능을 APEX로 개발했다고 가정해보자. 코딩하는 과정에서 개발자의 실수로 대량의 레코드 처리를 위한 루프(Loop) 부분에서 조건에 따라 무한루프의 발생 가능성이 있는데 이러한 코드의 논리적인 오류가 발견되지 못한 채 시스템에 업로드가 된다면, 강력하지만 유한한 자원을 공유해 운용되는 클라우드 컴퓨팅 환경, 다시 말해 SaaS 환경에서는 심각한 상황이 발생한다. 수천명, 수억명이 공유하는 시스템에서 무한 반복되는 한개의 단위 프로세스가 CPU 를 독점하게 된다면 모든 사용자에게 부정적인 영향을 줄 수 밖에 없다. 단일 인스턴스(Single Instance) 사용 하에 발생할 수 있는 가능성이지만, SaaS 서비스 제공자 입장에서는 이러한 오류를 근본적으로 차단할 필요가 있다.

 

이를 차단하고 관리하기 위해 Salesforce 가 사용하는 방법이 새로운 함수/프로세스 생성 시 이를 테스트 하는 코드를 같이 작성하게 하는 것이다. 아래 그림으로 이해해보자.

[APEX 코드와 테스트 클래스]

 

Salesforce 에서 APEX 코딩을 하는 경우는 크게 데이터와 관련해 트리거(Trigger) 를 사용하는 경우와 추가 기능을 생성하기 위해 새로운 클래스(Class) 를 만드는 경우다. 이때, 반드시 새로운 트리거나 클래스와 함께 작성해야 하는 것이 그에 상응하는 테스트 트리거나 클래스이다. 다시 말해, 트리거나 클래스가 존재한다면 반드시 그것과 쌍을 이루는 테스트 모듈이 존재해야 한다. 이 조건이 충족되지 않으면 개발한 코드를 운영 시스템(Production) 에 업로드 할 수 없다. 물론 이에 더하여 한가지 조건이 더 있다. 새로운 트리거나 클래스와 함께 반드시 개발해야 하는 트리거나 클래스의 테스트 모듈의 역할은 개발된 트리거나 클래스를 호출하여 실행하는 것이다. 호출 시, 하드코딩된 파라미터를 포함하여도 좋다. 어찌 되었든 대상 트리거나 클래스를 호출해 전체 코드의 75%가 실행되어야 하는 것이 조건이다. 이때 사용되는 기준은 소스코드의 행 수이다. 즉, 개발한 클래스의 전체 코드가 100 라인으로 되어 있다면, 이를 호출하는 테스트 모듈에 의해 75행이 실행되어야 한다는 의미이다. 당연하게도, 테스트 모듈은 이러한 제약에 포함되지 않는다.

 

정리 해보자면, 새로운 트리거나 클래스를 개발할 때 반드시 그에 상응하는 테스트 모듈을 작성해야 하며, 해당 테스트 모듈이 개발된 트리거나 클래스를 호출해 행 수 기준으로 전체의 75%에 해당하는 코드를 실행하는 것이 확인되어야 개발된 트리거/클래스가 테스트 모듈과 함께 운영 환경으로 배포(Deploy) 될 수 있다. 물론 에러를 포함해서는 안된다. 개발 환경(Sandbox) 에서는 이러한 제약이 없으니 테스트 하는 것이 문제가 되지 않는다. 오직, 운영 환경으로 배포 시점에서 개발한 코드를 배포/업로드해야 위 결과를 알 수 있다.

 

이 모든 내용이 단일 인스턴스(Single Instance) 나 업그레이드와는 무슨 관계가 있을까? 단일 인스턴스(Single Instance)라는 가정하에서 Salesforce 인스턴스를 새 버전으로 업그레이드하고 그 환경에서 사용자들의 코드를 모두 옮긴 다음, 사용자들이 작성해놓은 테스트 모듈만 모두 모아서 한번에 실행 시킨 후 그 결과를 보면 된다. 사용자들이 작성해 놓은 테스트 모듈은 이미 에러에 대한 검증이 되었으니, 개발된 코드의 75% 이상을 문제 없이 실행할 수 있음을 확인 시켜 준다. 즉, 해당 코드들은 업그레이드 버전에서 문제 없이 작동된다는 것이다. (참고- APEX Code: Testing and Code Coverage)

 

단일 인스턴스 아키텍처가 아닌 과거 소프트웨어 개발사의 개발 과정과 비교해보면 가히 혁신적이라 할 수 있다. 단일 인스턴스 구조 이전에는 소프트웨어 개발 후 업그레이드 버전의 오류를 수정하기 위해서, 또는 특정 일부 고객사의 요구 사항을 해결하기 위해 패치 버전이 만들어져야 했다 하지만 이러한 패치 버전들은 통합 관리가 쉽지 않을뿐더러 특히 고객별 패치가 존재하는 경우 이를 관리하기 위한 별도의 인적, 물적 자원들이 존재해야 했기에 소프트웨어 개발 비용을 기하급수적으로 증가시키고 결국 이를 감당하지 못하는 소프트웨어 개발 회사들이 사라지거나 합병을 당하게 되는 것이 다반사였다.

 

◈ 맺는 말

클라우드 컴퓨팅 및 SaaS 에서 Multi-Tenancy 와 더불어 단일 인스턴스(Single Instance)라는 개념을 통해 SaaS 의 여러가지 장점 중 업그레이드라는 관점에서 서비스 공급사와 사용자에게 어떤 이점을 가져다 주는지를 살펴 보았다. Salesforce 는 매년 3회 정기적으로 모든 고객에 대하여 제공되는 업그레이드를 자사의 중요한 성공 요인으로 꼽는다. 하지만, 기술적인 측면에서 업그레이드 자체를 넘어 무엇을 업그레이드 하는지가 더욱 중요하다. 

 

Salesforce 는 이를 위해 자사가 개발한 제품인 아이디어(Idea) 라는 플랫폼을 사용한다. Idea Exchange 라는 사이트에는 다양한 고객, 파트너, 사용자들이 불편 사항이나 새로운 아이디어를 포스팅 할 수 있는데, 포스팅 된 아이디어에는 찬, 반 투표를 할 수 있으며 찬성 시에는 10점이 더해지고, 반대 시에는 점수가 차감되는 시스템이다. 이렇게 만들어진 아이디어의 순위는 매 업그레이드 시 추가 또는 수정될 기능의 리스트에서 높은 우선 순위를 차지한다. 다른 각도에서 보면, Salesforce 는 자사가 잘 할 수 있는 것보다는 많은 고객들이 원하는 부분을 우선적으로 차기 업그레이드에 포함 시킴으로써 고객의 만족을 제고시키는 방향으로 업그레이드를 해 온 것이다..

 

현재 IT 기업들의 규모나 환경을 고려하면 웹기반 애플리케이션 서비스의 개발은 크게 어려워 보이지 않는다. 하지만, 장기적으로 고객이 만족하고 다른 사람에게 추천하고 싶은 서비스를 개발하는 것은 어렵지만 무척 중요한 일이다. On-Premises 기반의 시스템 개발이 필요없다는 의미는 아니지만, 분명한 사실은 클라우드 컴퓨팅 기반으로 서비스를 개발하는 경우 많은 이점이 있다는 것이다. 나아가 개발된 서비스가 Multi-Tenant 아키텍처에 단일 인스턴스(Single Instance) 로 제공될 때 더 많은 이점을 누릴 수 있게 된다.

 

◈  본 글은 ITBizNews에 기고한 기사의 원본입니다. ▶  https://www.itbiznews.com/news/articleView.html?idxno=59083