부적절한 EBS 스토리지 성능(AMS)으로 인한 AEM 작성자 불안정성과 심각한 지연
이 문서에서는 기본 EBS 볼륨 유형이 AEM의 TarMK 저장소의 I/O 요구 사항을 충족하지 않는 Adobe Managed Services(AMS)에 호스팅된 AEM 작성자 인스턴스의 반복적인 성능 저하 및 불안정성에 대해 설명합니다.
설명 description
환경
Amazon EBS 스토리지에서 지원하는 Adobe Managed Services(AMS)의 TarMK 저장소를 사용하는 Adobe Experience Manager 배포
문제/증상
AEM 작성자 인스턴스는 다음 중 하나 이상을 포함하여 일반 작성 작업 로드에서 불안정이 반복적으로 발생합니다.
- 표준 편집기, 셸 및 CSRF 토큰 요청에 대해 1분 이상의 응답 시간을 갖는 작성자 UI의 심각한 지연.
- 504 게이트웨이 시간 초과 및 작성자가 보고한 404 오류.
- 게시 작업이 실패했거나 상당히 지연되었습니다.
- 원격 DAM 이벤트 처리가 지연되고 차단됩니다.
성능이 저하된 기간 동안 또는 그 후에 error.log에서 다음 경고 및 오류가 나타날 수 있습니다.
*WARN* [ sling-oak-N-org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate-async]
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler
Failed to create checkpoint <uuid> in 10 seconds.
*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory
Couldn't compute safe timestamp to delete files from NIOFSDirectory@/mnt/crx/.../index/.../data
*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
File <segment> doesn't exist in /mnt/crx/.../repository/index/.../data
*WARN* [ sling-default-N-Registered Service.NNNNN]
com.adobe.cq.remotedam.internal.lifecycle.event.consumer.impl.LifecycleEventConsumerImpl
This sites instance is lagging far too behind Remote DAM. Pulling events is blocked
이러한 기간에 대한 request.log의 상관 관계는 일반적으로 상태 검사, 편집기, pulse 및 CSRF 토큰 종단점 전체에 걸쳐 30초~몇 분 후에 완료되는 요청 클러스터를 나타냅니다. 이 패턴은 단일 느린 요청이 아닌 JVM 전체의 지연을 나타냅니다.
원인
/mnt/crx 아래에 저장된 AEM의 TarMK 저장소는 세그먼트 저장소 쓰기, 체크포인트 생성, Lucene 인덱스 업데이트 및 압축을 위해 빈번한 순차적 및 무작위 I/O 작업을 수행합니다. 이러한 저장소 워크로드에는 일관된 스토리지 지연 시간과 충분한 IOPS가 필요합니다.
표준 마그네틱 EBS 볼륨은 이러한 워크로드에 적합한 성능 특성을 제공하지 않을 수 있습니다. 스토리지 처리량이 제한되면 운영 체제에서 지속적인 입출력 대기가 발생하여 여러 JVM 스레드 풀이 동시에 중지되고 관련 없는 요청에서 광범위한 애플리케이션 지연이 발생할 수 있습니다.
이 문제는 gp3 EBS 볼륨이 표준 저장소 스토리지 옵션이 되기 전에 마그네틱 EBS 볼륨으로 원래 프로비저닝된 비프로덕션 AMS 환경에서 가장 일반적으로 관찰됩니다. 운영 환경은 gp3 스토리지에서 프로비저닝되거나 나중에 gp3 스토리지로 마이그레이션되므로 영향을 받지 않는 경우가 많습니다.
해결 방법 resolution
반복되는 AEM Author 불안정, 심각한 지연 시간 및 저장소 성능 문제를 식별하고 해결하려면 다음 단계를 수행합니다.
- 영향을 받는 작성자 인스턴스에서 Amazon EBS 볼륨 유형 지원
/mnt/crx을(를) 확인하십시오. CSE(고객 성공 엔지니어)에 문의하여 볼륨 구성을 확인하고 저장소가 gp3 EBS 볼륨에서 호스팅되는지 확인합니다. - 저장소가 표준 자기 스토리지에서 호스팅되는 경우 gp3 EBS 볼륨으로의 마이그레이션을 평가합니다. AMS 계약에 따라 CSE와 함께 모든 서비스 또는 비용 고려 사항을 검토하십시오.
- CSE를 통해 스토리지 마이그레이션을 요청합니다. AMS 인프라 팀과 협력하여 마이그레이션 계획을 수립하고 저장소 크기 및 워크로드 요구 사항에 따라 타겟 IOPS 및 처리량 설정을 확인합니다.
- 저장소 볼륨을 gp3 EBS 볼륨으로 마이그레이션합니다. AMS 인프라 팀은 일반적으로 AEM 인스턴스를 중지하고, 기존 볼륨의 스냅샷을 만들고, 스토리지를 마이그레이션하고, 인스턴스를 다시 시작하여 이 프로세스를 수행합니다.
- 동일한 스토리지 구성을 사용하는 경우 영향을 받는 게시자 인스턴스를 마이그레이션 계획에 포함합니다.
- 마이그레이션 후 시스템 성능을 측정합니다. 일반적인 작성 작업 동안 I/O 대기, 스왑 사용 및 로드 평균이 감소했는지 확인합니다.
request.log을(를) 검토하고 편집기 및 유틸리티 끝점에 더 이상 1초 또는 1분 길이의 응답 시간이 표시되지 않는지 확인하십시오.error.log을(를) 검토하고 검사점 오류 메시지와 Lucene 인덱스 경고가 다시 발생하지 않는지 확인하십시오.- 작성자 페이지 편집기가 정상적으로 로드되고, 게시 작업이 성공적으로 완료되고, 비동기 인덱싱이 최신 상태로 유지되며, 원격 DAM 이벤트 프로세스가 지연 없이 진행되는지 확인하십시오.
- 마이그레이션 후 불안정성이 지속되면 반복되는 성능 저하와 대규모 복제 버스트, MSM 롤아웃, 패키지 배포 또는 대규모 에셋 수집과 같은 저장소 중심 작업의 상관 관계를 파악합니다.
- 최대 저장소 수요가 성능에 계속 영향을 줄 경우 영향력이 큰 워크로드의 일정 조정 또는 제한을 조정합니다.