애플리케이션 가상화
상태바
애플리케이션 가상화
  • 데이터넷 관리자
  • 승인 2006.11.08 00:00
  • 댓글 0
이 기사를 공유합니다

Product Review
“DLL의 지옥에서 탈출하라”
알티리스·소프트리시티·씬스톨 제품 평가 … 다른 방식 그러나 같은 효과

애플리케이션 가상화는 DLL 충돌을 피하고 애플리케이션 배포의 무거운 짐을 윈도 클라이언트로 덜 수 있게 해준다. 이러한 애플리케이션 가상화를 제공하면서 각각 다른 방식으로 접근하고 있는 세 가지 제품을 살펴봤다.

가상화가 요즘은 대유행이다. 이는 관리자들이 OS 레이어에서 가상화를 할 수 있게 해주는 제품(VM웨어나 마이크로소프트의 버추얼 PC 등)들이 시장에 쏟아져 나와 있는 것만 보아도 잘 알 수 있다. 포레스터의 전망에 따르면 북미지역 기업의 40%가 서버 가상화를 사용하고 있으며, 2008년이면 대부분의 서버 하드웨어에 이 기술이 탑재될 것이라고 한다.
그렇다면 애플리케이션 레벨에서 가상화를 적용시키는 것은 어떨까? 많은 회사들이 이 새로운 분야에 발을 들여 놓고 있는데, 이것은 애플리케이션 가상화, 애플리케이션 고립(isolation), 애플리케이션 샌드박싱(snadboxing), 애플리케이션 스트리밍 등 다양한 용어로 불리고 있다. 어떤 이름이든 그 프로세스에는 운영 시스템이나 다른 애플리케이션으로부터 이것을 고립시키는 레이어에서의 애플리케이션 래핑(wrapping)이 포함돼 있다. 즉, 애플리케이션이 무엇을 하든 이것은 실행되고 있는 다른 애플리케이션에게 영향을 주거나, 혹은 영향을 받을 수 없다.
애플리케이션이 필요로 하거나 수행하는 어떠한 파일이나 레지스트리 변경이든 고립이 되며 래퍼 레이어에 의해 캡처된다. 그 결과 애플리케이션은 배포가 훨씬 수월해지며 사용자 워크스테이션에서의 제거도 한결 편리하다. 가상화된 애플리케이션은 서버에서 사용할 수는 있지만, OS 가상화가 서버 쪽에서 이뤄지고 애플리케이션 가상화는 클라이언트 쪽에 속하게 될 가능성이 더 많다.
지금까지는 대부분의 중대형 IT 조직들이 사용자에게 애플리케이션을 배포하기 위한 규약을 갖고 있어야 했다. 이 프로세스에는 레퍼런스나 ‘골드 머신’으로 필요한 모든 애플리케이션을 설치한 다음 이것을 복제(cloning)하거나 노벨 젠웍스(Novell ZENworks) 또는 마이크로소프트 시스템 매니지먼트 서버 등과 같은 소프트웨어 배포 시스템을 이용해 한 번에 하나씩 애플리케이션을 배치하는 일이 포함될 것이다.
이러한 옵션들은 기본적인 소프트웨어 배포용으로는 문제가 없지만 두 개의 애플리케이션이 같은 DLL의 서로 다른 버전을 필요로 할 경우에는 라이브러리 충돌이 일어날 수 있다. 예를 들어 아웃룩과 유도라가 다른 버전의 MAPI32. DLL을 사용하려 할 때가 있다. 마이크로소프트 오피스의 버전 업그레이드 프로세스에서는 또 다른 문제가 일어날 수 있는데, 어떤 문서는 새 버전을 이용해 열려야 하는 반면 어떤 것들은 예전 버전을 이용해야 한다. 두 개의 오피스 버전이 같은 컴퓨터에서 돌아가는 일은 흔치 않을 것이다.
그리고 애플리케이션 지원 그룹에서는 다중 애플리케이션 버전에 대한 기술 지원을 제공해야 하는데, 이것은 기본적으로 기계당 한번만 설치가 가능한 것이다. 여기서 바로 애플리케이션 가상화가 도움을 줄 수 있다. 이것은 애플리케이션을 쉽게 배포하고, 같은 기계에서 한 애플리케이션의 여러 버전을 쉽게 돌릴 수 있도록 해준다.
가상화는 또한 워크스테이션에서 애플리케이션의 부담을 덜어 준다. 애플리케이션을 삭제한 후 제거되지 않은 추가 파일들을 청소하려면 OS를 다시 설치해야 하는 게 보통이었으며, 이것은 워크스테이션 성능을 저하시킬 수 있다. 하지만 가상화가 있으면 가상화된 애플리케이션에 의해 사용된 엔트리들이 OS 레지스트리로 들어가지 않고 가상의 공간으로 들어가기 때문에 레지스트리가 팽창될 일이 적다. 그 결과 OS가 깨끗한 상태로 유지되기 때문에 재설치가 필요한 일이 준다. 그리고 애플리케이션이 가상화되는 방식에 따라 애플리케이션을 다시 원래 설치된 상태로 돌려놓을 수도 있다.
가상화된 각 애플리케이션의 DLL 인스턴트는 다른 애플리케이션의 것들과는 독립적으로 유지되기 때문에 새로운 가상화 애플리케이션이 예전에 설치된 것들과 간섭을 일으킬 가능성은 적다. 하지만 모든 애플리케이션이 가상화될 수 있는 것은 아니다. 장비 드라이브나 기타 커널 레벨의 액세스가 필요한 프로그램은 가상화에 적합치 못하다. 그리고 하드웨어 스캐너에 포함된 것 같은 장비 드라이버에 의존하는 프로그램들도 마찬가지로 후보에서 제외시켜야 한다.
우리는 알티리스(Altiris) SVS(Software Virtulization Solution), 소프트리시티(Softricity) 소프트그리드 유니버설 데스크톱(SoftGrid Universal Desktop), 씬스톨(Thinstall) 임베디드(mbedded) 등 사용 가능한 제품 유형을 잘 대변하는 3가지 애플리케이션 가상화 제품들을 평가했다. 각각은 서로 다른 방식으로 윈도 컴퓨터용의 애플리케이션 가상화에 접근하고 있다.
알티리스와 소프트리시티 제품은 윈도 워크스테이션에 고립 레이어를 제공하는 작은 클라이언트를 설치한다. 씬스톨 임베디드는 클라이언트리스(clientless)로 윈도 OS에 어떤 특별한 것도 설치될 필요가 없고, 대신 새로운 가상화된 애플리케이션의 일부로 작은 클라이언트 조각이 번들링된다. 가상화는 어베일리전트(Availigent)의 듀레이션(Duration) 같은 다른 제품에서는 유닉스/리눅스 플랫폼에서 수행되며, 메이오시스(IBM이 인수)의 메타클러스터(MetaCluster)라는 제품은 유닉스 시스템용의 클러스터 환경에서 애플리케이션 가상화를 수행할 것이다.

알티리스 SVC
알티리스의 SVC 클라이언트는 가상화된 애플리케이션에서 가상 레지스트리 및 파일 저장소로 호출 방향을 조정해 주는 파일 시스템과 윈도 레지스트리용의 필터 드라이버를 제공한다. 클라이언트는 작으며 파일을 열 때 약간의 성능이 영향을 받겠지만 일단 파일이 열리면 눈에 띌 만한 어떠한 차이도 탐지되지 않았다.
씬스톨와 소프트리시티에서는 가상화된 애플리케이션 파일이 가상화된 애플리케이션 밖에서는 보이지가 않는데, 이는 곧 파일이 윈도 익스플로러에서도 숨겨진다는 얘기다. 하지만 SVC에서는 그렇지가 않다. 파일은 마치 애플리케이션 설치자에 의해 거기에 설치된 것처럼 보인다. 이 때문에 같은 프로그램의 여러 버전을 동시에 돌리는 것은 가능하지 않으며, 한 번에 애플리케이션의 한 버전만이 활성화될 수 있다.
이것은 또한 바이러스나 악성 사용자가 애플리케이션에 손상을 입히고 돌아가지 못하게 할 수 있다는 의미기도 하다. 긍정적인 쪽으로 생각하자면 이런 메커니즘은 애플리케이션 패키지를 설치됐을 때의 상태로 재설정을 하고 GUI 관리 혹은 명령어 라인 프로그램을 이용해 어떠한 변경 사항이든 제거하기가 편리하다. 심지어 삭제된 파일을 복구할 수도 있다. SVC는 SMS나 젠웍스를 포함한 기존 애플리케이션 배포 시스템과도 작동할 것이다. 이런 종류의 시스템을 사용하지 않고 있다면 알티리스의 SDS(Software Delivery Solution)를 구입해 SVC 패키지 전달을 보다 간편하게 할 수 있다.
SVC를 이용해 애플리케이션을 가상화하기는 어렵지 않다. 관리 툴을 이용해 ‘새 레이어 만들기(Create new layer)’ 마법사를 시작하면 된다. 그런 다음 ‘애플리케이션 설치(Install application)’ 옵션을 이용해 애플리케이션의 설치 바이너리 로케이션을 입력한다. 그러면 관리 툴에서 설치를 시작한다. 일단 프로세스가 완료되면 SVC는 읽기 전용 레이어로 가상화된 애플리케이션을 구축하며, 여기에는 어떠한 이전/이후 스냅샷도 필요치 않다.
미리 패키징된 오픈소스 애플리케이션들이나 svsdownloads.com과 같은 사이트에서 무료로 다운로드 받아 SVC와 함께 사용할 수 있는 애플리케이션들도 있다. 다운로드를 받고 나면 SVC 클라이언트가 있는 워크스테이션에서 이것을 활성화시키기만 하면 된다. 우리는 이 사이트에서 오픈 오피스(Open Office) 2.0을 다운로드 받아 이 기사를 작성하는 데 사용했다.
다중 소프트웨어 패키지를 평가해야 하는 관리자들은 SVC에 감사할 것이다. 애플리케이션이 가상화되게 하고 단일 워크스테이션에서 사용될 수 있게 준비를 갖추는 일은 우리가 살펴 본 다른 두 개의 시스템보다 훨씬 수월했다. 평가가 끝난 후 소프트웨어의 모든 흔적을 지우는 데는 동작을 중지시키고 레이어를 삭제하기만 하면 됐다. 그리고 노드당 25달러 또는 개인이 집에서 무료로 사용할 수 있는 SVC는 가능성 있는 저가 옵션이다.

소프트리시티 소프트그리드
소프트리시티 소프트그리드는 완전한 애플리케이션 관리 및 배포 시스템을 제공한다는 방식을 택하고 있다. 그 클라이언트-서버 아키텍처는 회사 인력(모바일 사용자 포함)이 자신들이 필요로 하는 애플리케이션을 설치 및 가동시킬 수 있게 해주는 확장성 있는 방안을 제공한다.
소프트그리드는 마이크로소프트의 AD(Active Direc-tory)와 IIS(Internet Information Services)를 중심으로 만들어졌다. 이미 인프라에서 돌아가고 있는 AD 도메인이나 IIS가 없는 조직이라면 제품을 사용하기 전에 이런 기술을 먼저 이행해야 하는데, 이것은 소프트그리드에게 크게 불리한 점이다.
각각의 워크스테이션은 소프크그리드 데스크톱 클라이언트를 필요로 하는데, 이것은 버추얼 애플리케이션 서버나 서버 풀과 통신해 로그인한 사용자나 특정 워크스테이션에서 어떤 애플리케이션으로 권한이 허가돼 있는지를 확인해 준다. 이러한 애플리케이션용의 아이콘은 파일 연합과 함께 로컬 워크스테이션에 추가된다. 파일 연합은 예전에 사용자 워크스테이션에 설치되거나 여기서 돌아갔을 수도 있고 아닐 수도 있는 애플리케이션을 사용자가 열 수 있게 해준다.
가상화된 애플리케이션이 워크스테이션에서 시작되면, 소프트그리드는 로컬 워크스테이션으로 애플리케이션을 스트리밍하기 시작할 것이다. 가상화된 애플리케이션은 패키징돼 프로그램을 설치 및 가동시키는 데 필요한 파일이 먼저 전송되게 한다.
소프트그리드는 필요한 것만 워크스테이션으로 스트리밍을 하고, 이것을 워크스테이션에서 로컬로 캐싱할 것이다. 가상화된 애플리케이션은 또한 사용자나 관리자에 의해 강제로 완전 캐싱을 하게 될 수도 있다. 이것은 모바일 인력이 많을 때 편리한데 그 이유는 원격 워크스테이션이 네트워크로부터 접속을 끊기 전에 필요한 것을 갖고 있는지 확인할 수 있기 때문이다.
씬스톨과 마찬가지로, 돌아가고 있는 가상화된 애플리케이션 그 자체만이 가상 애플리케이션 번들에 패키징된 파일을 보거나 액세스할 수 있는 유일한 것이다. 다른 애플리케이션들은 가상 애플리케이션 파일이 존재하는지조차 알지 못하기 때문에, 동시에 여러 버전의 애플리케이션을 돌리는 게 가능해진다. 예를 들어 우리는 같은 워크스테이션에서 아무 문제없이 마이크로소프트 워드 XP와 워드 2003을 동시에 사용했다.
소프트그리드는 단순한 애플리케이션 가상화 이상의 일을 한다. 즉, 라이선스 추적과 규정준수 보고를 수행할 수 있게 해주기 때문에, 구입한 소프트웨어 라이선스가 실제로 사용되고 있는지 여부를 파악하는 프로세스가 간편해진다. 소프트그리드의 클라이언트 액세스 라이선스는 이름이 있는 사용자나 장비당 200달러며, 무제한 서버 및 시퀀서의 라이선스는 5천달러다. 소프트리시티는 최근 마이크로소프트가 인수했다. 이 회사는 당분간은 제품 라인을 바꾸지 않을 계획이며, 장기적으로는 중소기업 시장을 넓히는 데 마이크로소프트가 힘이 될 것이라고 밝혔다.

씬스톨 임베디드
씬스톨의 모든 애플리케이션 파일과 레지스트리 엔트리뿐 아니라 실행시간 클라이언트는 하나의 EXE 파일 안에 통합돼 있다(가상화되는 애플리케이션에 따라 매우 큰 파일이 될 수도 있다). 사용자가 사용자 모드에서 애플리케이션을 돌릴 수 있는 한 이들은 단지 띄우기만 하면 가상화된 애플리케이션을 돌릴 수 있다. 애플리케이션이 종료된 후에는 가상화된 애플리케이션에 의해 만들어진 모든 파일 또는 레지스트리 변화를 포함하고 있는 몇 개의 임시 파일들만 남아 있을 것이다.
애플리케이션이 다시 실행되면 이전 실행에서 달라진 것들이 이 임시 파일로부터 사용될 수 있다. 관리자는 간단히 로컬 워크스테이션으로 파일을 복사하고, 애플리케이션을 띄우기 위한 데스크톱 숏컷(shorcut)을 제공하거나 하나의 EXE를 로컬 워크스테이션으로 복사하는 대신 네트워크 공유로부터 가상화된 애플리케이션을 띄워 줄 아이콘을 제공할 수 있다.
씬스톨에서 제공하는 클라이언트리스 솔루션의 약점은 안전해 보이는 기계가 예를 들어 사용자가 좋아하지만 금지된 프로그램이 가상화된 애플리케이션으로서 돌아가는 것으로 인해 손상을 입을 수 있다는 것이다. 물론 사용자가 가상화 소프트웨어를 사는 데서 문제를 겪을 일은 없겠지만, 씬스톨 기술을 이용해 가상화된 애플리케이션이 인터넷에 공짜로 돌아다닐 가능성은 있다.
또 한 가지 약점은 단일 EXE 파일을 복사함으로써 소프트웨어 해적질(pirating)이 쉽게 이뤄질 수 있다는 것이다. 다행히도 씬스톨의 빌트인 라이선싱 메커니즘은 관리자가 애플리케이션을 다양한 소프트웨어 식별자들(MAC 어드레스 등)과 연결시킬 수 있게 해줌으로써 이것을 방지하고 있다.
씬스톨 기술은 또한 가정/원격 직원용으로 유용하게 사용될 수 있다. IT부서는 하나의 단일 애플리케이션 바이너리를 CD에 두고 컴퓨터에 배치될 때 이것이 자동실행 되도록 할 수 있다. 원격 근로자는 워크스테이션에 실제로 소프트웨어를 설치할 필요없이 애플리케이션을 돌릴 수 있다.
씬스톨 임베디드는 ISV/ISP 시장을 타깃으로 하며, 루슨트, 퀄컴, T-모바일 및 美 국방부에서 내부적으로 사용하고 있다. 가상화된 타깃 애플리케이션을 구축하기 위해 특정 애플리케이션에서 어떤 파일과 레지스트리 설정을 돌릴 필요가 있는지를 알아야 하기 때문에, 이것은 내부에서 개발한 애플리케이션용으로 이용하는 게 가장 좋다.
좋은 소식은 이 기술이 잘 작동한다는 것이다. 우리는 로컬로 개발된 애플리케이션을 어려움 없이 가상화된 것으로 바꿀 수 있었다. 예제 파일과 레지스트리 설정 등을 포함해 전체 애플리케이션을 하나의 단일 EXE 파일에 묶은 다음, 이 EXE를 사용자가 파일 및 레지스트리 변경을 하지 못하도록 잠궈 둔 워크스테이션으로 가져가 네트워크 공유로부터 이것을 실행시켰다.
애플리케이션의 오픈 파일 대화창을 이용해 우리는 애플리케이션이 로컬일 경우 예제 파일이 있을 로컬 하드 드라이브 로케이션으로 브라우징을 했다. 물론 예제 파일은 사실과 다르게 로컬 파일 시스템에 있는 것처럼 나타났다.
우리는 또한 이 애플리케이션이 설치된 장소에 몇 개의 임시 파일을 쓴다는 사실을 알고 있었다. 잠긴 워크스테이션에서 우리는 애플리케이션이 이런 파일을 시스템에 쓸 수 있게 해야만 했다. 즉, 다른 애플리케이션이나 바이러스가 파일을 만들거나 변경할 수도 있는 구멍을 만들었다. 가상화된 애플리케이션은 마치 이 임시 파일을 써버릴 수 있는 것처럼 행동했다. 물론 이 로컬 파일 시스템에 대해 어떠한 권한도 허용되지 않은 상태였다.
씬스톨의 또 한 가지 특성은 이것이 만들어내는 단일 바이너리가 파일을 압축하고(기본 설정) 심지어 이들을 암호화할 수도 있다는 것이다. 압축이란 곧 애플리케이션 바이너리가 서버에 상주할 때 가상화된 애플리케이션을 띄우는 데 필요한 네트워크 대역폭 양이 줄어든다는 얘기다.
씬스톨은 이제 곧 IT 관리자들을 타깃으로 하는 씬스톨 버추얼라이제이션 스위트(Thinstall Virtualization Suite)라는 새 제품의 베타 버전을 내놓을 계획이다. 우리는 이 소프트웨어 제품의 알파 버전을 볼 기회가 있었는데, 이것은 관리자들이 전형적인 소프트웨어 패키지 설치를 캡처해 이것을 가상화된 애플리케이션으로 바꿀 수 있게 해줬다. 어떤 애플리케이션이든 이런 식으로 가상화가 이뤄질 수 있다면 좋을 것이다.
깨끗한 윈도 워크스테이션의 스냅샷을 먼저 확보한 다음, 가상화될 소프트웨어 패키지를 설치하고, 애플리케이션을 실행하고, 필요한 맞춤화를 하게 된다. 그리고 두 번째 스냅샷을 확보하면 된다. 그러면 버추얼라이제이션 스위트가 어떤 변화든 캡처해 그 정보를 가상화된 애플리케이션을 구축할 수 있는 포맷으로 저장해줄 것이다. 이것은 분명 주목해 볼 만한 가치가 있는 제품이다.
씬스톨 임베디드는 애플리케이션당 5천달러, 워크스테이션당 15달러며, 씬스톨 버추얼라이제이션 스위트는 관리자당 1만달러, 워크스테이션당 75달러가 될 예정이다. 애플리케이션 가상화는 이미 시장이 성숙했음을 감안할 때 모든 이들의 관심 대상 목록에 있어야 하며, 윈도 애플리케이션이 처음부터 패키징돼 있어야 했을 방식이기도 하다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.