Show Menu
화제×

하드웨어 크기 조정 지침

이러한 크기 조정 지침은 AEM 프로젝트를 배포하는 데 필요한 하드웨어 리소스를 대략적으로 제공합니다. 크기 평가는 프로젝트의 아키텍처, 솔루션의 복잡성, 예상 트래픽 및 프로젝트 요구 사항에 따라 다릅니다. 이 가이드는 특정 솔루션에 대한 하드웨어 요구 사항을 결정하거나 하드웨어 요구 사항에 대한 예상 상한과 하한을 찾는 데 도움이 됩니다.
고려해야 할 기본 요소는 다음과 같습니다(이 순서).
  • 네트워크 속도
    • 네트워크 지연
    • 사용 가능한 대역폭
  • 연산 속도
    • 효율적인 캐싱
    • 예상되는 트래픽
    • 템플릿, 애플리케이션 및 구성 요소의 복잡성
    • 동시 작성자
    • 작성 작업의 복잡성(간단한 컨텐츠 편집, MSM 롤아웃 등)
  • I/O 성능
    • 파일 또는 데이터베이스 스토리지의 성능 및 효율성
  • 하드 드라이브
    • 저장소 크기보다 최소 2 또는 3배 큼
  • 메모리
    • 웹 사이트 크기(컨텐츠 개체, 페이지 및 사용자 수)
    • 동시에 활성 상태인 사용자/세션 수

아키텍처

일반적인 AEM 설정은 작성자 및 게시 환경으로 구성됩니다. 이러한 환경에서는 기본 하드웨어 크기 및 시스템 구성과 관련하여 서로 다른 요구 사항이 있습니다. 두 환경에 대한 자세한 고려 사항은 작성 환경 게시 환경 섹션에 설명되어 있습니다.
일반적인 프로젝트 설정에서는 프로젝트 단계를 단계별로 처리할 여러 환경이 있습니다.
  • 개발 환경 ​새로운 기능을 개발하거나 중요한 변경을 수행하려면 개발자당 개발 환경(일반적으로 개인 시스템에 로컬 설치)을 사용하는 것이 좋습니다.
  • 테스트 환경 ​작성변경 사항을 확인합니다. 테스트 환경의 수는 프로젝트 요구 사항에 따라 달라질 수 있습니다(예: QA, 통합 테스트 또는 사용자 수락 테스트 별도).
  • 게시 테스트 환경 ​주로 소셜 공동 작업 사용 사례 및/또는 작성자 및 여러 게시 인스턴스 간의 상호 작용을 테스트하는 데 사용됩니다.
  • 제작 환경 ​작성자가 컨텐츠를 편집할 수 있습니다.
  • 제작 환경 ​게시된 컨텐츠를 제공하려면
또한 AEM 및 애플리케이션 서버를 실행하는 단일 서버 시스템부터 확장성이 뛰어난 다중 서버, 다중 CPU 클러스터 인스턴스 세트까지 환경이 달라질 수 있습니다. 각 프로덕션 시스템에 대해 별도의 컴퓨터를 사용하고 이러한 컴퓨터에서 다른 응용 프로그램을 실행하지 않는 것이 좋습니다.

일반적인 하드웨어 크기 조정 고려 사항

아래 섹션에서는 다양한 고려 사항을 고려하여 하드웨어 요구 사항을 계산하는 방법에 대한 지침을 제공합니다. 대규모 시스템의 경우 참조 구성에 대한 간단한 사내 벤치마크 테스트를 수행하는 것이 좋습니다.
성능 최적화는 특정 프로젝트에 대한 벤치마킹을 수행하기 전에 수행해야 하는 기본적인 작업입니다. 벤치마크 테스트를 수행하고 모든 하드웨어 크기 계산을 위해 결과를 사용하기 전에 성능 최적화 설명서에 제공된 조언을 반드시 적용하십시오.
고급 사용 사례를 위한 하드웨어 크기 조정 요구 사항은 프로젝트에 대한 자세한 성능 평가를 기반으로 해야 합니다. 탁월한 하드웨어 리소스를 필요로 하는 고급 사용 사례의 특징에는 다음과 같은 조합이 포함됩니다.
  • 높은 컨텐츠 페이로드 / 처리량
  • 사용자 정의 코드, 사용자 정의 워크플로우 또는 타사 소프트웨어 라이브러리를 광범위하게 사용
  • 지원되지 않는 외부 시스템 통합

디스크 공간/하드 드라이브

필요한 디스크 공간은 웹 애플리케이션의 볼륨 및 유형에 따라 크게 달라집니다. 계산은 다음 사항을 고려해야 합니다.
  • 페이지, 자산 및 워크플로우, 프로파일 등과 같은 다른 저장소 저장 엔티티의 양과 크기
  • 컨텐츠의 예상 빈도가 달라져서 컨텐츠 버전 생성
  • 생성할 DAM 자산 표현물의 볼륨
  • 시간의 경과에 따른 전체 컨텐츠 증가
디스크 공간은 온라인, 오프라인, 수정 기간 동안 지속적으로 모니터링됩니다. 사용 가능한 디스크 공간이 중요 값 아래로 떨어지면 프로세스가 취소됩니다. 중요한 값은 현재 저장소 디스크 공간의 25%이며 구성할 수 없습니다. 예상 증가를 포함하여 저장소 크기보다 최소 2~3배 큰 디스크 크기를 지정하는 것이 좋습니다.
데이터 중복을 위해 독립 디스크(예: RAID10)의 이중 어레이 설정을 고려합니다.
프로덕션 인스턴스의 임시 디렉토리에는 최소 6GB의 사용 가능한 공간이 있어야 합니다.

가상화

AEM은 가상화된 환경에서 잘 작동하지만 물리적 하드웨어와 직접 연결할 수 없는 CPU 또는 I/O 등의 요인이 있을 수 있습니다. 대부분의 경우 I/O 속도가 중요한 요소이므로 일반적으로 더 높은 I/O 속도를 선택하는 것이 좋습니다. 환경을 벤치마킹하여 어떤 리소스가 필요한지 정확하게 파악할 필요가 있습니다.

AEM 인스턴스 병렬화

실패 안전

장애 조치(fail-safe) 웹 사이트는 최소 두 개의 시스템에 배포됩니다. 한 시스템이 고장 나면 다른 시스템이 인계받아 시스템 오류를 해결할 수 있습니다.

시스템 리소스 확장성

모든 시스템이 실행되고 있는 동안 향상된 계산 성능을 사용할 수 있습니다. 관계가 기술 환경에 크게 종속되어 있으므로 추가적인 성능이 클러스터 노드의 수와 반드시 선형이 되지는 않습니다.자세한 내용은 클러스터 설명서를 참조하십시오.
필요한 클러스터 노드 수의 추정은 특정 웹 프로젝트의 기본 요구 사항 및 특정 사용 사례를 기반으로 합니다.
  • 실패 시 안전성의 관점에서 모든 환경에서 중요한 장애 발생 여부 및 클러스터 노드가 복구하는 데 걸리는 시간을 기준으로 장애 보상 시간을 결정해야 합니다.
  • 확장성 측면에서 볼 때 쓰기 작업의 수는 기본적으로 가장 중요한 요소입니다.작성자 환경에서 동시에 작업 및 게시 환경을 위한 소셜 협업을참조하십시오. 읽기 작업을 처리하기 위해서만 시스템에 액세스하는 작업에 대해 로드 밸런싱을 설정할 수 있습니다.자세한 내용은 디스패처를 참조하십시오.

작성 환경별 계산

Adobe는 벤치마킹 목적으로 독립 실행형 작성자 인스턴스에 대한 일부 벤치마크 테스트를 개발했습니다.
  • 벤치마크 테스트 1
    사용자가 기본 300개의 기존 페이지 로드 위에 간단한 페이지 만들기 연습을 수행하는 로드 프로필의 최대 처리량을 계산합니다. 모두 비슷한 특성을 갖습니다. 관련 단계는 사이트에 로그인하여 SWF 및 이미지/텍스트로 페이지를 만들고 태그 클라우드를 추가한 다음 페이지를 활성화하는 것이었습니다.
    • 결과
      상기(하나의 트랜잭션으로 간주됨)와 같은 간단한 페이지 작성 실행에 대한 최대 처리량이 시간당 1730 트랜잭션으로 발견되었습니다.
  • 벤치마크 테스트 2
    로드 프로필에 새로운 페이지 작성(10%), 기존 페이지 수정(80%), 생성 및 페이지 수정(10%)이 혼합되어 있을 때 최대 처리량을 계산합니다. 페이지의 복잡성은 벤치마크 테스트 1의 프로필과 동일하게 유지됩니다. 페이지의 기본적인 수정 작업은 이미지를 추가하고 텍스트 컨텐츠를 수정하여 수행됩니다. 벤치마크 테스트 1에서 정의된 것과 동일한 복잡도의 300페이지의 기본 로드 위에 연습을 수행했습니다.
    • 결과
      Maximum throughput for such a mix operation scenario was found to be 3252 transactions per hour.
처리량은 로드 프로필 내에서 트랜잭션 유형을 구분하지 않습니다. 처리량을 측정하는 데 사용되는 접근 방식은 각 트랜잭션 유형의 고정 비율이 작업 로드에 포함됩니다.
위의 두 테스트는 처리량이 작업 유형에 따라 달라진다는 것을 분명히 강조 표시합니다. 사용자 환경의 활동을 시스템 크기 조정을 위한 기초로 사용합니다. You will get better throughput with less intensive actions such as modify (which also common).

캐싱

작성 환경에서는 일반적으로 웹 사이트 변경 내용이 빈번하고 컨텐츠가 인터랙티브하고 개인화되므로 캐싱 효율성이 훨씬 낮습니다. 디스패처를 사용하여 AEM 라이브러리, JavaScripts, CSS 파일 및 레이아웃 이미지를 캐시할 수 있습니다. 이렇게 하면 제작 프로세스의 일부 측면을 가속화할 수 있습니다. 이러한 리소스에서 브라우저 캐싱에 대한 헤더를 추가로 설정하도록 웹 서버를 구성하면 HTTP 요청 수가 줄어들고 작성자가 경험한 대로 시스템 응답성이 향상됩니다.

동시에 작업 중인 작성자

작성 환경에서는 병렬로 작업하는 작성자 수와 상호 작용이 시스템에 추가하는 로드가 주요 제한 요소입니다. 따라서 데이터의 공유 처리량에 따라 시스템을 확장할 것을 권장합니다.
이러한 시나리오의 경우 Adobe는 작성자 인스턴스의 두 노드 공유 없음 클러스터에 대한 벤치마크 테스트를 실행했습니다.
  • 벤치마크 테스트 1a
    활성-활성 공유-없음 클러스터로 구성된 2개의 작성자 인스턴스를 사용하면 사용자가 기본 300개의 기존 페이지 로드 위에 간단한 페이지 만들기 연습을 수행하는 로드 프로필로 최대 처리량을 계산할 수 있습니다. 이 모든 것은 이와 유사합니다.
    • 결과
      상기와 같은 간단한 페이지 작성 연습을 위한 최대 처리량은 2016 트랜잭션/시간이라고 합니다. 이는 동일한 벤치마크 테스트에 대한 독립 실행형 작성자 인스턴스와 비교할 때 약 16%의 증가입니다.
  • 벤치마크 테스트 2b
    2개의 작성자 인스턴스의 활성-활성 공유-없음 클러스터로 구성된 경우, 로드 프로필에 새로운 페이지 생성(10%), 기존 페이지 수정(80%), 연속적으로 페이지 생성 및 수정(10%)이 혼합되어 있을 때 최대 처리량을 계산합니다. 페이지의 복잡성은 벤치마크 테스트 1의 프로필과 동일하게 유지됩니다. 페이지의 기본적인 수정 작업은 이미지를 추가하고 텍스트 컨텐츠를 수정하여 수행됩니다. 다시, 이 연습은 벤치마크 테스트 1에 정의된 것과 동일한 300페이지의 복잡성의 기본 로드 위에 수행되었습니다.
    • 결과
      Maximum throughput for such a mixed operation scenario was found to be 628 transactions/hour. 이는 동일한 벤치마크 테스트에 대한 독립 실행형 작성자 인스턴스와 비교할 때 약 93%의 증가입니다.
처리량은 로드 프로필 내에서 트랜잭션 유형을 구분하지 않습니다. 처리량을 측정하는 데 사용되는 접근 방식은 각 트랜잭션 유형의 고정 비율이 작업 로드에 포함됩니다.
위의 두 테스트는 AEM을 사용하여 기본 편집 작업을 수행하는 작성자에게 AEM의 크기가 잘 조절된다는 것을 분명히 강조 표시합니다. 일반적으로 AEM은 읽기 작업의 크기를 조정하는 데 가장 효과적입니다.
일반적인 웹 사이트에서 대부분의 저작 작업은 프로젝트 단계에서 이루어집니다. 웹 사이트가 라이브되면 평행한 작성자 수가 보통 낮은(작동 모드) 평균으로 줄어듭니다.
작성 환경에 필요한 컴퓨터(또는 CPU)의 수는 다음과 같이 계산할 수 있습니다.
n = numberOfParallelAuthors / 30
작성자가 AEM에서 기본 작업을 수행할 때 이 공식은 CPU 크기 조정을 위한 일반적인 지침 역할을 할 수 있습니다. 이 프로세스에서는 시스템과 애플리케이션이 최적화되었다고 가정합니다. 그러나 MSM 또는 자산과 같은 고급 기능에 대해서는 공식이 true가 아닙니다(아래 섹션 참조).
또한 병렬화 및 성능 최적화에 대한 추가 의견을 참조하십시오 .

하드웨어 권장 사항

일반적으로 게시 환경에 권장되는 것과 동일한 하드웨어를 작성 환경에 사용할 수 있습니다. 일반적으로 웹 사이트 트래픽은 저작 시스템에서 훨씬 낮지만 캐시 효율도 낮습니다. 그러나 여기에서 기본적인 요인은 시스템에 수행되는 작업 유형과 함께 병렬로 작업하는 작성자 수입니다. 일반적인 AEM 클러스터링(작성 환경)은 읽기 작업 크기 조정에 가장 효과적입니다.즉, AEM 클러스터는 기본 편집 작업을 수행하는 작성자와 잘 크기가 조절됩니다.
Adobe의 벤치마크 테스트는 Hewlett-Packard ProLiant DL380 G5 하드웨어 플랫폼에서 실행되는 RedHat 5.5 운영 체제를 사용하여 수행되었으며 다음 구성이 제공됩니다.
  • 3.00GHz의 쿼드 코어 Intel Xeon X5450 CPU 2개
  • 8GB RAM
  • Broadcom NetXtreme II BCM5708 기가비트 이더넷
  • HP 스마트 어레이 RAID 컨트롤러, 256MB 캐시
  • RAID0 스트라이프 세트로 구성된 146GB 10,000RPM SAS 디스크 2개
  • SPEC CINT2006 Rate 벤치마크 점수는 110입니다.
AEM 인스턴스가 최소 더미 크기 256M, 최대 더미 크기 1024M으로 실행 중입니다.

게시 환경별 계산

효율적인 캐싱 및 트래픽

캐시 효율성은 웹 사이트 속도에 매우 중요합니다. 다음 표는 최적화된 AEM 시스템에서 디스패처와 같은 역방향 프록시를 사용하여 처리할 수 있는 초당 페이지 수를 보여줍니다.
캐시 비율
페이지/초(최고)
백만 페이지/일(평균)
100%
1000-2000
35-70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
부인:번호는 기본 하드웨어 구성을 기반으로 하며 사용된 특정 하드웨어에 따라 달라질 수 있습니다.
캐시 비율은 AEM에 액세스하지 않고도 디스패처가 반환할 수 있는 페이지의 비율입니다. 100%는 디스패처가 모든 요청에 응답함을 나타내고, 0%는 AEM이 모든 단일 페이지를 계산함을 의미합니다.

템플릿 및 애플리케이션의 복잡성

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

공식

다음 공식을 사용하여 AEM 솔루션의 전체 복잡성에 대한 견적을 계산할 수 있습니다.
complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)
복잡성을 기반으로 게시 환경에 필요한 서버(또는 CPU 코어)의 수를 다음과 같이 결정할 수 있습니다.
n = (traffic * complexity / 1000 ) * activations
방정식의 변수는 다음과 같습니다.
트래픽 예상되는 초당 최대 트래픽입니다. 일일 페이지 히트 수로 35-000으로 나눌 수 있습니다.
applicationComplex
간단한 응용 프로그램에는 1을, 복잡한 응용 프로그램에는 2를 사용하거나 중간 값을 사용합니다.
  • 1 - 완전히 익명으로 컨텐츠 중심의 사이트
  • 1.1 - 완전히 익명의 컨텐츠 중심의 클라이언트 측/타겟 개인화 사이트
  • 1.5 - 익명의 섹션과 로그인 섹션이 모두 포함된 컨텐츠 중심의 사이트, 클라이언트측/타겟 개인화
  • 1.7 - 익명의 섹션과 로그인 섹션이 모두 포함된 컨텐츠 중심의 사이트, 클라이언트측/타겟 개인화 및 일부 사용자 생성 컨텐츠
  • 2 - 사용자 생성 컨텐츠와 다양한 개인화 기법을 광범위하게 사용하여 전체 사이트에 로그인해야 하는 경우
cacheRatio 디스패처 캐시에서 나온 페이지의 비율입니다. 모든 페이지가 캐시에서 가져온 경우 1을 사용하고, 모든 페이지가 AEM에 의해 계산되는 경우에는 0을 사용합니다.
templateComplex 1~10 사이의 값을 사용하여 템플릿의 복잡성을 나타냅니다. 숫자가 클수록 페이지당 평균 10개의 구성 요소가 있는 사이트에 대해 값 1을 사용하고, 페이지 평균 40개의 구성 요소에 대해 값 5를 사용하고, 평균 100개 이상의 구성 요소에 대해 10을 사용하여 보다 복잡한 템플릿을 나타냅니다.
활성화 시간당 평균 활성화 수(작성자에서 게시 계층으로 된 평균 크기의 페이지 및 자산 복제)를 x로 나눈 값입니다. x는 시스템에서 처리된 다른 작업에 대한 성능 부작용없이 시스템에서 수행한 활동 수입니다. x = 100과 같은 비관적인 초기 값을 미리 정의할 수도 있습니다.
보다 복잡한 웹 사이트가 있는 경우 AEM이 적절한 시간에 요청에 응답할 수 있도록 보다 강력한 웹 서버가 필요합니다.
  • 복잡성 4:
    • 1024MB JVM RAM*
    • 낮은-중간 성능 CPU
  • 4~8 간의 복잡성:
    • 2048MB JVM RAM*
    • 중간 및 고성능 CPU
  • 8 이상의 복잡성
    • 4096MB JVM RAM*
    • 고성능 CPU
*JVM에 필요한 메모리 외에 운영 체제에 사용할 충분한 RAM을 보유합니다.

추가 사용 사례별 계산

기본 웹 응용 프로그램에 대한 계산 외에 다음 사용 사례에 대한 특정 요소를 고려해야 할 수도 있습니다. 계산된 값은 기본 계산에 추가됩니다.

자산별 고려 사항

디지털 에셋의 광범위한 처리에는 최적화된 하드웨어 리소스가 필요하며, 가장 연관성 있는 요소는 이미지 크기와 처리된 이미지의 최고 처리량입니다.
최소 16GB 힙을 할당하고 Raw 이미지 인제스트를 위해 Camera Raw 패키지를 사용하도록 DAM 자산 업데이트 워크플로우를 구성합니다.
A higher throughput of images means that the computing resources need to keep pace with system I/O and or other versa. 예를 들어 이미지 가져오기로 워크플로우를 실행하는 경우 WebDAV를 통해 많은 이미지를 업로드하면 작업 과정 백로그가 발생할 수 있습니다.
TarPM, 데이터 저장소 및 검색 색인에 대해 별도의 디스크를 사용하면 시스템 I/O 동작을 최적화할 수 있습니다(하지만 일반적으로 검색 색인을 로컬에 유지하는 것이 적절합니다).

다중 사이트 관리자

제작 환경에서 AEM MSM을 사용할 때의 리소스 소비는 특정 사용 사례에 따라 크게 달라집니다. 기본 요인은 다음과 같습니다.
  • Live-Copy 수
  • 롤아웃의 주기성
  • 롤아웃할 컨텐츠 트리 크기
  • 롤아웃 작업의 연결된 기능
대표적인 컨텐츠 인용으로 계획된 사용 사례를 테스트하면 리소스 소비에 대한 이해를 향상시키는 데 도움이 될 수 있습니다. 계획된 처리량을 사용하여 결과를 추정하는 경우 AEM MSM에 필요한 추가 리소스를 평가할 수 있습니다.
AEM MSM 사용 사례에서 계획된 것보다 더 많은 리소스를 사용하는 경우 동시에 작업하는 작성자가 성능 부작용에 대해 인지합니다.

AEM Communities 크기 조정 고려 사항

AEM Communities 기능(커뮤니티 사이트)을 포함하는 AEM 사이트는 게시 환경의 사이트 방문자(구성원)와 높은 수준의 상호 작용을 경험합니다.
커뮤니티 사이트에 대한 크기 조정 고려 사항은 커뮤니티 구성원의 예상 상호 작용과 페이지 컨텐츠에 대한 최적의 성능이 더 중요한지 여부에 따라 다릅니다.
UGC(사용자 생성 콘텐츠) 제출 멤버는 페이지 컨텐츠와 별도로 저장됩니다. AEM 플랫폼에서는 작성자에서 게시로 사이트 컨텐츠를 복제하는 노드 저장소를 사용하지만 AEM Communities는 복제되지 않는 UGC에 대해 단일 공용 저장소를 사용합니다.
UGC 스토어의 경우 선택한 배포에 영향을 주는 SRP(Storage Resource Provider)를 선택해야 합니다. 자세한 내용은