클라우드로 데이터 베이스 이전을 시작할 때 알아두어야 할 점
이제 AWS 클라우드로 여러분의 데이터 베이스를 이전하기로 하셨다면 축하드립니다. 클라우드로 전환하도록 설득하는 과정에서 중요한 결정을 하신 것입니다. 이제 새로운 환경, 플랫폼 또는 기술로 애플리케이션을 옮기는 소위 애플리케이션 현대화(Modernizing Application)를 진행하게 됩니다. 데이터베이스를 재미로 이리저리 옮기는 사람은 없을 테니까요.
데이터베이스 마이그레이션은 평가, 데이터베이스 스키마 변환(엔진을 변경하는 경우), 스크립트 변환, 데이터 마이그레이션, 기능 테스트 등 여러 단계로 진행되는 복잡한 프로세스입니다.
AWS Database Migration Service(AWS DMS) 및 AWS Schema Conversion Tool(AWS SCT), 네이티브 엔진 도구 등의 도구를 사용하면 이 같은 데이터베이스 마이그레이션 프로세스의 일부 단계를 손쉽게 자동화할 수 있습니다. 하지만 성공적으로 마이그레이션하려면 데이터베이스 마이그레이션 프로젝트의 예측 가능성을 높이는 것이 무엇보다 중요합니다. 10TB의 데이터를 이미 마이그레이션한 상태에서 예기치 못한 문제가 발생하는 일은 없어야 겠죠.
프로젝트를 당장 시작하고 싶은 마음이 굴뚝같으실 겁니다. 하지만 프로젝트를 성공적으로 끝내는 데 필요한 자원은 모두 확보하셨나요? 이 블로그 게시물에서는 데이터베이스를 클라우드로 마이그레이션할 때 발생할 수 있는 일반적인 마이그레이션 문제에 대해 설명합니다. 마지막 섹션에서는 AWS 마이그레이션과 관련한 자세한 정보를 제공합니다.
프로젝트 인력 산정하기
파악해야 할 관련 모듈이 많기 때문에 애플리케이션 현대화는 까다로운 과제가 될 수 있습니다. 소스 데이터베이스 엔진을 잘 아는 전문가라도 엔진을 교체하는 경우에는 타겟 데이터베이스의 엔진에 대해서도 전문가가 되어야 합니다. 데이터베이스 간에 데이터를 이동하려면 네트워크를 통해야 하므로 서버, 포트, 방화벽 규칙에 대해서 잘 아는 사람도 필요합니다. 앞서 언급했듯이 데이터베이스 마이그레이션은 대개 더 광범위한 애플리케이션 현대화 프로젝트의 일환으로 진행되므로, 동종 간 마이그레이션을 비롯한 모든 데이터베이스 마이그레이션에서는 애플리케이션 코드를 일부 변경해야 합니다.
수십 명 또는 수백 명의 개발자가 개발한 지 15년이 지난 300,000줄의 COBOL 애플리케이션이 있는데 개발 당시 인력은 한 명도 회사에 남아 있지 않은 그런 상황이 흔합니다. 하지만 여전히 회사에서 근무 중인 개발자 3명이 모던 프로그래밍 언어로 코드를 작성했더라도 데이터베이스 마이그레이션을 위해 애플리케이션 코드를 어떻게 변경해야 할지를 평가할 사람이 필요합니다. 마지막으로, 클라우드 제공업체에 따라 이용 중인 제공업체 생태계를 잘 아는 사람이 팀에 필요합니다. 한마디로, 이 프로젝트에는 최고의 인재가 필요합니다.
일정 계획하기
일반적으로 데이터베이스 마이그레이션 프로젝트에서는 애플리케이션 및 데이터베이스의 소스 코드와 스키마를 변경해야 하는데, 그 프로세스는 시간이 많이 걸리고 반복적인 작업입니다. 애플리케이션과 데이터베이스가 얼마나 복잡한지에 따라 소스 코드 변경 프로세스는 몇 주에서 몇 개월까지 걸릴 수 있습니다. 데이터 센터를 철수해야 하는 경우처럼 일정이 확정되어 있는 경우 실현 가능한 목표를 세워야 합니다. 모든 과정이 순조롭더라도 예상보다 데이터 마이그레이션이 느리게 진행될 수 있습니다. 또한 실제 마이그레이션보다 계획을 수립하는 데 시간이 더 걸릴 수도 있다는 사실을 유의해야 합니다.
데이터베이스 현황 파악하기
마이그레이션 프로젝트를 성공적으로 진행하려면 소스 데이터베이스를 파악하는 것이 중요합니다.
다시 한번 최악의 상황을 상정해보자면, 제품의 첫 번째 버전이 수년 전 이미 사용 중단되었음에도 해당 버전을 지원할 수 있는 15년 된 데이터베이스가 여전히 사용되는 경우를 예로 들 수 있습니다. 10여년 전 여러분이 입사할 당시에 작성된 저장 프로시저가 그대로 남아 있는 데이터베이스에서 수천 개의 테이블과 수십 개의 스키마를 지원하는 경우도 있습니다.
어쨌든 운이 좋아서 이 정도로 최악의 상황이라고 합시다. 그렇다면 간단한 질문에 답해 보십시오. 여러분이 마이그레이션하려는 데이터베이스의 크기는 얼마입니까? 놀랍게도 대부분의 고객은 이 질문에 답하지 못합니다. 데이터베이스의 크기는 마이그레이션 프로젝트에서 사용할 적절한 마이그레이션 방식을 결정하는 데 있어서 중요합니다. 또한 데이터를 복사하는 데 소요되는 시간을 예상하는 데에도 도움이 됩니다. 무엇보다 마이그레이션할 스키마와 테이블의 수를 파악하는 것이 중요합니다. 데이터베이스의 레이아웃을 알면 마이그레이션 프로젝트를 정의하는 데 도움이 될 뿐만 아니라 데이터 복제 단계에 소요되는 시간을 대폭 단축할 수 있습니다. 나아가 어느 테이블이 어느 트랜잭션에 관여하는지까지 알면 더 효과적으로 프로젝트를 진행할 수 있습니다. 이 정보를 알면 서로 관련이 없는 여러 테이블 세트의 마이그레이션을 동시에 실행할 수 있습니다.
또 다른 중요한 문제로, 데이터베이스에 크기가 매우 큰 테이블은 몇 개나 있는지도 파악해야 합니다. “매우 크다”는 것은 주관적인 개념이지만, 마이그레이션에 있어서는 200기가바이트를 초과하고 행이 수억 개에 달하는 테이블이 있는 경우 데이터 마이그레이션이 지연될 수 있습니다. 테이블을 파티셔닝한 경우 AWS DMS와 같은 일부 네이티브 툴과 AWS 툴을 사용하여 데이터를 병렬로 로드하는 방법을 알아야 합니다.
자, 그러면 초기 조사를 어느 정도 마쳐 마이그레이션할 데이터베이스의 크기, 스키마, 테이블에 대한 정보를 알고 있다고 가정해보겠습니다. 이제 엔진별로 “고유” 데이터 유형이 스키마에 포함되어 있는지를 파악해야 합니다. 그러한 데이터 유형이 있으면 특히 Oracle에서 PostgreSQL로 전환하는 경우와 같이 데이터베이스 엔진을 전환할 때 문제가 될 수 있습니다. 이기종 마이그레이션을 계획하고 있는 경우에도 관련 데이터 형식 중 일부를 지원하지 않는 도구가 많습니다. 늘 그렇듯 먼저 설명서를 참조하는 것이 좋습니다. AWS DMS에는 마이그레이션 대상이 되는 데이터 형식을 확인하고 데이터 형식과 관련한 문제를 경고하는 마이그레이션 전 검증이라는 기능이 있습니다. 이후 데이터를 마이그레이션할 때에는 데이터 센터의 운영을 중단하기 전에 새 데이터 센터에서 마이그레이션된 모든 데이터가 올바른지를 확인해야 합니다. 이때에도 AWS DMS Data Validation 같은 다양한 도구를 활용하면 전체 데이터 세트 또는 샘플을 간편하게 비교할 수 있습니다.
다음으로 대용량 객체인 LOB를 살펴보겠습니다. 데이터베이스에 LOB가 없다면 다행이지만, LOB가 어떤 문제를 야기할 수 있는지 지금부터 설명해 드리겠습니다. LOB의 경우 마이그레이션 속도가 느려질 수도 있습니다. 마이그레이션 시간이 길어지고 복제 서버에 더 큰 메모리가 필요하게 됩니다. 아주 적은 수라도 LOB는 이동하기가 매우 어려울 수 있습니다. 게다가 LOB가 기본 키 또는 기타 고유한 제약 조건이 없는 테이블에 저장된다는 점도 문제가 됩니다. DBA가 10년 전쯤 첨단 기술에 관한 블로그에서 이 방식이 효과적이라는 글을 읽고 그렇게 만들었을지도 모를 일이죠. 이 같은 테이블은 CDC(변경 데이터 캡처) 스트림의 일부로서 해당 테이블을 변경하려 할 때 문제가 될 수 있습니다.
소스 데이터베이스에서 과부하를 방지하는 방법을 설명하기 전에, 마이그레이션 중에 데이터베이스 역할, 사용자 및 사용 권한을 다루는 작업에 얼마나 시간이 많이 허비되는지를 알아야 합니다. 대부분의 마이그레이션 도구에서는 메타데이터를 검색하고 로그를 읽고 변경 내용을 복제하는 데 소스 데이터베이스 카탈로그에 대한 관리자 액세스 권한이 필요합니다. 데이터베이스 역할 및 사용 권한 모델을 파악하거나 최소한 그러한 모델을 잘 아는 사람의 이름이라도 파악하여 액세스 권한을 부여할 수 있으면, 시간이 많이 절약됩니다.
마지막으로, 모든 형식, 스키마 및 LOB를 올바르게 처리하더라도 마이그레이션 속도가 느릴 수 있습니다. 경우에 따라 이 같은 속도 저하는 큰 문제가 될 수 있고 마이그레이션 프로젝트의 실패로 이어질 수 있습니다. 반대편에서 마지막 행이 표시될 때까지 걸리는 시간은 몇 가지 요인으로 결정됩니다. 그러한 요인 중에는 조정하기 쉬운 것도 있고 아닌 것도 있습니다.
첫 번째는 소스 데이터베이스 사용률입니다. 대부분의 마이그레이션 도구는 소스 데이터베이스에 어느 정도 부하를 가중시킵니다. 트래픽이 매우 높다면 실시간 마이그레이션을 계획하는 것은 현실성이 없으므로 다른 대안을 찾아야 합니다. 일반적으로 압축된 데이터베이스는 더 빠르게 마이그레이션되고 문제도 적게 발생하므로 데이터베이스가 마지막으로 언제 압축되었는지를 알아야 합니다. 압축되지 않았다면 압축하는 것이 좋습니다.
알아야 할 사항이 참 많고 이런 정보를 파악하려면 많은 사람과 협력해야 합니다. 하지만 이 같은 정보를 파악하면 처음 마이그레이션할 때 시간을 많이 절약하고 다음 마이그레이션 프로젝트에 활용할 몇 가지 모범 사례를 만들 수 있습니다.
DB 접속 네트워크 현황 파악하기
데이터베이스 마이그레이션을 수행하려면 여러분과 동료들이 네트워크와 관련한 방대한 지식을 갖추어야 합니다. 특히 전사적인 환경의 일부를 구성하는 데이터베이스를 마이그레이션할 때는 더 심층적인 지식이 요구됩니다. 이 같은 데이터베이스에 대한 네트워크 액세스는 여러 팀(보안, 네트워킹 등)에서 관리하는 경우가 많습니다. 방화벽 내에서 안전하게 포트를 열거나 라우팅을 변경하여 복제 서버가 데이터베이스에 액세스할 수 있게 하려면 이 같은 모든 관계자와 협의해야 할 수 있습니다. 또한 클라우드 제공업체에서 조직의 네트워크 설정을 어떻게 구성했는지에 대한 정보도 알아야 합니다.
마지막으로, 소스 데이터베이스와 타겟 데이터베이스 간의 연결 대역폭이 마이그레이션을 실행하기에 충분한지를 확인해야 합니다. 조직에서 클라우드 제공업체와 10GB 직접 연결을 구축한 경우에도 그 연결을 마이그레이션에 전적으로 사용할 수 있는 것은 아닙니다. 데이터 이동을 시작할 때 이 연결 성능 중 어느 정도를 마이그레이션에 사용하게 될지를 파악하고 테스트 데이터베이스 마이그레이션을 시작하면서 미션 크리티컬 워크로드에 지장을 주는 일은 없도록 해야 합니다.
애플리케이션 요구 사항 정리하기
하나 이상의 데이터베이스를 실행하는 대규모 서버를 하루 빨리 없애버리고 싶으실 겁니다. 하지만 그런 서버를 무엇으로 대체하게 될지 알고 계신가요? 새로운 환경의 주요 파리미터를 모두 아십니까? 이 같은 파라미터를 설정하기 위해 새로운 결정을 내려야 합니다. 일부는 기존 환경에서 그대로 가져오고, 일부는 애플리케이션에서 제어됩니다. 이 간단한 질문에 답해보십시오. 여러분이 사용하는 애플리케이션은 다운타임을 허용합니까? 허용되는 다운타임은 얼마나 됩니까? 대부분의 환경에는 20~30분의 다운타임만 허용하는 애플리케이션도 있고 몇 시간에 걸친 유지 관리 시간을 허용하는 애플리케이션도 있습니다. 팁을 하나 드리자면, 이 같은 애플리케이션을 첫 번째 프로젝트에 포함하는 것이 좋습니다. CDC(변경 데이터 캡처)를 처리할 필요가 없고 제거 및 복원 기능이나 기타 네이티브 도구를 사용하여 데이터베이스를 마이그레이션할 수 있습니다. 마이그레이션 방식에 영향을 주는 또 다른 중요한 요인은 마이그레이션이 완료된 후 소스 데이터베이스의 가용성을 계속 유지해야 할지 여부입니다. 그래야 한다면 필요할 때 어떻게 소스 데이터베이스로 되돌려야 할까요?
아무리 데이터베이스를 그대로 마이그레이션하더라도 새로운 플랫폼과 관련해 여러 가지 사항을 결정해야 합니다. 게다가 엔진을 바꾸는 경우에는 결정할 사항이 더 많습니다. 예를 들어 엔진의 선택 기준을 명확히 아십니까? 단순히 수석 개발자가 “요즘은 이 기술이 제일 핫 하다고”라고 말했기 때문일리는 없고, 합리적인 대화를 통해 애플리케이션, 팀, 일정에 맞는 특정 엔진을 선택했을 겁니다.
또한 모든 데이터를 마이그레이션해야 할지 여부를 결정하는 것도 중요합니다. 데이터베이스의 97%가 감사 로그 테이블인 경우를 예로 들어보겠습니다. 규정 준수를 위해 그렇게 방대한 로그가 필요하겠지만 라이브 마이그레이션하는 것이 아니라 나중에 아카이빙하는 건 어떨까요? 다른 예로, 데이터베이스에 새 플랫폼에서 제공되지 않는 기능을 지원하던 불필요한 테이블이 있는 경우를 들 수 있습니다.
모든 데이터를 이동해야 하더라도 이 마이그레이션을 기회로 삼아 일부 데이터의 대안을 평가해볼 수 있습니다. 예를 들어 새로운 환경에서는 NoSQL 저장소나 데이터 웨어하우스를 사용할 수 있습니다. 일반적으로 환경을 단순하게 유지할수록 좋습니다. 데이터를 먼저 이동한 후 변환하거나 재구성하거나 재설계하는 것입니다. 마이그레이션 시에 데이터베이스의 소스 코드를 변경하는 것이 이 같은 작업을 수행할 유일한 기회일 수 있습니다. 어떤 경우든 데이터 모델을 미리 계획하고 분석하는 것이 좋습니다. 마이그레이션을 완료한 후 데이터 모델을 변경할 예정이라도 마찬가지입니다.
마지막으로, 아무리 철저히 준비하더라도 마이그레이션 도중이나 이후에 문제는 얼마든지 발생할 수 있습니다. 따라서 항상 비상 계획을 수립해야 합니다. 원래 상태로 되돌릴 수 있는지, 이전 데이터베이스와 새 데이터베이스에서 동시에 애플리케이션을 실행할 수 있는지, 일정 시간 동안 데이터 가용성 손실이 발생해도 문제가 없는지 등을 점검해야 합니다. 이러한 사항을 확인하면 비상 계획을 수립하는 데 도움이 됩니다.
타겟 스키마 생성하기
타겟 데이터베이스 스키마와 관련해서도 고려해야 할 사항이 있습니다. 동종 간 마이그레이션의 경우에도 스키마를 단계적으로 적용하는 것이 좋습니다. 데이터를 이동하기 전에 테이블 및 기본 키를 준비해야 합니다. 하지만 성능 및 다른 이유로, 보조 인덱스를 생성하고 제약 조건을 나중에 적용하는 편이 나을 수 있습니다. 또한 초기 데이터 로드를 위해 트리거를 비활성화하는 것이 좋습니다. 요점은 누군가 단계적으로 적용되도록 스키마를 준비해야 한다는 것입니다. 엔진을 바꾸는 경우에는 앞서 언급한 AWS Schema Conversion Tool을 사용하면 이 같은 작업을 일부 수행하는 데 도움이 됩니다. 또한 꼭 필요하지 않는 한, 모든 스키마 변환은 마이그레이션이 끝난 후에 실행하는 것이 좋습니다.
AWS로 마이그레이션하기
클라우드마다 마이그레이션하는 단계가 다르고 해당 클라우드 생태계에 대한 전문 지식이 요구됩니다. 즉, 네트워킹, 사용 권한, 역할, 계정 등을 세부적으로 파악해야 합니다. 일반적인 클라우드의 작동 방식을 알아야 하는 것은 물론, 회사의 구체적인 클라우드 구현 방식도 철저히 숙지해야 합니다. 게시물의 이 섹션에서는 AWS로의 마이그레이션과 관련한 몇 가지 고유한 사항을 살펴보고 새로운 환경의 이점 및 한계와 관련해 무엇을 확인해야 할지를 알아봅니다.
앞서 말했듯 AWS는 고객이 마이그레이션 프로젝트를 성공적으로 진행할 수 있도록 다양한 도구와 지원 자료를 개발했습니다. 그중 매우 중요한 첫 번째 도구는 바로 설명서입니다. DMS 설명서와 SCT 설명서를 꼭 읽어보시기 바랍니다. 물론, 상세 로그를 설정하는 방법도 알고, 대부분의 Oracle 데이터 형식을 기억하고, 데이터 형식이 데이터베이스 엔진의 나머지 부분에 어떻게 매핑되는지 정도는 알고 계실 겁니다. 그래도 설명서를 꼼꼼히 읽어보시기 바랍니다. 그러면 마이그레이션 과정에서 시간과 스트레스를 많이 줄일 수 있습니다. AWS DMS 평가 보고서는 발생할 수 있는 여러 가지 문제를 분석하여 마이그레이션을 시작하기 전에 경고해 줍니다. DMS 및 SCT 포럼에서도 프로젝트를 시작하기 전에 유용한 정보를 참조할 수 있습니다. 일련의 세부 플레이북도 참조할 수 있습니다. 마지막으로 GitHub 리포지토리에는 대부분의 마이그레이션 관련 블로그 게시물에 사용된 도구, 예제, AWS CloudFormation 템플릿이 수록되어 있습니다.
대부분의 사용 사례에서는 관리형 서비스의 이점을 활용할 수 있는 Amazon RDS를 타겟 데이터베이스로 사용하는 것이 당연한 선택입니다. 따라서 백업, OS 및 데이터베이스 패치, 보안, 고가용성, 확장성, 탄력성, AWS 생태계와의 통합 등 관련 사항을 숙지해야 합니다. RDS를 사용하면 이 같은 작업에 시간을 허비하지 않아도 됩니다.
하지만 제한 사항도 있습니다. 스토리지 한도, 데이터베이스에 대한 관리 권한의 부재 등 이 같은 제한 사항도 숙지해야 합니다. 데이터베이스 호스트에 액세스할 필요가 있는지를 신중하게 판단해야 합니다. 물론 DBA는 데이터베이스 시스템에 대한 SSH 액세스가 불가능하면 세상이 끝나는 것처럼 말하겠지만, 정말로 그럴까요? 일부 애플리케이션에는 이 액세스가 필요하지만 대부분의 경우에는 DBA가 데이터베이스 관리 권한을 잃더라도 아무 문제가 없습니다.
게다가 Amazon RDS는 다양한 관리형 HA(고가용성) 기능을 제공합니다. 이쯤에서 여러분의 HA 요구 사항을 한번 다시 검토해 보십시오. 현재 설정에는 MySQL 스탠바이가 몇 개 포함되어 있을 겁니다. 이런 스탠바이를 둘 이유가 있나요? 더 나은 성능을 얻거나 번거로움을 덜기 위해서? 데이터베이스 담당자가 호스트 액세스를 원하는 이유가 바로 이러한 스탠바이 때문일 수 있습니다. 이 같은 결정 중 일부는 마이그레이션 후에 내려도 된다는 사실을 알아야 합니다. 예를 들어 MySQL 데이터베이스로 마이그레이션하는 경우 Amazon RDS 단일 AZ MySQL(실제로 더 빠름)로 마이그레이션한 후에 Amazon RDS 다중 AZ 인스턴스로 변환하거나 한발 더 나아가 Amazon Aurora를 이용해도 아무런 문제가 없습니다.
마지막으로, AWS는 평가를 실시하고 작업 범위를 정하며 마이그레이션 프로젝트를 실행하는 데 도움을 줄 수 있는 수많은 마이그레이션 파트너를 제공합니다.
마무리
데이터베이스 마이그레이션 프로젝트는 특히 처음으로 진행하는 경우에 무척 까다로울 수 있지만 데이터베이스를 클라우드로 마이그레이션 함으로서 얻게 되는 이점은 마이그레이션으로 인한 문제보다 훨씬 큽니다. 시작하기 전에 철저하게 준비하고 필요한 정보를 수집하면 이 같은 문제를 예측하고 최소화할 수 있습니다. 수천의 AWS 고객이 이미 AWS의 지원을 받거나 단독으로 마이그레이션을 완료했습니다. 그중에는 제대로 준비하지 않고 나섰다가 마이그레이션 중에 수많은 문제를 겪은 사례도 있고 준비하는 데 시간을 투자하여 원활하게 마이그레이션을 완료한 사례도 있습니다.
아래의 체크리스트틀 활용하면 시작하기 전에 필요한 사항을 꼼꼼히 확인할 수 있습니다.
읽어 주셔서 감사합니다. 데이터베이스를 성공적으로 마이그레이션하시기를 바랍니다.
데이터베이스 마이그레이션 체크리스트
1. 데이터베이스의 크기가 얼마입니까?
2. 스키마와 테이블의 수는 몇 개입니까?
3. 크기가 아주 큰(200기가바이트 또는 행 2억 개 이상) 테이블은 몇 개나 있습니까?
4. 트랜잭션 경계는 어떻게 설정되어 있습니까?
5. 현재 마이그레이션 도구로는 마이그레이션되지 않는 엔진의 고유한 데이터 형식이 있습니까?
6. 테이블에 LOB에 있습니까? LOB의 크기는 얼마나 됩니까?
7. LOB가 포함된 모든 테이블에 기본 키가 있습니까?
8. 소스 데이터베이스의 사용률은 얼마나 됩니까?
9. 소스 데이터베이스에는 어떤 유형의 사용자, 역할 및 사용 권한이 있습니까?
10. 언제 마지막으로 데이터베이스를 정리하거나 압축했습니까?
11. 데이터베이스에는 어떤 방법(방화벽, 터널, VPN)으로 액세스할 수 있습니까?
12. AWS에서 어떤 VPC를 사용할지 알고 계십니까?
13. 사용할 수 있는 VPC 보안 그룹을 알고 계십니까?
14. 모든 데이터를 이동하기에 대역폭이 충분합니까?
15. 다운타임이 허용됩니까? 얼마나 허용됩니까?
16. 마이그레이션 후에 소스 데이터베이스를 가용 상태로 유지해야 합니까? 얼마 동안 유지해야 합니까?
17. 귀사에서 특정 타겟 데이터베이스 엔진을 선호하는 이유를 아십니까?
18. HA(고가용성) 요구 사항은 어떻게 됩니까?
19. 모든 데이터를 이동해야 합니까?
20. 같은 위치로 이동해야 합니까?
21. Amazon RDS가 제공하는 이점을 알고 있습니까?
22. 귀사에 영향을 미치는 Amazon RDS의 제한 사항을 알고 있습니까?
23. 마이그레이션 후에 애플리케이션은 어떻게 됩니까?
24. 문제가 발생할 경우에 대비한 비상 계획은 어떻게 됩니까?
이 글은 AWS Database Blog의 Database Migration—What Do You Need to Know Before You Start?의 한국어 번역입니다.
Source: 클라우드로 데이터 베이스 이전을 시작할 때 알아두어야 할 점
