image_2

아키텍처 저널 21권 중 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계" 아티클 한글 번역본이 MSDN 싸이트에 공개되었습니다.
링크 1 : http://msdn.microsoft.com/ko-kr/architecture/aa699437.aspx
링크 2 : http://msdn.microsoft.com/ko-kr/architecture/aa699439.aspx

아울러 최종 번역물 PDF 버전도 위 링크 1에서 다운로드 받을 수 있습니다.

다음 번역물은 아키텍처 저널 19권 중 "Mapping Applications to the Cloud”입니다.

Posted by 장현춘

댓글을 달아 주세요

image_2

지난 4월 26일 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항" 두 번째 번역물을 올린데 이어, 오늘 그 마지막 남은 부분을 올립니다.

지금까지의 번역부분은 아래에서 확인할 수 있습니다.
첫번째 #1/3 : http://kingcrap.com/138
두번째 #2/3 : http://kingcrap.com/140

이번 마직막 부분을 포함하여 전체 내용을 PDF 버전으로 다운로드 할 수 있는 링크는 해당 웹 페이지가 MSDN에서 한글화되면 바로 제공할 예정입니다.

-------------------------------------------------------

보안
인터넷이 상거래 및 고객 서비스의 주요 채널로 사용되기 시작한 1990년대 후반부터, 보안은 엔터프라이즈 컴퓨팅의 가장 핵심적인 영역으로 자리매김하였다. 오늘날과 같은 S+S 컴퓨팅 시대에도, 비즈니스 웹을 지원하기 위해 개발된 보안 관련 베스트프랙티스와 기술은 여전히 의미가 있으며 그 중요성은 더욱 커졌다.
  S+S 보안은 ID 프로비저닝과 권한 부여에서부터 내부 시스템과 클라우드 시스템간의 Enterprise Single Sign-On 지원, 전송 중인 데이터와 대기 중인 데이터 보호, 그리고 클라우드 플랫폼에 배포된 애플리케이션 코드를 강화해 맬웨어 및 침투 공격에 대항하는 것 등 광범위한 주제를 다룬다.
  사용자 프로비저닝은 사용자 ID 수명 주기를 관리하는 데 있어 주요 과제이다. 기업에서 클라우드 서비스를 채택하면 클라우드 서비스 공급자와 함께 기업 사용자를 프로비전하는 방법을 연구해야 한다. 또한, 사용자의 조직 내 담당 업무가 변경되면 ID 관리 프로세스에서는 클라우드 서비스에서 사용자의 애플리케이션 권한이 맞게 조정되었는지 확인해야 한다. 사용자가 퇴사하는 경우 클라우드 서비스에 대한 접근도 비활성화되어야 한다. 또한, S+S와 관련된 사용자 프로비저닝을 가급적 최대한 자동화하여 서비스 접근 이슈로 인해 직원의 생산성이 저하되는 것을 방지하고 수동 프로비전 오류를 줄여야 한다.
  클라우드 서비스를채택한 많은 기업에서 우선순위가 높은 주요 요구 사항은 바로 기존 회사 ID를 활용하는 SSO(Single Sign-On) 기능이다. 그 이유는 명백하다. SSO는 최종 사용자에게 편리하고 보다 나은 애플리케이션 환경을 제공하고, 여러 보안 자격 증명을 관리함에 따라 생겨나는 보안 이슈를 줄여줄 수 있다. SSO를 성공적으로 구현하기 위해서는 먼저 기업 내 여러 ID 시스템을 구조적으로 개선하고 통합해야 한다. 또한, 새로운 ID-페더레이션 기술은 기존 사용자 자격 증명 및 권한의 이식성을 개선할 수 있다. 이 기술이 클라우드 서비스 공급자와 함께 비즈니스를 함에 있어서 SSO 전략의 핵심이 되어야 한다는 것은 두말할 나위 없다.
  모든 비즈니스에서 데이터는 매우 중요하다. 따라서 기업은 S+S에서도 비즈니스 정보 보안 유지에 주력해야 한다. 인터넷을 통해 데이터를 전송하고 정보가 클라우드 서비스 공급자에게 저장된다면, 데이터와 관련된 핵심 보안 문제는 기밀성과 무결성이다. 암호화와 서명 등과 같은 보안 방법을 사용하면 권한이 없는 사람이 데이터를 보거나 수정하는 것을 방지할 수 있다.
  인터넷 액세스가 가능한 클라우드 컴퓨팅 플랫폼에서 개발 및 호스팅되는 엔터프라이즈 애플리케이션과 관련된 보안 전략에는 새로운 보안 위협, 노출 및 완화 접근 방식이 반드시 들어있어야 한다. 잠재적인 보안 위협은 인터넷 해킹으로 인한 서비스 중단에서부터 애플리케이션 코드 내의 고유한 비즈니스 로직이나 거래 관련 기밀 콘텐츠 등의 검색 및 도난 위험에 이르기까지 다양하다. 애플리케이션을 클라우드 컴퓨팅 플랫폼에서 실행하기 위해 전달할 때 보안을 고려한 설계(Secure by Design) 관점의 보안 검토 프로세스를 진행하는 것이 더욱 필수불가결해졌다.
  마지막으로, IT 의사 결정자와 구현 전문가는 어느 시스템이든지 가장 약한 고리가 바로 그 시스템의 보안 수준이라는 점을 염두에 두어야 한다. 따라서, 기업은 항상 클라우드 공급자를 이용하는 데서 발생하는 새로운 위험 노출 문제를 조사하고 이를 완화할 수 있는 적절한 조치를 취해야 한다. 만약 가장 약한 고리가 아웃소싱된 공급자라면, 이로 인해 회사가 조치한 여러 보안 장치들이 무용지물이 될 수도 있다.

관리
IT 관리에서는 비즈니스 목표를 달성하기 위해 기업에서 사용하는 소프트웨어 애플리케이션 및 서비스의 종단간(end-to-end) 수명 주기를 다룬다. 수명 주기 단계에는 일상적인 비즈니스 업무를 지원하는 하드웨어, 네트워크, 인프라, 소프트웨어, 서비스로 구성된 IT 포트폴리오를 계획, 구현, 운영 및 지원하는 작업이 포함된다.

일반적으로 IT 관리에는 다음 업무가 포함된다.
1. 프로젝트 구현 및 운영 프로시저를 안내하는 정책 정의
2. 실행을 체계화하는 프로세스 구축
3. 책임이 명확하게 정의된 조직 역할 확인
4. IT 관리 작업 자동화 도구의 구현 및 유지 관리

처음 세가지 활동에 대한 모범 사례는 ITIL(Information Technology Infrastructure Library) 7 및 MOF(Microsoft Operation Framework) 8와 같은 기존의 산업 관리 프레임웍에서 찾을 수 있으며, 아키텍트 원칙과 IT 관리 솔루션은 IT 운영 자동화에 대한 주요 구성 요소이다.
  S+S는 기술 관점에서뿐만 아니라, IT 역할, 책임소재, 운영 프로시저, 소프트웨어와 서비스 운영 및 사용을 총괄하는 정책의 관점에서, 회사 방화벽을 뛰어 넘어 기업 IT 환경을 그 이상으로 확장한다.
  예를 들어, SaaS 공급자에게 아웃소싱된 애플리케이션은 사용 기업이 아닌 서비스 제공사의 관리자와 운영자에 의해 유지 관리된다. S+S에서는 전통적인 IT 역할과 책임이, SLA에 명시되어 있는 임무에 대해 계약 상의 책임을 지는 단일 서비스 공급자의 역할로 축소되어야 할 수도 있다. 또한, 강력한 법적 책임 조항을 명확하게 정의하여 서비스 공급자가 맡은 책임을 충분히 이행하지 못해 발생하게 되는 부정적인 결과를 방지해야 한다. 마찬가지로, 사용자 이슈와 기술 문제를 해결하기 위한 IT 관리 프로세스도 서비스 공급자가 담당한다. 서비스 중단 문제를 최소화할 수 있도록 명확한 상부 보고 절차(escalation procedure)를 만들고 효과적인 통신 채널을 기업의 최종 사용자 지원 프로세스에 통합시키는 작업은 필수적이다.
  기업에서 더 이상 아웃소싱된 서비스의 구현 세부 정보를 제어하지는 않지만, 사내 조직과 고객 간의 책임 및 신뢰에 영향을 끼칠 수 있는 서비스 공급자의 메커니즘과 프로시저는 알고 있어야 한다. 일부 서비스 공급자는 SAS 70처럼 감사 표준을 따르는 문서를 제공한다. 기업은 이를 통해 서비스 공급자에서 이루어지고 있는 IT 관리 관행이 비즈니스 및 업계의 요구 사항을 만족하는지 여부를 판단할 수 있다.
  기업에서는 클라우드에서 실행 중인 서비스를 모니터링하기 위한 IT 관리 솔루션 배포 계획을 세워야 한다. 운영 전략에서는 성능 지표 및 관리 규정을 정의해 외부 서비스의 성능 및 가용성을 파악할 수 있도록 해야 한다. 운영 모니터링 시스템은 관리측면의 알림과 경고를 발생시켜 모든 서비스 이상을 조기에 감지할 수 있도록 해야 한다.
  또한, 아웃소싱 서비스 공급자와 클라우드 서비스를 개발 중인 기업은 운영 관련 서비스 인터페이스를 구현해 사용자 계정 프로비저닝, 사용자 사용 권한 설정, 서비스 실행 상태 변경, 데이터 백업 시작 등 관리 업무를 자동화해야 한다.
  요컨대, S+S에서 IT 관리는 비즈니스 운영 지원을 위해 필요한 IT 기능을 계획하고 제공하고 운영하는 완벽한 종단간 전략을 지속적으로 구현해야 한다. 기존 IT 관리 프레임워크도 계속 사용된다. 아울러 기업은 외부 운영 프로세스, 인력 및 도구를 기존 IT 관리 활동에 통합할 때 발생할 수 있는 영향에 대해서도 신중하게 고려해야 한다.
  외부 서비스 공급자가 시스템에 대한 책임을 가지고 있다면, 조직은 인력, 프로세스 및 기술에 대한 직접적인 통제력을 상당 부분 놓치게 된다. 그 대신, 조직은 명확하게 정의하고 상호 합의한 SLA, 정책 및 프로시저, 주요 성과 지표, 관리 규칙, 서비스 제어 인터페이스를 통해 효과적인 관리를 할 수가 있어야 한다. 운영을 위한 설계(design for operation)는 관리 가능한 소프트웨어 및 서비스를 제공할 수 있는 아키텍처의 핵심이다. 궁극적으로 클라우드 서비스 공급자에게 운영 세부 정보를 아웃소싱함으로써 기존 IT 인력은 보다 큰 비즈니스 가치를 제공하는 우선 순위가 높은 새로운 컴퓨팅 프로젝트에 집중할 수 있어야 한다.

운영
운영은 IT 관리 수명 주기의 특정 단계를 구성한다. 여기에는 필수 서비스의 품질을 보장하기 위한 소프트웨어 및 서비스 모니터링, 문제 발생 시 이루어지는 정확한 조치, 사용자 문제 해결을 위한 고객 헬프 데스크 관리, 데이터 백업과 같은 반복적인 작업 수행, 지속적인 서비스 실행 상태 유지 관리 등 일상적인 활동이 포함된다. 운영 프로시저는 IT 정책에 따라 이루어지며, 그 결과는 가용성과 응답 시간과 같은 정확한 시스템 및 애플리케이션 상태 메트릭스로 측정된다.
  예를 들어, MOF는 이러한 활동과 관련된 모범 사례 모델을 설명한다.
  기업이 S+S 전략을 채택한다면 IT 운영의 역할 및 책임을 아웃소싱하는 데 따르는 비즈니스 영향도 함께 고려해야 한다. 신뢰할 수 있는 클라우드 서비스 공급자와 확실한 SLA를 수립하여, 비즈니스 연속성, 신뢰성 및 사원과 고객의 만족도 등 주요 사안을 해결해야 한다.
  기업은 자사의 하이브리드 소프트웨어 및 서비스 환경을 위한 IT 운영에서 적극적인 역할을 수행해야 한다. 기업은 실행 세부 정보에 집중하기 보다는 모니터링 시스템을 적절히 도입해 아웃소싱된 서비스에서 발생하는 기술적인 문제를 감지할 수 있어야 한다. 또한, 문제 발생시 서비스 공급자가 가급적 빨리 해당 문제를 해결할 수 있도록 보장하는 운영 프로시저도 수립해야 한다.
  기업과 클라우드 서비스 공급자 모두 운영 모범 사례를 설계함으로써 S+S 운영 효과를 높일 수 있다. "운영을 위한 설계(design for operation)"에는 소프트웨어 및 서비스에 대한 계획, 제공, 운영의 과정을 아우르는 실행 규칙과 아키텍처가 요구된다. 아키텍트는 안정성, 일관성, 보안 및 기타 품질 요인에 침해가 발생했을 때의 애플리케이션내 전환지점을 인식하고, 애플리케이션에 계측 기능을 포함시켜 영향을 받은 이벤트가 발생 했을 때 모니터링 도구에 이를 알릴 수 있도록 해야 한다. 애플리케이션에 대한 성능 상태, 성능 카운터, 관리 이벤트, 로그, 가상 트랜잭션 등과 같은 아키텍처 공통사항 및 패턴은 실운영 환경에 내놓아도 손색이 없는 소프트웨어 및 서비스를 준비하는 데 도움이 된다.
  클라우드 서비스를 평가하는 동안 기업은 서비스 공급자가 표준 IT 모니터링 솔루션에서 사용되는 운영 서비스 인터페이스 및 애플리케이션 성능 정보를 제공할 수 있는지 판단해야 한다. 또한, 기업은 외부 서비스 장애가 다른 부분까지 전파되지 않도록(compartmentalized) 자사 시스템을 설계하여 해당 서비스에 의존하는 솔루션 부분만 영향을 받을 수 있도록 해야 한다. 이러한 운영 전략은 비즈니스 연속성을 극대화할 수 있다

결론
S+S는 누구에게나 새로운 기회를 보장한다. 또한, 비즈니스와 IT 자산을 최적화할 수 있는 새로운 옵션뿐만 아니라, 비용 절감, 생산성 향상, 혁신, 새로운 시장 진출 등 다양한 혜택을 제공한다.
  클라우드 컴퓨팅을 사용하여 현재의 내부(on-premises) 기술 포트폴리오를 확장하려면 다음 세 가지 주요 방법, 즉 클라우드 소비, 클라우드 이용 및 클라우드 수용을 고려해야 한다.
* 클라우드 소비(Consume the Cloud)는 기본적으로 기업에서 애플리케이션과 서비스를 타사 클라우드 공급자에게 아웃소싱하는 것을 말한다. 기업이 온라인 서비스를 이용하도록 만드는 주요 비즈니스 동인은 IT 비용을 절감하고 귀중한 대역폭을 핵심 비즈니스 기능을 지원하도록 재조정할 수 있다는 데 있다. 클라우드 공급자는 규모의 경제(economy of scale)에 기반해 더욱 저렴하고 우수한 서비스를 제공할 수 있게 되면서, 고객에게 비용 절감 및 효율성을 보장할 수 있다. Microsoft 고객의 경우, Exchange Online과 Office SharePoint Online으로 구성된 Microsoft Business Productivity Online Suite, CRM Online, Live Meeting 서비스가 대표적이다.
* 클라우드를 이용(Use the Cloud)하면 기업은 클라우드 플랫폼과 인프라 서비스를 활용하고, 하드웨어 및 인프라 소프트웨어에 대규모 선행 자금을 투자하지 않고도 필요할 때 컴퓨팅 및 저장소 용량을 무제한적으로 이용할 수 있다. 이러한 유틸리티 컴퓨팅 모델을 사용하면 동적 비즈니스 요구를 충족할 수 있는 IT 리소스를 더욱 신속하게 얻을 수 있다. 또한, 클라우드 서비스를 사용하면 기존의 회사 인프라에 아무런 영향도 끼치지 않고, 웹 기반 애플리케이션의 배포 속도를 높여 고객 및 파트너와의 의사소통을 개선하는 새로운 비즈니스 이니셔티브를 지원할 수 있다. Microsoft 고객의 경우, Windows Azure와 SQL Azure가 대표적이다.
* 클라우드 수용(“Embrace the Cloud”)은 기업이 고객과 파트너에게 클라우드 서비스를 제공하도록 하는 기술을 채택할 때 발생한다. 이 모델은 핵심 비즈니스 자산을 정보 클라우드 서비스로 변형시켜 자사를 경쟁사와 차별화 시키는 서비스 지향 기업에서 가장 잘 활용하고 있다. Microsoft 고객의 경우, BizTalk Server Enterprise Service Bus Toolkit과 같은 내부 기술을 사용하여 데이터 피드를 통합하고, 클라우드 서비스를 통해 정보 교환을 처리하는 워크플로를 오케스트레이션할 수 있다.

<별책 1. 복합 애플리케이션(Composite Application) 위한 설계 시점의 서비스의 선택 >
Shrikant Mulik, Manish Godse

조직에서 SOA을 채택하면 애플리케이션을 맨 처음부터 구축하지 않고도, 서비스를 재활용함으로써 새로운 복합 애플리케이션 개발할 수 있다. 여기에 사용되는 서비스는 조직 내부에서 사용 가능한 것일 수도 있고, SaaS(Software as a Service) 등과 같이 외부 업체로부터 제공된 것일 수도 있다.
다음은 설계시 웹 서비스를 선택하는 9단계 접근 방식이다.
1. 웹 서비스 후보를 식별한다.
2. 선택 매개 변수를 설정한다.
3. 매개 변수를 제거 매개 변수와 평가 매개 변수로 구분한다.
4. 선택된 매개 변수에서 사용 가능 모든 서비스에 대한 데이터를 수집한다.
5. 제거 매개 변수에 따라 서비스 후보를 탈락시킨다.
6. 평가 매개 변수에 가중치를 부여한다.
7. 후보 자격이 있는 각 서비스에 1-5점까지 점수를 매긴다.
8. 각 서비스의 종합 점수를 가중 평균해 산출한다.
9. 최고 종합 점수를 보유한 웹 서비스를 선택한다.

한 애플리케이션 아키텍트가 어떤 글로벌 기업의 미국 지사에서 사용하는 품질 관리 시스템을 위한 복합 애플리케이션을 개발한 사례를 예로 들어 보겠다. 이 아키텍트는 감사 관리 기능을 제공하는 한 개의 웹 서비스를 선택해야 했다. 우선, 첫 번째 단계로 아키텍트는 다섯 개의 웹 서비스 후보를 찾았다. 그러고 나서 19개의 매개 변수를 설정한 후, 이를 아래와 같이 다섯 개의 카테고리로 나눴다.
1. 기능적 계약—작업 이름 및 각 연산에 대한 입출력 메시지의 세부 정보
2. 서비스 품질— 응답 시간, 처리량, 안정성, 사용 가능성, 접근성 및 상호 운용성
3. 서비스 보안—보안 프로토콜 (예: WS-Security), 디지털 서명 사용 (예/아니오), 암호화 사용 (예/아니오) 및 사용된 보안 토큰 유형 (예: X.509 및 Kerberos)
4. 기술적 세부사항—네트워크 프로토콜 (예: HTTP 및 JMS), 메시징 스타일 (RPC 또는 문서), 인코딩 스타일 (SOAP 인코딩 또는 리터럴), 컴퍼지션 속성 (원자성 또는 구성)
5. 상용서비스—일회성 비용, 연간 진행 비용 및 SLA(서비스 수준 계약) 약정

아키텍트는 이와 같은 19개의 매개 변수 가운데 기능적 계약과 서비스 보안 카테고리에 속하는 매개 변수를 모두 제거 매개 변수로 분류했다. 제거 매개 변수의 경우, 요구 사항이 명확하고 엄격하기 때문에 아키텍트는 이러한 요구 사항을 충족하지 못하는 서비스 후보를 쉽게 탈락시킬 수 있었다. 그 후, 아키텍트는 계속 작업을 진행해 각 서비스 후보의 모든 매개 변수와 관련된 데이터를 수집했다. 또한, 필수적인 WS-Security 프로토콜을 사용하지 않는 서비스와 요구된 디지털 인증을 사용하지 않는 서비스를 후보에서 탈락시켜야 했다. 다른 세 개의 서비스는 모두 제거 매개 변수에 따른 자격 시험에서 살아 남았다.
  이 애플리케이션 아키텍트는 그 다음 단계로 평가 매개 변수에 가중치를 부여했다. 아키텍트는 이해 관계자의 관점에서 매개 변수의 우선 순위를 정하는 데 계층 분석법(AHP)을 사용했다. 마지막 세 단계를 거치고 나자, 한 웹 서비스가 가장 높은 종합 점수를 얻었다. 그리고 바로 이 웹 서비스가 글로벌 품질경영시스템(Global Quality Management System) 개발 과정에서 선택되었다.
clip_image002
Shrikant Mulik(Shrikant.Mulik@lntinfotech.com)는 인도 뭄바이 L&T Infotech의 수석 컨설턴트이다.
Manish Godse(
manishgodse@iitb.ac.in)는 인도 붐베이 인도공과대학(IIT)의 연구학자이다.

<별책 2. 차세대 엔터프라이즈 아키텍처 구현을 위한 노력 >
작성자: Mario Fraiß and Erwin Zinser

앞으로 통합되고 및 자동화된 IT 인프라를 계획할 때에는 적응성, 유연성, 민첩성이라는 단어가 모든 고려 사항의 시작점이 될 것이다.
 
또한, 소위 말하는 인텔리전트 엔터프라이즈 아키텍처(IEA)를 구축하기 위한 필수 요구 사항으로 SOA 및 SOI와 같은 엔터프라이즈 아키텍처(EA)의 설계 컨셉을 신중하게 생각해봐야 한다. 그 다음 목표는 완전 자동화된 서비스와 사람에 의해 특정 지점에 놓여진 의사 결정 포인트 사이에 매시업을 만드는 것이다.
 
자동화된 IT 인프라 환경 내에서는 자동화 수준이 계속해서 증가하기 때문에 그 장점과 단점에 대해 논의하고 면밀히 조사해야 할 필요가 있다. 그렇지 않을 경우, 컴퓨터가 통제권을 갖게 되는 가상 시나리오가 현실이 될 수도 있다.
 
우리는 먼저, 이용가능한 비즈니스 지식을 지능적으로 사용해야 하며 그로 인해 얻어진 지적 자산을 비즈니스 및 그와 관련된 비즈니스 프로세스를 최적으로 지원하는 데 이용할 수 있다. 또한, 끊임 없이 변화하는 운영 및 인프라 관리와 관련된 요구 사항에도 대처해야 한다.
 
현대의 엔터프라이즈 아키텍처에 대한 이 새롭고 변화된 초점은 개발 기술 및 방법의 변경으로 이어져 미래 지향적인 엔터프라이즈 아키텍트에 의해 적용되어야 한다. (그림 1 참조)
 
복잡한 이벤트 처리 솔루션과 이와 관련된 이벤트 및 프로세스 모니터링 솔루션도 구축해야 한다. 이런 솔루션을 개발하면 문제 해결 프로세스를 독립적이고 동적으로 인스턴스화 할 수 있는 가능성이 높아진다. 이와 같은 이상적인 비전을 실현하기 위한 IEA 접근 방식을 소개한다.
 
이 접근 방식은 현재 고려중인 프레임웍의 각 레이어에, 현 시점의 EA 컨셉에 대한 분석과 서비스 지향 (service orientation) 개념을 일관성 있게 적용하는 것을 근간으로 개발되었다. 또한 기술 및 업계의 다양한 관점도 검토되었다.
 
그림 1에서와 같이 IEA의 핵심 구성 요소는 통신(Communication), 정보(Information), 인프라(Infrastructure) 및 프로세스(Process)이다. 이러한 하위 시스템은 전사적 핵심 역량에 초점을 맞추어 완벽한 기능 및 비즈니스 지원 환경을 보장해야 한다.

그림1. 기능형 기업 환경 개요
clip_image004

우리는 연구 프로젝트 과정에서 가상화된 가공 회사를 설정해 놓고 개념의 타당성을 확인하기 위한 기본 시나리오로 사용했다. 결론적으로, 우리는 IEA 설계 패러다임을 유도하는 이 접근 방식이 완벽하게 작동한다는 것을 입증할 수 있었다. 이러한 종합적인 결과는 최첨단 EA 설계 원칙의 성공적이고 선도적인 단계로 볼 수 있다.clip_image002
Mario Fraiß (mario@fraiss.at, http://www.mariofraiss.com)는 오스트리아의 기술 컨설팅 업체인 FRAISS – IT Consulting & Media Design 설립자이자 CEO이다. 이 업체는 Microsoft 기술을 기반으로 혁신적인 비즈니스 솔루션을 개발하고 있다.
Erwin Zinser (
erwin.zinser@fh-joanneum.at, http://www.entology.eu)는 오스트리아 그라츠에 있는 FH JOANNEUM University of Applied Sciences의 정보관리 학부, 엔터프라이즈 아키텍처 설계 교수이다.

감사의
Tim O’Brien, Rob Boucher Jr., Sharon Smith에게 감사의 뜻을 전한다.

리소스
Meier, J.D., Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat. Microsoft patterns & practices Application Architecture Guide 2.0: Designing Applications on the .NET Platform. 2008년 1월 15일(13장 “Service Layer Guidelines” 및 18장 “Services” 참조)

참조
1 Ross, Jeanne W., Peter Weill, and David Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business School Press, 2006.
2 Skonnard, Aaron. “Service Virtualization with the Managed Services Engine.” MSDN Magazine, May 2009.
3 Ferguson, Donald F, Dennis Pilarinos, and John Shewchuk. “The Internet Service Bus.” The Architecture Journal, MSDN, October 2007.
4 Khalidi, Yousef A. “Architecting Services for Windows Azure.” Professional Developers Conference 2008 (PDC2008), 2008, Slide 15.
5 Bain, Tony. “Is the Relational Database Doomed?” ReadWriteEnterprise, February 12, 2009.
6 Pritchett, Dan. “BASE: An Acid Alternative.” ACM Queue, July 28, 2008.
7 ITIL®. “Information Technology Infrastructure Library.” Offcial ITIL® Website, 2009.
8 Microsoft Corporation. “Microsoft Operations Framework.” Microsoft TechNet, 2009.

저자 정보
Fred Chong은 개발 도상국 시민들의 생활 및 생산성 표준을 향상하기 위해 휴대 전화, 소프트웨어, 클라우드 서비스를 통합하는 신규 및 신흥 시장 솔루션을 연구하고 있다.
Alejandro Miguel, Jason Hogg, Joshy Joseph은 CTO의 Worldwide Services Office 내 솔루션 엔지니어링 팀의 아키텍트이다.
Ulrich Homann은 WorldWide Enterprise Services의 수석 아키텍트이다.
Brant Zwiefel은 Microsoft Services— Service Lines 및 Marketing 팀의 비즈니스 아키텍트이다.
Danny Garber는 CTO 아키텍처 팀의 U.S. Azure Community 수석 아키텍트이다.
Scott Zimmerman은 미중부 애틀랜틱 지역에서 S+S에 대한 고객 상담을 제공하는 SOA 및 BizTalk 솔루션 아키텍트이다.
Stephen Kaufman은 Microsoft Consulting Services의 중간 계층 기술을 전문으로 하는 딜리버리 아키텍트이다.

Posted by 장현춘

댓글을 달아 주세요

image   지난 4월 20일에 올린 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항" 첫번째 번역물에 이어, 두번째 번역 부분을 올려 여러분의 피드백을 받습니다.

지난번 첫번째 번역 부분은 아래에서 확인할 수 있습니다.
#1/3 : http://kingcrap.com/138

이번 두 번째 번역 부분은 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 인프라에 걸쳐 배포되는 경우, 인프라 오류로 인해 발생하는 애플리케이션 실패를 디버깅하는 것이 어려울 수 있다. 사내에서 일반적으로 사용하는 네트워크 모니터링 및 추적 도구는 기업 및 서비스 공급자의 방화벽을 통과하지 못할 수도 있다. 따라서, 기업은 클라우드 인프라 공급자에게 클라우드 인프라 트래픽을 검사할 수 있는 진단 도구를 요청할 수 있다.

Posted by 장현춘

댓글을 달아 주세요

image

지난 번에 올렸던 "엔터프라이즈 소셜 컴퓨팅"은 현재 MSDN 싸이트에 공식적으로 번역물로 기재되었고 조만간 PDF 버전의 번역물 다운로드 링크도 추가될 예정이다.

아키텍처 저널 19권의 한글 MSDN 싸이트는 아래와 같다.
http://msdn.microsoft.com/ko-kr/aa699428.aspx
"엔터프라이즈 소셜 컴퓨팅"의 한글 번역 MSDN 싸이트는 아래와 같다.
http://msdn.microsoft.com/ko-kr/aa699425.aspx

이번부터 시작될 포스트는 아키텍처 저널21권에 수록된 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항"이라는 아티클 번역물에 대한 것으로 조금 긴 편이라 세 번에 걸쳐 리뷰가 끝나는 대로 포스팅을 할 예정이며 여러분의 피드백을 기다립니다.

 

------------------------------------------------------------------------------

요약

이 문서는 S+S(Software plus Services), 클라우드 컴퓨팅 또는 하이브리드 컴퓨팅으로 일컬어 지는 차세대 애플리케이션의 설계 패턴에 대한 Microsoft의 생각을 공유하기 위해 작성되었다. 여기에는 기업, 소프트웨어, 인프라 아키텍처 등 일반 아키텍처 도메인에 영향을 주는 S+S 아키텍처의 고려 사항과 패턴에 대한 견해가 실려 있다.

서론

많은 기업들이 체계적인 마스터 플랜을 따르기 보다는 그때그때의 요구사항에 맞춰 몸집을 키우는 IT 인프라를 보유하는 쪽을 선택한다. 이런 방식으로 확장된 기업 시스템은 강력하게 서로 결합되거나 혹은 완벽하게 분리된 여러 하위 시스템["사일로(Silos)" 시스템으로도 불림]으로 구성된 대형 모놀리식(monolithic) 구조체로 변하는 경향이 있다. 일반적으로, 이러한 시스템은 난해하고 일관되지 못한 인터페이스를 가지고 있으며 복잡하고 효율성이 떨어지기 때문에 비즈니스 혁신 속도가 느려진다. 이로 인해, IT 관리자는 정보 기술을 통해 어떻게 하면 핵심 비즈니스를 지원할 수 있을까에 집중하기 보다는 운영 및 장애 제거 프로세스에 더 많은 시간을 보내게 된다. 게다가 일부 기업의 IT 시스템은 기능면에서 부분적으로 중복되기 때문에 비즈니스 정보에 대한 뷰 자체가 단편적이고 일관되지 못하게 되어, 결국 기업의 재정 지출에 대한 합리적인 의사 결정에 영향을 끼친다.
S+S(Software plus Services)는 SaaS(Software as a Service)의 확장 형태로서 조직이 비즈니스를 영위하는데 필요한 기술의 개발, 관리, 배포 및 운영 측면에서 더 많은 아웃소싱 옵션을 제공한다. S+S는 서비스 지향 아키텍처(SOA)의 원칙을 따른다. S+S는 애플리케이션 소프트웨어 및 서비스의 소싱, 파이낸싱, 배포와 관련된 다양한 방법을 제공하기 때문에, SOA를 지원하는 기업에서는 기술 선택의 폭이 넓어졌다. 합리적인 의사 결정을 내리고 S+S 모델을 채택함으로써 얻을 수 있는 잠재 혜택을 극대화하기 위해서는, IT 아키텍트와 의사 결정권자는 사내외에 존재하는 경제적, 규제적, 정치적, 재정적인 요인보다는 비즈니스 동인과 기술적 요구 사항에 중점을 두어야 한다.
이 문서는 Microsoft Worldwide Services 컨설팅 조직이 S+S와 클라우드 기반 애플리케이션을 설계, 이관하는 과정에서 경험한 실제 사례를 근간으로 하고 있다. 또한, 기업, 소프트웨어, 인프라 아키텍처 등 일반적인 아키텍처 도메인에 영향을 미치는 S+S 아키텍처의 고려 사항과 패턴에 대한 견해가 나타나 있다.

SOA, S+S, 클라우드 컴퓨팅

2000년대 중반, 복잡한 IT 인프라 구조가 넘쳐나던 기업에 분별력을 제공하기 위해 다양한 SOA 사례가 소개되었다. 그 이후, 업계에서 가장 큰 인기를 끌던 SOA는 점차 주류에서 밀려나고 최근에는 “SOA는 죽었다”는 말까지 나오고 있다. 하지만 SOA가 오늘날까지도 지속되고 있는 중요한 패러다임의 변화를 이끌었다는 사실에는 변함이 없다.
기술적인 측면에서 SOA의 핵심적인 영향력은 바로 일련의 SOA 원칙, 패턴 그리고 분석 프로세스들이다. 이들을 활용하여 기업은 IT 포트폴리오에 대한 인벤토리를 작성하고 리팩터링을 진행하여 일상적인 비즈니스 운영 작업을 지원하는 모듈화되고 핵심적인 서비스 기능으로 변모시킬 수 있다. SOA의 주요 목표는 비즈니스 목표에 맞춰 기업의 IT를 재구성하고(align) 비즈니스 요구에 IT 부서가 보다 민첩하게 대응할 수 있도록 지원하는 것이다. IT 솔루션의 민첩성 강화를 위한 SOA의 몇 가지 주요 원칙으로는 느슨한 결합(loose coupling), 관심 분리(separation of concerns), 표준 기반 기술 및 대단위(coarse-grained) 서비스 설계가 있다.

그림 1. SOA, S+S, 클라우드 컴퓨팅을 통한 IT 최적화

aa699437_a1f1(en-us,MSDN_10)

SOA는 기업이 주요 서비스 기능을 식별하고, 비즈니스와 IT간 연계를 구축해 민첩성을 유지하도록 지원하는 반면, S+S는 사내에 배포된 클라우드 컴퓨팅 및 솔루션을 통해 IT 투자를 최적화할 수 있는 컴퓨팅 모델을 제공한다. 그러나 S+S는 SOA의 필요성을 없애는 것이 아니라 SOA를 지원하는 기업이 애플리케이션 소프트웨어 및 서비스를 소싱, 파이낸싱, 배포할 수 있는 여러 모드를 구축함으로써 기술 선택을 최적화할 수 있도록 도와준다.

그림 1은 SOA, S+S 및 클라우드 컴퓨팅 스택 관계를 나타낸다.

일반적으로 모든 조직에 적용할 수 있는 단 하나의 올바른 IT 포트폴리오가 있는 것이 아니기 때문에, 조직에 무엇이 가장 적합한가는 현재의 비즈니스 목표와 요구 사항에 달려 있다. 따라서 S+S 컴퓨팅 모델은 비용, 핵심 업무와의 관련성, 사용자 경험 및 혁신 가치, 비즈니스 차별성 등의 의사 결정 필터에 따라 특정 기술을 선택해 기업이 IT 포트폴리오를 최적화할 수 있도록 지원한다. S+S는 사업장내 (on-premises) 소프트웨어의 장점(예: 짧은 대기시간 및 풍부한 기능)과 클라우드 컴퓨팅의 장점(예: 유연한 확장성 및 아웃소싱)을 결합시켜 효과적인 하이브리드 분산 아키텍처 설계를 위한 보다 다양한 선택옵션을 제공한다.

클라우드 컴퓨팅은 제공되는 서비스를 집합적으로 지칭하는 말이다. 현재 클라우드 컴퓨팅은 아래와 같은 벤더의 솔루션을 포함한다.

* IaaS(Infrastructure as a Service). IaaS는 일반적으로 동적 확장이 가능하고 가상화된 계산 및 저장소 리소스가 서비스 형태로 제공되는 컴퓨팅 환경이다. 이 서비스는 서버 및 저장소 장치와 같은 하위 수준의 하드웨어에 대한 투자 요구로부터 서비스 고객 수를 산정한다.
* PaaS(Platform as a Service). PaaS는 서비스 고객에게 운영 체제와 애플리케이션 플랫폼 수준의 추상화를 제공한다. 또한, 단일 시스템 상의 다중 고객 지원 (multitenant) 환경에서 고객별 요청 처리 시간을 스케줄링하고, 메모리 공간을 할당하고, 시스템과 애플리케이션의 무결성을 보장할 수 있는 시스템 리소스 관리 기능을 제공한다. 서비스 고객은 PaaS 애플리케이션 개발 도구를 사용하여 호스팅 플랫폼에서 실행되는 클라우드 애플리케이션을 구축할 수 있다.
* SaaS(Software as a Service). SaaS는 타사 서비스 공급자에 의해 호스팅되는 비즈니스 및 소비자 애플리케이션을 의미한다. 서비스 고객은 웹 브라우저 또는 데스크톱에 설치된 애플리케이션을 통해 호스팅된 애플리케이션을 사용할 수도 있다. 어떤 경우에는, 기업이 자사의 데이터 및 비즈니스 프로세스와 SaaS 애플리케이션을 통합할 수 있도록 SaaS 공급자가 UI가 없는(headless) 웹 서비스를 제공하기도 한다.

클라우드 컴퓨팅 솔루션은 기업 관리 인프라를 보완하고 다음과 같은 다양한 이점을 제공한다.
* 추가 컴퓨팅 및 저장소 용량 등과 같은 리소스를 동적으로 할당하는 기능을 사용해 비즈니스 수요에 따라 IT 지출을 유연하게 조정할 수 있다.
* 트랜잭션 및 가입 기반 클라우드 플랫폼을 사용하여 막대한 IT 투자 없이도 새로운 비즈니스와 작업 모델을 신속하게 테스트할 수 있는 혁신적인 애플리케이션 솔루션을 개발할 수 있다.
* 아웃소싱된 솔루션은 모든 IT 자산을 효과적으로 관리 및 운영하는데 소요되는 지속적인 IT 비용과 책임(즉, 기회 비용)을 줄여준다.

설계 고려 사항

이 섹션에서는 S+S 기반 솔루션 설계 또는 채택 시 고려해야 할 비즈니스 및 기술적인 이슈에 대한 간략한 개요를 제공한다. 그림 2는 이 문서 구성에 사용된 프레임을 나타낸다. 이 프레임은 특정 아키텍처 관점을 중심으로 구성되었으며 공통 관심사(crosscutting concern)를 식별하여 S+S 전략의 일부로 간주되는 시나리오 유형, 설계 고려 사항 및 패턴에 관한 포괄적인 관점을 제공한다.
이 정보는 S+S 전략을 채택함에 있어서 전체적인 영향을 평가하는 기준이 된다.

엔터프라이즈 아키텍처

엔터프라이즈 아키텍트 역할 가운데 가장 까다로운 것 중 하나는 끊임없이 변하는 비즈니스 요구 사항과 이러한 요구 사항을 일관성있게 충족시킬 수 있는 IT 조직 능력 간에 균형을 유지하는 것이다.

그림 2. 아키텍처 관점 프레임웍

aa699437_a1f2(en-us,MSDN_10)

S+S는 IT 플랫폼, 애플리케이션 또는 애플리케이션(비즈니스) 서비스를 통합하거나, 때로는 아웃소싱하여 운영 비용을 절감할 수 있는 새로운 기술 배포 패턴을 제공한다. 또한, 조직은 S+S를 통해 시스템 전사 통합시 발생하는 마찰을 줄일 수 있다. 때로는 기존 채널들을 결합시키는 것만으로도 기존 비즈니스 관계에 정보 서비스를 제공할 수도 있다.
엔터프라이즈 아키텍트는 먼저 최상위 수준에서 조직의 핵심 역량을 판단할 수 있는 기준을 마련하고, 어떤 애플리케이션이 이러한 핵심 역량을 지원하고 있는지, 그래서 어떤 애플리케이션이 사내에서 계속 유지해야 하는지 혹은 외부에 아웃소싱 주어야 하는지를 결정할 수 있는 프로세스를 마련해야 한다.

다음은 몇몇 대규모 조직에서 사용되는 모델이다.
* 회사에 특화된(proprietary) 미션 크리티컬한 시스템— 회사에 특화된 시스템, 혹은 미션 크리티컬한 시스템, 혹은 경쟁 우위를 제공하는 시스템은 무척 중요하기 때문에 외부(off-premises) 서비스 공급자에게 아웃소싱하기에는 위험부담이 너무 크다고 여겨진다. 따라서 이러한 시스템은 주로 조직내 기존 IT 부서에서 설계, 개발, 운영 및 관리한다.
* 회사에 특화되지 않은 미션 크리티컬 시스템— 회사에 특화되어 있는 시스템은 아니지만 미션 크리티컬한 시스템인 경우, 개발은 다른 회사에서 할 수 있지만 설계, 운영 및 관리는 조직 내 기존 IT 담당 부서에서 담당한다.
* 회사에 특화되지 않은 시스템— 표준화된 기능 및 인터페이스를 제공하는 특정 회사에 특화되지 않은 시스템은 서비스 공급자와 적절한 SLA(서비스 수준 계약)을 설정할 수 있는 경우, 클라우드 서비스 공급자에게 아웃소싱하기에 아주 적당하다. 이러한 시스템의 예로는 전자 메일, 일정관리 및 콘텐츠 관리 도구 등이 있다.

이 모델은 애플리케이션 및 시스템을 평가하는 출발점을 제공한다. 하지만 조직마다 차이점이 존재한다는 사실을 고려해야 한다. 예를 들어, 예산 또는 전문가의 부재로 조직 내에서 핵심 시스템을 효율적으로 관리할 수 없는 경우에는 아웃소싱을 고려할 수 있다. 마찬가지로, 일부 미션 크리티컬한 시스템을 클라우드에 두면 적은 비용으로도 추가 기능을 제공할 수 있어 단점이 상쇄된다. 일례로, 지점 또는 신뢰할 수 있는 파트너는 사내 전용 인프라를 구축하지 않고도 시스템에 접근할 수 있다.

그림 3. IT 성숙도에 따른 S+S 영향

aa699437_a1f3(en-us,MSDN_10)

그러나 단순히 애플리케이션을 외부(off-premises)로 이동시킬 기회를 식별하는 것으로는 충분하지 않다. S+S 기회를 활용하려면 의사 결정권자가 조직의 IT 성숙도를 명확하게 이해하고 있어야 한다. 이러한 이해가 있어야만 IT 인프라와 프로세스를 어떻게 변경해야 S+S 채택으로 얻을 수 있는 비용 절감 또는 ROI(투자 수익률) 극대화와 같은 이점을 실현할 수 있는지 결정할 수 있다.

그림 3은 IT 성숙도("Enterprise Architecture as Strategy"에 근거한 성숙도 모델1)에 따른 다양한 수준에서 S+S 채택의 용이성을 나타낸 것으로, 조직 성숙도를 판단하지 않으면 예측된 ROI가 부정확할 수도 있다는 것을 보여준다.

Posted by 장현춘

댓글을 달아 주세요