‘UNIX To Linux’ 사례로 보는 LG CNS U2L 이야기

클라우드 연재 이번 시간에는 기존 UNIX 시스템에서 운영 중인 시스템을 x86 기반 Linux 환경으로 Migration 했던 사례와 효과를 소개해 드리고자 합니다.

UNIX 서버의 발전

먼저 UNIX 시스템의 발전을 살펴볼까요?

U2L은 Unix to Linux의 약자입니다. 1970년대부터 출시된 UNIX는 점진적인 기술발전을 이루어오다, 메인프레임의 컴퓨팅을 대체할 효과적인 컴퓨팅 파워의 등장으로 발전하기 시작했습니다. IBM AIX, HP HP-UX, Oracle Solaris 등 Global IT 기업들의 상용 Unix 시스템에 의해 1990년대까지 대부분의 엔터프라이즈 환경에서 IT 인프라의 핵심 시스템이 되었습니다. 이런 Unix 시스템의 발전은 CS(Client Server), Web 기반의 IT 환경을 이끌면서 비약적인 발전으로 이어지게 됩니다.

아래 그림에서 보듯이 UNIX가 발전하면서 다양한 종류의 UNIX가 출시되었으나, 결국 엔터프라이즈 시장에서 받아들여지는 UNIX는 대규모 자본력과 기술력을 기반으로 IBM, HP, SUN(Oracle) 등 Major 3개사로 압축됩니다.

x86 서버가 발전하기 위한 변화의 시작

x86은 어떻게 해서 발전하게 된 것일까요?

유닉스 시스템 역시, 2000년대 들어서부터 조금씩 변화의 조짐이 보이기 시작했습니다. 90년도부터 기술의 발전이 메인 프레임에서 UNIX로 다운사이징 프로젝트를 통해 대세의 흐름이 UNIX로 이동했듯이, UNIX에서 x86으로 다시 한번 다운사이징 하기 위한 변화가 보이기 시작한 것이죠.

이런 변화의 바람에 대한 원동력은 크게 5가지로 요약할 수 있을 것 같습니다.

첫째, x86 기반 CPU 성능의 비약적인 발전이 있습니다.

Multi-Core: 22Core/CPU 제공(Intel E5-2699v4 기준)
tpmC/core: 150,000tpmC/Core 제공(Intel E5-2637v4 기준, IBM P750 대비 111% 수치)

둘째, 주요 가상화 솔루션 업체를 중심으로 엔터프라이즈 서비스 수용이 가능할 정도로 가상화 기술이 성숙되었습니다.

주요 가상화 솔루션: VMWare vSphere, MS Hyper-V, Redhat RHEV, Citrix XenServer 등

셋째, 고가의 UNIX 서버에 대한 밴더 종속성 탈피에 대한 욕구가 증가했습니다.

Unix to Linux/Windows는 물론이고 Unix to Unix 환경 역시 제조사의 폐쇄적인 정책으로 인해
대형 서버 제조사에 종속적인 IT 환경 유지할 수밖에 없음

넷째, 웹 서비스, 인터넷 기업을 중심으로 자사의 핵심 업무영역에 Scale-Out 기반의 아키텍처 및 오픈 소스(OSS, Open Source Software)가 급격하게 확산했습니다.

기업용 OS 시장에서 Linux 시장점유율 확산

google, facebook, amazon 등 거대 인터넷 기업들 주도로 Apache, Tomcat, MariaDB 등 OSS소프트웨어의 기업 핵심 서비스 영역에 적용 확산
애플리케이션 서비스가 분산 아키텍처 기반 Scale-Out 환경으로 바뀌면서 기존 Scale-Up 기반 Unix 시스템으로는 이러한 변화를 Support하기엔 한계에 도달하게 됨

다섯째, 2000년대 초부터 amazon AWS, MS Azure, Google GCP 등 메가 클라우드 사업자를 중심으로 클라우드 서비스가 전방위적으로 확대되었습니다.

향후 기업에서 직접 도입하는 방식이 아닌 서비스 형태를 필요한 만큼 제공받는 클라우드 서비스가 확대될 것으로 예상
직접 H/W, S/W 등 IT 시스템을 도입해서 구축하기엔 급격한 Business 환경의 변화에 Agile 하게 대응하는 것이 불가능

여섯째. UNIX 시스템의 고비용 TCO 구조는 많은 Challenge를 받게 됩니다.

UNIX 시스템은 매우 고비용 구조여서 초기 도입비용도 많이 들지만, 도입 이후 유지비용도 매우 높은 것이 현실이어서 IT 관리자들이 매년 기업 내 CFO로부터 비용 절감에 대한 Challenge를 받게 됩니다.

여기에 한가지 더한다면 대기업, 금융권, 공공기관 등 대규모 트랜잭션 처리를 담당하는 IT 시스템의 x86 전면도입이 x86 도입을 주저하는 고객들에 대한 x86 확산에 기름을 부은 격이라고 할 수 있을 것입니다.

U2L 이란?

U2L을 간단히 정리한다면, Unix 시스템에서 운영되는 애플리케이션(WEB, WAS, DB 등)을 x86 기반 소프트웨어 Stack으로 Migration 하는 것을 말합니다.

아래 그림을 보면 알듯이 HW-OS-DBMS-WAS-WEB의 SW Stack 구조가 있을 경우, UNIX-AIX-ORACLE-WebLogic-HTTPServer Stack 구조에서 x86서버-CentOS-MariaDB-Tomcat-Apache Stack으로 변경이 되는 것을 말하죠.

얼핏 보면 H/W를 도입해서 신규로 설치하면 되는 매우 간단해 보이는 과정처럼 보이지만, 각각의 특성을 고려해서 아키텍처를 설계하고 각 Layer 별 Migration 전략을 고민하고 충분히 준비해서 실행에 옮겨야 합니다.

Unix 시스템에서 운영 중이던 각종 소프트웨어를 Linux 환경으로 변경하는 것은 정말 큰 결심일 수도 있습니다. 그래서, 각 기업의 환경에 맞게 적절한 U2L 전략을 수립하는 것이 시행착오를 줄이면서 원하는 비용, 효율성 측면의 효과를 극대화하는 방법입니다.

예를 들어, 아래 그림에 있는 기존 SW Stack 환경으로 시스템 운영한다고 가정했을 때 H/W부터 WEB까지 전 영역을 한꺼번에 U2L Stack으로 옮길 수도 있지만, 영역별로 단계별로 Migration 하는 것도 현명한 U2L 방법일 수 있습니다.

기존 고객사의 SW Stack을 U2L S/W Stack으로 Migration 하기 위해서는 크게 3가지 단계로 접근할 수 있습니다. 첫 번째는 H/W와 OS 영역만 변경하는 것이고, 두 번째는 WEB, WAS 영역을 변경하는 것이며, 마지막으로 난이도가 가장 높은 DBMS를 변경하는 것입니다.

첫째, 가장 손쉬운 방법은 상기 그림의 Level1 영역인 H/W, OS 영역만 x86 Server + CentOS(Linux)로 바꾸는 것입니다. 대부분 기업에서 가장 손쉽게 접근할 수 있어서 상대적으로 적은 Effort를 들이고 비교적 큰 비용효과를 얻을 수 있어서 빠르게 추진할 수 있습니다.

U2L Stack을 구성하기 위한 H/W를 도입하거나 클라우드 서비스를 활용하여 VM + OS를 Provisioning 해서 Migration 할 수 있는 환경을 만든 다음, 기존 DBMS, WAS, WEB SW를 설치하는 것입니다. 이때 Target 환경인 Linux OS버전에 기존 SW들이 호환되는지와 최적의 Configuration 등 Best Practice를 고려하여 구성해야 합니다. 이때 필요하다면 기존 SW의 Patch Level을 일부 업그레이드해야 할 수도 있습니다.

둘째는 Level1에 더해 WEB, WAS 영역인 Level2 영역을 추가로 Migration 하는 것입니다. H/W, OS만 변경하는 Level1에 비해 다소 난이도나 Knowledge가 필요하지만, 어느 정도의 Migration Resource를 투입하여 기대하는 효과를 거둘 수 있습니다.

이때, 기존 운영 중인 WAS 환경이 중요한데요. 특히, Java로 개발된 애플리케이션의 경우 Java version에 따라 Migration 공수나 Effort가 천차만별로 소요될 수 있기 때문에 현재 U2L 대상으로 생각하고 있는 시스템의 WAS 환경을 철저히 분석해야 합니다.

철저한 분석을 통해 Migration 전략을 수립해야 효율적인 U2L 전환을 할 수 있습니다. 일반적으로 J2EE 표준(EJB, JSP, Servlet, JDBC 등)을 준수해서 개발된 환경의 경우, WAS 전환 시 상대적으로 Effort가 적들이면서 U2L Stack으로 전환이 가능합니다. 그리고 Java 버전이 너무 낮을 경우, 소스 프로그램의 상당한 수정이나 변경이 필요할 수 있으므로 이 부분도 중요한 변수가 될 수 있습니다.

기타 C, C++ 등 장비에서 호환성을 제공하지 않는 다른 언어로 개발된 경우, 기존 프로그램 소스를 확인해서 U2L SW Stack 환경에서 컴파일을 다시 진행해야 합니다.

마지막으로 Level1, 2, 3 모든 영역을 U2L SW Stack으로 전환하는 것입니다.

Migration이 완료된 상태에서는 TCO 절감 효과를 얻을 수 있으면서, 가장 효율적인 상태로 인프라를 운영할 수 있는 이상적인 환경이라고 말할 수 있습니다. 하지만, 이러한 효과를 얻기까지는 중간에 기존 S/W Stack 전체를 U2L SW Stack으로 Migration 해야 한다는 부담이 있는데요.

특히, 기존 Oracle dependency가 있는 Trigger, PL/SQL, Sequence와 같은 기능들을 주로 사용하고 있다면, MariaDB 또는 MySQL 같은 환경으로 Migration하는데 더 어려움을 겪을 것입니다. 그렇지만 이러한 복잡한 과정을 자동으로 Migration해 주는 다양한 솔루션들이 존재하고 있어, 이를 활용하면 보다 효과적으로 DBMS를 U2L SW Stack 기반 환경으로 이관할 수 있습니다.

이들 솔루션의 주요 기능은 테이블, 데이터, 인덱스, 뷰, 시너님, 시퀀스, PL/SQL Stored Procedure, 패키지, 함수, 트리거 등을 자동으로 Migration 시켜주고 그 후 테이블 수 또는 Row 수 등을 검증할 수 있는 기능도 제공하므로 Migration Effort를 획기적으로 줄여줄 수 있습니다. 물론, 일부 비용이 발생할 수 있지만, 솔루션별로 가성비가 좋은 툴이 있으니 기능, 사례 등을 충분히 검토 후 기업에 적용하면 좋을 것 같습니다.

Migration 솔루션(예)

Ispirer (https://goo.gl/qjiftZ)
Sqlines (https://goo.gl/ZobTsQ)

U2l 고려사항

앞서 봤듯이 고비용 저효율의 기존 S/W Stack에서 소위 말해서 가성비가 높은 저비용 고효율 구조의 U2L S/W Stack으로 Migration을 하면, 기업 IT 환경이 효율화되고 비용이 절감되니 굳이 미룰 이유가 없지만, 프로젝트를 고민하기 전에 몇 가지 고려를 해야 합니다.
.
그럼 기업에서 U2L Migration을 위해 고려해야 할 대표적인 사항을 살펴보겠습니다.

1) 애플리케이션 소스코드 관리 수준

애플리케이션 소스코드 리스트 및 관리 현황
해당 애플리케이션 소스의 수정, 컴파일, 배포 등을 지원할 수 있는 개발자 보유 여부
프로그램 소스에 Hard Coding 여부 확인
외부 연계 시스템 영향도 파악 및 협조(FW Open, API 수정 등)

2) 소프트웨어 호환성

x86 환경에서 기존 소프트웨어 버전 및 호환성 보장여부 검토
(특히 상용SW의 경우 각 제조사의 Certification 확인)
운영중인 Java 버전, Compiler 종류 및 버전 등

3) 소프트웨어 Compliance 이슈

P2V, U2L 인프라 변경에 따른 상용 S/W License 정책 및 기보유 License 재활용 시 Compliance 이슈 고려
클라우드 환경에서의 ISV SW 업체 별 S/W License 정책 검토
(일부 ISV는 클라우드 라이선스가 없거나 고가로 책정하는 경우가 있음)
노후 SW(상용SW 등) 업그레이드 이슈 발생 시 ISV 업체별 지원정책(기술적, 비용적) 검토

4) 기업환경에 맞는 Migration 아키텍처 모델 선정

Re-Hosting: 기존 인프라 이관(P2V, V2V 등)
Re-Platforming: Web/WAS/DB 등 일부 SW 변경하면서 이관
Re-Factoring: 클라우드 환경에 맞는 응용 아키텍처 변경 후 이관

5) 현 환경에 맞는 데이터 Migration 방안 수립

애플리케이션 소스 이관 방안
애플리케이션 최종 데이터 동기화 방안
DB 데이터 Migration 방안

6) U2L Migration 이후 적절한 성능검증 방안 수립

성능검증 대상, 범위, 검증툴, KPI 등

7) U2L 환경에서의 고가용성 구성방안

High Availability, clustering, 이중화, 백업전략 등

8) 기업내 U2L SW Stack을 운영할 수 있는 기술보유 수준

핵심영역은 자체 역량으로 운영하고, 기타 영역은 외부 기술지원 체계 활용하는 방안
자체적인 운영역량 보유 여부(인력, 툴, 기술력 등)
U2L Migration 및 운영을 위한 기술지원 업체 등 외부 Support 체계

9) 기타

기존 투자자산 보호: 최근 투자 자산이 있을 경우 해당 자산을 처리하는 방안 검토
기존 애플리케이션을 운영하고 있는 개발자, 운영자 성향
U2L SW Stack으로 Transform하기 위한 단계별 Approach 전략(교육, 인사, 육성책 등)

LG CNS의 U2L 역량

LG CNS는 2010년대 초부터 Cloud Computing과 함께 U2L, OSS에 대해 관심을 가지고 지속적인 R&D와 고객 제안 및 Migration Project를 진행해서 다양한 경험 및 역량을 보유하고 있습니다. 이를 위해 U2L Migration 방법론과 Migration 자동화 솔루션 등에 확보하고, 실제 고객사 프로젝트 현장에서 적용하고 있습니다.

우선 체계적인 U2L 프로젝트를 위해서는 다양한 프로젝트 경험을 바탕으로 검증되고 적용 사례를 보유하고 있는 U2L Migration 방법론이 필요합니다.

① 방법론

② U2L Migration Support 솔루션

두 번째로 U2L migration 시 작업자의 Effort를 최소한으로 줄여줄 수 있는 자동화 툴입니다. U2L Migration 전 영역에 있어서 모든 경험을 가지고 있는 능력자가 나타나서 한 번에 아무 탈 없이 깔끔하게 진행한다면 좋겠지만, 현실은 그렇지 못합니다.

인력, 시간, 비용 등 다양한 변수들이 존재하기 때문에 수작업 Migration에 대한 공수를 최대한 줄이는 것이 중요합니다. 그래서, LG CNS에서는 이러한 이슈를 해결하기 위해 U2L Migration 주요 영역에서 효과적으로 활용할 수 있는 솔루션을 확보해서 활용하고 있습니다.

WCS: WAS Configuration Scanne
WCS는 기존 상용 WEB•WAS 솔루션을 U2L 환경으로 전환 시 기존 구성환경을 보다 효과적으로 분석하여 이관 대상을 명확히 함으로써 Migration 단계에서 발생할 수 있는 여러 가지 시행착오를 획기적으로 줄여줄 수 있습니다.

WAS Auto-Deployment Tool
WEB•WAS에 대하여 복잡한 설치 구성 정보를 다수의 WAS Instance에 설치가 필요할 경우 데이터 파일 형태의 구성요건을 분석하고 효과적인 설치를 제공하는 툴입니다.

AppScan
U2L 대상이 되는 기존 애플리케이션 환경을 체계적으로 분석하여 작업자로 하여금 효과적인 Migration을 수행할 수 있도록 도와주는 솔루션이며, 주요 기능은 다음과 같습니다. 기업마다 애플리케이션 소스관리를 체계적으로 완벽하게 수행하고 있는 곳은 흔하지 않을 것인데, IT 인프라의 효율화를 위해 U2L을 고려하고 있다면 기존 애플리케이션을 개발자 수준에서 분석할 수 있는 훌륭한 도구라고 생각이 듭니다.

● 웹 애플리케이션 아키텍처 분석

전체 파일 수, 확장자 및 유형에 따른 파일 수
적용된 Framework 정보
WEB-INF•lib•*.jar 파일 리스트 및 각 라이브러리의 Manifest 정보
잘 알려진 라이브러리 리스트
web.xml 주요 설정 (예: Filter 사용 여부 등)
각 WAS의 Deployment Descriptor 파일 (weblogic.xml 등) 확인
특정 WAS 기능 사용 여부 확인
JDBC Driver의 Driver class 중 Deprecated 여부 확인

● 소스 코드 스캔

JSP 파일 내 Content Type, Page Encoding 종류
클래스, JSP 파일에 import된 패키지 리스트
클래스, JSP, 각종 설정 파일에 포함된 IP Address 리스트
클래스, JSP, 각종 설정 파일에 포함된 경로 정보 리스트
클래스, JSP, 각종 설정 파일에 포함된 JDBC Connection 정보 리스트

LG CNS의 U2L 사례(1) – A통신사

A 통신사는 기존 UNIX 환경에서 운영 중인 SAP ERP 시스템을 x86 기반 Linux 환경으로 Migration 하여 비용 절감과 더불어 ERP 시스템 성능 향상 효과를 얻었습니다.

● SAP DB시스템 Migration Procedure

1) AS-IS ERP 시스템 서비스 정지
2) U2L Migration을 위한 Technical Preparation
– OS, DBMS Installation 및 Configuration
– SAP R3load Migration 환경 설정
3) [Source] SAP R3load를 활용한 Oracle DBMS 데이터 Export
4) [Target] SAP R3load를 활용한 export Data의 Linux 환경으로 Import
5) Post Migration
– Schema, Object, Data정합성 등 확인
6) SAP 애플리케이션 검증

● SAP U2L Migration Optimization을 위한 구성

1) Big Table Splitting
– Big Table에 대한 Migration 시간 단축을 위한 Splitting
2) Parallel export•import 옵션 적용
– Source•Target 시스템의 데이터 export•import 속도 향상을 위한 Parallel 기능적용
3) Distribution Monitor
– SAP DB+CI 서버 외 AP 서버 Resource를 활용하여 Migration Performance 최적화

LG CNS의 U2L 사례(2) – B식자재유통

고객사는 전체 시스템의 40% 이상을 UNIX 환경에서 운영 중이었으며 특히 ERP, 물류 및 기간계 시스템 등 주요 핵심시스템은 고가의 UNIX 시스템상에서 운영되고 있어서 매우 고비용 구조로 운영되고 있었습니다. 이러한 경직된 아키텍처로 운영하다 보니 Business 확장이 지속적으로 추진되고 있는 상황에서 이런 고비용 구조의 UNIX 구조는 고객사 사업에 많은 걸림돌이 되었습니다.

이러한 문제를 해결하고 향후 Scale-Out 아키텍처로 전환하여 비용 효율적인 IT 환경으로 전환을 위해 U2L을 고려하게 되었습니다.

고객사는 U2L 프로젝트를 통해 TCO 절감뿐만 아니라 서비스의 성능 개선 효과를 얻을 수 있어서 경영진에서도 매우 만족스러워하는 Best Practice가 되었습니다. 현재 고객사의 모든 시스템은 클라우드 기반 x86 환경에서 안정적으로 운영되고 있습니다.

U2L Migration 이후 실제 DB 서버의 CPU 사용률은 상당 부분 개선된 것으로 보여주고 있습니다. 위 그림에서 보듯이 기존 UNIX 서버의 tpmC 수치와 U2L 이후 tpmC 수치는 크게 차이는 없지만, 실제 workload를 수행했을 때 오히려 x86 기반 Linux 환경에서의 성능이 더 우수하다는 것을 볼 수 있습니다.

지금까지 U2L은 무엇인지와 LG CNS의 U2L 역량과 실제 적용사례를 소개해 드렸습니다. LG CNS에서는 Migration에 대한 공수를 최대한 줄이며, 그 이슈를 해결하기 위해 노력하고 있습니다. U2L 주요 영역에서 효과적으로 활용할 수 있는 솔루션을 확보한 것인데요. LG CNS의 역량 발전을 통해 보다 나은 서비스를 제공할 수 있도록 노력하고 있습니다.

글 ㅣLG CNS 인프라사업담당

블로그