Show Menu
화제×

자산 크기 조정 안내서

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

디스크

DataStore

에셋 구현에 필요한 디스크 공간을 크기 조정할 때 발생하는 일반적인 실수는 인제스트할 Raw 이미지 크기를 기준으로 계산하기 위한 것입니다. 기본적으로 AEM은 AEM UI 요소 렌더링에 사용할 원본 이미지 외에 3개의 변환을 만듭니다. 이전 구현에서 이러한 변환은 인제스트된 자산의 두 배 크기를 가정했습니다.
대부분의 사용자는 기본 변환 외에 사용자 정의 변환을 정의합니다. AEM Assets에서는 표현물 외에도 InDesign 및 Illustrator와 같은 일반적인 파일 유형에서 하위 자산을 추출할 수 있습니다.
마지막으로, AEM의 버전 관리 기능은 버전 내역에 자산의 복제본을 저장합니다. 자주 삭제되도록 버전을 구성할 수 있습니다. 그러나 많은 사용자가 시스템의 버전을 오랫동안 유지하려고 하여 추가 저장 공간을 사용합니다.
이러한 요인을 고려하여 사용자 에셋을 저장할 수 있는 사용이 편리한 정확한 저장 공간을 계산하기 위한 방법론이 필요합니다.
  1. 시스템에 로드할 자산의 크기와 수를 결정합니다.
  2. AEM 파섹 예를 들어 PSD, JPG, AI 및 PDF 파일을 시스템에 로드하려면 각 파일 포맷의 여러 샘플 이미지가 필요합니다. 또한 이러한 샘플들은 이미지의 다양한 파일 크기와 복잡성을 나타내야 합니다.
  3. 사용할 변환을 정의합니다.
  4. ImageMagick 또는 Adobe의 Creative Cloud 애플리케이션을 사용하여 AEM에서 변환을 만듭니다. 사용자가 지정하는 변환 외에 즉시 사용 가능한 변환을 만듭니다. Scene7을 구현하는 사용자의 경우 IC 바이너리를 사용하여 AEM에 저장할 PTIFF 변환을 생성할 수 있습니다.
  5. 하위 자산을 사용하려면 적절한 파일 유형에 대해 하위 자산을 생성합니다. InDesign 파일 또는 Illustrator 레이어에서 PNG/PDF 파일에서 하위 자산 페이지를 생성하는 방법에 대한 온라인 설명서를 참조하십시오.
  6. 출력 이미지, 변환 및 하위 자산의 크기를 원본 이미지와 비교합니다. 시스템이 로드되면 예상 성장 요소를 생성할 수 있습니다. 예를 들어 1GB의 자산을 처리한 후 크기가 3GB인 표현물과 하위 자산을 생성하는 경우, 표현물 증가 요인은 3입니다.
  7. 시스템에서 자산 버전을 유지 관리할 최대 시간을 결정합니다.
  8. 시스템에서 기존 자산이 변경되는 빈도를 결정합니다. AEM이 크리에이티브 워크플로에서 공동 작업 허브로 사용되는 경우 변경 내용이 높습니다. 완성된 자산만 시스템에 업로드하면 이 수가 훨씬 더 적습니다.
  9. 시스템에 매달 로드되는 자산의 수를 결정합니다. 확실하지 않은 경우 현재 사용 가능한 자산의 수를 확인하고 가장 오래된 자산의 연령으로 숫자를 나누어 대략적인 숫자를 계산합니다.
1-9 단계를 수행하면 다음을 결정하는 데 도움이 됩니다.
  • 로드할 자산의 원시 크기
  • 로드할 자산 수
  • 변환 증가 계수
  • 월별 자산 수정 수
  • 자산 버전을 유지 관리할 개월 수
  • 매월 로드되는 새 자산 수
  • 공간을 할당할 수 있는 성장 기간
네트워크 크기 조정 스프레드시트에서 이러한 숫자를 지정하여 데이터 저장소에 필요한 총 공간을 결정할 수 있습니다. 또한 에셋 버전을 유지 관리하거나 AEM에서 에셋을 수정하여 디스크 증가에 미치는 영향을 파악하는 유용한 도구입니다.
도구에 채워진 예제 데이터는 언급된 단계를 수행하는 것이 얼마나 중요한지를 보여 줍니다. 로드되는 Raw 이미지(1TB)를 기반으로 데이터 저장소의 크기를 조정하는 경우 저장소 크기를 15의 배율로 과소 계산했을 수 있습니다.

공유 데이터 저장소

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

Use Cases

기본 및 대기 작성자 인스턴스 간에 데이터 저장소를 공유하여 기본 인스턴스에서 변경한 내용으로 대기 인스턴스를 업데이트하는 데 소요되는 시간을 최소화할 수 있습니다. Adobe는 기본 작성자 인스턴스 간에 데이터 저장소를 공유하고 워크플로우 오프로딩 시 오버헤드를 줄이기 위해 작성자 인스턴스를 오프로드할 것을 권장합니다. 또한 작성자와 게시 인스턴스 간에 데이터 저장소를 공유하여 복제 중 트래픽을 최소화할 수 있습니다.

Drawbacks

일부 문제 때문에 데이터 저장소를 공유하는 것이 모든 경우에 권장되지 않습니다.

단일 장애 지점

공유 데이터 저장소가 있으면 인프라에서 단일 장애 지점이 발생합니다. 시스템에 각각 고유한 데이터 저장소가 있는 작성자 및 게시 인스턴스가 하나씩 있는 시나리오를 생각해 보십시오. 충돌이 발생한 경우 나머지 두 개는 계속 실행할 수 있습니다. 그러나 데이터 저장소가 공유되면 단일 디스크 장애가 전체 인프라를 다운시킬 수 있습니다. 따라서 데이터 저장소를 신속하게 복원할 수 있는 공유 데이터 저장소의 백업을 유지 관리해야 합니다.
공유 데이터 저장소에 대한 AWS S3 서비스 배포는 일반적인 디스크 아키텍처와 비교하여 실패 가능성을 상당히 감소시켜주므로 더 선호됩니다.

복잡성 증가

또한 공유 데이터 저장소에서는 가비지 수집과 같은 작업의 복잡성도 높아집니다. 일반적으로 독립형 데이터 저장소에 대한 가비지 수집은 한 번의 클릭으로 시작할 수 있습니다. 그러나 공유 데이터 저장소에서는 단일 노드에서 실제 컬렉션을 실행하는 것 외에 데이터 저장소를 사용하는 각 멤버에 대해 표시 제거 작업이 필요합니다.
AWS 작업의 경우, EBS 볼륨의 RAID 어레이를 구축하지 않고 단일 중앙 위치(S3를 통해)를 구현하면 시스템의 복잡성과 운영 위험을 크게 상쇄할 수 있습니다.

성능 문제

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

지연

S3 구현의 지연은 백그라운드 쓰기 스레드에서 도입됩니다. 백업 절차는 이 지연 및 모든 오프로딩 절차를 고려해야 합니다. 오프로딩 작업이 시작되면 S3에 S3 자산이 없을 수 있습니다. 또한 백업을 만들 때 Lucene 색인은 불완전한 상태로 남아 있을 수 있습니다. S3 데이터 저장소에 기록되고 다른 인스턴스에서 액세스하는 시간 감지 파일에 적용됩니다.

Node Store/Document Store

NodeStore 또는 DocumentStore에 대한 정확한 크기 수치는 다음과 같은 리소스가 소비하므로 도달하기가 어렵습니다.
  • 자산 메타데이터
  • 자산 버전
  • 감사 로그
  • 보관 및 활성 워크플로우
바이너리는 데이터 저장소에 저장되므로 각 바이너리는 일부 공간을 차지합니다. 대부분의 저장소의 크기는 100GB 미만입니다. 그러나 용량이 최대 1TB까지 클 수 있습니다. 또한 오프라인 구성 작업을 수행하려면 미리 구성된 버전과 함께 압축된 저장소를 다시 작성하기 위해 볼륨에 충분한 여유 공간이 필요합니다. 디스크 크기를 저장소에 필요한 크기의 1.5배로 늘리는 것이 좋습니다.
저장소의 경우 IOPS 수준이 3000을 초과하는 SSD 또는 디스크를 사용하십시오. IOPS가 성능 병목 현상을 유발할 가능성을 제거하려면 CPU IO 대기 수준을 모니터링하여 문제의 조기 징후를 파악하십시오.

네트워크

AEM Assets에는 많은 AEM 프로젝트보다 네트워크 성능이 더 중요한 많은 사용 사례가 있습니다. 고객은 빠른 서버를 가질 수 있지만 네트워크 연결이 시스템의 에셋을 업로드하고 다운로드하는 사용자의 로드를 지원할 만큼 크지 않으면 여전히 속도가 느려지는 것으로 보입니다. 사용자 경험, 인스턴스 크기 조정, 워크플로우 평가 및 네트워크 토폴로지에 대한 AEM 자산에서 사용자의 AEM에 대한 네트워크 연결에서 경계 지점을 결정하는 좋은 방법이 있습니다.

WebDAV

AEM 데스크탑 앱을 혼합에 추가하는 경우 WebDAV 프로토콜의 비효율성으로 인해 네트워크 문제가 더 심각해집니다.
이러한 비효율성을 설명하기 위해 Adobe는 OS X에서 WebDAV를 사용하여 시스템 성능을 테스트했습니다.3.5MB InDesign 파일을 열고 편집했으며 변경 사항이 저장되었습니다. 다음의 관찰이 수행되었습니다.
  • 작업을 완료하기 위해 생성된 총 약 100개의 HTTP 요청
  • HTTP를 통해 파일이 4번 업로드되었습니다.
  • HTTP를 통해 파일을 한 번 다운로드했습니다.
  • 전체 작업을 완료하는 데 42초가 걸렸습니다.
  • 총 18MB 데이터가 전송되었습니다.
WebDAV를 통해 파일의 평균 저장 시간을 분석하는 동안 대역폭 사용량이 5-10Mbps 수준까지 증가하면 성능이 크게 향상되는 것으로 나타났습니다. 따라서 Adobe는 동시에 시스템을 액세스하는 각 사용자가 최소 10Mbps의 업로드 속도와 5-10Mbps의 대역폭을 갖도록 권장합니다.
자세한 내용은 AEM 데스크톱 앱 문제 해결을 참조하십시오.

제한 사항

구현 크기를 조정할 때는 시스템 제한 사항을 염두에 두어야 합니다. 제안된 구현이 이러한 제한 사항을 초과하는 경우 여러 Assets 구현에서 자산을 분할하는 것과 같은 크리에이티브 전략을 사용하십시오.
파일 크기만 메모리 부족(OOM) 문제에 영향을 주는 것은 아닙니다. 이미지의 크기에도 따라 다릅니다. AEM을 시작할 때 더 큰 더미 크기를 제공하여 OOM 문제를 방지할 수 있습니다.
또한 Configuration Manager에서 구성 요소의 임계값 크기 속성을 편집하여 0보다 큰 중간 임시 파일을 사용할 수 있습니다. com.day.cq.dam.commons.handler.StandardImageHandler

최대 자산 수

파일 시스템 제한으로 인해 데이터 저장소에 존재할 수 있는 파일 수에 대한 제한은 21억입니다. 데이터 저장소 제한에 도달하기 전에 많은 수의 노드로 인해 저장소에 문제가 발생할 수 있습니다.
변환이 잘못 생성된 경우 Camera Raw 라이브러리를 사용합니다. 그러나 이 경우 이미지의 가장 긴 면은 65000픽셀보다 크지 않아야 합니다. 또한 이미지에 512MP(512 *)를 초과할 수 없습니다.1024 *1024픽셀)' 자산의 크기는 중요하지 않습니다 .
픽셀 크기 등의 추가 요인이 처리 과정에 영향을 주므로 OTB(즉시 사용 가능)에서 지원되는 TIFF 파일의 크기를 정확하게 계산하기 어렵습니다. AEM에서는 255MB OTB 크기의 파일을 처리할 수 있지만 18MB의 파일 크기는 이전 픽셀과 비교하여 비정상적으로 더 많은 픽셀로 구성되어 있기 때문에 처리할 수 없습니다.

자산 크기

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