Trimble의 오라클 DB 마이그레이션 성공기 – AWS Schema Conversion 활용 사례

Trimble의 오라클 DB 마이그레이션 성공기 – AWS Schema Conversion 활용 사례

최근에 Trimble사의 FSM(Field Service Management) 사업부 인프라 운영팀은 비공개로 호스팅 되는 SaaS 제품을 Amazon Web Services(AWS)로 마이그레이션하기 위한 적극적인 활동에 착수했습니다. 이 글은 Trimble Inc.의 FSM 인프라 운영 담당 이사인 Todd Hofert의 기고 글로서 어떻게 AWS로 마이그레이션 했는지 그 과정을 담고 있습니다.  좀 더 자세한 것은 Youtube 고객 사례를 참고하시기 바랍니다.

Trimble FSM 사업부는 하드웨어 교체 요구 및 지속적인 비용 절감 압박에 직면하면서 레거시 제품을 수정하여 회사의 차세대 플랫폼에 맞춰 AWS로 이전 하고 있습니다. 이에 따라 Trimble의 인프라 팀은 해당 데이터 웨어하우스 솔루션을 시작으로 하는 포괄적인 마이그레이션 계획을 수립했습니다.

Trimble은 Oracle에서 오픈 소스 데이터베이스 플랫폼으로 마이그레이션함으로써 현재 라이선스 비용을 최적화하기로 했습니다. 또한, 데이터베이스를 실행하는 데 Amazon RDS를 사용함으로써 안정성을 보장받고 운영 지원 오버헤드를 낮추기로 했습니다.

데이터베이스 선택
Trimble의 Operations and Database Development 팀은 Oracle의 데이터베이스 플랫폼을 AWS로 마이그레이션할 경우의 복잡성을 평가하도록 도와달라고 AWS 팀에 요청했습니다. 이 평가의 중심에는 AWS Schema Conversion Tool(AWS SCT) 평가 보고서가 있었습니다.

AWS 팀은 AWS SCT를 사용하여 원본 Oracle 데이터베이스와 Amazon Relational Database Service(Amazon RDS) 오픈 소스 데이터베이스 엔진 중 대체 엔진으로 사용할 대상 간의 “차이”를 확인했습니다. 두 번째 요구사항은 기존 ETL 도구(Informatica) 및 보고 제품(Microstrategy)과 협업할 수 있있어야 한다는 것 입니다. 우리는 프로젝트가 타임라인 및 비즈니스 기대를 충족하면서 작업 범위가 갑자기 증가되지 않도록 방지하기 위해서는 이러한 접근 방식이 필요하다고 결정했습니다.

우리는 Trimble이 어떤 데이터베이스를 통해서든  기존의 프런트엔드 솔루션을 계속 사용할 수 있다는 점을 알게되었습니다. 그러나, AWS SCT 평가 결과에 따르면 RDS for PostgreSQL와 Oracle 소스 데이터베이스 사이에 차이점은 매우 작다는 점을 알게 되었기 때문에 RDS for PostgreSQL을 이전 대상 데이터베이스로 선택했습니다. AWS SCT 평가 보고서는 현재 데이터베이스 플랫폼과 RDS for PostgreSQL 간의 기능적 차이를 처리하는 데, 우리가 해야할 작업이 무엇인지 명확히 보여주었습니다. 따라서 그에 맞춰 필요한 리소스 할당을 계획할 수 있었습니다.

평가 보고서를 통해 제3자에게 대량의 마이그레이션 작업에 참여하도록 입찰 요청서(RFP)를 전송하기 위한 기반 및 프레임워크 정보도 얻을 수 있었습니다. 이 정보를 손쉽게 얻음으로서 다른 마이그레이션 활동에 집중할 수 있었습니다. 그 결과, Amazon 파트너인 OpenSCG와 발전적인 파트너 관계를 형성하여 데이터베이스 마이그레이션 활동을 집중했습니다. Trimble은 현재 OpenSCG의 지원 제품 및 교육 프로그램을 통해 그 관계를 계속 유지하고 있습니다.

AWS SCT 평가 보고서는 마이그레이션에 대한 활동의 범위를 이해하는 데 핵심적인 역할을 제공합니다. 대체로 수동 작업이라고 생각하여 특별히 기대하지 않았던 작업들이 매우 간단하게 적용할 수 있게 되어 예상된 타임라인에서 수개월을 단축시켰습니다.

마이그레이션
Trimble은 4곳의 유망한 공급업체에 입찰을 요청했습니다. 입찰을 검토한 후 다른 공급업체의 입찰 내용과 비교했을 때 심층적인 전문 기술 및 지식을 보여준 OpenSCG와 계약을 체결했습니다. 이를 통해 기존에 확인된 기능적 차이를 해결하는 업무를 OpenSCG에 맡겼습니다. OpenSCG는 마이그레이션 스크립트를 작성하여 PostgreSQL 데이터베이스 스키마를 만들고, 소스 데이터베이스에서 대상 데이터베이스로 데이터를 이전했습니다. Trimble에 개발자들은 이러한 작업을 함께 지원했으며 프런트엔드 애플리케이션의 구성 및 검증과 관련된 모든 작업에 대해 책임졌습니다.

전체 프로젝트는 2개의 하위 프로젝트로 나뉘었습니다. 먼저, 북미에서 호스팅된 서비스 마이그레이션에 집중했고 그다음으로 유럽에서 호스팅된 마이그레이션에 진행했습니다. 북미 데이터베이스의 경우 총 크기가 6.5TB였으며 월평균 약 22GB씩 늘고 있었습니다. 유럽 ​​데이터베이스의 경우 크기가 4.6TB였으며, 월 33GB 정도 성장했습니다.

프로젝트 팀은 비공개로 호스팅되고 있던 기존 재해 복구 사이트의 데이터베이스 복제본 세트를 마이그레이션을 위한 소스 데이터베이스로 사용했습니다. 이와 함께 PostgreSQL 데이터베이스 가상 머신(VM) 및 데이터 마이그레이션용 VM을 배포했습니다. 배포한 VM에서 OpenSCG에서 제공한 스키마 및 스크립트를 사용하여 프로덕션 데이터베이스를 대상 PostgreSQL 데이터베이스로 이전했습니다. 마이그레이션이 성공적으로 완료된 후, 추출된 PostgreSQL 데이터베이스 데이터를 AWS Snowball을 사용하여 복사한 후 AWS 데이터센터로 보냈습니다. AWS에서는 내보낸 데이터베이스를 이전을 원하는 클라우드 상의 RDS for PostgreSQL 인스턴스로 가져왔습니다. 이 프로세스를 미국과 유럽에서 각각 두번씩 수행했습니다. 첫 번째는 테스트 데이터를 이전 했으며, 두 번째는 검증 후에 프로덕션 데이터 세트를 생성했습니다.

전환 과정
기존의 ETL 프로세스는 비공개로 호스팅된 라이브 데이터 웨어하우스 솔루션과 프로덕션 전 RDS for PostgreSQL 솔루션 간에 동기화를 유지했습니다. 그 동안 철저한 QA 기간, 기능 및 성능 테스트 그리고 데이터 무결성 검증을 통해 수많은 문제를 파악했습니다. 프로젝트 팀은 예정된 가동 날짜에 앞서 사전에 이러한 문제를 해결했습니다. 가장 중요한 과제는 ETL 프로세스의 성능과 관련이 있었으며, 일부 보고서의 성능 문제와도 결부되었습니다.

하지만, 구현 팀의 실사 결과 문제 없이 유연하게 전환이 이루어졌습니다. 이러한 전환 과정은 ETL 실행과 보고서 실행 사이에 예정된 것이어서 결과적으로 서비스를 이용하는 최종 사용자는 전환이 되었는지 알지 못한 채로 잘 이루어졌습니다.

전환 결과
Trimble의 FSM부서는 그 이후 레거시 데이터 웨어하우스 스택의 사용을 완전히 중지했습니다. 또한, 코로케이션 서비스 사용 역시 완전히 종료하였습니다.

이러한 과정을 통해 데이터 웨어하우스 마이그레이션은 모든 호스팅 솔루션을 AWS로 전환하기 위한 대규모 프로젝트는 3단계로 나누어 진행되었습니다. Trimble은 지금까지 총 두 개의 프로덕션 데이터 웨어하우스 스택, 각 개발 환경 그리고 북미 및 유럽의 레거시 프로덕션 애플리케이션 스택의 마이그레이션을 완료했습니다. 현재 응용프로그램 개발 환경을 마이그레이션하는 최종 단계에 있으며, 이는 연말까지 완료될 것으로 예상됩니다.

비용 예측에 따르면, 본 프로젝트를 통해 Trimble의 직접 인프라 비용은 비공개로 호스팅된 인프라 비용을 사용할 때 보다 1/4이하로 절감할 수 있을 것으로 추정됩니다. 앞으로 추가적으로 AWS 서비스를 사용하는 향후 추가 작업에 대한 계획이 진행 중이어서 운영 오버헤드를 훨씬 더 줄일 수 있을 것으로 기대합니다.

요약
본 프로젝트의 핵심 사항은 다음과 같습니다.

우선 기존에 철저한 실사를 수행함으로써 프로젝트 로드맵을 정의합니다. Trimble은 AWS Schema Conversion Tool을 사용하고 AWS 계정 팀의 조언을 활용했습니다. 이러한 자원들을 통해 프로젝트가 성공적으로 이루어졌습니다.

프로젝트를 보완하기 위해 외부 리소스 및 전문 기술을 사용하시기 바랍니다. 외부 공급업체와 협력하여 내부 팀을 보완하면 프로젝트 완료 시간을 수개월까지 단축할 수 있습니다.

마지막으로 우리가 원하는 최종 이전 완료후 상태를 고려한 후, 실현 가능한 것을 먼저 달성하는 것이 좋습니다. 많은 사람들이 Oracle에서 플랫폼을 마이그레이션하는 것은 매우 어렵기 때문에 달성할 수 없는 목표라고 생각했습니다. 하지만 이러한 걱정은 기우임에 불과했습니다.

이 글은 AWS Database Blog의 How the AWS Schema Conversion Tool Drove Trimble’s Database Migration Successes의 한국어 번역으로 정도현 AWS 테크니컬 트레이너가 감수했습니다.

Source: Trimble의 오라클 DB 마이그레이션 성공기 – AWS Schema Conversion 활용 사례

About KENNETH 19694 Articles
지락문화예술공작단

Be the first to comment

Leave a Reply

Your email address will not be published.


*


이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.