업종과 규모를 막론하고 모든 기업들이 가진 경영 목표는 수익의 창출과 지속적인 성장이라고 말 할 수 있을 것이다.
인류가 처음 기업을 만들고 경영을 시작한 시점부터 오늘날에 이르기까지 이 목표는 변하지 않았으며 앞으로도 또한 그럴 것이다.
그러나 기업이 겪는 환경은 시대에 따라, 기술 발전에 따라 또 고객의 요구에 따라 다양하고 복잡하게 변해왔으며 오늘날에는 그 변화의 속도와 내용이 매우 빠르고 복잡해지고 있으며 불확실성 또한 증가하고 있다.
한편, 인터넷이 보편화 되고 확산됨에 따라 고객들은 예전보다 양질의 정보를 더 많이 그리고 손쉽게 얻을 수 있게 되었고 보다 우수한 품질의 상품과 서비스에 대한 요구가 증가함에 따라 기업들은 새로운 시장기회에 진입할 수 있게 되었다. 반면에 새로운 시장기회에 대한 경쟁은 그 어느 때보다도 더욱 치열해지고 있다.
급변하고 복잡하게 변화하는 오늘날의 기업환경 속에서 기업의 경영목표를 달성하기 위해서는 새로운 성공전략의 수립과 고객의 요구에 부합하는 신상품과 서비스를 개발하여 시장기회를 신속하게 선점하여야만 한다.
기업이 이러한 시장경쟁력을 확보하기 위해서는 기업 활동을 뒷받침하는 IT환경이 비즈니스의 변화와 요구에 민첩하게 대응할 수 있는 역량을 갖추어야 한다.
IT의 과제
40여년전 최초의 메인프레임이 시장에 출시되었을 때는 고객과 기업간의 거래는 배치(Batch) 작업에 의해 일괄 처리되었으나 CICS, IMS와 같은 온라인처리 시스템이 등장하면서 실시간 처리가 가능하게 되었고 데이터베이스 관리 시스템은 기업이 보유한 막대한 양의 데이터를 처리, 저장 및 관리하게 되었다.
CICS와 IMS는 1960년대에 발표된 이후 진화와 발전을 거듭하면서 기업의 핵심 비즈니스 프로세스를 담당하는 애플리케이션 처리 환경의 근간을 이루고 있다. 클라이언트 서버 애플리케이션, e-비즈니스 애플리케이션 뿐만 아니라 CICS, IMS 애플리케이션도 새로운 기술이 등장하면서 레거시 애플리케이션으로 불리우게 되었지만 CICS, IMS 애플리케이션은 메인프레임에 최적화 되어있으며 메인프레임의 능력을 충분히 활용함으로써 효율적이고 안정적으로 가동되고 있다.
그렇기 때문에 오늘날 전세계 기업 데이터의 70%가 코볼로 짜여진 메인프레임 애플리케이션에 의해 처리되고 있으며 하루에 처리되는 웹 페이지의 숫자보다도 많은 300억개의 코볼 트랜잭션들이 매일 매일 처리되고 있다.
메인프레임 레거시 애플리케이션은 기업 고유의 비즈니스 로직에 의해 기업의 중요 데이터를 처리하고 있고 여러 분야에서 차별화된 경쟁력과 비즈니스 노하우를 담고 있다.
한마디로 말해, 메인프레임의 레거시 애플리케이션은 오랜 시간이 흘렀음에도 불구하고 오늘날의 기업들이 필요로 하는 많은 경쟁력을 여전히 가지고 있다.
한편, IT 조직에서는 직접적인 수익의 창출 보다는 비용의 지출이 더 많기 때문에 레거시 애플리케이션을 유지 관리해야 하는 IT조직으로서 비용절감은 많은 부담으로 작용하고 있으며 더욱이 최근에는 비즈니스가 요구하는 변화와 방향에 기민하게 대응해야 하는 도전에도 직면하고 있다.
비용절감과 비즈니스 목표 달성이라는 두 가지 과제는 기업의 IT 환경에 늘 존재해 왔으나 최근에는 이러한 요구가 보다 심화되고 있다.
이러한 과제를 해결하기 위해 ERP 또는 SCM과 같은 애플리케이션 패키지로의 교체, 애플리케이션 콘솔리데이션 및 전환, EAI 등 다양한 방법과 솔루션들이 시도되었으나 아래와 같은 이유에 때문에 기업이 원하는 바를 얻을 수가 없었으며 오히려 비즈니스 요구를 달성하지 못하면서도 비용이 증가하는 결과를 가져올 수 밖에 없었다.
기존 레거시 애플리케이션의 현실
쪾복잡/이질적
▶ 상이한 프로그래밍 언어
▶ 상이한 오퍼레이팅 시스템 또는 하드웨어 플랫폼
▶ 상이한 소프트웨어 벤더, 자체 개발 코드
쪾유연성
▶ 비즈니스 변화와 성장을 신속하게 지원하지 못함.
▶ 고객 중심이 아닌 비즈니스 기능 중심의 시스템
▶ 대체/첨단화하기가 어려움
쪾임시방편적
▶ 높은 유지 보수 비용과 불안정한 인프라스트럭처가 불가피
▶ 수많은 기술들로 인해 복잡도 증가
▶ 후속 시스템에 적용이 불가능할 정도로 어려운 작업
쪾기업내부에서만 적용이 가능했던 EAI 솔루션
▶ 상이한 기술에 의해 구현된 외부와의 Integration에는 적용 불가능
IT의 방향 - SOA
(Service Oriented Architecture)
비즈니스가 요구하는 바를 충실히 지원하기 위한 IT환경의 솔루션은 인티그레이션(Integration)이며, 인티그레이션은 기업내부 뿐만 아니라 외부의 프로세스와도 상호작용할 수 있도록 개방형 표준을 지원하여야 하며 이를 바탕으로 비즈니스의 유연성과 민첩성을 구비하여야 한다.
또한 유, 무형의 기존 투자 자산을 충분히 활용하고 단순화함으로써 적은 비용으로도 구현이 가능하여야 한다. 즉, 기존 투자 자산과 기존의 개발 기술을 활용한 IT 인티그레이션은 적은 비용으로도 구축이 가능하며 아래와 같은 장점을 갖게 된다.
쪾유연성 (Flexibility)
▶ 비즈니스 요구의 변화에 따라 신속하게 대응하여 비즈니스를 지원
쪾상호작용 (Interoperability)
▶ 서로 다른 프로그래밍 언어, 하드웨어, 오퍼레이팅 시스템 등
▶ 이질적 환경에서 작동하는 애플리케이션들과도 문제없이 상호 작용.
쪾단순 (Simplicity)
▶ 적은 비용과 단순화된 인프라스트럭처
쪾민첩성 (Agility)
▶ 비즈니스 구조 변화를 신속하고 기민하게 수용
이러한 IT 인티그레이션을 가능케 하는 것이 곧 SOA 이다.
SOA를 구현하기 위한 기술 중 현재 가장 보편화되고 발전된 기술은 웹 서비스(Web Services)이다. 웹 서비스는 XML(eXtensible Markup Language)을 기반으로 하는 공개 표준들을 이용하여 인터넷 기반의 컴퓨팅 환경에서 재사용이 가능한 소프트웨어 컴포넌트를 말한다.
웹 서비스는 개방형 표준 기술을 채택하여 플랫폼과 벤더 중립적이므로 이질적/이기종 환경에서도 비즈니스 프로세스의 인티그레이션이 가능하다.
SOA를 위한 플랫폼
웹 서비스를 지원하기만 한다면 어떤 플랫폼, 어떤 애플리케이션도 SOA에 적용할 수가 있다. SOA에서의 애플리케이션은, 다른 플랫폼에서 완전히 새로 재구축하는 것도 가능하며 기존 플랫폼의 애플리케이션을 재사용하는 것도 가능하다. 그러나 재구축하는 경우에는 재사용하는 경우에 비해 다음과 같은 문제점을 가지고 있다.
쪾재구축하는 경우에는 재사용하는 경우에 비해 5배 이상의 비용이 소요된다.
쪾기존 코드의 40%~60%는 재사용이 가능함에도 불구하고 모두 폐기하여야 한다.
쪾기존 IT 기술자들을 재교육 시켜야 하며 현재의 기술 수준에 도달하기 까지는 많은 시간이 소요된다.
쪾기존 애플리케이션에 숙련된 기술자들의 기술과 기존 애플리케이션에 담겨 있는 비즈니스 프로세스에 대한 노하우가 모두 폐기된다.
쪾새로운 프로그래밍 언어에 숙달되기까지는 오랜 시간이 필요하기 때문에 애플리케이션의 최적화에 많은 시간이 소요된다.
쪾최적화에 많은 시간이 소요되므로 애플리케이션의 안정성이 떨어지고 이로 인해 비즈니스가 위험에 노출된다.
쪾재구축이 완료될 때까지 많은 시간이 소요되므로 비즈니스 요구에 민첩한 대응이 어렵고 이로 인해 비즈니스의 유연성과 경쟁력이 떨어진다.
결국 급변하는 비즈니스 환경과 비용 절감에 오히려 역행하는 결과를 초래할 수 밖에 없다.
반면, 기존 애플리케이션을 재사용하는 경우에는 기존 플랫폼에 최적화된 애플리케이션을 이용하므로 위와 같은 문제점들을 피할 수 있다.
요약
IBM 메인프레임 레거시 애플리케이션을 핵심 비즈니스 프로세스를 위해 사용하고 있는 많은 기업들이 차세대 시스템의 구축을 계획하거나 또는 진행하고 있다.
차세대 시스템은 SOA를 채택하여 웹 서비스 기술을 적용하는 것이 바람직할 것이다.
IBM 메인프레임 하드웨어, 오퍼레이팅 시스템, 미들웨어, 프로그래밍 언어는 모두 웹 서비스를 지원하기 때문에 기존 레거시 애플리케이션을 웹 서비스로 Modernization이 가능하다.
이로써 SOA 구조의 차세대 시스템으로의 전환은 안정적이면서 단기간 내에 완료할 수 있으며 구축비용을 절감할 수 있다. 기존 레거시 애플리케이션들은 웹 인에이블먼트(Web Enablement) 툴을 이용함으로써 손쉽게, 단기간에, 안정적으로 Modernization 할 수 있다.
기존 애플리케이션에 없거나 새롭게 추가되어야 하는 애플리케이션들은 자바 코드로 작성하면 자바 전용 프로세서인 zAAP을 사용할 수 있기 때문에 소프트웨어 유지보수 비용도 획기적으로 절감할 수 있다. 향후 점진적으로 레거시 애플리케이션을 자바 기반의 애플리케이션으로 전환함으로써 운영비용은 더욱 절감될 것이다.
레거시 애플리케이션의 Modernization을 통해 적은 비용으로도 비즈니스 환경의 요구에 유연하고 민첩하게 대응할 수 있는 역량을 갖추게 된다.
zAAP 기능과 실제 활용
(zSeries Application Assist Processor)
e-비즈니스 온 디맨드의 시대에 접어들면서 비즈니스에 대한 요구 조건은 그 어느 때보다 빈번하게 변화하고 있다.
기업들은 최신 정보에 정통하면서 지속적인 경쟁력을 유지하기 위해 새로운 전략적인 웹 기반 적용업무를 개발하고 있다. 개방형 프로그래밍 모델로서의 자바 도입이 계속 가속화되고 있지만 이런 적용업무는 대개 추상화 단계, 코드 생성, 재사용 문제 등으로 인해 기존 적용업무보다 더 많은 정보기술 자원을 필요로 한다.
그러나 불행히도 이러한 필요에 보조를 맞추어 정보 기술 예산이 늘어나지는 않으므로 고객들은 새로운 자바 기술 기반의 적용업무를 전개하는 데 있어 보다 비용 효율적이고 생산적인 방법을 찾아내야만 한다.
zAAP이란?
IBM e서버 z시리즈 990(z990)과 z시리즈 890(z890) 서버에서 사용할 수 있는 IBM의 새로운 zAAP(zSeries Application Assist Processor)는 강력한 통합 기능과 z시리즈 플랫폼의 전통적인 서비스 품질을 원하는 고객들을 위해 전략적인 z/OS 자바 실행 환경을 매력적인 가격으로 제공하는 특화된 프로세서이다. 이를테면, IBM 미들웨어 제품군인 IBM 웹 스피어 관련 업무들을 전담 처리하는 프로세서인 셈이다.
zAAP을 통해서 IBM이 제공하고자 하는 것은 Java 기반의 적용업무 서버 환경에서 컴퓨팅 비용을 절감할 수 있게 하는 것이다. 즉, zAAP은 기존 IBM z시리즈 서버 플랫폼의 일반 프로세서에 비해 매우 할인된 저렴한 가격으로 판매되며, 소프트웨어 라이선스 사용 요금에 있어서도, IBM 소프트웨어는 어떠한 제품이든지 zAAP의 설치로 인한 소프트웨어 요금의 증가는 없게 된다. 한편 zAAP은 하드웨어 시스템상에서는 IFA(Integrated Facility for Application)라는 명칭으로 사용하게 됩니다.
고객들은 zAAP을 도입함으로써 다음과 같은 도입 효과를 얻을 수 있다.
1. 높은 성능과 신뢰성, 가용성, 보안성을 위해 e-비즈니스 자바 웹 적용업무를 중요 기간계 업무의 데이터베이스와 통합함으로써 서버 인프라를 단순화 할 수 있다.
2. 범용 프로세서의 수요 및 기능 요구를 줄여서 다른 z시리즈 워크로드에 재할당할 수 있게 함으로써 시스템 생산성을 높여 z시리즈의 투자 가치를 극대화한다.
3. 하드웨어, 소프트웨어, 유지보수 비용을 절약해서 웹 스피어 적용업무 서버와 다른 자바 기술 기반 적용업무의 전체적인 컴퓨팅 비용을 낮춘다.
z/OS(또는 z/OS.e)를 실행하는 논리적 파티션 내에서 범용 프로세서와 함께 구성되는 zAAP은 자바 프로그램과 관련한 업무 처리를 전담함으로써 범용 프로세서의 생산성을 높이고 z/OS 자바 기술로 만든 적용업무의 전체적인 컴퓨팅 비용을 절감하는 데 기여한다. zAAP는 범용 프로세서와 비동기적으로 작동해서 IBM 자바 가상 머신(IBM Java Virtual Machine, JVM)의 통제 아래 자바 프로그램을 실행시키도록 설계되었다. 이것은 범용 프로세서의 수요와 기능 요구를 줄여서 다른 z시리즈 워크로드에 재 할당할 수 있게 해준다.
자바로 작성된 적용업무라면 프로그램의 변경 없이 zAAP에서 IBM 자바 가상 머신 프로세싱 사이클을 실행할 수 있다. zAAP에서 자바 가상 머신 프로세싱 사이클을 실행하는 것은 z/OS용 IBM SDK(Software Developer's Kit, Java 2 Technology Edition V1.4, z/OS V1.6(또는 z/OS.e V1.6), PR/SM(Processor Resource/Systems Manager)가 가지고 있는 기능이다.
범용 프로세서를 통해 절감되는 총액은 zAAP에 의해 실행되는 자바 적용업무 코드의 양에 따라 달라진다. 이것은 관련 적용업무가 사용하는 자바 사이클의 양과 고객이 어떤 zAAP 실행 모드를 선택하는지에 달려 있다.
관련 데이터베이스 하부시스템으로 사용된 동일한 z/OS SMP LPAR 내에서 zAAP를 이용해 자바 적용업무를 실행하면 서버 인프라를 단순화하고 운영의 효율성을 높일 수 있다. 일례로, zAAP를 사용하면 별개의 물리적 서버 플랫폼에 적용업무 서버와 데이터베이스 서버를 전개할 때 필요한 TCP/IP 프로그래밍 스택, 방화벽, 물리적인 상호 접속 그리고 관련된 프로세싱 대기 시간 등의 숫자를 줄일 수 있다.
개념상 zAAP는 z시리즈 서버의 데이터 입출력처리를 담당하는 프로세서인 System Assist Processor(SAP)와 매우 유사하다. 즉 zAAP을 이용하여 시스템의 Initial Program Load를 실행할 수 없고, IBM 자바 가상 머신의 통제 하에서 자바 프로그래밍을 실행하기 위한 목적으로만 사용된다. 그래서 범용 프로세서, ICF, IFL과 달리 zAAP는 범용 프로세서와 함께 구성되어야 하며 단독적으로는 아무 것도 할 수가 없다.
이 때문에 IBM은 zAAP 기능에 대해서는 소프트웨어 대금을 청구하지 않는다. 부가적인 IBM 소프트웨어 대금은 다목적 범용 프로세서 기능이 추가로 사용될 때에만 적용된다.
zAAP 아키텍처 작업 처리 절차
zAAP이 이용되는 내부 아키텍처 구조를 살펴보면, 기본적으로IBM 자바 가상 머신과 z/OS 수퍼바이저에 의해 zAAP이 이용되는 구조이다.
좀더 세부적으로 살펴보면, 자바 프로그램 실행 요건이 발생하면 자바 가상 기기는 z/OS의 디스패처에게 해당 자바 프로그램의 실행을 요청한다. 이후, z/OS 디스패처는 zAAP 프로세서의 가용 여부를 판단하여 당시 시스템 상에 가용한 zAAP에게 해당 자바 프로그램을 실행하도록 해준다.
만약, zAAP이 사용되고 있는 상태이고 범용 프로세서는 여유가 있는 상태인 경우에는 해당 자바 프로그램을 범용 프로세서에서 실행할 수 도 있다. 이런 경우, 자바 프로그램을 범용 프로세서로 실행하느냐의 여부는 시스템 매개변수(Parameter)로 미리 설정하여 제어할 수 있다.
zAAP을 통한 정보 기술 인프라 통합 및 단순화
zAAP은 IBM z시리즈 서버를 통한 서버 인프라의 통합화 및 단순화를 가속시켜 전사적 서버 운용의 효율을 높여준다.
즉 zAAP을 사용하게 됨으로써 z시리즈 서버상에서 중요 기간계의 데이터베이스 처리를 행하는 e-비즈니스 적용업무의 통합이 용이하게 된다. 뿐만 아니라 <그림 1>의 예에서 보는 바와 같은 서버 구성의 단순화를 통한 서버 운용 효율화를 극대화 시킬 수 있는 효과를 볼 수 있다.
또한 zAAP은 서버 구성 요소를 절감시켜, 3계층의 서버 계층구조를 2계층으로 단순화할 수 있어 이에 따른 TCP/IP 링크를 줄여 네트웍의 효율화를 동시에 꾀할 수 있다. zAAP은 새로운 기술 혁신 외에도 기존의 z시리즈 서버가 제공하는 장점들을 함께 활용할 수 있다. 즉 z시리즈 서버만의 보안성과 가용성 및 확장성, 서버의 운용효율을 극대화시켜 주는 워크로드 매니저(WLM) 기능을 함께 활용할 수 있는 것이다.
zAAP TCO
<그림 2>의 예를 보면, zAAP의 개념을 쉽게 이해할 수 있다. <그림 2>의 예에서는 IBM 웹 스피어 적용업무의 트랜잭션 처리에 1,000 MIPS가 필요한 경우를 가정한 것이며, 전체의 50%인 500 MIPS에 상당하는 프로세서 처리 성능을 범용 프로세서에서 zAAP으로 변환시킨 것이다.
범용 프로세서로만 구성된 경우의 시스템 사용률이 80%였지만, 범용 프로세서를 일부 zAAP으로 대체시켜 Java관련 워크로드를 전담하게 함으로써, 시스템 전체의 사용률이 40%로 떨어지는 예를 보여주고 있는 것이다.
이로써 고객은 범용 프로세서의 감소로 인한 TCO의 절감효과(주로 ISV 소프트웨어 사용요금과 IBM 소프트웨어 사용 요금)를 누릴 수 있을 뿐만 아니라 여분의 시스템 자원(그림 2에서는 500 MIPS)을 활용하여 또 다른 업무를 추가로 처리할 수 있는 환경을 구축할 수 있다.
기타: zAAP 사용 전제 조건
아울러 zAAP을 사용하기 위해서는 몇 가지 전제조건이 필요하며 그 내용은 주로 아래와 같습니다.
쪾하드웨어 전제 조건
IBM e서버 z시리즈 890 (z890) 및 IBM e서버 z시리즈 990(z990) 서버, zAAP의 개수는 현재 이용되고 있는 범용 프로세서의 수만큼만 설치 가능하다.
(예 : 범용 프로세서가 3개 있는 경우는 zAAP도 최대 3개까지 설치가능하다)
쪾소프트 전제조건
z/OS V1R6이후의 운영체계가 필요하며, JDK V1.4.1 및 APAR PQ86689, PTF UQ88783의 적용이 필요하다. z/OS V1R6은 2004년 9월에 출시가 되어 시장에 판매되고 있다.
Linux on zSeries
메인프레임이라는 명칭으로 더 익숙한, IBM z시리즈는 여러 다른 회사의 하드웨어와 운영체계와 비교하여 제품의 완성도 뿐만 아니라, 기술 자체로도 선도적인 위치에 있다.
과거에도 그러했고, 지금도 지속적으로 z시리즈의 기술이 다른 하드웨어에 적용되고 있다.
이와 같이 z시리즈가 다른 어떤 서버 하드웨어 운영 환경과도 차별화 되는 것이 바로, 가상화 기술력이다.
가상화 기술력에서 차별화 뚜렷
이미 z시리즈는 전신인 S/390 아키텍처 시절에서부터에서, 하드웨어를 효율적으로 사용하기 위하여, 논리 분할(Logical Partition; LPAR) 이라는 개념을 통하여, 하드웨어의 모든 자원을 효율적으로 사용할 수 있는 방법을 제공하였다.
이것은 하나의 서버를 물리적(Physical Partition)으로 나누기만 하는 환경이 아니라, 예를 들어, 하나의 CPU를 여러 개의 운영체계에서 각각 자신에게 할당된 자원을 사용하는 것과 같은 환경을 제공하는 역할을 하였다.
그러한 가상화된 환경을 PR/SM(Processor Resource/System Management)이라고 하는 마이크로 코드하드웨어를 통하여 논리 분할(LPAR-Logical Partition)을 지원하고, z/VM이라는 운영체계를 통하여 다시 소프트웨어적으로 제공한다. 실제로 PR/SM과 z/VM의 운영방식은 개념적으로 동일하다. 다만 전자가 마이크로 코드에 의한 하드웨어적인 구현 방식을 취했다면, 후자는 소프트웨어적인 구현방식으로 가상화 환경을 제공해 주는 차이가 존재할 뿐이다.
가장 최신의 z시리즈 서버의 경우 30개의 LPAR를 지원하고 있다. 이것은 다시 말해, 하나의 z시리즈 서버에 30개의 서로 다른 운영체계를 설치하여 운영할 수 있는 것을 의미한다.
하지만, z/VM을 사용하는 경우, 이런 제한은 없어진다. 다만, z시리즈 자원이 지원할 수 있는 한도 내에서, 무제한 적으로 서로 다른 운영 체제를 설치한 독립 서버 환경을 사용할 수 있다.
또한, 서로 다른 운영체계를 연결하는 네트웍의 구성을 z시리즈 시스템 내부에서 가상으로 구성할 수 있다.
이것은 단순히 추가 네트웍 장비가 필요 없다는 수준의 문제가 아니라, 가상화된 네트웍을 통하여, 메모리 복사 수준의 속도와 함께 하드웨어 장애가 발생할 수 있는 부분이 사라지고, 누군가가 고객의 중요 데이터를 네트워크를 통하여 훔쳐보고 있을지도 모른다는 보안상의 문제점 자체를 제거하게 된다.
리눅스 z시리즈, z/OS 혹은 OS/390 등 필요 없어
이제 본론으로 들어가서, 리눅스에 대하여 살펴 보도록 하자. z시리즈에서의 리눅스가 우리가 일반적으로 인지하고 있는 리눅스와 동일한 것일까? 또한, z시리즈와 같은 대형 서버에서, 리눅스를 사용한다는 것이 어떤 의미가 있을까?
많은 경우, z시리즈에서 리눅스를 운영한다고 생각하면, 기존의 z시리즈에서 사용하는 운영체계인 z/OS에서 사용하던 유닉스 시스템 서비스(Unix System Service; USS)를 생각할 것이다. USS의 경우, Unix95 브랜드 인증을 획득한 유닉스 서비스 환경으로, 일반적으로 우리가 인지하고 있는 각 업체들의 유닉스 운영체계들 처럼, IBM에서 독자적으로 개발한 환경이다.
하지만, 리눅스의 경우 운영체계의 핵심인 커널이 리누스 토발즈(Linus Torvalds)와 그의 공동체에 의해 유지 관리되며, 기타 운영체계를 위한 기본 프로그램들도, GNU 정신에 입각하여 GPL(General Public License) 혹은 유사 라이선스 정책에 의해 공동체에 의해 유지 관리되고 있다.
zSeries에서도 다른 운영체계 - z/OS 혹은 OS/390, z/VM 혹은 VSE 등과 같은 - 와는 별개로 리눅스를 다른 여타 플래폼의 리눅스와 같이 독자적인 하나의 운영체계로 사용할 수 있다.
<그림 1>과 같이 리눅스 운영체계의 핵심인 커널을 유지 관리하는 kernel.org 웹사이트에서 What is Linux? 라는 부분을 살펴보면, z시리즈(S/390) 리눅스는 IBM이 아닌 리누스 토발즈를 중심으로 공동체에 의해서, 공식적으로 개발 유지 지원 되고 있는 것을 알 수 있다.
일부의 잘못된 생각 중 하나가, z시리즈의 리눅스를 USS의 연장선상에서 이해, z/OS 혹은 OS/390과 같은 운영체계가 필요한 것으로 생각하는 경우가 있다.
하지만, 이것은 잘못된 생각으로 리눅스는 그 자체가 하나의 완성된 운영체계로 다른 여타의 기존 z시리즈 운영체계와 상관없이 운영할 수 있다. 물론, z/VM의 가상화 기술과 함께 사용된다면, 효율은 극대화시킬 수 있지만, 독립된 LPAR에 그대로 사용해도 전혀 문제 될 것이 없다.
또, 사람들이 갖고 있는 생각 중 하나가, 일반 PC 서버에서 사용되는 리눅스와 z시리즈의 리눅스가 서로 다른 것일 것이라는 생각을 가지고 있다.
하지만, 위에서 설명한 바와 같이 리눅스 자체에 대해서는 어떤, 하드웨어/소프트웨어 업체도 독점적 권리를 주장 하거나 가질 수 없다. 이것은 공동체에 의하여해, 개발 유지 지원관리 되기 때문이다.
<그림 2>는 최근에 발표된 리눅스 커널인 2.6.10의 전체 소스 구조이다. 2.6.10의 경우 전체 소스 코드의 사이즈가 182MB에 달하는 것을 알 수 있다. 이중에, 하드웨어 구조와 관련된 코드가 31.1MB로 전체의 17%에 이르고, 그 하드웨어 구조와 관련된 코드는 각 하드웨어 별로 리눅스를 지원하기 위한 코드들로 나눌 수 있는데, i386으로 되어 있는 최초 목적으로 개발된 32비트 x86 기반의 하드웨어 환경을 위한 코드가 1.97MB로 전체의 약 1% 가량인 것을 알 수 있다.
또한, 인텔에서 발표한 IA64 아키텍처의 경우도 비슷한 1.91MB로 약 1% 가량인 것을 알 수 있다. 이와 마찬가지로, 이와 비슷하게 z시리즈(S/390) 아키텍처 또한, 0.69MB로 전체 코드의 0.3% 가량인 것을 확인 할 수 있다.
z시리즈, 리눅스 서버로서의 강점
이제 위에서 언급한 것과 같이 z시리즈에서 리눅스를 사용한다는 것이 어떤 의미가 있을지를 생각해 보자. 하나의 z시리즈 서버에 하나의 운영체계를 사용해야 한다면, 과연 얼마나 많은 사용자가 감히 리눅스를 사용할 수 있을까? 하지만, 하나의 z시리즈 서버에 수십 ~ 수백의 리눅스 운영체계를 통하여, 다양한 목적의 업무를 하나의 z시리즈 서버에서 운영할 수 있다면, 그것은 충분히 매력적일 것이다.
여기서 바로, z시리즈의 리눅스 서버로서의 강점이 발휘된다. 하나의 z시리즈 서버에, 수십에서 수백의 서로 다른 목적을 위한 서버를 통합이 가능한 것이다. 특정 서버의 자원이 넘치지만, 다른 자원이 부족한 서버에게 자원을 전달 할 수 없는 일반적인 독립된 서버 환경이 아니라, 하나의 하드웨어 자원을 공유하면, 자원이 필요한 서비스에 더 많은 자원을 할당하는 수십에서 수백의 서버를 통합 할 수 있는 것이다.
또한, 특정 목적 - 특별 캠페인과 같은 - 에 따른 서버가 갑자기 필요하다면, 필요한 순간에 그대로 만들어 낼 수 있는 환경의 구축이 가능하다. 실제로, 전산 부서의 가장 큰 고민 중 하나가 현업 부서의 요청을 받고 나서, 어떻게 하면, 보다 빠르게 대응할 수 있는 가이다.
하지만, 현재의 서버 환경에서는 하나의 서버에 여러 개의 서로 다른 업무를 사용하는 것에 한계가 있다. 그렇다고, 현업의 필요가 언제가 될지 모르는 상황에서 여분의 서버를 구비 해 놓는 것은 더 한계가 있다.
현업의 요청에 의해, 새로운 서버를 주문하고 구축하는데 걸리는 시간이 얼마나 될까? 아무리 빨라도, 일주일에서 한 달은 걸릴 것이다.
물론 회사의 규모와 의사 결정의 이루어지는 단계에 따라 다르지만, 역동적으로 초 단위로 시장이 변하고 있는 현대 사회에서 매우 긴 시간인 것에는 틀림없다.
여기에 리눅스와 z시리즈의 가상화 기술의 결합에서 오는 강점이 있다. 현업이 필요한 순간에 가상 서버를 구축하는 것이다. 그리고, 필요 없는 순간 그대로 가상 서버만을 제거하면 된다.
온 디맨드를 위한 최상의 전산 환경
오늘날에는 수많은 통합 기술들이 있다. 하나의 운영체계 내에서도 여러 가지 서비스를 제공하여 서버의 통합 효과를 제공할 수도 있고, 하나의 서버를 물리적으로 나누어서 여러 대의 서버를 통합하는 효과를 나타낼 수도 있다.
하지만, 오늘날과 같이 급변하는 온 디맨드 시대를 살아가고 있는 상황에서 전산 환경이 온 디맨드에 맞게 변화하기 위해서는 단순하게 통합이 아닌, 고객의 환경에 맞게 동적으로 재구성 가능한 전산 환경으로 거듭나야 한다.
리눅스와 z시리즈의 결합이야 말로 완벽한 온 디맨드를 위한 전산 환경을 제공하는 미래를 준비하는 최상의 전산 환경이다.
z시리즈는 탁월한 기술적 우월성으로 오랜 시간 서버 시장의 기술을 선도해 왔다. 많은 기술들이 다른 서버로 적용되고 있지만 아직도 그 차이는 매우 크다고 할 수 있다. 그 중 가장 큰 차이를 보이는 것들 중 하나가 바로 가상화 기술이다.
리눅스라는 업계 최고의 발전 속도와 수용성을 채택한 운영체계와 최고의 가상화 기술을 보유한 z시리즈의 결합을 통하여 기존 자산의 활용을 최대화 하여 추가 비용 없이 빠르게 새로운 서버 환경을 구축할 수 있다.
이를 통해 시장에 빠르게 진입할 수 있는 기회를 얻을 수 있으며, 사업 환경의 변화에 즉각 대처할 수 있을 것이다.