하드웨어 크기 조정 지침 hardware-sizing-guidelines
이러한 크기 조정 지침은 AEM 프로젝트를 배포하는 데 필요한 하드웨어 리소스를 대략적으로 설명합니다. 크기 예상 은 프로젝트의 아키텍처, 솔루션의 복잡성, 예상 트래픽 및 프로젝트 요구 사항에 따라 다릅니다. 이 가이드는 특정 솔루션에 대한 하드웨어 요구 사항을 확인하거나 하드웨어 요구 사항에 대한 예상 상한값과 하한을 찾는 데 도움이 됩니다.
고려해야 할 기본 요소는 다음과 같습니다(이 순서).
-
네트워크 속도
- 네트워크 지연
- 사용 가능한 대역폭
-
계산 속도
- 캐싱 효율성
- 예상되는 트래픽
- 템플릿, 애플리케이션 및 구성 요소의 복잡성
- 동시 작성자
- 작성 작업의 복잡성(단순 컨텐츠 편집, MSM 롤아웃 등)
-
I/O 성능
- 파일 또는 데이터베이스 스토리지의 성능 및 효율성
-
하드 드라이브
- 저장소 크기보다 2~3배 이상 큼
-
메모리
- 웹 사이트 크기(컨텐츠 개체, 페이지 및 사용자 수)
- 동시에 활성 상태인 사용자/세션 수
아키텍처 architecture
일반적인 AEM 설정은 작성자와 게시 환경으로 구성됩니다. 이러한 환경에는 기본 하드웨어 크기 및 시스템 구성에 대한 요구 사항이 다릅니다. 두 환경에 대한 자세한 고려 사항은 작성 환경 및 게시 환경 섹션에 자세히 설명되어 있습니다.
일반적인 프로젝트 설정에는 프로젝트 단계를 스테이징할 환경이 여러 개 있습니다.
-
개발 환경
새로운 기능을 개발하거나 중요한 변경 작업을 수행하려면 다음을 수행하십시오. 가장 좋은 방법은 개발자별로 개발 환경을 사용하여 작업하는 것입니다(일반적으로 개인 시스템에 로컬 설치). -
작성 테스트 환경
변경 사항을 확인하려면 테스트 환경 수는 프로젝트 요구 사항에 따라 달라질 수 있습니다(예: QA, 통합 테스트 또는 사용자 수락 테스트를 위해 별개). -
테스트 환경 게시
주로 소셜 공동 작업 사용 사례 및/또는 작성자와 여러 게시 인스턴스 간의 상호 작용을 테스트하는 데 사용됩니다. -
작성 프로덕션 환경
작성자가 컨텐츠를 편집할 수 있습니다. -
프로덕션 환경 게시
게시된 컨텐츠를 제공하려면
또한 AEM을 실행하는 단일 서버 시스템과 애플리케이션 서버에서 높은 스케일의 다중 서버 다중 CPU 클러스터 인스턴스 세트에 이르기까지 환경이 달라질 수 있습니다. 각 프로덕션 시스템에 별도의 컴퓨터를 사용하고 이러한 컴퓨터에서 다른 응용 프로그램을 실행하지 않는 것이 좋습니다.
일반적인 하드웨어 크기 조정 고려 사항 generic-hardware-sizing-considerations
아래 섹션에서는 다양한 고려 사항을 고려하여 하드웨어 요구 사항을 계산하는 방법에 대한 지침을 제공합니다. 대규모 시스템의 경우 참조 구성에 대해 간단한 사내 벤치마크 테스트 세트를 수행하는 것이 좋습니다.
성능 최적화는 특정 프로젝트에 대한 벤치마킹을 수행하기 전에 수행해야 하는 기본적인 작업입니다. 에 제공된 지침을 반드시 적용하십시오 성능 최적화 설명서 벤치마크 테스트를 수행하고 하드웨어 크기 조정 계산에 결과를 사용하기 전에
고급 사용 사례를 위한 하드웨어 크기 조정 요구 사항은 프로젝트에 대한 자세한 성능 평가를 기반으로 해야 합니다. 탁월한 하드웨어 리소스를 필요로 하는 고급 사용 사례의 특징에는 다음 조합이 포함됩니다.
- 높은 컨텐츠 페이로드/처리량
- 사용자 정의된 코드, 사용자 정의 워크플로우 또는 타사 소프트웨어 라이브러리의 광범위한 사용
- 지원되지 않는 외부 시스템과 통합
디스크 공간/하드 드라이브 disk-space-hard-drive
필요한 디스크 공간은 웹 애플리케이션의 볼륨과 유형에 따라 크게 달라집니다. 계산은 다음 사항을 고려해야 합니다.
- 페이지, 자산 및 워크플로우, 프로필 등과 같은 기타 저장소 저장 엔티티의 수량과 크기입니다.
- 예상되는 컨텐츠 변경 빈도 및 따라서 컨텐츠 버전 작성
- 생성될 DAM 자산 표현물의 볼륨
- 시간에 따른 전체 컨텐츠 증가
온라인 및 오프라인, 개정 정리 중에 디스크 공간이 지속적으로 모니터링됩니다. 사용 가능한 디스크 공간이 임계값보다 작은 경우 프로세스가 취소됩니다. 중요한 값은 리포지토리의 현재 디스크 사용 공간의 25%이며 구성할 수 없습니다. 예상 증식을 포함하여 저장소 크기보다 최소 2~3배 더 큰 디스크 크기를 지정하는 것이 좋습니다.
데이터 중복성을 위해 독립 디스크(예: RAID10)의 중복 어레이 설정을 고려합니다.
가상화 virtualization
AEM은 가상화 환경에서 잘 작동하지만 물리적 하드웨어와 직접 연결할 수 없는 CPU 또는 I/O와 같은 요인이 있을 수 있습니다. 대부분의 경우 I/O 속도가 중요한 요소이므로 더 높은 I/O 속도를 선택하는 것이 좋습니다. 환경을 벤치마킹하는 것은 어떤 리소스가 필요한지를 정확히 이해하기 위해 필요합니다.
AEM 인스턴스 병렬화 parallelization-of-aem-instances
안전 실패 fail-safeness
장애 조치(fail-safe) 웹 사이트가 적어도 두 개의 개별 시스템에 배포됩니다. 하나의 시스템이 고장나면 다른 시스템이 인계 받을 수 있어 시스템 실패를 보상할 수 있다.
시스템 리소스 확장성 system-resources-scalability
모든 시스템이 실행 중이면 컴퓨터 성능이 향상됩니다. 관계가 기술 환경에 크게 종속되어 있으므로 추가적인 성능이 반드시 클러스터 노드 수와 선형일 필요는 없습니다. 자세한 내용은 클러스터 설명서 추가 정보.
필요한 클러스터 노드 수 추정은 특정 웹 프로젝트의 기본 요구 사항과 특정 사용 사례를 기반으로 합니다.
- 장애 안전성의 관점에서 모든 환경에 대해 클러스터 노드가 복구되는 데 걸리는 시간에 따라 장애 발생 여부 및 장애 보상 시간을 결정해야 합니다.
- 스케일러빌러티의 측면에서 쓰기 작업의 수는 기본적으로 가장 중요한 요소입니다. 참조 동시에 작업하는 작성자 작성 환경 및 Social Collaboration 를 사용하도록 선택할 수 있습니다. 읽기 작업을 처리하기 위해 시스템에 액세스하는 작업에 대해 로드 밸런싱을 설정할 수 있습니다. 참조 Dispatcher 자세한 내용
작성 환경별 계산 author-environment-specific-calculations
벤치마킹을 위해 Adobe은 독립형 작성자 인스턴스에 대한 일부 벤치마크 테스트를 개발했습니다.
-
벤치마크 테스트 1
사용자가 300개의 기존 페이지의 기본 로드 위에 간단한 페이지 만들기 연습을 수행하는 로드 프로필의 최대 처리량을 계산하여 유사한 특성을 모두 갖습니다. 관련된 단계는 사이트에 로그인하고, SWF 및 이미지/텍스트를 사용하여 페이지를 만들고, 태그 클라우드를 추가한 다음 페이지를 활성화했습니다.
-
결과
위와 같은 간단한 페이지 작성 연습에 대한 최대 처리량이 1730개 트랜잭션/시간에 있는 것으로 확인되었습니다.
-
-
벤치마크 테스트 2
로드 프로필에 새 페이지 작성(10%), 기존 페이지 수정(80%), 생성 및 후속 페이지 수정(10%)이 혼합된 경우 최대 처리량을 계산합니다. 페이지의 복잡도는 벤치마크 테스트 1의 프로필과 동일하게 유지됩니다. 페이지의 기본적인 수정은 이미지를 추가하고 텍스트 컨텐츠를 수정하여 수행됩니다. 다시, 이 연습은 벤치마크 테스트 1에서 정의한 복잡도와 동일한 300페이지의 기본 로드 위에서 수행되었습니다.
-
결과
이러한 혼합 작업 시나리오에 대한 최대 처리량은 시간당 3252 트랜잭션으로 발견되었습니다.
-
위의 두 테스트는 처리량이 작업 유형에 따라 달라진다는 것을 명확하게 강조 표시합니다. 시스템의 크기 조정을 위한 기반으로 환경의 활동을 사용하십시오. 수정과 같은 작업이 덜 집중되어 처리량이 향상됩니다(또한 일반적입니다.).
캐싱 caching
작성 환경에서는 웹 사이트 변경 사항이 더 빈번하고 컨텐츠가 대화형 및 개인화되므로 캐싱 효율이 일반적으로 훨씬 낮습니다. 디스패처를 사용하여 AEM 라이브러리, JavaScript, CSS 파일 및 레이아웃 이미지를 캐시할 수 있습니다. 이를 통해 작성 프로세스의 일부 측면을 가속화할 수 있습니다. 이러한 리소스에 대해 브라우저 캐싱에 대한 헤더를 추가로 설정하도록 웹 서버를 구성하면 HTTP 요청 수가 줄어들고 작성자가 경험하는 대로 시스템 응답성이 개선됩니다.
동시에 작업하는 작성자 authors-working-in-parallel
작성 환경에서 동시에 작동하는 작성자 수와 시스템에 추가하는 상호 작용 로드가 주요 제한 요소입니다. 따라서 데이터의 공유 처리량에 따라 시스템을 확장하는 것이 좋습니다.
이러한 시나리오에 대해 Adobe이 작성자 인스턴스의 두 노드 공유-없음 클러스터에서 벤치마크 테스트를 실행했습니다.
-
벤치마크 테스트 1a
2개의 작성자 인스턴스의 활성 활성 상태의 공유 없는 클러스터를 사용하면 사용자가 300개의 기존 페이지의 기본 로드 위에 간단한 페이지 만들기 연습을 수행하는 로드 프로필로 최대 처리량을 계산합니다. 이러한 동작은 모두 비슷합니다.
-
결과
위와 같이 간단한 페이지 작성 연습에 대한 최대 처리량은 (하나의 트랜잭션으로 간주됨)2016년 트랜잭션/시간이 확인된 것입니다. 이는 동일한 벤치마크 테스트에 대한 독립 실행형 작성자 인스턴스와 비교할 때 약 16%의 증가입니다.
-
-
벤치마크 테스트 2b
2개의 작성자 인스턴스의 활성 활성 상태의 공유 없는 클러스터를 사용하는 경우, 로드 프로필에 새 페이지 만들기(10%), 기존 페이지 수정(80%) 및 연속된 페이지 만들기 및 수정(10%)이 혼합된 경우 최대 처리량을 계산합니다. 페이지의 복잡도는 벤치마크 테스트 1의 프로필과 동일하게 유지됩니다. 페이지의 기본적인 수정은 이미지를 추가하고 텍스트 컨텐츠를 수정하여 수행됩니다. 다시, 이 연습은 벤치마크 테스트 1에 정의된 대로 복잡도가 300페이지인 기본 로드 위에 수행되었습니다.
-
결과
이러한 혼합 작업 시나리오에 대한 최대 처리량은 시간당 6288 트랜잭션입니다. 이는 동일한 벤치마크 테스트에 대한 독립 실행형 작성자 인스턴스와 비교할 때 약 93%의 증가입니다.
-
위의 두 테스트에서는 AEM을 사용하여 기본 편집 작업을 수행하는 작성자에게 AEM의 크기가 잘 조절된다는 것을 명확히 보여줍니다. 일반적으로 AEM은 읽기 작업 크기 조절에 가장 효과적입니다.
일반적인 웹 사이트에서는 프로젝트 단계 동안 대부분의 작성이 발생합니다. 웹 사이트가 라이브로 전환되면 동시에 작업하는 작성자 수는 일반적으로 더 낮은(작동 모드) 평균에 해당합니다.
다음과 같이 작성 환경에 필요한 컴퓨터(또는 CPU) 수를 계산할 수 있습니다.
n = numberOfParallelAuthors / 30
이 공식은 작성자가 AEM에서 기본 작업을 수행할 때 CPU 크기 조정을 위한 일반적인 지침 역할을 합니다. 이 섹션에서는 시스템과 애플리케이션이 최적화되었다고 가정합니다. 그러나 MSM 또는 자산과 같은 고급 기능에 대해서는 수식이 true가 되지 않습니다(아래 섹션 참조).
다음에 대한 추가 주석을 참조하십시오. 병렬 처리 및 성능 최적화.
하드웨어 Recommendations hardware-recommendations
일반적으로 게시 환경에 권장되는 것과 동일한 하드웨어를 작성 환경에 사용할 수 있습니다. 일반적으로 웹 사이트 트래픽은 작성 시스템에서 훨씬 더 낮지만 캐시 효율도 더 낮습니다. 그러나 여기에서 근본적인 요소는 시스템에서 수행되는 작업 유형과 함께 동시에 작업하는 작성자 수입니다. 일반적으로 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 SUITE2006 벤치마크 점수는 110입니다.
AEM 인스턴스가 최소 힙의 크기가 256M이고 최대 힙의 크기는 1024M입니다.
게시 환경별 계산 publish-environment-specific-calculations
캐싱 효율성 및 트래픽 caching-efficiency-and-traffic
웹 사이트 속도에 있어 캐시 효율성이 중요합니다. 다음 표는 디스패처와 같이 역방향 프록시를 사용하여 최적화된 AEM 시스템에서 처리할 수 있는 초당 페이지 수를 보여줍니다.
캐시 비율은 AEM에 액세스하지 않고도 Dispatcher가 반환할 수 있는 페이지의 백분율입니다. 100%는 Dispatcher가 모든 요청에 응답함을 나타내고, 0%는 AEM이 모든 단일 페이지를 계산함을 의미합니다.
템플릿 및 애플리케이션의 복잡성 complexity-of-templates-and-applications
복잡한 템플릿을 사용하는 경우 AEM에서 페이지를 렌더링하는 데 시간이 더 필요합니다. 캐시에서 가져온 페이지는 영향을 받지 않지만 전체 응답 시간을 고려할 때 페이지 크기는 여전히 관련이 있습니다. 복잡한 페이지를 렌더링하는 데 간단한 페이지를 렌더링하는 것보다 10배 쉽게 걸릴 수 있습니다.
공식 formula
다음 공식을 사용하여 AEM 솔루션의 전체 복잡성에 대한 예상 을 계산할 수 있습니다.
complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)
복잡성에 따라 게시 환경에 필요한 서버(또는 CPU 코어)의 수를 다음과 같이 결정할 수 있습니다.
n = (traffic * complexity / 1000 ) * activations
방정식의 변수는 다음과 같습니다.
보다 복잡한 웹 사이트가 있는 경우, AEM이 허용 가능한 시간에 요청에 응답할 수 있도록 더 강력한 웹 서버가 필요합니다.
-
복잡성 4:
- 1024MB JVM RAM(&A);
- 저전력 CPU-중간 CPU
-
4와 8 사이의 복잡성:
- 2048MB JVM RAM(&A);
- 중간 고성능 CPU
-
8보다 복잡함:
- 4096MB JVM RAM(&A);
- 고성능 CPU
추가 사용 사례별 계산 additional-use-case-specific-calculations
기본 웹 애플리케이션에 대한 계산 외에도 다음과 같은 사용 사례에 대해 특정 요소를 고려해야 할 수 있습니다. 계산된 값이 기본 계산에 추가됩니다.
자산별 고려 사항 assets-specific-considerations
디지털 자산을 광범위하게 처리하려면 최적화된 하드웨어 리소스가 필요하며 가장 관련성이 높은 요소는 이미지 크기와 처리된 이미지의 최대 처리량입니다.
16GB 이상의 힙을 할당하고 DAM 자산 업데이트 워크플로우를 구성하여 Camera Raw 패키지 를 참조하십시오.
다중 사이트 관리자 multi-site-manager
작성 환경에서 AEM MSM을 사용할 때의 리소스 사용은 특정 사용 사례에 따라 크게 다릅니다. 기본 요소는 다음과 같습니다.
- Live Copy 수
- 롤아웃의 주기
- 롤아웃할 컨텐츠 트리 크기
- 롤아웃 작업의 연결된 기능
대표적인 컨텐츠 발췌문을 사용하여 계획된 사용 사례를 테스트하면 리소스 소비를 이해하는 데 도움이 될 수 있습니다. 계획된 처리량에 따라 결과를 추정하는 경우 AEM MSM에 필요한 추가 리소스를 평가할 수 있습니다.
AEM MSM 사용 사례에서 계획한 것보다 더 많은 리소스를 소비하는 경우 동시에 작업하는 작성자는 성능 부작용도 감지하게 된다는 점도 고려하십시오.
AEM Communities 크기 조정 고려 사항 aem-communities-sizing-considerations
AEM Communities 기능(커뮤니티 사이트)을 포함하는 AEM 사이트는 게시 환경의 사이트 방문자(구성원)와 높은 수준의 상호 작용을 경험합니다.
커뮤니티 사이트에 대한 크기 조정 고려 사항은 커뮤니티 구성원이 기대하는 상호 작용과 페이지 컨텐츠에 대한 최적의 성능이 더 중요한지 여부에 따라 달라집니다.
UGC(사용자 생성 컨텐츠) 제출 멤버는 페이지 컨텐츠와 별도로 저장됩니다. AEM 플랫폼에서는 작성자에서 게시로 사이트 컨텐츠를 복제하는 노드 저장소를 사용하지만 AEM Communities에서는 복제되지 않은 UGC에 대해 하나의 공통 저장소를 사용합니다.
UGC 저장소의 경우 선택한 배포에 영향을 주는 SRP(저장소 리소스 제공자)를 선택해야 합니다.
자세한 내용은