[U2L] Unix to Linux 기대효과 분석

본 포스팅은 U2L 프로젝트 수행 시 기대효과에 대해 알아보겠습니다.

---

최근 노후된 기 시스템을 U2L(Unix to Linux)을 통해 전환하는 사례가 늘어나고 있습니다. x86 서버의 성능이 최근 Unix 못지 않게 개선되었으며, 무엇보다 비용이 저렴하기 때문입니다. 본 포스팅에서는 U2L을 수행하는데에 따른 기대효과에 대해 살펴보고 이를 통해 변화하는 시스템 아키텍처의 방향성을 되짚어보도록 하겠습니다.

최근 IT 시장은 급변하는 DT 시대로 접어들고 있습니다. 그 중 클라우드에 접목시키기 위한 오픈소스 활용 방안이 늘어가고 있으며, 특히 x86(Linux)의 시장은 점점 늘어가고 있다고 볼 수 있습니다.

U2L 수행시 어떠한 기대효과가 있을것인가에 대한 고민에서부터 시작해 보도록 하겠습니다.

---

- 저비용 고효율 IT 시스템 구축

전세계 Unix 시장점유율은 계속 감소하는데 반해 리눅스는 증가하고 있는 추세입니다.

Unix 시스템을 비용 효율적인 X86 서버로 대체함으로서, 시스템 구축 비용 및 운영 비용 절감과 유연성 확보합니다.

- IT 환경의 유연성과 기술혁신 토대 마련

신기술 수용, 유연성, 비용 효율화, 유지보수 효율성을 확보합니다.

x86/리눅스 기반의 인프라 혁신이 주류를 이루고 있습니다.

최근 SW의 개발환경이 대부분 리눅스 플랫폼으로 이루어져 있습니다.

- 클라우드 레디 시스템 구축

클라우드 인프라 기반 플랫폼은 x86/리눅스 서버가 주를 이룹니다.

x86 서버는 오픈 클라우드 환경 전환이 용이하나, Unix서버는 벤더 종속적입니다.

---

1. x86(Linux)의 장점

x86(이하 Linux)의 시장이 늘어가고 있는 이유를 살펴보다면 몇가지 이유가 있지만 대체로 아래와 같은 이유가 수반되기 때문입니다.

---

- 먼저 오픈소스를 기반으로 한 신기술을 적용하는데 장점이 있습니다.

- 특정 벤더사에 종속되어 있는 기술구조가 아닌 다양한 회사에서 오픈소스를 발전시키며 경쟁하는 구도로 많은 부분에서 기술적인 발전을 이끌어 낼 수 있습니다.

- 성능, 속도 그리고 무엇보다 비용 절감 측면에서 효과적이며, 신기술이 지속적으로 업데이트 되는 최근 추세에 변화 가능한 Linux를 사용하는 것으로부터 사이트 유지보수 측면의 장점을 갖추고 있습니다.

---

2. U2L을 통한 대상 및 기회비용 산정

자 그렇다고 무조건 U2L을 수행할 수 있는 것은 아닙니다. U2L을 수행하는데 있어서 고효율을 이끌어내고 전환 비용을 산정할 때 어느 수준까지 U2L 대상에 포함시킬 것인가를 결정하는것은 매우 중요한 요소입니다.

U2L을 효과적으로 수행하기 위해서는 그 범위를 OS, WEB, WAS, DB까지 포함하여 일괄로 진행하게 될 경우 전환 시간을 줄이고, 최대 효과를 낼 수 있지만 다음과 같은 제약사항 역시 발생할 수 있습니다.

---

- OS만 전환대상에 포함 할 경우 : U2L 마이그레이션을 통해 위험부담을 줄 일 수 있지만, OS 이후 WEB, WAS, DB, 솔루션등을 체계적으로 하나씩 전환해 나간다면 전환 시간이 상대적으로 오래 소모 될 수 있으며, 커다란 효과를 보기 어렵습니다.

- OS와 WAS를 전환대상에 포함 할 경우 : U2L 마이그레이션 중 공수 산정시간이 긴 편으로 애플리케이션 전환 비용 및 WAS 변경으로 인한 마이그레이션 작업이 필요합니다. 전환이 완료될 경우 기대효과가 크다고 볼 수 있습니다.

- OS와 WEB을 전환대상에 포함 할 경우 : U2L 마이그레이션을 통한 위험부담이 적은 모듈로써, 전환 공수가 짧게 산정되지만, 이에 따른 기대효과를 크게 가져올 수는 없습니다.

- OS와 DB를 전환대상에 포함 할 경우 : U2L 마이그레이션을 수행하기 위한 가장 많은 공수 산정이 필요하며, 전환 자체의 난이도 역시 매우 높습니다. Data를 마이그레이션 하기 위한 전문가 투입이 필요하며, 이는 U2L 프로젝트 중 가장 큰 비용이 소모 된다고 볼수도 있지만, 역시 성공적으로 프로젝트를 완수하였을 경우 기대 효과가 매우 크다고 볼 수 있습니다.

---

위와 같이 다양한 모듈들을 OS U2L대상에 포함시키게 되면 일정을 단축할 수 있고, 기대비용 역시 크게 작용한다고 볼 수 있습니다. WEB/WAS의 경우 동시에 진행되는 경우가 많지만, DB의 경우 영향도 파악이나, 마이그레이션에 소모되는 비용과 리스크가 크기때문에 별도로 진행되는 경우가 있긴합니다.

이때 선정되는 일반적인 오픈소스 모듈은 다음과 같습니다.

---

- WEB : Apache 등

- WAS : JBossEAP, Tomcat 등

- DB : EPAS, MariaDB, MongoDB 등

---

3. U2L 전환 절차

다음으로 전환 절차에 대해 살펴보겠습니다. Unix를 Linux로 전환하기 위해서는 일반적으로 다음과 같은 과정을 수행합니다.

---

- 기 운영 환경 분석 및 대상 선정

- 이행 준비 및 사전 테스트

- 마이그레이션 수행

- 최적화 및 안적화 수행 후 오픈

---

각 단계별 주요 필수 확인사항으로는

[기 운영 환경 분석 및 대상 선정]

---

a. 현행 시스템 분석단계에서 충분한 분석 활동이 요구된다.

충분한 분석 없이 시스템 구성도 등의 기본항목만을 작성하여, 아키텍처 설계 시 고려되어야 할 입력 항목들을 추가적으로 식별하기 위해 불필요한 반복/산발적인 작업이 수행되는 경우가 존재한다.

b. 현행 시스템 분석에서 파악된 현행 시스템의 문제점을 통해 아키텍처의 개선점을 도출할 수 있다.

이러한 개선점은 시스템 운영자 및 사용자의 확인을 거친 후 요구사항 정제 과정을 통하여 요구사항으로 정의한다.

c. 수행 방법은 인터뷰와 문서 그리고 실사로 이루어진다.

인터뷰 : 고객의 분석 담당자와 인터뷰를 통해서 프로세스 수행에 필요한 시스템을 확인한다. 인터뷰 시 담당자뿐만 아니라 업무 담당자도 함께 배석하는 것이 좋으며, 시스템이 있다고 하더라도 실제 일하는 방식은 OFF-LINE에서 수행되는 것이 더 중요하고 의미있는 경우가 많다. 특히 해외에는 정형화된 패키지를 사용하는 경우가 많으므로 고객의 NEEDS가 시스템상에 나타나지 않는 경우가 있다.

문서 및 산출물 : 시스템에 대한 설명 자료(메뉴얼, 운영가이드 등)와 업무 진행 중에 만들어진 산출물을 이용하여 분석하낟.

실사 : 실제 해당 시스템이 동작 중인지 사용 중인지 확인 절차가 반드시 필요하다. 특히, 외부적으로는 사용한다고 했으나 사용하지 않는 경우 혹은 사용할 수 없는 경우도 있으며, 담당자도 이를 정확하게 모르는 경우도 많다. 특히 업무 담당자가 배석하지 않은 경우에는 해당 위험이 더 높아진다.

---

[이행 준비 및 사전 테스트]

---

a. 아키텍처 이슈에 대해서 아키텍트의 수행경험, Best Practice 등을 참고하여 설계전략 후보를 도출하되 기술적 위험이 큰 경우에 대해서 설계전략 검토서의 항목으로 작성을 하도록 한다. 이를 통해서 결정된 의사결정에 대해서 아키텍처정의서에 기술한다.

- 설계전략 검토서 주요 작성항목 

아키텍처 설계 전략 정의 대상 : 아키텍처 분석에서 도출된 아키텍처 이슈에 대한 설계전략 수립 대상을 선정하여 기술한다.

설계 전략 대안 검토 : 설계 전략 수립대상 별로 검토한 내용을 기술한다. 설계 전략은 아키텍처 스타일, 컴포넌트 도출 전략, 배치작업 전략, 트랜잭션 처리 전략, 통합 로깅 전략, 사용자 인증 전략, Legacy연계 전략 등과 같이 반드시 대안이 고려되어야 하는 시스템 전체 품질속성에 영향을 줄 수 있는 항목을 대상으로 작성하도록 한다.

설계 전략 개요 : 설계 전략의 이슈 및 수립된 전략에 대해 간단하게 기술한다.

설계 전략 (내용) : 수립된 전략의 구체적인 내용, 즉 설계대안에 대한 장단점을 기술한다

b. 기술 위험이 큰 설계전략의 경우는 가급적 PoC를 수행하여 의사결정 사항을 명확하게 해야 한다.

poc간 업무영향도가 큰 시스템을 선정하여 사전 애플리케이션 포팅 및 데이터베이스 마이그레이션을 진행하고 이를 기반으로 기능, 성능 측정을 수행할 수 있도록 선행 사전 테스트를 수행한다.

---

[마이그레이션 수행]

---

a. 솔루션이 결정되면 이를 기반으로 서비스 마이그레이션 시나리오를 정의한다.

마이그레이션을 통해 순차적으로 진행되어야 할 시스템과 병행해서 진행해야 할 시스템을 결정한다.

또한 업무간 협업이 필요한 경우를 대비하여 사전 연계 모듈에 대한 파악 및 업무 협약을 진행한다.

b. AS-IS 시스템과 TO-BE 시스템 간의 성능 비교를 위한 측정 데이터를 사전에 수집한다.

이후 기능 검증에 대한 시나리오를 확정하고, 성능 측정 시 어떠한 기준치를 가져갈 것인지에 대한 비교 데이터 즉 AS-IS 시스템을 기준으로 TPS 등을 결정한다.

c. 실제 업무 전환을 진행한다.

다양한 부서의 조직이 업무를 수행함에 있어 이를 리딩하는 PM, PL을 기준으로 파트별 협업이 명확히 이루어지고, 업무분장이 될 수 있도록 각 Architecture 조직별로 업무처리를 리딩한다.

장애 처리나 이슈를 처리하는데 SW의 지원이 필요할 경우 SA, 인프라 관련 TA, 데이터베이스 관련 DA, Application 개발 관련 AA를 통해 업무가 효율적으로 처리 될 수 있도록 PM은 리딩해 나갈 필요가 있다.

d. 전환이 완료되면 이를 어떻게 이행할 것인지에 대해 결정한다.

---

[최적화 및 안적화 수행 후 오픈]

---

a. 전환이 완료 된 이후 기존 as-is 시스템을 기반으로 측정한 성능 비교 및 기능 테스트를 수행한다.

b. 장기간(최소 1주일) Stress Test를 통해 시스템의 안정성을 검토한다.

c. 안정성이 확보된 이후에는 이를 기반으로 시스템을 오픈한다.

d. 오픈 이후 후선 대응 방안을 마련하고, 비상연락망 체계를 구축한다.

---

오픈소스를 사용할 경우 위와 같은 다양한 장점을 기반으로 도입을 검토하게 되지만, 모든 면에서 장점만 있는 것은 아닙니다.

비용절감과 전문 기술 확보를 위한 IT부서의 장점은 있지만, 오픈소스를 다루는 전문 인력이 부족하다보니 추후 운영측면에서 매우 중요한 기술지원 서비스의 품질이 떨어질 수 있고, 컨설팅, 마이그레이션에 투입과는 비용 산정의 문제가 발생할 수 있습니다.

이와같이 최근 IT 환경을 이끌어 나가는 오픈소스 그리고 x86 리눅스로의 전환을 사이트에 적용하기 위해서는 다양한 검토가 필요할 것입니다.