마이그레이션 고려 사항

24분

온-프레미스에서 실행되는 비즈니스 시스템에는 동일한 환경에서 작동하는 다른 서비스와 결합된 아키텍처가 있을 수 있습니다. 마이그레이션하려는 시스템과 조직에서 현재 사용 중인 기타 애플리케이션 및 서비스 사이의 관계를 이해하는 것이 중요합니다.

기술 스타트업 회사에서 공급업체 데이터베이스는 항상 구성 요소의 재고가 있고 제조 프로세스에서 사용하기 위해 적시에 도착하도록 보장하는 데 사용됩니다. 재고 컨트롤러는 화물이 도착하면 모바일 디바이스를 사용하여 이 데이터베이스를 업데이트하고 구매자는 웹 사이트를 사용하여 재고 수준을 모니터링하고 최적의 주문 시간을 식별합니다. 관리자는 비즈니스에 중요한 보고서 세트를 사용하여 프로세스를 모니터링하고 효율성을 향상시킵니다. Azure로의 마이그레이션이 이러한 사용자에게 부정적인 영향을 미치지 않도록 확인하는 것이 좋습니다.

여기에서는 클라우드로의 원활한 데이터베이스 마이그레이션을 계획하고 실행하는 방법을 알아봅니다.

종속성 조사

복잡한 시스템에서는 구성 요소가 완전히 독립적으로 작동하는 경우가 거의 없습니다. 대신 다른 프로세스 및 구성 요소를 호출합니다. 예를 들어 데이터베이스는 사용자 계정을 호스트하는 디렉터리 서비스에 종속될 수 있습니다. 클라우드로 데이터베이스를 이동하면 해당 디렉터리 서비스에 액세스할 수 있나요? 그렇지 않으면 사용자는 어떻게 로그인하나요? 이와 같은 종속성을 간과하면 데이터베이스가 완전히 실패할 수 있습니다.

위험을 완화하려면 데이터베이스가 다음과 같은 서비스에 종속되어 있는지 확인합니다.

디렉터리 서비스(예: Active Directory).
기타 보안 주체 저장소.
기타 데이터베이스.
웹 API 또는 다른 네트워크 서비스.

다른 구성 요소가 데이터베이스에 종속될 수 있음도 기억하세요. 종속된 구성 요소를 다시 구성하지 않고 데이터베이스를 이동하면 어떤 결과가 발생하나요? 예를 들어 제품 카탈로그 데이터베이스를 이동하고 공용 웹 사이트에서 사용자에게 제공할 제품을 결정하는 데 데이터베이스를 사용하는 경우 데이터베이스를 이동하면 서비스가 중단되나요?

해당 유형의 구성 요소가 데이터베이스에 종속되는지 확인합니다.

웹 사이트 및 웹 API.
모바일 앱 및 데스크톱 소프트웨어와 같은 클라이언트 앱.
기타 데이터베이스.
보고서를 참조하십시오.
데이터 웨어하우스.

이 검사를 수행하려면 각 데이터베이스 및 시스템 구성 요소와 관련된 관련자, 관리자 및 개발자에게 문의하세요. 문서를 참조한 다음에도 시스템의 동작을 이해하는 데 확신이 없으면 네트워크 캡처와 같은 테스트를 실행하여 동작을 관찰하는 것이 좋습니다.

대체 방법 준비

모든 마이그레이션 프로젝트에서 항상 실패에 대비해야 합니다. 클라우드로 데이터베이스를 마이그레이션하는 프로젝트에서는 최악의 경우 새 데이터베이스를 사용할 수 없게 되고 사용자가 작업을 수행할 수 없게 됩니다. 온-프레미스로 수정되지 않은 원본 데이터베이스를 롤백할 계획을 세워 회사의 수익성에 큰 영향을 미칠 수 있는 이 위험을 완화하는 것이 일반적입니다.

대체 계획으로 다음을 고려합니다.

실패한 마이그레이션에 영향을 받지 않은 데이터베이스로 대체할 수 있음을 확인하는 방법은 무엇인가요? 예를 들어 마이그레이션을 시작하기 직전에 전체 데이터베이스를 백업하는 것이 좋습니다.
대체해야 하는 경우 데이터베이스가 오프라인 상태를 유지할 수 있는 기간은 얼마나 되나요?
대체 계획에 사용할 수 있는 예산은 얼마나 되나요? 예를 들어 데이터베이스를 전용 대체 서버에 복제할 여유가 있나요? 그렇다면 마이그레이션 직전에 이 서버를 끌 수 있습니다. 대체하려면 이 서버를 부팅합니다. 백업에서 복원할 필요 없이 마이그레이션의 영향을 받지 않는 데이터베이스가 즉시 생성됩니다.

오프라인 대 온라인 마이그레이션

데이터베이스를 마이그레이션하는 데 최소 다음 두 가지 옵션이 있습니다.

참고

현재 Data Migration Service의 MySQL 데이터베이스에는 온라인 옵션을 사용할 수 없습니다.

시스템을 중단하고 데이터베이스를 전송한 다음 새 데이터베이스를 사용하도록 시스템을 다시 구성하고 다시 시작합니다. 이 작업은 오프라인 마이그레이션입니다.
데이터베이스를 새 위치로 이동하는 동안 시스템을 실행된 상태로 두고, 마이그레이션을 진행하는 동안 원본 데이터베이스에 대해 수행되는 트랜잭션을 새 데이터베이스에 롤포워드한 다음 새 데이터베이스에 연결하도록 애플리케이션을 전환합니다. 이 작업은 온라인 마이그레이션입니다.

마이그레이션이 진행되는 동안 데이터를 변경할 수 없는 오프라인 마이그레이션을 수행하는 것이 더 간단합니다. 그러나 데이터베이스가 사용 중이거나 조직의 성공에 중요한 경우에는 이 작업을 수행할 수 없습니다.

오프라인 마이그레이션

데이터베이스가 정상 업무 시간 동안 단일 시간대에서 모두 근무하는 분석가 팀을 지원한다고 가정합니다. 팀은 일반적으로 주말에는 근무하지 않습니다. 금요일 오후 6:00와 일요일 오전 9:00 사이에는 데이터베이스가 자주 사용되지 않습니다.

이 경우 다음 단계에 따라 주말에 오프라인으로 마이그레이션할 수 있습니다.

금요일 저녁에 모든 트랜잭션이 완료되고 나면 데이터베이스를 오프라인 상태로 전환합니다.
전체 백업을 수행하거나 데이터베이스를 내보냅니다.
온-프레미스 서버를 종료하고 대체해야 하는 경우에 대비하여 유지합니다.
대상 클라우드 시스템에서 데이터베이스를 복원합니다.
대상 시스템을 온라인 상태로 전환합니다.
클라이언트를 클라우드 데이터베이스에 연결하도록 다시 구성합니다.

이 경우 서비스 중단이 사용자에게 거의 영향을 미치지 않는 기간이 길기 때문에 오프라인 마이그레이션이 가능합니다. 이 시간 동안에는 변경 사항이 누락되지 않고 데이터베이스의 전체 백업 및 복원을 수행할 수 있습니다.

온라인 마이그레이션

이제 판매 앱을 지원하는 다른 데이터베이스를 살펴보겠습니다. 판매 직원은 전 세계에 분산되어 있으며 주말에도 근무합니다. 활동이 적은 기간이 없고 데이터베이스가 항상 사용 중이므로 상당히 오랜 기간 동안 데이터베이스를 오프라인으로 전환하면 사용자에게 영향을 미칩니다. 판매 활동은 업무상 중요하므로 서비스를 중단하면 조직의 수익에 직접적인 영향을 미칩니다.

이와 같은 경우 온라인 마이그레이션을 수행하는 것이 좋습니다. 온라인 마이그레이션에서 가동 중지 시간은 새 데이터베이스로 전환하는 데 걸리는 시간으로 한정됩니다. Azure Data Migration Service와 같은 도구를 사용하여 온라인 마이그레이션을 실행합니다. 오프라인 마이그레이션과 다른 온라인 마이그레이션의 차이점은 다음과 같습니다.

백업 또는 내보내기를 수행하기 전에 원본 데이터베이스를 오프라인으로 전환하지 않습니다.
마이그레이션이 진행 중인 동안에는 변경 내용이 이전 데이터베이스에 적용됩니다.
마이그레이션 도구를 사용하면 변경 내용이 전환 전에 새 데이터베이스에 복사됩니다. 변경 내용을 새 데이터베이스에 복제하도록 이전 데이터베이스를 다시 구성하여 수행하는 경우가 많습니다.

애플리케이션 마이그레이션

데이터베이스를 마이그레이션한 다음 새 시스템으로 전환하여 새 데이터베이스를 사용하도록 애플리케이션을 업데이트하는 방법과 시기는 어떻게 되나요? 다음을 수행할 수 있습니다.

애플리케이션을 하나씩 새 데이터베이스로 이동합니다.
사용자의 하위 세트를 이동합니다.
두 접근 방식의 조합을 채택합니다.

문제가 발생하면 쉽게 롤백할 수 있는 소규모 단계에서 애플리케이션 마이그레이션을 수행하기 위해서입니다. 데이터베이스를 마이그레이션하는 데 오프라인 또는 온라인 접근 방식을 따랐는지 여부와 관계없이 원래 원본에 작동하는 구성이 있어야 합니다. 이론적으로는 원래 원본으로 빠르게 다시 전환할 수 있습니다. 하지만 데이터가 지속적으로 변경되는 경우 변경이 수행된 위치를 고려해야 합니다.

오프라인 마이그레이션에서는 원본과 대상이 서로 독립적입니다. 사용자와 애플리케이션에 더 이상 데이터가 일관되게 표시되지 않을 수 있습니다. 트랜잭션 시스템에서는 이 상황이 허용되지 않을 수 있습니다. 이 경우 두 시스템이 모두 활성 상태로 유지되는 동안 데이터베이스 사이에서 일정 양식의 양방향 복제를 유지 관리해야 합니다. 또는 월별 또는 주별 보고서를 생성하거나 판매 전망을 생성하거나 기타 통계 작업을 수행하기 위해 애플리케이션을 사용하는 경우에는 이처럼 일관성이 없어도 그다지 걱정스럽지 않을 수 있습니다. 해당 애플리케이션에서는 최신 데이터에 의존하지 않고 데이터를 "장기적인 관점"으로 사용합니다. 후자의 경우 트랜잭션 애플리케이션은 새 데이터베이스를 사용하는 반면, 보고 애플리케이션은 더 느리게 이동합니다.
온라인 마이그레이션에서 새 데이터베이스는 일반적으로 일정 형태의 복제를 통해 이전 데이터베이스와 계속 동기화됩니다. 복제 프로세스는 비동기식일 수 있으므로 지연이 발생할 수 있습니다. 그러나 새 데이터베이스의 데이터를 변경해도 이전 데이터베이스에 다시 전파되지 않으므로 충돌이 발생할 수 있습니다. 이전 데이터베이스에 대해 애플리케이션을 실행하면 새 데이터베이스에서 수정된 데이터와 충돌하는 변경 내용이 생성될 수 있습니다. 복제는 새 데이터베이스의 변경 내용을 무조건 덮어쓰므로 "업데이트 손실"이 발생합니다.

테스트 접근 방식

데이터베이스가 비즈니스에서 중요한 역할을 하는 경우 실패로 인한 결과는 상당할 수 있습니다. 더 확실히 이 상황이 발생하지 않게 하려면 사용자가 부여한 로드를 처리하고 신속하게 대응하도록 마이그레이션된 데이터베이스에 대해 성능 테스트를 실행하는 것이 좋습니다. 수요가 평소보다 훨씬 더 높은 경우 최대 활동 기간일 수 있습니다. 마이그레이션된 시스템이 예상 워크로드를 처리하는지 알아야 합니다.

사용자에 대한 액세스를 허용하기 전에 항상 새 데이터베이스에 대해 일정 형식의 회귀 테스트를 수행합니다. 이 테스트에서는 시스템의 동작 및 기능이 올바른지 확인합니다.

또한 "내구성 테스트"를 실행하는 것이 좋습니다. 내구성 테스트는 시스템 전체가 압박을 받는 상황에서 어떻게 작동하는지 확인하기 위해 설계된 부하 테스트입니다. 내구성 테스트는 새 데이터베이스를 과부하시키고 수요가 높은 상황에서 안정적인지 확인합니다. 내구성 테스트는 수요가 계속 높은 경우 발생하는 상황을 확인하기 위해 상당한 기간 동안 실행됩니다.

새 시스템을 안정적으로 설정하면 사용자 마이그레이션을 시작할 수 있습니다. 그러나 사용자가 새로운 시스템을 허용하는지도 추가로 확인해야 합니다. 이 시점에서 "카나리아 테스트"를 고려할 수 있습니다. 카나리아 테스트에서는 사용자의 일부를 새 시스템으로 명확하게 안내하지만, 사용자는 새 시스템에 액세스 중임을 알지 못합니다. 새 시스템에서 발생하는 문제나 이슈를 찾는 데 사용할 수 있는 일종의 블라인드 테스트입니다. 사용자의 응답을 모니터링하고 필요한 대로 조정합니다.

병렬 시스템 유지 관리

이전 온-프레미스 데이터베이스를 새 클라우드 데이터베이스와 병렬로 실행하도록 선택하는 이유는 몇 가지가 있습니다.

테스트 기간. 이전 토픽에서 살펴본 대로, 사용자를 지원하는 데 사용하기 전에 마이그레이션된 데이터베이스에 대해 카나리아 테스트를 실행하여 기능, 안정성 및 용량을 평가하는 것이 좋습니다. 온-프레미스 시스템을 병렬로 유지 관리하면 새 시스템에 문제가 있는 경우 사용자를 이전 시스템으로 빠르게 되돌릴 수 있습니다.
단계별 마이그레이션. 예기치 않은 실패가 프로덕션에 미치는 영향을 완화하는 한 가지 방법은 먼저 소수의 사용자를 새 시스템으로 이동하고 결과를 모니터링하는 것입니다. 모든 작업이 원활하게 실행되면 새 데이터베이스에 대한 확신을 갖고 다른 사용자 그룹을 이동할 수 있습니다. 사용자가 새 데이터베이스에 있을 때까지 사용자를 부서별, 위치별 또는 역할별로 이동할 수 있습니다.
증분 마이그레이션. 또 다른 접근 방법은 사용자가 아니라 워크로드로 마이그레이션을 분할하는 것입니다. 예를 들어, 판매를 지원하는 데이터베이스 테이블에 앞서 인사부를 지원하는 데이터베이스 테이블을 마이그레이션할 수 있습니다.

이와 같은 경우 항상 이전 온-프레미스 데이터베이스가 새 클라우드 데이터베이스와 병렬로 실행되는 기간이 있습니다. 이전 데이터베이스의 변경 내용이 새 데이터베이스에도 적용되고 반대 방향으로도 진행되는지 확인해야 합니다. 이 동기화를 스크립팅하거나 Azure Data Migration Service와 같은 도구를 사용할 수 있습니다.

병렬 데이터베이스를 유지 관리하고 변경 내용을 동기화하도록 결정한 경우 스스로에게 다음을 질문해 보세요.

충돌 해결. 온-프레미스로 행을 변경하는 작업과 클라우드에서 동일한 행을 변경하는 또 다른 작업이 비슷한 시간에 발생할 가능성이 있나요? 그러면 충돌이 발생할 수 있으며, 어떤 변경 내용을 유지할지 명확하지 않습니다. 이 충돌은 어떻게 해결하나요?
네트워크 트래픽. 데이터베이스 간에 변경 사항이 동기화되는 동안 얼마나 많은 네트워크 트래픽이 생성되나요? 이 트래픽에 사용할 네트워크 용량이 충분한가요?
대기 시간. 데이터베이스 중 하나가 변경되면 해당 변경 내용이 다른 데이터베이스에 도달하기 전에 허용되는 지연 시간은 얼마나 되나요(있는 경우)? 예를 들어 제품 카탈로그에서 새 제품이 모든 사용자에게 표시될 때까지 최대 하루를 기다려야 할 수 있습니다. 그러나 데이터베이스에 환율과 같은 중요한 트랜잭션 정보가 포함되어 있으면 해당 데이터는 즉시 동기화되지 않더라도 훨씬 더 자주 동기화되어야 합니다.

증분 마이그레이션

증분 마이그레이션에서는 전체 시스템을 워크로드로 나누고 한 번에 하나의 워크로드를 마이그레이션합니다.

여러 데이터베이스

복잡한 시스템에는 여러 워크로드를 지원하는 여러 개의 데이터베이스가 포함될 수 있습니다. 예를 들어 인사 팀은 StaffDB 데이터베이스를 사용하는 반면, 판매팀에는 ProductCatalogDB 데이터베이스와 OrdersDB 데이터베이스를 모두 쿼리하는 모바일 앱이 있을 수 있습니다.

물론 전체 데이터베이스 시스템을 한 번에 클라우드로 마이그레이션하도록 선택할 수 있습니다. 온-프레미스와 클라우드 모두에서 데이터베이스를 실행할 필요가 없기 때문에 더 간단할 수 있습니다. 마이그레이션 중에 이 데이터베이스가 통신하는 방식을 고려할 필요가 없습니다. 그러나 실패의 위험은 더 높습니다. 하나의 문제가 인사 팀과 판매팀 모두에 영향을 미칠 수 있습니다.

한 번에 하나의 워크로드를 이동하는 증분 마이그레이션을 수행하여 중대형 데이터베이스 시스템에 대한 위험을 완화하는 것이 좋습니다. 이 예에서는 실패와 관련된 문제가 인사 팀에 한정되고 주문을 받는 데 방해가 되지 않으므로 먼저 StaffDB 데이터베이스 마이그레이션을 고려할 수 있습니다. StaffDB 마이그레이션과 관련하여 발생하는 문제를 해결하면 다른 워크로드 마이그레이션에 적용되는 방법을 배울 수 있습니다.

다음으로 제품 카탈로그 워크로드를 클라우드로 마이그레이션하는 것을 고려할 수 있습니다. 그런 경우 다음과 같은 질문을 고려하세요.

카탈로그에 새로 추가된 제품을 주문할 수 있는지 확인하려면 어떻게 해야 하나요?
온-프레미스로 유지되는 OrdersDB 데이터베이스와 데이터를 동기화해야 하나요?
신제품이 제품 카탈로그에서 OrdersDB 데이터베이스에 도달할 때까지 허용되는 대기 시간은 얼마인가요?

단일 데이터베이스 증분 마이그레이션

모든 워크로드를 지원하는 단일 데이터베이스만 있는 경우에도 증분 마이그레이션을 고려할 수 있습니다. 예를 들어 데이터베이스를 다음과 같은 부분으로 나눌 수 있습니다.

HR 작업을 지원하는 테이블.
판매를 지원하는 테이블.
분석 및 보고를 지원하는 테이블.

HR 작업 테이블을 먼저 마이그레이션하면 발생하는 모든 문제가 HR 담당자에게만 영향을 줍니다. 판매 및 데이터 분석가는 중단 없이 이전 데이터베이스에서 계속 작동합니다.

증분 마이그레이션을 수행하려면 먼저 데이터베이스를 파악하고 애플리케이션에서 데이터베이스를 사용하는 방법을 완전히 이해해야 합니다. 예를 들어 데이터베이스의 일부 테이블은 판매 및 보고를 모두 지원할 수 있습니다. 즉, 워크로드를 명확하게 나눌 수 없습니다. 모든 워크로드가 마이그레이션될 때까지 온-프레미스 및 클라우드 데이터베이스 간에 이 테이블을 동기화해야 합니다.

보안에 대한 우려

데이터베이스에는 제품 정보, 개인 직원 정보, 결제 세부 정보와 같은 중요한 데이터가 포함될 수도 있으므로 항상 보안이 가장 우선시됩니다. 마이그레이션하는 동안 새 데이터베이스에서 이 데이터를 보호하는 방법을 결정해야 합니다.

방화벽 보호

인터넷에 연결된 애플리케이션에서 데이터베이스 서버는 일반적으로 두 개 이상의 방화벽을 통해 보호됩니다. 예를 들어, 해당 서버가 웹 사이트 또는 웹 API를 호스트하는 경우 첫 번째 방화벽에서 프런트 엔드 서버와 인터넷을 분리합니다. 외부 방화벽에서는 TCP 포트 80만 열려 있어야 하지만, 이 포트는 차단된 주소를 제외한 모든 원본 IP 주소에 대해 열려 있어야 합니다.

두 번째 방화벽은 프런트 엔드 서버를 데이터베이스 서버와 분리합니다. 외부에 알려지지 않은 프라이빗 포트 번호에서 데이터베이스 서비스를 게시하는 것이 좋습니다. 두 번째 방화벽에서는 프런트 엔드 서버의 IP 주소에만 이 포트 번호를 개방합니다. 이처럼 정렬하면 악의적인 인터넷 사용자에서 데이터베이스 서버로 직접 통신할 수 없습니다.

데이터베이스 서버를 Azure 가상 머신으로 마이그레이션하려는 경우 NSG(네트워크 보안 그룹)가 는 가상 네트워크를 사용하여 방화벽 규칙을 복제합니다. Azure Database for MySQL, Azure Database for MariaDB 또는 Azure Database for PostgreSQL을 사용하는 경우 Azure Portal의 서버에 대한 연결 보안 페이지를 사용하여 데이터베이스를 보호하는 방화벽 규칙을 만들 수 있습니다.

인증 및 권한 부여

대부분의 데이터베이스에서 누가 어떤 데이터에 액세스하고 수정하는지를 세밀하게 제어해야 합니다. 이 제어를 사용하려면 사용자가 데이터베이스에 연결할 때 사용자를 확실하게 식별해야 합니다. 이 프로세스는 인증이라고 하며 일반적으로 사용자 이름 및 암호를 사용하여 수행됩니다. MySQL, MariaDB 및 PostgreSQL과 같은 데이터베이스 시스템은 자체 인증 메커니즘을 제공합니다. 시스템을 클라우드로 마이그레이션할 때 계속 사용자를 안전하게 인증해야 합니다.

참고

Azure Database for MySQL, Azure Database for MariaDB 및 Azure Database for PostgreSQL 서비스는 기존 MySQL, MariaDB 및 PostgreSQL 인증을 에뮬레이트합니다.

사용자가 누구인지 알고 있으면 업무의 일부인 작업을 완료할 수 있는 권한을 할당해야 합니다. 이 프로세스를 권한 부여라고 합니다.

데이터베이스 마이그레이션 프로젝트의 경우 클라우드 데이터베이스에서 사용자에게 올바르게 권한이 부여되었는지 확인해야 합니다.

온-프레미스 시스템에서 사용자 계정이 저장된 위치를 확인합니다. MySQL에서 사용자 계정은 일반적으로 mysql 데이터베이스의 user 테이블에 저장되지만, Active Directory에 저장된 사용자 계정과 통합하는 등의 작업을 수행할 수 있습니다.
모든 사용자 계정 목록을 가져옵니다. 예를 들어 MySQL에서는 다음 명령을 사용할 수 있습니다.
```
SELECT host, user FROM mysql.user;
```
사용자 계정마다 데이터베이스에 대한 액세스 권한을 확인합니다. 예를 들어 MySQL에서는 dbadmin@on-premises-host 사용자 계정에 다음 명령을 사용할 수 있습니다.
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
클라우드 데이터베이스에서 각 사용자 계정을 다시 생성합니다. 예를 들어 MySQL에서는 새 계정을 만드는 데 다음 명령을 사용할 수 있습니다.
```
CREATE USER 'dbadmin'@'cloud-host'
```
클라우드 데이터베이스에서 사용자 계정마다 올바른 수준의 액세스 권한을 부여합니다. 예를 들어 MySQL에서는 이 명령을 사용하여 사용자가 전체 데이터베이스에 액세스하도록 허용할 수 있습니다.
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

암호화

데이터가 네트워크를 통해 전송될 때 “중간자(man-in-the-middle)”라는 공격을 통해 가로챌 수 있습니다. 이 문제를 방지하기 위해 Azure Database for MySQL, Azure Database for MariaDB 및 Azure Database for PostgreSQL에서 모두 통신을 암호화하도록 SSL(Secure Sockets Layer)을 지원합니다. SSL은 기본적으로 강제 적용되며 이 설정은 변경하지 않는 것이 좋습니다.

SSL 암호화를 사용하도록 클라이언트 애플리케이션의 연결 설정을 수정해야 할 수도 있습니다. 개발자와 이 토픽에 대해 논의하여 필요한 변경 사항을 결정합니다.

모니터링 및 관리

데이터베이스 마이그레이션 계획의 일부로 데이터베이스 관리자가 마이그레이션 후 작업을 계속 수행하는 방법을 고려합니다.

모니터링

온-프레미스 데이터베이스 관리자는 정기적으로 모니터링하여 하드웨어 병목 현상 또는 네트워크 액세스 경합과 같은 문제를 파악합니다. 생산성에 영향을 주기 전에 문제를 해결할 수 있는지 모니터링합니다. 정기적으로 모니터링하지 않는 데이터베이스는 조만간 문제를 일으킬 수 있습니다.

클라우드 데이터베이스에 대해서도 똑같은 접근 방식을 사용해야 합니다. 하드웨어를 구입, 설정, 구성하지 않고도 리소스를 추가할 수 있으므로 Azure와 같은 PaaS 시스템의 문제를 해결하는 것이 더 쉬울 수도 있습니다. 그러나 여전히 발생하는 문제를 찾아내야 하므로 일상적인 작업에서 모니터링의 우선 순위가 높습니다.

데이터베이스를 클라우드로 마이그레이션하기 전에 관리자가 현재 사용하는 모니터링 도구를 확인합니다. 이 도구가 제안된 클라우드 기반 솔루션과 호환되는 경우 마이그레이션된 데이터베이스에만 다시 연결하면 될 수도 있습니다. 그렇지 않으면 대안을 조사해야 합니다.

Azure는 성능 모니터링 도구 세트를 포함하며 다양한 성능 카운터 및 로그 데이터를 수집한다는 점에 유의하세요. Azure Monitor를 구성하여 Azure Portal에서 대시보드 및 차트로 이 데이터를 표시합니다. 관리자의 요구 사항에 맞게 특별히 설계된 사용자 지정 그래프, 테이블 및 보고서를 생성합니다.

관리

데이터베이스 관리자는 기본 도구를 사용하여 온-프레미스에서 데이터베이스의 스키마와 콘텐츠를 변경합니다. 마이그레이션 후 동일한 도구를 사용하는 경우 계속해서 전문 지식을 활용할 수 있습니다. 기존 도구 세트가 제안된 클라우드 호스트 데이터베이스와 호환되는지 평가하여 시작합니다. 대부분의 도구는 SQL과 같이 광범위하게 채택된 표준을 기반으로 하기 때문에 서로 호환되지만, 그래도 호환성을 확인하는 것이 중요합니다. 마이그레이션 후 현재 관리 도구가 작동하지 않으면 관리자와 함께 대안을 확인하세요.

Azure에는 MySQL, MariaDB 및 PostgreSQL 데이터베이스를 관리하는 데 사용할 수 있는 여러 도구가 포함되어 있습니다.

Azure Portal. 이 웹 사이트에는 데이터베이스 및 Azure 클라우드에서 만들 수 있는 기타 모든 리소스를 구성, 모니터링 및 관리하는 데 사용하는 강력한 기능이 있습니다.
Azure PowerShell. 다양한 명령 세트가 있는 스크립팅 실행 환경 및 언어입니다. Windows 및 Linux 환경에서 사용할 수 있는 PowerShell을 사용하여 복잡한 데이터베이스 관리 작업을 자동화합니다.
Azure CLI Azure의 명령줄 인터페이스입니다. Azure에서 서비스 및 리소스를 관리하는 데 사용합니다. Windows 및 Linux 셸 환경과 Bash 스크립트에서 CLI를 사용할 수 있습니다.