업그레이드 계획 planning-your-upgrade

AEM 프로젝트 개요 aem-project-overview

AEM은 수백만 명의 사용자에게 제공될 수 있는 영향력이 큰 배포에서 종종 사용됩니다. 일반적으로 인스턴스에 배포되는 사용자 정의 애플리케이션이 있어 복잡성을 가중시킵니다. 이러한 배포를 업그레이드하기 위한 모든 노력은 체계적으로 처리되어야 합니다.

이 안내서는 업그레이드를 계획할 때 명확한 목표, 단계 및 결과물을 설정하는 데 도움이 됩니다. 전체적인 프로젝트 수행 및 가이드라인에 초점을 맞추고 있다. 실제 업그레이드 단계에 대한 개요를 제공하지만 적합한 경우 사용 가능한 기술 리소스를 참조합니다. 이 설명서는 문서에서 언급한 사용 가능한 기술 리소스와 함께 사용해야 합니다.

AEM 업그레이드 프로세스에는 각 단계에 대해 정의된 주요 결과물을 사용하여 계획, 분석 및 실행 단계를 신중하게 처리해야 합니다.

AEM 버전 6.0 및 최대 6.5에서 바로 업그레이드할 수 있습니다. 5.6.x 이하를 실행하는 고객은 먼저 버전 6.0 이상으로 업그레이드해야 하며 6.0(SP3) 이 권장됩니다. 또한 이제 새로운 Oak 세그먼트 Tar 형식이 6.3부터 세그먼트 노드 저장소에 사용되며, 6.0, 6.1 및 6.2에서도 이 새로운 형식으로 저장소 마이그레이션이 필수입니다.

CAUTION
AEM 6.2에서 6.3으로 업그레이드하는 경우 버전(6.2-SP1-CFP1 - -6.2SP1-CFP12.1) 또는 6.2SP1-CFP15 계속. 그렇지 않고에서 업그레이드하는 경우 6.2SP1-CFP13/6.2SP1CFP14 AEM 6.3으로 업그레이드해야 합니다 6.3.2.2. 그렇지 않으면 업그레이드 후 AEM Sites이 실패합니다.

업그레이드 범위 및 요구 사항 upgrade-scope-requirements

아래에는 일반적인 AEM 업그레이드 프로젝트의 영향을 받는 영역 목록이 있습니다.

구성 요소
영향
설명
운영 체제
불확실하지만 미묘한 영향
AEM 업그레이드 당시에는 운영 체제를 업그레이드해야 할 시기일 수도 있으며 이는 일부 영향을 미칠 수 있습니다.
Java™ 런타임
중간 영향
AEM 6.3에는 JRE 1.7.x(64비트) 이상이 필요합니다. JRE 1.8은 현재 Oracle에서 지원하는 유일한 버전입니다.
하드웨어
중간 영향
온라인 개정 정리 시 무료 필요
저장소 크기의 25%에 해당하는 디스크 공간 및 15%의 사용 가능한 힙 공간
을(를) 완료했습니다. 하드웨어를 업그레이드해야 할 수도 있습니다.
온라인 개정 정리를 위한 충분한 리소스가 있어야 합니다.
도망쳐! 또한 AEM 6 이전 버전에서 업그레이드하는 경우
추가 스토리지 요구 사항이 될 수 있습니다.
콘텐츠 저장소(CRX 또는 Oak)
높은 영향
버전 6.1부터 AEM은 CRX2를 지원하지 않으므로
이전 버전에서 업그레이드하는 경우 Oak(CRX3)가 필요합니다. AEM 6.3 has
마이그레이션이 필요한 새 세그먼트 노드 저장소를 구현했습니다. 다음
crx2oak 도구는 이 용도로 사용됩니다.
AEM 구성 요소/컨텐츠
중간 영향
/libs/apps 업그레이드를 통해 쉽게 처리되지만, /etc 일반적으로 맞춤화를 수동으로 다시 적용해야 합니다.
AEM 서비스
낮은 영향
대부분의 AEM 핵심 서비스는 업그레이드를 위해 테스트됩니다. 이 영역은 영향력이 낮은 영역입니다.
사용자 정의 응용 프로그램 서비스
낮은 영향에서 높은 영향
애플리케이션 및 사용자 정의에 따라 다음과 같은 경우가 있을 수 있습니다.
jvm, 운영 체제 버전 및 일부 인덱싱 관련 종속성
Oak에서 색인이 자동으로 생성되지 않으므로 변경되었습니다.
사용자 정의 애플리케이션 콘텐츠
낮은 영향에서 높은 영향
업그레이드를 통해 처리되지 않는 컨텐츠는 백업할 수 있습니다.
업그레이드가 수행되기 전에 저장소로 다시 이동했습니다.
대부분의 콘텐츠는 마이그레이션 도구를 통해 처리할 수 있습니다.

지원되는 운영 체제, Java™ 런타임, httpd 및 Dispatcher 버전을 실행 중인지 확인하는 것이 중요합니다. 자세한 내용은 AEM 6.5 기술 요구 사항 페이지. 이러한 구성 요소 업그레이드는 프로젝트 계획에서 고려해야 하며 AEM을 업그레이드하기 전에 수행해야 합니다.

프로젝트 단계 project-phases

AEM 업그레이드를 계획하고 실행하는 데 많은 작업이 필요합니다. Adobe은 이 프로세스에 들어가는 다양한 노력을 명확히 하기 위해 계획 및 실행 연습을 별도의 단계로 분류했습니다. 아래 섹션에서 각 단계는 프로젝트의 미래 단계에서 자주 사용되는 결과물을 생성합니다.

작성자 교육 계획 planning-for-author-training

새로운 릴리스에서는 도입될 수 있는 UI 및 사용자 워크플로에 대한 잠재적인 변경 사항이 있습니다. 또한 새로운 릴리스에는 비즈니스에서 사용하는 데 도움이 될 수 있는 새로운 기능이 도입됩니다. Adobe은 도입된 기능 변경 사항을 검토하고 사용자를 효과적으로 사용하도록 교육하기 위한 계획을 구성할 것을 권장합니다.

unu_cropped

AEM 6.5의 새로운 기능은에서 찾을 수 있습니다. adobe.com의 AEM 섹션. 조직에서 일반적으로 사용하는 UI 또는 제품 기능에 대한 변경 사항을 알아 두십시오. 새로운 기능을 살펴보면서 귀사에 유용할 수 있는 모든 기능을 주목하십시오. AEM 6.5에서 변경된 사항을 살펴본 후 작성자를 위한 교육 계획을 개발하십시오. 여기에는 도움말 기능 비디오 또는 을 통해 제공되는 공식 교육과 같이 자유롭게 사용할 수 있는 리소스를 사용하는 작업이 포함될 수 있습니다 Adobe 디지털 학습 서비스.

테스트 계획 만들기 creating-a-test-plan

각 고객의 AEM 구현은 고유하며 비즈니스 요구 사항을 충족하도록 사용자 정의되었습니다. 따라서 테스트 계획에 포함될 수 있도록 시스템에 적용된 모든 사용자 지정을 결정하는 것이 중요합니다. 이 테스트 계획은 업그레이드된 인스턴스에서 Adobe이 수행하는 QA 프로세스를 강화합니다.

시험 계획

모든 애플리케이션과 사용자 정의 코드가 원하는 대로 계속 실행되는지 확인하려면 업그레이드 후 정확한 프로덕션 환경을 복제하고 테스트해야 합니다. 모든 사용자 지정을 취소하고 성능, 로드 및 보안 테스트를 실행합니다. 테스트 계획을 구성할 때는 일상적인 작업에 사용되는 기본 UI 및 워크플로뿐만 아니라 시스템에 적용된 모든 사용자 지정 사항도 다루어야 합니다. 여기에는 사용자 지정 OSGI 서비스 및 서블릿, Adobe Experience Cloud에 대한 통합, AEM 커넥터를 통한 서드파티와의 통합, 사용자 지정 서드파티 통합, 사용자 지정 구성 요소 및 템플릿, AEM의 사용자 지정 UI 오버레이 및 사용자 지정 워크플로가 포함될 수 있습니다. AEM 6 이전 버전에서 마이그레이션하는 고객의 경우 색인화해야 할 수 있으므로 모든 사용자 지정 쿼리를 분석해야 합니다. 이미 AEM 6.x 버전을 사용 중인 고객의 경우 업그레이드 후에도 색인이 계속 효과적으로 작동하도록 이러한 쿼리를 계속 테스트해야 합니다.

필요한 아키텍처 및 인프라 변경 결정 determining-architectural-and-infrastructure-changes-needed

업그레이드할 때 운영 체제나 JVM과 같은 기술 스택에 있는 다른 구성 요소도 업그레이드해야 할 수 있습니다. 또한 저장소 구성의 변경으로 인해 추가 하드웨어가 필요할 수 있습니다. 이는 6.x 이전 인스턴스에서 마이그레이션하는 고객에게만 적용되지만 고려해야 합니다. 마지막으로, 모니터링, 유지 관리, 백업 및 재해 복구 프로세스 등 운영 관행에 변화가 필요할 수 있습니다.

doi_cropped

AEM 6.5에 대한 기술 요구 사항을 검토하고 현재 사용 중인 하드웨어 및 소프트웨어가 충분한지 확인합니다. 운영 프로세스에 대한 잠재적 변경 사항은 다음 문서를 참조하십시오.

모니터링 및 유지 관리:

작업 대시보드

Assets 모니터링 우수 사례

JMX 콘솔을 사용한 서버 리소스 모니터링

개정 정리

백업/복원 및 재해 복구:

백업 및 복원

성능 및 확장성

TarMK 콜드 대기로 AEM을 실행하는 방법

콘텐츠 재구성 고려 사항 content-restructuring-considerations

AEM은 보다 원활한 업그레이드를 수행하는 데 도움이 되는 저장소 구조 변경 사항을 도입했습니다. 변경 사항에는 Adobe 또는 고객의 콘텐츠 소유 여부에 따라 /libs, /apps 및 /content를 포함하는 폴더로 /etc 폴더의 콘텐츠를 이동하는 작업이 포함되며 따라서 릴리스 중 콘텐츠를 덮어쓸 가능성이 제한됩니다. 저장소 재구성은 6.5 업그레이드 시 코드를 변경할 필요가 없는 방식으로 수행되지만, 세부 사항을 검토하는 것이 좋습니다. AEM의 저장소 재구성 업그레이드를 계획하는 동안.

업그레이드 복잡성 평가 assessing-upgrade-complexity

Adobe 고객이 AEM 환경에 적용하는 맞춤화의 양과 특성이 매우 다양하기 때문에 업그레이드 시 예상되는 전반적인 작업 수준을 파악하기 위해 미리 시간을 투자하는 것이 중요합니다.

업그레이드의 복잡성을 평가하는 방법에는 두 가지가 있습니다. 예비 단계에서는 AEM 6.1, 6.2 및 6.3 인스턴스에서 실행할 수 있는 새로 도입된 패턴 감지기를 사용할 수 있습니다. 패턴 감지기는 보고된 패턴을 사용하여 예상되는 업그레이드의 전체 복잡성을 평가하는 가장 쉬운 방법입니다. 패턴 탐지기 보고서에는 사용자 지정 코드베이스에서 사용 중인 사용할 수 없는 API를 식별하기 위한 패턴이 포함됩니다(이 작업은 6.3에서 업그레이드 전 호환성 검사를 사용하여 수행됨).

초기 평가 후, 보다 포괄적인 다음 단계는 테스트 인스턴스에 대한 업그레이드를 수행하고 몇 가지 기본 연기 테스트를 수행하는 것입니다. Adobe은 몇 가지 도 제공합니다. 또한, 사용이 중단되거나 제거된 기능 업그레이드하려는 버전뿐만 아니라 소스 및 타겟 버전 사이의 모든 버전을 검토해야 합니다. 예를 들어 AEM 6.2에서 6.5로 업그레이드하는 경우 AEM 6.5의 기능 외에 더 이상 사용되지 않거나 제거된 AEM 6.3 기능을 검토해야 합니다.

트리 자름(_C)

최근에 도입된 패턴 감지기는 대부분의 경우 업그레이드 중에 예상되는 사항을 상당히 정확하게 예측할 수 있도록 해 줍니다. 그러나 변경 내용이 호환되지 않는 보다 복잡한 사용자 지정 및 배포의 경우 의 지침에 따라 개발 인스턴스를 AEM 6.5로 업그레이드할 수 있습니다 즉석 업그레이드 수행. 완료되면 이 환경에서 높은 수준의 스모크 테스트를 수행합니다. 이 연습의 목표는 테스트 사례 인벤토리를 완전히 완성하고 공식적인 결함 인벤토리를 생성하는 것이 아니라 6.5 호환성을 위해 코드를 업그레이드하는 데 필요한 작업의 양을 대략적으로 예상하는 것입니다. 과 결합 시 패턴 감지 그리고 이전 섹션에서 결정된 아키텍처 변경 사항에 대해 프로젝트 관리 팀에 대략적인 견적을 제공하여 업그레이드를 계획할 수 있습니다.

업그레이드 및 롤백 Runbook 빌드 building-the-upgrade-and-rollback-runbook

Adobe은 AEM 인스턴스 업그레이드 프로세스를 문서화했지만 각 고객의 네트워크 레이아웃, 배포 아키텍처 및 맞춤화는 이 접근 방식을 미세 조정하고 맞춤화해야 합니다. 따라서 Adobe은 제공된 모든 설명서를 검토하고 이를 사용하여 사용자 환경에서 수행할 특정 업그레이드 및 롤백 절차를 요약한 프로젝트별 Runbook을 알리는 것을 권장합니다. CRX2에서 업그레이드하는 경우 CRX2에서 Oak로 이동할 때 컨텐츠 마이그레이션이 얼마나 오래 걸리는지 평가해야 합니다. 대형 저장소의 경우 상당할 수 있습니다.

runbook 다이어그램

Adobe은에서 업그레이드 및 롤백 절차를 제공했습니다. 업그레이드 프로시저 및 수행 시 업그레이드 적용에 대한 단계별 지침 즉석 업그레이드. 업그레이드 중에 실행할 적절한 전환 및 롤백 절차를 결정하려면 시스템 아키텍처, 사용자 정의 및 가동 중지 시간 허용 범위와 함께 이러한 지침을 검토하고 고려해야 합니다. 사용자 지정된 Runbook을 작성할 때 아키텍처 또는 서버 크기에 대한 모든 변경 사항을 포함해야 합니다. 이는 1차 드래프트로 처리되어야 한다는 점에 유의할 필요가 있다. 팀이 QA 및 개발 주기를 완료하고 스테이징 환경에 업그레이드를 배포하면 몇 가지 추가 단계가 필요할 수 있습니다. 이상적으로 이 문서에는 운영 직원에게 전달될 경우 내부 정보에서 업그레이드를 완전히 완료할 수 있도록 충분한 정보가 포함되어 있어야 합니다.

프로젝트 계획 개발 developing-a-project-plan

이전 연습의 결과를 사용하여 테스트 또는 개발 노력, 교육 및 실제 업그레이드 실행에 대한 예상 일정을 다루는 프로젝트 계획을 작성할 수 있습니다.

개발 프로젝트 계획

포괄적인 프로젝트 계획에는 다음이 포함되어야 합니다.

  • 개발 및 테스트 계획 확정
  • 개발 및 QA 환경 업그레이드
  • AEM 6.5에 대한 사용자 지정 코드 기반 업데이트
  • QA 테스트 및 수정 주기
  • 스테이징 환경 업그레이드
  • 통합, 성능 및 로드 테스트
  • 환경 인증
  • 실행

개발 및 QA 수행 performing-development-and-qa

Adobe에 대한 절차 제공 코드 및 사용자 지정 업그레이드 AEM 6.5와 호환됩니다. 이 반복 프로세스가 실행되면 필요에 따라 Runbook을 변경해야 합니다. 추가 정보 AEM 6.5의 이전 버전과의 호환성 업그레이드 후 즉시 개발하지 않고도 일반적으로 맞춤화가 이전 버전과 호환되는 방식을 유지할 수 있는 방법에 대해 설명합니다.

patru_cropped

개발 및 테스트 프로세스는 일반적으로 반복적인 프로세스입니다. 사용자 지정으로 인해 업그레이드 중에 변경 사항이 발생하면 제품의 전체 섹션을 사용할 수 없게 될 수 있습니다. 개발자가 문제의 근본 원인을 해결했고 테스트 팀이 이러한 기능을 테스트할 수 있게 되면 추가 문제를 발견할 수 있습니다. 업그레이드 프로세스를 조정해야 하는 문제가 발견되면 사용자 지정 업그레이드 Runbook에 추가해야 합니다. 테스트 및 수정을 여러 번 반복한 후 코드 베이스의 유효성을 완전히 검사하고 스테이징 환경에 배포할 준비가 되어야 합니다.

최종 테스트 final-testing

Adobe은 코드베이스가 조직의 QA 팀에 의해 인증된 후 최종 테스트 라운드를 권장합니다. 이 테스트에는 스테이징 환경에서 Runbook의 유효성을 검사한 다음 사용자 승인, 성능 및 보안 테스트를 수행하는 작업이 포함됩니다.

cinci_cropped

이 단계는 프로덕션 유사 환경에 대해 Runbook의 단계를 확인할 수 있는 유일한 시간이므로 중요합니다. 환경이 업그레이드되면 최종 사용자가 일상적인 활동에서 시스템을 사용할 때 로그인하고 수행하는 활동을 수행할 수 있는 시간을 갖도록 하는 것이 중요합니다. 사용자가 이전에 고려하지 않은 시스템 일부를 사용하는 것은 드문 일이 아닙니다. 가동 전에 이러한 영역에서 문제를 찾아 수정하면 많은 비용이 드는 생산 중단을 방지하는 데 도움이 될 수 있습니다. 새 AEM 버전에는 기본 플랫폼에 대한 중요한 변경 사항이 포함되어 있으므로 시스템을 처음 시작할 때처럼 시스템에서 성능, 로드 및 보안 테스트를 수행하는 것도 중요합니다.

업그레이드 수행 performing-the-upgrade

모든 이해 당사자로부터 최종 승인을 받은 후에는 정의된 Runbook 프로시저에서 실행할 차례입니다. Adobe에서 업그레이드 및 롤백에 대한 단계를 제공했습니다 업그레이드 프로시저 및 설치 단계 수행 즉석 업그레이드 를 참조점으로 사용하십시오.

업그레이드 수행

Adobe은 환경 유효성 검사에 대한 업그레이드 지침에 몇 가지 단계를 제공했습니다. Adobe 여기에는 업그레이드 로그를 스캔하고 모든 OSGi 번들이 제대로 시작되었는지 확인하는 것과 같은 기본 검사가 포함되지만, 비즈니스 프로세스를 기반으로 자체 테스트 사례를 사용하여 확인하는 것이 좋습니다. Adobe은 또한 AEM Online Revision Cleanup의 일정 및 관련 루틴을 확인하여 회사의 조용한 시간에 작업이 수행되는지 확인할 것을 권장합니다. 이러한 루틴은 AEM의 장기 성능에 필수적입니다.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2