기술 마이그레이션 전략에 대한 전체 가이드: (3부 – 데이터베이스 마이그레이션)

게시 됨: 2020-12-25

새 아파트를 구입하고 이사할 준비가 되어 있고 신중하게 절차를 계획한 시나리오를 상상해 보십시오. 새 집으로 이사할 준비가 모두 되어 있는데 갑자기 문제가 있음을 깨닫게 됩니다. 가구와 공예품은 새 아파트와 잘 어울리지 않습니다.

모든 가구를 버리고 처음부터 다시 시작해야 한다면 어떤 기분이 들까요? 이 비유에서 더 나아가 새 아파트를 새 데이터베이스로, 가구를 데이터로 간주합니다. 데이터는 귀하의 비즈니스에 가구보다 훨씬 더 중요하므로 마이그레이션을 계획하는 동안 데이터의 모든 부분을 유지하기를 원할 것입니다.

기술 마이그레이션 시리즈의 후속편으로 이 블로그에서는 데이터베이스 마이그레이션(DBM)의 기본 사항, 데이터베이스 마이그레이션을 수행하는 동안 이해하고, 고려하고, 주의해야 할 사항에 대해 알아보겠습니다.

데이터베이스 마이그레이션이 필요한 이유와 시기는?

이전 애플리케이션 마이그레이션 블로그의 후속 조치로, 오늘의 내용은 데이터베이스 마이그레이션(스키마 마이그레이션이라고도 함)에 중점을 둡니다. 데이터베이스 마이그레이션은 주로 한 데이터베이스 프레임워크에서 데이터를 선택, 추출, 전송/업데이트하는 것을 다루는 가장 중요한 마이그레이션 중 하나이기 때문입니다. 또 다른.

기본적으로 데이터베이스 마이그레이션의 필요성은 비즈니스 요구 사항에 따라 다르거나 다양한 규제 기관에서 제정한 최신 여러 규제 정책을 충족하기 위한 것일 수도 있습니다. DBM이 필요한 정의된 상황은 없지만 피할 수 없는 몇 가지 상황을 나열했습니다.

일반적인 이유는 오래된 시스템을 비즈니스 요구 사항과 최신 데이터 요구 사항을 충족하는 시스템으로 옮기는 것입니다. 새롭고 현대적인 스토리지 기술은 빅 데이터 시대에 필수가 되었습니다.
특정 규제 기관에서는 데이터가 특정 지역에만 있어야 하는 것을 의무화했습니다. 따라서 분산된 데이터를 단일 위치로 마이그레이션해야 합니다.
일부 회사는 온프레미스 데이터베이스를 클라우드 데이터베이스로 이동하는 것을 선호합니다. 이렇게 하면 일반적으로 데이터를 지원하고 시스템을 더 빠르게 만드는 데 필요한 인프라와 전문 지식 리소스를 절약할 수 있습니다.
새 플랫폼으로 마이그레이션하면 포괄적인 데이터 무결성이 보장됩니다. 스토리지 및 미디어 비용을 줄여 ROI를 크게 향상시킵니다.
많은 현대 기업은 모든 데이터를 한 곳에 보관하기를 원합니다. 이렇게 하면 회사의 모든 부서에서 데이터에 액세스할 수 있습니다.

데이터베이스 시스템을 새로운 플랫폼으로 마이그레이션하면 일상적인 비즈니스 운영에 발생하는 중단이 줄어듭니다. 새 데이터베이스 플랫폼을 현명하게 선택하면 최소한의 수작업으로 이 작업을 수행할 수 있습니다.

데이터베이스 유형

데이터베이스 마이그레이션을 진행하기 전에 먼저 다양한 유형의 데이터베이스를 살펴보겠습니다.

관계형 데이터베이스 – 관계형 데이터베이스는 데이터베이스 산업의 핵심으로 알려져 있습니다. 이러한 데이터베이스는 테이블 집합으로 분류됩니다. 테이블은 행에 데이터 인스턴스가 포함되고 열에 특정 범주에 대한 데이터 항목이 포함되는 행과 열로 구성됩니다. SQL – Structured Query Language는 관계형 데이터베이스의 표준 프로그래밍 인터페이스입니다.
분산 데이터베이스 – 이름에서 알 수 있듯이 데이터는 모든 조직의 다양한 사이트에 분산되어 있습니다. 통신 링크는 사이트를 서로 연결하는 데 사용됩니다. 이렇게 하면 분산 데이터베이스에 쉽게 액세스할 수 있습니다.
객체 지향 데이터베이스 – 이 유형의 데이터베이스는 관계형 데이터베이스와 객체 지향 프로그래밍의 속성을 병합합니다. C++ 및 Java로 작성된 다양한 항목을 관계형 데이터베이스에 저장할 수 있지만 객체 지향 데이터베이스가 더 적합합니다.
NoSQL 데이터베이스 – NoSQL 데이터베이스는 여러 가상 서버에 저장된 대규모 비정형 데이터를 효율적으로 분석할 수 있습니다. 대조적으로 관계형 데이터베이스는 일부 빅데이터 성능을 효율적으로 처리할 수 없습니다. NoSQL 데이터베이스는 이러한 경우를 쉽게 관리할 수 있으며 대규모 분산 데이터 집합에 사용됩니다.
클라우드 데이터베이스 – 클라우드 데이터베이스는 사용량에 따라 지불할 수 있는 유연성을 제공하는 가상 환경입니다. 사용자는 요구 사항에 맞는 대역폭과 저장 용량에 대해서만 비용을 지불하면 됩니다.
그래프 데이터베이스 – 간단히 말해서 그래프는 노드와 에지의 모음입니다. 그래프 데이터베이스에는 엔터티를 나타내는 노드가 포함되어 있고 에지는 해당 엔터티 간의 관계를 설명합니다. NoSQL 데이터베이스 유형이며 그래프 이론을 사용하여 관계를 매핑, 저장 및 쿼리합니다.
중앙 집중식 데이터베이스 – 이 유형의 데이터베이스를 사용하면 데이터가 단일 중앙 위치에 저장됩니다. 데이터베이스에는 기본적으로 사용자가 원격 위치에서도 DB에 액세스할 수 있도록 하는 응용 절차가 포함되어 있습니다.

데이터베이스 마이그레이션 접근 방식

한 데이터베이스 플랫폼에서 다른 데이터베이스 플랫폼으로 데이터를 마이그레이션하는 것은 중요한 작업이 될 수 있습니다. 마이그레이션이 라이브 환경에서 계획된 경우 마이그레이션은 최대한 주의해서 수행해야 합니다. 데이터 마이그레이션을 진행하기 전에 편리한 마이그레이션 시간을 선택해야 합니다. 라이브 시스템은 데이터가 새 데이터베이스로 전송될 때 종종 다운타임을 경험합니다.
데이터베이스 마이그레이션에는 주로 두 가지 접근 방식이 있습니다.

빅뱅 데이터 마이그레이션:

이 접근 방식은 제한된 시간 내에 전체 데이터베이스를 한 번에 마이그레이션하도록 선택하는 방법입니다. 빅뱅 데이터 마이그레이션은 덜 복잡해 보이지만 라이브 웹사이트에 충분한 다운타임이 필요합니다. 또한 이 접근 방식을 사용하면 마이그레이션이 실패하는 경우 마이그레이션 프로세스의 완전한 롤백을 달성하기가 쉽지 않을 수 있습니다.

트리클 데이터 마이그레이션

이 접근 방식을 사용하면 마이그레이션 프로세스를 더 작은 청크 또는 단계로 분할해야 합니다. 마이그레이션에 대한 애자일 접근 방식과 거의 유사하게 단일 단계가 실패하면 해당 단계만 롤백하고 프로세스를 반복하면 됩니다. 그러나 Trickle 데이터 마이그레이션은 시간이 많이 소요되므로 프로젝트 비용이 증가할 수 있습니다.

다양한 마이그레이션 유형

관계형 DB에서 관계형 DB로

이 접근 방식은 가장 직접적인 마이그레이션입니다. 이러한 유형의 마이그레이션을 거의 100% 효과적으로 수행할 수 있는 도구가 많이 있습니다.

관계형 DB에서 비관계형 DB로 및 그 반대로

이 마이그레이션은 앞서 언급한 마이그레이션에 비해 더 어렵습니다. Relational DB와 Non-Relational DB는 근본적으로 다르기 때문에 마이그레이션이 100% 효율적이지 않을 수 있습니다. 기본적으로 비관계형 DB로 마이그레이션한다는 것은 데이터베이스의 확장성을 보장하는 ACID 속성(원자, 일관성, 격리 및 내구성)을 희생한다는 의미입니다.
그러나 관계형 DB에서 비관계형 DB로의 데이터베이스 마이그레이션을 지원하는 여러 무료 도구가 있습니다. 이러한 도구는 시스템의 스키마 구조를 지원하지 않고 대부분 시스템 요구 사항을 적용하기에는 너무 엄격해 보이기 때문에 사용하는 것은 널리 권장되지 않습니다.

우리가 고려할 수 있는 이러한 유형의 마이그레이션에 대해 렌더링할 수 있는 몇 가지 기본 변환 팁이 있지만(편의를 위해 MySQL을 관계형 데이터베이스로, MongoDB를 비관계형 데이터베이스로 간주하겠습니다)

mysql-string-data-type-to-string-in-mongodb 변환

MongoDB에서 MySQL 문자열 데이터 유형을 문자열로 변환합니다. 여기에는 char, varchar, blob, 텍스트 등이 포함될 수 있습니다.
MongoDB에서 MySQL 숫자 데이터 유형을 숫자로 변환합니다. 여기에는 int, float, decimal, double 등이 포함될 수 있습니다.
MySQL Date 데이터 유형을 MongoDB에서 Date로 변환합니다. 여기에는 날짜, 연도, 타임스탬프 등이 포함될 수 있습니다.
MongoDB에서 MySQL Bool & Boolean 데이터 유형을 Boolean으로 변환합니다.
다른 경우도 같은 방식으로 평가할 수 있습니다.

하이브리드 모델로 마이그레이션

하이브리드 모델 설계는 두 가지 인기 있는 데이터베이스 모델을 단일 프레임워크에 통합하는 동시에 각 시스템의 단점을 완화합니다. 예를 들어, 데이터 집약적인 이니셔티브를 위한 비관계형 DB와 결합하여 덜 까다로운 작업에 관계형 DB를 활용할 수 있는 하이브리드 접근 방식을 항상 사용할 수 있습니다.

데이터 백업

실행 전에 마이그레이션 전략을 계획하면 원활한 마이그레이션 프로세스를 보장할 수 있습니다. 즉, 항상 플랜 B가 있어야 합니다. 데이터 손실이 발생하거나 마이그레이션을 실행하는 동안 데이터가 손상되는 최악의 시나리오를 가정합니다. 다시 시도하기 전에 데이터를 원래 상태로 복원할 준비가 되어 있어야 합니다. 이것이 DBM(데이터베이스 마이그레이션) 중에 데이터 백업이 매우 필수적인 단계인 이유입니다. 따라서 안전한 데이터 백업을 보장하기 위해 어떤 옵션이 있는지 살펴보겠습니다.

클라우드 백업

마이그레이션 이니셔티브를 보호하는 가장 효율적이고 안전한 방법 중 하나는 클라우드 스토리지에 백업을 실행하는 것입니다. 기본적으로 데이터를 클라우드 스토리지에 백업하면 파일이 오프사이트에 저장됩니다. 이렇게 하면 문제를 일으킬 수 있는 로컬 하드웨어 취약성이 제거됩니다. 그렇다면 왜 클라우드 백업입니까?

클라우드 백업은 사용한 만큼만 지불하면 되므로 저렴합니다.
클라우드 백업은 종단 간 암호화를 제공하므로 안전합니다.
손쉬운 재해 복구 및 데이터 복원 가능
강력한 클라우드 백업 옵션에는 시스템 이미지의 전체 백업이 포함됩니다. 따라서 OS를 다시 설치할 필요가 없습니다. 컴퓨터 및 서버가 마지막 작동 버전으로 복원됩니다.

파일 공유 소프트웨어

Dropbox와 같은 소프트웨어 제품군은 사용자의 요구 사항을 충족하기 위해 성장하고 있습니다. Dropbox는 필요할 때 복원할 수 있는 파일 버전을 유지 관리합니다. 클라우드 백업과 유사하게 이 옵션은 저렴하고 파일이 오프사이트에 저장됩니다. 장점은 무엇입니까?

파일은 모든 위치의 모든 시스템으로 복원할 수 있습니다.
무료로 협업을 지원합니다.
높은 보안(클라우드 스토리지가 전송 중인 파일을 암호화함)
오프라인 작업 기능

그러나 단점은 복원이 자동화되지 않는다는 것입니다. 데이터를 저장하려면 파일 공유 디렉토리 구조에 데이터를 복사하여 붙여넣어야 합니다. 파일은 정의된 구조에 있어야 합니다. 그렇지 않으면 백업되지 않습니다. 파일이 공유 폴더나 디렉터리에 있는 경우 해당 파일을 백업하려면 더 많은 대역폭이 필요할 수 있습니다.

일반적으로 플래시 드라이브나 외장 하드 드라이브에 백업하는 것과 같이 백업에 사용할 수 있는 다른 매체가 있습니다. 그러나 이러한 옵션은 클라우드 백업 또는 파일 공유 소프트웨어에 비해 완전히 안전하지 않으므로 권장하지 않습니다. 예를 들어, 하드 드라이브가 물리적으로 손상되면 데이터가 손실될 수 있습니다. 또한 랜섬웨어 공격 및 크립토 바이러스에 더 취약하고 취약합니다.

데이터가 안전한지 확인하는 방법은 무엇입니까?

데이터 마이그레이션을 수행할 때 민감한 데이터가 침해되거나 변조되지 않았는지 확인해야 합니다. 마이그레이션이 잘못되면 더 큰 결과를 초래할 수 있으며 2020년 여기에 인용된 예와 같이 데이터 유출 또는 데이터 손실이 발생할 수 있습니다.

불행히도 데이터 유출은 고객의 평판을 손상시키고 비즈니스와 고객의 손실을 초래할 수 있습니다. 또는 경우에 따라 법적 조치를 유발할 수 있습니다. 이러한 결과를 모두 방지하려면 마이그레이션 전략을 염두에 두고 사전에 보안 계획을 세워야 합니다.

우선 안정적이고 안전한 서버 액세스 및 데이터 액세스가 우선 순위 목록에 있어야 합니다.
데이터 전송에 필요한 권한 수를 늘립니다. 대규모 조직에서 보안 부서는 서버에 대한 액세스를 제한하고 관련된 서버 간의 데이터 마이그레이션을 정의합니다.
더 많은 당사자가 관련될 때 데이터는 높은 위험에 노출됩니다. 따라서 휴대용 저장 장치나 이메일을 통해 당사자 간에 전송하지 마십시오. 이러한 경우 데이터가 쉽게 손상될 수 있습니다.
데이터의 안전한 액세스, 저장 및 검색을 보장하려면 암호화 및 암호 해독을 지속적으로 연습해야 합니다. 하이브리드 암호화 알고리즘을 사용하여 데이터 보안을 극대화할 수 있습니다. 그러나 이것은 모든 사람에게 권장되지 않습니다. 마이그레이션이 실패하면 데이터가 복잡해져서 데이터 손상 또는 데이터 손실이 발생할 수 있습니다.

안전한 마이그레이션을 위해 기본 도구를 사용하지 마십시오. 기본 도구를 사용하면 시스템이 약화되고 해커가 액세스할 수 있는 허점이 남을 수 있습니다. 기능적으로 특정한 데이터 마이그레이션을 위해 강력한 도구를 사용해야 합니다.

데이터 마이그레이션 프로세스

데이터 마이그레이션은 기본적으로 다단계 프로세스이며 데이터 손실을 방지하고 안전한 데이터베이스 마이그레이션을 보장하기 위해 다음 단계를 따라야 합니다.

평가 :

비즈니스 요구 사항 분석을 수집하고 DBM으로 달성해야 하는 주요 목표를 정의합니다.
범위 정의
광범위한 데이터 프로파일링 수행:
- 소스 데이터, 데이터 형식 검토, 스키마 구조, 내용 및 데이터 인스턴스 간의 관계 검토
대상 시스템 이해
이해 관계자 식별
전체 활동 예산

데이터 백업

마이그레이션하는 데이터가 안전하게 백업되었는지 확인하십시오. 클라우드 백업을 사용하는 것이 좋습니다.
목적지가 깨끗하고 데이터 해킹으로부터 보호되는지 확인하십시오.

리소스 가용성 :

마이그레이션을 위한 시간 가용성 및 대상 시스템의 가동 중지 시간입니다.
고용된 인적 자원이 올바른 기술을 갖고 있는지 확인하십시오.
올바른 도구와 스크립트를 식별합니다.

데이터 마이그레이션 실행 :

마이그레이션 프로세스에는 데이터 이동을 위한 스크립팅, ETL 도구 또는 기타 유사한 도구가 포함될 수 있습니다.
마이그레이션 시 데이터를 변환하고 데이터 유형을 정규화하고 마지막으로 가능한 오류를 확인합니다.

테스트 및 조정 :

팀과 클라이언트 팀은 모든 데이터가 올바르게 마이그레이션되었는지 확인해야 합니다.
따라서 데이터가 올바르게 이동되었는지, 데이터가 완전한지 확인하고 누락된 값이 없는지 확인하십시오.
또한 데이터가 유효하고 null 값을 포함하지 않는지 확인하십시오.
데이터 불일치가 있는 경우 데이터 롤백이 있어야 하며 전체 프로세스를 다시 시작해야 합니다.

심사

새 데이터베이스가 활성화되면 데이터를 감사하도록 시스템을 설정할 수 있습니다. 이렇게 하면 데이터베이스 마이그레이션의 정확성을 보장하고 불완전하고 부정확한 데이터에 주의를 기울입니다.

데이터베이스 마이그레이션의 잠재적 위험

데이터베이스 마이그레이션은 매우 복잡한 절차이며 위험과 불확실성이 따릅니다. 적절한 계획과 실행을 통해 항상 이러한 문제를 극복할 수 있습니다. 발생할 수 있는 위험은 다음과 같습니다.

구식 소스 시스템: 여기서 데이터 소스는 구식, 중복, 구식 또는 사소한 것일 수 있습니다.
이종 데이터베이스 아키텍처: 이 시나리오에서 원본 데이터베이스는 여러 위치에 있을 수 있고 서로 완전히 다른 아키텍처를 가질 수 있지만 대상 데이터베이스는 모든 것이 동기화되어야 합니다.
연장된 다운타임: 계획된 마이그레이션이 예상보다 오래 걸리는 경우가 있으며 이로 인해 시스템의 다운타임이 연장됩니다. 이는 최종 클라이언트에게 비즈니스 손실을 초래할 수 있으며 허용되지 않을 수 있습니다.
잠재적 데이터 손실: 테스트 단계에서 모든 데이터 손실을 식별할 수 있는 것은 아닙니다. 일부 데이터 손실 인스턴스는 시스템이 충분한 트래픽을 얻을 때 결국 식별될 수 있습니다.

실시간 데이터베이스에서 마이그레이션: 트랜잭션이 많은 웹 사이트의 경우 데이터 업데이트가 지속적으로 발생하기 때문에 데이터베이스 마이그레이션은 항상 어렵습니다. 라이브 및 실시간 데이터 마이그레이션은 불가능합니다. 마이그레이션이 발생하려면 다운타임이 있어야 합니다.

최종 비고

데이터베이스 마이그레이션에 대한 제3자 전문가의 조언을 언제든지 구할 수 있습니다. 우리는 데이터베이스 마이그레이션을 전문으로 하는 Creole Studios이며 그러한 노력에 기꺼이 도움을 주거나 상담할 것입니다. 기술 마이그레이션 시리즈의 네 번째이자 마지막 블로그를 계속 확인하십시오.