Assets 크기 조정 안내서 assets-sizing-guide

Adobe Experience Manager Assets 구현을 위해 환경 크기를 조정할 때 디스크, CPU, 메모리, IO 및 네트워크 처리량 측면에서 사용 가능한 리소스가 충분한지 확인하는 것이 중요합니다. 이러한 리소스 중 많은 크기를 조정하려면 시스템에 로드되는 자산 수를 이해해야 합니다. 더 나은 지표를 사용할 수 없는 경우 기존 라이브러리의 크기를 라이브러리 페이지로 나누어 자산이 만들어지는 비율을 찾을 수 있습니다.

디스크 disk

DataStore datastore

자산 구현에 필요한 디스크 공간 크기를 조정할 때 발생하는 일반적인 오류는 시스템에 수집할 원시 이미지의 크기를 기반으로 계산되는 것입니다. 기본적으로 Experience Manager 는 렌더링을 위해 원본 이미지 외에 세 개의 렌디션을 만듭니다. Experience Manager UI 요소. 이전 구현에서 이러한 표현물은 수집된 자산의 두 배 크기를 가정하기 위해 관찰되었습니다.

대부분의 사용자는 기본 제공 표현물 외에 사용자 지정 표현물을 정의합니다. Assets를 사용하면 표현물 외에도 InDesign 및 Illustrator과 같은 일반적인 파일 유형에서 하위 자산을 추출할 수 있습니다.

마지막으로, AEM 버전 관리 기능은 버전 기록에 자산의 중복을 저장합니다. 자주 삭제되도록 버전을 구성할 수 있습니다. 그러나 많은 사용자가 시스템의 버전을 오랫동안 보존하도록 선택하므로 추가 저장 공간이 소모됩니다.

이러한 요소를 고려하여 사용자 자산을 저장할 수 있도록 허용 가능한 정확한 스토리지 공간을 계산하기 위한 방법론이 필요합니다.

1-9단계를 수행하면 다음 사항을 결정하는 데 도움이 됩니다.

네트워크 크기 조정 스프레드시트에서 이러한 숫자를 지정하여 데이터 저장소에 필요한 총 공간을 결정할 수 있습니다. 또한 자산 버전을 유지 관리하거나 자산을 수정하는 것의 영향을 결정하는 데 유용한 도구입니다 Experience Manager 디스크 증가 시

도구에서 채워진 예제 데이터는 언급된 단계를 수행하는 것이 얼마나 중요한지 보여줍니다. 로드된 원시 이미지(1TB)를 기반으로 데이터 저장소의 크기를 지정하는 경우 저장소 크기를 15배수로 과소 평가했을 수 있습니다.

파일 가져오기

공유 데이터 저장소 shared-datastores

큰 데이터 저장소의 경우 네트워크에 연결된 드라이브의 공유 파일 데이터 저장소를 통해 또는 S3 데이터 저장소를 통해 공유 데이터 저장소를 구현할 수 있습니다. 이 경우 개별 인스턴스는 바이너리 사본을 유지 관리할 필요가 없습니다. 또한 공유 데이터 저장소는 바이너리 없는 복제를 용이하게 하며, 자산을 게시 환경에 복제하거나 인스턴스를 오프로딩하는 데 사용되는 대역폭을 줄이는 데 도움이 됩니다.

사용 사례 use-cases

기본 및 대기 작성자 인스턴스 간에 데이터 저장소를 공유하여 기본 인스턴스에서 변경된 내용으로 대기 인스턴스를 업데이트하는 데 걸리는 시간을 최소화할 수 있습니다. Adobe은 워크플로우 오프로딩에서 오버헤드를 줄이려면 기본 작성자 인스턴스와 작성자 인스턴스 간에 데이터 저장소를 공유하는 것이 좋습니다. 작성자 및 게시 인스턴스 간에 데이터 저장소를 공유하여 복제 중 트래픽을 최소화할 수도 있습니다.

단점 drawbacks

몇 가지 위험 때문에 모든 경우에 데이터 저장소를 공유하는 것이 권장되지 않습니다.

단일 장애 지점 single-point-of-failure

공유 데이터 저장소가 있는 경우 인프라에서 단일 장애 지점이 발생합니다. 시스템에 하나의 작성자 및 두 개의 게시 인스턴스가 있고 각각 고유한 데이터 저장소가 있는 시나리오를 생각해 보십시오. 충돌하면 다른 두 항목은 계속 실행될 수 있습니다. 그러나 데이터 저장소가 공유되면 단일 디스크 오류로 인해 전체 인프라가 다운될 수 있습니다. 따라서 데이터 저장소를 빠르게 복원할 수 있는 공유 데이터 저장소의 백업을 유지 관리해야 합니다.

공유 데이터 저장소에 대해 AWS S3 서비스를 배포하는 것이 좋습니다. 일반적인 디스크 아키텍처에 비해 장애 발생 가능성이 상당히 감소하기 때문입니다.

복잡성 증가 increased-complexity

공유 데이터 저장소는 가비지 수집과 같은 작업의 복잡성도 높입니다. 일반적으로 독립형 데이터 저장소에 대한 가비지 수집은 한 번의 클릭으로 시작할 수 있습니다. 그러나 공유 데이터 저장소는 단일 노드에서 실제 수집을 실행하는 것 외에도 데이터 저장소를 사용하는 각 멤버에 대한 표시 제거 작업이 필요합니다.

AWS 작업의 경우 EBS 볼륨의 RAID 어레이를 만들지 않고 S3를 통해 단일 중앙 위치를 구현하면 시스템의 복잡성과 운영 위험을 크게 상쇄할 수 있습니다.

성능 문제 performance-concerns

공유 데이터 저장소를 사용하려면 모든 인스턴스 간에 공유되는 네트워크 마운트 드라이브에 바이너리를 저장해야 합니다. 이러한 바이너리는 네트워크를 통해 액세스되므로 시스템 성능에 부정적인 영향을 줍니다. 빠른 네트워크 연결을 사용하여 빠른 디스크 어레이에 대한 영향을 부분적으로 줄일 수 있습니다. 그러나, 이것은 비싼 제안이다. AWS 작업의 경우 모든 디스크가 원격이며 네트워크 연결이 필요합니다. 사용 후 볼륨은 인스턴스가 시작되거나 중지되면 데이터가 손실됩니다.

지연 latency

S3 구현의 지연은 백그라운드 쓰기 스레드에서 도입됩니다. 백업 절차는 이러한 지연 시간 및 오프로딩 절차를 고려해야 합니다. 오프로딩 작업이 시작될 때 S3 자산이 S3에 없을 수 있습니다. 또한 백업을 수행할 때 Lucene 인덱스가 불완전할 수 있습니다. S3 데이터 저장소에 기록하고 다른 인스턴스에서 액세스하는 시간 구분 파일에 적용됩니다.

노드 저장소/문서 저장소 node-store-document-store

NodeStore 또는 DocumentStore에 대한 정확한 크기 조정 수치를 얻기 어렵습니다. 이는 다음과 같은 리소스에서 소비되는 리소스입니다.

바이너리는 데이터 저장소에 저장되므로 각 바이너리는 일부 공간을 차지합니다. 대부분의 리포지토리는 크기가 100GB 미만입니다. 그러나 최대 1TB의 대용량 저장소가 있을 수 있습니다. 또한 오프라인 압축을 수행하려면 미리 압축된 버전과 함께 압축된 리포지토리를 다시 작성하기에 충분한 공간이 볼륨에 필요합니다. 디스크의 크기를 리포지토리에 필요한 크기의 1.5배까지 조정하는 것이 가장 좋습니다.

저장소의 경우 IOPS 수준이 3000보다 큰 SSD 또는 디스크를 사용하십시오. 성능 병목 현상을 야기하는 IOPS의 가능성을 제거하기 위해 CPU IO 대기 수준을 모니터링하여 문제의 조기 징후를 확인하십시오.

파일 가져오기

네트워크 network

Assets 에는 대부분의 Adobe에서 사용하는 것보다 네트워크 성능이 더 중요한 사용 사례가 많습니다 Experience Manager 프로젝트를 참조하십시오. 고객은 빠른 서버를 사용할 수 있지만 네트워크 연결이 시스템에서 자산을 업로드하고 다운로드하는 사용자의 로드를 지원할 만큼 크지 않다면 속도가 느려진 것으로 보입니다. 사용자의 네트워크 연결에서 초크 포인트를 결정할 수 있는 좋은 방법이 있습니다 Experience Manager at Experience Manager 사용자 환경, 인스턴스 크기 조정, 워크플로우 평가 및 네트워크 토폴로지에 대한 자산 고려 사항.

WebDAV webdav

를 추가할 경우 Experience Manager WebDAV 프로토콜의 비효율성 때문에 데스크탑 앱을 혼용하면 네트워크 문제가 더욱 심각해집니다.

이러한 비효율성을 보여주기 위해 Adobe은 OS X에서 WebDAV를 사용하여 시스템 성능을 테스트했습니다. 3.5MB InDesign 파일이 열리거나 편집하고 변경 사항이 저장되었습니다. 다음 관찰이 수행되었습니다.

WebDAV를 통해 파일의 평균 저장 시간을 분석하는 동안 5-10Mbps 수준까지 대역폭이 증가함에 따라 성능이 크게 향상되는 것으로 나타났습니다. 따라서 Adobe은 시스템에 동시에 액세스하는 각 사용자가 업로드 속도 10Mbps와 5-10Mbps의 대역폭을 가져야 한다고 권장합니다.

자세한 내용은 문제 해결 Experience Manager 데스크탑 앱.

제한 사항 limitations

구현 크기를 조정할 때는 시스템 제한을 염두에 두어야 합니다. 제안된 구현이 이러한 제한 사항을 초과하는 경우 여러 자산 구현에서 자산을 분할하는 등의 광고 전략을 사용하십시오.

파일 크기가 메모리 부족(OOM) 문제에 기여하는 유일한 요소는 아닙니다. 이미지의 차원에도 따라 다릅니다. AEM을 시작할 때 더 큰 힙을 제공하여 OOM 문제를 방지할 수 있습니다.

또한, com.day.cq.dam.commons.handler.StandardImageHandler 구성 관리자의 구성 요소를 사용하여 0보다 큰 중간 임시 파일을 사용합니다.

최대 자산 수 maximum-number-of-assets

데이터 저장소에 있을 수 있는 파일 수로 제한되는 제한은 파일 시스템 제한 때문에 21억 개일 수 있습니다. 데이터 저장소 제한에 도달하기 훨씬 전에 많은 수의 노드로 인해 리포지토리에 문제가 발생할 수 있습니다.

표현물이 잘못 생성되면 Camera Raw 라이브러리를 사용합니다. 그러나 이 경우 이미지의 가장 긴 측면이 65000 픽셀보다 크지 않아야 합니다. 또한 이미지에는 512MP(512 *)를 초과할 수 없습니다 1024년 * 1024픽셀)'. 자산 크기가 중요하지 않음.

OOTB(기본 제공)에서 지원되는 특정 힙과 함께 TIFF 파일의 크기를 정확하게 추정하는 것은 어렵습니다 Experience Manager 픽셀 크기 등의 추가 요소가 처리에 영향을 주기 때문입니다. 가능한 건 Experience Manager 255MB OOTB의 파일을 처리할 수 있지만, 파일 크기가 18MB인 것은 처리할 수 없습니다. 파일의 크기는 이전에 비해 비정상적으로 더 많은 수의 픽셀로 구성되기 때문입니다.

자산 크기 size-of-assets

기본적으로 Experience Manager 최대 2GB의 파일 크기의 자산을 업로드할 수 있습니다. AEM에서 매우 큰 자산을 업로드하려면 다음을 참조하십시오 매우 큰 자산을 업로드하도록 구성.