[기술기고] 클라우드 전환 시 기업들이 가장 궁금해 하는 3가지

기업들의 애플리케이션이 구동되는 인프라는 글로벌 기준 52%가 여전히 데이터센터에 발이 묶여 있고, 국내 엔터프라이즈의 경우 80% 수준에서 운영되고 있는 실정이다. 기업들이 목표로 삼고 있는 종착지인 애플리케이션 모던화는 커녕 기존 운영하던 업무를 클라우드화 하는데도 상당한 어려움을 겪고 있는 것이 현실이다.

일반적으로 클라우드 인프라, 지속 통합/배포(CI/CD), 애자일, 마이크로서비스 아키텍처(MSA)가 클라우드 네이티브 애플리케이션을 위한 핵심 요소라고 이야기한다. 이 글을 읽는 독자들이 운영하는 시스템이 앞서 언급한 4가지 항목 중 몇 개가 구현돼 있는지 살펴보면 현재 우리의 수준이 CNA(Cloud Native Application)화에 어느 정도까지 도달했는지 알아볼 수 있을 것이다.

가트너나 클라우드 서비스 공급업체(CSP)들이 이야기하는 5R/6R 등의 마이그레이션 방법론은 워낙 일반적인 내용이라 이번에는 다루지 않으며, 기업들이 실제로 맞닥뜨리게 되는 클라우드 전환 시 발생할 수 있는 문제와 그 해결 방법에 대해서 살펴보겠다.

가장 궁금해 하는 것 ‘고려사항’

클라우드 마이그레이션 전문 기업 오픈소스컨설팅이 고객 500명에게 클라우드 전환 관련 설문을 진행했는데, 가장 많이 나온 키워드가 ‘고려사항’이었다. 그 다음으로 방법론, 사례, 데이터 이동, 또 다른 영역으로 비용, 보안, 솔루션 순이었다.

지금부터 가장 빈번하게 질문하고 많은 고객들이 궁금해 하는 영역을 선정해 그 질문의 내용과 최선책을 제시해보도록 하겠다.

마이그레이션 진행 시 단계별 고려사항은 무엇인가?

마이그레이션의 단계는 AS-IS 분석, TO-BE 설계, 전환 진행, 이행, 안정화의 단계로 보통 진행되는데 각 영역별 소요되는 시간, 리소스가 고객사마다 다르지만 코어인 분석, 설계, 구축, 전환, 이행까지 이러한 단계의 순서는 변하지 않는 것이 일반적인 전환이다.

마이그레이션 대상이 결정됐다면 실제 구축 전에 마이그레이션을 진행하는 이해관계자들의 명확한 역할과 책임(R&R) 정리가 필요하다. 이후 애플리케이션 분석과 변경요소를 식별한 후 설계 단계에 이를 적용하도록 해야 하고, 실제 전환 시 가장 중요한 비기능적 요소 구현 작업이 아키텍처 설계이므로, 이 작업을 원활하게 진행할 협의체를 구성한다. 또 인프라 요구사항이나 애플리케이션 요구사항을 수시로 협의해 확정하고 설계에 반영해야 한다.

전환 진행을 하는 경우 인프라적인 환경 구축 단계에서는 기존의 운영 환경에 영향을 주지 않도록 별도의 폐쇄망 구성을 보통 진행하게 된다. 연계 시스템 간 통신이 될 수 있도록 구축과 테스트는 필수적이며, 애플리케이션 관점에서는 TO-BE 인프라에 맞는 코드 레벨의 변경과 컴파일, 빌드 작업이 필요하다. 전환 이후에는 해당 애플리케이션이 정상적으로 전환이 잘 됐는지 TO-BE 환경에서 검증과 테스트가 매우 중요하다.

이행 단계에서는 테스트가 완료된 업무 시스템을 전환하는 사전 리허설을 진행해 봄으로써 컷 오버(Cut Over) 시 발생할 수 있는 결함을 사전에 파악하고 보완해야 한다. 실제 컷 오버 작업이 문제 발생이 되는 경우 페일백(Fail-Back) 계획의 수립도 진행해야 한다.

서비스 오픈 이후에는 최소 3일 이상의 안정화 모니터링을 진행해 이 기간 중에 식별된 이슈 및 결함 조치에 대한 통합 관리를 수행하면서 운영팀으로 이관 지원을 수행하는 방식으로 진행하면 된다.

애플리케이션 전환 시에는 무엇을 검토해야 하는가?

업무 애플리케이션 마이그레이션 시 해당 업무를 구동하는 소프트웨어 스택이 존재한다. 서버, OS, 사용하는 언어, 미들웨어 등이 전환 대상이 되는데, 그중 전환 난이도를 결정하는 중요한 요소는 사용하는 언어와 얼마나 많은 인터페이스를 가지고 있는지 여부다.

인프라의 경우 적정한 TO-BE 환경에 대한 사이징, OS의 경우 커널과 디스크 데이터들, 서드 파티 소프트웨어 업그레이드, 미들웨어 복제 또는 리플랫폼 여부, 애플리케이션 소스 수정까지 고려해야 한다.

언어적인 측면의 경우 자바로 된 애플리케이션은 보통 웹 애플리케이션 서버를 사용하게 되는데 사용 중인 WAS(Web Application Server)와 소스 코드 레벨의 관점에서 전환에 대한 고려사항이 있다. 이 중 중요한 요소는 하드코딩된 IP, 연계 인터페이스 식별, JDK 업그레이드 시 발생할 수 있는 라이브러리의 확인 등이 있으며, 정책적인 부분으로 WAS의 경우 동일 기종인 경우 업그레이드할 것인지, 다른 WAS로 변경할 것인지에 따라 소스 코드 레벨까지 변환해야 하는 영향도가 있으므로 초기 의사결정이 매우 중요하다.

C 언어로 작성된 애플리케이션의 경우 Pro*C 같은 배치성 프로그램이나 Tuxedo, Tmax 등의 TP-Monitor가 될 수 있으며, 전환 핵심 포인트는 유닉스 런타임을 리눅스 런타임으로 바꿔야 하기 때문에 GCC로 컴파일되도록 하는 것과 런타임 검증이 제일 중요한 고려사항이 된다.

클라우드 네이티브 환경 전환에서 직면하는 어려움이 무엇인가?

클라우드로 전환을 하게 되는 경우 기존의 시스템을 단순히 리프트 앤 시프트(Lift-and-Shift)로 옮기는 대상도 있지만 변경하여 옮겨야 하는 상황도 발생을 하고 있고, 향후 클라우드 네이티브 애플리케이션을 변화시키고자 애플리케이션 모던화를 검토하는 고객이 많아지고 있다.

비즈니스 혁신 등의 목적으로 많은 기업들이 클라우드 도입을 추진하고 있음에도 불구하고, 동시에 많은 엔터프라이즈 기업들이 마이그레이션 과정에서 어려움을 직면하고 있는 것도 사실이다. 이 어려움을 4가지로 정리해보면 다음과 같다.

첫 번째는 조직 간 클라우드 이해에 대한 차이가 있다는 것 그리고 주요 이해 관계자 간의 전사 부서들 간의 조정이 부족하다는 점이 있다.

두 번째는 불명확한 목표, 결국엔 마이그레이션이 되고 난 이후에 어떤 목표를 향해 달려가야 할지에 대한 기업 내부와 조직 간 동일한 목표 합의가 부족하다는 점, 이러한 부분을 커버하기 위해 엔터프라이즈 애자일을 검토하는 추세다.

세 번째는 클라우드 마이그레이션을 위한 내부 역량 준비 상황이 어떻게 되는지 파악이 부족한 부분이 있다. 내부적인 정확한 역량 파악이 우선되어야 전환 준비와 전환 후 대응이 가능하게 될 것이다.

마지막으로는 클라우드로의 여정에 복잡한 과정이 있음에도 불구하고 마이그레이션을 리피트 앤 시프트(Lift-and-Shift)만의 단순한 과정으로만 생각해서 계획하고 실행하는 오류를 범하게 되는데, 이러한 사항들이 기업의 마이그레이션 과정에서 직면하고 있는 근본적인 어려움이 되고 있다.

사실 이 네 가지 원인이 각각의 독립적인 원인이기보다는 서로 굉장히 타이트하게 연결된 복잡한 원인들로 인해 발생되는 것들이 많은데, 이런 부분을 해결하기 위해서는 첫째 성공적인 마이그레이션을 위해서는 현실적인 기대치를 가져야 하며, 둘째 잘 다듬어지고 정교한 계획을 수립을 하는 준비 과정이 반드시 필요하다.

클라우드 네이티브를 통해 디지털 전환을 위한 여정은 수개월 내에 끝낼 수 있는 간단한 사항이 아니다. 이 과정은 매우 긴 여정이며, 시작 초기에 작은 경험을 통해 얻은 지식을 점차 넓혀 전체로 확대될 수 있는 전략을 세우는 것이 매우 중요하다.

 [백서 다운로드] 클라우드 마이그레이션 수행 시 가장 많이 묻는 질문 Top 10

출처: 데이터넷 https://www.datanet.co.kr/news/articleView.html?idxno=164386