클라우드

클라우드 환경에서 코딩과 관련된 문제점: 1부

David Taber | CIO 2011.05.04
대부분의 클라우드 애플리케이션에는 개발과 관련된 기능이 포함돼 있다. 최소한 스크립팅은 가능하다. 그리고 이는 상당한 수준의 맞춤화와 일정 수준의 데이터베이스 접근, 연산 기능을 개발할 수 있도록 해준다. 그러나 최고 수준의 클라우드 애플리케이션조차 플랫폼/개발 환경 차원에서 한계가 있다. 앱이란 범용 목적의 실행 시간이나 제네릭(generic) 객체 컨테이너(container)가 아니기 때문이다.
 
예를 들어 멀티 테넌트(Multi-tenant) 배치에 맞춰 안전하게 개발 언어를 만들어야 한다. 또 사용자 코드가 가상 컴퓨터나 데이터베이스, 애플리케이션들을 저해하지 않도록 해야 한다. 더 나아가, 일부 언어는 그 구조를 제한해 자원 호깅(Hogging)과 교착(deadlock)을 방지해야 한다. 세일즈포스닷컴의 경우, 자체 클라우드 환경에서 수십억 개의 사용자 코드를 구동할 때 가장 중요한 업무 중 하나는 빠른 대응성과 양호한 업타임 상태를 유지하는 것이다.
 
세일즈포스의 APEX를 사용한다고 치자. 복잡한 과정을 많이 거치지 않고도 언어가 대부분의 비즈니스 로직을 처리할 수 있다. 그러나 클라우드 기반의 개발 환경으로 불가능한 부분이 있다. 플랫폼의 한계를 밀어붙이려면 특정 요건이 필요하다는 것이다. 예를 들어, J2EE의 라이브러리를 이용하면 원하는 것을 할 수 있다. 그러나 필요하다고 클라우드 플랫폼에서 J2EE를 간단히 쓸 수 있는 건 아니다. 라이브러리에서 몇 가지 방법이 필요한 경우라도, 기반이 되는 기능 중 일부를 플랫폼의 원본 언어로 포트해 올 수 없다.
 
라이선스 키를 생성하는 사례를 들어보겠다. 소프트웨어 벤더들은 고객과 계약을 맺을 때 라이선스 키를 사용하기를 선호한다. CRM 시스템은 라이선스 키를 고객의 자산 중 일부로 보유한다. 따라서 CRM 애플리케이션 내부에서 전적으로 키를 생성하는 게 바람직하다. 소프트웨어 부서들은 키젠 시스템을 CRM 앱으로 포트할 것을 요청한다.
 
키 생성을 위해 암호화 방식을 쓰는데, 이는 CRM 플랫폼의 일부로 제공된다. 그러나 임의의 정밀 수학 연산을 하는 니피(niffy) 라이브러리를 사용하기도 한다. 두 자릿수 숫자 2개를 곱한 후, 여기에 7제곱근을 씌운 값과 같은 정밀한 계산에 쓰이는 것이다. 니피 라이브러리는 가장 많이 쓰이는 공식을 반복해 하나의 데이터로 인식하고 이러한 복잡한 연산을 수행한다.
 
따라서 CRM 시스템에 모든 로직을 포트할 수 있다고 하더라도, 키젠을 실제 구동하는 연산 로드는 CPU 힙(heap) 크기와 쿼리의 수에 따라 강제되는 거버너(governor) 한계를 거쳐 전달된다. 이런 실행 시간 한계는 종종 BI같은 분석 솔루션, 주식 포트폴리오와 같은 최적화 솔루션, 고객 모델 정의나 다채널 유통모델 같은 중요한 고려사항들, 그리고 그 밖의 비즈니스 애플리케이션에 영향을 주곤 한다.
 
물론 답은 있다. 인접 클라우드에서 외부 데이터 크런칭을 수행하는 서비스를 도입하는 것이다. 불행히도 이런 상황에서 쉬운 설계 패턴이란 없다. 다음의 이유 때문이다:
 
-접근할 필요가 있는 데이터 중 일부는 이전이 불가능하다. 정책과 보안 등의 문제 때문이다.  또 다른 시스템에 변화가 있어 데이터를 이전해야 하는 경우도 있다.
 
-다른 클라우드가 CRM 데이터베이스에 상주하는 많은 데이터에서 크런칭 해야 한다면, 원본 레코드보다는 데이터의 비트맵과 롤업, 초록, 요약을 옮기기 원할 것이다.
 
-문제에 따라, 데이터를 원격 자원자원에서 전송해오는 것이, 또는 코드를 다른 클라우드로 포트하는 것이, 그리고 기능을 옮기는 전략을 활용하는 것이 쉬울 수 있다.
 
-WSDL과 SOAP에서 문제가 발생하는 경우일지라도, JSON 같은 RESTful 프로토콜을 이용하기 쉬운 여타의 클라우드가 있을 수 있다.
 
-연산의 성격에 따라, CRM 시스템에서 모든 작업을 가상화 하고, 원격 클라우드에서 필요한 방법 일부를 불러와 이용하는 게 적합할 수 있다. 이와는 반대로 모든 업무를 원격 환경에서 가상화 하는 게 나을 수도 있다. 이를 완벽하게 갖춘 서비스라고 지칭한다.
 
-시스템 상태(예, 워크플로, 락, 데이터 변경)를 평가해야 하는 경우, 네트워크 트래픽(그리고 라텐시)의 양이 중요한 요소가 될 수 있다.
 
-보안과 테스트, 배치와 관련된 사항들을 무시할 수 없다. 연산과 관련된 문제가 중대하다면, 몇 년이 걸릴 수도 있다. 즉 오랜 기간에 걸쳐 관리를 해야 하고, 개발자와 관리자, 기업 소유권에 변화가 있는 경우에는 충돌을 최소화 해야 한다. (구조재편이 있는 경우, 개발자들이 미래에 배치될 다른 클라우드에 충분히 접근할 수 있는지 고려해야 한다.)
 
따라서 첫 번째 단계로 클라우드 지형 전반에 걸쳐 어떤 데이터 요소를 옮기고 클래스를 다시 팩터링할 지 파악해, 특정 애플리케이션에 가장 적합한 아키텍처를 판단해야 한다.
 
다음 주에도 클라우드 환경에서의 코딩과 관련해 더욱 깊게 살펴볼 예정이다.
 
*David Taber는  <세일즈포스닷컴의 성공 비밀(Salesforce.com Secrets of Success)>이라는 책의 저자이자, 세일즈로지스틱스(SalesLogistix)의 CEO다.
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.