1.1   "시스템의 CPU 사용량" 은 어떻게 측정되는가?

Solaris 운영체제는 1초에 100번씩 CPU가 어떤 일을 하는지 감시한다. 이때 CPU가 user mode에서 작업을 실행하면 user_tick에 1을 증가 시키고, system mode에서 작업을 실행하면(애플리케이션이 시스템 콜을 호출하여 커널에서 실행되고 있는 경우) system_tick에 1을 증가시킨다.
CPU가 실행할 작업이 없어서 쉬고 있는 경우, I/O(block device: hard disk)를 기다리는 작업이 있으면 wait_tick에 1을 증가시키고, 그렇지 않으면 idle_tick에 1을 증가시킨다.
vmstat나 sar 명령어는 이러한 값을 시스템으로 부터 얻어서 주어진 시간간격(interval) 의 차이 값을 구하여 각각을 백분율(%)로 나타낸 것이 CPU 사용율이다.

만일 sar 명령어로 10초 간격으로 시스템 사용량을 조사하면, sar 명령어는 먼저 위에서 설명한 값을 시스템으로 부터 얻어 오고, 10초 후에 한번 더 얻어와서 2회 측정한 값의 차이 값을 각각의 백분율로 보여 준다.

예를 들어, 10초 간격으로 CPU 사용율을 조사하면,

Tick

First

Second
(10 sec later)

Delta
(Total: 1000)

%

user

230

430

430-230 = 200

200/1000*100 = 20%

system

350

500

500-350 = 150

150/1000*100 = 15%

wait

160

310

310-160 = 150

150/1000*100 = 15%

idle

160

660

660-160 = 500

500/1000*100 = 50%

다음은 CPU 사용율을 알아보는 명령어 sar 와 vmstat 명령어의 결과이다. 

# sar -u 1 10
14:43:22    %usr    %sys    %wio   %idle
14:43:23       3       7      26      64
14:43:24       0       5      33      62
14:43:25       1       4      39      56
14:43:26       1       3      40      56

# vmstat 1 
 procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr f0 s0 s1 s1   in   sy   cs us sy id
 0 0 0 2330808 102048 3  18 21  4  4  0  3  0  1  0  0  430  431  339  1  0 99
 0 1 0 674656 95224 215   8 6720 0 0  0  0  0 808 0  0 1879 9666 1871  3 11 86
 0 1 0 674656 89584 190   0 3560 0 0  0  0  0 406 0  0 1601 4239 1064  0  5 94

위의 결과에서 보면, sar 명령어는 CPU 사용량을 %usr(user)와 %sys(system)과 %wio(wait)와 %idle(idle)로 구분하고, vmstat에서는 us(user)와 sy(system)과 id(idle)로 구분한다.
%wio의 값은 CPU의 사용율과는 무관하다. 이 값은 CPU가 놀고 있을 때, IO를 기다리고 있는 프로세스가 있는지 여부를 알아보는 힌트이다.
IO를 기다리는 프로세스가 있다는 것은 그 IO가 완료되면 곧 바로 CPU를 다시 사용할 것이라는 것을 암시한다. 유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix,solaris

sar 와 vmstat 명령어의 결과는 다음과 같은 관계이다. 

         sar     vmstat		CPU
---------------------------------------------------
         %usr  =  us		run on user mode
         %sys  =  sy		run on system mode
%wait + %idle  =  id		idle
선 솔라리스 solaris, scsa, scna 선 솔라리스 solaris, scsa, scna 선 솔라리스 solaris, scsa, scna
이제 가상화에 대한 기존의 고정 관념으로부터 탈피할 때입니다

Bill Vass가 새 레터로 여러분을 다시 찾아 뵙습니다. 애독자들이 행여라도 제 글에 두서가 없다고 생각하시기 전에, 저는 이 레터를 통해 당사가 기업 데이터센터의 비용 절감, 하드웨어 이용률 증대, 애플리케이션의 가용성과 성능 향상 등을 가능하게 하는 다양한 기술들을 구축하고 있다는 사실을 밝혀 두는 바입니다.

최근의 레터에서 우리는 어떻게 썬의 CMT 프로세서가 데이터센터의 요구사항을 감소시키고, 오픈소스와 OpenSolaris가 보안 및 애플리케이션 성능을 강화하고, 오픈소스 미들웨어가 레거시 투자를 최대한으로 보호할 수 있는지에 관해 살펴보았습니다. 이번 호에서는 잠시 발길을 되돌려 오늘날의 기업들에게 초미의 관심사가 되고 있는 가상화에 관해 논해볼까 합니다.

가상화를 아주 간단하게 설명하자면 기본적인 하드웨어로부터 컴퓨팅 리소스를 추출하는 일이라고 할 수 있습니다. 한편, 가상 머신 기술은 최근에 가상화 자체와 거의 동의어가 되어버린 새로운 현상으로 부상하기에 이르렀지만, 가상 머신은 결코 가상화의 ‘시작이자 끝’은 아닙니다. Solaris Container와 같은 운영체제 가상화 방식은 매우 중요한 역할을 담당합니다. 또한 보다 넓은 관점에서 볼 때, 그리드는 애플리케이션의 개발/제공 방식을 획기적으로 바꾸어 놓을 수 있는 그리고 이미 광범하게 보급된 가상화/공유 아키텍처에 커다란 잠재력을 부여합니다.

가상화의 사업적 타당성
데이터센터에서 하드웨어를 유지 보수하는 데 상당한 비용이 초래될 수 있다는 것은 누구나 알고 있는 사실이며, 실제로 전력, 냉각, 공간 관련 비용은 IT 예산의 3중고에 해당한다고 할 수 있습니다. 대부분의 기업들의 경우, 피크 로드에 대비해서 시스템을 증축하긴 하지만 피크 타임은 사분기 말이나 연말에 집중될 뿐이고 나머지 기간의 하드웨어 이용률은 10%에서 15% 선에 불과합니다. 그 결과 상당량의 리소스가 그대로 방치되는데, 이는 자본과 전력과 공간의 엄청난 낭비로 이어집니다.

대형 서버 팜의 관리는 비용 증가의 또 다른 요인으로 작용하게 되며, 하드웨어 가격이 하락함에도 불구하고 관리비는 계속해서 치솟습니다. 대규모 데이터센터의 직접 비용은 차치하고라도, 모니터하고 유지 보수할 물리적 시스템의 수를 줄이는 일은 가상화 기술을 채택할 수밖에 없는 또 다른 동기가 됩니다. 물론, 이것은 기업이 단순히 물리적 관리를 가상 머신 관리로 대체하지 않는다는 가정 하에서의 얘기입니다.

자주 거론되지는 않지만 이에 못지 않게 중요한 것은 기업들이 애플리케이션의 가용성을 하드웨어에 주로 의존한다는 사실입니다. 대부분의 조직체는 애플리케이션과 비즈니스의 지속적인 운영을 보장하고 심각한 다운타임을 피하기 위해 리던던트 하드웨어를 구현하곤 하지만 하드웨어 리던던시는 애플리케이션 가용성을 보장하는 데 완벽한 수단이 되지 못할 뿐 아니라 데이터센터의 비용을 가중시키기까지 합니다.

이용률과 리던던시 문제를 동시에 해결할 수 있는 수단으로 부상하게 된 가상화는 애플리케이션과 운영체제 인스턴스가 하드웨어 리소스를 공유하게 함으로써 이용률과 투자수익률을 높여줍니다. 가상화는 기본 하드웨어에서 소프트웨어를 추출함으로써 까다로운 하드웨어에 의존하지 않고도 애플리케이션 리던던시를 구현할 수 있으므로 가용성 향상에 특히 효과적입니다. 요컨대, 조직체는 가상화를 통해 다음의 목표를 달성할 수 있게 합니다.

  • IT 및 비즈니스 유연성 향상
  • 인프라의 신속한 확장 및 축소
  • 가용성 향상 및 애플리케이션 성능 강화
  • 애플리케이션 관리의 간소화 및 소요 비용 대비 애플리케이션 성능 증대

가상 머신의 여명기
이제 가상 머신 기술은 가상화의 일반적 형태로 확고하게 자리매김하였습니다. 본질적으로 이 기술은 특정 물리적 시스템이 복수의 가상 운영체제 인스턴스를 호스트할 수 있게 해주며, Solaris, Linux, Windows와 같은 다양한 운영체제가 동일 하드웨어 상에서 평화롭게 공존할 수 있도록 도와줍니다.

근년 들어 VMware 기술은 가상 머신 시장에서 가장 유력한 후보로 떠올랐는데, VMware 가상화 기술의 원리는 먼저 부트되는 미니 운영체제처럼 행동하면서 본질적으로 기본 하드웨어를 작은 조각들로 가상화하여 동일한 물리적 서버 상에서 다양한 운영체제가 실행될 수 있도록 하는 하이퍼바이저를 생성하는 것입니다. 이런 접근법은 혼용 운영체제 환경을 필요로 하는 레거시 애플리케이션을 보유한 조직체에게 특히 유용한 것으로 입증되었습니다.

 
가상화에 의한 통합: Sun x64 서버 제품 라인

VMware 가상 머신 방식은 매력적이긴 하지만 성능 면에서 볼 때는 상대적으로 고가입니다. 일반적으로 하이퍼바이저는 총 CPU 파워의 5~15%를 소비하며, 각 운영체제의 오버헤드는 점진적으로 증가하게 됩니다. 결국 기업들은 단지 가상 머신 인프라를 지원하기 위해 대량의 CPU 리소스를 소비하게 되는 셈입니다. 또한 가상 머신은 애플리케이션에 장애가 발생할 경우 애플리케이션, 운영체제, 가상 머신 기술 중 어디에 원인이 있는지 파악하기 어렵기 때문에 가시성(observability)에 부정적인 영향을 줄 수 있습니다.

최근에는 Open Source Xen 소프트웨어가 VMware의 대안으로 떠오르고 있는데, Xen도 VMware와 마찬가지로 동일한 하드웨어 상에서 복수의 게스트 운영체제를 실행할 수 있게 해줍니다. Xen은 훨씬 낮은 레벨의 가상화 방식으로, 관리자가 메모리와 CPU를 포함한 시스템의 다양한 부분을 가상화할 수 있게 합니다. Xen은 이처럼 낮은 레벨에 상주하기 때문에 상당한 수준의 리소스와 장애 격리 기능을 제공할 수 있습니다.

Xen을 고려하지 않을 수 없도록 만드는 이유로는 여러 가지가 있습니다. 첫째, Xen은 오픈소스입니다. 둘째, Xen은 상대적으로 경량이므로 과도한 양의 CPU 리소스를 소비하지 않습니다. 셋째, Xen은 가상 머신 기술 간에 높은 수준의 격리 효과를 실현합니다. 끝으로, Xen은 다른 가상 머신 기술과 마찬가지로 혼용 운영체제와 버전을 지원하며 관리자가 서비스에 영향을 주지 않고 운영체제 인스턴스를 동적으로 인스턴스화하고 실행할 수 있게 해줍니다.

가상 머신으로 Solaris Container 사용하기
모든 솔라리스 10 OS 사용자에게 무료로 제공되는 또 다른 형태의 가상화가 존재하는데, 그것은 바로 Solaris Container입니다. 솔라리스 환경에서는 Solaris Container를 이용해서 각 애플리케이션에 자체적인 IP 주소, 파일 시스템, 사용자, 할당된 리소스를 부여함으로써 애플리케이션 환경을 가상화할 수 있습니다. 게다가 Solaris Container는 커널 레벨에서 가상화가 이루어지기 때문에 극히 부담이 적다 할 수 있습니다. 또한 복수 커널의 오버헤드가 추가되지 않기 때문에 단일 서버 상에서 수천까지는 아니더라도 수백 개의 Solaris Container를 실행하는 것도 가능합니다. 이 외에도, ‘Solaris Containers for Linux Applications’과 더불어 Solaris Container에서도 Linux 애플리케이션을 전혀 수정하지 않고 실행할 수 있습니다.

Solaris Container는 복수의 운영체제 인스턴스를 허용하지는 않지만 그 외에 다음과 같은 여러 가지 이점을 제공합니다.

이용률 향상: 컨테이너는 오버헤드를 추가하지 않고 작업부하로 인해 요구되는 리소스만을 소비하기 때문에 이용률을 증대시켜 줍니다.
관리비 경감: 관리자가 각각의 작업부하를 위해 별도의 운영체제 인스턴스를 유지할 필요가 없기 때문에 관리비 절감 효과가 뛰어납니다.
탁월한 가시성: 특히 실시간 문제해결을 위한 DTrace 등의 다른 솔라리스 기능과 연계하여 가상화된 환경에 대해 뛰어난 가시성을 제공합니다.
신속한 프로비저닝: 다양한 시스템과 서비스 구성에 대해 광범위한 회귀 검사(regression testing)를 수행하는 QA 환경에서처럼 신속한 프로비저닝과 호스트의 단기적 가용성을 보장해 줍니다.
라이센스 비용 절감: 하나의 OS 라이센스로 수백 개의 Solaris Container를 지원할 수 있기 때문에 잠재적으로 라이센스 비용을 절감시켜 줍니다.

하지만 가상 머신이 제공하는 더 높은 레벨의 리소스와 장애 격리 기능을 과소평가해서는 안 됩니다. 때로는 애플리케이션이 Solaris Container의 능력을 넘어선 수준의 격리를 요구하는 경우가 있는데, 바로 이런 경우에 가상 머신을 Solaris Container와 연계해서 사용하면 최고 수준의 격리, 이용률, 관리 용이성을 달성할 수 있습니다.

Solaris Container와 가상 머신의 혼합
가상 머신과 Solaris Container의 혼합이 유용한 사례를 살펴보기로 하겠습니다. 보안이나 성능상의 이유로 패치가 필요한 애플리케이션, 그리고 패치 레벨이 충돌하는 또 다른 애플리케이션이 있다고 가정합시다. 그리고 Windows 운영체제에 연결된 제3의 레거시 애플리케이션이 있습니다. 이 세 개의 애플리케이션은 세 가지의 서로 다른 가상 머신 운영체제 인스턴스에서 실행되어야 합니다. 이번에는 동일한 환경에 패치의 관점에서 관용성을 지닌 4개의 애플리케이션이 더 있다고 가정해 봅시다.

이 예에서, 자체적인 운영체제 인스턴스를 요하는 세 개의 애플리케이션은 가상 머신을 이용하여 가상화될 수 있고, 네 번째 가상 머신 운영체제 인스턴스는 단지 하나의 솔라리스 인스턴스를 요하는 애플리케이션들을 위한 4개의 Solaris Container를 수용할 수 있습니다. 이 경우 다음과 같은 이점이 있습니다.

  • Solaris Container는 애플리케이션들이 동일한 패치 세트를 공유할 수 있게 해줍니다.
  • 관리자는 단 하나의 운영체제 인스턴스만 유지하면 됩니다.
  • 관리자는 복수의 가상 머신을 추적할 필요가 없습니다.
  • 조직체는 관리비를 절감할 수 있습니다.

그리드: 과거와 현재와 미래의 가상화
지금까지 이 레터의 내용은 가상화를 둘러싼 논의의 지평을 확대한다는 면에서 상당히 온건한 편이었습니다. 하지만 이제부터는 다릅니다. 가상화가 오랫동안 사용되어 왔으면서도 가상화의 측면이 거의 거론된 적이 없던 영역이 있습니다. 그것은 바로 그리드입니다. 그리드는 첫눈에 가상화처럼 보이지 않을지도 모르지만, 이 레터의 시작 부분에서 제시한 정의-기본적인 하드웨어에서 컴퓨팅 리소스를 추출하는 작업-를 상기한다면 가상화의 사례로 이보다 더 알맞은 것도 없을 것입니다.

기업이 가상화 환경을 향해 나아가다 보면 가상화는 본질적으로 그리드 환경을 지향한다는 것을 알게 될 것입니다. 그 이유는, 가상화된 솔라리스 인스턴스와 복수의 Solaris Container가 있을 경우, 이 컨테이너의 리소스는 복수의 그리드에 의해 소비될 수 있기 때문입니다. 애플리케이션 그리드는 소프트웨어를 서비스로 제공하는 그리드 프레임워크에 의해 형성·제어될 수 있으며, 그리드 엔진은 컴퓨트 그리드의 초과 사이클(excess cycles)을 활용할 수 있습니다. 실례합니다. 여느 때처럼 제가 좀 서두르는 것 같군요.

그리드는 물론 새로운 것이 아니며, 연산 집약적 작업을 집단적으로 처리하기 위한 수단으로 이용되어 왔습니다. 즉, 그리드는 복잡한 기상 시뮬레이션을 제작하고, 막대한 지하 유전을 측량하고, 핵 폭발의 결과를 유추하고, 복잡한 금융 파생상품의 재정 실적을 시뮬레이트하고, 영화의 개별 프레임에 다층 구조를 추가하는 등의 작업에 사용되어 왔던 것입니다. 결국 과중한 프로세싱 요구에 직면하는 대다수의 산업이 그리드에 크게 의존하고 있는 것이 현실입니다.

“Stateless vs Stateful” 그리드
전통적인 그리드의 작동 원리는 매우 단순했습니다. 영화 스튜디오에서 어떤 영화의 1,000개 프레임을 텍스처 매핑해야 하는 경우, 그리드 컨트롤러는 1,000개의 병렬 프로세스를 산출하고 이를 같은 수의 서버로 보냅니다. (물론, 가상 환경에서라면 1,000개의 물리적 서버 또는 CPU 대신 1,000개의 Solaris Container만으로 쉽게 해결되겠지만.)

 
그리드의 작동 방식을 보려면 Sun Utility Grid를 참조하십시오

어떤 경우든, 하나의 서버가 다운되면 그리드 컨트롤러는 다른 999개의 작업부하를 수집하여 1개가 모자라는 것을 확인한 다음 나머지 부하를 정상적인 서버로 분산시킵니다. 이 가장 기본적인 형태의 그리드를 stateless 그리드라고 하는데, 그 이유는 누군가가 한 서버에 접근해 전원을 차단하더라도 전체적으로는 별 차이가 나지 않기 때문입니다. 그리드 컨트롤러는 단순히 없어진 작업부하를 다른 서버에 재할당하는 것입니다—아무런 손상이나 충돌도 없이 말이죠.

최근에는 이른바 stateful 그리드가 출현하기에 이르렀습니다. 썬은 엄청난 양의 불필요한 프로세싱 파워를 지닌 데스크탑을 여러 대 설치하는 대신 디스플레이 그리드와 Sun Ray 씬 클라이언트를 연계하여 사용자가 필요로 하는 시간과 장소에 맞추어 데스크탑을 제공합니다. 또한 썬의 그리드 컨트롤러는 700대의 디스플레이 그리드 전용 서버 중에서 각 개인이 필요로 하는 프로세싱 파워만을 제공합니다.

예를 들어, 어떤 직원이 사무실에 출근해서 StarOffice를 가동시키면 일반적으로 CPU의 총 프로세싱 파워 중 60% 정도가 필요할 것이므로, 그리드 컨트롤러는 이에 해당하는 양을 직원에게 제공하는 것입니다. 썬 디스플레이 그리드를 stateful 그리드라고 하는데, 그 이유는 사용자가 기본 인프라에 상태 기반(stateful) 연결을 하기 때문입니다. 따라서 누군가가 데스크탑의 전원을 꺼버리면 대개의 경우 사용자는 이를 알아차리게 됩니다.

애플리케이션 그리드를 통한 리소스 최적화
이번에는 보다 진보된 형태의 stateful 그리드인 애플리케이션 그리드에 대해 살펴보기로 하겠습니다. 어떤 회사가 비(非) RAC Oracle ERP 시스템을 그리드 환경으로 전환하려 하는데, 그 시스템은 전형적인 3-티어의 프레젠테이션 레이어, 애플리케이션 레이어, 데이터베이스 레이어 아키텍처로 구성되어 있다고 가정해봅시다. 웹 서버로 20개의 그리드 컨트롤러를 할당하고 그 중 4개를 로드 밸런서로 지정할 수 있습니다.

그런 다음 기업은 애플리케이션 서버의 역할을 하는 두 세트의 컨테이너 간에 stateful 클러스터를 생성하여 누군가가 애플리케이션 서버 중 하나를 꺼버릴 경우 그리드 컨트롤러가 정상적인 애플리케이션 서버에서 해당 작업을 재개하도록 할 수 있습니다. 이제 회사가 그리드에 데이터베이스 레이어를 추가할 경우 그리드는 컨테이너를 stateful 컴포넌트로 할당하고, 심지어 그 컨테이너들을 그리드 전반에 걸친 고가용성 클러스터로 만들어 컨테이너들이 다양한 물리적 위치를 차지하도록 할 수 있습니다.

과거에는 이런 아키텍처를 구축하려면 독립형 Oracle ERP 시스템이 각 레이어에 대해 20개 정도의 CPU를 전담시켜야 했을 것입니다. 전형적인 ERP 시스템의 경우 오전에 맹공을 당하고 잠시 소강 상태를 유지하다가 오후에 다시 프로세싱 요구가 피크에 달하는 경향이 있다는 사실에도 불구하고 말이지요. 역시 이 경우에도, 피크대를 위해 지나치게 많은 하드웨어와 리소스가 낭비될 뿐입니다.

 
이제 규모를 막론한 거의 대부분의 조직체들이 각자의 기본적인 하드웨어 인프라 전체를 모든 애플리케이션이 공유하는 리소스로 취급하게 되는 것은 시간 문제라 할 수 있습니다.

그리드 환경에서는 그리드 컨테이너를 이용해서 동일한 아키텍처를 생성할 수 있습니다. 따라서 웹 서버 레이어는 20개의 컨테이너로 구성되고, 애플리케이션 레이어는 10개의 주 컨테이너와 10개의 리던던트 컨테이너를 보유하고, 데이터베이스 레이어는 또 다른 10개의 컨테이너와 10개의 리던던시를 보유하도록 하는 것이 가능합니다. 그리고 모든 레이어가 동일한 가상 하드웨어 리소스를 공유하게 되는 것이지요.

하드웨어 이용률 100%를 향하여
진정한 변혁은 동일한 그리드 상에서 부하를—stateless이건 stateful이건 관계없이—믹스 앤 매치하는 것이 가능해진다는 사실입니다. 그리고 부하의 statefulness 또는 criticality가 주어진다면 우선순위를 할당하는 것도 가능해집니다. 예를 들어, StarOffice를 가동하는 직원은 백그라운드에서 실행되는 대규모의 stateless 부하로부터 CPU 파워를 가져옵니다. 마찬가지로, Oracle 애플리케이션이나 데이터베이스 서버가 프로세싱 파워를 요구할 경우 StarOffice 직원은 잔여 CPU 사이클을 확보하고 stateless 부하가 나머지 프로세싱 파워를 모두 가져오게 되는 것입니다.

결국, 모든 애플리케이션이 동일한 가상화 인프라를 공유하도록 하고 적절한 리소스 관리를 활용함으로써, 기업은 오늘날의 현실인 15%가 아닌 100%에 육박하는 하드웨어 이용률을 실현하고 애플리케이션 리던던시와 가용성을 동시에 향상시킬 수 있게 될 것입니다.

가상화와 그리드를 모두 함께
본 기사에서 그려 보인 시나리오는 결코 그림의 떡이 아닙니다. 바로 현실입니다. 기업들은 이미 VMware나 Xen과 같은 가상 머신 기술을 유용하게 활용하고 있으며, 많은 조직체가 이용률 향상을 위해 Solaris Container를 배치하고 있습니다.

또한 거대한 자동차 회사와 세계적 수준의 금융기관을 비롯한 일부 선도적 기업들은 가상화 운영체제, 가상화 애플리케이션, 공유 데스크탑 인프라, stateless/stateful 부하를 처리하기 위한 그리드 등을 포함하여 완벽한 가상화 환경으로 이동하고 있습니다.

이는 부정할 수 없는 대세입니다. 이제 규모를 막론한 거의 대부분의 조직체들이 각자의 기본적인 하드웨어 인프라 전체를 모든 애플리케이션이 공유하는 리소스로 취급하게 되는 것도 시간 문제라 할 수 있습니다. 이익은 크고 사업적 타당성도 너무나 명확한데 이에 관심을 갖지 않을 기업이 과연 있을까요?

Bill Vass
CIO
Sun Microsystems, Inc.
cio@sun.com


출처 : kr.sun.com
(1) 정의
 
     SCSI는 Small Computer Systems Interface의 약어로 PC에 내/외장으로 고속의 지능적인 I/O 장치를
     장착할 수 있는 기술로 장비에 따라 8~16개까지 연결이 가능합니다. SCSI 장비에는 하드디스크, 테이프
     드라이브, CD-ROM 등이 있습니다.
 
(2) 종류
     
 
SCSI 종류
표준
최고버스속도
(MB/s)
버스폭
(bit)
핀(pin)
최고 지원
드라이브수
SCSI-1
SCSI-1
5
8
50
8
Fast SCSI
SCSI-2
10
8
50
8
Fast Wide SCSI
SCSI-2
20
16
68
16
Ultra SCSI
SCSI-3
20
8
50
8
Wide Ultra SCSI
SCSI-3
40
16
68
16
Ultra2 SCSI
SCSI-3
40
8
50
4
Wide Ultra2 SCSI
SCSI-3
80
16
68
16
Ultra3 SCSI
SCSI-3
160
16
68
16
Ultra 160(/m) SCSI
SCSI-3
160
16
68
16
Ultra320 SCSI
SCSI-3
320
16
68
16
 
 
(3) 연결
 
  시스템에는 채널을 통해 데이터 송/수신을 제어, 감독하듯이 SCSI도 자체 처리능력이 있어 CPU의
  도움없이도 각 장치간의 통신을 제어할 수 있습니다.
 
(4) Terminators(종단기)
 
   SCSI 버스의 종료를 알리는 것입니다. 이것은 버스를 통과하는 반사되는 신호를 완충하는 역할을 합니다.
   터미네이션은 버스의 물리적으로 마지막 부분에 설치해줘야 합니다.
   컨넥터 종류를 불문하고 두가지로 분류하자면 패시브와 액티브를 들 수 있습니다. 패시브 터미네이터는
   SCSI 버스의 전력 신호를 사용하여 동작하고 액티브 터미네이터의 경우 더욱 정확한 전압 레귤레이터를 사용합니다.
 
Sun Solaris 멀티 쓰레드의 개념
 
<표 1>은 이 글에서 사용되는 몇 가지 용어를 소개하고 있다.
 
표 1 > 멀티 쓰레딩 용어
용어 정의
 
프로세스(process)

프로그램을 실행하기 위해 설정된 fork (2) 시스템 호출을 통해 생성된 UNIX 환경(파일 기술자, 사용자 ID 등)

쓰레드(thread) 프로세스 컨텍스트 내에서 실행되는 명령어 시퀀스
p쓰레드(POSIX 쓰레드) POSIX 1003.1c 호환 쓰레드 인터페이스
Solaris 쓰레드(Solaris thread) POSIX와 호환되지 않는 썬 마이크로시스템즈 쓰레드 인터페이스
단일 쓰레딩(single-threaded) 단일 쓰레드 액세스로 제한
멀티 쓰레딩(multithreaded)

2개 이상의 쓰레드에 대한 액세스 지원. 사용자(커널에 반대되는) 공간의 쓰레드

사용자 또는 애플리케이션 레벨 쓰레드
(User- or Application-level thread)		 라이브러리 루틴에 의해 관리되는 쓰레드
경량형 프로세스(lightweight process)

커널 코드 및 시스템 호출을 실행하는 커널의 쓰레드 (LWP라고도 불림)

바운드 쓰레드(bound thread) LWP에 영구적으로 연결되는 쓰레드
언바운드 쓰레드(unbound thread)

커널 지원 없이 매우 빠르게 컨텍스트 스위칭을 수행하는 디폴트 Solaris 쓰레드

속성 객체(attribute object)

POSIX 쓰레드, 상호 배제 락(mutual exclusion lock, mutexe) 및 조건 변수의 구성 가능한 측면을 표준화하기 위해 사용되는 데이터 타입 및 관련 조작 기능 포함

상호 배제 로크(mutual exclusion lock)

공유 데이터에 대한 액세스 락(lock) 및 언락(unlock)을 지원하는
기능

조건 변수(condition variables) 상태 변화 때까지 쓰레드를 차단(blocking) 하는 기능
카운팅 세마포어(counting semaphore) 메모리 기반의 동기화 메커니즘
패러럴리즘(parallelism) 최소 2개의 쓰레드가 동시에 실행되고 있을 때 발생하는 상황
동시성(concurrency)

최소 2개의 쓰레드가 진행될 때 존재하는 상황. 가상 패러럴리즘의 한 형태인 시간 분할(time slicing) 기능을 포함하고 있는 보다 일반적인 형태의 패러럴리즘.

 

멀티 쓰레딩 프로그래밍의 개념은 최소한 1960년 대로 거슬러 올라간다. UNIX 시스템 상에서의 멀티 쓰레딩 프로그램 개발은 1980년대 중반부터 시작됐다. 멀티 쓰레딩에 대한 정의와 이를 지원하는데 필요한 기능에 대한 합의가 이루어졌지만, 멀티 쓰레딩 구현에 사용되는 인터페이스는 매우 다양했다.
수년 간 POSIX(Portable Operating System Interface) 1003.4a라 불리는 그룹이 멀티 쓰레딩 프로그래밍을 위한 표준 개발에 주력했다. 현재, 이 표준은 승인을 받은 상태이다. 이 글은 POSIX 표준인 P1003.1b 최종 드래프트 14(실시간) 및 P1003.1c 최종 표준 10(멀티 쓰레딩)을 기초로 작성됐다.
또 여기서는 POSIX 쓰레드(p쓰레드라고도 불림) 및 Solaris 쓰레드를 모두 다루고 있다. Solaris 쓰레드는 Solaris 2.4 버전부터 지원되며, POSIX 쓰레드와 기능 측면에서 크게 차이나지 않는다. 한편, 이 글에서는 POSIX 쓰레드가 Solaris 쓰레드에 비해 이식성이 훨씬 뛰어나다는 사실을 감안, POSIX 관점에서 멀티 쓰레딩에 대해 알아보고자 한다.

 

> 애플리케이션 응답성 개선
많은 작업이 상호 의존적으로 수행되지 않는 프로그램의 경우, 이를 재설계해, 각 활동을 쓰레드로 정의할 수 있다. 예를 들어, 멀티 쓰레딩 GUI 사용자는 하나의 작업이 완료될 때까지, 다른 작업에 착수하는 것을 미룰 필요가 없다.

 

> 효율적인 멀티프로세서 활용
일반적으로, 쓰레드 실행시 동시성을 요구하는 애플리케이션은 가용 프로세서의 수를 고려할 필요가 없다. 애플리케이션 성능은 프로세서 추가를 통해 투명하게 개선된다.
행렬 곱셈(matrix multiplication)과 같이 패러럴리즘의 수준이 높은 수치 알고리즘 및 애플리케이션은 멀티프로세서 상의 쓰레드로 구현될 때, 훨씬 빠르게 실행될 수 있다.

 

> 프로그램 구조 개선
많은 프로그램을 단일 모놀리식(monolithic) 쓰레드가 아니라 여러 개의 독립적 또는 중간 독립적(semi-independent) 실행 유닛으로 구성함으로써 효율성을 높일 수 있다. 멀티 쓰레딩 프로그램은 단일 쓰레딩 프로그램보다 다양한 사용자 요구에 대한 보다 뛰어난 적응성을 갖게 된다.

 

> 최소한의 시스템 자원 활용
공유 메모리를 통해 공통의 데이터에 액세스하는 2개 이상의 프로세스를 사용하는 프로그램은 1개 이상의 제어 쓰레드를 적용하고 있다.
그러나, 각 프로세스는 완벽한 어드레스 공간 및 운영 환경 상태를 보유하고 있다. 대용량의 상태 정보를 작성 및 유지보수 하는데 소요되는 비용 때문에, 각 프로세스는 시간 및 공간 측면에서 쓰레드 보다 많은 비용을 소모하게 된다.
뿐만 아니라,프로세스 간의 구분 속성 때문에 프로그래머들은 서로 다른 프로세스 내 쓰레드 간 통신이나 그 실행을 동기화하는데 상당한 노력을 기울여야 한다.

> 쓰레드와 RPC의 결합
쓰레드와 RPC(Remote Procedure Call) 패키지를 결합함으로써, 비공유 메모리 멀티프로세서(예를 들면 워크스테이션 컬렉션과 같은)의 이점을 활용할 수 있다. 이러한 결합을 통해, 비교적 손쉽게 애플리케이션을 배포하는 것은 물론, 워크스테이션 컬렉션을 멀티프로세서로서 다룰 수 있게 된다.
예를 들면, 하나의 쓰레드로 하위(child) 쓰레드를 생성할 수 있다. 이들 각각의 하위 쓰레드는 원격 프로시저를 요청해, 다른 워크스테이션 상에서 프로시저를 호출하게 된다. 오리지널 쓰레드는 현재 병렬로 실행되고 있는 쓰레드만을 생성하지만, 다른 컴퓨터에서도 패러럴리즘이 구현된다.

 

> 동시성 및 패러럴리즘
단일 프로세서 상의 멀티 쓰레딩 프로세스의 경우, 해당 프로세서는 쓰레드 간의 실행 자원을 교환할 수 있기 때문에, 동시 실행이 이루어지게 된다.
공유 메모리 멀티프로세서 환경 내 동일한 멀티 쓰레딩 프로세스의 경우, 해당 프로세스 내에서 각 쓰레드는 별도의 프로세서 상에서 동시에 실행됨으로써 병렬 실행이 이루어지게 된다. 해당 프로세스에서 쓰레드 수가 프로세서 수와 같거나 이보다 적을 경우, 해당 운영 환경과 함께 쓰레드 지원 시스템은 각 쓰레드가 서로 다른 프로세서 상에서 작동할 수 있도록 보장하게 된다. 예를 들면, 쓰레드와 프로세서 수가 동일한 행렬 곱셈에서 각 쓰레드(및 각 프로세서)는 결과의 1 행(row)을 계산하게 된다.

 

> 멀티 쓰레딩 구조의 이해
기존의 UNIX도 이미 쓰레드 개념을 지원하고 있다. 즉 각 프로세스는 하나의 쓰레드를 포함하고 있기 때문에, 멀티프로세스를 이용한 프로그래밍은 멀티 쓰레드를 통해 수행된다. 그러나, 하나의 프로세스는 하나의 어드레스 공간을 의미하기 때문에, 하나의 프로세스를 구축한다는 것은, 하나의 새로운 어드레스 공간을 생성하는 것이 된다.
새롭게 생성된 쓰레드는 기존의 프로세스 어드레스 공간을 사용하기 때문에, 쓰레드를 만드는 것이 새로운 프로세스를 만드는 것보다 훨씬 저렴하다. 쓰레드 간 스위칭의 경우, 어드레스 공간의 스위칭을 포함하지 않기 때문에 쓰레드 간의 스위칭에 소요되는 시간은 프로세스 스위칭에 소요되는 시간보다 훨씬 적다.
쓰레드는 모든 것, 특히 어드레스 공간을 공유하기 때문에 단일 프로세스 내 쓰레드간 통신은 간단하다. 따라서, 하나의 쓰레드가 생성한 데이터는 다른 모든 쓰레드에서 즉시 사용할 수 있게 된다.
멀티 쓰레딩에 대한 인터페이스 지원은 POSIX 쓰레드의 경우 libpthread, Solaris 쓰레드의 경우 libthread 같은 서브루틴 라이브러리를 통해 이루어진다. 멀티 쓰레딩은 커널 레벨 및 사용자 레벨 자원을 분리함으로써 유연성을 부여하게 된다.

 

> 사용자 레벨 쓰레드
쓰레드는 멀티 쓰레딩 프로그래밍의 주요 프로그래밍 인터페이스이다. 사용자 레벨 쓰레드1는 사용자 공간에서 처리되며, 커널 컨텍스트 스위칭 과정을 배제하게 된다. 하나의 애플리케이션이 수백 개의 쓰레드를 가질 수 있으며, 여전히 많은 커널 자원을 소비하지 않는다. 애플리케이션이 사용하는 커널 자원의 크기는 주로 애플리케이션에 의해 결정된다.
쓰레드는 어드레스 공간, 개방된 파일 등과 같은 모든 프로세스 자원을 공유하고 있는 프로세스 내에서만 볼 수 있다. 아래와 같은 상태는 각 쓰레드에 따라 고유하게 지정된다.

 
쓰레드 ID
레지스터 상태 (PC 및 스택 포인터 포함)
스택
시그널 마스크(signal mask)
우선 순위
쓰레드 전용(thread-private) 스토리지
 

쓰레드는 프로세스 명령어와 프로세스 데이터의 대부분을 공유하기 때문에 한 쓰레드에 의해 공유 데이터 내에 변경이 이루어질 경우, 해당 프로세스 내의 다른 쓰레드가 이를 확인할 수 있다. 한 쓰레드가 동일한 프로세스 내의 다른 쓰레드와 상호 작용해야 할 경우, 운영 환경의 개입없이 이를 수행할 수 있다.
쓰레드는 기본값으로 초경량(lightweight)으로 설정되어 있다. 그러나, 쓰레드를 보다 완벽하게 제어하기 위해(예를들어, 스케줄링 정책을 보다 완벽하게 제어하기 위해) 애플리케이션은 이 쓰레드를 연결(binding)할 수 있다. 애플리케이션이 쓰레드를 실행 자원에 연결하면 쓰레드는 커널 자원이 된다.
사용자 레벨 쓰레드에 대한 내용을 요약하면 다음과 같다.

 

고유한 어드레스 공간을 생성할 필요가 없기 때문에, 보다 저렴한 비용으로 개발할 수 있다. 이는 런타임 시 어

 

드레스 공간에서 할당되는 가상 메모리이다.

커널 레벨이 아니라 애플리케이션 레벨에서 수행되기 때문에 신속하게 동기화할 수 있다.
libpthread 또는 libthread와 같은 쓰레드 라이브러리를 통해 손쉽게 관리할 수 있다.
 

> 경량형 프로세스
쓰레드 라이브러리는 커널에 의해 지원되는 경량형 프로세스라고 불리는 기본 제어 쓰레드를 사용한다. 이러한 LWP는 코드나 시스템 요청을 실행하는 가상 CPU로서 간주할 수 있다.
쓰레드를 이용해 프로그래밍하는데 있어, LWP 때문에 고민할 필요는 없다.


주 - Solaris 2, Solaris 7 및 Solaris 8 운영 환경의 LWP는 Solaris 2, Solaris 7 및 Solaris 8 운영 환경에서 지원되지 않는 SunOS 4.0 LWP 라이브러리의 LWP와는 다른 것이다.

 

fopen() 및 fread() 같은 studio 라이브러리 루틴이 open() 및 read() 함수를 사용하는 것처럼, 상당 부분 같은 이유로 쓰레드 인터페이스도 LWP 인터페이스를 사용하고 있다.
LWP(Lightweight Process)는 사용자 레벨과 커널 레벨을 잇는 가교 역할을 한다. 각 프로세스는 1개 이상의 LWP와 바인딩을 포함하고 있으며, 각 LWP는 1개 이상의 사용자 쓰레드를 실행하고 있다(<그림 1> 참조). 쓰레드를 생성하기 위해서는 일부 사용자 컨텍스트의 작성이 이루어져야 하지만, LWP의 생성과는 전혀 관계가 없다.

각 LWP는 커널 풀(pool) 내 커널 자원으로서, 각 쓰레드 단위로 할당(attached) 또는 해제(detached) 된다. 이는 쓰레드가 스케줄링 및 소멸될 때 발생하게 된다.

> 스케줄링
POSIX는 FIFO(first-in-first-out)(SCHED_FIFO), 라

운드 로빈(round-robin)(SCHED_RR) 및 맞춤형(SCHED_OTHER) 등 3가지 스케줄링 정책에 대해 구체적으로 명시하고 있다. SCHED_FIFO는 각 우선순위 레벨에 따라 서로 다른 대기 행렬을 가진 대기 행렬 기반의 스케줄러이다. SCHED_RR은 각 쓰레드가 할당된 실행 시간을 가지고 있다는 점을 제외하고는 FIFO와 유사하다.
SCHED_FIFO 및 SCHED_RR 모두 POSIX Realtime 익스텐션이다. SCHED_OTHER는 기본값으로 설정된 스케줄링 정책이다.
언바운드 쓰레드를 위한 프로세스 범위와 바운드 쓰레드를 위한 시스템 범위 등 2가지 스케줄링 범위가 지원된다. 서로 다른 범위 상태를 지닌 여러 쓰레드들이 동일한 시스템 상은 물론, 심지어 동일한 프로세스 상에 공존할 수 있다. 일반적으로 범위는 쓰레드 스케줄링 정책이 유효한 범위를 설정하게 된다.

 

> 프로세스 범위(언바운드 쓰레드)
언바운드 쓰레드는 PTHREAD_SCOPE_PROCESS으로 생성된다. 이들 쓰레드는 LWP 풀의 가용 LWP로부터의 연결 및 해제되도록 사용자 공간 내에서 스케줄링된다. LWP는 프로세스의 쓰레드에서만 이용할 수 있다. 즉, 쓰레드는 이들 LWP 상에서 스케줄링되는 것이다.
대부분의 경우, 쓰레드는 PTHREAD_SCOPE_PROCESS가 된다. 따라서, 쓰레드는 LWP 간을 이동할 수 있으며, 이를 통해 쓰레드 성능이 개선된다(이는 THR_UNBOUND 상태에서 Solaris 쓰레드를 생성하는 것과 동일하다). 쓰레드 라이브러리는 다른 쓰레드 중 해당 커널을 통해 지원받게 되는 쓰레드를 결정하게 된다.

> 시스템 범위(바운드 쓰레드)
바운드 쓰레드는 PTHREAD_SCOPE_SYSTEM으로 생성된다. 바운드 쓰레드는 LWP에 영구적으로 연결된다. 각 바운드 쓰레드는 쓰레드의 수명이 다할 때까지 LWP에 연결된다. 이는 THR_BOUND 상태에서 Solaris 쓰레드를 생성하는 것과 마찬가지이다. 대체 시그널 스택을 제공하기 위해, 또는 Realtime 스케줄링과 함께 특수 스케줄링 속성을 사용하기 위해 쓰레드를 연결할 수 있다. 모든 스케줄링은 운영 환경에 의해 수행된다.

 

> 취소 (cancellation)
쓰레드 취소 기능을 통해 쓰레드는 해당 프로세스에서 여타 다른 쓰레드의 실행을 종료시킬 수 있다. 타깃 쓰레드(취소 대상)는 취소 요청을 보류시키고, 취소 통보 시 실행되는 애플리케이션별 삭제(cleanup) 작업을 수행하게 된다.
pthread 취소 기능은 비동기식 또는 유예식(deferred) 쓰레드 종료가 지원된다. 비동기식 취소는 언제든지 실행될 수 있지만, 유예식 취소는 지정된 시점에서만 실행된다. 유예식 취소가 기본 타입으로 설정된다.

 

> 동기화
동기화는 동시적으로 실행되는 쓰레드를 위해 공유 데이터에 대한 프로그램 플로우 및 액세스를 제어할 수 있도록 지원한다.
상호 배제 락(mutex lock), 읽기 · 쓰기 락(read · write lock), 조건 변수(condition variables), 세마포어(semaphore) 등 4가지 동기화 모델이 제공된다.

 

상호 배제 락(mutex)은 한번에 1개의 쓰레드만 특정 코드 섹션을 실행하거나 특정 데이터에 액세스하도록 허용한다.

읽기 · 쓰기 락은 보호되는 공유 자원에 대해 동시 읽기 및 배타적 쓰기를 허용한다. 자원을 변경하기 위해, 쓰레드는 먼저 배타적 쓰기 락을 확보해야 한다. 배타적 쓰기 락은 모든 읽기 락이 해제되기 전까지는 허용되지 않는다.

 

조건 변수는 특정 조건이 true가 될 때까지 쓰레드를 차단한다.

카운팅 세마포어는 일반적으로 자원에 대한 액세스를 조정한다. 카운트는 세마포어에 액세스할 수 있는 쓰레드 수에 대한 제한 값이다. 카운트에 도달하면 세마포어는 차단된다

애플리케이션 개발자들에게 있어, Solaris 64비트와 32비트 운영 환경 간의 가장 큰 차이점은 사용되는 C-언어 데이터 타입 모델이다. 64비트 데이터 타입은 long 및 포인터가 64비트폭인 LP64 모델을 사용한다. 기타 모든 기본 데이터 타입은 32비트 구현을 그대로 유지하고 있다. 32비트 데이터 타입은 int, long 및 포인터가32비트인 ILP32 모델을 사용한다.

 
다음은 64비트 환경의 주요 특징과 사용 시 고려사항에 대해 간략하게 설명한 것이다.
 
대형 가상 어드레스 공간
 

64비트 환경의 경우, 프로세스는 최고 64비트의 가상 어드레스 공간 또는 18exabyte를 가질 수 있다. 이는 현재 32비트 프로세스의 최대값인 4GB의 40억 배에 해당한다. 그러나, 일부 플랫폼들은 하드웨어 제한으로 인해 풀 64비트 어드레스 공간을 지원하지 못할 수도 있다. 대형 어드레스 공간으로 기본 설정된 스택 크기(32비트의 경우 1MB, 64비트의 경우 2MB)에서 생성할 수 있는 쓰레드 수도 증가하게 된다. 기본 설정된 스택 크기에서 쓰레드 수는 32비트 시스템의 경우 약 2,000개, 64비트 시스템의 경우 약 8조 개에 달한다.

 
커널 메모리 리더
 

커널은 내부적으로 64비트 데이터 구조를 사용하는 LP64 객체이기 때문에 libkvm, /dev/mem 또는 /dev/kmem을 사용하는 기존 32비트 애플리케이션은 제대로 작동할 수 없으며 64비트 프로그램으로 전환해야 한다.

 
/proc 제약 조건
 

/proc을 사용하는 32비트 프로그램은 32비트 프로세스를 볼 수 있지만 64비트 프로세스를 이해할 수는 없다. 따라서, 프로세스를 설명한 기존 인터페이스 및 데이터 구조는 관련 64비트 프로세스를 포함할 수 있는 충분한 크기를 가지고 있지 않다. 이러한 프로그램들은 32비트 및 64비트 프로세스 모두에서 작동할 수 있도록 64비트 프로그램으로 재컴파일 되어야 한다.

 
64비트 라이브러리
 

32비트 애플리케이션은 32비트 라이브러리와 연결되어야 하며, 64비트 애플리케이션은 64비트 라이브러리와 연결되어야 한다. 노후된 라이브러리를 제외한 모든 시스템 라이브러리는 32비트 및 64비트 버전으로 제공된다. 그러나 그 어떤 64비트 라이브러리도 정적인 형태로 제공되지는 않는다.

 
64비트 계산
 

64비트 계산 방식은 과거의 32비트 Solaris 버전에서도 오랫동안 사용되어 왔지만, 64비트 구현은 정수 연산 및 파라미터 전달(parameter passing)을 위해 완전 64비트 머신 레지스터를 제공한다.

 
대용량 파일(Large File)
 

애플리케이션이 대용량 파일 지원 만을 요구하는 경우, 32비트를 그대로 유지하면서 Large File 인터페이스를 사용할 수도 있다. 그러나, 64비트 기능을 완전히 활용하기 위해서는 애플리케이션을 64비트로 변환하는 것이 효과적이다

사용자 삽입 이미지

WAS 도입으로 얻게 되는 효과
그럼 기업들은 WAS를 왜 도입해야 하는 것일까. WAS를 굳이 도입하지 않고도 e-비지니스를 위한 시스템은 얼마든지 구축할 수 있다. 사용자가 적은 사업 초기에는 아무런 문제가 일어나지 않지만 사업이 활성화됨 따라 사용자가 늘어가면서 문제는 발생하게 된다. 기하급수적으로 시스템 성능은 저하되고, 점차로 사용자의 불만이 가중돼 시스템의 확장을 검토한다. 하드웨어 서버의 수, CPU 수를 증가시켜보지만 상황은 점점 더 악화될 뿐이다. 급기야 하드웨어 서버의 다운이 빈번해지고 서비스의 질적 하락과 함께 시스템 도입을 후회하게 된다.

결국 개발업체, 하드웨어 서버 업체 간에는 점차로 험악한 분위기가 조성되며 서로를 불신하는 상황이 전개된다. 아마도 웹 시스템을 도입한 회사라면 정도는 다르겠지만 이와 같은 상황을 어느 정도 경험했을 것이다.
이런 현상이 발생한 기업은 여지없이 WAS 없이 웹 시스템을 구축한 경우가 대부분이고 원인은 다음과 같다.

·사용자 수의 증가에 대한 과도한 메모리의 요구
·로드밸런싱(Load Balancing)이 되지 않음
·웹 서버와 DB 서버 간의 2계층 구조 채택
·페일오버(Failover)가 안되고 있음
·보안 문제에 대한 대비가 없음



WAS(Web Application Server)서버의 의미(간략하게..^^)
2006/10/26 오후 2:01 | 보안&네트워크

WAS 라는 것은 J2EE 쪽에서 나온 용어인데요..

사실 Windows 2000 Server 도 WAS 역할을 합니다.

WAS 가 갖추고 있어야할 기능으로 대표적인 것으로

분산 트랜잭션 기능, 보안기능, 메시징 기능들이 있는데요.
엔터프라이즈급의 대용량 트랜잭션 업무에 적용합니다..

J2EE 에서 EJB 스펙에서 맞게 컴포넌트를 만들었을 경우

이 컴포넌트들을 상호 연동해서 위의 기능들을 덧붙여주는 거죠

개발자가 위의 기능들을 각자 코딩을 한다면, 품질도 보장 안되고
생산성도 낮아지겠지요..

요즘은 WAS 에 웹 서버기능까지 포함되어있기도 하죠..

.NET 쪽에서는 COM+라는 것이 있어서 위의 기능을 하구요..
IIS 가 웹서버 역할을 합니다.

J2EE 의 WAS 는 IBM 의 WebSphere 와 BEA WebLogic
국산으로는 jeus 가 있습니다..

각 벤더마다 EJB 스펙을 기준으로 위 기능들을 처리하도록
구현해놓은 것이 WAS 지요..
(출처 : '웹어플리케이션서버 WAS 가 정확히 어떤일을 하나요?' - 네이버 지식iN)


was는 J2EE 스펙을 구현한 서버입니다.

그중에서 특히 주목해야할 건 jsp/servlet Container와 EJB Container로서의 기능입니다.

이중에서도 EJB Container로서의 역할에 비중이 크죠.



가장 많이 쓰이는 WAS는 BEA사의 Web Logic이며, 그밖에도 여러가지의 WAS가 있습니다. 참고로 tomcat 은 jsp/servlet Container의 기능은 구현했으나 EJB Container로서의 기능은 없습니다. 그래서 tomcat은 WAS가 아니라고 하는 분들도 있습니다.



application이라 함은 응용프로그램입니다.



응용프로그램이란 어떤 목적을 위해 만들어진 프로그램입니다.

word는 문서작성을 위한 목적을 가지고 만들어진 프로그램이며,

포토샵은 이미지 편집/작성을 목적으로 만들어진 프로그램입니다.



web application이란 web에서 어떤 목적을 처리할 목적으로 만들어진 프로그램을 총칭하는 말입니다. 대표적인 웹 어플리케이션으로는 게시판, 쇼핑몰 등이 있겠네요. 아 지금 이곳 지식iN도 웹 어플리케이션입니다. word와 포토샵을 웹으로 구현하면 그것도 웹 어플리케이션입니다만 일반 어플리케이션을 그 상태 그대로 웹에서 실행시킬 수는 없습니다.

미들웨어도 하나의 응용 프로그램이라고 볼 수 있습니다.

주요 기능으로는 각 응용 프로그램간의 연계이죠.

미들웨어로서의 WAS는 Web Server와 DB Server 사이에 존재하면서 웹 어플리케이션을 탑재하고 있습니다. 이 웹 어플리케이션의 주요 기능은 DB의 데이터를 사용자의 목적에 맞게 가공하여 web server를 통해 보여주는 것이죠.

그럼 왜 WAS를 사용하느냐?

한마디로 분산환경에서 사용합니다.

분산환경에서의 가장 큰 이슈는 트랜잭션 처리인데, 이 트랜잭션 처리를 아주 적은 비용으로 효과적으로 처리할 수 있게 해주는 것이 WAS입니다.

(출처 : 'WAS(web application server) 가 어떻게 쓰이나요?' - 네이버 지식iN)

J2EE 를 구성하는 개별 스펙들은 주로 서비스 API 와 세만틱을 정의한 것이고 어떤식으로 구현할 것인지는 내용이 없습니다. 또한 스펙에 없거나 부족하지만 개발 및 운영시에 반드시 필요한 부분(클러스터링이나 매니지먼트 등)은 각 벤더들이 알아서 만들고 있구요.. 각 벤더별로 특정 부분에 무게를 주어 스펙에 앞서는 기능을 먼저 선보이기도(주로 웹서비스/ESB쪽) 하고 개발자의 요청에 따라 특별한 기능들을 갖고 있기도 합니다. 이런 부분들이 WAS 선정에 있어서 중요한 부분이 되기도 합니다.

웹로직은 미국의 거대 기업인 BEA 가 만든 것으로 역사도 길고 제품 완성도도 JEUS 보다 낫습니다. 가격이 엄청 비쌌지만 요즘은 거의 덤핑가로 들어가더군요 (JEUS 효과라 할 수도 있겠습니다). 기술지원의 속도나 수준이 낮은 것이 국내 상황에서의 최대 단점입니다.

JEUS 는 국내 기업인 Tmax 에서 만든 것으로 제품 완성도나 지명도에서 떨어집니다. 하지만 명성/악명 높은 강력한 기술지원력으로 국내 시장에서는 시장 점유율 1위로 올라선지 꽤 됐습니다. 가격은 요즘 BEA가 하도 후려쳐서 좀 더 비싸거나 비슷하거나 할겁니다.

1. WAS란?


 Web application server의 약자입니다.


알기 쉽게 비유로 설명을 드리겠습니다.

우리가 PC에서 어떤 프로그램이든 실행시킬려면 먼저 Windows가 설치 되어 있어야합니다. PC에 Windows가 설치 되어 있지 않다면, 인터넷은 물론 여러가지 Game이나 HWP 등의 Software를 사용할 수가 없습니다.

여기서 Windows와 같은 것을 O/S (Operating System; 운영체제)라고 합니다.

이와 유사하게 Web에서 사용되어지는 JSP나 Servlet 등이 실행되기 위해서도 WAS 라는 것이 필요하게 됩니다.

O/S라는 것이 PC에서 사용할 수 있는 여러가지 프로그램을 실행할 수 있는 기초적인 환경을 제공하여 주는 것인 것 과 같이 WAS는 웹 프로그램(혹은 웹 시스템, 웹 싸이트, 웹 서비스 등)을 실행할 수 있는 기초적인 환경을 제공하여 주는 것입니다.


2. WAS Software


O/S에도 Windows XP 한 가지만 존재하는 것이 아니고, Linux나 Mac O/S 등 여러가지가 있는 것 처럼 WAS도 여러가지 제품이 존재합니다.


그 중 가장 많이 사용하는 상용 제품으로 WebLogic, WebShpere, 제우스 등을 들 수 있습니다. 무료 제품으로 JBoss 같은 것도 존재하며, 그 외에도 많은 WAS 제품이 존재합니다.

출처 : http://aqua707.cafe24.com/blog/index.php

<file descriptor에 대한 것>

(1) 언제 file descriptor를 변경해야 되는지?
      - 소켓을 사용하는 multi-threaded 프로그램 환경에서 서비스 요청이 동시에
        많이 발생하면, 서비스를 처리하는 accept() 함수가 에러를
        뿌려 주게 되지요. 아래처럼 말이죠.

        "errno=24, Too many open files"
       
          이런 경우 동시에 open() 할 수 있는 파일 갯수의 제한 때문에 변경을
          해 줄 필요가 있지요.

      - system resource를 제한할 수 있는 경우는 아래와 같습니다.
        (per-user 또는 per-process 를 기준으로 )

        1> 한 프로세스에 의해 만들어질 수 있는 core file size
        2> 한 프로세스의 Heap (process data segment)
        3> 한 프로세스에 의해 만들어질 수 있는 file size
        4> 한 프로세스가 생성할 수 있는 file descriptors
        5> 한 프로세스의 process stack segments
        6> 한 프로세스가 초당 사용할 수 있는 cpu time
        7> 한 프로세스의 Virtual memory (mapped address space)
        ** #man getrlimit 해 보면 resource definition 정보를 보실 수 있습니다.

(2) file descriptor에 대한 의미
    - 위의 7가지 경우중에서 4>번 file descriptors만이 kernel tunable 변수로서
      조정이 가능합니다. 즉 /etc/system 파일을 사용하는 경우입니다.

    - os별로 limit 값을 보면, 아래와 같습니다.
        ---------------------------------------------------------------------------------
        os ver  default(soft limit)  default(hard limit)    max(stdio)    max(select())
        ---------------------------------------------------------------------------------
        5.4~5.6          64        1024          256        1024
        5.7(32bit)      64        1024          256        65535
        5.7(64bit)      64        1024          256        65535
        5.8(32bit)      256        1024          256        65535
        5.8(64bit)      256        1024          256        65535
        5.9(32bit)      256      65535          256        65535
        5.9(64bit)      256        65535          256        65535
        ---------------------------------------------------------------------------------
        ** 위에서 32bit 인 경우 max(select())의 경우는 source code에
              아래의 line을 추가한 뒤에 recompile이 필요합니다.
              >  #define FD_SETSIZE 65535
                  #include <sys/select.h>
                  (설명)
                        - FD_SETSIZE : library file descriptor limit 입니다.
                        - library limit값이 조정이 된 후에는 system의 file descriptors
                            의 조정이 필요합니다. 이 값을 /etc/system에 아래처럼
                            추가하는 겁니다. 당연히 reboot 필요합니다.
                            set rlim_fd_cur=1024
                            set rlim_fd_max=65535

        - Berkeley stdio.h를 이용하는 경우(fopen/fclose/fread/fwrite) per-process
          당 open할 수 있는 maximum fd 갯수는 256 입니다.

          DB서버 나 웹서버가 아닌 대부분의 application에서는 256 보다 크게 변경할
          필요가 전혀 없습니다.  때때로 이 값이 1024보다 크게 설정했을 경우, select.h
          함수에 선언되어 있는 fd_set 같은 structure 경우는 maximum fd를 1023으로
          간주하기 때문에 이 범위를 벗어나는 경우 memory space의 문제가 야기 됩니다.
          위의 fd_set structure는 select() 함수에 의해서 사용이 됩니다.

          solaris 7,8 등의 경우 현재 돌고 있는 프로세스에 대한 hard/soft  limit 값을
          변경할 수 있습니다. 아래처럼 말입니다.

          #plimit <pid> (현재 설정된 값을 확인할 수 있습니다)
          #plimit -n <soft>,<hard> <pid> (단, soft limit은 hard limit값을 초과하면 안됨)

(3) file descriptor 변경하는 3가지 방법
    1) ulimit 을 이용하는 방법
      - 이 방법은 현재 쉘에서 soft limit 값만을 변경해 줍니다.
          > default 값 : 64 (SunOS 5.8 미만 버젼)
          > 변경 범위: hard limit 값 < 변경할 값 < default 값(soft limit값)
      - #ulimit -n <변경할 값>
         
    2) setrlimit 함수를 사용하는 방법
        - 이 방법은 hard and soft limit 모두 변경을 합니다.
          단, hard limit 변경을 위해서 root 권한이 필요합니다.
       
    3) /etc/system 파일에 넣어 주는 방법
        - 이 방법은 hard and soft limit 모두 변경을 합니다.
        - set rlim_fd_cur=4096
          set rlim_fd_max=4096
          이런식으로 설정하는 방법입니다.
          (의미)
                > rlim_fd_max : 한 프로세스가 open할 수 있는 파일의 갯수
                                        Hard Limit 임.
                > rlim_fd_cur : 모든 쉘에서 사용하는 기본값

+ Recent posts

티스토리툴바