지난 20년간 기업 소프트웨어 개발의 변화
지난 20년간 기업 소프트웨어 개발 분야를 지켜본 결과, 데이터베이스를 클라우드로 이전하는 추세가 두드러지게 나타났습니다.
저는 기존의 온프레미스 데이터베이스를 Amazon Web Services(AWS) 클라우드 데이터베이스로 옮기는 여러 마이그레이션 프로젝트에 참여한 경험이 있습니다. AWS 설명서에는 이 작업이 매우 간단해 보이지만, 실제로는 계획 실행이 쉽지 않고 실패할 가능성도 있다는 점을 알아두어야 합니다.
이 글에서는 다음과 같은 다양한 상황에서의 실제 경험을 다룰 것입니다.
- 소스: 이론적으로는 소스가 중요하지 않지만 (대부분의 주요 데이터베이스에 유사한 접근 방식을 적용할 수 있습니다), Oracle은 오랫동안 대기업에서 가장 선호하는 데이터베이스 시스템이었습니다. 따라서 Oracle을 중심으로 논의를 진행할 것입니다.
- 대상: AWS에서 대상 데이터베이스를 선택할 수 있으며, 어떤 데이터베이스를 선택하든 접근 방식은 여전히 유효합니다.
- 모드: 전체 새로 고침 또는 증분 새로 고침을 선택할 수 있습니다. 배치 데이터 로드(소스 및 대상 상태 간에 지연이 있음) 또는 실시간 데이터 로드를 선택할 수 있습니다. 이 두 가지 모드를 모두 다룰 것입니다.
- 빈도: 일회성 마이그레이션을 통해 클라우드로 완전히 전환하거나, 전환 기간 동안 온프레미스와 AWS 간에 데이터를 동시에 최신 상태로 유지해야 할 수 있습니다. 후자의 경우, 온프레미스와 AWS 간의 일일 데이터 동기화를 개발해야 합니다. 전자는 더 간단하고 합리적이지만, 후자는 더 많이 요구되고 문제 발생 지점이 훨씬 많습니다. 이 글에서는 두 가지 경우를 모두 살펴볼 것입니다.
문제 정의
요구 사항은 종종 간단합니다.
AWS 내에서 서비스를 개발하고 싶으니, 모든 데이터를 “ABC” 데이터베이스에 복사해 주세요. 빠르고 간단하게요. 그리고 나서 AWS 내부의 데이터를 활용해야 합니다. 이후에 DB 디자인의 어떤 부분을 변경해야 할지 알아볼 것입니다.
하지만 시작하기 전에 몇 가지 고려해야 할 사항이 있습니다.
- “일단 있는 그대로 복사하고 나중에 처리하자”는 생각으로 너무 빨리 넘어가서는 안 됩니다. 물론 이것이 가장 쉬운 방법이고 빠르게 완료할 수 있지만, 대부분의 새로운 클라우드 플랫폼에서 심각한 구조 조정 없이는 나중에 수정할 수 없는 근본적인 아키텍처 문제가 발생할 가능성이 있습니다. 클라우드 환경은 온프레미스 환경과 완전히 다릅니다. 시간이 지남에 따라 새로운 서비스가 도입될 것이고, 사람들은 자연스럽게 동일한 데이터를 다른 방식으로 사용하기 시작할 것입니다. 클라우드에서 온프레미스 상태를 1:1로 복제하는 것은 거의 좋은 생각이 아닙니다. 특수한 경우에는 해당될 수도 있지만, 다시 한번 확인해 보시기 바랍니다.
- 다음과 같은 몇 가지 중요한 질문으로 요구 사항에 의문을 제기해 보세요.
- 새로운 플랫폼의 주요 사용자는 누구입니까? 온프레미스에서는 트랜잭션 비즈니스 사용자일 수 있지만, 클라우드에서는 데이터 과학자, 데이터 웨어하우스 분석가, 서비스(예: Databricks, Glue, 머신 러닝 모델)일 수도 있습니다.
- 클라우드로 전환한 후에도 기존의 일상 업무가 유지될 것으로 예상됩니까? 그렇지 않다면 어떻게 변화할 것으로 예상됩니까?
- 시간이 지남에 따라 데이터가 크게 증가할 계획입니까? 클라우드로 마이그레이션하는 가장 중요한 이유 중 하나이기 때문에 대답은 ‘예’일 가능성이 큽니다. 새로운 데이터 모델이 필요할 것입니다.
- 최종 사용자는 새로운 데이터베이스를 통해 얻을 수 있는 일반적이고 예상되는 쿼리에 대해 생각해볼 것입니다. 이를 통해 기존 데이터 모델을 얼마나 변경해야 성능을 유지할 수 있는지 정의할 수 있습니다.
마이그레이션 준비
대상 데이터베이스가 선택되고 데이터 모델에 대한 논의가 충분히 이루어졌다면, 다음 단계는 AWS Schema Conversion Tool을 익히는 것입니다. 이 도구는 다음과 같은 여러 영역에서 유용합니다.
- 소스 데이터 모델을 분석하고 추출합니다. SCT는 현재 온프레미스 데이터베이스의 내용을 읽고 초기 소스 데이터 모델을 생성합니다.
- 대상 데이터베이스를 기반으로 대상 데이터 모델 구조를 제안합니다.
- 대상 데이터 모델을 설정하기 위한 대상 데이터베이스 배포 스크립트를 생성합니다(도구가 원본 데이터베이스에서 찾은 내용을 기반으로 함). 이렇게 하면 배포 스크립트가 생성되며, 스크립트 실행 후 클라우드 내 데이터베이스는 온프레미스 데이터베이스에서 데이터를 로드할 준비를 마칩니다.
참조: AWS 설명서
Schema Conversion Tool 사용에 대한 몇 가지 팁을 드리겠습니다.
첫째, 생성된 결과물을 그대로 사용하는 경우는 거의 없어야 합니다. 이는 데이터의 이해, 목적, 클라우드에서 데이터가 사용되는 방식에 따라 조정이 필요한 참조 결과와 비슷하다고 생각해야 합니다.
둘째, 이전에는 특정 데이터 영역에서 빠른 결과를 원하던 사용자가 테이블을 선택했을 수 있습니다. 하지만 이제는 분석 목적으로 데이터를 선택할 수 있습니다. 예를 들어, 이전에 온프레미스 데이터베이스에서 유용했던 데이터베이스 인덱스는 이제 불필요하며, 새로운 사용 방식과 관련된 DB 시스템의 성능을 향상시키지 못합니다. 또한 소스 시스템과 마찬가지로 타겟 시스템에서 데이터를 분할하는 방식도 다를 수 있습니다.
또한 마이그레이션 프로세스 중에 일부 데이터 변환을 수행하는 것을 고려해 보는 것이 좋습니다. 이는 기본적으로 일부 테이블의 대상 데이터 모델을 변경하는 것을 의미합니다(더 이상 1:1 복사본이 아님). 나중에 변환 규칙을 마이그레이션 도구에 구현해야 합니다.
원본 및 대상 데이터베이스가 동일한 유형인 경우(예: 온프레미스 Oracle과 AWS의 Oracle, PostgreSQL과 Aurora PostgreSQL 등), 특정 데이터베이스가 기본적으로 지원하는 전용 마이그레이션 도구(예: 데이터 펌프 내보내기 및 가져오기, Oracle Goldengate 등)를 사용하는 것이 가장 좋습니다.
그러나 대부분의 경우 원본 데이터베이스와 대상 데이터베이스는 호환되지 않으므로, AWS Database Migration Service가 유용한 대안이 될 수 있습니다.
참조: AWS 설명서
AWS DMS는 기본적으로 다음과 같은 테이블 수준의 작업 목록을 구성할 수 있습니다.
- 연결할 정확한 소스 DB와 테이블은 무엇입니까?
- 대상 테이블에 데이터를 가져오는 데 사용할 명령문 사양은 무엇입니까?
- 소스 데이터가 대상 테이블 데이터에 매핑되는 방식을 정의하는 변환 도구(있는 경우)(1:1이 아닌 경우)는 무엇입니까?
- 데이터를 로드할 정확한 대상 데이터베이스 및 테이블은 무엇입니까?
DMS 작업 구성은 JSON과 같은 사용자 친화적인 형식으로 수행됩니다.
가장 간단한 시나리오에서는 대상 데이터베이스에서 배포 스크립트를 실행하고 DMS 작업을 시작하기만 하면 됩니다. 하지만 실제로는 더 많은 고려 사항이 있습니다.
일회성 전체 데이터 마이그레이션
가장 간단한 경우는 전체 데이터베이스를 대상 클라우드 데이터베이스로 한 번에 이동하는 경우입니다. 이 경우 기본적으로 필요한 모든 작업은 다음과 같습니다.
- 각 소스 테이블에 대한 DMS 작업을 정의합니다.
- DMS 작업 구성을 올바르게 지정해야 합니다. 즉, 적절한 병렬 처리, 캐싱 변수, DMS 서버 구성, DMS 클러스터 크기 조정 등을 설정해야 합니다. 이는 최적의 구성을 찾기 위해 광범위한 테스트와 미세 조정이 필요하므로 일반적으로 가장 시간이 많이 걸리는 단계입니다.
- 각 대상 테이블이 예상 테이블 구조로 대상 데이터베이스에 생성되었는지(비어 있는지) 확인합니다.
- 데이터 마이그레이션을 실행할 기간을 예약합니다. 마이그레이션을 시작하기 전에 성능 테스트를 수행하여 마이그레이션을 완료하는 데 시간이 충분한지 확인해야 합니다. 마이그레이션 중에는 소스 데이터베이스의 성능이 제한될 수 있습니다. 또한 마이그레이션이 실행되는 동안 원본 데이터베이스가 변경되지 않도록 해야 합니다. 그렇지 않으면 마이그레이션 후 데이터가 원본 데이터와 다를 수 있습니다.
DMS 구성이 제대로 완료되면 이 시나리오에서 큰 문제가 발생하지 않습니다. 모든 소스 테이블이 선택되어 AWS 대상 데이터베이스로 복사됩니다. 중요한 점은 작업 성능을 확인하고 저장 공간 부족으로 인해 실패하지 않도록 모든 단계에서 크기 조정이 올바른지 확인하는 것입니다.
증분 일일 동기화
여기서부터 일이 복잡해지기 시작합니다. 물론 세상이 이상적이라면 모든 것이 잘 작동하겠지만, 현실은 그렇지 않습니다.
DMS는 두 가지 모드로 작동하도록 구성할 수 있습니다.
- 전체 로드: 위에서 설명하고 사용한 기본 모드입니다. DMS 작업은 사용자가 시작하거나 시작하도록 예약될 때 실행됩니다. 완료되면 DMS 작업이 종료됩니다.
- CDC(변경 데이터 캡처): 이 모드에서는 DMS 작업이 계속 실행됩니다. DMS는 소스 데이터베이스에서 테이블 수준의 변경 사항을 감지합니다. 변경 사항이 발생하면 변경된 테이블과 관련된 DMS 작업 구성에 따라 대상 데이터베이스에 변경 사항을 즉시 복제하려고 시도합니다.
CDC를 사용할 때는 CDC가 원본 DB에서 델타 변경 사항을 추출하는 방법을 선택해야 합니다.
#1. Oracle Redo 로그 판독기
한 가지 옵션은 Oracle의 기본 데이터베이스 다시 실행 로그 판독기를 선택하는 것입니다. CDC는 이 판독기를 활용하여 변경된 데이터를 가져오고 최신 변경 사항을 기반으로 대상 데이터베이스에 동일한 변경 사항을 복제할 수 있습니다.
Oracle을 소스로 사용하는 경우 이것이 당연한 선택처럼 보일 수 있지만 문제가 있습니다. Oracle redo 로그 판독기는 소스 Oracle 클러스터를 사용하므로 데이터베이스에서 실행 중인 다른 모든 작업에 직접적인 영향을 미칩니다. (실제로 활성 세션을 직접 생성합니다.)
구성한 DMS 작업이 많을수록(또는 병렬로 연결된 DMS 클러스터가 많을수록) Oracle 클러스터를 더 크게 확장해야 합니다. 기본적으로 기본 Oracle 데이터베이스 클러스터의 수직 확장을 조정해야 합니다. 이것은 분명히 솔루션의 총 비용에 영향을 미치며, 일일 동기화가 장기적인 프로젝트로 진행될수록 더욱 그렇습니다.
#2. AWS DMS 로그 마이너
위의 옵션과 달리 이것은 동일한 문제에 대한 기본 AWS 솔루션입니다. 이 경우 DMS는 원본 Oracle DB에 영향을 주지 않습니다. 대신 Oracle redo 로그를 DMS 클러스터에 복사하고 그곳에서 모든 처리를 수행합니다. Oracle 리소스를 절약하지만 더 많은 작업이 필요하므로 더 느린 솔루션입니다. 또한 쉽게 짐작할 수 있듯이, Oracle redo 로그에 대한 사용자 지정 판독기는 Oracle의 기본 판독기보다 속도가 느릴 수 있습니다.
원본 데이터베이스의 크기와 일일 변경 횟수에 따라 최상의 시나리오에서는 온프레미스 Oracle 데이터베이스에서 AWS 클라우드 데이터베이스로 데이터를 거의 실시간으로 증분 동기화할 수 있습니다.
다른 시나리오에서는 여전히 거의 실시간 동기화가 가능하지 않을 수 있지만, 소스 및 대상 클러스터 성능 구성, 병렬 처리, DMS 작업의 양, CDC 인스턴스 간의 배포를 조정하여 개선할 수 있습니다.
또한 CDC에서 지원하는 소스 테이블 변경(예: 열 추가)을 알아두는 것이 좋습니다. 모든 변경 사항이 지원되는 것은 아니기 때문입니다. 경우에 따라 유일한 방법은 대상 테이블을 수동으로 변경하고 CDC 작업을 처음부터 다시 시작하는 것입니다. (이 과정에서 대상 데이터베이스의 모든 기존 데이터가 손실될 수 있습니다.)
문제가 발생할 때
저는 힘든 경험을 통해 배웠지만, 일일 복제의 목표를 달성하기 어려운 DMS와 관련된 특정 시나리오가 하나 있습니다.
DMS는 정의된 속도로만 리두 로그를 처리할 수 있습니다. 작업을 실행하는 DMS 인스턴스가 많다고 해서 달라지는 것은 없습니다. 각 DMS 인스턴스는 여전히 정의된 단일 속도로만 리두 로그를 읽고, 각 인스턴스는 전체 로그를 읽어야 합니다. Oracle redo 로그를 사용하든 AWS 로그 마이너를 사용하든 마찬가지입니다. 둘 다 이 제한 사항이 있습니다.
Oracle redo 로그가 매일 엄청나게 커지는 경우 (예: 500GB 이상), 소스 데이터베이스에 많은 변경 사항이 발생하면 CDC는 제대로 작동하지 않습니다. 하루가 끝나기 전에 복제가 완료되지 않습니다. 다음 날에는 처리되지 않은 작업이 누적되어 복제해야 할 새로운 변경 사항이 기다리고 있을 것입니다. 처리되지 않은 데이터의 양은 매일 증가합니다.
이 특별한 경우에는 CDC가 옵션이 아니었습니다(수많은 성능 테스트와 시도 후). 현재 날짜의 모든 델타 변경 사항이 같은 날에 복제되도록 하는 유일한 방법은 다음과 같이 접근하는 것이었습니다.
- 자주 사용하지 않는 매우 큰 테이블을 분리하고 일주일에 한 번만 복제합니다 (예: 주말).
- 크지는 않지만 여전히 큰 테이블의 복제를 여러 DMS 작업으로 분할합니다. 하나의 테이블을 10개 이상의 분리된 DMS 작업으로 병렬 마이그레이션하여 DMS 작업 간에 데이터를 분할하고 (이 과정에서 사용자 지정 코딩이 필요함) 매일 실행합니다.
- DMS 인스턴스를 추가하고 (이 경우 최대 4개) DMS 작업을 이들 간에 균등하게 분할합니다. 이는 테이블 수뿐만 아니라 테이블 크기도 고려해야 합니다.
기본적으로 DMS의 전체 로드 모드를 사용하여 일일 데이터를 복제했습니다. 이것이 당일 데이터 복제 완료를 달성하는 유일한 방법이었기 때문입니다.
완벽한 솔루션은 아니지만, 여전히 유효하며 여러 해가 지난 지금도 같은 방식으로 작동합니다. 결국 그렇게 나쁜 해결책은 아닐 수도 있습니다. 😃