AJ16_cover

지난 포스팅에 이어 아키텍처 저널 16권에 실린 사용자 인증 및 아이덴티티 관련된 아티클 번역물 두번째를 올린다. 클라우드가 이제는 모든 비지니스의 기본 인프라처럼 여겨지는 시대가 되어 가는데, 이때 필요한 것이 상호간 Seamless 연동을 가능케하는 인증 체계의 통합이다. 이 글은 클레임 기반 인증 방식의 가장 기본이 되는 원칙과 원리를 설명하고 있으며, 이를 통해 클라우드 시대까지 확장할 수 있는 인증 통합을 살며시 이야기하고 있다. 

이 아티클의 원문은 아래에서 확인할 수 있다.
http://msdn.microsoft.com/ko-kr/architecture/cc836390(en-us).aspx

참고로, 현재까지 번역된 아키텍처 저널은 다음과 같으며 3개의 아티클이 한글 PDF 버전으로 다운로드 가능하다.
아키텍처 저널 21 : http://msdn.microsoft.com/ko-kr/architecture/aa699437.aspx
아키텍처 저널 19 : http://msdn.microsoft.com/ko-kr/architecture/aa699428.aspx
---------------------------------------------------------------------------------------
클레임 인식 솔루션의 아키텍처 패턴
앞서 언급한 기본 개념은 새로운 인증 메커니즘의 기반이 된다. 따라서 이러한 개념을 조합하면 어떤 시스템과 트랜잭션도 설명할 수 있다. 이 새로운 세상에서, 전통적으로 하나로 융합되어 있던 두 가지 기능, 즉 (클레임을 통해) 호출자에 대한 정보를 얻는 기능과 (자격 증명을 통해) 호출자가 기존 사용자인지 여부를 확인하는 기능을 마침내 분리할 수 있게 되었다. 이러한 분리 덕분에 이제 어떤 기능이 시나리오에 가장 적합한지 결정할 수 있다(보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, The TAO of Authentication).
일반적인 시나리오를 설명하는 데 특히 유용한 특정 패턴이 있으며, 이중 가장 일반적인 세 가지 패턴을 기술할 예정이다. 아울러 일반적인 시나리오에 대해서 클레임 기반 접근법이 기존 방식에 비해 갖는 장점을 몇 가지 설명할 예정이다. 모든 패턴은 온프레미스 및 클라우드 아키텍처 모두에 적합하다.

정식 패턴: 주체(Subject)-IP-RP
이 패턴은 인증 관리에 있어 드물게 발생하는 상황, 즉 하나의 주체가 제한된 리소스(RP)에 접근하길 원하는 상황을 설명한다. 이러한 패턴은 Windows 사용자가 네트워크 공유에 접근을 시도하는 경우, 스마트 클라이언트가 보안 웹 서비스를 호출하는 경우, 웹 서퍼가 제한된 컨텐츠를 찾아보는 경우 등에 발생한다(그림 2 참조). 주요 절차는 다음과 같다.

그림 2. 주체-IP-RP 정식 패턴. 숫자는 텍스트를 나타낸다.

  1. (독립적으로) RP가 정책의 형태로 요구 사항을 게시한다. 이러한 요구 사항은 다음을 포함한다.
    1. 클레임 목록
    2. RP가 이러한 클레임의 소스로 신뢰하는 IP
    3. RP가 사용할 수 있는 특정 인증 기술에 관한 세부 정보 (예: RP가 이해하는 토큰 형식)
  2. 주체(Subject)가 RP 정책을 읽고 이를 준수할 수 있는지 확인한다. 이것은 실제로 주체가 RP가 신뢰하는 그 어떤 IP로부터도 적절한 토큰을 확보할 수 있는지 여부를 확인하는 것을 의미한다.
  3. 주체가 적절한 IP를 호출하고, RP 정책을 준수하는 토큰을 요청한다. 실제로 이는 일반적으로 RST 메시지를 IP의 STS로 전송하는 것을 의미한다.
  4. IP가 RST를 수신하고 주체를 인증한다. 주체가 확인되면 IP는 필요한 클레임 값을 검색하고, 토큰으로 패키지화하여, 서명 후 주체에 다시 전송한다.
  5. 주체는 이 토큰을 수신하여 RP를 호출하는 데 사용한다.
  6. RP가 호출 메시지에서 토큰을 추출한 후, 신뢰할 수 있는 IP에 의해 서명된 것인지와 적절한 클레임을 포함하고 있는지를 검사한다. 확인 결과가 긍정적이면,
    1. 클레임 값은 일부 접근 제어 로직을 공급하는 데 사용된다.
    2. 접근 제어 로직이 충족되면, 리소스 자체에서 클레임 값을 사용할 수 있게 되고, 접근이 허용된다.

본 설명의 취지에 따라 여기서는 리소스가 웹 서비스라고 가정하도록 한다. 위의 패턴은 다수의 좋은 속성을 보여준다.

인증 외부화 (Authentication externalization)
토큰 및 클레임을 사용하면 리소스가 명시적 아이덴티티 관리 코드를 작성해야 하는 부담이 줄어든다. 또한, RP 정책 게시를 처리하는 인프라와 동일한 인프라가 토큰을 역직렬화하고, 서명을 확인하며, 리소스 개발자가 실제 사용되는 토큰의 형태에 관계없이 클레임 값을 손쉽게 사용할 수 있도록 하는 등의 작업을 수행할 수 있다. 이 인프라는 클레임 값에 기반해 일부 권한 부여를 결정할 수도 있어, 개발자의 작업을 더 줄여준다.
이는 모든 시나리오에 적용되는 장점이지만, 호스팅 기술이 하나의 변수인 클라우드에서 특히 진가를 발휘한다. 클레임을 사용하면 리소스를 호스팅하는 인프라의 세부 정보와 런타임 시 제공되는 인증 기술 세부 정보로부터 리소스를 분리시킴으로써 진정으로 이식 가능한 리소스를 실현한다.

리소스 레벨 정책 (Resource-level policy)
리소스 레벨에서 정책을 지정할 수 있게 되면, 배포가 매우 민첩해지고, 상세한 제어가 가능하며, 인증 기술에 대한 선택을 동적으로 가능하게 한다. 또한, 상호 운용이 가능한 표준을 사용하기 때문에 호스팅 환경에 관계없이 효과적인 관리 전략을 수립할 수 있으며, 실행 환경으로부터 리소스 자체가 분리되기 때문에 (클라우드로의 이동 포함해) 리소스를 훨씬 더 쉽게 이동시킬 수 있다.

자율성
모든 리소스는 자율적으로 자신의 요구 사항을 명시하고, 주체(Subject)가 그러한 요구 사항을 자신의 능력과 매칭시킨다. 이와 같은 상호 작용은 리소스와 주체가 결합할 때 나타나는 특징적인 속성이다. 리소스와 주체 양쪽 모두 독립적으로 변할 수 있고, 리소스에 접근할 수 있는 주체들의 집합은 외부적인 영향이나 인프라 의존 관계와는 상관없이 리소스의 요구 사항을 준수할 수 있는 능력에 의해서만 정의된다. 이 시스템은 각자의 요구 사항 및 능력에만 신경 쓰면 되기 때문에 매우 강력하다. 명시적인 협상이나 조정이 필요하지 않으므로 사용자 참여도 매우 쉽다.

일부 인증 및 권한 부여 로직의 중앙 집중화
이 패턴에서는 IP가 모든 특성(attribute) 검색 작업을 수행한다. RP는 다른 시스템에 쿼리를 실행하지 않고도 필요한 것을 토큰 형태로 받는다. 이는 RP가 접근 권한을 가지지 않는 특성에는 분명 이점이 된다. (즉, 항공사 A가 주체의 파트너 항공사 B의 마일리지 정보를 요청하는 것과 같은 이치이다.) 뿐만 아니라 특성 검색 로직을 한 곳으로 중앙 집중화할 수 있는 훌륭한 수단이 된다. 또한, 특성 저장소에 접근해야 하는 접점(endpoint)의 수를 줄이고, 관리 용이성 및 보안을 향상시켜 준다. 뿐만 아니라, 일단 주체가 토큰을 얻으면 만료될 때까지는 IP에 조회할 필요 없이 이를 캐시 및 재사용할 수 있기 때문에 접근 횟수 자체도 줄일 수 있다. 또한, IP는 권한 부여를 결정하는 데 사용될 수 있는데, 이는 클레임을 통해서도 표현할 수 있다. 단, 이 때 IP는 주체 및 리소스 모두와 긴밀한 관계를 가지고 있어야만 한다. 이러한 패턴은 예를 들어 IP가 디렉터리를 나타내고 RP는 IP가 관리하는 리소스 중 하나인 경우와 같이 중요한 시나리오에서 발생하지만, 일반적으로 RP와 IP 사이에는 어떠한 관계도 가정될 수 없다.
이것은, 가능한 사용자에 대한 정보를 확인하기 위해 리소스가 외부 IP에 의존해야 하는 경우와 같이 많은 클라우드 시나리오에 있어 핵심이 된다. 또한, 파트너 조직의 사용자가 기술이나 플랫폼과 무관한 토큰 형태로 표현될 수 있는, 전통적인 페더레이션보다는 다소 애자일한 경우에 아주 유용하며, 아울러 모든 유형의 경계를 넘나드는 경우에 큰 도움이 된다.

클레임 변환기 유형: 주체-IP-클레임 변환기-RP
방금 설명한 패턴은 일반 소비자(항공사 A의 단골 고객이 파트너 항공사 B의 웹 사이트를 접근하는 경우)에서 기업(거의 모든 Kerberos 시나리오가 그와 같은 방식으로 모델링될 수 있으며, 기술 독립성이라는 이점도 추가로 누릴 수 있음)에 이르기까지 광범위한 시나리오에 적용될 수 있다.
단, 실제로는 특정 제약 조건으로 인해 이 패턴을 적용하지 못하는 상황이 존재한다.

1. 간접 신뢰(Indirect trust). RP가 주체와 관계를 맺고 있는 IP를 직접적으로 신뢰하지 않을 수 있지만, 신뢰 관계를 중개해 줄 수 있는 일련의 중간 단계 인증 기관을 둘 수 있다. 비행기를 타고 싶다고 해서 지갑 속에 들어있는 신분 증명 문서(정부가 발행한 여권 또는 운전 면허증)만으로는 바로 비행기를 탈 수 없다. 탑승 게이트의 직원은 제대로 된 항공사에서 발급한 탑승권만 신뢰할 것이다. 따라서, 이미 소유하고 있는 신분 증명 문서를 체크인 프런트에서 사용하여 탑승권을 받으면 된다.

2. 클레임 형식. 주체가 바로 이용할 수 있는 IP에서 발급한 클레임의 형식을 RP가 이해하지 못할 수 있다. 이는 때로는 단순한 형식 문제일 수도 있고 (예를 들어, 이탈리아 ID에 “birth date” 대신 “nato il”로 되어 있다면, 미국의 바텐더는 필요한 정보를 눈 앞에 두고도 알지 못한다.), 때로는 RP가 요구하는 클레임이 수신된 원시 정보를 가공한 결과를 원하기 때문일 수도 있다. (RP가 수신된 “age”와 “Nationality”를 가공하여 “CanDrink?”라는 클레임을 필요로 할 수도 있다.)

위에서 언급한 것과 같은 새로운 제약 조건이 있을 경우, 이는 새로운 요소를 추가함으로써 쉽게 처리할 수 있다. 클레임 변환기 (claim transformer)로 불리게 될 이 요소는 리소스에 도달하기 전에 토큰을 처리할 수 있으며, RP가 신뢰를 중개하고 수신 클레임을 보다 적절한 형식으로 변환하는 데 활용할 수 있다. 주체와 RP 사이에는 임의의 긴 클레임 변환기 사슬이 존재할 수 있다. 따라서 상위 수준에서 계획하지 않고도, 동적인 정책 협상에서 경로(존재하는 경우)를 자동으로 “선택”할 수 있다.
클레임 변환기를 구현하는 최상의 아티팩트는 다시 말하지만 STS이다. 클레임 변환기가 사용하는 STS는 자체 데이터 소스로부터 발급된 클레임을 채우는 것 대신, 주로 수신된 정보를 조작하게 된다. 전통적인 페더레이션 경우처럼, RP를 소유하고 있는 동일한 엔터티가 STS를 실행하는 경우가 많기 때문에, 이러한 종류의 STS는 일반적으로 Resource STS, R-STS 또는 RP-STS로 지칭된다. 보다 자세한 정보는 저자 블로그에서 확인하도록 한다(리소스 부분 참조).
클레임 변환기를 적용하는 방식은 몇 가지 강력한 이점을 제공하며, 분산 시스템의 아이덴티티 관리를 위한 지배적인 패턴으로 부상할 것으로 생각된다(그림 3 참조).

Cc836390_ClaimsAndIdentity03(en-us,MSDN_10)

리소스 클러스터링
클레임 변환기는 엔터프라이즈 수준에서 단일 리소스와 디렉터리 간에 지속적인 granularity를 제공할 수 있다. R-STS는 요구 사항이 비슷한 여러 리소스를 모으는 데 사용할 수 있다. 복잡한 신뢰 중개 나 원본 클레임 처리 작업을 엔터프라이즈 수준까지 요청할 필요도 없이 한 지점 내로 이동시킴으로써 정책 관리를 간소화한다. R-STS는 네트워크 상에서 제 역할을 제대로 하지 못할 수 있는 레거시 리소스를 보호하는 가상 경계도 될 수 있다. 이러한 것들은 클레임 변환기의 강력한 효과를 보여 주는 일부 사례에 지나지 않는다(그림 4 참조).

Cc836390_ClaimsAndIdentity04(en-us,MSDN_10)

권한 부여 결정 지점(Authorization Decision Point)
IP는 일반적으로 독립적인 엔터티지만, R-STS는 협력하는 리소스의 일부 정보를 소유하는 경우가 많다. R-STS는 이러한 정보를 통해 권한 부여 결정을 내릴 수 있다. 수신 클레임은 주체가 접근을 시도하는 리소스의 요구 사항과 함께 처리될 수 있고, 그 결과는 곧 주체가 필요한 권한을 보유하고 있는지 여부에 관한 결정이 될 수 있다. 이러한 결정은 다양한 방식으로 표현될 수 있다.

  • 주체가 어떠한 권한도 가지고 있지 않은 경우, R-STS는 단순히 토큰 발급을 거부하고 호출을 차단할 수 있다. 이 경우 R-STS는 권한 부여를 강제하는 것이다.
  • 주체가 일정 권한을 가지고 있는 경우, R-STS는 이러한 권한 부여 결정을 클레임의 형태로 공식화할 수 있다. 따라서 RP는 권한 부여 로직을 실행해야 하는 부담에서 벗어나 R-STS에서 클레임의 형태로 받는 지시문을 적용하기만 하면 된다.

토큰, 클레임 및 IP 사용은 인증 과정 외부화를 가능하게 하고, 어느 특정 상황에서 R-STS는 권한 부여 결정에도 동일한 작업을 수행할 수 있도록 도움을 줄 수 있다.

위임
레거시 시스템, 디렉터리 수준에서 직접 관리되는 리소스 등 클레임이 인식하지 않는 수많은 리소스가 존재한다. 때로는 이러한 리소스에 대한 접근을 관리하기 위해 ACL 할당 및 그룹 생성과 같이 몇 가지 투자가 이루어진 경우도 있다. 클레임 기반 보안을 통해 프런트 엔드 애플리케이션을 호출하는 주체의 아이덴티티는 이러한 투자를 활용하는 데 적합하지 않다. 단, 프런트 엔드 애플리케이션이 호출자를 대신하여 디렉터리 아이덴티티를 받을 수 있다면 문제가 해결된다. 사실 다른 누군가를 대신하여 토큰을 받는 것은 발급된 토큰이 클레임의 영역에 남아 있는 경우에도 분명히 가치가 있다.

클레임과 클라우드
지금까지 설명한 것의 장점은 느슨하게 연결된 모든 시스템에 적용될 수 있다는 것이다. 최고의 분산 시스템이라 할 수 있는 클라우드도 예외가 아니다. 클라우드 차원에서 생각한다는 것은 모든 엔터티가 독립적으로 관리되는 환경을 다루는 것이다. 즉, 클레임, 토큰, 신뢰 및 아이덴티티 메타 시스템 기능은 다루고 있는 파티들 사이의 관계에 대해 알고 있는 정보의 크기가 얼마가 됐든 이를 최대한 활용할 수 있도록 지원한다. 클레임 기반 솔루션을 설명하면서 우리는 사내 및 클라우드에 모두 비슷하게 적용될 수 있는 도구를 제공하는 일석이조의 효과를 거두었다.
우리가 클라우드 시나리오에 대한 자세한 지침을 제공하기에는 앞으로 어떤 식으로 변하게 될지 너무 적게 알고 있는 실정이다. 하지만 몇 가지 기본적인 가설을 통해 클라우드에 특히 잘 맞는 클레임 인식 아이덴티티 관리의 여러 가지 측면은 조명해 볼 수 있다.

클레임 변환을 통한 접근 제어
클라우드 공급자가 저장 및 계산, 메시징, 통합 등과 같은 서비스를 제공할 수 있다는 것은 잘 알려진 사실이다. 클레임 변환기 섹션에서 다뤘던 내용을 상기해보면, 클라우드 공급자의 분명한 접근 제어 전략은 R-STS를 제공하고 리소스가 이를 신뢰하게 만드는 것임을 알 수 있다. 그러면 이 R-STS를 사용하는 모든 리소스들은 R-STS의 클레임 변환 규칙을 조작함으로써 간단하게 접근 제어를 관리할 수 있게 된다.
ISV로서 어떤 클라우드 공급자에 서비스를 구축하기를 원한다고 가정해 보자. 먼저 서비스가 받아들일 클레임 집합을 결정하고, 이 서비스가 클라우드 공급자의 R-STS를 신뢰하도록 설정한다. 이로써, 누가 서비스를 호출하더라도 접근 제어 전략은 이미 마련되어 있다! 새로운 고객을 참여시킬 때에는 R-STS 수준에서 몇 가지 규칙을 설정하여 고객의 클레임을 자신의 클레임으로 매핑하는 방법을 정의하기만 하면 된다. 이는 놀라울 정도로 민첩한 방법으로 유지 관리하기도 매우 쉽다(그림 5 참조).

Cc836390_ClaimsAndIdentity05(en-us,MSDN_10)

권한 부여 외부화 (Externalizing Authorization)
지금까지 R-STS가 권한 부여 결정을 편리하게 외부화하고 집계하는 방법에 대해 살펴보았다. 물론 이 방법은 클라우드 시나리오에서도 유효하다. 실제로는 권한 부여 적용까지 포함하도록 R-STS의 적용 범위가 확대된 사례가 많다. ISV 사례로 돌아가자.
서비스가 메시징 방식을 통해 제공되는 경우, 메시지가 타겟에 도달하기 전에 권한 부여에 관련된 클레임을 검사함으로써, 서비스 전송 인프라 자체에서 권한 부여 결정 사항을 강제할 수 있다. 이는 ISV의 부담을 줄여준다. 즉, 서비스가 해당 공급자의 메시징 인프라를 사용하지 않는 경우, 권한 부여 관련 결정 사항을 강제하기 위해서는 리소스 앞쪽에 일부 처리 파이프라인을 추가해야 하는 부담이 발생하게 된다. (보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, 클레임 유형).

관계 관리하기
설명한 모델을 통해 ISV는 고객 관계를 일련의 규칙으로 나타낼 수 있다. 이는 전통적인 방법을 통해 디렉터리 간에 페더레이션 관계를 생성하는 것보다 훨씬 더 민첩한 방식이다. 이 방식은 관리의 세분성은 떨어지지만, 피어 파트너 관계에는 필요하나 공급자-고객 관계에는 과도한 경우가 많은 추가 관리 부담을 해소시켜 준다.
또한, 이 모델은 고급 아이덴티티 기능 없이도 개인 및 고객을 수용할 수 있게 해 준다. ISV 서비스는 고객이 자체 IP에서 발급된 토큰을 통해 인증을 받았든, 단순한 일회용 사용자 이름 및 암호를 통해 인증을 받았든, 언제나 R-STS가 발급한 토큰을 확인한다.

미래
클라우드로의 전환은 확실히 이루어질 것이다. 업계에서는 중요한 것은 클라우드 환경으로 전환할지 여부가 아니라 전환 시점이라는 것을 매우 빠르게 인식하고 있다. 미래를 예측하는 것은 언제나 위험한 일이다. 하지만 클라우드는 오늘날 아이덴티티 유토피아처럼 보임에도 불구하고 지금까지 설명한 원리 덕분에 지극히 타당해 보이는 개발에 뛰어들지 않고 그냥 넘기기에는 너무 들떠 있는 상황이다.
오늘날 접근 제어는 기능보다는 순위를 반영하는 권한으로 인해 조직 구조의 철로에서 제약을 받는 경우가 많다. 상호 운용성 이벤트에 참여하는 기업 및 오픈 소스 이니셔티브의 수와 수준(리소스 부분 참조: RSA 2008 OSIS 상호 운용성 이벤트), 그리고 주요 제품에서의 클레임 지원 통합은 클레임 기반 프로그래밍이 주류가 되고 있음을 보여준다. 그렇게 된다면 아이덴티티 및 접근 제어 구조가 어떻게 조직이 아닌 작업을 중심으로 수렴될 수 있을지를 쉽게 상상할 수 있다. 수많은 기업의 주체, 리소스, 역할 및 인증 기관은 모두 특정 프로젝트의 측면에서 설명될 수 있고, 조직 순위가 아닌 프로젝트 자체의 측면에서 수행되는 기능에 따라 권한이 할당될 것이다. 작업이 이루어지는 동안에는 가상 조직이 생성되었다가 임무가 완료되면 사라질 수 있다. 또한, 기업 전체에서 이루어지는 작업 템플릿을 지원하여, 모범 사례를 적용하고, 예측 가능성을 향상시킬 수 있다(그림 6 참조).

Cc836390_ClaimsAndIdentity06(en-us,MSDN_10)

이를 실현하려면 클레임은 충분조건이 아닌 필요조건이다. 여기에 가상 디렉터리와 같은 새로운 기술이 또한 핵심 역할을 할 것이다. (보다 자세한 내용은 Kim Cameron의 블로그 www.identityblog.com을 참조할 것).

Call to Action
클레임 기반 방식은 전통적인 시나리오와 클라우드 시나리오 모두를 위한 훌륭한 방식이다. 차이가 있다면 전통적인 시나리오에서는 경우에 따라 다량의 추가 리소스를 사용하여 나쁜 전략을 피할 수 있는 반면, 일단 클라우드를 사용하는 경우에는 이것이 쉽지 않다는 것이다. 자신과 조직이 미래의 물결에 대비하길 원한다면 다음과 같은 몇 가지 작업을 수행할 수 있다.

여기서 ‘수박 겉핥기 식’이라는 속담을 언급할 수 있을 듯하다. 그리고 아마 그 말이 맞을지도 모른다. 하지만 그 대신 클레임은 전통적인 시나리오와 클라우드 시나리오 모두에 있어 흥미로운 아이덴티티 관리 전략 개발의 토대가 된다는 말로 이 글을 정리하고 싶다. 자신이 괴짜라고 생각한다면 이러한 상호 작용의 대부분이 아주 명백히 드러나는 특별한 전환의 순간을 즐기라고 권하고 싶다. 그리고 아울러 그 외 사람들에게는 세부 정보의 대부분은 인프라에 통합되고 새로운 차원의 도구를 통해 겉으로 드러나지 않을 것으로 예상되기 때문에 안심해도 된다고 말하고 싶다.

리소스
Vittorio Bertocci의 블로그:

Kim Cameron의 블로그:

“Understanding Windows Cardspace”, Chapter II (Addison Wesley 2008)(MSDN에 게시)

RSA2008 OSIS 상호 운용성 이벤트:

WS-Security

WS-Trust:

저자 소개
Vittorio Bertocci는 Microsoft사 Cloud Services Evangelism의 수석 아키텍트 전도사로 대기업이 신기술을 활용할 수 있도록 도움을 주고 있다. 그는 Italian Microsoft Services에서 몇 년간 근무한 후, 미국 본사로 전근하여 지난 3년간 고객이 아이덴티티 및 접근 관리, SOA 및 서비스를 토대로 솔루션을 구축할 수 있도록 지원해 왔다. 현재 클라우드 컴퓨팅의 아이덴티티 및 접근 측면에 전념하고 있으며, 사용자 중심의 ID를 주제로 공동 집필한 저서 Understanding Windows Cardspace가 지난 1월에 출간된 바 있다. Vittorio는 유명한 블로그(http://blogs.msdn.com/vbertocci)를 운영하고 있다.
이 글은 Microsoft가 출판하고 온라인으로 게시하는 Architecture Journal에 실려 있다. Architecture Journal에서 더 많은 글을 읽고 싶다면 Architecture Journal 웹 사이트를 참조한다.

Posted by 장현춘

댓글을 달아 주세요

  AJ16_cover

아키텍처 저널 16권에 실린 사용자 인증 및 아이덴티티 관련된 아티클을 번역 중이며, 그 전반부를 올린다. 이 아티클에 실린 내용은 전통적인 on premise 방식의 시스템이나 근래들어 관심을 끌고 있는 클라우드 기반 애플리케이션 개발에 있어서도 다른 시스템과의 연계나 통합 측면에서 늘 고려되고 중요시되는 사용자 인증과 서로 다른 아이텐티티 통합 관련하여 클레임 기반 관리 기법을 소개한다. 이는 특정 플랫폼이나 벤더에 종속적이지 않으면서 표준적인 토큰 방식을 적용하여 광범위하게 적용할 수 있는 방법이며 마이크로소프트는 Active Directory Federation Service를 통해 이미 지원하고 있다.

이 아티클의 원문은 아래에서 확인할 수 있다.
http://msdn.microsoft.com/ko-kr/architecture/cc836390(en-us).aspx

참고로, 현재까지 번역된 아키텍처 저널은 다음과 같으며 3개의 아티클이 한글 PDF 버전으로 다운로드 가능하다.
아키텍처 저널 21 : http://msdn.microsoft.com/ko-kr/architecture/aa699437.aspx
아키텍처 저널 19 : http://msdn.microsoft.com/ko-kr/architecture/aa699428.aspx 
----------------------------------------
요약
오늘날의 아이덴티티 관리는 종종 불완전한 솔루션 여러 개를 짜깁기한 방식으로 이루어진다. 이 방식은 기술 및 조직 경계에 의해 분리된 애플리케이션 및 엔터티를 어느 정도 지원하기는 하지만, 이들을 실제로 통합하지는 못한다. 하지만 기업들은 SaaS(Software as a Service) 및 클라우드 컴퓨팅의 확산으로 인해 이러한 경계를 허물어야 하는 상황에 자주 직면하게 될 것이고, 따라서 임시방편적인 솔루션은 더 이상 통하지 않게 될 것이다. 이러한 환경에서는 아이덴티티 사일로(silo)를 허물고 의도적으로 계획된 경계가 없는 IT를 지원하는 새로운 접근법이 적절하다.
이 아티클은 전통적인 시나리오와 클라우드 시나리오에 동일하게 효과적으로 적용될 수 있는 모델인 클레임 기반 아이덴티티 관리(claims-based identity management)의 원칙에 대해 살펴본다. 아울러 이러한 원칙이 클라우드 컴퓨팅 환경과 일반적인 분산 시스템에 적용될 때 얻을 수 있는 장점과 기회를 중심으로 가장 일반적인 토큰 교환 패턴에 대해 살펴볼 것이다.

한계는 없다
여러분의 내면에 있는 어린아이는 구름 낀 하늘에서 용이나 성과 같은 것을 보겠지만, 이 아티클을 읽고 난 후에 여러분은 아키텍트로서 구름 속에서 달러 기호를 보게 될 것이다. 클라우드 컴퓨팅은 IT에 대한 사고 방식에 획기적인 이점을 가져온다고 약속한다. 클라우드 컴퓨팅의 기본적인 개념은 기업이 자산을 회사 외부에 호스팅하며, 필요한 인프라를 유지 관리해야 하는 부담 없이 이러한 자산이 제공하는 혜택을 누릴 수 있다는 것이다. 이는 기업이 원하는 기능을 서비스 형태로 구입함으로써, 핵심 비즈니스와 관련이 없는 온프레미스(on-premise) 애플리케이션을 관리해야 하는 부담을 없애주는 SaaS와 어느 정도 비슷하다. 하지만 클라우드 컴퓨팅은 그 한계를 더욱 확장시킨다. 클라우드는 대표적인 CRM 및 HR 패키지 등 타사가 제공하는 완벽한 애플리케이션을 구입하지 않고도, 데이터 센터 내에서 플랫폼으로 노출되는 자사 리소스를 호스팅할 수 있는 가능성을 제공한다. 이렇게 되면 CPU와 대역폭 사용량을 고민할 필요 없고, 하드웨어를 직접 다루거나 실내 냉방을 고민하지 않으면서도 리소스 제어 권한을 유지할 수 있다. 심지어 시스템 패치를 염려할 필요도 없다. 웹 애플리케이션이 새로운 데이터를 매일 생성하는 경우, 클라우드의 데이터 저장소를 이용하면 용량 확장을 위해 하드웨어를 계속 추가로 구입하지 않아도 된다. 가장 좋은 점은 하드웨어와 인프라에 미리 투자하지 않아도 되며, 실제로 리소스를 사용하는 양만큼 비용을 지불하면 된다는 것이다. “클라우드 컴퓨팅”이라는 용어 대신 “유틸리티 컴퓨팅”이라는 용어가 자주 사용되는 이유도 바로 이러한 “사용량 기준 결제(pay-per-use)” 방식 때문이다. CPU 사용량이 많은 작업의 경우, 이러한 장점은 더욱 확연해 진다. 피크 타임을 고려하여 용량 산정한 데이터센터를 구축하여 대부분의 시간 동안 제대로 활용되지 않는 상태로 두는 대신, 엄청난 규모의 데이터 센터에 CPU 사용량이 가장 많은 프로세스를 구축할 수 있다고 상상해 보라. 필요한 만큼 CPU 사용량을 늘릴 수 있고, 사용한 양만큼만 클라우드 공급자에게 비용을 지불하면 된다. 이러한 것들은 IT 관리자의 눈을 반짝이게 만드는 장점 중 일부에 불과하다. 클라우드는 이 밖에도 아키텍트의 관심을 끌 수 있는 보다 더 흥미로운 특성을 지니고 있다. 클라우드 공급자는 공통 인프라에서 리소스를 호스팅하기 때문에, 개발 및 유지 관리를 간소화시킬 수 있는 서비스를 모든 리소스가 활용할 수 있도록 제공하고 있다. 여기에 해당하는 대표적인 서비스로는 네이밍, 메시지 전송, 로깅, 접근 제어를 들 수 있다. 어떤 리소스라도 클라우드 인프라를 한 번 사용하기만 하면, 해당 리소스 자체에서 그러한 기능의 구현을 제외시킬 수 있다.
클라우드 컴퓨팅에 관한 문헌의 양은 방대할 뿐만 아니라 나날이 증가하고 있다. 여기서 소개한 내용으로 클라우드 컴퓨팅이 지닌 엄청난 잠재력을 확인하기에 충분하지 않다면, 가장 좋아하는 검색 엔진에서 이 용어를 검색해보도록 하라. IT 업계가 클라우드 컴퓨팅을 얼마나 중요하게 받아들이고 있는가를 짐작할 수 있을 것이다. 성실한 아키텍트라면 이 시점에서 “우리 회사도 클라우드 컴퓨팅에 준비가 되어 있을까 ?”라는 궁금증을 가질 것이다. 물론 이 질문에 답하는 것은 그리 간단한 일이 아니다. 여기에는 아키텍처의 여러 가지 측면과 회사의 업무 방식이 고려되어야 한다. 최대한 간단하게 설명하자면, 확고한 서비스 중심(service orientation : SO) 원칙에 따라 비즈니스를 운영하고 있다면, 이러한 신기술을 활용할 수 있는 이상적인 위치에 있는 것이다. 요컨대, 자율성이 중시되고, 정책이 공개되며, 표준이 사용된다면, 서비스가 어디에서 실행되든 누가 상관하겠는가? 만약 이런 위치에 있다면 축하한다. 하지만 경험에 비추어볼 때, 누구도 SO 원칙을 엄청 세세하게 적용하지는 않는다. 예를 들어, 같은 기술로 개발된 서비스들은 상호 간에 호환이 되었을 때 특별한 기능을 제공한다. 그리고 실제로도 이러한 기능을 활용해야지만 완벽하게 말이 되는 상황이 존재한다는 것이다.
아이덴티티 관리 및 접근 제어는 이러한 현상의 영향을 받을 가능성이 높다. 일반적으로 기업은 디렉터리 소프트웨어를 보유하고 있으며, 이 소프트웨어를 리소스 접근 제어와 관련된 여러 방면에서 합법적으로 사용한다. 때로 이러한 소프트웨어는 아주 훌륭하게 작동하여 개발자들이 아이덴티티 개념을 익힐 필요도 없게 만든다. 물론 이는 좋은 현상이지만 실제로는 거의 발생하지 않는다. 디렉터리 외부의 파트너와 연결하거나, 다른 자격 증명 유형을 사용하는 등 일정 형태의 접근 제어 관리를 수반하는 작업을 맡게 되었을 때, 개발자가 최악의 회전 의자식(swivel chair) 통합 솔루션을 가지고 온다고 예상하면 된다. 아이덴티티가 개발 측면에서 가장 나쁜 결과를 가져온다면, 어째서 우리는 아이덴티티와 무리없이 잘 지내고 있을까 ? 이 질문에 안 그럴 때도 있다고 쉽게 대답할 수도 있다. 자신과 관련되어 있는 사례 중 접근 제어가 잘못된 끔찍한 경우를 알고 있을 것이다. 보다 현명한 대답은 다음과 같다. 우리가 아이덴티티와 관련된 이슈로부터 잘 지낼 수 있는 이유는 우리가 인프라의 대부분을 소유하고 우리가 엄격한 거버넌스를 강제하는 한, 그러한 이슈를 처리할 수 있기 때문이다. 이 경우, 필요한 양보다 많은 리소스를 사용할 수도 있고 필요한 것보다 더 자주 비상 상황에 대응할 수도 있지만, 어쨌든 우리는 지속할 수 있다. 사실상 점차 증가하는 시장 압력으로 인해 “인프라의 대부분을 소유”하는 것은 어려워지고 있다. 비즈니스의 많은 부분에서 끊임없는 연결이 필요하고 새로운 파트너를 참여시켜야 한다면, 여러분의 인프라는 어디에서 끝나고 파트너의 인프라는 어디에서 시작되는 것인가? 클라우드 컴퓨팅은 이 질문을 더욱 복잡하게 만들 것이다. 일단 클라우드가 또 다른 배포(운영) 옵션이 되면, 모든 리소스에 대한 고유한 접근 코드를 만드는 것은 불가능해진다.
좋은 소식은 일반적인 분산 시스템에 대해 아이덴티티 및 접근 제어 관리를 지원하는 아키텍처적인 접근법이 존재하며, 이는 사내(on premise), 클라우드 및 하이브리드 시스템에 모두 똑같이 적용될 수 있다는 것이다. 핵심 개념은 거의 모든 것을 클레임 교환과 모델 트랜잭으로 보고 훨씬 더 자연스러운 방식으로 모델링하는 것이다.
이 아티클에서는 이러한 새로운 접근법을 소개한다. 클라우드와 특히 관련이 있는 측면에 특별한 주의를 기울이겠지만, 제시되는 개념과 패턴의 상당부분은 분산 시스템의 특성에 상관없이 적용 가능하다. 여기서 다루고자 하는 문제는 단순한 단일 사이트의 멤버 자격 공급자에 기반한 애플리케이션이 아니라는 점에 유의하길 바란다. 여기서 정해진 원칙은 모든 시스템에 적용된다. 따라서 단순한 상황에도 적용되지만, 파트너 관계, 복잡한 접근 규칙 및 구조화된 아이덴티티 정보를 포괄하는 시나리오에서 그 포괄적인 능력을 최대한 활용할 수 있다.
아래에 나오는 정의를 처음부터 이해하는 것이 어렵다면 고대 로마의 표기법을 사용하여 수를 더했던 중세 시대의 유럽인들이 숫자 “0”을 사용하는 방법을 배우기가 얼마나 어려웠을지 생각해 보도록 한다. 당시 기존 방식의 저항에 부딪혔지만, 더 나은 모델을 채택함으로써 얻은 대가는 더욱 특별했다!

클레임 기반 솔루션 (Claims-based Solutions)
전통적인 아이덴티티 관리 솔루션의 문제는 한 마디로 너무 많은 것을 가정하고 있다는 것이다.
가장 일반적인 가정은 어떤 전지전능한 권한을 가진 중앙 인증 기관이 존재하여 트랜잭션에 참여하는 모든 엔터티를 알고 있어서, 누가 어떤 조건으로 무엇에 접근할 수 있는지 결정할 수 있는 있다고 가정하는 것이다. 이러한 가정은 디렉터리를 통해 관리되는 엔터프라이즈 네트워크와 같은 독립형 시스템에서는 대체적으로 맞지만, 비즈니스 프로세스가 자체적인 아이덴티티 저장소를 갖추고 있는 소프트웨어 패키지 혹은 엑스트라넷에 접근하는 파트너와 고객, 컨설턴트 등과 같은 외부 요소들을 필요로 하기 시작하게 되면 틀린 가정이 된다. 섀도 계정(shadow account) 사용과 같은 전략적 솔루션은 종종 소유하지 않은 무언가를 관리할 수 있는 것처럼 기능해야 하기 때문에 매우 불안정하다.
또 다른 일반적인 가정은 ‘트랜잭션의 모든 참가자는 일관된 아이덴티티 관리 기술을 사용한다‘는 것이다. 다시 한번 말하지만, 이러한 가정은 독립형 시스템(예: 네트워크 소프트웨어)의 경우에는 맞지만, 프로세스에 외부 참가자를 들여놓자 마자 틀린 가정이 된다. 다양한 기술을 수용하는 일반 방식에서는 이러한 상황을 예외로 취급하고 있다. 그 결과, 대체적으로 아이덴티티 전문가(?)라고 여겨지는 개발자가 작성한 수많은 아이덴티티 관리 플러밍 (plumbing) 코드를 리소스 자체에 포함하게 된다. 이는 프리젠테이션 레이어에 비즈니스 로직을 포함하는 것에 대한 오래된 금기보다 더 나쁜 영향을 끼친다. 리소스 내부에서 직접 아이덴티티 플러밍을 처리하는 것은 시스템을 불안정하게 만들고 유지 관리하기 힘들게 할 뿐만 아니라, 시스템 관리자의 삶 또한 암울하게 만든다. 로직이 리소스 자체에 갇혀 있다면, 배포(deploy) 시점에 접근 제어를 어떻게 관리할 수 있겠는가?
클레임에 기반한 접근 방식에서는 각 작업을 원래 소유자인 엔터티에게 할당함으로써 이러한 문제를 방지하며, 모든 참가자의 자율성을 존중해 인위적인 의존 관계와 기대가 형성되는 것을 차단한다. 이것이 바로 좋은 점만 갖춘 SO 아키텍처의 오랜 원칙이다.
이어서 클레임에 기반한 접근 방식에 대해 간략히 설명하도록 하겠다. 이 주제는 그 자체가 아주 방대하다. 사실, 이에 관한 책을 공동 저술한 바 있다. 이 글에서 시사하는 의미를 완벽히 이해하려면 MSDN에서 온라인으로 무료로 이용할 수 있는 Chapter 2(리소스 부분 참조)를 읽어보도록 한다.

기본 정의
여기에서는 클레임 기반 접근법을 살펴보는 과정에서 만나게 될 다양한 개념과 구문에 대한 정의를 소개한다.

클레임 (Claims)
클레임은 또 다른 엔터티(“authority”)에서 명시한 어떤 엔터티(“subject”)에 관한 사실이다.
클레임은 문자 그대로 어떤 주체의 한 측면을 설명하는 모든 것이 될 수 있다. 여기서 주체는 실제 사람일 수도 있으며 추상적인 리소스일 수도 있다. 클레임의 대표적인 예로 “Bob은 22살이 넘는다,” “Bob은 도메인 Contoso.com을 위한 ‘원격 디버거’ 그룹에 소속되어 있다,” “Bob은 Star Alliance 항공사의 Silver Elite 회원이다” 등을 들 수 있다. 클레임은 인증 기관에서 보증한다. 따라서 한 관찰자는 해당 인증 기관의 신뢰성에 따라 해당 클레임이 진술하는 사실을 참으로 간주해야 하는지 여부를 판단할 수 있다.

신뢰 (Trust)
엔터티 B가 발표하는 클레임을 엔터티 A가 참으로 간주한다면 엔터티 A는 엔터티 B를 신뢰한다고 말할 수 있다. 이 정의는 매우 단순하면서도 본 글의 취지에 잘 부합한다. B가 어떤 주체에 대해 말하는 것을 신뢰하면 해당 클레임을 직접 확인하는 데 따르는 번거로움으로부터 A를 해방시켜 준다. 단, 엔터티 A는 여전히 해당 클레임이 실제로 B에 의해 제공되는 것이고 위조가 아니라는 것을 확인해야 한다.

토큰 (Tokens)
보안 토큰은 인증 기관이 서명한 XML 구문으로, 클레임과 (아마도) 자격 증명 정보를 포함한다.
보안 토큰은 아티팩트, 즉 XML 조각(리소스 부분 참조: WS-Security) 으로 다음 두 가지 기능을 수행할 수 있다. 
* 클레임을 전파하는 수단을 제공한다. 
* 암호화 작업을 지원하거나, 자격 증명 인증에 참여할 수 있다.

비대칭 암호화의 속성 덕분에, 토큰이 서명되었다는 사실은 해당 토큰이 포함하는 클레임의 진원지를 확인하는 것을 더욱 쉽게 만든다.
또한, 토큰은 암호화 및 SOAP 메시지의 서명에서 참조될 수 있는 키 및 키에 관한 참조 등과 같은 암호화 자료를 포함하고 있다. 이러한 작업은 자격 증명 확인 과정의 일환으로 이용될 수 있다. 이러한 맥락에서 우리는 호출자가 기존 사용자임을 확인하는 어떤 메커니즘의 일부로 사용될 수 있는 자료를 “자격 증명”이라고 간주한다. 암호 및 인증서가 좋은 예이다(보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, The Tao of Authentication).
토큰은 X509 인증서와 같은 특정 인증 기술의 “프로젝션 (projection)” 일 수 있으며, 발급될 수도 있다. (발급된 토큰의 한 예로 웹 서비스 보안 관련 문맥에서 언급된 것을 들어본 적이 있을만한 널리 사용되는 토큰 형태인 SAML을 들 수 있다.) 시스템은 미래 지향적이어서, 새로운 기술이 등장하면 적합한 토큰 “프로젝션”을 프로필 사양으로 문서화할 수 있다.

STS(보안 토큰 서비스)
보안 토큰 서비스는 WS-Trust에서 설명한 바와 같이 보안 토큰을 발급하는 서비스를 말한다(리소스 부분 참조: WS-Trust).
STS (그림 1 참조)는 RST(보안 토큰 요청) 메시지를 처리하고 RSTR(보안 토큰 응답 요청)을 통해 토큰을 발급할 수 있다. RST 처리는 일반적으로 호출자를 인증하고 호출자 자체를 설명하는 클레임이 포함된 토큰을 발행하는 것으로 이루어진다. STS가 RST에서 수신한 클레임을 변형한 결과물인 클레임을 발급하는 경우도 있다(보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, R-STS).

clip_image002

그림 1. 보안 토큰의 구조

IdM(Identity Metasystem)
IdM( Identity Metasystem)은 클레임 확보를 위해 기술과 상관없이 정의한 추상화 계층을 제공하는 모델이다.
이것은 모델을 온전하게 설명하지 않는 매우 단순화된 정의이다. 예를 들어, 정책 배포 및 시스템 관리를 언급하지 않았다(리소스 부분 참조: WS-Security, WS-Trust).
모든 아이덴티티 기술은 동일한 작업을 수행하는 경향이 있으며, 공통된 패턴을 따르고 거의 동일한 기능 역할을 다룬다. IdM은 이러한 패턴과 역할을 추상적으로 기술하면서, 클레임 교환에 관한 모든 시스템 동작을 모델링한다. 단, 이러한 패턴 및 역할이 특정 기술에 어떤 방식으로 구현되는가에 관한 세부 정보는 남겨둔다. 필요한 추상화 수준은 WS-* 사양의 제품군과 같이 상호 운용 가능한 개방형 프로토콜을 활용하여 달성한다.
IdM은 다음 세 가지 역할을 설명한다. 
* 주체(Subject). 주체는 클레임 정의에서 언급했던 주체 엔터티로, 트랜잭션에서 확인되어야 하는 누군가(또는 무엇)을 의미한다.
* RP(Relying Party). RP는 이용하기 전에 인증을 거쳐야 하는 리소스이다. RP의 예로 웹 사이트와 웹 서비스를 들 수 있다. RP라는 명칭은 확인해야 하는 주체에 관한 클레임을 확보하기 위해 IP에 의존(rely)한다는 사실에서 유래한 것이다. 
* IP(Identity Provider). IP는 클레임 정의에서 언급했던 인증 기관 엔터티를 말한다. IP는 주체에 관한 정보를 소유하며 클레임 형태로 주체를 표현할 수 있다. 특정 IP를 신뢰하는 모든 RP는 이러한 클레임에 의존하여 주체에 대한 인증 및 권한 부여와 관련된 결정을 내릴 수 있다. 참고: 종종 IP는 STS를 사용하여 토큰 형태로 클레임을 발급하지만, 이것이 곧 모든 STS가 IP임을 의미하는 것은 아니다. STS는 IP가 작업을 완료하기 위해 사용하는 도구이다.

Posted by 장현춘

댓글을 달아 주세요

어느새 아키텍처 저널 24호가 발행되었다. 이번 호에서는 가상화라는 주제하여 다양한 분야의 전문가가 기고하는 형태로 작성되었다. 포함되어 있는 아티클은 다음과 같다.

image

The Impact of Virtualization on Software Architecture

How Virtualized Corporate Networks Raise the Premium on System Reliability

Virtualization: Without Control, Power Is Nothing

Models and Application Life-Cycle Management

Getting the Most Out of Virtualization

From Virtualization to Dynamic IT

 

아키텍처 저널의 홈 페이지는 아래와 같다. 현재 아티클 각각에 대한 한글화 작업이 진행중이며, 아티클에 따라 어떤 것은 한글로 어떤 것은 영어로 게시되어 있다. 한글로 번역된 아티클은 PDF 버전의 문서를 다운로드 받을 수 있도록 아티클별로 링크를 가지고 있다. 현재 총 3개의 아티클이 번역을 마치고 게시되어 있으며, 6개의 아티클이 번역 혹은 리뷰 과정에 들어가 있다. 번역은 시대 흐름과 맞는 주제를 우선적으로 선별하여 해당하는 아티클들을 일괄 번역하고 있으며, 가급적 근래에 발행된 아티클을 번역하고자 한다.

한글 : http://msdn.microsoft.com/ko-kr/architecture/bb410935(en-us).aspx 
영문 : http://architecturejournal.net

bb410935_JournalLogo(en-us,MSDN_10)

Posted by 장현춘

댓글을 달아 주세요

AJ19_cover 지난 포스팅에 이어 이번에도 아키텍처 저널 19권 중 애플리케이션을 클라우드에 매핑이라는 아티클의 번역물을 이어 올린다.  지난 포스팅은 애플리케이션을 클라우드에 매핑하기 위해 필요한 사항을 점검하는 방법에 대해서 알아보았다면, 이번 포스팅은 지난번 흐름을 이어 클라우드에 적합한 시스템을 예를 들어가면서 클라우드에서 설계할 때 주의할 사항들에 대해 논의한다. 마지막에는 클라우드에 매핑할 때 사용하는 기준인 각종 특성들에 대한 목록을 부록으로 제공하고 있다.

지난 포스팅은 아래에서 확인할 수 있다.
http://kingcrap.com/entry/아키텍처-저널-번역-19권-애플리케이션을-클라우드에-맵핑-12

MSDN 한글화 작업도 마무리가 되었다. 관련 링크는 아래에서 확인 할 수 있다.
http://msdn.microsoft.com/ko-kr/architecture/aa699427.aspx
이 아티클의 한글화된 PDF 버전은 아래 링크에서 다운로드 받을 수 있다.
http://msdn.microsoft.com/ko-kr/aa699428.aspx
------------------------------------------------

하나의 클라우드로 모든 애플리케이션 지원
하나의 클라우드가 존재하는가, 다수의 클라우드가 존재하는가? 이는 필자가 지금까지 수도 없이 많이 들어온 논쟁이다. 이 논쟁의 일면에는 퍼블릭 클라우드와 다른 프라이빗 클라우드가 존재한다. 사적으로 구현한 클라우드 기술을 클라우드라고 할 수 있는가, 아니면 다른 것으로 봐야 할까? 모든 퍼블릭 클라우드는 동일한 기능을 제공하는가? 프라이빗 클라우드와 퍼블릭 클라우드를 혼합하여 함께 사용하는 애플리케이션이나 시스템의 경우는 어떠한가? 그리고 이들은 어디에 해당하는가?

그림 5. 티켓팅 시스템에 클라우드 인프라 이용 
aa699427_art1fig5(en-us,MSDN_10) 이러한 논쟁은 무의미하다는 것이 필자의 솔직한 의견이다. 어떤 이론에 동의하든 원하는 결과는 같다. 즉, 실제로 작동하는 가능한 가장 경제적인 시스템을 구축하는 것이다. 이전 섹션에서는 결정을 내리는 데 도움이 되는 방안을 논의했다면 지금부터는 클라우드에 존재하거나 혼합 클라우드 솔루션의 일부로 존재할 수 있는 애플리케이션에 대해 간략하게 살펴볼 것이다.

클라우드에서 솔루션 아키텍처 설계 하기
이 섹션에서는 클라우드 서비스를 사용하여 구현할 수 있는 솔루션에 대한 세 가지 애플리케이션 시나리오를 설명한다. 다음 시나리오는 클라우드 서비스를 사용할 수 있는 포괄적인 솔루션 목록이 아니며, 실현 가능한 애플리케이션을 몇 가지 제시한 것에 불과하다.

티켓팅 시스템
클라우드 인프라의 장점에 대해 논의할 때, 콘서트 티켓팅 시스템이 클라우드 시나리오에 적합하다는 것에 대해서는 대체로 의견 일치를 보인다(그림 5). 표면적으로는 이런 유형의 애플리케이션이 적합해 보인다. 티켓팅 시스템은 짧은 기간에 많은 수요를 감당해야 하는 경우가 많다 (사람들은 곧 매진될 콘서트 또는 스포츠 경기의 티켓을 사기 위해 몰려든다). 이 기간이 지나면 작업량이 적거나 중간 정도인 수준의 기간이 길게 이어진다.
  티켓팅 애플리케이션은 수요가 많은 기간 동안에, 즉 컴퓨팅 리소스 요구량이 아주 많은 시기에는 과부하되는 경우가 많다. 이러한 시기를 감당하기 위해서는 가상 시스템의 인스턴스를 실행할 수 있는 기능이 효과적이다. 단, 이러한 솔루션의 아키텍처 설계시에 다음과 같은 몇 가지 이슈를 반드시 고려해야 한다.

  • 티켓팅 시스템은 데이터 사용량과 트랜잭션이 아주 많다. 어떤 주어진 이벤트에 특정 좌석을 예약하거나 결제를 하기 위해서 트랜잭션이 필요할 수 있다.
  • 많은 고객이 해당 티켓팅 회사에 계정이 있거나 계정 생성을 원할 수 있으므로, 개인 식별 정보를 수집해야 한다.
  • 신용 카드 결제 확인에는 많은 시간이 소요될 수 있으며, 이는 티켓팅 프로세스에서 나타나는 병목 현상의 원인이 될 수 있다.
  • 일부 가상 서버 플랫폼은 상태를 저장할 수 없다. 이는 서버 이미지가 종료되면 해당 이미지 내에 저장된 데이터에 대한 모든 변경 내용이나 추가 내용이 손실된다는 것을 의미한이다.
  • 기존 티켓팅 회사들은 이미 인프라 및 데이터 관리에 상당한 규모의 투자를 하였다.
  • 선택하는 클라우드 서비스에 따라, 상태를 저장할 수 없는 가상 클라우드 서버 이미지의 경우, 정보를 이벤트마다 다시 생성해야 하는데, 이렇게 되면 각각의 새로운 인스턴스에 맞는 환경을 준비하기 위해 상당량의 작업을 수행해야 한다.

이러한 점들을 염두에 두면 클라우드 서비스를 이용하여 최대 부하 시간에 기존 시스템에 대한 수요를 줄일 수 있는 여러 가지 방법이 존재한다.

그림 6. 사진/비디오 처리에 클라우드 인프라 이용
aa699427_art1fig6(en-us,MSDN_10)

  • 내부 시스템을 완벽하게 이중화. 가장 많은 양의 작업이 필요하다. 이는 애플리케이션을 사용할 준비가 되면 새로운 인스턴스가 만들어질 때마다 기존 시스템과 동기화해야 하기 때문이다. 시스템을 계속 켜둔 상태로 두면 (용량이 줄어든 상태라 할지라도) 서비스 플랫폼 사용 비용 때문에 많은 비용이 들 수 있다.
  • 내부 시스템과 클라우드 시스템 간의 워크로드를 실시간으로 분리. 두 개의 환경에서 좌석 선택과 티켓 구입 과정을 분리하는 것이다. 예를 들어, 내부 티켓팅 시스템에서 트랜잭션이 시작되어 고객이 계정에 로그인하고 참석하고자 하는 이벤트를 선택하고 좌석을 정하게 되면, 최종 결제 처리를 위해 클라우드 서비스로 넘어가는 것이다. 즉, 단순히 마지막 처리 단계를 완료하는 가상 클라우드 서버를 구축하는 것이기 때문에 주 시스템과 동기화할 필요가 없고, 효과적인 상태 비저장 처리 엔진 역할을 할 수 있다. 최소한의 데이터만 클라우드 서비스에 전송하면 되고 신용카드 정보는 일회용으로 외부 시스템에 수집한 후 삭제할 수 있다.
  • 일괄 처리를 통해 내부 시스템 간의 워크로드 분리. 앞서 말한 처리 방식과 비슷하지만, 이 방식은 참조 정보를 포함한 모든 개인 정보를 내부 시스템에 수집한다는 점에서 차이가 있다. 그런 다음, 이러한 정보는 프로세스 대기열에 있다가 클라우드 서비스로 일괄 전송되어 처리된다. 즉, 결제가 실패하면 티켓 구입을 시도하는 사람과 연락하는 보조 프로세스를 구현해야 한다.

상기의 솔루션은 사용량이 많은 기간 동안 티켓팅 시스템이 클라우드 서비스와 회사 내부 시스템 간에 처리 작업을 어떤 방식으로 분리할 수 있는지를 보여주는 사례이다.

그림 7. 최대 로드 지원을 위해 클라우드 인프라 사용
aa699427_art1fig7(en-us,MSDN_10)

포토/비디오 처리
이 예는 다수의 서비스(인프라, 저장소, 대기)를 결합하여 하나의 데이터 처리 솔루션을 제공하는 방법을 보여준다(그림 6). 이 시나리오에는 디지털 미디어 파일을 렌더링하거나 포맷을 변경하기 위해 클라우드 서비스를 이용하는 포토 처리점들이 처리 체인점이 있다.
  이 포토 체인은 미국 전역에 수많은 매장을 두고 있으며, 대규모 이미지 및 비디오 처리를 중앙 집중화하여 시스템의 두 가지 측면, 즉 각 저장소매장의 하드웨어 수와 하드웨어 유지 보수 및 지원 작업의 복잡성을 줄이고자 한다.
  고객이 다른 포맷으로 변환해야 하는 비디오와 함께를 들고 매장을 방문하면, 먼저 해당 비디오 파일을이 먼저 저장소 서비스로 업로드시킨다. 그러면 ‘파일이 저장소 플랫폼에 있으며 다른 포맷으로 변환해야 한다’는 메시지가 대기열 서비스에 배치된다. 컴퓨터 인스턴스를 실행하는 애플리케이션 컨트롤러가 대기열에서 이 메시지를 받은 후, 가상 시스템의 기존 인스턴스를 사용하거나 새로운 인스턴스를 만들어 비디오의 포맷 변경을 처리한다. 이 프로세스가 완료되는 즉시, 컨트롤러는 프로젝트가 완료되었음을 매장에 알리기 위해 대기열에 메시지를 배치한다.
  상기 시나리오는 온라인 환경으로 쉽게 바꿀 수 있기 때문에, 고객은 실제 매장을 방문할 필요 없이 파일을 업로드하여 처리할 수 있다.

웹 사이트 최대 로드 처리
마지막으로 트래픽이 불규칙하게 매우 많아져서 이러한 최대 로드를 지원할 수 있는 호스팅 인프라를 구축하는 것이 현실적으로 불가능한 웹 사이트의 예를 들어보도록 하겠다(그림 7). 긴급 뉴스속보가 있는 뉴스 사이트, 새로운 게임을 발표하는 게임 사이트, 새로운 블록버스터의 예고편을 보여주는 영화 사이트가 여기에 해당된다.
  이 시나리오에 대한 솔루션은 회사 웹 사이트의 완벽한 복사본을 생성하는 것이다. 즉, 웹 사이트의 일부가 클라우드 서비스 인프라 서비스에서 많은 트랙픽을 처리하는 것이다. 사이트의 복사본은 로드 밸런싱된 일련의 서버 또는 클러스터로 구성 가능한 수많은 웹 서버에서 실행되는 정적 인스턴스가 될 것이다. 원본 웹 사이트에 필요한 변경 작업을 수행한 다음 이를 클라우드 서버에 동기화할 수 있다. 이렇게 하면 지연이 발생하겠지만, 웹 서버와 웹 사이트를 유지 관리하는 데 드는 수고를 크게 줄이고 내부 호스팅 웹 사이트와 외부 호스팅 웹 사이트 간 상태를 유지 관리하는 문제를 해소할 수 있다.
  클라우드 서비스를 사용할 수 있는 시나리오가 더 많이 있으므로 상기 시나리오를 위한 솔루션을 설계하는 방법도 많이 있다. 여기서는, 새롭게 등장하고 있는 서비스의 활용 사례와 몇 가지 대안을 조명하는 것으로 마무리하고자 한다.

결론

클라우드 및 클라우드 기술이 지닌 매력 때문에 많은 개발자, ISV, 신생 기업 및 대기업은 클라우드 서비스를 면밀히 검토하고 도입의 적합성 여부를 진단하고 있다. TCO 비용 절감과 더불어 저장소 및 인프라의 무제한 확장 가능성을 무시하기 어렵다. 클라우드의 가능성은 확실히 검토할 만한 것이지만, 클라우드 서비스 도입은 신중하게 다루고 아울러 모든 애플리케이션이 클라우드에 적합한 것은 아니라는 사실을 명심해야 한다. 많은 애플리케이션이 클라우드에서 운영될 것이다. 하지만, 클라우드에 일부 솔루션을 호스팅하는 데 드는 부대 비용으로 인해 일부 프로젝트의 경우, 잘 정립된 전통적인 아키텍처 및 기술에 비해 훨씬 더 많은 개발 및 운영 비용이 들 수도 있다.

저자 소개
Darryl Chantry는Microsoft Platform Architecture 팀의 수석 아키텍트이다. 엔터프라이즈 아키텍트, 솔루션 아키텍트, 인프라 아키텍트로 근무한 경험을 바탕으로 폭넓은 기술력을 보유하고 있다. Darryl은 뉴질랜드 오클랜드에서 나고태어나 자랐으며 2002년에 Microsoft의 New Zealand Developer & Platform Evangelism 팀에 합류했다. 럭비를 매우 좋아하며 인류학, 역사 및 사용자 경험에 특별한 관심을 가지고 있다. Darryl 부부는 현재 보어보엘 개 한 마리와, 버마산미즈 고양이 두 마리와 함께 워싱턴 레드몬드에서 살고 있다.

관련 자료

부록 A

aa699427_appAfig1(en-us,MSDN_10)
aa699427_appAfig2(en-us,MSDN_10)

 부록 B

클라우드 인프라 플랫폼 및 가상화 유형
클라우드 컴퓨팅 플랫폼의 핵심 지원 기술 중 하나는 가상화, 즉 컴퓨팅 리소스를 추상화할 수 있는 기술이다. 오늘날 클라우드 인프라 플랫폼은 크게 전체완벽히 가상화된 환경 아니면 또는 부분 반가상화된 (paravirtualized) 환경으 이 두 가지 형태로 구축된다.
방금 언급한 두 가지 이외에도 변형된 형태의 가상화 기술이 더 많지만, 이 글의 목적상 현재 존재하고 클라우드 인프라 솔루션에 원활하게 통합 가능한 몇 가지 가상화 방식만 논의하도록 하겠다.

에뮬레이션
이 유형의 가상화에서는 가상 환경이 수정되지 않은 게스트 OS (운영 체제)가 필요로 하는 하드웨어 아키텍처를 에뮬레이트한다. 에뮬레이트된 하드웨어를 접하게 되는 일반적인 경우 중 하나는 모바일 장치를 사용하는 경우이다. 애플리케이션 개발자는 에뮬레이트된 환경을 통해, 예를 들어 스마트폰이나 PDA에서 실행되도록 설계된 애플리케이션을 테스트할 것이다(그림 8 참조).

그림 8. 에뮬레이트된 가상화 환경 
aa699427_art1fig8(en-us,MSDN_10)

장점: 기본 하드웨어와 완전히 다른 하드웨어 환경을 시뮬레이션한다. 데스크톱에 에뮬레이트되는 스마트폰 등의 모바일 장치를 예로 들 수 있다.
단점: 성능 수준이 낮고 리소스 사용량이 많다.

전체 가상화
전체 가상화에서는 가상화 환경 내에 수정되지 않은 완전한 게스트 OS의 이미지가 생성되고 실행된다. 전체 가상화와 에뮬레이션의 차이점은 모든 가상화 게스트가 동일한 하드웨어 아키텍처에서 실행된다는 것이다. 모든 게스트가 동일한 하드웨어를 지원하므로 게스트가 하드웨어에서 많은 명령을 직접 실행하여 성능을 향상시킬 수 있다(그림 9참조).

그림 9. 전체 가상화 환경 
aa699427_art1fig9(en-us,MSDN_10)

장점: 여러 공급업체가 제공하는 여러 버전의 OS(예: Microsoft Windows Server 2003, Windows Server 2008, Linux, and UNIX)를 실행할 수 있다.
단점: 가상화 이미지는 전체 OS를 설치하는 것이므로 파일 용량이 매우 커질 수 있다. 전체 가상화 환경에서는 (특히 일반 하드웨어에) 심각한 성능 문제가 발생하고 입출력 작업이 많은 애플리케이션이 부정적인 영향을 받을 수 있다.

부분 반가상화(Para-Virtualization)
부분 반가상화에서는 하이퍼바이저가 물리적 하드웨어의 수정 복사본을 내보낸다. 내보낸 계층은 서버 하드웨어와 아키텍처가 동일하다. 하지만 게스트 OS가 네이티브에 가까운 속도로(near-native speeds) 작동하게 하려면 이 계층에 특정 수정 작업을 수행해야 한다. 이처럼 수정된 호출을 활용하려면 게스트 OS를 약간 수정해야 한다. 예를 들어, 물리적 하드웨어에서 기대하는 것과 동일한 수준의 기능을 제공하는 하이퍼콜(hypercall)을 이용하기 위해 게스트 OS를 수정할 수 있다. 단, 하이퍼콜을 이용할 경우 가상화 환경에서 실행될 때에 게스트의 효율성이 크게 향상된다(그림 10 참조).

그림 10. 부분 반가상화 환경 
aa699427_art1fig10(en-us,MSDN_10)

장점: 소규모로 가볍고 속도가 빠르다. 이미지 크기가 크게 줄어들고 성능이 네이티브에 가까운 속도로 향상될 수 있다. 일반적으로 전체 가상화를 지원하지 않는 아키텍처를 가상화할 수 있게 해 준다.
단점: 게스트 OS가 네이티브 기능에 대해 하이퍼콜을 지원하려면 게스트 OS를 수정해야 한다.

OS 레벨 가상화
OS 가상화에서는 가상 시스템이 없고 전적으로 단일 OS 내에서 가상화가 이루어진다. 게스트 시스템은 기본 OS의 공통된 기능과 드라이버를 공유하며, 완전히 분리된 컴퓨터와 모양과 느낌이 유사하다. 각 게스트 인스턴스는 자체적인 파일 시스템, IP 주소 및 서버 구성을 가지며 완전히 다른 애플리케이션을 실행한다(그림 11 참조).

그림 11. OS 가상화 환경 
aa699427_art1fig11(en-us,MSDN_10)

장점: 소규모로가볍고 속도가 빠르며고 효율적이며 대량의 가상 인스턴스를 지원할 수 있다.
단점: 인스턴스 격리 및 데이터 관련 보안이 중대한 문제이다. 가상 인스턴스는 반드시 동일한 OS를 지원해야 한다.

애플리케이션 가상화
여느기타 다른 유형의 가상화와 마찬가지로 애플리케이션 가상화를 위해서는 가상화 계층이 존재해야 한다. 가상화 계층은 가상화 애플리케이션이 기본 파일 시스템으로 보내는 모든 호출을 가로채어 가상 위치로 리디렉션한다. 애플리케이션은 물리적 플랫폼으로부터 완전히 분리되어 가상화 계층하고만 상호 작용한다. 이렇게 되면 상호 호환되지 않는 애플리케이션을 병렬로 실행할 수 있다. 예를 들어, Microsoft Internet Information Services 4.0, 5.0 및 6.0을 모두 병렬로 실행할 수 있다. 또한, 설계 시점에서 염두에 두지 않은 OS에서도 애플리케이션을 원활하게 실행할 수 있도록 지원함으로써 애플리케이션의 이동성을 향상시켜 준다(그림 12 참조).

그림 12. 애플리케이션 가상화 환경 
aa699427_art1fig12(en-us,MSDN_10)

장점: 애플리케이션의 이동성을 향상시켜 서로 다른 운영 환경에서도 실행할 수 있게 해 준다. 호환되지 않는 애플리케이션의 병렬 실행을 지원하고, 주문형 애플리케이션 스트리밍을 통해 애플리케이션 구축 속도를 향상시켜 준다.
단점: 가상 시스템 지원에 따른 부담으로 런타임 및 네이티브 환경 모두에서 애플리케이션의 실행 속도가 더 늦어질 수 있다. 모든 소프트웨어를 가상화할 수 있는 것은 아니므로 완벽한 솔루션이 되지 못한다.

Posted by 장현춘

댓글을 달아 주세요

AJ19_cover 이번 번역물은 아키텍처 저널 19권에 실려있는 "애플리케이션을 클라우드에 매핑"이라는 아티클을 번역한 것으로 현재 클라우드 컴퓨팅에 관한 관심이 고조되고 여기 저기서 비지니스를 위해 어떻게 활용할 것인지를 고민하고 있는 시점에서 시기적절한 주제인 듯 하다. 내용을 간단히 요약하면 다음과 같다.
- 어떤 것들을 클라우드에 올릴 것인지, 혹은 새로 만드는 것을 클라우드에서 개발해야하는지 등에 대한 논의가 많은데, 이에 대한 가이드를 제공한다.
- 클라우드에 적합한 애플리케이션인지 아닌지를 판단하기 위해서 혹은 어떤 클라우드 사업자가 가장 적합한지를 판단하기 위해 고려해야 할 것들이 있다.
- 먼저, 고려 중인 애플리케이션의 특성을 부록에 나와 있는 속성들을 기준으로 드릴다운해가며 정리한다. 예를 들면, 데이터 관리 --> 접근 방식 --> 온라인/오프라인 혹은 둘다 --> 둘다인 경우에는 싱크도 고려, 오프라인만인 경우 클라우드 부적합 등
- 그 다음, 클라우드 서비스의 특성을 다섯 가지 특성, 즉, 클라우드 인프라, 클라우드 스토리지, 클라우드 플랫폼, 클라우드 애플리케이션, 핵심 클라우드 서비스로 구분하여 각각의 특성을 드릴 다운하여 정리한다. 각 사업자의 장단점도 함께 기술한다.
- 이러한 과정을 통해 클라우드에 적합한 애플리케이션인지, 그렇다면 가장 적합한 클라우드 사업자는 누구인지 등을 하나하나 체크해볼 수 있다.
오늘 올리는 부분은 여기까지이며, 다음에 이어서 올릴 부분은 티켓팅 시스템을 예로들어 클라우드 기반으로 구현할  때 고려 사항을 살펴보고, 구분의 기준이 되는 각종 속성들을 부록으로 제공하고 있다.

---------------------------------------------------
요약
전 세계적으로 경제적 압박이 커지면서 많은 기업들이 IT 관련 TCO(총 소유 비용)를 절감하기 위한 대안으로 클라우드 컴퓨팅에 눈을 돌리기 시작했다. 클라우드 컴퓨팅 기술을 활용하는 방법을 모색할 때에 기업들은 “비즈니스 특성상 클라우드 컴퓨팅을 고려할 수 있는가?”와 같은 질문 등을 자문해 봄으로써 클라우드로 이동하기에 적합한 애플리케이션과 그렇지 않은 애플리케이션을 점검하는 과정을 거쳐야 한다.
이 글은 클라우드 컴퓨팅의 개념을 개괄적으로 설명하고, 자신의 애플리케이션이나 비즈니스 모델이 클라우드로 이동하기에 적합한지 여부를 판단하는데 도움이 되도록 엔터프라이즈 애플리케이션을 클라우드 컴퓨팅 플랫폼에 매핑하는 방식에 대해 논의한다.

클라우드가 먼저인가, 클라우드 컴퓨팅이 먼저인가?
클라우드 컴퓨팅은 소규모 ISV(Independent Software Vendor), 실리콘 밸리 신생 기업, 비용 절감을 모색하는 대기업 등 전 세계 수많은 IT(정보 기술) 전문가들의 상상력에 불을 지피고 있다. 모든 IT 문제를 해결할 특효약을 개발하기 위해 클라우드에 주목하는 사람들이 점점 늘어나는 추세이다.
클라우드 컴퓨팅에 관한 대대적인 광고에서 한 가지 흥미로운 점은 무엇이 클라우드 컴퓨팅은 무엇인지, 그리고 클라우드 컴퓨팅이 아닌 것은 무엇인지에 관한 명확한 정의가 결여되어 있다는 것이다. 100명의 사람들에게 클라우드의 정의와 클라우드 컴퓨팅이 무엇이라고 생각하는지에 대해 묻는다면 아마도 150개의 다른 답변을 듣게 될 것이다. 두 번 대답하길 좋아하는 어떤 사람들은 두 번째 대답을 하는데 첫 번째 대답이 두 번째 대답과 모순되게 말하기도 한다. 이러한 실정을 감안한다면 클라우드 컴퓨팅에 대한 전반적인 정의를 먼저 살펴보는 것이 적절할 듯 싶다.
클라우드(또는 ‘인터넷’이라고 하자)가 등장한 지 25년 정도 되었으니 의심할 여지 없이 클라우드가 클라우드 컴퓨팅보다 먼저가 아닐까? 혹자는 인터넷에 최초로 설치된 서버는 사실상 데이터와 애플리케이션을 전역에서 공유 및 실행하기 위해서, 즉 전역적으로 여러 곳에 구축된 클라우드 컴퓨팅 리소스에 거의 무한에 가까운 확장성을 제공하기 위해 설치된 저장 장치였다고 주장할 수도 있을 것이다. 이를 주로 데이터, 애플리케이션 및 컴퓨팅 성능에 거의 무한한 확장성을 제공하기 위해 존재하는 오늘날의 클라우드 컴퓨팅 이니셔티브와 비교해 보면 그 차이점을 쉽게 알 수 있지 않을까? 아니 사실 차이점이 있기나 할까?
  차이점은 오늘날에는 신기술을 사용하여 오래된 개념을 새롭게 해석하기 위해 신기술을 사용하고 있다는 것이다. 클라우드 컴퓨팅은 이러한 사고를 기반으로 유틸리티 기반의 사용량 기준 결제 (pay-for-what-you-use) 방식을 통해 예산에 구애 받지 않고 이용할 수 있는, 혁명보다는 진화에 가까운 기술이다.

유틸리티 컴퓨팅
유틸리티 컴퓨팅은 전기나 물을 사용하는 것과 같이 사용한 만큼만 비용을 지불하는 미터제 서비스로 컴퓨팅 리소스(인프라, 저장소, 핵심 서비스)를 사용하는 것을 말한다. 유틸리티는 하드웨어, 서버, 애플리케이션 플랫폼을 구입, 운영, 유지 관리하고 과금 또는 보안 서비스와 같은 핵심 서비스를 개발해야 하는 필요성을 해소시킬 수 있다. 다음 시나리오를 참고하도록 하자.
Facebook 또는 MySpace를 위한 구성 요소를 제공하려는 웹 기반 ISV는 다음과 같은 딜레마에 빠지고 만다. 이들이 개발하는 구성 요소는 수천 명이 채택하거나, 어떤 형태로든 받아들여지기 위해 고군분투하게 될 수도 있을 것이다. 대부분의 ISV는 자본금이 부족하기 때문에 애플리케이션 개발 비용과 소프트웨어 지원을 위한 인프라 제공 비용 지출 사이에서 적절한 균형을 유지해야 한다.
이러한 비용 조정 조치는 플랫폼 지원은 우수하지만 성능이 좋지 않은 애플리케이션을 낳을 수도 있고 또는 성능은 우수하지만 미흡한 플랫폼 지원으로 거의 액세스가 불가능한 애플리케이션을 낳을 수도 있다. 둘 중 어떤 시나리오도 성공하기는 힘들다. 바로 이런 경우에 유틸리티 기반의 클라우드 플랫폼이 도움이 된다. 클라우드 유틸리티 플랫폼은 ISV의 애플리케이션에 대한 수요를 충족시키기 위해 손쉽게 확장할 수 있는 경제적인 대안 솔루션을 제공함으로써 사실상 보유하고 있는한 모든 리소스를 우수한 애플리케이션을 구축하는 데 사용할 수 있도록 지원한다.
클라우드 서비스는가 근기본적으로 유틸리티 솔루션으로 제공되기 때문에, 제품에 장애가 발생하는 경우 ISV는 서비스를 차단하고 해당 소프트웨어와 관련된 모든 비용 지출을 중단하면 된다.
또한, 유틸리티 모델을 통해 기업은 추가 인프라 리소스를 제공하여 최대 부하를 관리함으로써 사설 데이터 센터 운영 비용의 일부를 상쇄할 수 있는데, 이를 일컬어 클라우드 버스팅(cloud bursting)이라고도 한다.
전통적으로 최대 부하를 처리하기 위해 기업들은 주로 최대 부하를 감당할 수 있는 처리 능력을 갖추도록 데이터 센터를 설계하였다. 이는 곧 최대 부하에 이르지 않는 대부분의 시간 동안 데이터 센터가 저조한 활용도를 보인다는 것을 의미한다. 클라우드 버스팅을 이용하는 기업은 각자의 환경에서 일상적인 모든 워크로드를 처리할 수 있는 사양으로 데이터 센터를 구축한 후 클라우드 공급자를 통해 추가 리소스를 제공하여 최대 부하를 감당할 수 있다.
유틸리티 컴퓨팅은 대규모 데이터 센터를 통해 사용자에게 거의 무한한 저장소 용량 또는 컴퓨팅 성능을 제공할 수 있도록 하는 일정 형태의 가상화 플랫폼과 연관되는 경우가 많다. 클라우드 컴퓨팅의 진화는 현재 기본적인 인프라를 넘어 서비스를 포함하는 개념으로 유틸리티 컴퓨팅의 정의를 확대하고 있다.

모든 애플리케이션을 클라우드로 이동할 것인가?
모든 애플리케이션을 클라우드에서 운영할 것인가? 기존 애플리케이션을 모두 클라우드로 이동시켜야 할 것인가? 모든 신규 애플리케이션을 클라우드에서 개발할 것인가? 클라우드란 도대체 무엇인가?  이는 클라우드 서비스 사용을 고려하기 시작할 때하면 생겨나는 이런 의문들이다.
클라우드 플랫폼으로 이동하고 클라우드 플래폼에서 개발하거나 클라우드 인프라에 호스팅하기에 적합한 애플리케이션이 있는가 하면, 클라우드를 사용하기에 부적합한 애플리케이션도 있다. 전술한 모든 질문에는 “상황에 따라 다르다”라는, 아키텍처에 관한 기본 해답이 통할 수 있을 것이다. 실제로 모든 애플리케이션의 일부 또는 전체가 클라우드에 있을 수 있다. 한 가지 주의해야 할 점을 들자면, 클라우드로 이동하고자 하는 애플리케이션의 특성 및 (가능한 경우) 기능의 장단점이다.
다음 페이지에서는 특정 애플리케이션을 클라우드에서 운영하는 것이 실용적인가에 대한 결정을 내리는 데 도움이 되도록 애플리케이션과 클라우드를 기본적인 속성들로 분해하기 위한 몇 가지 방안을 논의한다.

애플리케이션을 클라우드에 매핑
주문 관리 시스템, 항공 예약 시스템, CRM 애플리케이션 등을 비롯한 모든 애플리케이션은 특정 목적을 충족하기 위해 설계된다. 애플리케이션의 기능을 구현하려면 일정한 특성들이 존재해야 한다. 예를 들어, 주문 관리 시스템의 경우에는, 애플리케이션의 트랜잭션 및 잠금 지원이 애플리케이션에 무엇보다 중요하다. 이는 클라우드 저장소가 이러한 목적의 데이터 저장소에는 적합하지 않을 수도 있다는 것을 의미한다. 특정 애플리케이션 혹은 대규모 애플리케이션의 하위 시스템이 갖는 주요 특성을 파악하는 것은 특정 애플리케이션이 클라우드에 적합한지 여부를 판단하는 데 있어 매우 중요한 과정이다.

그림 1. 애플리케이션의 특성 맵
그림1

그림 1은 모든 애플리케이션과 연관될 수 있는 여러 가지 주요 상위 특성(파란색 열)을 보여준다. 특정 애플리케이션에 존재할 수 있는 특성의 수를 기록할 필요는 없다. 해당 애플리케이션의 중요한 특성이 무엇인가만 판단하면 된다. 이렇게 하면 관리하기 쉬운 특성 목록을 작성하여 클라우드에 매핑할 수 있다. 예를 들어, 데이터 관리를 선택하면 상위 수준의 특성에 대해 보다 자세한 정보를 제공하는 부차적인 특성의 목록이 나타난다. 액세스를 선택하면 데이터 소스에 온라인 액세스, 오프라인 액세스, 온라인과 오프라인으로 모두 액세스하는 방식 중에서 원하는 것을 지정할 수 있다.
데이터 액세스 사례를 통해 이 특성이 클라우드 공급자를 통해 데이터 저장소를 이용할지 여부를 선택하는 데 있어 어떤 영향을 미치는지 확인해 볼 수 있다. 문제의 애플리케이션이 순수하게 온라인 데이터만 필요로 한다면, 클라우드 저장소가 탁월한 선택이 될 것이다. 반면, 오프라인 데이터만 필요하다면 이는 해당 애플리케이션이 클라우드에 적합하지 않다는 것을 알려주는 중요한 지표가 될 수 있다. 애플리케이션에 온라인 모델과 오프라인 모델이 모두 필요한지를 결정해야 한다면, 애플리케이션과 클라우드 간의 데이터 동기화를 위한 애플리케이션 개발 비용을 고려해야 한다.
최종 사용자를 위해 오프라인 및 온라인 액세스를 모두 지원하기로 선택하는 경우에는 프로젝트 비용이 추가로 늘어날 것이다. 하지만 만약 우수한 확장성과 같은 또 다른 특성이 파악된다면 이 영역에서 클라우드가 제공하는 이점이 오프라인 액세스환경 개발에 소요되는 비용을 쉽게 상쇄시킬 수 있을 것이다. (6페이지에 있는 부록 A, 애플리케이션 매핑 특성 참조)

그림 2. 애플리케이션 특성을 클라우드 특성에 매핑 

aa699427_art1fig2(en-us,MSDN_10) 클라우드 구성 요소
애플리케이션을 분해하고 주요 특성을 파악했다면 클라우드,( 특히 클라우드 서비스 공급자)에 대해서도 비슷한 작업을 시작할 수 있다. 클라우드 특성을 개괄적인 범주로 분리하면 매핑 프로세스를 간소화할 수 있다. 이 예에서 사용된 범주는 클라우드 인프라, 클라우드 저장소, 클라우드 플랫폼, 클라우드 애플리케이션, 그리고 핵심 클라우드 서비스이다.
그림 2와 같이 모든 애플리케이션 특성을 하나 이상의 범주로 구분된 클라우드 특성에 매핑할 수 있다.

클라우드 인프라
클라우드 인프라는 인프라, 또는 보다 일반적으로으로 말해 클라우드에 있는 가상 서버를 말한다. 인프라 솔루션은 대규모 프로세스나 애플리케이션을 지원하는 처리 능력이다. 대규모 애플리케이션의 예로는 Facebook이나 MySpace를 생각할 수 있고, 대규모 처리 능력의 경우는 항공기나 자동차 제조를 위해 엔지니어링 스트레스 테스트 시뮬레이션을 실행하는 고성능 인프라 클러스터를 생각해 보도록 하자.
클라우드 인프라의 주요 수단은 가상화이다. 보다 구체적으로 말하면, 대규모 데이터 센터에서 가상 서버를 실행함으로써 고가의 하드웨어를 구입 및 유지 관리해야 할 필요성을 해결하고 인프라 리소스를 공유함으로써 규모의 경제를 활용하는 것이다. 가상화 플랫폼은 일반적으로 전체 가상화 또는 부분 가상화 환경이다. (가상화에 대한 보다 자세한 설명은 7페이지의 부록 B를 참조)

클라우드 저장소
클라우드 저장소는 클라우드에 있는 모든 유형의 데이터 저장소를 말하는 것으로, 데이터베이스와 유사한 기능을 제공하는 서비스, 비정형 데이터 서비스(예: 디지털 미디어 파일 저장소), 데이터 동기화 서비스 또는 NAS(Network Attached Storage) 서비스를 포함한다. 데이터 서비스는 사용량 기준 결제 방식, 또는 이 경우 용량(GB) 기준 결제 방식으로 이용한다(저장 및 이동 데이터 모두 포함).
클라우드 저장소는 언제 어디에서든 방대한 데이터를 저장 및 검색할 수 있는 기능을 비롯해 다양한 장점을 제공한다. 데이터 저장소 서비스는 빠르고 저렴하며 거의 무한한 확장이 가능하다. 단, 아무리 우수한 서비스도 때로 장애가 발생하기 때문에 신뢰성이 문제가 될 수 있다. 트랜잭션 지원 역시 클라우드 기반 저장소 시스템이 안고 있는 문제 중 하나인데, 기업에서 저장 시스템을 널리 사용해야 하는 경우에는 반드시 해결해야 하는 중대사안이다.

클라우드 플랫폼
클라우드 플랫폼은 사실상 클라우에서 애플리케이션을 구축, 테스트, 구현, 실행 및 관리할 수 있는 능력이다. 클라우드 플랫폼은 이러한 작업에 대해 다양한 선택의 여지를 제공한다. 예를 들어, 온라인 전용, 오프라인 전용 또는 온라인/오프라인 결합 형태로 구축 작업을 수행할 수 있고 플랫폼에 따라 애플리케이션 테스트를 위한 도구를 지원하지 않거나 매우 우수한 도구를 지원할 수 있다.
일반적으로 클라우드 플랫폼은 웹 기반 애플리케이션 및 서비스를 위한 경제적이고 확장성이 우수한 호스팅/개발 환경이다. 지나치게 단순화하는 면이 있기는 하지만, 클라우드 플랫폼을 일반 웹 호스트보다 확장성과 가용성이 우수한, 보다 발전된 형태의 웹 호스팅으로 간주할 수 있다. 어떠한 기술이든 장단점이 있는데, 클라우드 플랫폼의 단점은 이동성이다. 특정 플랫폼에서 실행되도록 어떤 애플리케이션을 개발하는 즉시, 다른 클라우드 플랫폼으로 이동하거나 기존 호스팅 환경으로 다시 이동하는 것은이 사실상 불가능하다.

그림 3. 클라우드 저장소의 다섯 가지 클라우드 범주 및 특성 
aa699427_art1fig3(en-us,MSDN_10) 클라우드 애플리케이션
클라우드 애플리케이션은 클라우드 내에 부분적으로 또는 전체적으로 존재하며 클라우드 서비스를 이용하여 애플리케이션 내에서 핵심 기능을 구현한다. 클라우드 애플리케이션의 아키텍처는 전통적인 애플리케이션 모델과 상당히 다를 수 있으므로, 클라우드 애플리케이션을 구현하려면 애플리케이션 설계 사고 방식의 근본적인 전환이 필요할 수 있다.
클라우드 애플리케이션은 로컬에 애플리케이션을 설치 및 실행해야 하는 필요성을 해소시켜 주므로 소프트웨어 유지 관리, 구축, 관리 또는 지원에 필요한 비용을 절감할 수 있다. 이러한 유형의 애플리케이션은 SaaS(Software as a Service) 애플리케이션으로 간주된다.
이러한 애플리케이션의 대안은 S+S(Software plus Services) 모델로, 전통적인 애플리케이션 개발과 완벽한 SaaS 구현을 혼합한 것이다. S+S 애플리케이션은 일반적으로 외부에 호스팅된 서비스의 인터페이스로 고객의 PC에 설치된 리치 클라이언트 애플리케이션을 사용한다. 일반적으로, S+S 애플리케이션에는 오프라인 모드에서 애플리케이션과 상호 작용할 수 있는 기능과, 필요에 따라 중앙 서비스로 동기화할 수 있는 기능이 포함되어 있다.

핵심 클라우드 서비스
핵심 클라우드 서비스는 ID 관리, 서비스 간 통합, 매핑, 과금/결제 시스템, 검색, 메시징, 비즈니스 프로세스 관리, 워크플로 등 클라우드 기반 솔루션을 지원하는 서비스를 말한다. 핵심 클라우드 서비스는 개인이 직접 사용하거나 시스템 간 통합을 통해 간접적으로 사용할 수 있다.
많은 서비스가 BSS (Business Support System) 또는 OSS (Operational Support System)의 범주에 해당하는 상황에서 핵심 클라우드 서비스의 진화는 어쩌면 전자 통신 업계의 진화 과정을 모방하게 될 것이다.

BSS 서비스는 상호 작용을 관리하고 고객은 일반적으로 다음과 같은 작업을 처리한다.
- 주문 접수
- 청구서 처리 
- 수금

OSS 서비스는 서비스 자체를 관리하고 다음과 같은 사항을 처리한다.
- 서비스 모니터링
- 서비스 프로비저닝
- 서비스 구성

클라우드 서비스의 특성 맵
다섯 가지 클라우드 범주를 사용하면 범주별로 일련의 특성을 작성할 수 있다. 이러한 특성은 다음 두 가지 방식으로 이용할 수 있다.
- 애플리케이션의 특성을 클라우드 특성에 매핑하여 클라우드 서비스가 해당 애플리케이션에 적합한지 검사하고 어떤 유형의 서비스를 사용할지 파악한다.
- 애플리케이션을 호스팅할 수 있는 후보자로 여러 클라우드 서비스 공급자를 평가하고 선택한 공급자를 통해 어떤 유형의 서비스를 이용할 수 있는지 확인한 다음, 제공된 서비스의 구체적인 구현 특성을 파악한다.

그림 3은 다섯 가지 클라우드 범주와 클라우드 저장소 범주의 특성 목록을 보여준다. 각 클라우드 공급자는 조금씩 다른 방식으로 클라우드 서비스를 구현한다. 예를 들어, Microsoft와 같은 기업은 개발자가 특정 애플리케이션에 필요한 기능에 따라 선택할 수 있는 다양한 대체 저장소를 제공하고 있다.
의사 결정을 내릴 때에는 구현 비용을 감안해야 하기 때문에, 특정 클라우드 공급자의 서비스가 여러분의 요구 사항에 적합한지 판단할 경우, 애플리케이션 특성과 마찬가지로 클라우드 특성을 주의 깊게 고려해야 한다. (6페이지에 있는 부록 A, 클라우드 매핑 특성 샘플 참조)

클라우드 및 애플리케이션 오버레이
하나의 솔루션을 구현할 때 사용할 수 있는 클라우드 서비스와 애플리케이션을 완벽하게 이해했으니, 이제 최종적으로 어떤 아키텍처가 가능한지에 대한 결정을 내릴 수 있다. 클라우드가 전통적인 애플리케이션 아키텍처의 실용적이고 경제적인 대안이라는 판단이 든다면, 그 다음으로 할 일은 해당 애플리케이션에 가장 적합한 클라우드 공급자를 선택하는 것이다. 
자신의 요구 사항을 완벽하게 충족시킬 수 있는 단일 공급업체는 없다고 해도 틀린 말이 아닐 것이다. 반면, 여러 공급업체를 이용하면 애플리케이션이 필요한 모든 서비스를 이용할 수 있다.

그림 4. 여러 클라우드 서비스 및 공급업체를 이용하는 단일 애플리케이션 
aa699427_art1fig4(en-us,MSDN_10)

그림 4는 여러 클라우드 공급자가 제공하는 다양한 클라우드 서비스를 이용하는 애플리케이션을 보여준다. 상기 사례는 ASP.NET으로 구축되고 Azure 플랫폼 (클라우드 플랫폼)에서 실행되고 있는 애플리케이션을 나타낸다. 단, 이때의 애플리케이션에는 완벽하게 신뢰할 수 있는 (full trust) 구성 요소도 필요한데, 이는 구성 요소가 전체 가상 환경 (클라우드 인프라) 에서만 실행 가능하다는 것을 의미한다. 데이터는 Microsoft 클라우드(클라우드 저장소)에 저장되고 서비스 버스 및 Identity 같은 서비스 (핵심 클라우드 서비스)도 Azure를 통해 제공된다. 이 애플리케이션에 마지막으로 필요한 것은 과금/결제 서비스 (핵심 클라우드 서비스)인데, 이는 다른 클라우드 공급자를 통해 제공될 수 있다.
이러한 시나리오는 실현 가능하기는 하지만, 여러 공급자에 계정을 두고 다수의수많은 API를 사용하며 모든 서비스를 하나의 애플리케이션에 통합하는 데 따르는 비용이 비현실적일 수 있다. 현실적으로 가능한 솔루션은 애플리케이션에 필요한 서비스의 대다수를 제공하는 단일 공급업체를 찾고, 이를 기본 플랫폼으로 이용하여 혼합 솔루션을 구축하는 것이다.

Posted by 장현춘

댓글을 달아 주세요

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 장현춘

댓글을 달아 주세요

image엔터프라이즈 소셜 컴퓨팅에 관한 아키텍처 저널 19권의 두번째 번역물 리뷰를 마치고 여러분의 피드백을 기대하며 올린다.

이 글은 크게 전반부와 후반부로 나누어 올렸으며 전반부는 아래에서 찾을 수 있다.

엔터프라이즈 소셜 컴퓨팅 #1/2

전반부와 후반부를 합치고 영어 원문과 근접한 형태의 문단 배치를 갖는 PDF 버전은 작업이 끝나는 대로 다운로드 받을 수 있도록 공개할 예정이다.

두번째 번역물은 솔루션 프레임웍부터 시작된다.
많은 피드백을 기원하며…

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

그림 2. 소셜 컴퓨팅 솔루션 프레임웍
aa699425_art4fig2(en-us,MSDN_10)

솔루션 프레임워크

Microsoft Office SharePoint Server(MOSS) 2007에서는 위에서 간략히 설명한 소셜 컴퓨팅 비즈니스 요구를 충족할 수 있는 플랫폼 및 솔루션 프레임워크를 제공한다. 소비자 중심적인 솔루션 프레임워크에는 방화벽 외부에 있는 애플리케이션, 서비스 및 사용자도 물론 포함되지만 여기에서는 기업의 사무실 내에서 지원할 프레임워크에 대해서만 다루도록 한다. 다음 그림에서 간단히 살펴볼 수 있다(그림 2).

LOB(업무용) 시스템
기업 LOB(업무용) 시스템의 데이터를 MOSS 2007과 같은 엔터프라이즈 플랫폼에 제공해야 할 경우가 있는데, 이러한 데이터로는 고객 관리 정보(CRM), 재무 및 회계 데이터, 영업 정보 등을 들수 있다. SharePoint 플랫폼에 설계되어 있는 주요 비즈니스 프로세스 및 워크플로에서는 성공적인 수행을 위해 이러한 LOB 데이터에 의존한다.

엔터프라이즈 생산성 서비스
이러한 서비스는 약한 소셜 소프트웨어 및 강력한 소셜 소프트웨어 모두에 공통적으로 적용될 수 있는 많은 기능을 포함하고 있으며, 조직에서 소프트웨어에 대한 장단기 투자를 구체화할 수 있는 강력한 엔터프라이즈 플랫폼을 선택했을 경우에 핵심적인 장점으로 부각된다. MOSS 2007 서비스에는 다음과 같은 기능이 포함되어 있다.

• EMM(엔터프라이즈 메타데이터 관리): 플랫폼의 다양한 기능에서 활용할 수 있는 회사의 메타데이터를 중앙에서 관리 및 유지
• ECM(엔터프라이즈 컨텐츠 관리): 컨텐츠 및 자산 관리, EMM과의 통합으로 컨텐츠 설명 및 분류, 규정 준수 및 보존 정책 아키텍처, 컨텐츠 자산 및 메타데이터를 Microsoft Office 2007 제품군과 같은 생산성 애플리케이션에 통합
• WCM(웹 컨텐츠 관리): 웹 기반 컨텐츠 관리, 재사용 가능하고 현지화된 컨텐츠 관리, 컨텐츠 준비 및 복제, 웹 기반 컨텐츠로 문서 변환, 주요 UI 및 브랜딩 자산 작성 및 유지 관리
• BPM(비즈니스 프로세스 관리): SharePoint Designer 2007 워크플로 및 사용자가 개발한 WF(Windows Workflow Foundation) 솔루션을 통해 워크플로를 자동화하여 비즈니스 프로세스를 관리
• BI(비즈니스 인텔리전스): Excel 서비스, Excel 웹 액세스, KPI(핵심 성과 지표) 등
• LOB 통합: Excel 서비스에서 제공하는 비즈니스 인텔리전스 데이터를 표시하는 BDC(비즈니스 데이터 카탈로그)를 통해 LOB 시스템을 통합
• 엔터프라이즈 검색: 플랫폼 외부의 파일 공유 및 데이터베이스에 저장된 컨텐츠, LOB 데이터, 프로필 및 검색 컨텐츠에 대한 검색 기능
• 사용자 프로필: 프로필 데이터, 관계도 및 관계, 프로필과 연결된 개인 관리 자산, 통합 통신(UC), 현재 상태(Presence) 및 Active Directory 통합
• 포털 프레임워크: 위의 기능에 대한 사용자 인터페이스를 오케스트레이션하고 제공하도록 설계된 핵심 서비스로, 전자 메일 알림, RSS 피드, Outlook 2007 및 Excel 2007과 같은 Microsoft Office 2007 제품에 대한 연결 등의 기능을 제공하고, 다양한 인증, 권한 부여 및 사용 권한 모델을 제공

그림 3. 협업 레코드 관리: 홈 페이지
aa699425_art4fig3(en-us,MSDN_10)

엔터프라이즈 소셜 컴퓨팅 기능
MOSS 2007에서는 핵심 생산성 서비스 기반으로 구축되는, 즉시 사용 가능한 여러 소셜 컴퓨팅 기능을 제공하여 기업으로 하여금 다음과 같은 사항을 계획할 때 비교적 소규모 투자로 이러한 기능을 사용할 수 있도록 한다.

• 블로그: 사용자는 즉시 사용 가능한 (out-of-the-box) 기능을 통해 블로그를 만들고, Microsoft Word 2007 및 Windows Live Writer와 같은 웹 인터페이스와 도구를 통해 글을 게시하고, 범주 및 메타데이터를 관리할 수 있다. 또한 게시물에 의견을 추가할 수도 있다. SharePoint의 블로그 기능 개선 사항으로는 Community Kit for SharePoint의 Enhanced Blog Edition을 들 수 있다.
• 위키(Wikis): 사용자가 위키 페이지를 빠르게 작성하고 스텁 (stub) 페이지를 만들어 향후 추가 컨텐츠가 필요한 위치를 표시하고, 시간이 지남에 따라 컨텐츠를 편집 및 버전 관리하여 구조화되지 않은 풍부한 지식 저장소를 만들 수 있도록 한다. SharePoint의 위키 기능 개선 사항으로는 Community Kit for SharePoint의 Enhanced Wiki Edition이 있다.
• 포럼 및 토론 게시판: 사용자가 온라인으로 토론 주제를 게시하고 답변할 수 있는 기능이다. Microsoft Exchange와 통합됨으로써 사용자가 전자 메일 기반의 토론 그룹을 계속해서 사용할 수 있고, 엔터프라이즈 검색 결과에 토론 내용을 인덱싱하고 표시할 수 있도록 토론 스레드의 사본을 온라인으로 저장할 수도 있다.
• 소셜 코어(Social Core): 내 사이트 (MySite) 기능을 사용하면 사용자가 프로필 뿐만 아니라, 기업내 동료들의 사교적 관계 및 조직 측면에서의 계층도를 만들고 유지 관리할 수 있다. 또한 MOSS에서는 현재 상태(Presence) 외에도 소셜 네트워크에 속한 동료의 활동에 대한 알림 표시 기능을 제공한다.
• 분석(Analytics): MOSS에서는 즉시 사용 가능한 사용 현황 분석과 이벤트 로깅 기능을 제공한다.

엔터프라이즈 소셜 컴퓨팅 클라이언트
MOSS는 주로 웹 브라우저 클라이언트를 통해 접근할 수 있지만 Microsoft Office 2007 생산성 제품군과 다양하게 통합되어 있어 모바일 인터페이스를 통해서도 접근할 수 있다. MOSS에는 웹 서비스도 포함되어 있어 다른 애플리케이션에서 이 웹 서비스를 호출하여 사용자에게 유용한 데이터를 통합, 처리 및 표시할 수 있다. 가장 좋은 예로는 MOSS 데이터를 사용자 지정한 형태로 보여주는 Vista 가젯을 들 수 있다.

그림 4. 협업 레코드 관리: Outlook 2007에 문서 라이브러리 연결
aa699425_art4fig4(en-us,MSDN_10)

기업내 소셜 컴퓨팅의 사례

다음 사례는 기업내의 플랫폼 기능과 소셜 컴퓨팅 기능을 모두 보여준다. 처음 두 사례는 “약한” 소셜 소프트웨어 환경에 보다 적합한 솔루션을 보여주고 나머지 사례는 “강력한” 소셜 소프트웨어 환경에 적합한 솔루션을 보여 준다.

그림 5. 협업 레코드 관리: 오프라인으로 문서 편집
aa699425_art4fig5(en-us,MSDN_10) 

협업 레코드 관리
이 솔루션은 각 분야 전문가들(subject matter experts)이 지리적으로 분산되어 있는 조직에서 MOSS의 협업 기능을 사용하여 여러 개의 브리핑 문서를 서로 보다 쉽게 공유하는 방법을 보여준다(그림 3, 4, 5). 이 사례에서는 소비자 사이트에서 제공되는 기능과 같은 것은 보여 주지 않지만, 사용자들이 이미 서로 잘 알고 긴밀하게 함께 작업을 수행하는 “약한” 소셜 시나리오 측면에서 MOSS와 같은 엔터프라이즈 플랫폼이 제공할 수 있는 강력한 기능을 보여 준다. 또한 이 사례는 작업자들이 특별한 비즈니스 요구를 충족하기 위해 신속하게 작성할 수 있는 “임시 애플리케이션(provisional application)”의 좋은 예이기도 하다. 특히 이 솔루션은 다음과 같은 기능을 수행한다.

• 오프라인으로 탐색 및 편집할 수 있도록 SharePoint 문서 라이브러리를 Microsoft Outlook 2007에 연결한다.
• 문서 라이브러리를 사용자 지정 뷰로 제공하므로 미리 정의된 기준에 따라 그룹화된 정보 또는 뷰를 빠르게 검색할 수 있다.
• Groove 2007 작업 영역을 SharePoint 문서 라이브러리에 연결하여 사용자가 미리 선택한 인터페이스에서 관련 정보를 사용할 수 있다.
• RSS 피드를 통해 주요 문서 메타데이터 및 설명을 사용할 수 있다.
• SharePoint Designer 2007 워크플로를 활용하여 사용자가 프로젝트 Brief 서식 파일을 완전히 채우지 않아도 Brief에 대해 “빠른 제출 (Quick Submit)”을 수행할 수 있다. 사용자는 필요에 따라 모바일 인터페이스에서도 “빠른 제출” 기능을 사용할 수 있다.

그림 6. 수직 산업 및 역할별로 필터링한 콜 센터 질문
aa699425_art4fig6(en-us,MSDN_10)

그림 7. 콜 센터 등급 드릴다운
aa699425_art4fig7(en-us,MSDN_10)

콜 센터 질문 관리
이 솔루션은 내부의 영업 전문가로 구성된 소규모 팀에 제공되었는데, 이 팀의 영업 활동에는 회사의 최고위 임원(C-level executive)들이 포함되어 있다(그림 6, 7). 이 팀은 영업 관련 전화상담에 사용하는 질문 스크립트들을 Microsoft Word 및 Excel로 관리하고 있는데, MOSS 2007을 사용하여 팀 구성원이 질문의 효용성에 점수을 매기고 개인적인 의견을 제공할 수 있는 방법을 찾아 왔다. MOSS가 제공하는 나열 메커니즘은 가장 효용성이 높은 질문으로 점수가 매겨진 질문 항목이 질문 목록의 “맨 위에 위치”되도록 하여 질문 항목들이 보다 효과적으로 사용될 수 있도록 한다.

그림 8. 소셜 검색: 결과 인터페이스
aa699425_art4fig8(en-us,MSDN_10)

그림 9. 소셜 검색: 검색 결과에 의견 추가
aa699425_art4fig9(en-us,MSDN_10)

소셜 검색: Silverlight 검색 애플리케이션
이 소셜 검색 애플리케이션은 MOSS의 엔터프라이즈 검색 기능을 개선할 수 있는 방법을 보여 주기 위한 프로토타입으로 설계되었다(그림 8, 9). MOSS 엔터프라이즈 검색 카탈로그는 다른 검색 소스 및 소셜 검색 기능으로 보완되었다.

• 애플리케이션 UI는 Silverlight의 풍부한 시각화 및 UI 기능을 사용할 수 있도록 Silverlight로 작성되었으며, Silverlight 플러그 인을 사용하지 않는 사용자를 위해 표준 ASP.NET 버전을 개발했다.
• 이 솔루션에는 여러 개의 검색 카탈로그를 하나의 마스터 검색 인덱스로 통합한 웹 서비스를 사용하는데, 이 웹 서비스는 기본 제공이 아닌 별도로 개발되었다.
• 이 솔루션에는 소비자 소셜 검색과 책갈피 기능 영역에 공통으로 사용되는 소셜 기능이 도입되었다. 사용자는 검색 결과에 등급을 매기고, 검색 결과에 의견을 추가하며, 즐겨 찾는 검색 및 링크를 저장하고, 자신의 링크를 사용자가 생성한 컨텐츠의 카탈로그로 전송할 수 있다.

그림 10. PKS: 홈 페이지 기능
aa699425_art4fig10(en-us,MSDN_10)

그림 11. PKS 포드캐스트 다운로드 및 세부 정보 페이지
aa699425_art4fig11(en-us,MSDN_10)

엔터프라이즈 소셜 미디어: Podcasting Kit for SharePoint
PKS(Podcasting Kit for SharePoint)는 SharePoint 플랫폼에서 사용할 수 있는 “강력한” 소셜 컴퓨팅 환경의 가장 좋은 예 중 하나다(그림 10, 11). 솔루션 액셀러레이터로 설계된 PKS를 사용하면 기업에서 포드캐스트 및 일반적인 소셜 컴퓨팅 기능(등급 매기기, 의견 추가, 즐겨찾기, 다운로드 통계, 사용자 프로필, 맞춤 탐색, 모바일 인터페이스, 분류/태깅)을 사용하여 조직 내에서 지식을 관리 및 통합할 수 있다. PKS는 Public License에 따라 소스 코드와 함께 배포되며 MOSS 2007을 이미 사용 중인 경우에는 무료로 사용할 수 있다.

참조

1 엔터프라이즈 요구에 대한 이 표현은 2007 Strategic Architect Forum에서 발표된 Scott Jamison의 프레젠테이션에서 차용했다. 이러한 요구는 지금도 여전히 유효하며 현재의 세계 경제를 고려할 때 보다 빠르게 나타날 가능성이 있다.
2 Salkowitz, 2008년, pp. 85-88
3 2008년 6월에 열린 Enterprise 2.0 Conference에서 발표자로 등장한 CIA의 Don Burke 및 Sean Dennehy는 CIA에서 Intellipedia를 배포 및 채택한 내용에 대해 발표했고, Shawn Dahlen 및 Christopher Keohane은 Lockheed Martin의 소셜 소프트웨어 플랫폼을 데모로 보여 주었다.
4 군대의 호스트 컴퓨터에서 거의 30,000개에 달하는 맬웨어를 발견한 Jeffrey Sorenson 중장의 예를 참조하라.
5 Facebook에서 엔터프라이즈에 대한 Mark Zuckerberg의 의견을 참조하라. Mark Zuckerberg는 Facebook은 엔터프라이즈 애플리케이션이 아니지만 누군가 엔터프라이즈 소셜 네트워크 애플리케이션을 개발하면 큰 돈을 벌 수 있을 거라고 말한다.
6 Nikos Drakos, 2008년

참고 문헌

Nikos Drakos, A. B. (2008). Tutorial: Social Context, Not Technology, Definies
Social Software. Gartner.
Salkowitz, R. (2008). Generation Blend. Hoboken, New Jersey: John Wiley & Sons, Inc.
Tapscott, D. (2008). Grown Up Digital. New York, New York: McGraw Hill.

작성자 정보

Kendrick Efta는 Allyis의 공동 창업자이자 수석 컨설턴트이다. 10년 이상 엔터프라이즈 솔루션을 개념화, 설계 및 구축한 경력이 있는 Ken은 Allyis의 혁신 및 사고의 리더십을 이끌고 있으며 고객에게 전략적 통찰 및 방향을 제공하는 업무를 담당하고 있다. Allyis를 공동 창업하기 전에는 시애틀 지역의 기업 다수를 대상으로 기술 컨설턴트로 활약했다. Ken은 Allyis의 공동 창업자인 Richard Law와 Ethan Yarbrough와 함께 Western Washington University로부터 첫 번째 “올해의 젊은 동문 상”(Young Alumnus of the Year)을 받았다.

이 주제에 대한 내용 더 보기

• Microsoft 제품을 통해 소셜 컴퓨팅을 비즈니스에 맞게 최대로 활용하는 방법(영문): http://www.microsoft.com/downloads/details.aspx?FamilyId=C5844123-7F31-49D4-811C-7B90E6217B1D&displaylang=en
• Microsoft 플랫폼에서의 소셜 컴퓨팅(영문): http://www.microsoft.com/sharepoint/capabilities/collaboration/social.mspx

Posted by 장현춘

댓글을 달아 주세요