[Oracle] 온프레미스에서 AWS 마이그레이션 1. 준비

IT서비스의 클라우드 전환은 피할 수 없는 흐름이다.

 

2027년까지 클라우드 마이그레이션 시장 규모는 연 평균 약 28.9%의 성장이 전망된다. 

[CLOUD MIGRATION MARKET - GROWTH, TRENDS, COVID-19 IMPACT, AND FORECASTS (2022 - 2027)]

https://www.mordorintelligence.com/industry-reports/cloud-migration-services-market

 

 

경영자는 빠른 확장성과 고가용성을 가지면서도 비용을 아낄 수 있고,

세계 어느지역에서도 자신의 의도가 수시로 반영될 수 있는 IT서비스를 원한다. 

 

즉, CSP 업체의 강력한 인프라 위에서 서비스를 제공하고 싶어한다. 

 

 

WAS는 인스턴스의 개수를 늘렸을때 L4 또는 L7 단계에서 효과적인 로드밸런싱이 가능하고, 

대용량 파일의 I/O만 없다면 Scale In/Out, Up/Down 효과를 온전히 누릴 수 있다. 

 

 

하지만, DB는 조금 사정이 다르다. 

Scale Up/Down의 효과는 확실하지만, Scale In/Out 의 효과는 제한적이다.

 

MariaDB의 경우 

1) 1개의 Master(Read/Write 가능) 노드와 여러개의 Slave(Read 가능) 노드를 구성할 수 있지만, 

    DML이 많은 상황에서 Master 노드의 부하가 병목을 유발할 수 있다.

   (구성 예시 : https://subbak2.tistory.com/106 )

 

2) 여러개의 Master(Read/Write 가능) 노드를 구성할 경우 

   노드간 Group communication으로 인한 성능 이슈가 발생할 수 있고, 

   모든 노드가 동일한 데이터를 보유함으로 인한 저장 공간의 낭비도 무시할 수 없다. 

 

OracleDB의 경우 

온프레미스에서는 RAC로 여러 인스턴스에서 Read/Write를 수행하면서도 공유 스토리지를 통해 

MariaDB 대비 성능과 스토리지를 효율적으로 확보할 수 있지만, 

 

가장 큰 CSP업체인 AWS에서 제공하는 Oracle DB는 RAC를 지원하지 않는다.

아마도 Oracle이 자사의 Cloud 서비스인 OCI를 판매하기 위해 차이를 둔 것으로 추측한다.

 

Architect와 DevOps 조직은 시장 점유율이 높고 우수한 서비스를 제공 중인 

AWS로 가고 싶어하는데 성능이 중요한 OLTP DB를 운영하는 DBA 입장에서는 난감하다.

어쨋든 해야한다면 준비해야한다. 

 

 

Amazon RDS for Oracle 의 특징과 대응방안에 대해 준비해보려고 한다. 

 

1. RAC가 안된다

오라클 DBMS를 사용하는 가장 큰 이유 중에 하나가 RAC로 인한 고가용성인데 

Amazon RDS는 RAC는 지원하지 않고, 고가용성을 위해 다중AZ를 사용하라고 권장한다.

 

이때, Active 상태가 아닌 인스턴스는 Standby 인스턴스로 장애로 인한 DR로써는 기능할 수 있으나, 

결론적으로 단일 인스턴스로 서비스를 제공해야한다. 

 

→ 결국 하나의 인스턴스에서 Scale Up을 통해 성능을 확보해야한다.

 

 

2. 최대 자원용량의 한계

'22년 10월 6일 현재. 선택 가능한 최대 자원이다. 

 

Cpu는 최대 128 core인데 일반적인 규모에서는 문제가 되지 않겠지만, 대규모 B2C 서비스라면 문제가 될 수 있다.

운영 중인 DB 중 이 규모를 넘는 DB가 있어, 어쩔 수 없이 Hybrid 아키텍처를 구성해야하는 경우가 생길수도 있을 것 같다.

 

메모리의 경우 일반적으로 문제가 되진 않을 것 같다. 

이 이상의 메모리를 필요로 한다면 OLTP DB라기보단 OLAP DB일 것 같고, 여러개의 노드를 통해 데이터를 분석해도 문제되진 않아 보인다.

 

네트워크는 최대 40,000Mbps로 일반적인 상황에서는 문제가 안 될 것으로 보인다.

 

 

스토리지의 장점은 IOPS 조정이 가능하다는 점 같다. 

DB 특성에 맞게 IOPS를 조정한다면 비용 효율적인 운영이 가능해보인다.

 

다만, 최대 용량이 64TB인 점 역시 시스템에 따라 문제가 발생할 수 있을 것 같다.

대부분의 경우 문제되진 않겠지만 규모가 큰 경우 S3에 파일로 백업 등의 방법으로 방안을 모색해야할 것 같다.

 

 

3. CDC가 안된다.

오라클 DB의 경우 OGG라는 이름의 강력한 CDC 솔루션을 통해 다양하게 활용할 수 있다.

https://subbak2.tistory.com/93

[Oracle] OGG란? CDC솔루션 쓰는 이유

 

하지만, Amazon RDS for Oracle은 CDC를 지원하지 않고, AWS Database Migration Service를 통해 데이터를 실시간 복제해야한다. 

 

이 역시 OCI에서 정책적으로 막은 것 같은 느낌이 들고, 

원래 AWS DMS의 용도는 하이브리드 아키텍처에서의 데이터 복제에 조금 더 특화되어 보인다.

 

즉, Amazon RDS 데이터 끼리 복제도 가능하지만, OGG보다 성능 부분의 단점이 있을 수 있어 보인다. 

 

 

간단하게 살펴봤을때 아래 4가지 제약사항이 보이는데 

 

1) Failover 발생시 장애 시간 증가   (RAC 노드간 전환 vs 액티브-스탠바이 전환)

2) CPU 최대 128코어로 대규모 서비스의 경우 다소 제한적 

    (Ex> 직원의 Parallel 힌트 실수시 - RAC의 경우 단일 노드 지연 vs 전체 DB 지연)

3) 스토리지 최대용량 한계로 인한 효율화 중요성

    ( DBA 역할이 더 중요할 수도 있어 보인다 - Reorg, Index Rebuild, 압축 적용 / S3 파일 보관 등)

4) CDC 솔루션 적용 불가로 실시간 동기화에서 약간의 성능제약 발생 가능 

    ( 다른 시스템 DB간 데이터 사용시 AWS DMS보다 API 통신이 더 효율적일 수 있을 것 같음)

 

결론적으로 내가 경영자라면 비즈니스 특성에 따라 아주 괜찮은 선택으로 보인다. 

웹 어플리케이션에서의 장점이 명확하고 ( 빠른 확장성, 고가용성, 비용 효율성, 글로벌 진출 등), 

IT인력을 채용하는 관점에서도 다소 레거시해보이는 온프레미스 서버보다 AWS 서버를 사용하는게

장점으로 작용할 수 있기 때문이다.

 

 

 

* 참고자료 : 

https://www.mordorintelligence.com/industry-reports/cloud-migration-services-market

Cloud Migration Market Size, Analysis, Share (2022 - 27)

https://www.samsungsds.com/kr/insights/cloud_migration.html

디지털 전환의 시작, 클라우드 마이그레이션 - 1 성장하는 시장

https://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Oracle.ToRDSOracle.html

Oracle에서 Amazon RDS for Oracle로 변환 - AWS Schema Conversion Tool

https://education.oracle.com/migrating-rac-database-to-oracle-cloud-infrastructure/courP_47058769

Migrating RAC Database to Oracle Cloud Infrastructure

https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/Welcome.html

AWS Database Migration Service란 무엇입니까? - AWS Database Migration Service