[아키텍처 저널 번역] 21권 소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항 #2/3
지난 4월 20일에 올린 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항" 첫번째 번역물에 이어, 두번째 번역 부분을 올려 여러분의 피드백을 받습니다.
지난번 첫번째 번역 부분은 아래에서 확인할 수 있습니다.
https://blogs.msdn.com/eva/archive/2010/04/20/21-1-3.aspx
이번 두 번째 번역 부분은 S+S가 가져오는 기업내 아키텍처 관점에서의 변화를 지난 번의 엔터프라이즈 아키텍처에 이어 인프라 아키텍처, 소프트웨어 아키텍트의 다양한 관점에서 고찰하는 내용입니다.
여러분의 피드백을 기다리며..
-------------------------------------------------
소프트웨어아키텍처 , 통합설계
별개로 존재하는 엔터프라이즈 애플리케이션은 거의 없다. 대다수의 애플리케이션은 다른 애플리케이션과 연결되어 있으며, 데이터, 기능 및 프레젠테이션 통합과 같은 다양한 기술을 통해 상호 연결되는 복잡한 시스템을 형성한다.
대부분의 경우, 조직은 다양한 통합 기술을 사용한다. 그 결과 여러 시스템이 긴밀하게 결합되어(tightly coupled), 분리하거나 외부 기능으로 대체하는 것이 어려워진다. 일반적으로 이러한 경우, 조직은 서브 시스템내에 일부 기능들을 대표하는 Course-Grained Façade를 구축하거나, 레거시 애플리케이션과 서비스(내부 혹은 외부에서 호스팅되는 서비스)를 연동시키는 통합 기술을 채택한다.
데이터 계층에서 통합하고 외부 애플리케이션이 내부 애플리케이션과 동일한 데이터를 사용하도록 하는 경우, 조직은 마스터 데이터의 위치 등 다양한 요소를 고려해야 한다. 읽기 전용 데이터 또는 참조 데이터의 경우, 밀어넣기 또는 끌어오기 (push-or-pull) 복제 기술을 사용해 데이터를 동기화할 수도 있다. 비즈니스 또는 트랜잭션 데이터의 경우에는 다른 기술을 고려해야 한다.
SOA 기반의 기능성 비즈니스 서비스를 사용하는 조직은 이러한 서비스를 클라우드로 이동시키는 것을 고려해볼 수 있다. 이에 대한 자세한 내용은 다음 섹션에서 다루고 있다. 그러나 어떤 경우에는 비즈니스 애플리케이션을 서비스 계약 기반 클라이언트(service contract-driven clients)와 서비스 공급자 구성 요소(service-provider components)로 쉽게 분류할 수 없을 수도 있다. 예를 들어, 시스템에 복잡한 레거시 프로세스와 휴먼 워크플로가 포함되어 있는 경우를 들 수 있다. 이런 경우에는, 워크플로를 클라우드로 이동시켜 워크플로가 온라인 및 오프라인 시나리오를 모두 확장할 수 있는 하이브리드 운영 모드를 지원할 수 있다.
트랜잭션을 관리하는 전통적인 단일 접근방식은 더 이상 가능하지 않을 수도 있으며, 조직에서는 데이터 일관성을 보증할 수 있는 대체 모델을 검토해야 한다. 이와 관련된 프로세스는 이 문서의 정보 설계 섹션에서 자세히 설명하고 있다.
특히 최근에 개발된 애플리케이션은 기능 통합에 서비스 지향 접근 방식을 사용하고 있을 가능성이 높으며 이 경우, S+S 채택이 보다 간편해진다. 공용 서비스 디렉터리를 사용하는 애플리케이션은 서비스 디렉터리에서 대상 서비스의 위치 및 바인딩 요구 사항을 업데이트할 수 있으며, 클라이언트는 스스로를 동적으로 다시 구성할 수 있다. 이는 동일한 계약을 가지고 있는 서비스가 사외로(off-premises) 재배치된 경우에도 마찬가지이다. 그러나 많은 경우에, 클라이언트는 기대와 다른 계약(contract)을 가지고 있는 서비스와 상호 작용해야 한다. 이 경우, 중개자가 클라이언트의 요청을 가로채서 새로운 대상 서비스가 원하는 형태의 요청으로 변형시킬 수 있는 서비스 가상화 기술2을 사용하여 문제를 해결할 수 있다.
조직이 애플리케이션을 클라우드로 이동시키면서 여러 서비스 공급자가 제공하는 서비스에 더욱 의존하게 되고, 기존 중앙 관리식 메시지 버스3 기술 또한 여러 요구 사항을 충족시키기에 불충분해짐에 따라 조직은 점차 인터넷 서비스 버스 기술을 고려하게 되었다.
소프트웨어아키텍처 , 애플리케이션설계
지난 10년간 많은 조직들이 중앙 집중식 메인 프레임 기반 애플리케이션에서 서비스 지향 및 인터넷 지향 아키텍처 방식에 근거한 분산 컴퓨팅 모델로 이동했다. 서비스 지향 원칙에 따라 설계된 애플리케이션은 S+S 애플리케이션의 채택 또는 통합을 위한 견고한 기반을 제공한다.
그러나 이것만으로 충분할 것이라고 단정지으면 안된다. 원격 서비스는 주로 이를 사용하는 조직에서 제어할 수 없는 곳에 위치한다. 따라서 클라이언트 애플리케이션을 개발하는 조직은 원격 서비스가 실패했을 경우를 대비해 애플리케이션이 더 큰 복원력을 갖도록 설계해야 한다. 참조 데이터를 캐싱하거나, 축적 전송 방식(store-and-forward) 등의 기술을 사용하면 서비스 공급자의 서비스 실패시에도 클라이언트 애플리케이션은 영향을 받지 않게 된다. 또한, 원격 서비스와의 상호 작용시 전통적인 단일 트랜잭션(atomic transaction)이 더 이상 적합하지 않을 수 있기 때문에 개발자들은 보상 트랜잭션(compensating transaction) 등과 같은 대안을 고려해야 한다.
서비스가 외부로 이동함에 따라 원격 서비스에 접근하는 시간도 늘어날 수 있다. 애플리케이션 개발자는 비동기 메시징 기술 등 대체 메시징 전략을 고려할 필요가 있다. 서비스 공급자는 대부분 비동기 메시징 전략을 채택해 시스템의 확장성을 높이고자 한다.
클라이언트 애플리케이션이 대체 서비스 공급자의 가용여부 및 응답시간에 따라 이들과 상호 작용할 수 있도록 하려면, 클라이언트 애플리케이션에서 이러한 서비스의 위치를 동적으로 확인하고 상호 작용에 사용된 프로토콜을 수정할 수 있어야 한다. 외부 서비스에 의존하는 클라이언트 애플리케이션 또는 서비스가 많은 대규모 조직의 경우, 일관된 관리를 위해 구성 정보를 중앙집중화해야 한다.
S+S 애플리케이션은 종종 단일 시스템에서 다중 사용자를 지원하기 때문에, 변경 관리시 보다 많은 주위를 요구한다. 애플리케이션이 실행시에 거의 100퍼센트에 가까운 가용성이 요구되는 경우에는 업그레이드를 위한 공간이 거의 없기 때문에 문제가 더 복잡해진다. 업데이트 도메인4을 사용하는 애플리케이션 업그레이드 또는 롤링 업데이트의 경우, 보다 신중한 애플리케이션 설계가 필요하다. 이 때, 서비스 공급자에게는 서비스에 고가용성 배포 패턴에 대한 지원을 포함시킬 것이 요구된다.
서비스의 구현 또는 설계 변경은 서비스 소비자에게 예기치 못한 영향을 끼칠 수도 있으며, 클라이언트 애플리케이션은 정상적인 동작을 위해 지속적인 업데이트가 필요하게 된다. 또한, 서비스가 클라우드 서비스 사업자에 의해 제공되는 그러한 S+S 시나리오하에서 클라이언트가 수정되어야 할 수도 있기 때문에 명확한 버전 관리 전략이 필수적이다. 어떤 경우에는, 웹 서비스 중개자가 이러한 변경에 대해 방어할 수 있는 세이프가드 기능을 제공해, 메시지 변환이 발생해도 클라이언트에게는 일관성있게 메시지가 전달되도록 지원한다. 서비스 공급자는 반드시 클라이언트의 사용 시나리오에 대한 완벽한 이해를 갖추어 서비스 계약(contract) 또는 동작(behavior)의 변경이 예상치 못한 클라이언트 동작의 변경으로 이어지지 않도록 해야 한다.
S+S 애플리케이션을 테스트할 때도 주의가 필요하다. 클라이언트 애플리케이션에는 개발, 사용자 수용, 성능 테스트 등 다양한 환경이 실제 운영 환경과 동일하게 구성되어 있다는 확신 하에, 이들 다양한 환경을 시뮬레이션할 수 있는 기능이 반드시 있어야 한다.
관심의 분리(Separation of concern)처럼 확립된 원칙은, 애플리케이션에 최소한의 영향을 미치면서 새로운 인증 및 권한 부여 메커니즘을 허용할 수 있기 때문에, 애플리케이션의 보안 모델을 더욱 간편하게 변경할 수 있도록 지원한다.
아키텍트는 일반적으로 ‘이 조직에서만 이 애플리케이션을 사용한다’는 가정 하에 애플리케이션 및 관련 데이터 저장소를 설계해 왔다. 그러나, S+S 애플리케이션 설계에서는 더 이상 이러한 가정을 할 수 없으며 아키텍트는 반드시 데이터베이스 설계시 확장을 위해 다양한 접근 방식과 다중 고객 지원(multi-tenancy)을 고려해야 한다.
소프트웨어아키텍처 , 정보설계
정보 설계는 애플리케이션과 서비스에서 사용되는 데이터의 구조, 관리, 저장소 및 배포와 관련이 있다. 전통적으로 엔터프라이즈 애플리케이션은 데이터 일관성, 트랜잭션 안정성 및 증가된 처리량에 초점을 맞춰왔으며, 안정적인 데이터베이스를 설계하기 위한 방법으로 ACID(원자성, 무결성, 일관성, 영속성) 원칙을 사용하는 관계형 데이터 모델과 관계형 DBMS(데이터베이스 관리 시스템)에 주로 의존해 왔다. 하지만 이제 S+S를 채택함에 따라 조직은 정보 설계 프로세스를 다른 시각에서 생각해볼 필요가 있다.
SOA의 채택은 원본 데이터를 호스팅하는 플랫폼과는 별도로 데이터에 대한 유비쿼터스 접근이 제공되는 DaaS(Data as a Service) 개념을 이끌어 냈다. 이 기능을 사용하려면 데이터 공개에 따른 개인 정보 보호 및 보안 관련 영향을 고려하면서도, 데이터의 청결도와 무결성을 확인 및 검증할 수 있는 운영을 위한 데이터 저장소가 필요하다.
클라우드에서 실행하게 될 서비스 설계시 서비스 공급자는 단일 시스템 상의 다중 고객을 지원하는 (multi-tenant) 애플리케이션과 관련된 요구 사항을 고려해야 한다. 단일 시스템 상의 다중 고객을 지원하는 애플리케이션에는 유연하고 안전하며 버전 관리가 되는 대안 스키마 설계가 필요하다. 또한, 일부 영역에서는, 사용자별 스키마 변경에는 더 큰 유연성을 제공하면서 데이터 중복 관리 및 발생 가능한 불일치 문제는 애플리케이션으로 넘기는 범용 비관계형 데이터 모델로 교체하는 움직임이 발견되고 있다. 점차 더 많은 시스템 이 반구조화(semi-structured)되거나 구조화되지 않은 데이터(문서 또는 미디어)를 처리하고 있다. 이러한 데이터는 구조화된 관계형 데이터 모델에 적합하지 않기 때문에 이름-값 저장소(name-value store) 및 개체 저장소(entity store)와 같은 범용 데이터 모델이 필요하다. 큐 지원, 구조화되지 않은 대용량 데이터에 대한 BLOB 제공, 제한된 관계형 의미 체계를 가지고 있는 테이블 제공 등이 유용하다.
서비스와 기반 데이터 구조는 과거에 비해 훨씬 더 커진 트랜잭션을 지원하도록 설계되어야 하고, 더욱 커진 데이터 볼륨을 관리할 수 있어야 한다. 따라서 스키마 설계와 데이터 분할 전략(data-partitioning)에도 변화가 필요하다. 분할 전략은 근간이 되는 데이터베이스의 확장을 지원해야만 하는데 이는 주로 기능 구분 또는 수평 분할을 통해 이루어진다. 그러나 이러한 전략은 최상의 성능을 얻을 수 있는 능력에 영향을 미칠 수 있다. 이는 왜 일부 고성능 시스템이 ACID 안정성5에서 BASE(Basically Available, Soft State, Eventually Consistent) 일관성6으로, 그리고 물리적 분할 스키마에서 디커플링(decoupling) 논리적 분할로 이동하고 있는 지를 설명해 준다.
인프라아키텍처
일반적으로 컴퓨팅 인프라는 기업 IT 투자에서 상당 부분을 차지한다. 클라우드 컴퓨팅 시대 이전에는 인프라에 필요한 데스크톱, 서버 하드웨어, 저장소 장치 및 네트워크 장치를 구입하는 데 막대한 비용을 들일 수밖에 없었다. 또한, 대규모 기업에서는 하드웨어와 서비스 인력을 호스팅하기 위해 자체 데이터 센터를 구축하고 운영하는 데 투자했을 수도 있다.
이제 기업은 IaaS를 통해, 사설 클라우드 서비스와 다양한 형태의 가상화 기술을 통해 많은 대안책을 얻어 자사의 IT 인프라 투자 전략을 재평가할 수 있게 되었다.
IaaS 덕분에 기업은 트랜잭션 기반 또는 가입(subscription) 기반 지불 방식을 사용해 컴퓨팅 리소스 사용에 대한 요금을 지불할 수 있다. 또한, 동적 확장이 가능한 인프라는 기업이 비즈니스 요구에 따라 인프라 지출을 신속하게 조정할 수 있도록 지원한다. 기업의 인프라 예산이 계산(연산) 사이클 및 저장소에 대한 요구 변동에 따라 늘리거나 줄일 수 있는 운영비용으로 점차 전환됨에 따라, 기업은 새로운 재정적 유연성을 얻게 된다. 이러한 인프라 서비스는 계절적으로 성수기 또는 하루 중 피크타임에 계산 요구가 최고조를 기록하고 그 외의 경우에는 리소스 사용량이 떨어지는 전자 상거래 사이트에 유용하다. IaaS는 컴퓨팅 리소스를 추가하거나 줄이는데 있어서, 인프라 하드웨어에 남아돌게 혹은 부족하게 투자하지 않도록 함으로써 IT 아키텍트의 용량 산정을 용이하게 한다.
뿐만 아니라, IaaS를 사용하면 새로운 온라인 비즈니스 서비스를 더욱 빨리 시작하고 테스트할 수 있다. 전통적인 방식에서는 새로운 온라인 서비스를 시도할 때 소요되는 하드웨어 초기 투자에 대한 비즈니스 중요성을 판단하는 작업을 하게 된다. 더욱 어려운 점은 시범 서비스를 배포하기 위해, 회사 네트워크 및 방화벽을 재구성 하기 위한 내부 IT 부서와의 싸움이다. 사내 정책-준수 문제는 새로운 온라인 비즈니스 시작을 지연시키는 단골 원인이었다. 하지만 이제 IaaS를 통해 이러한 프로세스를 신속하게 처리할 수 있고, 인프라와 관련된 복잡한 문제를 줄일 수 있다.
사용자 데스크톱은 서비스 형태로 제공될 수 있으며, 사용자는 어느 곳에서든 가상화 서비스에 네트워크 연결이 되어 있다면 이러한 사용자 데스크톱을 이용할 수 있다. 서버 가상화 기술은 기업에서 서버 하드웨어 공간을 줄이는 데 크게 기여한다. IaaS를 통해 기업은, 클라우드 인프라에서 실행되는 가상 서버 인스턴스를 비즈니스 요구에 맞추어 복제함으로써 인프라 비용을 즉시 절감할 수 있다.
클라우드 인프라 관련 서비스는 이전에는 불가능했던 많은 혜택을 제공한다. 하지만 이 같은 혜택을 그냥 얻을 수 있는 것은 아니다. IT 아키텍트는 하이브리드 S+S 인프라를 계획하고 구현하는 과정에서 가용성, 확장성, 보안, 안정성 및 관리 효율성 등과 같은 설계 고려 사항에 계속해서 무게를 두어야 한다.
인프라 서비스가 중단되면 결국 애플리케이션 서비스의 가용성에 영향을 끼친다. 상위 수준 애플리케이션 서비스의 상당수가 아웃소싱된 클라우드 인프라에서 실행될 수 있기 때문에 서비스 공급자 인프라에서 발생한 장애가 하나 이상의 비즈니스 기능에 영향을 끼치고 결과적으로 여러 분야에서 생산성 저하나 수익 손실 등을 야기한다. 따라서, 기업은 자신의 인프라 서비스 공급자가 이러한 장애를 해결하도록 지원할 수 있는지 알고 있어야 한다. 어떤 기업은 다수의 인프라-서비스 공급자를 이용하여, 주 공급자에서 서비스 장애가 발생해도 보조 공급자의 컴퓨팅 리소스를 활성화할 수 있다.
중앙 집중식 호스팅 인프라를 통해 데스크톱 가상화 기술이 제공될 때에는 솔루션의 확장성 및 성능을 고려해야 한다. 데스크톱 가상화 서비스는 주로 직원들이 로그온해 회사 업무를 수행하는 근무 시간에 부하 사용량이 가장 많으며 근무 시간 이후에는 점차 줄어든다. 동적으로 확장 가능한 컴퓨팅 인프라 서비스에 가상화 기술을 결합하는 것은 조직의 계산(연산) 요구가 변동하는 경우에 좋은 접근 방법이 될 수 있다.
인프라 보안은 언제나 기업을 보호하는 심층적인 방어 수단으로 이용되어 왔다. 예를 들어, 일부 기업에서는 인트라넷을 통한 기계간 통신을 보호하기 위해 IPSec을 사용한다. IPSec에서는 방어 계층을 추가해, 회사 소유가 아닌 컴퓨팅 장치로부터의 인가되지 않은 정보 접근을 차단해 회사 자산을 보호할 수 있다. 기존 인프라 수준의 보안 메커니즘을 클라우드 인프라 서비스에서 계속해서 사용하기 위해서는 조직의 네트워크, 공개 키 및 이름 확인(name –resolution) 인프라를 다시 구성해야 할 수도 있다.
서버 인프라가 가상화된 인스턴스로 실행되기 위해 배포되면, IT 아키텍트는 하나의 서비스 실패가 해당 서비스만 영향을 주고 다른 가상화된 서비스들에게 영향을 미치지 않도록, 각 가상 인스턴스를 각 단위(unit) 서비스로 분리, 조직하는 것을 고려해야 한다. 이와 같은 인프라 설계 관행은 상위 애플리케이션 서비스를 원자 단위로 배포하여, 다른 가상화된 단위 서비스가 운영상에 실패를 겪을 때 해당 단위 서비스를 치환할 수 있게 된다.
상위 수준의 애플리케이션이 하이브리드 S+S 인프라에 걸쳐 배포되는 경우, 인프라 오류로 인해 발생하는 애플리케이션 실패를 디버깅하는 것이 어려울 수 있다. 사내에서 일반적으로 사용하는 네트워크 모니터링 및 추적 도구는 기업 및 서비스 공급자의 방화벽을 통과하지 못할 수도 있다. 따라서, 기업은 클라우드 인프라 공급자에게 클라우드 인프라 트래픽을 검사할 수 있는 진단 도구를 요청할 수 있다.