하드웨어 크기 조정 지침 hardware-sizing-guidelines

이러한 크기 조정 지침은 AEM 프로젝트를 배포하는 데 필요한 하드웨어 리소스에 대한 대략적인 정보를 제공합니다. 예상 크기는 프로젝트의 아키텍처, 솔루션의 복잡성, 예상 트래픽 및 프로젝트 요구 사항에 따라 다릅니다. 이 안내서는 특정 솔루션에 대한 하드웨어 요구 사항을 확인하거나 하드웨어 요구 사항에 대한 상위 및 하위 예상 값을 찾는 데 도움이 됩니다.

고려해야 할 기본 요소는 (이 순서로) 다음과 같습니다.

  • 네트워크 속도

    • 네트워크 지연
    • 사용 가능한 대역폭
  • 연산 속도

    • 캐싱 효율성
    • 예상 트래픽
    • 템플릿, 애플리케이션 및 구성 요소의 복잡성
    • 동시 작성자
    • 작성 작업의 복잡성(간단한 콘텐츠 편집, MSM 롤아웃 등)
  • 입출력 성능

    • 파일 또는 데이터베이스 스토리지의 성능 및 효율성
  • 하드 드라이브

    • 저장소 크기보다 최소 2배 또는 3배 큼
  • 메모리

    • 웹 사이트 크기(content-object, page 및 사용자 수)
    • 동시에 활성화된 사용자/세션 수

아키텍처 architecture

일반적인 AEM 설정은 작성자와 게시 환경으로 구성됩니다. 이러한 환경은 기본 하드웨어 크기 및 시스템 구성과 관련하여 서로 다른 요구 사항을 가지고 있습니다. 두 환경에 대한 자세한 고려 사항은 작성 환경게시 환경 섹션.

일반적인 프로젝트 설정에서는 프로젝트 단계를 스테이징할 수 있는 몇 가지 환경이 있습니다.

  • 개발 환경
    새로운 기능을 개발하거나 중요한 변경 작업을 수행하기 위해 가장 좋은 방법은 개발자별 개발 환경(개인 시스템에 로컬 설치)을 사용하여 작업하는 것입니다.

  • 작성자 테스트 환경
    변경 내용을 확인하려면 테스트 환경의 수는 프로젝트 요구 사항에 따라 달라질 수 있습니다(예: QA, 통합 테스트 또는 사용자 승인 테스트의 경우 각각 다름).

  • 테스트 환경 게시
    주로 소셜 공동 작업 사용 사례 및/또는 작성자와 여러 게시 인스턴스 간의 상호 작용을 테스트하기 위한 것입니다.

  • 작성자 프로덕션 환경
    작성자가 컨텐츠를 편집할 수 있습니다.

  • 프로덕션 환경 게시
    게시된 콘텐츠를 제공합니다.

또한 AEM 및 애플리케이션 서버를 실행하는 단일 서버 시스템에서 확장성이 높은 다중 서버, 다중 CPU 클러스터 인스턴스 세트에 이르기까지 환경이 달라질 수 있습니다. Adobe은 각 프로덕션 시스템에 대해 별도의 컴퓨터를 사용하고 이러한 컴퓨터에서 다른 응용 프로그램을 실행하지 말 것을 권장합니다.

일반적인 하드웨어 크기 조정 고려 사항 generic-hardware-sizing-considerations

아래 섹션에서는 다양한 고려 사항을 고려하여 하드웨어 요구 사항을 계산하는 방법에 대한 지침을 제공합니다. 대규모 시스템의 경우, Adobe은 참조 구성에 대해 간단한 사내 벤치마크 테스트를 수행할 것을 제안합니다.

성능 최적화는 특정 프로젝트에 대한 벤치마킹을 수행하기 전에 수행해야 하는 기본적인 작업입니다. 에 제공된 조언을 적용하십시오. 성능 최적화 설명서 벤치마크 테스트를 수행하고 그 결과를 사용하여 하드웨어 크기 조정 계산을 수행하기 전에

고급 사용 사례에 대한 하드웨어 크기 조정 요구 사항은 프로젝트에 대한 자세한 성능 평가를 기반으로 해야 합니다. 뛰어난 하드웨어 리소스를 필요로 하는 고급 사용 사례의 특징은 다음과 같습니다.

  • 높은 컨텐츠 페이로드/처리량
  • 사용자 지정된 코드, 사용자 지정 워크플로우 또는 서드파티 소프트웨어 라이브러리의 광범위한 사용
  • 지원되지 않는 외부 시스템과의 통합

디스크 공간/하드 드라이브 disk-space-hard-drive

필요한 디스크 공간은 웹 애플리케이션의 볼륨과 유형에 따라 크게 달라집니다. 계산은 다음을 고려해야 합니다.

  • 페이지, 에셋 및 워크플로우, 프로필 등과 같은 기타 저장소 저장 엔티티의 수량 및 크기입니다.
  • 콘텐츠 변경 횟수와 콘텐츠 버전 작성 예상 빈도
  • 생성될 DAM 에셋 렌디션의 볼륨
  • 시간에 따른 전반적인 컨텐츠 증가

온라인 및 오프라인, 개정 정리 시 디스크 공간이 계속 모니터링됩니다. 사용 가능한 디스크 공간이 위험 값 미만으로 떨어지면 프로세스가 취소됩니다. 임계값은 저장소의 현재 디스크 풋프린트의 25%이며 구성할 수 없습니다. Adobe은 예상 증가량을 포함하는 저장소 크기보다 최소 2~3배 더 큰 디스크 크기를 조정할 것을 권장합니다.

데이터 중복을 위해 독립 디스크의 중복 어레이(RAID, 예: RAID10)를 설정하는 것이 좋습니다.

NOTE
프로덕션 인스턴스의 임시 디렉터리에는 최소 6GB의 사용 가능한 공간이 있어야 합니다.

가상화 virtualization

AEM은 가상화 환경에서 잘 실행되지만 CPU 또는 I/O와 같이 물리적 하드웨어와 직접 비교할 수 없는 요소가 있을 수 있습니다. 일반적으로 입출력 속도가 매우 중요한 요소이므로 일반적으로 더 높은 입출력 속도를 선택하는 것이 좋습니다. 필요한 리소스를 정확하게 파악하려면 환경을 벤치마킹해야 합니다.

AEM 인스턴스의 병렬 처리 parallelization-of-aem-instances

안전 실패

오류 방지 웹 사이트는 두 개 이상의 별도 시스템에 배포됩니다. 한 시스템이 고장나면 다른 시스템이 시스템을 인수하여 시스템 고장을 보완할 수 있습니다.

시스템 리소스 확장성

모든 시스템이 실행되는 동안 향상된 컴퓨팅 성능을 사용할 수 있습니다. 이 관계는 기술 환경에 크게 의존하기 때문에 추가 성능이 클러스터 노드 수와 반드시 일치하는 것은 아닙니다. 다음을 참조하십시오 클러스터 설명서 추가 정보.

필요한 클러스터 노드의 수는 특정 웹 프로젝트의 기본 요구 사항과 특정 사용 사례를 기반으로 계산됩니다.

  • 장애 안전성의 관점에서, 모든 환경에서 클러스터 노드가 복구되는 데 걸리는 시간을 기반으로 심각한 장애와 장애 보상 시간을 결정해야 합니다.
  • 확장성의 측면에서 볼 때 기본적으로 쓰기 작업의 수가 가장 중요한 요소입니다. 동시 작업 작성자 작성 환경 및 소셜 공동 작업 게시 환경용입니다. 로드 밸런싱은 읽기 작업만 처리하기 위해 시스템에 액세스하는 작업에 대해 설정할 수 있습니다. 다음을 참조하십시오. 디스패처 을 참조하십시오.

작성자 환경별 계산 author-environment-specific-calculations

벤치마킹 목적으로 Adobe은 독립형 작성자 인스턴스에 대한 몇 가지 벤치마크 테스트를 개발했습니다.

  • 벤치마크 테스트 1
    사용자가 300개의 기존 페이지를 기본 로드하고 유사한 성격의 페이지에서 간단한 페이지 만들기 연습을 수행하는 로드 프로필의 최대 처리량을 계산합니다. 관련 단계는 사이트에 로그인하고, SWF과 이미지/텍스트로 페이지를 만들고, 태그 클라우드를 추가한 다음 페이지를 활성화하는 것입니다.

    • 결과
      위와 같은 간단한 페이지 생성 작업을 위한 최대 처리량(하나의 트랜잭션으로 간주됨)은 시간당 1,730 트랜잭션입니다.
  • 벤치마크 테스트 2
    로드 프로필에 새 페이지 생성(10%), 기존 페이지 수정(80%) 및 연속으로 페이지 생성 후 수정(10%)이 혼합된 경우 최대 처리량을 계산합니다. 페이지의 복잡성은 벤치마크 테스트 1의 프로필에서와 동일하게 유지됩니다. 페이지의 기본 수정은 이미지를 추가하고 텍스트 콘텐츠를 수정하여 수행됩니다. 이 연습은 벤치마크 테스트 1에서 정의된 것과 동일한 복잡성의 300페이지의 기본 로드 위에서 수행되었습니다.

    • 결과
      이러한 혼합 작업 시나리오의 최대 처리량은 시간당 3252개의 트랜잭션으로 확인되었습니다.
NOTE
처리량 속도는 로드 프로필 내의 트랜잭션 유형을 구분하지 않습니다. 처리량을 측정하는 데 사용되는 접근 방식은 각 트랜잭션 유형의 고정 비율이 작업 로드에 포함되도록 합니다.

위의 두 테스트는 작업 유형에 따라 처리량이 다르다는 것을 명확하게 강조합니다. 시스템 크기 조정을 위한 기반으로 사용 중인 환경의 활동을 사용하십시오. 수정과 같은 덜 집중적인 작업으로 처리량이 향상됩니다(일반적으로 더 많음).

캐싱 caching

작성 환경에서는 웹 사이트를 변경하는 경우가 더 많고 콘텐츠의 대화형 및 개인화가 향상되므로 일반적으로 캐싱 효율성이 훨씬 낮습니다. Dispatcher를 사용하여 AEM 라이브러리, JavaScript, CSS 파일 및 레이아웃 이미지를 캐시할 수 있습니다. 이렇게 하면 작성 프로세스의 일부 측면이 빨라집니다. 이러한 리소스에 대한 브라우저 캐싱을 위한 헤더도 설정하도록 웹 서버를 구성하면 HTTP 요청 수가 감소하므로 작성자가 경험한 대로 시스템 응답성이 향상됩니다.

동시 작업 작성자 authors-working-in-parallel

작성 환경에서는 동시에 작동하는 작성자 수와 상호 작용이 시스템에 추가되는 로드가 주요 제한 요소입니다. 따라서 Adobe은 데이터의 공유 처리량을 기반으로 시스템의 크기를 조정할 것을 권장합니다.

이러한 시나리오의 경우, Adobe은 작성자 인스턴스의 2노드 공유 없음 클러스터에서 벤치마크 테스트를 실행했습니다.

  • 벤치마크 테스트 1a
    2개의 작성자 인스턴스로 구성된 활성-활성 공유 없음 클러스터를 사용하여 사용자가 300개의 기존 페이지(모든 유사한 특성)를 기본 로드로 하여 간단한 페이지 만들기 연습을 수행하는 로드 프로필을 사용하여 최대 처리량을 계산합니다.

    • 결과
      위와 같은 간단한 페이지 생성 작업을 위한 최대 처리량(하나의 트랜잭션으로 간주됨)은 2016 트랜잭션/시간으로 나타났습니다. 동일한 벤치마크 테스트에 대한 독립 실행형 작성자 인스턴스와 비교하여 약 16% 증가된 것입니다.
  • 벤치마크 테스트 2b
    2개의 작성자 인스턴스로 구성된 활성-활성 공유 없음 클러스터를 사용하여 로드 프로필에 새 페이지 작성(10%), 기존 페이지 수정(80%) 및 연속하여 페이지 작성 및 수정(10%)이 혼합된 경우 최대 처리량을 계산합니다. 페이지의 복잡성은 벤치마크 테스트 1의 프로필에서와 동일하게 유지됩니다. 페이지의 기본 수정은 이미지를 추가하고 텍스트 콘텐츠를 수정하여 수행됩니다. 이 연습은 벤치마크 테스트 1에서 정의된 것과 동일한 300페이지의 복잡성 기본 부하 위에 수행되었습니다.

    • 결과
      이러한 혼합 작업 시나리오의 최대 처리량은 6,288개의 트랜잭션/시간으로 확인되었다. 동일한 벤치마크 테스트에 대한 독립형 작성자 인스턴스와 비교할 때 약 93%가 증가한 것입니다.
NOTE
처리량 속도는 로드 프로필 내의 트랜잭션 유형을 구분하지 않습니다. 처리량을 측정하는 데 사용되는 접근 방식은 각 트랜잭션 유형의 고정 비율이 작업 로드에 포함되도록 합니다.

위의 두 테스트는 AEM에서 기본 편집 작업을 수행하는 작성자에게 AEM이 잘 조절된다는 것을 분명히 보여 줍니다. 일반적으로 AEM은 읽기 작업의 크기를 조정하는 데 가장 효과적입니다.

일반적인 웹 사이트에서는 프로젝트 단계 중에 대부분의 작성이 수행됩니다. 웹 사이트가 실행되면 병렬로 작업하는 작성자의 수는 일반적으로 더 낮은(운영 모드) 평균으로 줄어듭니다.

다음과 같이 작성 환경에 필요한 컴퓨터(또는 CPU) 수를 계산할 수 있습니다.

n = numberOfParallelAuthors / 30

이 공식은 작성자가 AEM으로 기본 작업을 수행할 때 CPU 크기를 조정하는 일반적인 지침으로 사용할 수 있습니다. 시스템과 애플리케이션이 최적화되어 있다고 가정합니다. 그러나 공식은 MSM 또는 에셋과 같은 고급 기능에 대해서는 적용되지 않습니다(아래 섹션 참조).

추가 정보 평행화성능 최적화.

하드웨어 Recommendations hardware-recommendations

일반적으로 게시 환경에 권장되는 것과 동일한 하드웨어를 작성자 환경에 사용할 수 있습니다. 일반적으로 웹 사이트 트래픽은 작성 시스템에서 더 낮지만 캐시 효율성도 더 낮습니다. 그러나 여기서 근본적인 요소는 시스템에 대해 수행되는 작업의 유형과 함께 동시에 작업하는 작성자의 수입니다. 일반적으로 (작성자 환경의) AEM 클러스터링은 읽기 작업의 크기를 조절하는 데 가장 효과적입니다. 즉, AEM 클러스터는 기본 편집 작업을 수행하는 작성자와 함께 크기가 잘 조절됩니다.

Adobe 시 벤치마크 테스트는 Hewlett-Packard ProLiant DL380 G5 하드웨어 플랫폼에서 실행되는 Red Hat® 5.5 운영 체제를 사용하여 수행되었으며, 다음과 같은 구성이 적용되었습니다.

  • 쿼드 코어 Intel Xeon® X5450 CPU 2개(3.00GHz)
  • 8GB RAM
  • Broadcom NetXtreme II BCM5708 기가비트 이더넷
  • HP Smart Array RAID 컨트롤러, 256MB 캐시
  • RAID0 스트라이프 세트로 구성된 146GB 10,000RPM SAS 디스크 2개
  • SPEC CINT2006 속도 벤치마크 점수는 110입니다.

AEM 인스턴스는 최소 힙 크기가 256M이고 최대 힙 크기가 1024M인 상태로 실행되고 있었습니다.

환경별 계산 게시 publish-environment-specific-calculations

캐싱 효율성 및 트래픽 caching-efficiency-and-traffic

캐시 효율성은 웹 사이트 속도에 매우 중요합니다. 다음 표는 최적화된 AEM 시스템이 Dispatcher와 같은 역방향 프록시를 사용하여 처리할 수 있는 초당 페이지 수를 보여 줍니다.

캐시 비율
페이지/초(최대)
백만 페이지/일(평균)
100%
1000-2000
35-70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
CAUTION
면책조항: 이 수치는 기본 하드웨어 구성을 기반으로 하며 사용되는 특정 하드웨어에 따라 달라질 수 있습니다.

캐시 비율은 Dispatcher가 AEM에 액세스하지 않고도 반환할 수 있는 페이지의 백분율입니다. 100%는 Dispatcher가 모든 요청에 응답함을 나타내고 0%는 AEM이 모든 페이지를 계산함을 의미합니다.

템플릿 및 애플리케이션의 복잡성 complexity-of-templates-and-applications

복잡한 템플릿을 사용하는 경우 AEM에서 페이지를 렌더링하는 데 더 많은 시간이 필요합니다. 캐시에서 가져온 페이지는 이에 의해 영향을 받지 않지만 전체 응답 시간을 고려할 때 페이지 크기는 여전히 적절합니다. 복잡한 페이지를 렌더링하는 것은 간단한 페이지를 렌더링하는 것보다 10배 더 오래 걸릴 수 있습니다.

공식 formula

다음 공식을 사용하여 AEM 솔루션의 전반적인 복잡성에 대한 예상치를 계산할 수 있습니다.

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

복잡성을 기반으로 다음과 같이 게시 환경에 필요한 서버(또는 CPU 코어) 수를 결정할 수 있습니다.

n = (traffic * complexity / 1000 ) * activations

방정식의 변수는 다음과 같습니다.

트래픽
초당 예상되는 최대 트래픽 수입니다. 일별 페이지 조회수를 35,000으로 나눈 값으로 예상할 수 있습니다.
applicationComplexity

단순 응용 프로그램에는 1, 복잡한 응용 프로그램에는 2 또는 그 사이의 값을 사용합니다.

  • 1 - 완전히 익명의 콘텐츠 지향 사이트
  • 1.1 - 클라이언트측/Target 개인화를 사용하는 완전 익명 콘텐츠 지향 사이트
  • 1.5 - 익명 섹션과 로그인 섹션이 모두 있는 콘텐츠 중심 사이트, 클라이언트측/Target 개인화
  • 1.7 - 익명 섹션과 로그인 섹션이 모두 있는 콘텐츠 지향 사이트, 클라이언트측/Target 개인화 및 일부 사용자 생성 콘텐츠의 경우
  • 2 - 사용자 생성 콘텐츠의 광범위한 사용 및 다양한 개인화 기술을 통해 전체 사이트에 로그인해야 하는 경우
cacheRatio
Dispatcher 캐시에서 나오는 페이지의 백분율입니다. 모든 페이지가 캐시에서 온 경우 1, 모든 페이지가 AEM에서 계산된 경우 0을 사용합니다.
templateComplexity
1에서 10 사이의 값을 사용하여 템플릿의 복잡성을 나타냅니다. 숫자가 높을수록 페이지당 평균 10개의 구성 요소가 있는 사이트의 경우 값 1, 페이지 평균 40개의 구성 요소가 있는 페이지의 경우 값 5, 평균 100개가 넘는 구성 요소가 있는 사이트의 경우 값 1 을 사용하여 더 복잡한 템플릿을 나타냅니다.
활성화
시간당 평균 활성화(작성자의 평균 크기 페이지 및 에셋을 게시 계층으로 복제)의 수를 x로 나눈 값입니다. 여기서 x는 시스템에서 처리한 다른 작업에 대해 성능 부작용이 없는 시스템에서 수행된 활성화의 수입니다. x = 100과 같은 비관적 초기 값을 미리 정의할 수도 있습니다.

보다 복잡한 웹 사이트가 있는 경우 AEM이 적절한 시간에 요청에 응답할 수 있도록 보다 강력한 웹 서버도 필요합니다.

  • 복잡성 4 미만:

    • 1024MB JVM RAM*
    • 저성능 CPU ~ 중간 성능 CPU
  • 4~8의 복잡성:

    • 2048MB JVM RAM*
    • 중고성능 CPU
  • 복잡성 8 이상:

    • 4096MB JVM RAM*
    • 고성능 CPU에서 고성능
NOTE
* JVM에 필요한 메모리 외에 운영 체제에 필요한 충분한 RAM을 예약합니다.

추가적인 사용 사례별 계산 additional-use-case-specific-calculations

기본 웹 응용 프로그램에 대한 계산 외에 다음 사용 사례에 대한 특정 요소를 고려하십시오. 계산된 값이 기본 계산에 추가됩니다.

에셋별 고려 사항 assets-specific-considerations

디지털 에셋을 광범위하게 처리하려면 최적화된 하드웨어 리소스가 필요하며, 가장 관련성이 높은 요소는 이미지 크기와 처리된 이미지의 최대 처리량입니다.

16GB 이상의 힙 할당 및 구성 DAM 자산 업데이트 사용할 워크플로 Camera Raw 패키지 원시 이미지 수집용

NOTE
이미지 처리량이 높으면 컴퓨팅 리소스는 시스템 I/O와 보조를 맞출 수 있어야 합니다. 예를 들어 이미지를 가져와 워크플로우를 시작하는 경우 WebDAV를 통해 많은 이미지를 업로드하면 워크플로우가 백로그될 수 있습니다.
TarPM, 데이터 저장소 및 검색 색인에 대해 별도의 디스크를 사용하면 시스템 I/O 동작을 최적화하는 데 도움이 될 수 있습니다(하지만 일반적으로 검색 색인을 로컬로 유지하는 것이 좋습니다).
NOTE
다음 항목도 참조하십시오. Assets 성능 안내서.

다중 사이트 관리자 multi-site-manager

작성 환경에서 AEM MSM을 사용할 때 리소스 사용량은 특정 사용 사례에 따라 크게 달라집니다. 기본 요인은 다음과 같습니다.

  • 라이브 카피 수
  • 롤아웃 주기
  • 롤아웃할 콘텐츠 트리 크기
  • 롤아웃 작업의 연결된 기능

대표적인 콘텐츠 발췌본을 사용하여 계획된 사용 사례를 테스트하면 리소스 사용에 대한 이해를 높이는 데 도움이 될 수 있습니다. 계획된 처리량으로 결과를 추정하는 경우 AEM MSM에 필요한 추가 리소스를 평가할 수 있습니다.

또한 동시에 작업하는 작성자를 설명합니다. AEM MSM 사용 사례가 계획보다 더 많은 리소스를 소비하는 경우 성능 부작용을 인식하게 됩니다.

AEM Communities 크기 조정 고려 사항 aem-communities-sizing-considerations

AEM Communities 기능(커뮤니티 사이트)이 포함된 AEM 사이트에서는 게시 환경의 사이트 방문자(구성원)로부터 높은 수준의 상호 작용을 경험합니다.

커뮤니티 사이트에 대한 크기 조정 고려 사항은 커뮤니티 구성원의 예상 상호 작용과 페이지 콘텐츠에 대한 최적의 성능이 더 중요한지 여부에 따라 다릅니다.

UGC(사용자 생성 컨텐츠) 제출 멤버는 페이지 컨텐츠와 별도로 저장됩니다. AEM 플랫폼에서는 작성자에서 게시로 사이트 콘텐츠를 복제하는 노드 저장소를 사용하는 반면, AEM Communities에서는 복제되지 않는 UGC에 대한 단일 공통 저장소를 사용합니다.

UGC 스토어의 경우 선택한 배포에 영향을 주는 SRP(저장소 리소스 제공자)를 선택해야 합니다.
자세한 내용은

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2