Citrix MetaFrameCitrix MetaFrame 을을 통한통한 웹웹 기반기반 어플리케이션어플리케이션 구축구축

By Citrix Consulting Services

Citrix Systems, Inc.

주의

이 간행물에 대한 정보는 경고 없이 바뀔 수 있다.

이 간행물은 특정 목적이나 합법화를 위한 어떤 종류의 수정-그것이 명백하든 암시적이든 - 에 대한 보증-시장성에 대한

보증을 포함하여 - 없이 ‘현재 상태’로 제공된다. CITRIX SYSTEMS, INC. (“CITRIX”), 는 비록 앞으로 발생할 손상의

가능성에 대해 충고를 하였을 지라도 기술적 혹은 편집상의 오류 또는 이 간행물에 생략된 것에 대해서는 책임을 지지

않는다. 또한, 이 간행물을 사용, 이행, 공급함으로써 발생하는 직접적, 우발적, 필연적 혹은 어떤 종류의 손상에 대해서도

책임을 지지 않는다.

이 간행물은 저작권법에 의해서 보호된 정보를 포함한다. 내부적인 배포를 제외하고 이 간행물의 어떤 부분도 Citrix 로

부터의 서면 승인없이 어떤 형태로든지 재생산되거나 사진 복사될 수 없다.

Citrix 제품에 대한 배타적 보증은, 만일 있다면, 그 제품에 첨부된 제품 문서에 기술되어 있다. Citrix 자체의 생산품 외에는

보증하지 않는다.

이 곳에 언급된 제품명은 해당 회사의 상표이거나 등록된 상표일 수 있다

Copyright © 2002 Citrix Systems, Inc., 6400 NW 6th Way, Ft. Lauderdale, Florida 33309 U.S.A. All rights reserved.

Version History

1.0 Doug Dobson 5/30/2002

2.0 Jo Harder 7/20/2002

3.0 Doug Dobson 10/14/2002

3.1 Randall Jacques 10/17/2002

3.2 Doug Dobson 1/17/2003

목 차목차.................................................................................................................................................................................................. III

서론………………………………………………………………………………………………………....1

웹 기반 어플리케이션이란?............................................................................................................................3

용어정의와 기능……………… …………………………………………………………………………………………………………..3

프로세싱과 컨트롤………………………………………………………………………………………………………………………...3

시사점………………………………………………………………………………………………..………………………..6

Citrix Metaframe 과 웹 어플리케이션……………………………………………………………………………………………………..10

부록 A: 의사 결정 격자………………………………………………………………………………………………………………………10.

Business Drivers……………………………………………………………………………………………………………..10.

Technical Drivers…………………………………………………………………………………………………………………….......12

부록 B: 샘플테스트 및 제 3 자 소프트웨어…………………………………………………………………………………………………13

샘플테스트……………………………………………………………………………………………………………………13

제 3 자 소프트웨어…………………………………………………………………………………………………………………………13

Citrix MetaFrame 을 통한 웹 기 반 어플리케이 션 구축 ii

Introduction 새로운 기술과 어플리케이션의 빠른 발전을 지원하면서, 신뢰성과 일관된 어플리케이션 접근을 어떻게 균형을 맞출 것인가 하는 문제는 IT 부서에 끊임없이 제기되는 과제이다. 지속적인 데스크탑 프로세싱 파워의 향상은 IT 설계자에게 데스크탑에서 보다 복잡한 기능과 프로세싱이 가능하도록 만들어 왔다. 분산컴퓨팅이 좀더 적은 비용으로, 효율성을 증진시키고, 어플리케이션에 대한 접근을 유연하게 제공할 것으로 예견되었다. 어느 정도 이런 목적들은 데스크톱이 워크스테이션 수준까지 발전하여 클라이언트 서버 및 로컬 어플리케이션을 동시에 탑재하면서 충족되었다.

그러나, 기술이 발전함에 따라, 비용을 줄이고,신뢰성을 증진시키고 개선하기 위한 방안을 채택해 왔다. 데스크탑에서 어플리케이션을 적용/유지 하는데 드는 과도한 비용을 들이지 않고, 데스크탑의 기능을 적용하기 위한 방법을 제공하기 위해 브라우저 기반 기술(Web apps)이 출현하게 되었다. 이 방법은 다음과 같은 이점이 있다:

데스크톱/워크스테이션 유지 비용의 절감

하드웨어 업그레이드 비용의 절감

WAN 이나 LAN 을 통한 장소에 구애 받지 않는 접속

어플리케이션 구축, 업그레이드 및 배포 속도의 향상

사용자 지원 및 관리 비용의 절감

사례들을 볼 때 이러한 이점들이 얻어질 수 있는 반면 다음과 같은 점들이 해결되어야 함을 알 수 있다.

IT 기획자들은 기능성을 희생하면서 브라우저를 통해 접속 가능한 웹 인터페이스를 전달하는 ‘화려한’ 사용자 인터페이스(User Interface, UI)를 갖추도록 요구 받고 있다.

시스템이 중앙에 집중하여 있으므로, 네트워크 주변의 사용자들은 데이터에 대한 빠르고 신뢰성 있는 접속을 요구한다. 그러나 브라우저를 기반으로 한 구현은 사용자가 요구한 정보의 모든 바이트를 전송해야 하는데, 이는 네트워크가 반드시 대용량의 데이터 흐름을 다룰 수 있도록 설계되어야 함을 의미한다. 이러한 설계는 높은 비용의 증가를 초래할 수 있으며 대역폭의 용량을 초과하게 될 수도 있다. 그러나 IT 기획자는 반드시 성능요구사항을 충족시켜야만 한다.

어떤 브라우저를 사용하느냐에 따라 지원하는 기능이 달라지므로 특정 브라우저를 지원하도록 결정을 내려야 한다.

더욱 견실한 환경이 되기 위해서는 클라이언트 쪽 스크립팅 및 컨트롤이 필요한 데, 이는 더욱 높은 수준의 하드웨어, 소프트웨어 및 네트워크 사양을 요구하게 된다.

다른 브라우저 버전, 다양한 어플리케이션의 브라우저 요구사항, 그리고 부가 어플리케이션(예를 들어 MS Word)에 대한 요구 등은 데스크톱으로 인한 절감 효과를 감소시킨다.

사용자들의 웹 기반 어플리케이션의 기능성에 대한 이해와 채택은 기대하는 것보다 느리다. 이로 인해 줄어든 기능성은 개별 사용자들의 업무 효율을 떨어뜨리기도 한다.

- 1 -

가장 마지막에 언급된 내용이 아마도 가장 심각한 문제일 것이다. 이 문제를 해결하기 위해, 웹 어플리케이션은 비슷한 비용으로 기준 성능은 유지하면서, 기능성은 향상시키면서 사용자에게 풍부한 UI 를 제공하는 길을 찾고 있다.

이 보고서에서 우리는 Citrix MetaFrame 이 이러한 이슈들을 상쇄시키고 IT 조직이 오늘날의 IT 환경과 고객이 요구하는 효과를 얻기 위해 어떻게 사용될 수 있는지 논의할 것이다.

- 2 -

웹 기반 어플리케이션이란?

용어 정의와 기능“웹 기반 어플리케이션”은 광범위한 뜻을 담고 있다. 실제로, 웹/브라우저 어플리케이션은 4 가지 유형이 있으며 기업 어플리케이션은 일반적으로 최종 UI 를 전달하기 까지 이러한 4 가지 유형의 기술에 기반하고 있다.

단순 HTML/XML/XSL

클라이언트 측 스크립팅

서버 측 스크립팅/서버측 프로세싱

임베디드 객체/컨트롤

이들은 사용자에게 웹 페이지를 보여주기 위해 조합으로 사용 되어지기도 한다. 단순 HTML(Hyper Text Markup Language)은 거의 모든 웹기반 어플리케이션에서 사용될 것이다. HTML 은 포맷과 표현문법을 가지고 있으며 이는 브라우저에 의해 해석되어 최종 UI 로 사용자에게 보여진다.

HTML 과 XML(Extensible Markup Language)은 모두 특정 포맷으로 정보를 전달할 수 있다. 이는 태그를 사용하여 이루어지게 되는데:

XML 은 개발자가 그들 자신이 태그를 만들어, 정의하고, 전송하고, 유효성을 평가하고, 어플리케이션 사이에 혹은 조직들 사이에서 데이터를 해석할 수 있게 하는 것이 가능하게 한다.

XSL(Extensible Style Language)은 개발자가 포맷으로부터 컨텐츠를 구분하도록 하여 여러 웹페이지에 특정 스타일을 적용시킬 수 있게 한다. 즉 효과적으로 단일 포맷 문서를 재사용 가능하도록 하는 것이다.

나머지 세 가지의 기술들은 웹 어플리케이션이 철자 맞춤법을 조사하고 데이터베이스로부터 데이터를 요청하고, 정형화된 문서를 만드는 등의 프로세싱과 컨트롤 기능을 제공하도록 고안되었다.

프로세싱과 컨트롤클라이언트 측 스크립팅. 클라이언트 측 스크립팅은 클라이언트 브라우저가 웹사이트로부터 다운 받은 프로그램을 처리하고 수행시키는 것을 의미한다. ‘스크립팅’이라는 용어는 단지 프로그래밍 언어가 컴파일되지 않은 채로 사용된다는 것을 의미한다. 클라이언트 컴퓨터가 명령을 수행하도록 하기 위해서는, 그 스크립트는 이를 읽고 컴퓨터가 처리할 수 있는 명령으로 변환시키는 프로그램으로 보내져야 한다. 이 프로그램들을 가상머신( Virtual Machine, VM)이라고 부르며, 대부분 사용자들이 널리 알고 있는 것 중의 하나가 바로 자바 가상머신(Java Virtual Machine, JVM)이다.

문제를 더 복잡하게 하는 것은 어떤 스크립트와 언어는 특정 버전의 혹은 특정 공급자의 가상머신을 요구한다는 것이다. 따라서 이러한 유형의 구축은 IT 기획자들이 다음을 반드시 고려해야 한다는 것을 뜻한다:

스크립트를 실행하기 위해서는 얼마나 많은 양의 데이터가 다운로드 되어야 하는가 – 단지 스크립트면은 충분한가?

그 스크립트는 네트워크를 통해 얼마나 많은 데이터를 접속할 것인가?

그 스크립트를 빠르게 처리하기 위해서 클라이언트 시스템에 요구되는 메모리와 CPU 는 어느 정도 인가?

스크립트의 기능과 가상머신을 지원하기 위해 필요한 브라우저의 버전은?

- 3 -

클라이언트

클라이언트 브라우저가

스크립트를 요청

클라이언트에

스크립트를 다운로드웹 서버

컨텐츠

가상머신이

스크립트를 해석

웹페이지 / 문서 렌더링1 3 4

서버2

로컬 워크스테이션에 설치되어야 하는 가상 머신/지원파일들의 버전은?

스크립트가 실행되도록 하기 위해 요구되는 브라우저의 보안 설정은 어떻게 되는가?

스크립트로부터의 데이터 교횐 뿐만 아니라 최초 다운로드를 지원하는데 필요한 네트워크 대역폭의 최소 수순은?

다음 그림 – 1. 클라이언트 측 스크립팅은 단순화된 프로세스 흐름을 보여주고 있다.

그림-1. 클라이언트 측 스크립팅 흐름

서버 측 프로세싱. 서버측 프로세싱은 웹 서버나 비즈니스 계층 서버에서 스크립트가 실행되는 것을 의미한다. 이러한 접근 방법의 이점은 하드웨어 구성과 프로그래밍 등의 요구사항이 중앙에서 구현되며 관리된다는 점이다. 클라이언트 시스템은 간단히 서버에 요청을 하는데, 이는 통상 웹 서버에 (‘포스트’) 데이터를 보냄으로써 이루어진다. 그러면 웹 서버 객체는 요청에 대한 처리를 시작하거나, 다른 서버에서 돌고 있는 프로그램에 요청을 넘긴다. 결과가 도출되면, 웹서버는 다시 응답을 기다리고 있는 클라이언트에게 정보를 전송하게 된다. 서버의 응답을 대기상태로 기다리지 않을 수도 있는데, 이런 경우의 요청을 비동기 요청이라고 부른다.

앞장에서 언급한 많은 도전 과제들이 이 유형에서도 또한 존재한다. 이 유형의 핵심적인 이점은 IT 기획자가 보다 적은 수의 시스템(서버)과 작업하게 되고 시스템의 구성과 배포에 대한 완벽한 제어가 가능하다는 점이다. 그러나 그럼에도 다음과 같은 문제점들이 여전히 존재한다:

사용자들이 그들의 요청이 처리될 때까지 지연을 수용할 수 있는가?

어떤 기능들이 이 유형에 적합한가? 만일 철자 맞춤법 체크 같은 기능들이 클라이언트의 모든 데이터가 보내지고, 처리되어, 다시 되돌아 오도록 구현되는 것을 사용자들이 수용할 수 있을 것인가?

이 유형의 구조는 규모의 확대에 얼마나 대응할 수 있는가 – 특정 프로그램이 다른 서버로 프로세싱의 짐을 분산시키도록 구현이 가능한가? 어플리케이션 서버는 로드 분산이 구현될 수 있는가?

성공적으로 처리되기까지 얼마나 많은 그리고 얼마나 자주 데이터를 주고 받아야 하는가?

이 프로세싱 유형을 지원하기 위한 소프트웨어, 하드웨어 등의 요구사항 및 구성은 어떻게 되는가?

시스템의 보안은 어떻게 보증할 수 있는가?

이 유형의 기능은 보통 사용자들이 경험한 표준 어플리케이션에 비해 더 풍부하거나 더 쌍방향적이지 못하다 – 그들이 이를 수용하겠는가?

- 4 -

다음 그림-2. 서버 측 프로세싱은 단순화된 프로세스 흐름을 보여준다.

그림-2. 서버 측 프로세싱

임베디드 객체/컨트롤. 임베디드 객체/컨트롤이란 특정 어플리케이션을 위해 이미 만들어져 클라이언트 브라우저 혹은 어플리케이션에 다운 받게 만들어진 컴파일된 프로그램 혹은 클래스 파일이다. 이러한 기술은 스크립트 프로그램으로 수행될 때 보다 복잡하고 빠른 처리가 요구될 때 사용된다. 마이크로소프트 인터넷 익스플로러에서, 이 기술이 적용된 가장 흔한 예가 바로 ‘ActiveX 컨트롤’이다. 앞으로 마이크로소프트 닷넷의 개발 환경은 컨트롤 뿐만 아니라 현재의 표준 어플리케이션에서 가능한 풍부한 UI 와 유사하게 제공되는 온전한 폼 자체가 다운로드 되도록 할 것이다. 자바 어플리케이션의 경우, 이 프로그램은 종종 애플릿이라고 불리며, 지원 컨텐츠와 함께 자바 클래스 파일들 또는 JAR 파일들의 다운로드를 수반하기도 한다.

어떠한 기술이 사용되든지 간에, 이 프로세싱 유형에서 주목해야 할 것은 ‘다운로드’라는 용어이다. IT 기획들은 그 프로그램/객체가 클라이언트 데스크탑에 빠르게 닿을 수 있다는 것을 보장해야 한다. 이러한 기술을 사용할 때 공통적으로 고려해야 할 점으로 다음과 같은 것들이 있다:

다운로드 되는 양은 얼마나 큰가?

어플리케이션은 얼마나 자주 다운로드를 요청하게 되는가?

네트워크로 연결된 사용자들이 적정시간 내에 객체를 다운로드 할 수 있는가?

이러한 프로그램이 적절히 수행되기 위한 하드웨어 사양은 어떻게 되는가?

클라이언트 시스템에 요구되는 소프트웨어 및 설정은 어떻게 되는가?

로컬 워크스테이션에 설치되어야 할 가상머신/지원파일들의 버전은?(JAVA 의 JVM, .NET 의 CLR)

이러한 작업을 수행할 수 있도록 하는 브라우저의 보안 설정은 어떻게 되는가?

그 객체는 얼마나 많이 그리고 얼마나 자주 서버측에 데이터를 요청하게 되는가?

다음 그림-3. 임베디드 객체/컨트롤은 단순화 된 프로세스 흐름을 보여준다.

- 5 -

클라이언트

클라이언트

브라우저가

처리 요청을 전송

웹 서버 컨텐츠 웹 페이지 / 문서 렌더링

서버

웹 서버가 요청을 처리함

어플리케이션 서버가 로드분산 요청을 처리함

1

2 45

응답 컨텐츠

3

6

그림-3. 임베디드 객체/컨트롤

시사점 이 네 가지 기술 모두 소스로부터 클라이언트에 데이터를 전송하는 과정을 포함한다. 표현되어야 할 정보뿐만 아니라 포맷을 지정하기위한 문자들까지 전송하므로 단순 HTML 의 경우 가장 클라이언트의 역할이 적은 기술이다. 다른 모든 기술들의 경우에도 포맷을 지정하기위한 문자(HTML)와 처리되어야 할 모든 원시 데이터뿐만 아니라 프로세스를 수행할 코드 혹은 객체(컨트롤)들까지 전송되어야 한다. 궁극적으로는 브라우저는 요청한 정보를 사용자에게 보여줄 프레젠테이션 페이지까지 받게 된다.

그러나…모든 인프라 비용과 관리 비용을 절감시키면서 이러한 구성을 최적화할 수 있는 방안이 있다. 만일 IT 기획자가 기회의 관점에서 도전과제를 평가한다면, 다음과 같은 점들을 도출하게 될 것이다:

당신이 대역폭 사용을 줄일 수 있다면 당신은 더 싼 비용으로 네트워크 인프라를 구축할 수 있다. 당신이 가능한 최상의 성능을 낼 수 있다면 그 결과 얻어진 효율성은 기업의 전반적인 운용비용을

줄이게 될 것이다. 클라이언트 워크스테이션을 업그레이드 하지 않을 수 있다면 하드웨어 및 설치 비용을 절감할 수

있다. 당신이 프로세싱을 중앙 집중화 하고 클라이언트 어플리케이션의 설치를 단순화 할 수 있다면,

관리비용을 절감시킬 수 있다.

이러한 도전 과제들에 기반하여, 가용한 웹 기반 기술들을 살피는 것은 더욱 딜레마에 빠지게 한다: 각각의 기술들은 하나 혹은 두개 정도의 도전과제를 만족시켜 주지만, 네 개 중 어떤 것도 모든 도전과제를 충족시켜주지는 못한다. 그래서, 어플리케이션이 구축될 때 어떤 도전 과제들은 극복되지 않고 단지 최소화 되고 있을 뿐이다.

Citrix 시스템의 MetaFrame 기술은 웹 어플리케이션뿐만 아니라 현재 데스크톱에 구축된 거의 모든 어플리케이션을 지원할 수 있도록 확장 가능한 인프라를 구축하면서 이러한 도전과제를 충족시킬 수 있는 방안을 제공한다.

- 6 -

클라이언트

클라이언트

브라우저가 처리 요청웹서버 컨텐츠

웹 페이지 / 문서 렌더링

서버

어플리케이션이

객체 다운로드 요청1

2브라우저에 객체를 돌려줌

객체가 요청을

처리함

3

4브라우저에 돌려줌

5브라우저가 컨텐츠 전달

Citrix MetaFrame 과 웹 어플리케이션

Citrix MetaFrame 은 IT 기획자들이 직면한 네가지 근본적인 도전과제를 충족시키면서 사용자들이 기존 웹 어플리케이션과 인프라를 구축할 수 있게 한다:

대역폭/네트워크

성능

하드웨어 비용

중앙 집중 관제

대역폭/네트워크. MetaFrame XP™은 IT 관리자가 브라우저를 게시된 어플리케이션으로 사용 가능하게 한다. 이러한 구성 하에서는 클라이언트 시스템은 단지 ICA 트래픽만을 받으면 되는데, 이 ICA 트래픽은 주로 마우스의 움직임, 키보드의 키를 누름 스크린의 변화 등으로 이루어져 있다. 이 결과 초고속 네트워크 기간망 상에 위치한 웹 어플리케이션 서버와 브라우저를 함께 위치하도록 하면서 전반적인 네트워크 활용도를 낮추게 된다. 이 때문에 어플리케이션 성능이 수많은 네트워크 요청을 처리하고 있는 네트워크의 한시적 가용성에 의존하지 않을 수 있게 된다.

웹 어플리케이션은 버스트 형태의 행태를 보이기 때문에, 평균 대역폭 사용량은 브라우저 기반의 어플리케이션에 ICA 를 비교하는 적절한 수단이 되지 못한다. 이는 세션이 존재하는 매순간 특정량의 네트워크 트래픽이 ICA 세션이 활성화 될 때 발생되기 때문이다. 브라우저 어플리케이션의 경우, 사용자는 한시간에 2-3 회 데이터를 입력하고 2-3 회 응답을 받는다고 치면, 나머지 시간 동안 어플리케이션은 아무것도 하지 않는 상태로 있는다.

그러나 이러한 웹 어플리케이션은 ICA 와 평균 대역폭 관점에서 본다면 잘 해야 비슷한 정도의 결과를 낳는다. 보다 중요한 점은, MetaFrame 을 사용하지 않고 구축한 경우에는 사용량의 극점에서는 심각한 지연을 야기할 수 있다는 점이다. 만일 당신이 웹 어플리케이션으로부터 30 페이지 분량의 데이터를 요청한다면, 그 데이터의 모든 바이트가 네트워크를 통해 보내져야만 한다. 그 결과 그 2-3 회 동안, 사용자는 아마도 응답에 필요한 30초를 기다려야 할지도 모른다. ICA 의 경우, 모든 것이 로컬에 위치하고 최적화 될 수 있으므로, 그 응답을 받는데 걸리는 시간은 n 계층(비즈니스 계층) 응답 시간 + ICA 클라이언트에 보내져 요청된 화면 전환에 걸리는 시간 정도일 것이다.

분석의 최종단계에서 보면, ICA 는 상당히 낮은 수준(대체로 20Kbps 혹은 그 이하)에서 안정상태의 대역폭 사용량을 나타낼 것이다. ICA 사용량에서 단 몇 개의 극점들은 최초 시작 시, 파일 복사 혹은 프린트 요청 정도이다. 그러나 이 경우들에서도 이러한 작업들이 MF 서버와 기업네 네트워크 자원 사이에서 발생하기 때문에 웹 어플리케이션의 경우 보다는 대역폭 사용량이 낮다.,

성능. Citrix MetaFrame 은 관리자가 Citrix Resource Manager 를 사용하여 성능을 감시하고 그들이 게시한 어플리케이션의 로드를 분산 시킬 수 있도록 하기 때문에 사용자들이 단순 대역폭 대비 성능 비 이상의 성능 기대효과를 얻을 수 있도록 한다. 사용자들은 서버 클래스에 접속할 수 있게 하면서 IT 기획자들이 어플리케이션 관제 및 배포를 단순화 하게 한다.

하드웨어 비용. 이 문서에서 논의된 모든 주제들에 총소유 비용(Total Cost of Ownership, TCO)이라는 개념이 적용될 수 있다. 그러나, 기업들에게는 TCO 보다는 하드웨어 비용이 더 일반적으로 통용된다. 실제로 사용자들을 업그레이드 하는 비용은 데스크톱 당 약 $2,000 정도에 이른다고 한다. 그러나, $6,000

- 7 -

짜리 IU 나 블레이드 서버를 구축함으로써, IT 기획자는 15 명, 30 명, 심지어 40 명까지의 사용자들에게 서버 클래스의 성능 개선 효과를 전달할 수 있을 것이다.

중앙 집중 관제. 중앙집중 서버를 두고 어플리케이션을 데스크톱에서 분리해 가져옴으로써, IT 기획자는 인건비를 절약할 수 있을 뿐 아니라 그들의 어플리케이션 배포 인프라의 신뢰도를 증가시킬 수 있게 된다.

다음 “그림-4. Citrix MetaFrame 을 통한 웹 어플리케이션“은 Citrix MetaFrame 을 통해 웹 어플리케이션을 구현한 시스템의 구성도를 보여주고 있다.

그림-4. Citrix MetaFrame 을 통한 웹 어플리케이션

푸른색 상자 내에 있는 숫자는 Citrix 를 통한 접속의 프로세스를 나타낸다. 명백함을 제공하기 위해, WAN 과 LAN 을 통한 접속을 그림 속에 포함 시켰다. 표준 웹 어플리케이션에 대한 프로세스는 붉은 상자로 표시했다.

- 8 -

Citrix MetaFrame 접속:

1. 클라이언트는 NFuse Classic 또는 Citrix ICA 클라이언트를 활용하여 인터넷 브라우저 어플리케이션의 실행을 초기화 한다.

2. Citrix Secure Gateway(CSG)가 이 요청을 처리하고 유닉스와 윈도우를 구분하여 MetaFrame 서버에 연결시켜준다. WAN 을 통해 되돌아 오는 ICA 트래픽은 따로 표시하지 않았음에 유의하기 바란다. CSG 는 사용자가 안전하게 SSL 혹은 TSL 을 사용하여 연결될 수 있도록 한다.

3. 게시된 브라우저가 브라우저 어플리케이션에 대한 요청을 하면, 이는 단지 내부 네트워크를 통해 MetaFrame 서버상에서 돌고 있는 브라우저 세션에서 내부(혹은 외부)웹서버 까지 전달한다.

4. 서버측 프로세싱에 대한 요청이 오면, 웹 서버는 그 요청을 비즈니스 어플리케이션 서버에 전달한다.

5. 비즈니스 어플리케이션 서버는 필요 시 데이터베이스 계층/서버에 접속한다.

6. 터미널 및 워크스테이션 등의 내부 클라이언트들은 로컬 데스크 톱에 어플리케이션을 배포하거나 유지하는데 필요한 추가 비용을 들이지 않고 어떤 장애도 없이 빠르게 어플리케이션에 접속할 수 있다.

고유 브라우저 접속:

1. 사용자가 웹 어플리케이션을 요청한다. 이 요청은 그 사이트에 대한 보안을 위해 외부 접속 기술이 사용되지 않았다면 일반적인 웹 서버를 통해 이루어져야 한다.

2. 방화벽을 거쳐, DMZ(혹은 내부) 웹 서버로부터 데이터가 교환된다.

3. 웹 서버는 안전한 TCP 연결을 통해 내부 IT 자원들에 접속한다.

4. 서버측 프로세싱이 요청되면, 웹 서버는 이 요청을 비즈니스 서버로 넘기게 되고 필요하다면 다시 데이터베이스 계층에 접속하게 된다.

이 그림에서 주목해야 할 핵심적인 사항은 다음과 같다:

Citrix MetaFrame 서버를 통해 중앙 집중 제어가 가능하다.

Citrix MetaFrame 을 통한 웹 어플리케이션 구축은 그렇지 않은 경우 보다 보안이 더 잘 유지될 수 있다. 왜냐하면 스크린의 변화, 마우스 클릭 등의 정보 외에 무의미한 데이터가 네트워크 밖으로 보내지지 않기 때문이다.

Citrix MetaFrame 의 아키텍처는 데스크톱 관리를 단순하게 하고 부가적인 어플리케이션들을 보급하기 위해 LAN 및 WAN 사용자들에 의해 조정될 수 있다.

무거운 네트워크 트래픽이 LAN 내부에 고립되게 되므로, IT 기획자는 WAN 인프라를 유지하는데 드는 비용을 절감 시킬 수 있다.

- 9 -

Appendix A: Decision Grids아래에 있는 표는 MetaFrame 을 통해 웹 기반 어플리케이션을 구축할 때 다뤄야 할 고려사항과 그에 대한 솔루션들이다. 이 표에서는 포괄적이지는 않지만 단지 IT 아키텍처를 변경하고자 할 때 다루어야 할 가장 일반적인 내용들을 다루었다.

Business Drivers이슈 도전과제 Citrix MetaFrame 솔루션

제어와 보안 만약 사용자가 중간계층이나 데이터 베이스/파일 서버에 바로 접근할 수 있다면 보안이 훼손 될 수 있다.

제어는 중간계층과 데이터 베이스/파일 서버에 게이트웨이 역할을 하는 MetaFrame 서버에 집중될 수 있다.

MetaFrame 서버는 방화벽 뒤에 위치하여 CSG 를 사용하여 외부 사용자가 안전하게 접속할 수 있게 한다.

SAP, PeopleSoft, Oracle, and Siebel 과 같은 벤더에 의한 지원

웹 기반 클라이언트 지원 MetaFrame 구축 지원

IT 리소스 요구사항

각 데스크 탑은 개선될 필요가 있다. 이것은 수동으로나 Group Policies 와 같은 도구를 통해서 수행될 수 있다.

사용자들은 웹 브라우저 사용권한을 수정할 가능성이 있다. 그리고 교정 위해 헬프데스크 지원이 요구된다.

이슈가 발생하면, 그 이슈가 웹 브라우저, 로컬 클라이언트 장치(device) 또는 어플리케이션에 의한 것인지 즉시 알 수 없다.

표준화된 웹 브라우저와 버전이 명시되지 않은 곳은 헬프데스크 지원이 더 복잡해 질 수 있다.

사용자들은 OS 와 웹 브라우저의 종류 그리고 버전에 따라 다양한 경험을 가지고 있어서 헬프데스크가 지원하기가 쉽지 않다.

사용자들은 MetaFrame server 를 통해 어플리케이션에 접속해야 할 필요가 있다. 접속수단이 하나인 점은 더 빠르게 문제해결이 이루어 질 수 있음을 의미한다.

지원 자원은 지엽적으로 각각의 컴퓨터 있지 않고 데이터센터 내에서 어플리케이션이 운영되기 때문에 집중될 수 있다.

웹 브라우저 사용 권한은 MetaFrame 서버에 잠겨 있게 된다. 따라서 사용자가 수정할 수 없다..

특정 웹 브라우저와 버전은 단지 접속 수단에 불과하다. 관리하는 것이 간소화된다.

사용자의 경험은 일관적이어야 하며 이슈는 쉽게 복제될 수 있다.

섀도잉 기법을 통해 지원 호출은 감소시키면서 헬프데스크 요원이 사용자에게 어플리케이션 기능을 실행하는 법을 보여주는 것이 가능하다.

- 10 -

이슈 도전과제 Citrix MetaFrame 솔루션

사용자 교육 사용자들은 특정 설정을 지원하기 위해 웹 브라우저의 세팅을 바꾸는 방법에 대해 교육 받아야 한다.

특별히 MetaFrame 을 통해 어플리케이션을 접근하게 되면 이를 위한 어떤 부가적인 사용자 교육도 필요 없다.

Citrix MetaFrame 비용

Citrix MetaFrame 서버와 라이슨스가 필요하다. 흩어져 있는 데스크탑, 지원 및 소프트웨어 관리의 비용이 반드시 비교되어야 한다.

Citrix MetaFrame 을 구축하면 더 효율적인 어플리케이션 구축, 지원, 그리고 향상된 시스템 관리능력 등으로 인해 결과적으로 총소유비용 (TCO)을 낮출 것이다. 헬프데스크 지원과 교육의 예에서 알 수 있듯이 그 밖의 많은 하드달러(hard dollar) 비용들이 다른 하드달러와 소프트달러(soft dollar) 절감으로 전환될 수 있다.

구축 시간 만약 특정 공급자의 혹은 특정 버전의 웹 브라우저가 필요하다면 구축시간이 길어진 수 있다.

어플리케이션은 몇 분 이내에 MetaFrame 을 통해 게시 된다.

사용자 장비 지원 특정 공급자의 혹은 특정 버전의 웹 브라우저가 필요할 수 있다.

ICA 클라이언트를 지원하는 어떤 장비도 가능하다. 현재 ICA 는 많은 장비들과 OS 에 의해 지원된다. 정확한 자료를 원한다면 http://www.citrix.com/download/ica_clients.asp 에서 가용한 Citrix ICA 클라이언트에 대한 자료를 찾아보기 바란다.

어플리케이션 접속 시간

네트워크 트래픽의 버스트 특성으로 인한 응답시간의 불규칙성

어플리케이션 속도와 응답시간은 더 빠르다(테스트에 의해 확인 될 수 있다)

여유분 (Redundancy)

다중 혹은 클러스터 웹 서버는 여유공간을 필요로 할 수 있다.

복수개의 MetaFrame 서버는 로드 밸런싱 기능을 내장하고 있어 서버의 다운 등이 미치는 영향이 최소가 되게 한다.

비용 흩어져 있는 데스크탑을 지원하고 다양한 어플리케이션 구조를 지원하는 능력에 드는 비용이 늘어남에 주의를 기울일 필요가 있다.

모든 유형의 어플리케이션의 구축 및 관리에 드는 총 소유비용이 줄어든다.

- 11 -

Technical Drivers이슈 도전과제 Citrix MetaFrame 솔루션

특정 자바 가상머신과 ActiveX/플러그 인 프로그램들

모든 데스크탑에 수정이 가해져야 할 필요가 있을 수 있다. 이것은 Group Policies 와 같은 도구나 혹은 수작업으로 행해질 수 있다.

중앙의 MetaFrame 서버를 통해 쉽게 배포될 수 있다.

임베디드 객체와 클라이언트 측 스크립팅

데스크탑이 표준화 되지 않은 것은 많은 문제를 야기시킬 수 있다.

MetaFrame 을 통해 배포 되기 때문에 다운로드 시간과 CPU 활용에 관한 이슈가 효과적으로 다루어 질 수 있다.

API 호출 등과 같이 인터넷 익스플로러 또는 넷스케이프 네비게이터에 대한 어플리케이션 종속성

사용자가 특정 웹 브라우저에 대해 선호하고 있을 수 있으며 왜 어느 브라우저에서 제대로 작동하지 않는지에 대해 이해하지 못할 수 있다

MetaFrame 를 통하므로 어떤 브라우저를 사용해도 상관 없다. 모든 사용자는 같은 방식으로 접속하게 된다.

보안 보안 패치가 각각의 클라이언트 워크스테이션에 설치될 필요가 있는데 이는 많은 시간을 들여야 하고 보안 취약성을 유발 시킬 수 있는 가능성을 만들게 된다.

보안 패치는 빠르고 효과적으로 MetaFrame 에 설치될 수 있다.

어플리케이션 종속성 도움말 어플리케이션이 개별 클라이언트 데스크톱에 필요하다.

도움말 어플리케이션은 MetaFrame 서버에 위치하여 쉽게 접속하여 사용할 수 있다.

테스트, 시험 출시 및 제품 출시

만약 사용자자 브라우저와 버전을 선택하도록 한다면 이런 상황에 대한 관리자의 제어가 매우 제한적이다.

제어 가능하다.

대역폭 요구사항 만약 어플리케이션이 본래 네트워크 트래픽을 압축하지 않는다면 압축되지 않은 상태로 보내지게 된다.

ICA 는 네트워크 트래픽을 압축하여 최소화 한다.

- 12 -

부록 B: 샘플 테스트 및 제 3 자 소프트웨어

샘플테스트만약 여러분의 조직내에 MetaFrame 으로 웹기반 어플리케이션을 구축하려고 한다면 이 테스트를 시도하라.

MetaFrame 을 통해 웹 브라우저를 인터넷에 게시하라.

게시된 어플리케이션을 통해 웹 브라우저를 접속하라.

여러 내부와 외부 웹 페이지에 접근해서 웹 페이지가 완전히 열릴 때까지 몇 초가 걸리는지 기록해라.

로컬 클라이언트를 통해 동일한 웹 페이지에 접근해라.

이 간단한 테스트에서 얻은 속도와 반응시간의 결과는 사용자 관점에서 어떤 방법이 가장 빠른지에 대한 척도를 제공한다.

제 3자 소프트웨어 2002년 10월 현재, 가동되고 있는 웹 기반 클라이언트들은 다음 소프트웨어 사업자들에 의해 보증된 것들이다:

Oracle

PeopleSoft

SAP

Siebel

J.D. Edwards

제 3 자 소프트웨어 사업자들의 전체 리스트와 그들의 MetaFrame 에 대한 지원을 보기 원한다면, 이곳을 방문하기 바란다:

http://www.citrix.com/cba – 이곳은 Citrix 비즈니스 제휴 업체들을 위한 웹사이트이다.

http://www.citrix.com/support - 이곳은 Citrix 지식 기반 웹사이트로 많은 백서들과 제 3 자 소프트웨어 공급자들이 작성한 설치 기록을 담고 있다.

- 13 -

6400 NW 6th Way Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com

Copyright © 2002 Citrix Systems, Inc. All rights reserved. Citrix, WinFrame and ICA are registered trademarks, and MultiWin and MetaFrame are trademarks of Citrix Systems, Inc. All other products and services are trademarks or service marks of their respective companies. Technical specifications and availability are subject to change without prior notice.