OpenCloud

메인프레임까지... ㅎㄷㄷ

 APN Blog 메인프레임 섹션 에 참조할 만한 많을 글이 있다.

https://aws.amazon.com/ko/blogs/korea/yes-you-should-modernize-your-mainframe-with-the-cloud/

클라우드 이전 시 많은 대기업 고객이 떨쳐버리지 못하는 걱정은 마이그레이션하고 나면 저 메인프레임(Mainframe)은 어떻게 해야 하는지에 대한 것입니다. 사실 클라우드 기반으로 설계된 워크로드는 수평적 확장성에 집중합니다. 즉, 컴퓨팅 처리 용량이 필요해지면 수요를 충족하기 위해 인스턴스를 추가하면 됩니다. 이에 반해 많은 레거시 시스템은 필요에 따라 더 크고 더 강력한 시스템을 추가하는 수직적 확장을 염두에 두고 설계되었으며, 결국 대기업에서 가장 중요한 워크로드는 메인프레임을 선정하고, 대체로 뛰어난 성능과 안정성을 제공했기 때문에 성공적입니다.

이 글은 메인프레임 워크로드를 클라우드로 마이그레이션하는 데 관심이 있는 기업들이 선택할 수 있는 여러 방안을 설명합니다.

왜 메인프레임이 아니고 클라우드인가?

대기업 고객에게는 기존 메인프레임을 AWS 클라우드로 마이그레이션하는 사업상 이유가 있습니다. 하지만, 메인프레임 현대화 프로젝트는 대체로 인내심과 강력한 리더십, 그리고 의도한 ROI를 달성할 탄탄한 접근 방법이 필요합니다. 기존에 AWS 클라우드로 이전하는 고객 프로젝트에서 성공을 거둔 경험을 바탕으로 우리는 새 메인프레임을 AWS로 이전하는 이니셔티브를 촉진하는 패턴, 교훈, 모범 사례를 파악했습니다.

우리는 고객이 AWS로 메인프레임 워크로드를 현대화하려는 여러 이유가 있음을 알게 되었습니다. 첫째, 비용 절감은 분명 메인프레임에서 AWS로 워크로드를 이전하는 데 따라오는 강력한 이점입니다. 자본 지출과 MIPS(millions of instructions per second)를 제거하고, 독립 소프트웨어 공급업체(ISV) 라이선스 비용을 줄이며, 탄력적 요금 모델을 활용할 수 있기 때문입니다. 둘째, 연속 통합 및 지속적인 업데이트(CI/CD)와 온디맨드로 사용하는 거의 무한한 인프라 리소스를 통해 개발 주기가 단축되어 민첩성을 얻게 됩니다. 셋째, 수십 년간의 비즈니스 거래가 포함되어 경쟁 차별화 요소를 모색하는 데이터 분석 또는 머신 러닝 이니셔티브를 제공할 수 있는 메인프레임 데이터 활용에 따른 장점이 있습니다. 마지막 네 번째로 AWS 클라우드로 이전을 통해 메인프레임 퇴역에 따른 기술 격차를 해결하고 새로운 인재를 유치하여 핵심 비즈니스 워크로드를 현대화할 수 있습니다.

AWS 클라우드를 통한 메인프레임 현대화에는 한 가지 해결책이 없습니다. 대기업 고객은 비즈니스 및 IT 전략에 따라 메인프레임 특유의 기술적 제약에 따라 가장 적합한 패턴을 선택해야 합니다. 메인프레임이 여러 워크로드를 처리할 만큼 크다면 각 워크로드의 특성마다 유리한 패턴이 다를 수 있습니다. 워크로드 자체가 특정 프로그램이나 데이터와 독립적일 경우에는 쉽게 파악할 수 있습니다. 하나의 메인프레임 내에서 안정화된 애플리케이션이 따르는 패턴이 있기도 하고, 계속해서 변화 중인 애플리케이션은 다른 패턴에 따를 수 있습니다. 이처럼 워크로드마다 적합한 여러 전략을 선택할 수 있다는 점이 위에서 설명한 네 가지 동인, 그중에서도 비즈니스 민첩성과 기술 격차를 활용하는 것이 고객이 성공을 거두는 비결입니다.

이를 바탕으로 AWS 고객 중 메인 프레임을 이전한 성공적인 패턴 몇 가지를 소개합니다.

패턴 1: 자동 리팩터링을 통한 단기 마이그레이션

자동 리팩터링은 레거시 스택(예: COBOL 기반)을 새로운 스택(예: Java 기반 또는 .Net 기반)으로 변환하기 위해 리버스 엔지니어링과 포워드 엔지니어링을 모두 자동화합니다. 효율성과 품질을 위해 이 변환에는 최대한 많은 자동화가 있지만 수동 코드 재작성은 없습니다. 일반적으로 이로 인해 애플리케이션은 클라우드 네이티브 애플리케이션과 비슷한 열 두가지 앱 모범 사례에 따라 다양한 AWS 서비스를 통해 탄력성, 수평적 확장성, 보다 간편한 통합을 제공합니다.

그림 1: 자동 리팩터링을 통한 단기 마이그레이션

이 패턴을 기본적인 줄 단위 코드 변환(예를 들어, 절차형 COBOL을 절차형과 유사한 Java(혹은 JOBOL)로 변환하는 것으로 유지 관리와 통합이 어려운 변환 작업)을 수행하는 언어 변환 도구와 혼동하면 안 됩니다. 자동 리팩터링 도구는 코드, 데이터 액세스, 데이터 스토어, 프레임워크, 트랜잭션 하위 시스템, 의존성 호출을 포함한 전체 레거시 스택을 분석하고 변환하는 종합적 접근 방법을 취합니다. 여기서 자동으로 생성되는 일관되고 기능적으로 동등한 대상 스택은 서비스 지향적이고 서비스 가능할 뿐 아니라 AWS 서비스를 위한 패키징된 최적화를 갖추고 있습니다. 또 마이크로서비스 생성을 위한 서비스 분해도 촉진합니다.

자동 리팩터링 도구의 가치와 차별화 요소는 주로 자동화된 포워드 엔지니어링 기능에 달려 있습니다. 리버스 엔지니어링 기능을 갖춘 도구는 많지만 강력하고 광범위한 포워드 엔지니어링 자동화를 갖춘 도구는 거의 없습니다.

일례로 미 국방부의 한 고객은 전체 메인프레임 COBOL 및 C-logistics 시스템(수백만 줄의 코드)을 AWS에서 Java로 자동으로 리팩터링하여 레거시 코드의 기술적 부채를 제거했습니다. APN 블로그는 ‘Blu Age와 AWS를 사용하여 메인프레임 배치를 클라우드 마이크로서비스로 마이그레이션하는 방법‘과 ‘클라우드 네이티브 Heirloom PaaS가 포함된 AWS의 고성능 메인프레임 워크로드‘에서 몇 가지 자동 리팩터링 도구를 보여 줍니다.

패턴 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

이 패턴은 AWS 클라우드에서 실행되는 에뮬레이터에 대한 리플랫폼(re-platform)입니다. 이 접근 방법을 사용하면 레거시 애플리케이션 코드가 코드 변경이 최소화된 상태로 에뮬레이터로 이전되므로 동일한 애플리케이션 유지 관리 및 개발 기술이 유지되고 필요합니다. 이 마이그레이션은 최종 사용자의 관점에서 매끄러우며, 애플리케이션의 인터페이스와 룩 앤 필을 동일하게 유지합니다.

그림 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

일반적으로 지원되는 소스 코드는 다시 컴파일되며 지원되지 않는 언어 코드는 먼저 지원되는 언어로 변환된 다음 다시 컴파일됩니다. 다른 타사 유틸리티 인터페이스와 통합하거나 그 과정에서 데이터 스토어 및 데이터 액세스를 현대화할 때는 코드 변경 또는 리팩터링이 필요합니다. 이 패턴의 경우, 도구에는 에뮬레이터와 컴파일러뿐 아니라 프로그램 및 데이터 마이그레이션 자동화에 필요한 유틸리티도 포함됩니다.

이 패턴을 더 큰 현대화 여정 내의 중간 단계 또는 안정화된 애플리케이션의 목표 상태로 보기도 합니다. 일례로 한 다국적 음료 회사는 AWS에서 에뮬레이터를 사용하여 배치 모드 및 온라인 트랜잭션 처리 기능을 다시 만들어 마이그레이션하면서 동일한 메인프레임 그린 스크린 경험을 제공했습니다. APN 블로그는 ‘NTT DATA 서비스를 사용하여 메인프레임 애플리케이션을 AWS로 리호스팅‘ 및 ‘5단계로 메인프레임을 AWS로 마이그레이션하기‘에서 몇 가지 에뮬레이터 도구를 보여 줍니다.

패턴 3: 데이터 분석을 통한 증설

이 패턴은 워크로드 마이그레이션이 아니라 AWS에서 민첩한 데이터 분석 서비스를 사용하는 메인프레임 증설에 대한 것입니다. 엄청나게 많은 사용자의 수십 년에 걸친 과거 비즈니스 트랜잭션이 포함될 수 있는 메인프레임 데이터는 강력한 비즈니스 장점입니다. 이에 따라 고객들은 빅 데이터 분석을 사용하여 메인프레임 데이터의 비즈니스 가치를 높입니다. 메인프레임이라는 대안에 비해 AWS의 빅 데이터 서비스를 사용하면 보다 빠른 분석 기능을 얻을 수 있으며, 데이터 레이크를 만들어 구조화된 데이터와 구조화되지 않은 데이터를 혼합하고 회사 데이터 자산에 대한 한층 더 종합적인 관점을 제공할 수 있습니다.

그림 3: 데이터 분석을 통한 확대

AWS는 수집부터 처리, 저장, 분석, 시각화, 자동화까지 전체 데이터 수명 동안 서비스를 제공합니다. 복제 도구는 메인프레임의 관계형, 계층적 또는 레거시 파일 기반 데이터 스토어에서 민첩한 AWS 데이터 레이크, 데이터 웨어하우스 또는 데이터 스토어로 메인프레임 데이터를 실시간으로 복사합니다. 이 실시간 복제로 데이터가 새것으로 유지되고 최신 분석과 대시보드가 가능해지며, 메인프레임은 레코드 원본으로 유지합니다.

일례로 미국의 한 여객 철도 회사는 이 절에서 설명한 패턴에 따라 판매, 마케팅, 수익, 사기 분석을 위한 실시간 대시보드와 보고를 통해 메인프레임 데이터를 활용했습니다. APN 블로그에서는 ‘AWS 및 Attunity Replicate로 메인프레임 데이터를 활용하는 방법‘을 통해 실시간 데이터 복제를 보여 줍니다.

패턴 4: 새로운 채널을 통한 확대

레거시 언어를 사용한 메인프레임 개발 주기는 느리고 융통성이 없기 때문에 고객들은 AWS를 사용하여 새로운 서비스를 신속히 구축하면서 로컬 AWS 데이터 스토어에 있는 실시간 메인프레임 데이터에 액세스합니다. 이것은 패턴 3의 변형으로서 로컬 메인프레임 데이터를 분석이 아니라 최종 사용자용 신규 통신 채널과 신규 기능에 사용합니다. AWS의 민첩한 새 기능은 레거시 메인프레임 애플리케이션을 확대합니다. 새로운 채널의 예는 모바일 또는 음성 기반 애플리케이션일 수도 있고, 마이크로서비스 또는 머신 러닝에 기반한 혁신일 수도 있습니다.

그림 4: 새로운 채널을 통한 확대

이 패턴은 AWS에서 새로운 채널을 배포하여 값비싼 메인프레임 MIPS 증가를 방지합니다. 데이터가 복제되기 때문에 데이터 아키텍트는 메인프레임과 AWS 데이터 스토어에서 잠재적인 데이터 일관성 또는 무결성 문제에 주의해야 합니다.

일례로 미국의 한 대형 상업 은행은 AWS에서 새로운 Lambda 기반 서버리스 마이크로서비스를 개발하여 DynamoDB에 있는 복제된 메인프레임 데이터에 액세스하고 이 새로운 서비스를 API 게이트웨이를 통해 모바일 사용자에게 제공했습니다. 이 패턴의 도구는 패턴 3 도구와 비슷하며, 레거시 데이터 스토어 또는 메인프레임 메시징 시스템에서 실시간 데이터 복제를 수행합니다.

메인 프레임 이전 과정 및 모범 사례

우리는 과거 프로젝트, 고객, 파트너 경험에서 배운 것을 토대로 메인프레임을 개발해 AWS 모범 사례로 개선하고 있습니다.

1. 신기술 적용 테스트 (POC) – AWS로 이전할 메인프레임 워크로드의 가장 복잡한 기술적 측면을 해결할 수 없으면 프로젝트는 실패할 수 있습니다. 위험을 줄이려면 고객은 복잡한 POC를 요청해 고객만의 가장 어려운 시나리오로 도구 기능을 평가해야 합니다. 이것은 POC 범위가 커야 한다는 뜻이 아니라 소수의 POC 테스트 케이스가 최대한 세밀해야 한다는 뜻입니다. 고객 메인프레임 워크로드에 따라 배치 기간, 다수의 프로그램 및 데이터 의존성, 비지니스 논리, 일반적이지 않은 레거시 기술 또는 버전, 지연 시간 요구 사항, 높은 초당 처리량이나 트랜잭션 또는 많은 양의 코드나 데이터에 있을 수 있습니다. 세밀한 POC는 도구의 능력을 검증하고, 도구 결과물의 품질을 보여 주며, 도구 공급업체와 고객에게 성공적인 협업을 보증합니다.
2. 자동화 – 메인프레임은 일반적으로 수백만 줄의 코드와 페타바이트 규모의 데이터를 호스팅합니다. 사람의 개입은 오류, 위험, 테스트, 기간, 비용을 늘립니다. 따라서 단기 현대화 프로젝트는 수동으로 재작성 없는 최대한의 자동화와 함께 입증된 소프트웨어 스택을 사용합니다. 이러한 자동화에는 마이그레이션 규칙을 적용하기 위한 자동화, 코드 리팩터링을 위한 자동화, 데이터 현대화를 위한 자동화, 테스트 실행을 위한 자동화(CI/CD 파이프라인)가 포함됩니다.
3. 패턴, 도구, 아키텍처, 활동 순서 결정 – 개별 이전 패턴은 전체 접근 방법의 틀을 잡으며, 패턴마다 다른 도구 세트가 필요합니다. 개발 도구는 메인프레임 현대화의 중요한 성공 요인이며, 가능한 한 일찍 세밀한 POC를 사용하여 기술적으로 테스트해야 합니다. 도구가 검증되면 도구와 AWS 모범 사례를 바탕으로 전체 아키텍처가 생성됩니다. 그 다음에는 기술적 아키텍처가 현대화 구현 활동을 주도합니다.
4. 벤더 중립적인 패턴 선택 – 메인프레임 현대화에서 모든 경우에 두루 적합한 단일 방법이나 단일 도구는 없습니다. 도구 공급업체들은 한 가지 패턴에만 집중하는 경향이 있습니다. 또한 패턴마다 여러 공급업체와 도구가 존재합니다. 따라서 패턴 선택은 공급업체 제약이 없어야 하고(vendor agnostic), 고객의 비즈니스 및 IT 전략 우선 순위와 고객 메인프레임 스택의 기술적 제약이 중심이 되어야 합니다.
5. 시스템 통합 사업자 선택 – 컨설팅 및 시스템 통합 서비스 회사는 AWS로의 메인프레임 현대화 프로젝트의 모든 단계에서 다양한 정도로 도움을 줄 수 있습니다. 오직 한 가지 패턴과 선호하는 한 가지 도구에만 특화되어 있는 시스템 통합 사업자가 있는가 하면 여러 패턴과 패턴별로 여러 도구를 아우르는 시스템 통합 사업자도 있습니다. 현대화 도구 선택에 앞서 한 가지 특정 도구에 대한 시스템 통합 사업자의 전문성이 아닌 고객의 최선의 이익을 기준으로 패턴과 도구에 대해 조언하려면 컨설팅 전문 서비스가 패턴 중립적이고 공급업체 중립적이어야 합니다. 다른 한편 일단 고객 시스템 통합 사업자가 도구를 선택하고 나면 전문 서비스는 선택된 메인프레임 현대화 도구와 AWS 관련 전문성을 갖춰야 합니다. 관련된 기능이 다양하기 때문에(컨설팅, 메인프레임, AWS, 현대화, 도구, 통합, 테스트) 팀 또는 전문 서비스 회사의 연합이 참여하는 것을 흔히 볼 수 있습니다.
6. 레거시 데이터 스토어 현대화 – AWS에서 계층적 데이터베이스 또는 색인 데이터 파일 같은 레거시 데이터 스토어를 유지하면 단일 장애 지점, 병목 현상 또는 낡은 데이터 모델 같은 레거시 기술 부채와 제약 및 인터페이스가 그대로 유지됩니다. 어떤 패턴이건 데이터 스토어 및 데이터 액세스 계층 현대화는 일반적으로 소규모 투자를 통해 확장성, 가용성, 민첩성, 운영, 기술, 비용 절감, 데이터 통합 및 새로운 기능 개발을 위한 더 큰 이득을 제공합니다.
7. 워크로드 기반 현대화 – 여러 독립적 워크로드를 호스팅하는 대규모 메인프레임의 경우, 워크로드마다 서로 다른 현대화 패턴에 따를 수 있습니다.
8. 기술적 이전과 비즈니스 팀과 동시 협업– 이전 도구는 일반적으로 빠르게 기술적인 현대화에 우선 최적화되어 있습니다. 비즈니스 수준의 변경 또는 리팩터링에는 수동 개입과 비즈니스 팀의 참여가 필요하며, 메인프레임과 AWS 사이에서 몇 가지 기능적 동등성 테스트를 수행할 수 없습니다. 따라서 비즈니스 현대화와 기술적 현대화를 동시에 혼용하면 복잡성, 기간, 위험, 비용이 증가합니다.
9. 도구 평가 방식 정의 – 레거시 기술 스택 지원, 복잡한 POC 성공, IT 전략 정렬, 프로젝트 속도(매달 마이그레이션되는 코드 줄 수 등), 대상 애플리케이션 스택 민첩성, 대상 데이터 스토어 민첩성, 대상 코드 유지 관리, 코드 줄당 마이그레이션 비용, 대상 스택 라이선스 비용, 투자 수익(ROI) 속도 등을 정의해야 합니다.
10. 이전 및 실행 시간 비용 추정 – 현대화 비용에는 현대화 과정에서 사용하는 도구의 라이선스 비용과 현대화 활동에 필요한 전문 서비스 비용이 포함됩니다. 여기에 더해 ROI 속도에 직접 영향을 미치는 대상 아키텍처의 반복적 실행 시간 비용이 중요합니다. 실행 시간 비용에는 도구 라이선스 비용(있는 경우)과 AWS 서비스 비용이 포함됩니다. 예를 들어 고객이 반복적인 연간 실행 시간 비용을 80% 줄이는 경우, 3년 후에 현대화 비용을 회수할 수 있어 그 이후로는 신규 투자에 사용할 수 있는 상당한 절감이 발생합니다.

마무리

최근 대기업 고객들은 AWS를 활용하여 메인프레임을 현대화합니다. 이 글에서 알려드린 패턴, 모범 사례, 파트너 프로그램 등이 이러한 프로젝트를 성공적으로 이끌고 있습다. 여러분이 메인프레임 현대화 프로젝트에 관심이 있으시다면, 여러 모로 도움이 되기를 바랍니다. 클라우드 이전을 시작하시려면 다음 조치를 취하는 것이 좋습니다.

1. 비즈니스 및 IT 우선 순위와 더불어 메인프레임의 기술적 아키텍처를 수집합니다.
2. 가능한 AWS 현대화 패턴을 이해하고 선호하는 패턴을 결정합니다.
3. 선택한 패턴과 메인프레임 특성을 가장 잘 지원하는 도구와 공급업체를 파악합니다.
4. 도구의 가치 제안을 평가하고 복잡한 개념 증명을 사용하여 선택을 확인합니다.

AWS로의 메인프레임 마이그레이션에 대해 자세히 알아보려면 언제든지 문의하십시오. APN Blog 메인프레임 섹션에서 우리 파트너의 가치 제안을 검토해 보십시오. 메인프레임이 아닌 레거시 AS/400 또는 iSeries 또는 IBM i 시스템을 위한 유사한 패턴과 모범 사례도 있습니다.