FAQ
다음은 Adobe Experience Manager Guides에서 게시 워크플로, 확장 동작 및 인프라 성능을 관리하는 방법에 대한 자세한 통찰력을 제공하는 FAQ에 대한 답변 목록입니다. 대규모 게시를 위해 Experience Manager Guides을 사용하는 엔터프라이즈 사용자, 관리자 및 설명서 팀을 대상으로 합니다. 다이어그램은 Experience Manager Guides Publishing Architecture의 전체 워크플로를 설명합니다.
Experience Manager Guides은 하루에 몇 개의 게시 요청을 실행할 수 있습니까?
Experience Manager Guides이 하루에 처리할 수 있는 게시 요청 수는 컨텐츠 크기와 유형에 따라 다릅니다. 구성에 따라 시스템은 프로세서 코어당 하나의 게시 작업을 허용합니다. 현재 설정에서는 20개의 게시 작업을 동시에 실행할 수 있습니다(각각 2개의 pod × 10개의 코어).
프로덕션 환경이 자동으로 확장되므로 Pod가 4까지 확장되면 이 숫자는 동시 게시 작업 40개로 늘어날 수 있습니다.
얼마나 많은 게시 요청이 대기열에 추가되기 전에 동시에 실행될 수 있습니까?
- 최소(기본값): 20개의 게시 작업(2개의 pod)
- 최대(크기 조정): 게시 작업 40개(pod 4개)
이 숫자는 전체 서버 로드에 따라 달라질 수 있습니다. 다른 백그라운드 슬링 작업이 실행 중인 경우 처리 코어를 공유하므로 동시성이 20 미만으로 감소할 수 있습니다.
여러 게시 요청을 실행하는 것이 .dita 파일 편집과 같은 다른 애플리케이션 기능에 영향을 줍니까?
성능에 약간의 영향이 있을 수 있지만 일반적으로 최소입니다. 대부분의 대량 처리는 IO 런타임(서버를 사용하지 않는 게시 서비스)에서 발생하지만, AEM 인스턴스는 주로 종속성 생성 및 상태 폴링을 위한 I/O 작업을 수행합니다. 따라서 AEM 내의 CPU 활용도는 낮게 유지되며 작성/편집 경험은 크게 영향을 받지 않습니다.
Experience Manager Guides은 500KB를 초과하는 SVG 또는 .dita 파일과 같은 대용량 파일과 그래픽을 어떻게 관리합니까?
모든 큰 파일은 압축되어 JCR(Java Content Repository)에 저장됩니다. IO 런타임은 게시를 시작하기 전에 전체 zip 패키지를 가져옵니다. 여러 개의 대용량 파일(예: 각각 500KB)을 처리하는 경우에도 최적화된 패키징 및 병렬 I/O 처리로 인해 다운로드 또는 전송 속도에 크게 영향을 주지 않습니다.
Experience Manager Guides에서 사용하는 게시 인프라 및 구성은 무엇입니까?
Experience Manager Guides은 게시를 위해 컨테이너화된 서버리스 마이크로서비스를 사용합니다. 게시 서비스의 각 새 버전은 Adobe의 클라우드 환경에 자동으로 배포되는 도커 이미지로 릴리스됩니다. 이 설계는 다음을 보장합니다.
- 고객을 위한 전용 인프라 유지 보수 없음
- 게시 수요를 처리하기 위한 자동 크기 조정
- 빠른 업데이트 및 가동 중지 시간 최소화
오버로드로 인해 게시 큐 또는 관리 시스템이 충돌하는 경우 다른 AEM 기능이 영향을 받습니까?
아니요. Experience Manager Guides은 내결함성 아키텍처로 빌드되었습니다. 게시 큐에 오버로드가 발생하는 경우 요청이 자동으로 다시 시도되고, pod의 크기가 자동으로 조정되어 추가 로드를 처리합니다. 특정 임계값을 초과하면 안정성을 유지하기 위해 부하 제한이 적용됩니다. 다른 애플리케이션 영역(작성, 검토, 에셋 관리)은 영향을 받지 않습니다.
Experience Manager Guides에 로드가 많은 경우(Jenkins 모니터링과 유사)를 식별하는 데 사용할 수 있는 모니터링 도구 또는 로그 액세스가 있습니까?
아니요. 현재 내부 모니터링 도구에 대한 액세스 권한이 없습니다. Adobe 내부 팀의 경우 다음을 사용하여 모니터링을 수행할 수 있습니다.
- 로그 및 오류 추적용 Splunk
- Pod 수준 성능 및 확장 동작을 확인하기 위한 Kubernetes (K8s) CLI
성능 저하가 감지되면 고객은 Adobe 지원에 연락하여 조사 및 분석을 시작해야 합니다.
게시 요청을 마이크로서비스에 발송하기 전에 어떤 처리를 합니까?
맵 콘솔의 사전 설정 탭에서 게시 요청을 트리거하면 다음 단계가 수행됩니다.
- 시스템이 요청을 수락하고 베이스라인 및 조건부 사전 설정을 확인합니다.
- AEM은 모든 적격 DITA 에셋 및 종속성을 집계합니다.
- 이러한 자산은 zip 패키지에 번들로 제공됩니다.
- 서버를 사용하지 않는 게시 서비스는 도커 컨테이너를 활성화하고, 자산을 다운로드하고, 게시 작업을 실행하고, 생성된 출력 아티팩트를 다시 Experience Manager Guides에 배치합니다.
이 워크플로우는 안정적이고 격리되며 확장 가능한 게시 실행을 보장합니다.
맵이 마이크로서비스 컨테이너에 게시되기 전에 얼마나 많은 시간이 걸리고 이 시간을 정의하는 요소는 무엇입니까?
게시 요청은 일반적으로 마이크로서비스 컨테이너로 발송되기 전에 몇 분 정도 걸립니다. 이 초기 시간은 AEM 내의 종속성 집계에 사용됩니다.
서버를 사용하지 않는 게시 서비스에서 요청을 받은 후 총 게시 시간은 다음에 따라 달라집니다.
- DITA 맵 크기
- 주제 및 미디어 에셋 수
- 조건부 콘텐츠 및 서식 규칙의 복잡성
더 크거나 더 복잡한 맵을 게시하는 데 비례적으로 더 오래 걸릴 수 있습니다.
Experience Manager Guides에서 선착순 서비스 대신 대기열의 게시 요청을 우선 지정할 수 있습니까?
현재 모든 게시 작업은 동일하게 처리되며 선착순 (FCFS) 모델을 따릅니다. 현재 사용할 수 있는 우선 순위 지정 메커니즘이 없습니다.
그러나 향후 릴리스에서는 대기열 최적화 개선 사항의 일부로 우선 순위 지정 논리(예: 작업 크기 또는 비즈니스 중요도 기반)를 도입할 수 있습니다.
Experience Manager Guides은 게시 요청에 대한 자동 크기 조절을 어떻게 처리합니까?
Experience Manager Guides publishing infrastructure는 로드에 따라 자동 크기 조절을 지원합니다. 게시 수요가 증가할 때:
- 추가 포드(컨테이너)는 자동으로 회전됩니다.
- 각 Pod는 여러 게시 작업을 동시에 처리할 수 있습니다.
- 로드가 감소하면 pod가 축소되어 비용과 성능이 최적화됩니다.
이를 통해 고가용성과 일관된 성능을 보장하며 피크 로드 중에 대기열 시간을 최소화할 수 있습니다.
게시 작업이 실패하거나 시간이 초과되면 어떻게 됩니까?
일시적인 문제(예: 네트워크 중단, 서비스 시간 초과)로 인해 게시 요청이 실패하는 경우:
- 게시 서비스에 구성된 다시 시도 논리를 기반으로 자동으로 다시 시도합니다.
- 로그 및 오류 메시지는 진단 목적으로 백엔드에 캡처됩니다.
- 실패 상태를 보고 필요한 경우 맵 콘솔에서 수동으로 게시를 다시 시도할 수 있습니다.
게시 작업의 진행 상황을 모니터링하거나 추적할 수 있습니까?
예. Experience Manager Guides은 맵 콘솔의 사전 설정 탭에서 다음을 포함하여 실시간 작업 상태 업데이트를 제공합니다.
- 작업 시작 및 완료 시간
- 현재 단계(결과 압축, 발송, 게시 또는 업로드)
- 오류 알림(있는 경우)
이를 통해 작업 진행 상황을 이해하고 잠재적인 지연 시간을 파악할 수 있습니다.
Experience Manager Guides에서 게시 성능을 향상시킬 수 있는 모범 사례는 무엇입니까?
최적의 게시 속도를 보장하려면 다음 모범 사례를 따르십시오.
- 불필요한 대용량 이미지 파일 또는 참조되지 않은 주제 방지
- 게시의 범위를 제한하려면 기준선을 사용하십시오
- DITA 맵 계층을 관리 가능하고 체계적으로 유지
- 사용량이 적은 시간 동안 집중 게시 예약
- 조건부 필터를 효과적으로 사용하여 처리 로드 감소