この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
안녕하세요! 올해 4월 클래스메소드에 입사한 김재욱이라고 합니다!
기다리고 기다리던 AWS Summit Online Korea가 이번 주 드디어 개최되었습니다!!
정말 많은 세션 중에서 어떤 것들을 봐야 할까 고민을 하다가, 제 눈에 들어왔던 세션은「Oracle DB를 AWS로 이관하는 방법들」이었습니다. 로컬 환경, 데이터센터에서 어떻게 AWS로 데이터베이스를 마이그레이션 할 수 있을까? 궁금했기 때문에 이 세션을 보고 내용을 정리해봤습니다.
세션 개요
목차
- AWS와 Oracle DB
- Oracle DB 이전을 위한 사전 준비
- Oracle DB 이관 전략
- DB이관을쉽게도와주는AWS도구및서비스
- Oracle DB 이관시 유의 사항
- 기타 유의 사항
- 마지막으로
AWS와 Oracle DB
왜 Oracle DB일까요?
한국 DBMS 시장 점유율을 보면, Oracle 43%, MS 23%, IBM 14%로 각각 1위 2위 3위를 차지하고 있습니다. 빅3 업체인 Oracle, MS, IBM은 전체 시장의 80%의 점유율을 차지하고 있습니다.
여기서 Oracle이 43%로 가장 높은 점유율을 나타내고 있으며, 국내 엔터프라이즈 환경에서의 도입 사용률은 아직도 월등히 높습니다. 즉 가장 사용률이 높은 Oracle DB의 마이그레이션 방법을 알아보고자 합니다.
왜 AWS일까요?
AWS는 전세계 24개의 리전 내에 77개의 가용 영역을 운영하면서 가장 높은 점유율을 보유하고 있습니다. 그렇다면 한국에서는 어떨까요?「2020년 국내 클라우드 서비스별 점유율 TOP5」에서 아마존 AWS가 51%를 차지하면서 압도적인 1위를 달성했습니다. DBMS 업계와 관련한 시장조사기관인 가트너에 따르면,「2023년까지 DB의 75%는 클라우드 플랫폼에 배치될 것이며, 이는 DBMS 시장 지형을 크게 바꿔놓을 것이다.」라고 말 할 정도로, 클라우드 플랫폼의 중요성은 더욱 더 커지고 있습니다.
Oracle DB 이전을 위한 사전 준비
Oracle DB를 이전하기 전에, 단계별로 상세하게 계획을 수립할 필요가 있습니다.
- Assess(소스 DB환경에 대한 분석)
- 인프라환경
- 데이터 양
- 데이터 종류
- 연계 환경
- 요구 조건
- 영향, 리스크
- Plan(데이터 용량, 이관 기간, 다운타임, 실행 난이도 등을 전체적으로 고려하여 계획 수립)
- 이관 전략
- 이관 기술
- 테스트 - 검증 계획
- 이행 계획
- 롤백 계획
- Test(실제 데이터로 테스트 환경에서 이관 테스트를 진행)
- 검증
- 시간 측정
- 튜닝요소 점검
- 2~3회 테스트
- Execute(계획에 맞추어 DB이관 진행)
- 이관 진행
- 상황 모니터링
- 검증 진행
- 시스템 오픈
- 모니터링
- 운영 모드 진입
Oracle DB 이관 전략
이번에는 Oracle DB 이관 전략에 대해 알아보고자 합니다.
6가지 마이그레이션 전략
- 리호스팅(Rehosting) - ‘리프트 앤 시프트(lift-and-shift)’라고도 하는 리호스팅에서는 애플리케이션을 변경 없이 이전 - 기업이 마이그레이션을 구현하고 신속하게 확장하여 비즈니스 사례를 충족하기를 원하는 대규모 레거시 마이그레이션의 시나리오에서는 대부분의 애플리케이션이 리호스팅
- 리플랫포밍(Replatforming) - 리프트 앤 시프트 및 수정(lift, tinker, and shift)이라고도 하는 리플랫포밍에서는 실질적인 이점을 실현하기 위해 몇 가지 클라우드 최적화를 수행
- 리팩터링(Refactoring)/아키텍처 재설계(Re-architecting) - 리팩터링(아키텍처 재설계라고도 함)에서는 클라우드 네이티브 기능을 사용하여 애플리케이션을 설계하고 개발하는 방식을 재구성 - 일반적으로 리팩터링은 비즈니스 요구 사항으로 인해, 다른 방법으로는 기존 환경의 애플리케이션에서 실현하기가 까다로운 기능 추가, 확장 또는 성능 개선의 필요성이 클 때 활용
그 외
- 재구매(Repurchasing) - 재구매에서는 기존 라이선스를 Software-as-a-Service 모델로 전환
- 유지(Retaining) - 유지에서는 비즈니스에 중요한 애플리케이션을 소스 환경에 유지
- 폐기(Retiring) - 폐기는 더 이상 필요하지 않은 애플리케이션을 제거하는 프로세스
DB 이관을 쉽게 도와주는 AWS 도구 및 서비스
이관을 쉽게 도와주는 AWS 도구 및 서비스 3가지를 소개하고자 합니다.
AWS SCT(Schema Conversion Tool)
AWS Schema Conversion Tool(AWS SCT)을 사용하면 소스 데이터베이스 스키마와 대부분의 데이터베이스 코드 객체(보기, 저장된 프로시저, 함수 등)를 대상 데이터베이스와 호환되는 형식으로 자동으로 변환하여 예측 가능할 정도로 이기종 데이터베이스 마이그레이션을 수행
- OS/플랫폼이 서로 다른 환경에서의 스키마 변환이 가능
- 지원하는 모든 DB로의 스키마 변환이 가능
AWS DMS(Database Migration Service)
AWS Database Migration Service는 Oracle에서 Oracle로의 마이그레이션과 같은 동종 마이그레이션뿐 아니라 Oracle 또는 Microsoft SQL Server에서 Amazon Aurora로의 마이그레이션과 같은 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원
AWS Database Migration Service를 사용하면 고가용성으로 데이터를 연속적으로 복제할 수 있으며 Amazon Redshift 및 Amazon S3로 데이터를 스트리밍하여 페타바이트급 규모의 데이터 웨어하우스에 데이터베이스를 통합 가능
- 간편한 사용
- 최소한의 가동 중단
- 널리 사용되는 데이터베이스 모두 지원
- 저렴한 비용
- 지속적 복제
- 안정성
AWS Snowball Edge
단기간 내 초대용량 규모의 데이터 전송을 가능할 수 있게 해주는 서비스
AWS Snowball Edge는 일부 AWS 기능을 위한 온보드 스토리지 및 컴퓨팅 파워를 갖춘 Snowball 디바이스의 한 유형, Snowball Edge는 로컬 환경과 AWS 클라우드 간에 데이터를 전송하는 것 외에도 로컬 처리 및 엣지 컴퓨팅 워크로드를 수행
- 디바이스의 대용량 스토리지 용량 또는 컴퓨팅 기능. 이는 작업을 생성할 때 선택하는 옵션에 따라 다름
- 전송 속도가 최대 100GB/s인 네트워크 어댑터
- 암호화가 적용되어 유휴 데이터와 물리적으로 전송 중인 데이터를 보호
- 로컬 환경과 간에 데이터를 가져오거나 내보낼 수 있으며Amazon S3, 인터넷을 사용하지 않고 하나 이상의 디바이스를 사용하여 데이터를 물리적으로 전송 가능
- Snowball 엣지 디바이스는 고유한 견고한 상자입니다. 디바이스가 배송 준비가 되면 기본 제공 E Ink 디스플레이가 변경되어 배송 라벨을 표시
Oracle DB 이관시 유의 사항
Oracle Rac 경우
Oracle RAC(Real Applications Cluster)은 여러 Oracle DB 서버들을 하나의 클러스터로 모두 Active 상태로 운영 가능하게 해주는 고가용성 옵션 기능
- 분산구조 DB Scale-Out이 비교적 쉽게 가능
- 노드들이 모두 Active 상태로 특정 노드 장애시 다른 노드의 빠른 Take-over이 가능
Oracle RAC 대안 1
Oracle RAC을 이전하는 경우 가장 쉽게 고려할 수 있는 안은 Active-Standby로 재구성하는 안
- 비교적 Application의 수정이 크지 않다
- DB의 수정은 거의 없으며 기존 사용하던 Oracle의 기능들을 그대로 사용 가능
- RAC 대비 아키텍쳐 및 운영이 단순해지며 쉬워짐
- RAC 옵션이 필요 없어지면서 비용이 절감
Oracle RAC 대안 2
Oracle DB 는 유지하는 아키텍처 수정 범위내에서 단순 Active-Standby 구조에 비해 읽기 업무에 대한 확장성을 추가로 가져가는 안
- 타 DB 로의 교체 경우에 비해 Application 의 수 정이 크지 않음
- 기존 사용하던 Oracle 의 기능들을 그대로 사용 가능
- Read DB 의 Scale-Out 이 가능
- Active Data Guard 비용은 RAC 대비 저렴하여 비용이 절감
Oracle RAC 대안 ３
Re-architect 전략으로 완전히 새로운 아키텍처 로 처음부터 다시 구성하는 안
- Re-architect 전략 선택시 장점들(최적화, 확장성, 유연성, 효율)을 고스란히 다 가지고 옴
- 여러가지 조건들 (크지 않은 데이터, 충분한 시간 등) 이 맞을 경우 충분히 진행해 볼 가치는 있음
기타 유의 사항
- 이전할 데이터 크기와 사용하게 될 네트워크 대욕폭에 유의
- 보유하고 있는 Oracle 라이센스의 종류와 수량 그리고 전환 형태를 파악
- 이관 기술에 대한 튜닝 포인트를 파악
- 데이터 개인정보가 있을 경우 보안 방침에 대해 충분히 사전 준비
- 3rd party SW가 있을 경우 호환성/기능성을 충분히 테스트/ 검증
마지막으로
로컬 환경에서 클라우드로 마이그레이션 할 수 있는 방법이 다양하게 존재 한다는걸 알게 되어서 좋았습니다. 아직 잘 모르는 AWS 서비스가 많이 있기 때문에 배워나가는 즐거움이 있는 것 같습니다. 앞으로도 자주 이러한 컨퍼런스에 참여해서 AWS 서비스에 대해서 많이 배워나가고 싶습니다.
0
