설명서AEM as a Cloud Service사용 안내서

실행 go-live

Last update: Wed Mar 06 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

이 여정 부분에서는 코드와 컨텐츠를 모두 AEM as a Cloud Service으로 이동할 준비가 되면 마이그레이션을 계획하고 수행하는 방법을 배웁니다. 또한 마이그레이션을 수행할 때 모범 사례와 알려진 제한 사항이 무엇인지 알아봅니다.

지금까지의 스토리 story-so-far

여정의 이전 단계에서

  • 에서 AEM으로 as a Cloud Service으로 이동하는 방법을 배웠습니다. 시작 페이지를 가리키도록 업데이트하는 중입니다.
  • 를 읽고 배포를 클라우드로 이동할 준비가 되었는지 확인했습니다. 준비 단계
  • 에서 코드 및 콘텐츠 클라우드를 준비할 수 있는 도구 및 프로세스에 익숙해집니다. 구현 단계.

목표 objective

이 문서는 여정의 이전 단계를 잘 알고 있는 경우 AEM으로 as a Cloud Service으로 마이그레이션하는 방법을 이해하는 데 도움이 됩니다. 초기 프로덕션 마이그레이션을 수행하는 방법과 AEM as a Cloud Service으로 마이그레이션할 때 따라야 할 모범 사례를 알아봅니다.

초기 프로덕션 마이그레이션 initial-migration

프로덕션 마이그레이션을 수행하기 전에 다음에 요약된 마이그레이션 기능 및 증명 단계를 따르십시오. 컨텐츠 마이그레이션 전략 및 타임라인 의 섹션 구현 단계.

  • 클론에 대해 수행된 AEM as a Cloud Service 마이그레이션 과정에서 얻은 경험에 따라 프로덕션에서 마이그레이션을 시작합니다.

    • Author-Author
    • Publish-Publish

  • AEM as a Cloud Service 작성자 및 게시 계층 모두에 수집된 콘텐츠의 유효성을 검사합니다.

  • 수집이 완료될 때까지 소스와 대상 모두에서 컨텐츠가 이동하지 않도록 컨텐츠 작성 팀에 지시합니다

  • 새 콘텐츠를 추가, 편집 또는 삭제할 수 있지만 이동하지 마십시오. 이는 소스와 대상 모두에 적용됩니다.

  • 레코드 수행한 시간 전체 추출 및 수집을 통해 향후 추가 마이그레이션 일정에 대한 예상 값을 얻을 수 있습니다.

  • 만들기 마이그레이션 플래너 작성자와 게시 모두에 해당합니다.

증분 추가 top-up

프로덕션에서 초기 마이그레이션 후 증분 추가 작업을 수행하여 클라우드 인스턴스에서 콘텐츠를 최신 상태로 유지해야 합니다. 이러한 이유로 다음 모범 사례를 따르는 것이 좋습니다.

  • 컨텐츠 양에 대한 데이터를 수집합니다. 예를 들어 1주마다, 2주마다 또는 한 달마다.
  • 48시간 이상의 콘텐츠 추출 및 수집을 피하는 방식으로 추가 작업을 계획해야 합니다. 콘텐츠 윗면이 주말 시간대에 맞춰지도록 하는 것이 좋습니다.
  • 필요한 최상위 작업의 수를 계획하고 예상 값을 사용하여 Go-Live 날짜를 기준으로 계획을 수립합니다.

마이그레이션에 대한 코드 및 컨텐츠 고정 타임라인 식별 code-content-freeze

앞에서 언급했듯이 코드 및 콘텐츠 고정 기간을 예약해야 합니다. 동결 기간을 계획하는 데 도움이 되는 질문은 다음과 같습니다.

  • 콘텐츠 작성 활동을 얼마나 동결해야 합니까?
  • 게재 팀에 새 기능 추가를 중지하도록 얼마 동안 요청해야 합니까?

첫 번째 질문에 답변하려면 비프로덕션 환경에서 체험판 실행을 수행하는 데 걸린 시간을 고려해야 합니다. 두 번째 질문에 답변하려면 새로운 기능을 추가하는 팀과 코드를 리팩터링하는 팀 간의 긴밀한 협업이 필요합니다. 기존 배포에 추가된 모든 코드도 클라우드 서비스 분기에 추가, 테스트 및 배포되도록 하는 것이 목표입니다. 일반적으로 코드 동결량이 더 적다는 의미입니다.

또한 최종 콘텐츠 추가 일정이 잡히면 콘텐츠 중지를 계획해야 합니다.

모범 사례 best-practices

마이그레이션을 계획하거나 수행할 때는 다음 지침을 고려해야 합니다.

  • 작성자에서 작성자로 마이그레이션 및 게시로 게시

  • 다음을 수행하는 데 사용할 수 있는 운영 클론 요청:

    • 저장소 통계 캡처
    • 마이그레이션 활동 증명
    • 마이그레이션 계획 준비
    • 컨텐츠 고정 요구 사항 식별
    • 프로덕션에서 마이그레이션을 수행할 때 프로덕션의 업사이징 요구 사항 파악

컨텐츠 전송 도구 모범 사례

라이브 진행 시 클론 대신 프로덕션에서 컨텐츠 마이그레이션을 실행해야 합니다. 좋은 방법은 AZCopy 초기 마이그레이션 후 자주(심지어 매일) 추가 추출을 실행하여 더 작은 청크를 추출하고 소스 AEM에 대한 장기적인 로드를 방지합니다.

다음과 같은 이유로 운영 마이그레이션을 수행할 때는 클론에서 컨텐츠 전송 도구를 실행하지 않아야 합니다.

  • 고객이 추가 마이그레이션 중에 컨텐츠 버전을 마이그레이션해야 하는 경우 클론에서 컨텐츠 전송 도구를 실행해도 버전이 마이그레이션되지 않습니다. 라이브 작성자에서 클론을 자주 재생성하더라도 클론이 생성될 때마다 컨텐츠 전송 도구에서 델타를 계산하는 데 사용하는 체크포인트가 재설정됩니다.
  • 클론은 전체적으로 새로 고칠 수 없으므로 ACL 쿼리 패키지를 사용하여 프로덕션에서 클론으로 추가 또는 편집되는 콘텐츠를 패키징하고 설치해야 합니다. 이 방법의 문제는 소스 및 클론 모두에서 수동으로 삭제되지 않는 한 소스 인스턴스의 삭제된 컨텐츠는 클론에 도달하지 않는다는 것입니다. 이렇게 하면 프로덕션에서 삭제된 콘텐츠가 클론과 AEM에서 as a Cloud Service으로 삭제되지 않을 수 있습니다.

콘텐츠 마이그레이션을 수행하는 동안 AEM 소스에 대한 로드 최적화

AEM 소스의 로드는 추출 단계 동안 더 커집니다. 다음 사항에 주의하십시오.

  • 컨텐츠 전송 도구는 4GB의 JVM 힙을 사용하는 외부 Java 프로세스입니다
  • AzCopy가 아닌 버전은 바이너리를 다운로드하고 소스 AEM 작성자의 임시 공간에 저장하여 디스크 I/O를 사용한 다음 네트워크 대역폭을 사용하는 Azure 컨테이너에 업로드합니다
  • AzCopy blob을 blob 저장소에서 Azure 컨테이너로 직접 전송하여 디스크 I/O 및 네트워크 대역폭을 저장합니다. AzCopy 버전에서는 여전히 디스크 및 네트워크 대역폭을 사용하여 세그먼트 저장소에서 Azure 컨테이너로 데이터를 추출하고 업로드합니다
  • 컨텐츠 전송 툴 프로세스는 수집 로그만 스트리밍하고 디스크 I/O 또는 네트워크 대역폭에 관한 한 소스 인스턴스에 대한 로드가 많지 않으므로 수집 단계에서 시스템 리소스에 대한 부담이 적습니다.

알려진 제한 사항 known-limitations

다음 제한 사항 중 하나라도 추출된 마이그레이션 세트의 일부로 해당되는 경우 전체 수집이 실패한다는 점을 고려하십시오.

  • 이름이 150자를 초과하는 JCR 노드
  • 16MB보다 큰 JCR 노드
  • 을(를) 가진 모든 사용자/그룹 rep:AuthorizableID 이미 AEM as a Cloud Service에 있는 수집 중
  • 추출되어 수집된 에셋이 마이그레이션의 다음 반복 전에 소스 또는 대상에서 다른 경로로 이동하는 경우.

에셋 상태 asset-health

수집 위의 섹션과 비교 다음이 아님 다음 자산 문제로 인해 실패합니다. 그러나 다음 시나리오에서 적절한 단계를 수행하는 것이 좋습니다.

  • 원본 렌디션이 누락된 모든 에셋
  • 누락된 모든 폴더 jcr:content 노드.

위의 두 항목은 모두에서 식별되고 보고됩니다 Best Practice Analyzer 보고서.

실행 체크리스트 Go-Live-Checklist

이 활동 목록을 검토하여 원활하고 성공적인 마이그레이션을 수행하도록 하십시오.

  • 기능 및 UI 테스트를 통해 엔드 투 엔드 프로덕션 파이프라인을 실행하여 항상 최신 AEM 제품 경험입니다. 다음 리소스를 참조하십시오.

  • 콘텐츠를 프로덕션으로 마이그레이션하고 스테이징에서 테스트를 위해 관련 하위 집합을 사용할 수 있는지 확인하십시오.

    • AEM에 대한 DevOps 우수 사례는 코드가 개발 환경에서 프로덕션 환경으로 이동하는 반면 콘텐츠는 프로덕션 환경에서 이동하는 것을 의미합니다.

  • 코드 및 컨텐츠 고정 기간을 예약합니다.

  • 최종 컨텐츠 추가 작업을 수행합니다.

  • Dispatcher 구성의 유효성을 검사합니다.

    • 로컬에서 Dispatcher 구성, 유효성 검사 및 시뮬레이션을 용이하게 하는 로컬 Dispatcher 유효성 검사기를 사용하십시오

    • 가상 호스트 구성을 주의 깊게 검토하십시오.

      • 가장 쉬운(그리고 기본) 솔루션은 다음을 포함하는 것입니다. ServerAlias * 의 가상 호스트 파일에서 /dispatcher/src/conf.d/available_vhostsfolder.

        • 이렇게 하면 제품 기능 테스트, Dispatcher 캐시 무효화 및 클론이 사용하는 호스트 별칭이 작동할 수 있습니다.

      • 그러나 다음과 같은 경우에는 ServerAlias * 은(는) 허용되지 않으며, 최소한 다음과 같습니다 ServerAlias 사용자 정의 도메인 외에 항목을 허용해야 합니다.

        • localhost
        • *.local
        • publish*.adobeaemcloud.net
        • publish*.adobeaemcloud.com

  • CDN, SSL 및 DNS를 구성합니다.

    • 자체 CDN을 사용하는 경우 지원 티켓을 입력하여 적절한 라우팅을 구성합니다.

    • 추가 CDN을 사용하지 않는 경우 다음 설명서에 따라 SSL 및 DNS를 관리합니다.

    • DNS 레코드에 대한 TTL 집합의 유효성을 검사해야 합니다.

      • TTL은 서버에 업데이트를 요청하기 전에 DNS 레코드가 캐시에 남아 있는 시간입니다.
      • TTL이 매우 높은 경우 DNS 레코드 업데이트가 전파되는 데 시간이 더 오래 걸립니다.

  • 비즈니스 요구 사항 및 목표를 충족하는 성능 및 보안 테스트를 실행합니다.

    • 스테이지 환경에서 테스트를 수행합니다. 이는 프로덕션 크기와 동일합니다.
    • 개발 환경의 크기가 단계 및 프로덕션과 동일하지 않습니다.

  • 잘라내어 새로운 배포나 콘텐츠 업데이트 없이 실제 Go-Live가 수행되도록 하십시오.

  • Admin Console 사용자 알림 프로필을 만듭니다. 다음을 참조하십시오 알림 프로필

  • 웹 사이트에서 허용해서는 안 되는 트래픽을 제어하도록 트래픽 필터 규칙 을 구성하는 것이 좋습니다.

    • 속도 제한 트래픽 필터 규칙은 DDoS 공격에 효과적인 도구가 될 수 있습니다. WAF 규칙이라고 하는 특별한 범주의 트래픽 필터 규칙에는 별도의 라이센스가 필요합니다.
    • 자세한 내용은 설명서 를 참조하십시오 제안된 시작 규칙.

마이그레이션을 수행하는 동안 작업을 다시 수정해야 하는 경우 언제든지 목록을 참조할 수 있습니다.

다음 단계 what-is-next

AEM으로 as a Cloud Service으로 마이그레이션하는 방법을 이해하면 Go-Live 후 원활한 인스턴스 실행을 위한 페이지.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab