다음을 통해 공유

Microsoft 365 및 Office 365 이메일 마이그레이션 성능 및 모범 사례

  • 아티클

온-프레미스에서 호스트되는 조직의 전자 메일 데이터를 Microsoft 365 또는 Office 365로 마이그레이션하는 여러 경로가 있습니다. Microsoft 365 또는 Office 365로 마이그레이션을 계획할 때 데이터 마이그레이션 프로세스 및 속도를 명확하게 이해하면 관리자가 더 나은 계획을 세울 수 있습니다.

Microsoft 365 또는 Office 365로 전자 메일 마이그레이션 개요

Microsoft 365 또는 Office 365는 여러 전자 메일 계정을 Microsoft 365 또는 Office 365로 마이그레이션하는 방법에 설명된 대로 기존 메시징 환경에서 Microsoft 365 또는 Office 365로 전자 메일, 일정 및 연락처 데이터를 마이그레이션하는 여러 가지 방법을 지원합니다.

Microsoft 365 또는 Office 365에 대한 네트워킹 및 성능 관련 질문은 Microsoft 365 또는 Office 365에 대한 네트워크 계획 및 성능 조정을 참조하세요.

자주 사용하는 마이그레이션 방법

마이그레이션 방법 설명 리소스
IMAP(Internet Message Access Protocol) 마이그레이션 Exchange 관리 센터 또는 Exchange Online PowerShell을 사용하여 사용자의 사서함 콘텐츠를 IMAP 메시징 시스템에서 Microsoft 365 또는 Office 365 사서함으로 마이그레이션할 수 있습니다. 여기에는 Gmail 또는 Yahoo Mail과 같은 다른 호스팅 전자 메일 서비스의 사서함을 마이그레이션하는 경우가 포함됩니다. Exchange Online은 이제 기존 Gmail/G Suite/GWS(Google WorkSpace) 배포 조직에서 Exchange Online으로 전자 메일을 마이그레이션하기 위한 최신 EAC의 고도로 전문화된 프로세스를 제공합니다. IMAP 사서함을 Microsoft 365 또는 Office 365로 마이그레이션
단독형 마이그레이션 단독형 마이그레이션을 사용하여 며칠 동안 모든 온-프레미스 사서함을 Microsoft 365 또는 Office 365로 마이그레이션합니다. 전체 전자 메일 조직을 Microsoft 365 또는 Office 365로 이동하고 Microsoft 365 또는 Office 365에서 사용자 계정을 관리하려는 경우 단독형 마이그레이션을 사용합니다. 단독형 마이그레이션을 사용하여 온-프레미스 Exchange 조직에서 Microsoft 365 또는 Office 365로 최대 2,000개의 사서함을 마이그레이션할 수 있습니다. 그러나 권장되는 사서함 수는 150개입니다. 성능이 그보다 높은 숫자로 성능이 저하 될 수 있습니다. 온-프레미스 Exchange 조직의 메일 연락처 및 배포 목록도 마이그레이션됩니다. Microsoft 365 또는 Office 365로 단독형 마이그레이션
미리 구성된 마이그레이션 시간이 지남에 따라 조직의 모든 사서함을 Microsoft 365 또는 Office 365로 마이그레이션하려는 경우 단계적 마이그레이션을 사용합니다. 단계적 마이그레이션을 사용하여 몇 주 또는 몇 달 동안 온-프레미스 사서함의 일괄 처리를 Microsoft 365 또는 Office 365로 마이그레이션합니다. Microsoft 365 또는 Office 365로 미리 구성된 전자 메일 마이그레이션에 대해 알아야 할 사항
하이브리드 배포 하이브리드 배포는 조직에 기존 온-프레미스 Exchange 조직에서 제공하는 풍부한 기능 환경 및 관리 제어를 클라우드로 확장할 수 있는 기능을 제공합니다. 하이브리드 배포는 온-프레미스 Exchange 조직과 Microsoft 365 또는 Office 365의 Exchange Online 간에 단일 Exchange 조직의 원활한 모양과 느낌을 제공합니다. 또한 하이브리드 배포는 Microsoft 365 또는 Office 365 조직으로 완전히 이동하는 중간 단계로 사용될 수 있습니다. Microsoft 365 및 Office 365 메일 마이그레이션 관리자

Exchange Server 하이브리드 배포

메일 마이그레이션 관리자

Exchange용 Exchange 배포 도우미 온-프레미스 2013/2016/2019

Exchange Server 2013 하이브리드 배포

최소 하이브리드 구성
타사 마이그레이션 타사에서 제공하는 도구가 많이 있습니다. 그들은 독특한 프로토콜과 접근 방식을 사용하여 GWS, GoDaddy, Yahoo, IBM Lotus Notes 및 Novell GroupWise와 같은 이메일 플랫폼에서 이메일 마이그레이션을 수행합니다. 타사 플랫폼에서 Exchange 마이그레이션을 수행하는 데 도움이 될 수 있는 몇 가지 타사 마이그레이션 도구 및 파트너는 다음과 같습니다.

이진 트리 / 퀘스트 / QuadroTech: 이진 트리 및 QuadroTech는 이제 퀘스트의 일부입니다. Quest는 여러 플랫폼을 Exchange Online으로 분석, 공존 및 마이그레이션하기 위한 제품과 함께 플랫폼 간 메시징 마이그레이션 및 공존 소프트웨어의 공급자입니다. 퀘스트 솔루션은 마이그레이션 전체에서 공존을 유지하면서 사서함, 공용 폴더 및 일정 정보를 동기화합니다.

BitTitan: 다양한 플랫폼에서 Microsoft 365 또는 Office 365로 마이그레이션하기 위한 자동화된 솔루션을 제공합니다.

CodeTwo: 보안 및 자동화된 데이터를 Exchange 온-프레미스, IMAP 서버 및 Microsoft 365 테넌트 간에 Microsoft 365(Office 365)로 안전하게 마이그레이션하기 위한 Microsoft 365 및 Office 365 마이그레이션 솔루션 공급자입니다.

Transvault: Exchange 및 Notes에서 Microsoft 365로 클라우드 Office 마이그레이션 솔루션 공급자. Transvault는 마이그레이션을 위해 수십 개의 원본을 지원하며 프로젝트 크기, 복잡한 이메일 보관 마이그레이션 및 PST 관리를 제공하는 제품을 제공합니다. 엔터프라이즈 마이그레이션 솔루션은 안전하고 규정을 준수하며 효율적이며 사용자 중심이며 온-프레미스와 클라우드에서 모두 실행할 수 있습니다.

SkyKick: 여러 원본 유형에서 Microsoft 365 또는 Office 365로 이동하는 자동화된 마이그레이션 솔루션 공급자입니다. 종단 간 마이그레이션 도구는 파트너가 마이그레이션 프로젝트의 영업, 계획, 마이그레이션, 관리 및 온사이트 단계를 수행하는 데 도움을 줍니다.

BCC: 협업 마이그레이션 전략을 지원하여 기업을 지원합니다. Microsoft Exchange, Microsoft 365 및 Office 365로 마이그레이션하기 위해 Domino 플랫폼을 기반으로 하는 마이그레이션 도구의 동급 최고의 공급업체입니다.

마이그레이션 방법에 대한 성능

다음 섹션에서는 사서함 마이그레이션 워크로드 및 사서함 및 사서함 데이터를 Microsoft 365 또는 Office 365로 마이그레이션하기 위한 다양한 마이그레이션 방법에 대한 관찰된 성능 결과를 비교합니다. 이러한 결과는 내부 테스트 및 Microsoft 365 또는 Office 365로의 실제 고객 마이그레이션을 기반으로 합니다.

중요

마이그레이션 수행 방식과 마이그레이션 수행 시기의 차이로 인해 실제 마이그레이션 속도가 달라질 수 있습니다.

고객 마이그레이션 워크로드

다음 표에서는 일반적인 마이그레이션과 관련된 다양한 워크로드와 각 워크로드에 대한 과제 및 옵션에 대해 설명합니다.

워크로드 참고
온보딩(Microsoft 365 또는 Office 365로 마이그레이션) Microsoft는 고객이 Exchange Server 온-프레미스(컷오버스테이징//하이브리드를 통해) 또는 Gmail/S Suite/GWS 일명 Google 작업 공간(EAC, PowerShell을 통해) 또는 기타 IMAP 원본(PowerShell, IMAP를 통한 Gmail) 또는 테넌트 간 마이그레이션에서 Microsoft 365 또는 Office 365의 Exchange Online으로 데이터를 마이그레이션하는 데 사용할 수 있는 데이터 마이그레이션 기능 및 도구를 제공합니다.
Multi-Geo 전 세계에 지사가 있는 다국적 기업은 데이터 상주 요구 사항을 충족하기 위해 특정 지역에 직원 데이터를 저장해야 하는 경우가 많습니다. Multi-Geo를 사용하면 단일 Microsoft 365 또는 Office 365 조직이 여러 Microsoft 365 또는 Office 365 데이터 센터 지리(지리적 위치)에 걸쳐 확장할 수 있으며, 이를 통해 Exchange 데이터를 사용자 단위로 선택한 지역에 저장할 수 있습니다. 자세한 내용은 Multi-Geo를 사용하여 엔터프라이즈급 글로벌 데이터 위치 컨트롤 가져오기를 참조하세요.
암호화 고객 키를 사용한 서비스 암호화는 고객이 Microsoft 365 또는 Office 365의 애플리케이션 계층에서 미사용 데이터를 암호화하는 데 사용되는 루트 키를 프로비전하고 관리할 수 있는 기능입니다. 사서함을 처음으로 암호화하려면 사서함 이동이 필요합니다. 자세한 내용은 Microsoft Purview 고객 키를 사용하여 서비스 암호화를 참조하세요.
GoLocal Microsoft는 새 지역 또는 지역에서 새 데이터 센터를 계속 열고 있습니다. 기존 고객은 적격한 경우 원래 데이터 센터의 고객 데이터를 새 지리적 위치로 이동하도록 요청할 수 있습니다. 이 요청을 수행할 수 있는 기간은 일반적으로 서비스에 대한 전체 수요에 따라 1년 또는 2년입니다. 새 지역 시작에 대한 데이터 센터(DC)가 시작되면 고객 데이터를 이동하도록 요청할 수 있는 이 기간이 짧아집니다(이 시점에서 이동을 요청하는 데 약 3~6개월이 있음). 자세한 내용은 핵심 데이터를 새 Microsoft 365 데이터 센터 지리적 위치로 이동에서 확인할 수 있습니다.

Microsoft 365 데이터 센터 내에서 사서함을 마이그레이션하는 경우 모든 사서함 이동 또는 대량 사서함 이동은 작업을 완료하는 데 시간이 필요합니다. Microsoft 365 서비스 활동과 같은 여러 가지 요인이 있으며, 이는 정확한 시간에 영향을 줄 수 있습니다. 이 서비스는 사서함 이동과 같은 임의 워크로드를 제한하여 서비스가 모든 사용자에 대해 최적으로 실행되도록 설계되었습니다. 그러나 서비스의 임의 리소스 가용성에 따라 사서함 이동이 처리될 것으로 예상할 수 있습니다. 리소스 제한에 대한 자세한 내용은 이 블로그 게시물에서 확인할 수 있습니다.

Exchange Online의 사서함 마이그레이션 기간 예상 시간

마이그레이션을 계획하는 데 도움이 되도록 다음 표에서는 대량 사서함 마이그레이션 또는 개별 마이그레이션이 완료되는 시기를 위한 지침을 제공합니다. 이러한 추정치는 이전 고객 마이그레이션의 데이터 분석을 기반으로 합니다. 모든 환경이 고유하기 때문에 정확한 마이그레이션 속도는 다를 수 있습니다.

사서함 크기 프로필에 따라 사서함 마이그레이션 기간:

  • GoLocal/다중 지역/Exchange Online의 암호화

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    GoLocal/다중 지역/암호화 0 - 10 1 1
    GoLocal/다중 지역/암호화 10 - 50 2 6
    GoLocal/다중 지역/암호화 50 - 100 4 11
    GoLocal/다중 지역/암호화 100 - 200 6 14
    GoLocal/다중 지역/암호화 > 200 지원되지 않음 지원되지 않음

  • 온-프레미스 Exchange 서버에서 Exchange Online으로 온보딩(단독/형 하이브리드/)

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    온-프레미스에서 온보딩 0 - 10 1 3
    온-프레미스에서 온보딩 10 - 50 2 6
    온-프레미스에서 온보딩 50 - 100 4 13
    온-프레미스에서 온보딩 100 - 200 10 31
    온-프레미스에서 온보딩 > 200 지원되지 않음 지원되지 않음

  • 테넌트 간 Exchange Online 마이그레이션( Microsoft 자사 솔루션 사용 또는 타사 솔루션 사용).

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    테넌트 간 0 - 10 1 1
    테넌트 간 10 - 50 1 2
    테넌트 간 50 - 100 2 5
    테넌트 간 100 - 200 3 6
    테넌트 간 > 200 지원되지 않음 지원되지 않음

  • Gmail/G Suite/GWS(EAC, PowerShell)에서 Exchange Online에 특수 온보딩

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    특수 Gmail 온보딩 0 - 10 1 2
    특수 Gmail 온보딩 10 - 50 1 8
    특수 Gmail 온보딩 50 - 100 3 12
    특수 Gmail 온보딩 100 - 200 5 19
    특수 Gmail 온보딩 > 200 지원되지 않음 지원되지 않음

  • IMAP 원본에서 Exchange Online에 온보딩 (기타 IMAP 원본, PowerShell, IMAP를 통한 Gmail)

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    일반 IMAP 온보딩 0 - 10 1 1
    일반 IMAP 온보딩 10 - 50 1 2
    일반 IMAP 온보딩 50 - 100 1 8
    일반 IMAP 온보딩 100 - 200 3 29
    일반 IMAP 온보딩 > 200 지원되지 않음 지원되지 않음

  • PST 가져오기를 통해 Exchange Online에 온보딩

    워크로드 사서함 크기(GB) P50(50번째 백분위수 기간)(일) P90(90번째 백분위수 기간)(일)
    PST 가져오기 0 - 10 1 1
    PST 가져오기 10 - 50 1 3
    PST 가져오기 50 - 100 2 5
    PST 가져오기 100 - 200 3 6
    PST 가져오기 > 200 지원되지 않음 지원되지 않음

참고

일부 이상값 사서함은 사서함 프로필에 따라 완료하는 데 더 오래 걸립니다. 또한 테넌트에서 평균적으로 사서함이 더 큰 경우 마이그레이션 기간이 길어질 수도 있습니다.

마이그레이션 성능 요인

사서함/전자 메일 마이그레이션에는 마이그레이션 성능에 영향을 주는 몇 가지 일반적인 요소가 있습니다.

일반적인 마이그레이션 성능 요인

다음 표에는 마이그레이션 성능에 영향을 주는 일반적인 요인 목록이 표시되어 있습니다. 자세한 내용은 개별 마이그레이션 방법을 설명하는 섹션에 나와 있습니다.

요인 설명 예제
데이터 원본 마이그레이션할 데이터를 호스트하는 장치 또는 서비스입니다. 하드웨어 사양, 최종 사용자 작업 및 백 엔드 유지 관리 작업으로 인해 데이터 원본에 많은 제한 사항이 적용될 수 있습니다. Gmail은 특정 기간 동안 추출할 수 있는 데이터의 양을 제한합니다.
데이터 형식 및 밀도 고객 비즈니스의 고유한 특성으로 인해 사서함 내 메일 항목의 유형과 조합은 매우 다양합니다. 각각 10MB의 첨부 파일이 포함된 400개의 항목이 있는 4GB 사서함 하나는 더 작은 100,000개의 항목이 있는 4GB 사서함 하나보다 빠르게 마이그레이션됩니다.
마이그레이션 서버 대부분의 마이그레이션 솔루션에서는 "점프 박스" 유형의 마이그레이션 서버 또는 워크스테이션을 사용하여 마이그레이션을 완료합니다. 일반적으로 고객은 성능이 낮은 가상 컴퓨터를 사용하여 하이브리드 배포 또는 클라이언트 PC 비하이브리드 마이그레이션을 위한 MRSProxy 서비스를 호스트합니다.
마이그레이션 엔진 원본 서버에서 데이터를 끌어와야 하는 데이터 마이그레이션 엔진은 필요한 경우 데이터를 변환합니다. 그런 다음 엔진은 네트워크를 통해 데이터를 전송하고 Microsoft 365 또는 Office 365 사서함에 데이터를 삽입합니다. 사서함. MRSProxy 서비스는 자체적인 기능 및 제한 사항이 있습니다.
온-프레미스 네트워크 어플라이언스 엔드 투 엔드 네트워크 성능(데이터 원본에서 Exchange Online 클라이언트 액세스 서버로)은 마이그레이션 성능에 영향을 줍니다. 온-프레미스 조직의 방화벽 구성 및 사양.
Microsoft 365 또는 Office 365 서비스 Microsoft 365 및 Office 365에는 마이그레이션 워크로드를 관리하는 기본 제공 지원 및 기능이 있습니다. 사용자 제한 정책은 기본 설정을 포함하며 전체 최대 데이터 전송 속도를 제한합니다.

네트워크 성능 요인

이 섹션에서는 마이그레이션 중에 네트워크 성능을 개선하기 위한 모범 사례에 대해 설명합니다. 마이그레이션하는 동안 네트워크 성능에 대한 가장 큰 영향은 타사 하드웨어 및 ISP(인터넷 서비스 공급자)와 관련되므로 설명은 일반적인 사항을 다룹니다.

Exchange Analyzer를 사용하여 Microsoft 365 또는 Office 365와의 네트워크 연결에 대한 심층적인 이해를 얻을 수 있습니다. Microsoft 지원 및 복구 도우미에서 Exchange Analyzer 테스트를 실행하려면 고급 진단 > Exchange Online > Check Exchange Online 네트워크 연결 예로 > 이동합니다. Microsoft 지원 및 복구 도우미에 대해 자세히 알아보려면 Microsoft 지원 및 복구 도우미에 대해 읽어보세요.

요인 설명 모범 사례
네트워크 용량 사서함을 Microsoft 365 또는 Office 365로 마이그레이션하는 데 걸리는 시간은 네트워크의 사용 가능한 용량과 최대 용량에 따라 결정됩니다. 사용 가능한 네트워크 용량을 식별하고 최대 업로드 용량을 확인합니다.
ISP에 문의하여 할당된 대역폭을 확인하고 특정 기간에 전송될 수 있는 총 데이터 양과 같은 제한 사항에 대한 자세한 정보를 얻습니다.
도구를 사용하여 실제 네트워크 용량을 평가합니다. 온-프레미스 데이터 원본에서 Microsoft 데이터 센터 게이트웨이 서버로의 종단 간 데이터 흐름을 테스트하도록 합니다.
네트워크 용량에 영향을 줄 수 있는 네트워크의 다른 부하(예: 백업 유틸리티 및 예약된 유지 관리)를 식별합니다.
네트워크 안정성 네트워크가 빠르다고 해서 항상 마이그레이션이 빠르게 진행되는 것은 아닙니다. 네트워크가 안정적이지 않으면 오류 수정으로 인해 데이터 전송에 시간이 더 오래 걸립니다. 마이그레이션 유형에 따라 오류 수정은 마이그레이션 성능에 상당한 영향을 줄 수 있습니다. 네트워크 하드웨어 및 드라이버 문제는 흔히 네트워크 안정성 문제를 일으킵니다. 하드웨어 공급업체에 문의하여 네트워크 장치를 이해하고 공급업체에서 권장하는 최신 드라이버 및 소프트웨어 업데이트를 적용합니다.
네트워크 지연 네트워크 방화벽에 구성된 침입 감지 기능은 흔히 상당한 네트워크 지연을 일으키며 마이그레이션 성능에 영향을 줍니다.
Microsoft 365 또는 Office 365 사서함으로 데이터를 마이그레이션하는 것은 인터넷 연결에 의존합니다. 인터넷 지연은 전체 마이그레이션 성능에 영향을 줍니다.
또한 같은 회사의 사용자들이 서로 다른 지리적 위치에 있는 데이터 센터에 상주하는 클라우드 사서함을 보유할 수 있습니다. 고객의 ISP에 따라 마이그레이션 성능이 다를 수 있습니다.		 모든 잠재적 Microsoft 데이터 센터에 대한 네트워크 지연을 평가하여 결과가 일관되게 합니다. (이렇게 하면 최종 사용자가 일관된 환경을 유지할 수 있습니다.) ISP와 협력하여 인터넷 관련 문제를 해결합니다.
허용 목록에 Microsoft 데이터 센터 서버의 IP 주소를 추가하거나 네트워크 방화벽에서 모든 마이그레이션 관련 트래픽을 무시합니다. Microsoft 365 또는 Office 365 IP 범위에 대한 자세한 내용은 Microsoft 365 및 Office 365 URL 및 IP 주소 범위를 참조하세요.

사용자 환경 내의 마이그레이션에 대한 심층 분석을 보려면 사서함 마이그레이션 성능 분석을 확인하세요. 이 게시물에는 이동 요청을 분석하는 데 도움이 되는 스크립트가 포함되어 있습니다.

Microsoft 365 및 Office 365 제한

Microsoft 365 및 Office 365는 다양한 제한 메커니즘을 사용하여 보안 및 서비스 가용성을 보장합니다. 다음과 같은 세 가지 유형의 제한은 마이그레이션 성능에 영향을 줄 수 있습니다.

  • 사용자 제한
  • 마이그레이션 서비스 제한
  • 리소스 상태 기반 제한

참고

세 가지 유형의 Microsoft 365 및 Office 365 제한은 모든 마이그레이션 방법에 영향을 주지 않습니다.

Microsoft 365 및 Office 365 사용자 제한

사용자 제한은 대부분의 타사 마이그레이션 도구 및 클라이언트 업로드 마이그레이션 방법에 영향을 줍니다. 이러한 마이그레이션 방법은 HTTP 프로토콜을 통한 RPC(원격 프로시저 호출)와 같은 클라이언트 액세스 프로토콜을 사용하여 사서함 데이터를 Microsoft 365 또는 Office 365 사서함으로 마이그레이션합니다. 이러한 도구는 IBM Lotus Domino 및 Novell GroupWise와 같은 플랫폼에서 데이터를 마이그레이션하는 데 사용됩니다.

사용자 제한은 Microsoft 365 및 Office 365에서 가장 제한적인 제한 방법입니다. 사용자 제한은 개별 최종 사용자에 대해 작동하도록 설정되므로, 응용 프로그램 수준 사용량은 쉽게 제한 정책을 초과하여 데이터 마이그레이션 속도가 느려집니다.

Microsoft 365 및 Office 365 마이그레이션 서비스 제한

마이그레이션 서비스 제한은 모든 Microsoft 365 또는 Office 365 마이그레이션 도구에 영향을 줍니다. 마이그레이션 서비스 제한은 Microsoft 365 또는 Office 365 마이그레이션 솔루션에 대한 마이그레이션 동시성 및 서비스 리소스 할당을 관리합니다.

마이그레이션 서비스 제한은 다음 마이그레이션 방법을 사용하여 수행되는 마이그레이션에 영향을 줍니다.

  • IMAP 마이그레이션
  • 단독형 Exchange 마이그레이션
  • 미리 구성된 Exchange 마이그레이션
  • 하이브리드 마이그레이션(하이브리드 환경의 MRSProxy 서비스 기반 이동)

중요

앞서 언급한 마이그레이션 방법은 사용자 제한의 영향을 받지 않습니다.

마이그레이션 서비스 제한의 예는 간단한 Exchange 마이그레이션 및 IMAP 마이그레이션 중에 동시에 마이그레이션되는 사서함의 수를 제어하는 것입니다. 기본값은 20입니다. 즉, 모든 마이그레이션 일괄 처리에서 최대 20개의 사서함이 언제든지 마이그레이션됩니다. Exchange 관리 센터 또는 Windows PowerShell에서 마이그레이션 일괄 처리에 대한 동시 사서함 마이그레이션 수를 늘릴 수 있습니다. 이 설정을 최적화하는 방법에 대한 자세한 내용은 Microsoft 365 또는 Office 365에서 마이그레이션 일괄 처리 관리를 참조하세요.

Microsoft 365 또는 Office 365 리소스 상태 기반 제한

모든 마이그레이션 방법은 가용성 제한 관리의 적용을 받습니다. 그러나 Microsoft 365 또는 Office 365 서비스 제한은 이전에 설명한 다른 유형의 제한만큼 Microsoft 365 또는 Office 365 마이그레이션에는 영향을 주지 않습니다.

리소스 상태 기반 제한은 가장 덜 공격적인 제한 방법입니다. 이 제한은 최종 사용자 및 중요한 서비스 작업에 영향을 주는 서비스 가용성 문제를 방지하기 위해 발생합니다.

서비스 성능이 최종 사용자 성능에 영향을 줄 수 있는 지점으로 저하되기 전에 하이브리드 마이그레이션은 성능이 복구되고 서비스가 제한 임계값 아래 수준으로 돌아갈 때까지 중단됩니다.

다음은 cmdlet을 사용하는 Get-MoveRequestStatistics - <> -IncludeReport 중단 기간과 관련하여 고객에게 표시되는 내용을 보여 줍니다.

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

솔루션 및 연습:

비슷한 상황이 발생하는 경우 Microsoft 365 또는 Office 365 리소스를 사용할 수 있게 될 때까지 기다립니다.

비하이브리드 배포 마이그레이션의 성능 요인 및 모범 사례

이 섹션에서는 IMAP, 단독형 또는 미리 구성된 마이그레이션 방법을 사용하는 마이그레이션에 영향을 주는 요인을 설명합니다. 또한 마이그레이션 성능을 개선하는 모범 사례도 설명되어 있습니다.

요소 1: 비 하이브리드 배포 마이그레이션을 위한 데이터 원본

아래 표에서는 현재 전자 메일 조직의 원본 서버가 마이그레이션에 주는 영향 및 마이그레이션에 대한 영향을 완화하기 위한 모범 사례를 설명합니다.

검사 목록 설명 모범 사례
시스템 성능 데이터 추출은 많은 주의를 기울여야 하는 작업입니다. 원본 시스템에는 CPU 시간 및 메모리와 같은 충분한 리소스가 있어야 하고 원본 시스템은 최적의 마이그레이션 성능을 제공해야 합니다. 마이그레이션하는 동안 원본 시스템은 일반적인 최종 사용자 작업의 관점에서 봤을 때 자주 전체 용량에 가까워집니다. 시스템 리소스가 불충분한 경우 마이그레이션에서 발생하는 추가 작업은 최종 사용자에 영향을 줄 수 있습니다. 파일럿 마이그레이션 테스트 중에 시스템 성능을 모니터링합니다. 시스템의 작업량이 많은 경우 마이그레이션 속도가 느려지고 서비스 가용성 문제가 발생할 수 있으므로 특정 시스템에 대한 공격적인 마이그레이션 일정은 피하는 것이 좋습니다. 가능한 경우 하드웨어 리소스를 추가하여 원본 시스템 성능을 향상하고 작업 및 사용자를 마이그레이션과 관련 없는 다른 서버로 이동하여 시스템에 대한 부하를 줄입니다.

자세한 내용은 Exchange Server의 서버 상태 및 성능(2007, 2010, 2013, 2016, 2019)을 참조하세요.

참고: Exchange Server 2007 및 2010은 더 이상 적극적으로 지원되지 않습니다. Exchange 2013 서버 지원 종료는 2023년 4월로 예정되어 있습니다. Exchange Server 2016 및 2019는 2025년 10월까지 추가 지원됩니다. 자세한 내용은 Exchange Server 지원 가능성 매트릭스 를 참조하세요.

사서함 서버가 여러 대 있는 온-프레미스 Exchange 조직에서 마이그레이션하는 경우 여러 사서함 서버에 걸쳐 균등하게 분산되는 마이그레이션 사용자 목록을 만드는 것이 좋습니다. 개별 서버 성능에 따라 이 목록을 미세 조정하여 처리량을 최대화할 수 있습니다.

예를 들어 서버 A에서 사용 가능한 리소스가 서버 B보다 50% 더 많은 경우에는 동일한 마이그레이션 일괄 처리에서 서버 A에 사용자를 50% 더 많이 배치하는 것이 적절합니다. 다른 원본 시스템에 비슷한 모범 사례를 적용할 수 있습니다. 업무 시간 이후나 주말 및 공휴일과 같이 서버의 리소스 가용성이 최대일 때 마이그레이션을 수행합니다.
백 엔드 작업 마이그레이션 시간 중에 실행되는 기타 백 엔드 작업입니다. 업무 시간 후에 마이그레이션을 수행하는 것이 가장 좋습니다. 마이그레이션은 온-프레미스 서버에서 실행되는 유지 관리 작업(예: 데이터 백업)과 충돌하는 것이 일반적입니다. 마이그레이션 중에 실행될 수 있는 기타 시스템 작업을 검토하세요. 리소스를 많이 사용하는 다른 작업이 실행되고 있지 않을 때 데이터 마이그레이션을 수행하는 것이 좋습니다.
참고: 온-프레미스 Exchange를 사용하는 고객의 경우 일반적인 백 엔드 작업은 백업 솔루션 및 Exchange 저장소 유지 관리(2013, 2016, 2019)입니다.
제한 정책 일정 시간 동안 시스템에서 추출할 수 있는 데이터의 속도와 양에 대한 특정 제한을 설정하는 제한 정책으로 전자 메일 시스템을 보호하는 것이 일반적입니다. 전자 메일 시스템에 배포된 제한 정책을 확인합니다. 예를 들어 Google Mail은 특정 기간에 추출할 수 있는 데이터의 양을 제한합니다. 버전에 따라 Exchange에는 온-프레미스 메일 서버에 대한 IMAP 액세스(IMAP 마이그레이션에 사용됨) 및 RPC over HTTP 프로토콜 액세스(단독형 Exchange 마이그레이션 및 미리 구성된 Exchange 마이그레이션에 사용됨)를 제한하는 정책이 있습니다.

제한 설정을 확인하려면 Get-ThrottlingPolicy cmdlet을 실행합니다. 제한에 대한 자세한 내용은 (2007, 2010, 2013, 2016, 2019) 를 참조하세요.

IMAP 제한에 대한 자세한 내용은 IMAP 사서함을 Microsoft 365 또는 Office 365로 마이그레이션을 참조하세요.

2단계: 비 하이브리드 배포 마이그레이션을 위한 마이그레이션 서버

IMAP, 단독형 및 미리 구성된 마이그레이션은 클라우드에서 시작되는 데이터 가져오기 마이그레이션 방법이므로 전용 마이그레이션 서버가 필요하지 않습니다. 그러나 인터넷 연결 프로토콜 호스트(HTTP 프로토콜을 통한 IMAP 또는 RPC)는 사서함 및 사서함 데이터를 Microsoft 365 또는 Office 365로 마이그레이션하기 위한 마이그레이션 서버로 작동합니다. 따라서 현재 전자 메일 조직의 데이터 원본 서버에 대한 이전 섹션에서 설명한 마이그레이션 성능 요소 및 모범 사례도 인터넷 에지 서버에 적용됩니다. Exchange 2007, Exchange 2010 및 Exchange 2013 조직의 경우 클라이언트 액세스 서버가 마이그레이션 서버 역할을 합니다.

자세한 내용은 다음 항목을 참조하세요.

3단계: 비 하이브리드 배포 마이그레이션을 위한 마이그레이션 엔진

IMAP, 단독형 및 준비된 Exchange 마이그레이션은 Exchange 관리 센터의 마이그레이션 대시보드를 사용하여 수행됩니다. Microsoft 365 또는 Office 365 마이그레이션 서비스 제한의 적용을 받습니다.

솔루션 및 연습:

이제 고객은 Windows PowerShell을 사용하여 마이그레이션 동시성(예: 동시에 마이그레이션할 사서함 수)을 지정할 수 있습니다. 기본값은 사서함 20개입니다. 마이그레이션 일괄 처리를 만든 후 다음 Windows PowerShell cmdlet을 사용하여 이 값을 최대값 100으로 늘릴 수 있습니다.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

자세한 내용은 Microsoft 365 또는 Office 365에서 마이그레이션 일괄 처리 관리를 참조하세요.

참고

데이터 원본에 모든 연결을 관리할 수 있는 충분한 리소스가 없는 경우 높은 동시성을 피하는 것이 좋습니다. 작은 동시성 값(예: 10)으로 시작하세요. 최종 사용자 액세스 문제를 방지하기 위해 데이터 원본 성능을 모니터링하는 동안 이 값을 늘리세요.

4단계: 비 하이브리드 배포 마이그레이션을 위한 네트워크

확인 테스트:

마이그레이션 방법에 따라 다음과 같은 유효성 검사 테스트를 시도할 수 있습니다.

  • IMAP 마이그레이션: 샘플 데이터를 사용하여 원본 사서함을 미리 채점합니다. 그런 다음 인터넷(온-프레미스 네트워크 외부)에서 Microsoft Outlook과 같은 표준 IMAP 전자 메일 클라이언트를 사용하여 원본 사서함에 연결한 다음 원본 사서함에서 모든 데이터를 다운로드하는 데 걸리는 시간을 결정하여 네트워크 성능을 측정합니다. 처리량은 다른 제약 조건이 없는 경우 Microsoft 365 또는 Office 365에서 IMAP 마이그레이션 도구를 사용하여 고객이 얻을 수 있는 것과 유사해야 합니다.

  • 단독형 및 준비된 Exchange 마이그레이션: 샘플 데이터로 원본 사서함을 미리 채점합니다. 그런 다음 인터넷(온-프레미스 네트워크 외부)에서 HTTP 프로토콜을 통해 RPC를 사용하여 Outlook을 사용하여 원본 사서함에 연결합니다. 캐시된 모드를 사용하여 연결하고 있는지 확인합니다. 원본 사서함에서 모든 데이터를 다운로드하는 데 걸리는 시간을 확인하여 네트워크 성능을 측정합니다. 처리량은 다른 제약 조건이 없다는 점을 감안할 때 Microsoft 365 또는 Office 365의 간단한 Exchange 마이그레이션 도구를 사용하여 고객이 얻을 수 있는 것과 유사해야 합니다.

실제 IMAP, 단독형 또는 미리 구성된 Exchange 마이그레이션 중에는 약간의 오버헤드가 있습니다. 그러나 실제 처리 속도는 이러한 유효성 검사 테스트 결과와 유사해야 합니다.

요소 5: 비 하이브리드 배포 마이그레이션을 위한 Microsoft 365 및 Office 365 서비스

Microsoft 365 또는 Office 365 리소스 상태 기반 제한은 기본 Microsoft 365 또는 Office 365 간단한 마이그레이션 도구를 사용하는 마이그레이션에 영향을 줍니다. Microsoft 365 또는 Office 365 리소스 상태 기반 제한 섹션을 참조하세요.

Microsoft 365 또는 Office 365에서 요청 이동

이동 요청에 대한 상태 정보를 가져오는 방법에 대한 일반적인 내용은 이동 요청 속성 보기를 참조하세요.

  • 이동 사서함

  • [Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)

Microsoft 365 또는 Office 365 서비스에서 마이그레이션 큐와 마이그레이션에 할당된 서비스 리소스는 테넌트 간에 공유되며 이동 프로세스의 각 단계에서 이동 요청을 관리하는 방법에 영향을 줍니다.

Microsoft 365 및 Office 365에는 두 가지 유형의 이동 요청이 있습니다.

  • "이동" 요청 온보딩: 새 고객 마이그레이션은 이동 요청을 온보딩하는 것으로 간주됩니다. 이러한 요청의 우선 순위는 보통입니다.

  • 데이터 센터 내부 "이동" 요청: 데이터 센터 운영 팀에서 시작한 사서함 이동 요청입니다. 이동 요청이 지연되더라도 최종 사용자 환경은 영향을 받지 않으므로 이러한 요청의 우선 순위는 더 낮습니다.

상태가 "대기" 및 "진행 중"인 이동 요청에 대한 잠재적 영향 및 지연

  • 대기 중인 이동 요청: 이 상태는 이동이 큐에 대기 중이며 Exchange 사서함 복제 서비스가 해당 이동을 선택할 때까지 대기 중임을 지정합니다. Exchange 2003 이동 요청의 경우 사용자는 이 단계에서 여전히 사서함에 액세스할 수 있습니다.

    다음과 같은 두 가지 요인이 사서함 복제 서비스에 의해 선택되는 요청에 영향을 줍니다.

    • 우선 순위: 우선 순위가 더 높은 대기 중인 이동 요청은 우선 순위가 낮은 이동 요청 전에 선택됩니다. 따라서 고객 마이그레이션 이동 요청은 항상 데이터 센터 내부 이동 요청보다 먼저 처리됩니다.

    • 큐의 위치: 이동 요청의 우선 순위가 같으면 요청이 큐에 더 일찍 들어갈수록 사서함 복제 서비스에서 더 일찍 선택됩니다. 동시에 사서함 마이그레이션을 수행하는 고객이 여러 명 있을 수 있으므로 새 이동 요청이 처리되기 전에 큐에 유지되는 것은 일반적입니다.

일반적으로 사서함 요청이 처리되기 전에 큐에서 기다리는 시간은 마이그레이션 계획 중에 고려되지 않습니다. 따라서 모든 계획된 마이그레이션을 완료하기에 충분한 시간이 할당되지 않는 고객이 발생하게 됩니다.

  • 진행 중인 이동 요청: 이 상태는 이동이 아직 진행 중임을 지정합니다. 온라인 사서함 이동인 경우 사용자는 여전히 사서함에 액세스할 수 있습니다.

사서함 이동 요청의 상태가 "진행 중"이 된 후에는 더 이상 우선 순위가 중요하지 않으며 새로운 이동 요청이 우선 순위가 더 높더라도 기존 "진행 중" 이동 요청이 완료될 때까지 새로운 이동 요청은 처리되지 않습니다.

모범 사례

계획: 앞에서 설명한 것처럼 Exchange 2003 사용자는 하이브리드 마이그레이션 중에 액세스 권한을 잃기 때문에 Exchange 2003 고객은 일반적으로 마이그레이션을 예약하는 시기와 소요 시간을 더 염려합니다.

특정 기간에 마이그레이션할 사서함 수를 계획할 때는 다음 사항을 고려하세요.

  • 이동 요청이 큐에서 대기하는 시간을 포함합니다. 다음을 사용하여 이 값을 계산합니다.

    (마이그레이션할 총 사서함 수) = ((총 시간) - (평균 큐 시간)) * (마이그레이션 처리량)

    여기서 마이그레이션 처리 속도는 시간당 마이그레이션될 수 있는 총 사서함 수와 같습니다.

예를 들어 사서함을 마이그레이션하는 데 6시간의 기간이 있다고 가정합니다. 평균 큐 시간이 1시간이고 마이그레이션 처리량이 시간당 100개인 경우 6시간 프레임에서 500개의 사서함을 마이그레이션할 수 있습니다. 500 = (6 - 1) * 100.

  • 큐 시간을 완화하려면 처음에 계획한 것보다 빨리 마이그레이션을 시작합니다. 사서함이 대기되는 경우 Exchange 2003 사용자는 여전히 사서함에 액세스할 수 있습니다.

큐 시간 결정: Microsoft는 고객의 마이그레이션 일정을 관리하지 않으므로 큐 시간이 항상 변경됩니다.

고객은 잠재적 큐 시간을 확인하기 위해 실제 마이그레이션이 시작되기 몇 시간 전에 테스트 이동을 예약해 볼 수 있습니다. 그런 다음 요청이 큐에 있는 관찰된 시간을 기반으로 마이그레이션을 시작할 시기와 특정 기간에 이동될 수 있는 사서함 수를 더 잘 예측할 수 있습니다.

예를 들어 테스트 마이그레이션이 계획된 마이그레이션 시작 4시간 전에 완료되었습니다. 고객은 테스트 마이그레이션의 큐 시간이 약 1시간임을 확인할 수 있습니다. 그런 다음 고객은 모든 마이그레이션을 완료하는 데 시간이 충분하도록 원래 계획보다 1시간 일찍 마이그레이션을 시작하는 것을 고려해야 합니다.

Microsoft 365 또는 Office 365 마이그레이션을 위한 타사 도구

타사 도구는 Gmail/G Suite/GWS(Google Workspace), IBM Lotus, Domino 및 Novell GroupWise와 같이 Exchange를 포함하지 않는 마이그레이션 시나리오에서 주로 사용됩니다. 이 섹션에서는 실제 제품 및 마이그레이션 도구가 아니라 타사 마이그레이션 도구에서 사용되는 마이그레이션 프로토콜을 집중적으로 설명합니다. 다음 표에서는 Microsoft 365 또는 Office 365 마이그레이션 시나리오에 대한 타사 도구에 적용되는 요인 목록을 제공합니다.

중요

타사 도구를 사용하여 마이그레이션을 수행한 후 데이터 일관성 또는 무결성과 관련된 문제는 지원을 위해 도구를 제공한 공급업체에 문의하세요.

요소 1: 타사 도구 마이그레이션을 위한 데이터 원본

검사 목록 설명 모범 사례
시스템 성능 데이터 추출은 많은 주의를 기울여야 하는 작업입니다. 원본 시스템에는 CPU 시간 및 메모리와 같은 충분한 리소스가 있어야 하고 원본 시스템은 최적의 마이그레이션 성능을 제공해야 합니다. 마이그레이션하는 동안 원본 시스템은 일반적인 최종 사용자 작업의 관점에서 봤을 때 자주 전체 용량에 가까워집니다. 시스템 리소스가 불충분한 경우 마이그레이션에서 발생하는 추가 작업은 최종 사용자에 영향을 줄 수 있습니다. 파일럿 마이그레이션 테스트 중에 시스템 성능을 모니터링합니다. 시스템의 작업량이 많은 경우 마이그레이션 속도가 느려지고 서비스 가용성 문제가 발생할 수 있으므로 특정 시스템에 대한 공격적인 마이그레이션 일정은 피하는 것이 좋습니다. 가능한 경우 하드웨어 리소스를 추가하여 원본 시스템 성능을 향상하고 작업 및 사용자를 마이그레이션과 관련 없는 다른 서버로 이동하여 시스템에 대한 부하를 줄입니다.

자세한 내용은 Exchange Server의 서버 상태 및 성능(2007, 2010, 2013, 2016, 2019)을 참조하세요.

참고: Exchange Server 2007 및 2010은 더 이상 적극적으로 지원되지 않습니다. Exchange 2013 서버 지원 종료는 2023년 4월로 예정되어 있습니다. Exchange Server 2016 및 2019는 2025년 10월까지 추가 지원됩니다. 자세한 내용은 Exchange Server 지원 가능성 매트릭스 를 참조하세요.

사서함 서버가 여러 대 있는 온-프레미스 Exchange 조직에서 마이그레이션하는 경우 여러 사서함 서버에 걸쳐 균등하게 분산되는 마이그레이션 사용자 목록을 만드는 것이 좋습니다. 개별 서버 성능에 따라 처리 속도가 최대화되도록 목록을 추가로 미세 조정할 수 있습니다.

예를 들어 서버 A가 서버 B보다 리소스 가용성이 50% 더 높은 경우 같은 마이그레이션 일괄 처리에서 서버 A의 사용자를 50% 더 많게 하는 것이 타당합니다. 다른 원본 시스템에 비슷한 모범 사례를 적용할 수 있습니다.

업무 시간 이후나 주말 및 공휴일과 같이 서버의 리소스 가용성이 최대일 때 마이그레이션을 수행합니다.
백 엔드 작업 기타 백 엔드 작업은 일반적으로 마이그레이션 시간 동안 실행됩니다. 마이그레이션은 업무가 끝난 후에 수행하는 것이 가장 좋은데, 데이터 백업 등 온-프레미스 서버에서 실행되는 기타 유지 관리 작업과 마이그레이션이 충돌하는 경우가 흔하기 때문입니다. 마이그레이션 중에 실행될 수 있는 기타 시스템 작업을 검토하세요. 리소스를 많이 사용하는 다른 작업이 실행되고 있지 않을 때 데이터 마이그레이션을 수행하는 것이 좋습니다.

참고: 온-프레미스 Exchange를 사용하는 고객의 경우 일반적인 백 엔드 작업은 백업 솔루션 및 Exchange 저장소 유지 관리(2013, 2016, 2019)입니다.
제한 정책 전자 메일 시스템을 특정 시간 내에, 특정 마이그레이션 방법을 사용하여 시스템에서 추출될 수 있는 데이터의 양과 속도에 대한 특정 제한을 설정하는 제한 정책으로 보호하는 것은 일반적입니다. 전자 메일 시스템에 배포된 제한 정책을 확인합니다. 예를 들어 Google Mail은 특정 기간에 추출할 수 있는 데이터의 양을 제한합니다. 버전에 따라 Exchange에는 온-프레미스 메일 서버에 대한 IMAP 액세스(IMAP 마이그레이션에 사용됨) 및 RPC over HTTP 프로토콜 액세스(단독형 Exchange 마이그레이션 및 미리 구성된 Exchange 마이그레이션에 사용됨)를 제한하는 정책이 있습니다.

제한 설정을 확인하려면 Get-ThrottlingPolicy cmdlet을 실행합니다. 제한에 대한 자세한 내용은 (2007, 2010, 2013, 2016, 2019) 를 참조하세요.

IMAP 제한에 대한 자세한 내용은 IMAP 사서함을 Microsoft 365 또는 Office 365로 마이그레이션을 참조하세요.

요소 2: 타사 도구 마이그레이션을 위한 마이그레이션 서버

Microsoft 365 또는 Office 365 마이그레이션을 위한 대부분의 타사 도구는 클라이언트가 시작하고 Microsoft 365 또는 Office 365로 데이터를 푸시하는 것입니다. 일반적으로 이러한 도구를 사용하려면 마이그레이션 서버가 필요합니다. 시스템 성능, 백 엔드 작업 및 원본 서버에 대한 제한 정책과 같은 요인이 이러한 마이그레이션 서버에 적용됩니다.

참고

일부 타사 마이그레이션 솔루션은 클라우드 기반 서비스로 인터넷에서 호스트되며 온-프레미스 마이그레이션 서버가 필요하지 않습니다.

솔루션 및 연습:

마이그레이션 서버를 사용할 때 마이그레이션 성능을 향상시키려면 팩터 1: 타사 도구 마이그레이션을 위한 데이터 원본 섹션에 설명된 것과 동일한 모범 사례를 적용합니다.

3단계: 타사 도구 마이그레이션을 위한 마이그레이션 엔진

타사 마이그레이션 도구의 경우 사용되는 가장 일반적인 프로토콜은 Exchange 웹 서비스 및 RPC over HTTP 프로토콜입니다.

Exchange Web Services:

Exchange Web Services는 대규모 데이터 일괄 처리를 지원하고 서비스 지향 제한이 더 우수하기 때문에 Microsoft 365 또는 Office 365로 마이그레이션하는 데 사용하는 권장 프로토콜입니다. Microsoft 365 또는 Office 365에서 가장 모드로 사용되는 경우 Exchange Web Services를 사용한 마이그레이션은 사용자의 예산이 지정된 Microsoft 365 또는 Office 365 Exchange Web Services 리소스를 사용하지 않고 예산이 지정된 리소스의 복사본을 대신 사용합니다.

  • 같은 관리자 계정에서 수행한 호출을 가장하는 모든 Exchange 웹 서비스는 이 관리자 계정에 적용된 예산에서 개별적으로 계산됩니다.

  • 각 가장 세션의 경우 실제 사용자 예산의 섀도 복사본이 만들어집니다. 이 특정 세션에 대한 모든 마이그레이션에서는 이 섀도 복사본을 사용합니다.

  • 가장 하에서의 제한은 각 사용자 마이그레이션 세션에 대해 격리됩니다.

  • 마이그레이션을 완료할 수 있도록 테넌트에서 Exchange Web Services 제한 정책을 일시적으로 변경할 수 있습니다(30, 60 또는 90일 동안). Microsoft 365 관리 센터의 도움말 섹션에서 요청할 수 있습니다.

모범 사례:

  • EWA 가장을 사용하는 타사 마이그레이션 도구를 사용하는 고객의 마이그레이션 성능은 다른 테넌트의 Exchange 웹 서비스 기반 마이그레이션 및 서비스 리소스 사용과 경쟁합니다. 따라서 마이그레이션 성능이 달라집니다.

  • 가능한 경우 항상 고객은 Exchange 웹 서비스 가장을 사용하는 타사 마이그레이션 도구를 사용해야 하는데, 일반적으로 RPC over HTTP 프로토콜과 같은 클라이언트 프로토콜을 사용하는 것보다 빠르고 효율적이기 때문입니다.

HTTP 프로토콜을 통한 RPC:

기존 마이그레이션 솔루션은 HTTP 프로토콜을 통해 RPC를 사용합니다. 이 방법은 Outlook과 같은 클라이언트 액세스 모델을 완전히 기반으로 하며, Microsoft 365 또는 Office 365 서비스는 애플리케이션이 아닌 사용자가 사용한다는 가정 하에 액세스를 제한하기 때문에 확장성 및 성능이 제한됩니다.

모범 사례:

  • HTTP 프로토콜을 통해 RPC를 사용하는 마이그레이션 도구의 경우 마이그레이션 서버를 더 추가하고 여러 Microsoft 365 또는 Office 365 관리 사용자 계정을 사용하여 마이그레이션 처리량을 늘리는 것이 일반적입니다. 이 방법은 각 관리 사용자에게 Microsoft 365 및 Office 365 사용자 제한이 적용되므로 데이터 주입 병렬 처리를 얻고 더 높은 데이터 처리량을 얻을 수 있습니다. Microsoft는 많은 엔터프라이즈 고객으로부터 마이그레이션 처리 속도 20~30GB/시간을 얻기 위해 마이그레이션 서버를 40개 이상 설정해야 했다는 보고서를 받았습니다.

  • 마이그레이션 도구 개발 단계에서는 메시지를 마이그레이션하는 데 필요한 RPC 작업의 수를 고려해야 합니다. 이를 설명하기 위해 고객이 사서함을 Microsoft 365 또는 Office 365로 마이그레이션하는 데 사용하는 두 개의 타사 마이그레이션 솔루션(타사 회사에서 개발)을 위해 Microsoft 365 또는 Office 365 서비스에서 캡처한 로그를 수집했습니다. 타사에서 개발한 두 마이그레이션 솔루션을 비교했습니다. 각 마이그레이션 솔루션에 대해 두 사서함의 마이그레이션을 비교했으며 Outlook에서의 .pst 파일 업로드도 비교했습니다. 결과는 다음과 같습니다.

메서드 사서함 크기 항목 수 마이그레이션 시간 총 RPC 트랜잭션 수 평균 클라이언트 대기 시간(ms) AvgCasRPCProcessingTime(ms)
솔루션 A(사서함 1개) 376.9MB 4,115 4:24:33 132,040 48.4395 18.0807
솔루션 A(사서함 2) 249.3MB 12,779 10:50:50 423,188 44.1678 4.8444
솔루션 B(사서함 1) 618.1MB 4,322 1:54:58 12,196 37.2931 8.3441
솔루션 B(사서함 2) 56.7MB 2,748 0:47:08 5,806 42.1930 7.4439
Outlook 201.9MB 3,297 0:29:47 15,775 36.9987 5.6447

참고

클라이언트 및 서비스 프로세스 시간은 비슷하지만 솔루션 A는 데이터를 마이그레이션하기 위해 훨씬 더 많은 RPC 작업을 수행합니다. 각 작업에는 클라이언트 대기 시간 및 서버 프로세스 시간이 사용되므로 솔루션 A는 솔루션 B 및 Outlook에 비해 동일한 양의 데이터를 마이그레이션하는 속도가 훨씬 느립니다.

요소 4: 타사 도구 마이그레이션을 위한 네트워크

모범 사례:

RPC over HTTP 프로토콜을 사용하는 타사 마이그레이션 솔루션의 경우 잠재적 마이그레이션 성능을 측정하는 좋은 방법은 다음과 같습니다.

  1. 마이그레이션 서버에서 HTTP 프로토콜을 통해 RPC를 사용하여 Outlook에서 Microsoft 365 또는 Office 365 사서함에 연결합니다. 캐시된 모드를 사용하여 연결하지 않는지 확인합니다.

  2. 샘플 데이터가 포함된 큰 .pst 파일을 Microsoft 365 또는 Office 365 사서함으로 가져옵니다.

  3. .pst 파일을 업로드하는 데 걸린 시간을 측정하여 마이그레이션 성능을 측정합니다. 다른 제약 조건이 없다고 한다면, 마이그레이션 처리 속도는 고객이 RPC over HTTP 프로토콜을 사용하는 타사 마이그레이션 도구에서 얻을 수 있는 값과 비슷해야 합니다. 실제 마이그레이션 중에는 오버헤드가 있으므로 처리 속도가 약간 다를 수 있습니다.

5단계: Microsoft 365 및 Office 365 서비스

Microsoft 365 및 Office 365 리소스 상태 기반 제한은 타사 마이그레이션 도구를 사용하는 마이그레이션에 영향을 줍니다. 자세한 내용은 Microsoft 365 및 Office 365 리소스 상태 기반 제한을 참조하세요.