Show Menu
화제×

업그레이드 계획

AEM 프로젝트 개요

AEM 파섹 대부분의 경우 인스턴스에 배포되는 사용자 정의 애플리케이션이 있으므로 복잡성이 가중됩니다. 이러한 배포를 업그레이드하려는 모든 노력은 체계적으로 처리해야 합니다.
본 가이드는 업그레이드를 계획할 때 명확한 목표, 단계 및 결과물을 설정하는 데 도움이 됩니다. 전체 프로젝트 실행 및 지침에 중점을 둡니다. 실제 업그레이드 단계에 대한 개요를 제공하는 반면, 적절한 경우 사용 가능한 기술 리소스를 말합니다. 이 제품은 문서에 명시된 사용 가능한 기술 리소스와 함께 사용해야 합니다.
AEM 업그레이드 프로세스는 각 단계에 대해 정의된 주요 산출물을 사용하여 계획, 분석 및 실행 단계를 신중하게 처리해야 합니다.
AEM 버전 6.0 및 최대 6.4에서 직접 업그레이드할 수 있습니다.5.6.x 이하 버전을 실행하는 고객은 먼저 6.0(SP3)을 버전 6.0 이상으로 업그레이드해야 합니다. 또한 새로운 OAK 세그먼트 Tar 포맷은 6.3 이후 세그먼트 노드 저장소에 사용되며 이 새 포맷으로 변환하는 저장소 마이그레이션은 6.0, 6.1 및 6.2에서도 필수입니다.
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가 실패합니다.

업그레이드 범위 및 요구 사항

다음은 일반적인 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를 지원하지 않으므로 이전 버전에서 업그레이드하는 경우 CRX3로의 마이그레이션이 필요합니다. AEM 6.3은 마이그레이션이 필요한 새 세그먼트 노드 저장소를 구현했습니다. crx 2oak 도구는 이 용도로 사용됩니다.
AEM 구성 요소/컨텐츠 중간 영향 /libs 또한 업그레이드를 통해 /apps 손쉽게 처리할 수 있지만 /etc 일반적으로 사용자 정의 사항을 수동으로 다시 적용해야 합니다.
AEM Services 낮은 영향 대부분의 AEM 핵심 서비스는 업그레이드를 테스트합니다. 이것은 낮은 영향의 한 단계입니다.
사용자 정의 응용 프로그램 서비스 낮은 효과에서 높은 효과 Oak에서 인덱스가 자동으로 생성되지 않으므로 애플리케이션 및 사용자 정의에 따라 JVM, 운영 체제 버전 및 일부 색인 관련 변경 사항에 대한 종속성이 있을 수 있습니다.
사용자 지정 애플리케이션 컨텐츠 낮은 효과에서 높은 효과 업그레이드를 통해 처리되지 않는 컨텐츠는 업그레이드가 시작되기 전에 백업되어 다시 저장소로 이동할 수 있습니다. 대부분의 컨텐츠는 마이그레이션 도구를 통해 처리할 수 있습니다.
지원되는 운영 체제, Java 런타임, httpd 및 Dispatcher 버전을 실행 중인지 확인해야 합니다. 자세한 내용은 AEM 6. 4 기술 요구 사항 페이지를 참조하십시오. 이러한 구성 요소 업그레이드는 프로젝트 계획에서 설명되어야 하며 AEM을 업그레이드하기 전에 수행해야 합니다.

프로젝트 단계

AEM 업그레이드를 계획 및 실행하는 데 많은 작업이 소요됩니다. 이 과정에서 이루어지는 다양한 노력을 명확히 하기 위해 기획과 실행 연습을 별도의 단계로 분류했습니다. 아래 섹션에서 각 단계는 프로젝트의 향후 단계에서 종종 활용되는 결과물을 생성합니다.

작성자 교육 계획

새로운 릴리스에서는 UI 및 사용자 워크플로우에 대한 잠재적인 변경 사항이 적용될 수 있습니다. 또한 새로운 릴리스에서는 비즈니스에 도움이 될 수 있는 새로운 기능이 도입되었습니다. 도입된 기능 변경 사항을 검토하고 사용자를 효과적으로 활용할 수 있도록 교육 계획을 구성하는 것이 좋습니다.
AEM 6.4의 새로운 기능은 adobe.com 의 AEM 섹션에 있습니다. 조직에서 일반적으로 사용되는 UI 또는 제품 기능의 변경 사항을 반드시 메모해 두십시오. 새로운 기능을 살펴보면서 조직에 유용한 모든 기능을 살펴볼 수 있습니다. AEM 6.4의 변경 사항을 살펴본 후 작성자를 위한 교육 계획을 수립합니다. 여기에는 도움말 기능 비디오나 Adobe 디지털 학습 서비스를 통해 제공되는 공식 트레이닝과 같이 무료로 제공되는 리소스를 활용할 수 있습니다 .

테스트 계획 만들기

각 고객의 AEM 구현은 고유하며 비즈니스 요구 사항을 충족하도록 맞춤화되었습니다. 따라서 테스트 계획에 포함할 수 있도록 시스템에 대해 수행된 모든 사용자 지정을 확인하는 것이 중요합니다. 이 테스트 계획은 업그레이드된 인스턴스에서 수행하는 QA 프로세스를 강화합니다.
모든 애플리케이션과 사용자 지정 코드가 원하는 대로 계속 실행되도록 하려면 정확한 프로덕션 환경을 복제해야 하며 업그레이드 후에 테스트를 수행해야 합니다. 사용자 지정을 모두 등록하고 성능, 로드 및 보안 테스트를 실행해야 합니다. 테스트 계획을 구성할 때는 일상적으로 작업하는 동안 활용되는 기본 UI 및 워크플로우 외에 시스템에 수행된 모든 사용자 지정을 포함해야 합니다. 이러한 기능에는 사용자 정의 OSGI 서비스 및 서블릿, Adobe Marketing Cloud와의 통합, AEM 커넥터를 통한 타사 통합, 사용자 정의 타사 통합, 사용자 정의 구성 요소 및 템플릿, AEM의 사용자 정의 UI 오버레이, 사용자 정의 워크플로우가 포함될 수 있습니다. AEM 6 이전 버전에서 마이그레이션하는 고객의 경우 색인이 필요할 수 있으므로 모든 사용자 지정 쿼리를 분석해야 합니다. 이미 AEM 6.x 버전을 사용하고 있는 고객의 경우 업그레이드 후에도 해당 인덱스가 계속 효과적으로 작동되도록 테스트를 거쳐야 합니다.

건축과 인프라 변화 결정

업그레이드할 때 운영 체제 또는 JVM과 같은 기술 스택의 다른 구성 요소를 업그레이드해야 할 수도 있습니다. 또한 저장소 구성의 변경 사항으로 인해 추가 하드웨어가 필요할 수 있습니다. 일반적으로 6.x 이전 인스턴스에서 마이그레이션하는 고객에게만 해당되지만 고려해야 할 사항은 중요합니다. 마지막으로 모니터링, 유지 관리, 백업 및 재해 복구 프로세스 등 운영 방식에 변경이 필요할 수 있습니다.
AEM 6.4의 기술 요구 사항을 검토하고 현재 하드웨어와 소프트웨어가 충분한지 확인합니다. 운영 프로세스에 대한 잠재적 변경 사항은 다음 문서를 참조하십시오.
모니터링 및 유지 관리:
백업/복원 및 재해 복구:

컨텐츠 재구성 고려 사항

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

업그레이드 복잡성 평가

고객이 AEM 환경에 적용하는 사용자 지정의 양과 특성에 따라 다양하기 때문에 업그레이드에 예상해야 하는 전반적인 노력 수준을 결정하기 위해 몇 시간을 먼저 보내는 것이 중요합니다.
업그레이드의 복잡성을 평가하기 위해 취할 수 있는 두 가지 접근 방법이 있으며, 예비 단계에서는 AEM 6.1, 6.2 및 6.3 인스턴스에서 실행할 수 있는 새롭게 도입된 패턴 탐지기를 사용할 수 있습니다. 패턴 탐지기는 보고된 패턴을 사용하여 예상되는 업그레이드의 전반적인 복잡성을 평가하는 가장 쉬운 방법입니다. 패턴 탐지기 보고서에는 사용자 지정 코드베이스에서 사용 중인 사용할 수 없는 API를 식별하기 위한 패턴이 포함되어 있습니다(6.3에서 업그레이드 전 호환성 검사를 사용하여 수행됨).
초기 평가 후 보다 포괄적인 다음 단계는 테스트 인스턴스에서 업그레이드를 수행하고 몇 가지 기본적인 연기 테스트를 수행하는 것입니다. Adobe에서 제공하는 다양한 기능 또한 더 이상 사용되지 않음 및 제거된 기능 목록은 업그레이드할 버전뿐만 아니라 소스 버전과 대상 버전 간의 모든 버전에 대해서도 검토해야 합니다. 예를 들어 AEM 6.2에서 6.4로 업그레이드하는 경우 AEM 6.4에 대한 기능 외에 더 이상 사용되지 않고 제거된 기능을 검토해야 합니다.
6.4에 도입된 패턴 탐지기는 대부분의 경우에 업그레이드 시 예상되는 사항에 대한 정확한 예측을 제공합니다. 그러나 호환되지 않는 변경 사항이 있는 복잡한 사용자 지정 및 배포의 경우 적소에 업그레이드 수행의 지침에 따라 개발 인스턴스를 AEM 6.4로 업그레이드할 수 있습니다 . 완료되면 이 환경에서 고급 연기 테스트를 수행합니다. 이 연습의 목적은 테스트 케이스 재고를 철저히 완료하여 공식 결함 재고를 제공하는 것이 아니라 6.4 호환성을 위해 코드를 업그레이드하는 데 필요한 작업 양을 대략적으로 추정하기 위한 것입니다. 패턴 감지 및 이전 섹션에서 결정한 아키텍처 변경 사항과 결합하면 업그레이드를 계획하기 위해 프로젝트 관리 팀에 가산 견적을 제공할 수 있습니다.

업그레이드 및 롤백 Runbook 작성

Adobe에서 AEM 인스턴스 업그레이드 프로세스를 문서화했지만 각 고객의 네트워크 레이아웃, 배포 아키텍처 및 사용자 지정을 위해서는 이 방법을 세밀하게 조정하고 수정해야 합니다. 이러한 이유로 Adobe가 제공한 모든 설명서를 검토하고 이를 사용하여 귀하의 환경에서 수행해야 할 특정 업그레이드 및 롤백 절차에 대해 대략적으로 설명하는 프로젝트 특정 Runbook에 알리십시오. CRX2에서 업그레이드하는 경우 CRX2에서 Oak로 이동할 때 컨텐츠 마이그레이션에 걸리는 시간을 평가해야 합니다. 대형 리포지토리의 경우 상당한 가치가 있을 수 있습니다.
업그레이드 절차에 업그레이드 및 롤백 절차는 물론 업그레이드 수행 시 업그레이드를 적용하기 위한 단계별 지침을 제공했습니다 . 이러한 지침은 시스템 아키텍처, 사용자 지정 및 다운타임 허용 여부와 함께 검토하여 업그레이드 중에 실행할 적절한 전환 및 롤백 절차를 판단해야 합니다. 맞춤형 Runbook을 작성할 때 아키텍처 또는 서버 크기에 대한 변경 사항이 포함되어야 합니다. 이 항목은 첫 번째 초안으로 취급해야 한다는 점에 유의하십시오. 팀에서 QA 및 개발 주기를 완료하고 스테이징 환경으로 업그레이드를 배포하면 몇 가지 추가 단계가 필요할 수 있습니다. 가장 좋은 방법은 이 문서에 필요한 정보를 충분히 포함하고 있어야 합니다. 이러한 정보를 작업 담당자에게 전달하면 해당 작업에 포함된 정보에서 업그레이드를 완전히 완료할 수 있습니다.

프로젝트 계획 개발

이전 연습의 결과물을 사용하여 테스트 또는 개발 노력, 트레이닝 및 실제 업그레이드 실행에 대한 예상 일정을 포함하는 프로젝트 계획을 구축할 수 있습니다.
포괄적인 프로젝트 계획에는 다음이 포함되어야 합니다.
  • 개발 및 테스트 계획의 완성
  • 개발 및 QA 환경 업그레이드
  • AEM 6.4용 사용자 지정 코드 베이스 업데이트
  • QA 테스트 및 수정 주기
  • 스테이징 환경 업그레이드
  • 통합, 성능 및 로드 테스트
  • 환경 인증
  • 라이브

개발 및 QA 수행

AEM 6.4 와 호환되도록 코드 및 사용자 지정 업그레이드 절차를 제공했습니다.이 반복 프로세스가 실행되면 필요에 따라 Runbook을 변경해야 합니다. 업그레이드 후 바로 개발하지 않고도 대부분의 경우 사용자 지정 내용이 이전 버전과 호환되는 방법에 대한 자세한 내용은 AEM 6.4의 이전 버전과의 호환성을 참조하십시오.
개발 및 테스트 프로세스는 일반적으로 반복적인 프로세스입니다. 사용자 지정 사항으로 인해 업그레이드 중 변경된 내용은 제품의 전체 섹션을 사용할 수 없게 될 수 있습니다. 개발자가 문제의 근본 원인을 해결하고 테스트 팀이 이러한 기능을 테스트할 수 있게 되면 추가 문제를 발견할 수 있습니다. 업그레이드 프로세스를 조정해야 하는 문제가 발견되면 사용자 지정 업그레이드 Runbook에 추가해야 합니다. 테스트 및 수정을 여러 번 반복한 후 코드 베이스의 유효성을 철저히 검사하여 스테이징 환경에 배포할 수 있어야 합니다.

최종 테스트

코드 베이스가 조직의 QA 팀에서 인증한 후 최종 테스트 라운드를 권장합니다. 이 테스트는 스테이징 환경에서 Runbook을 검증한 후 사용자 수락, 성능 및 보안 테스트가 라운드됩니다.
이 단계는 프로덕션과 같은 환경에서 Runbook의 단계를 확인할 수 있는 유일한 시간이므로 매우 중요합니다. 환경이 업그레이드된 후에는 최종 사용자가 로그인하여 일상적으로 시스템을 사용할 때 수행하는 작업을 수행할 수 있도록 하는 것이 중요합니다. 이전에 고려되지 않았던 시스템의 일부를 사용자가 활용하는 것은 드문 일이 아닙니다. 이러한 영역에서 문제를 찾아 미리 수정한 후 라이브하면 많은 비용이 소요되는 운영 중단을 방지할 수 있습니다. 새 버전의 AEM에는 기본 플랫폼에 대한 중요한 변경 사항이 포함되어 있으므로 처음 실행하는 것처럼 시스템에서 성능, 로드 및 보안 테스트를 수행하는 것도 중요합니다.

업그레이드 수행

모든 이해 관계자로부터 최종 로그오프가 수신되면, 정의된 Runbook 절차에서 실행될 때입니다. 업그레이드 절차 및 설치 단계에서 업그레이드 및 롤백을 위한 단계와 참조 지점으로 즉석 업그레이드 수행을위한 단계를 제공했습니다.
환경 확인을 위한 업그레이드 지침에 몇 가지 단계를 제공했습니다. 이러한 기능에는 업그레이드 로그 스캔 및 모든 OSGi 번들이 제대로 시작되었는지 확인하는 등의 기본 검사가 포함되어 있지만 비즈니스 프로세스에 따라 자체 테스트 케이스를 확인하는 것이 좋습니다. 또한 AEM의 온라인 개정 정리 일정 및 관련 루틴을 확인하여 회사의 조용한 시간 동안 이러한 루틴을 발생시킬 것을 권장합니다. 이러한 루틴은 AEM의 장기적인 성능에 필수적입니다.