[아키텍처 저널 번역] 19권 애플리케이션을 클라우드에 매핑 #2/2
지난 포스팅에 이어 이번에도 아키텍처 저널 19권 중 애플리케이션을 클라우드에 매핑이라는 아티클의 번역물을 이어 올린다. 지난 포스팅은 애플리케이션을 클라우드에 매핑하기 위해 필요한 사항을 점검하는 방법에 대해서 알아보았다면, 이번 포스팅은 지난번 흐름을 이어 클라우드에 적합한 시스템을 예를 들어가면서 클라우드에서 설계할 때 주의할 사항들에 대해 논의한다. 마지막에는 클라우드에 매핑할 때 사용하는 기준인 각종 특성들에 대한 목록을 부록으로 제공하고 있다.
지난 포스팅은 아래에서 확인할 수 있다.
https://blogs.msdn.com/b/eva/archive/2010/06/25/architecture-journal-19-1-2.aspx
MSDN 한글화 작업도 마무리가 되었다. 관련 링크는 아래에서 확인 할 수 있다.
https://msdn.microsoft.com/ko-kr/architecture/aa699427.aspx
이 아티클의 한글화된 PDF 버전은 아래 링크에서 다운로드 받을 수 있다.
https://msdn.microsoft.com/ko-kr/aa699428.aspx
------------------------------------------------
하나의 클라우드로 모든 애플리케이션 지원
하나의 클라우드가 존재하는가, 다수의 클라우드가 존재하는가? 이는 필자가 지금까지 수도 없이 많이 들어온 논쟁이다. 이 논쟁의 일면에는 퍼블릭 클라우드와 다른 프라이빗 클라우드가 존재한다. 사적으로 구현한 클라우드 기술을 클라우드라고 할 수 있는가, 아니면 다른 것으로 봐야 할까? 모든 퍼블릭 클라우드는 동일한 기능을 제공하는가? 프라이빗 클라우드와 퍼블릭 클라우드를 혼합하여 함께 사용하는 애플리케이션이나 시스템의 경우는 어떠한가? 그리고 이들은 어디에 해당하는가?
그림 5. 티켓팅 시스템에 클라우드 인프라 이용
이러한 논쟁은 무의미하다는 것이 필자의 솔직한 의견이다. 어떤 이론에 동의하든 원하는 결과는 같다. 즉, 실제로 작동하는 가능한 가장 경제적인 시스템을 구축하는 것이다. 이전 섹션에서는 결정을 내리는 데 도움이 되는 방안을 논의했다면 지금부터는 클라우드에 존재하거나 혼합 클라우드 솔루션의 일부로 존재할 수 있는 애플리케이션에 대해 간략하게 살펴볼 것이다.
클라우드에서 솔루션 아키텍처 설계 하기
이 섹션에서는 클라우드 서비스를 사용하여 구현할 수 있는 솔루션에 대한 세 가지 애플리케이션 시나리오를 설명한다. 다음 시나리오는 클라우드 서비스를 사용할 수 있는 포괄적인 솔루션 목록이 아니며, 실현 가능한 애플리케이션을 몇 가지 제시한 것에 불과하다.
티켓팅 시스템
클라우드 인프라의 장점에 대해 논의할 때, 콘서트 티켓팅 시스템이 클라우드 시나리오에 적합하다는 것에 대해서는 대체로 의견 일치를 보인다(그림 5). 표면적으로는 이런 유형의 애플리케이션이 적합해 보인다. 티켓팅 시스템은 짧은 기간에 많은 수요를 감당해야 하는 경우가 많다 (사람들은 곧 매진될 콘서트 또는 스포츠 경기의 티켓을 사기 위해 몰려든다). 이 기간이 지나면 작업량이 적거나 중간 정도인 수준의 기간이 길게 이어진다.
티켓팅 애플리케이션은수요가 많은 기간 동안에, 즉 컴퓨팅 리소스 요구량이 아주 많은 시기에는 과부하되는 경우가 많다. 이러한 시기를 감당하기 위해서는 가상 시스템의 인스턴스를 실행할 수 있는 기능이 효과적이다. 단, 이러한 솔루션의 아키텍처 설계시에 다음과 같은 몇 가지 이슈를 반드시 고려해야 한다.
- 티켓팅 시스템은 데이터 사용량과 트랜잭션이 아주 많다. 어떤 주어진 이벤트에 특정 좌석을 예약하거나 결제를 하기 위해서 트랜잭션이 필요할 수 있다.
- 많은 고객이 해당 티켓팅 회사에 계정이 있거나 계정 생성을 원할 수 있으므로, 개인 식별 정보를 수집해야 한다.
- 신용 카드 결제 확인에는 많은 시간이 소요될 수 있으며, 이는 티켓팅 프로세스에서 나타나는 병목 현상의 원인이 될 수 있다.
- 일부 가상 서버 플랫폼은 상태를 저장할 수 없다. 이는 서버 이미지가 종료되면 해당 이미지 내에 저장된 데이터에 대한 모든 변경 내용이나 추가 내용이 손실된다는 것을 의미한이다.
- 기존 티켓팅 회사들은 이미 인프라 및 데이터 관리에 상당한 규모의 투자를 하였다.
- 선택하는 클라우드 서비스에 따라, 상태를 저장할 수 없는 가상 클라우드 서버 이미지의 경우, 정보를 이벤트마다 다시 생성해야 하는데, 이렇게 되면 각각의 새로운 인스턴스에 맞는 환경을 준비하기 위해 상당량의 작업을 수행해야 한다.
이러한 점들을 염두에 두면 클라우드 서비스를 이용하여 최대 부하 시간에 기존 시스템에 대한 수요를 줄일 수 있는 여러 가지 방법이 존재한다.
- 내부 시스템을 완벽하게 이중화. 가장 많은 양의 작업이 필요하다. 이는 애플리케이션을 사용할 준비가 되면 새로운 인스턴스가 만들어질 때마다 기존 시스템과 동기화해야 하기 때문이다. 시스템을 계속 켜둔 상태로 두면 (용량이 줄어든 상태라 할지라도) 서비스 플랫폼 사용 비용 때문에 많은 비용이 들 수 있다.
- 내부 시스템과 클라우드 시스템 간의 워크로드를 실시간으로 분리. 두 개의 환경에서 좌석 선택과 티켓 구입 과정을 분리하는 것이다. 예를 들어, 내부 티켓팅 시스템에서 트랜잭션이 시작되어 고객이 계정에 로그인하고 참석하고자 하는 이벤트를 선택하고 좌석을 정하게 되면, 최종 결제 처리를 위해 클라우드 서비스로 넘어가는 것이다. 즉, 단순히 마지막 처리 단계를 완료하는 가상 클라우드 서버를 구축하는 것이기 때문에 주 시스템과 동기화할 필요가 없고, 효과적인 상태 비저장 처리 엔진 역할을 할 수 있다. 최소한의 데이터만 클라우드 서비스에 전송하면 되고 신용카드 정보는 일회용으로 외부 시스템에 수집한 후 삭제할 수 있다.
- 일괄 처리를 통해 내부 시스템 간의 워크로드 분리. 앞서 말한 처리 방식과 비슷하지만, 이 방식은 참조 정보를 포함한 모든 개인 정보를 내부 시스템에 수집한다는 점에서 차이가 있다. 그런 다음, 이러한 정보는 프로세스 대기열에 있다가 클라우드 서비스로 일괄 전송되어 처리된다. 즉, 결제가 실패하면 티켓 구입을 시도하는 사람과 연락하는 보조 프로세스를 구현해야 한다.
상기의 솔루션은 사용량이 많은 기간 동안 티켓팅 시스템이 클라우드 서비스와 회사 내부 시스템 간에 처리 작업을 어떤 방식으로 분리할 수 있는지를 보여주는 사례이다.
그림 7. 최대 로드 지원을 위해 클라우드 인프라 사용
포토/비디오 처리
이 예는 다수의 서비스(인프라, 저장소, 대기)를 결합하여 하나의 데이터 처리 솔루션을 제공하는 방법을 보여준다(그림 6). 이 시나리오에는 디지털 미디어 파일을 렌더링하거나 포맷을 변경하기 위해 클라우드 서비스를 이용하는 포토 처리점들이 처리 체인점이 있다.
이 포토 체인은 미국 전역에 수많은 매장을 두고 있으며, 대규모 이미지 및 비디오 처리를 중앙 집중화하여 시스템의 두 가지 측면, 즉 각 저장소매장의 하드웨어 수와 하드웨어 유지 보수 및 지원 작업의 복잡성을 줄이고자 한다.
고객이 다른 포맷으로 변환해야 하는 비디오와 함께를 들고 매장을 방문하면, 먼저 해당 비디오 파일을이 먼저 저장소 서비스로 업로드시킨다. 그러면 ‘파일이 저장소 플랫폼에 있으며 다른 포맷으로 변환해야 한다’는 메시지가 대기열 서비스에 배치된다. 컴퓨터 인스턴스를 실행하는 애플리케이션 컨트롤러가 대기열에서 이 메시지를 받은 후, 가상 시스템의 기존 인스턴스를 사용하거나 새로운 인스턴스를 만들어 비디오의 포맷 변경을 처리한다. 이 프로세스가 완료되는 즉시, 컨트롤러는 프로젝트가 완료되었음을 매장에 알리기 위해 대기열에 메시지를 배치한다.
상기 시나리오는 온라인 환경으로 쉽게 바꿀 수 있기 때문에, 고객은 실제 매장을 방문할 필요 없이 파일을 업로드하여 처리할 수 있다.
웹 사이트 최대 로드 처리
마지막으로 트래픽이 불규칙하게 매우 많아져서 이러한 최대 로드를 지원할 수 있는 호스팅 인프라를 구축하는 것이 현실적으로 불가능한 웹 사이트의 예를 들어보도록 하겠다(그림 7). 긴급 뉴스속보가 있는 뉴스 사이트, 새로운 게임을 발표하는 게임 사이트, 새로운 블록버스터의 예고편을 보여주는 영화 사이트가 여기에 해당된다.
이 시나리오에 대한 솔루션은 회사 웹 사이트의 완벽한 복사본을 생성하는 것이다. 즉, 웹 사이트의 일부가 클라우드 서비스 인프라 서비스에서 많은 트랙픽을 처리하는 것이다. 사이트의 복사본은 로드 밸런싱된 일련의 서버 또는 클러스터로 구성 가능한 수많은 웹 서버에서 실행되는 정적 인스턴스가 될 것이다. 원본 웹 사이트에 필요한 변경 작업을 수행한 다음 이를 클라우드 서버에 동기화할 수 있다. 이렇게 하면 지연이 발생하겠지만, 웹 서버와 웹 사이트를 유지 관리하는 데 드는 수고를 크게 줄이고 내부 호스팅 웹 사이트와 외부 호스팅 웹 사이트 간 상태를 유지 관리하는 문제를 해소할 수 있다.
클라우드 서비스를 사용할 수 있는 시나리오가 더 많이 있으므로 상기 시나리오를 위한 솔루션을 설계하는 방법도 많이 있다. 여기서는, 새롭게 등장하고 있는 서비스의 활용 사례와 몇 가지 대안을 조명하는 것으로 마무리하고자 한다.
결론
클라우드 및 클라우드 기술이 지닌 매력 때문에 많은 개발자, ISV, 신생 기업 및 대기업은 클라우드 서비스를 면밀히 검토하고 도입의 적합성 여부를 진단하고 있다. TCO 비용 절감과 더불어 저장소 및 인프라의 무제한 확장 가능성을 무시하기 어렵다. 클라우드의 가능성은 확실히 검토할 만한 것이지만, 클라우드 서비스 도입은 신중하게 다루고 아울러 모든 애플리케이션이 클라우드에 적합한 것은 아니라는 사실을 명심해야 한다. 많은 애플리케이션이 클라우드에서 운영될 것이다. 하지만, 클라우드에 일부 솔루션을 호스팅하는 데 드는 부대 비용으로 인해 일부 프로젝트의 경우, 잘 정립된 전통적인 아키텍처 및 기술에 비해 훨씬 더 많은 개발 및 운영 비용이 들 수도 있다.
저자 소개
Darryl Chantry는Microsoft Platform Architecture 팀의 수석 아키텍트이다. 엔터프라이즈 아키텍트, 솔루션 아키텍트, 인프라 아키텍트로 근무한 경험을 바탕으로 폭넓은 기술력을 보유하고 있다. Darryl은 뉴질랜드 오클랜드에서 나고태어나 자랐으며 2002년에 Microsoft의 New Zealand Developer & Platform Evangelism 팀에 합류했다. 럭비를 매우 좋아하며 인류학, 역사 및 사용자 경험에 특별한 관심을 가지고 있다. Darryl 부부는 현재 보어보엘 개 한 마리와, 버마산미즈 고양이 두 마리와 함께 워싱턴 레드몬드에서 살고 있다.
관련 자료
- Introducing the Azure Services Platform(David Chappell이 쓴 기사) : https://download.microsoft.com/download/e/4/3/e43bb484-3b52-4fa8-a9f9-ec60a32954bc/Azure_Services_Platform.pdf
- Azure for Business : https://www.microsoft.com/azure/business.mspx
- Azure for Corporate Developers : https://www.microsoft.com/azure/corpdev.mspx
- Azure for Independent Software Vendors (ISVs): https://www.microsoft.com/azure/isv.mspx
부록 A
부록 B
클라우드 인프라 플랫폼 및 가상화 유형
클라우드 컴퓨팅 플랫폼의 핵심 지원 기술 중 하나는 가상화, 즉 컴퓨팅 리소스를 추상화할 수 있는 기술이다. 오늘날 클라우드 인프라 플랫폼은 크게 전체완벽히 가상화된 환경 아니면 또는 부분 반가상화된 (paravirtualized) 환경으 이 두 가지 형태로 구축된다.
방금 언급한 두 가지 이외에도 변형된 형태의 가상화 기술이 더 많지만, 이 글의 목적상 현재 존재하고 클라우드 인프라 솔루션에 원활하게 통합 가능한 몇 가지 가상화 방식만 논의하도록 하겠다.
에뮬레이션
이 유형의 가상화에서는 가상 환경이 수정되지 않은 게스트 OS (운영 체제)가 필요로 하는 하드웨어 아키텍처를 에뮬레이트한다. 에뮬레이트된 하드웨어를 접하게 되는 일반적인 경우 중 하나는 모바일 장치를 사용하는 경우이다. 애플리케이션 개발자는 에뮬레이트된 환경을 통해, 예를 들어 스마트폰이나 PDA에서 실행되도록 설계된 애플리케이션을 테스트할 것이다(그림 8 참조).
장점: 기본 하드웨어와 완전히 다른 하드웨어 환경을 시뮬레이션한다. 데스크톱에 에뮬레이트되는 스마트폰 등의 모바일 장치를 예로 들 수 있다.
단점: 성능 수준이 낮고 리소스 사용량이 많다.
전체 가상화
전체 가상화에서는 가상화 환경 내에 수정되지 않은 완전한 게스트 OS의 이미지가 생성되고 실행된다. 전체 가상화와 에뮬레이션의 차이점은 모든 가상화 게스트가 동일한 하드웨어 아키텍처에서 실행된다는 것이다. 모든 게스트가 동일한 하드웨어를 지원하므로 게스트가 하드웨어에서 많은 명령을 직접 실행하여 성능을 향상시킬 수 있다(그림 9참조).
장점: 여러 공급업체가 제공하는 여러 버전의 OS(예: Microsoft Windows Server 2003, Windows Server 2008, Linux, and UNIX)를 실행할 수 있다.
단점: 가상화 이미지는 전체 OS를 설치하는 것이므로 파일 용량이 매우 커질 수 있다. 전체 가상화 환경에서는 (특히 일반 하드웨어에) 심각한 성능 문제가 발생하고 입출력 작업이 많은 애플리케이션이 부정적인 영향을 받을 수 있다.
부분 반가상화(Para-Virtualization)
부분 반가상화에서는 하이퍼바이저가 물리적 하드웨어의 수정 복사본을 내보낸다. 내보낸 계층은 서버 하드웨어와 아키텍처가 동일하다. 하지만 게스트 OS가 네이티브에 가까운 속도로(near-native speeds) 작동하게 하려면 이 계층에 특정 수정 작업을 수행해야 한다. 이처럼 수정된 호출을 활용하려면 게스트 OS를 약간 수정해야 한다. 예를 들어, 물리적 하드웨어에서 기대하는 것과 동일한 수준의 기능을 제공하는 하이퍼콜(hypercall)을 이용하기 위해 게스트 OS를 수정할 수 있다. 단, 하이퍼콜을 이용할 경우 가상화 환경에서 실행될 때에 게스트의 효율성이 크게 향상된다(그림 10 참조).
장점: 소규모로 가볍고 속도가 빠르다. 이미지 크기가 크게 줄어들고 성능이 네이티브에 가까운 속도로 향상될 수 있다. 일반적으로 전체 가상화를 지원하지 않는 아키텍처를 가상화할 수 있게 해 준다.
단점: 게스트 OS가 네이티브 기능에 대해 하이퍼콜을 지원하려면 게스트 OS를 수정해야 한다.
OS 레벨 가상화
OS 가상화에서는 가상 시스템이 없고 전적으로 단일 OS 내에서 가상화가 이루어진다. 게스트 시스템은 기본 OS의 공통된 기능과 드라이버를 공유하며, 완전히 분리된 컴퓨터와 모양과 느낌이 유사하다. 각 게스트 인스턴스는 자체적인 파일 시스템, IP 주소 및 서버 구성을 가지며 완전히 다른 애플리케이션을 실행한다(그림 11 참조).
장점: 소규모로가볍고 속도가 빠르며고 효율적이며 대량의 가상 인스턴스를 지원할 수 있다.
단점: 인스턴스 격리 및 데이터 관련 보안이 중대한 문제이다. 가상 인스턴스는 반드시 동일한 OS를 지원해야 한다.
애플리케이션 가상화
여느기타 다른 유형의 가상화와 마찬가지로 애플리케이션 가상화를 위해서는 가상화 계층이 존재해야 한다. 가상화 계층은 가상화 애플리케이션이 기본 파일 시스템으로 보내는 모든 호출을 가로채어 가상 위치로 리디렉션한다. 애플리케이션은 물리적 플랫폼으로부터 완전히 분리되어 가상화 계층하고만 상호 작용한다. 이렇게 되면 상호 호환되지 않는 애플리케이션을 병렬로 실행할 수 있다. 예를 들어, Microsoft Internet Information Services 4.0, 5.0 및 6.0을 모두 병렬로 실행할 수 있다. 또한, 설계 시점에서 염두에 두지 않은 OS에서도 애플리케이션을 원활하게 실행할 수 있도록 지원함으로써 애플리케이션의 이동성을 향상시켜 준다(그림 12 참조).
장점: 애플리케이션의 이동성을 향상시켜 서로 다른 운영 환경에서도 실행할 수 있게 해 준다. 호환되지 않는 애플리케이션의 병렬 실행을 지원하고, 주문형 애플리케이션 스트리밍을 통해 애플리케이션 구축 속도를 향상시켜 준다.
단점: 가상 시스템 지원에 따른 부담으로 런타임 및 네이티브 환경 모두에서 애플리케이션의 실행 속도가 더 늦어질 수 있다. 모든 소프트웨어를 가상화할 수 있는 것은 아니므로 완벽한 솔루션이 되지 못한다.