Adobe Experience Manager 및 MongoDB

마지막 업데이트: 2025년 6월 13일
  • 적용 대상:
  • Experience Manager 6.5

작성 대상:

  • 관리자

이 문서에서는 MongoDB와 함께 AEM(Adobe Experience Manager)를 성공적으로 배포하는 데 필요한 작업 및 고려 사항에 대한 지식을 향상하고자 합니다.

배포와 관련된 자세한 내용은 설명서의 배포 및 유지 관리 섹션을 참조하십시오.

AEM에서 MongoDB를 사용해야 하는 경우

MongoDB는 일반적으로 다음 기준 중 하나가 충족되는 AEM 작성자 배포를 지원하는 데 사용됩니다.

  • 하루에 1000명 이상의 고유 사용자
  • 100명 이상의 동시 사용자
  • 대량의 페이지 편집
  • 대규모 롤아웃 또는 활성화.

위의 기준은 작성자 인스턴스용일 뿐이며 TarMK 기반이어야 하는 모든 게시 인스턴스에 대한 것은 아닙니다. 작성자 인스턴스는 인증되지 않은 액세스를 허용하지 않으므로 사용자 수는 인증된 사용자를 참조합니다.

기준을 충족하지 않으면 가용성을 해결하기 위해 TarMK 활성/대기 배포를 사용하는 것이 좋습니다. 일반적으로 MongoDB는 단일 하드웨어 항목으로 확장 요구 사항을 달성할 수 있는 것보다 더 많은 상황에서 고려되어야 합니다.

노트
작성자 인스턴스 크기 조정 및 동시 사용자 정의에 대한 추가 정보는 하드웨어 크기 조정 지침에서 찾을 수 있습니다.

AEM용 MongoDB 배포 최소화

다음은 MongoDB의 AEM에 대한 최소 배포입니다. 간소화를 위해 SSL 종료 및 HTTP 프록시 구성 요소가 일반화되었습니다. MongoDB 복제본 세트 하나로 구성되며, 기본 복제본 세트와 보조 복제본 세트 두 개가 있습니다.

chlimage_1-4

최소 배포에는 복제본 집합으로 구성된 mongod 인스턴스 3개가 필요합니다. 한 인스턴스는 기본 인스턴스로, 다른 인스턴스는 보조 인스턴스로, 선택은 mongod에서 관리합니다. 각 인스턴스에 로컬 디스크가 연결되어 있습니다. 따라서 클러스터가 로드를 지원할 수 있으므로 최소 처리량은 초당 12MB이며 초당 3000회 이상의 입출력 작업(IOPS)을 수행하는 것이 좋습니다.

AEM 작성자는 mongod 인스턴스에 연결되고 각 AEM 작성자는 세 개의 mongod 인스턴스에 모두 연결됩니다. 쓰기 작업은 운영 시스템으로 전송되며 읽기는 모든 인스턴스에서 읽을 수 있습니다. 트래픽은 Dispatcher에 의한 로드를 기반으로 활성 AEM 작성자 인스턴스 중 하나로 분산됩니다. Oak 데이터 저장소는 FileDataStore이며 MongoDB 모니터링은 배포 위치에 따라 MMS 또는 MongoDB Ops Manager에서 제공합니다. 운영 체제 수준 및 로그 모니터링은 Splunk 또는 Ganglia와 같은 타사 솔루션에서 제공합니다.

이 배포에서는 성공적인 구현을 위해 모든 구성 요소가 필요합니다. 누락된 구성 요소는 구현을 작동하지 않습니다.

운영 체제

AEM 6에서 지원되는 운영 체제 목록은 기술 요구 사항 페이지를 참조하십시오.

환경

프로젝트를 실행하는 여러 기술 팀 간에 원활한 의사 소통이 이루어지는 경우 가상화 환경이 지원됩니다. 이 지원에는 AEM을 실행하는 팀, 운영 체제를 사용하는 팀 및 가상 인프라를 관리하는 팀이 포함됩니다.

가상화 환경을 관리하는 팀이 관리해야 하는 MongoDB 인스턴스의 I/O 용량에 대한 특정 요구 사항이 있습니다. 프로젝트에서 Amazon Web Services과 같은 클라우드 배포를 사용하는 경우 MongoDB 인스턴스를 지원하려면 충분한 I/O 용량과 일관성으로 인스턴스를 프로비저닝해야 합니다. 그렇지 않으면 MongoDB 프로세스 및 Oak 저장소가 불안정하고 비정상적으로 수행합니다.

가상화된 환경에서 MongoDB의 스토리지 엔진이 VMWare 리소스 할당 정책에 의해 손상되지 않도록 하려면 MongoDB는 특정 I/O 및 VM 구성이 필요합니다. 성공적인 구현은 다양한 팀 사이에 장벽을 없애고 모든 팀이 필요한 성능을 제공하기 위해 등록하도록 보장합니다.

하드웨어 고려 사항

스토리지

MongoDB는 일반적으로 SSD 스토리지 또는 SSD와 동등한 성능을 갖춘 스토리지를 필요로 하지 않고 최상의 성능을 제공하기 위해 읽기 및 쓰기 처리량을 구현합니다.

RAM

MMAP 스토리지 엔진을 사용하는 MongoDB 버전 2.6 및 3.0을 사용하려면 데이터베이스 및 해당 인덱스의 작업 집합이 RAM에 적합해야 합니다.

RAM이 부족하면 성능이 크게 저하됩니다. 작업 집합 및 데이터베이스의 크기는 응용 프로그램에 따라 크게 달라집니다. 몇 가지 예상이 가능하지만 필요한 RAM의 양을 결정하는 가장 안정적인 방법은 AEM 애플리케이션을 빌드하고 부하 테스트하는 것입니다.

로드 테스트 프로세스를 지원하기 위해 전체 데이터베이스 크기에 대한 작업 집합의 비율을 다음과 같이 가정할 수 있습니다.

  • SSD 스토리지용 1:10
  • 하드 디스크 스토리지용 1:3

이러한 비율은 SSD 배포의 경우 2TB 데이터베이스에 200GB의 RAM이 필요함을 의미합니다.

MongoDB 3.0의 WiredTiger 스토리지 엔진에도 동일한 제한 사항이 적용되지만 작업 세트, RAM 및 페이지 폴트 간의 상관 관계는 그리 강력하지 않습니다. WiredTiger는 MMAP 스토리지 엔진과 동일한 방식으로 메모리 매핑을 사용하지 않습니다.

노트
Adobe에서는 MongoDB 3.0을 사용하는 AEM 6.1 배포에 WiredTiger 스토리지 엔진을 사용하는 것이 좋습니다.

데이터 저장소

MongoDB 작업 세트 제한 사항으로 인해 데이터 저장소는 MongoDB와 독립적으로 유지되는 것이 좋습니다. 대부분의 환경에서는 모든 AEM 인스턴스에서 사용할 수 있는 NAS를 사용하는 FileDataStore을(를) 사용해야 합니다. Amazon Web Services을 사용하는 상황의 경우 S3 DataStore도 있습니다. 어떤 이유로든 데이터 저장소는 MongoDB 내에서 유지되며, 데이터 저장소의 크기를 전체 데이터베이스 크기에 추가하고, 작업 집합 계산을 적절히 조정해야 합니다. 이 크기 조정은 페이지 오류 없이 성능을 유지하기 위해 더 많은 RAM을 프로비저닝하는 것을 의미할 수 있습니다.

모니터링

프로젝트의 성공적인 구현을 위해서는 모니터링이 필수적이다. 충분한 지식이 있으면 모니터링 없이 MongoDB에서 AEM을 실행할 수 있습니다. 그러나 이러한 지식은 일반적으로 배포의 각 섹션에 특화된 엔지니어에서 발견됩니다.

이 전문 지식에는 일반적으로 Apache Oak Core에서 근무하는 R&D 엔지니어와 MongoDB 전문가가 포함됩니다.

모든 수준에서 모니터링하지 않으면 문제를 진단하기 위해 코드 베이스에 대한 자세한 지식이 필요합니다. 적절한 모니터링과 주요 통계에 대한 적절한 지침을 통해 구현 팀은 예외 항목에 적절히 대응할 수 있습니다.

명령줄 도구를 사용하여 클러스터 작업에 대한 빠른 스냅샷을 얻을 수 있지만 많은 호스트에서 실시간으로 수행하는 것은 거의 불가능합니다. 명령줄 도구는 몇 분 이상의 내역 정보를 제공하는 경우가 거의 없으며 서로 다른 유형의 지표 간에 상호 연관성을 허용하지 않습니다. 느린 백그라운드 mongod 동기화 기간이 짧으면 I/O 대기 또는 연결되지 않은 가상 컴퓨터의 공유 저장소 리소스에 대한 과도한 쓰기 수준과 상관 관계를 맺기 위해 상당한 수작업이 필요합니다.

MongoDB Cloud Manager

MongoDB Cloud Manager은 MongoDB가 제공하는 무료 서비스로 MongoDB 인스턴스의 모니터링과 관리가 가능하다. MongoDB 클러스터의 성능과 상태를 실시간으로 확인할 수 있습니다. 인스턴스가 Cloud Manager 모니터링 서버에 도달할 수 있는 경우 클라우드와 비공개 호스팅 인스턴스를 모두 관리합니다.

모니터링 서버에 연결하는 MongoDB 인스턴스에 에이전트가 설치되어 있어야 합니다. 세 가지 수준의 에이전트가 있습니다.

  • MongoDB 서버의 모든 것을 완전히 자동화할 수 있는 자동화 에이전트,
  • mongod 인스턴스를 모니터링할 수 있는 모니터링 에이전트입니다.
  • 데이터의 스케줄 지정 백업을 수행할 수 있는 백업 에이전트입니다.

Cloud Manager을 MongoDB 클러스터의 유지 관리 자동화에 사용하면 많은 일상적인 작업이 더 쉬워지지만 필요하지 않으며 둘 다 백업에 사용하지 않습니다. 모니터링할 Cloud Manager을 선택할 때는 모니터링이 필요합니다.

MongoDB Cloud Manager에 대한 자세한 내용은 MongoDB 설명서를 참조하세요.

MongoDB 운영 관리자

MongoDB Ops Manager는 MongoDB Cloud Manager과 동일한 소프트웨어입니다. 등록되면 Ops Manager를 로컬로 다운로드하여 개인 데이터 센터 또는 기타 랩톱 또는 데스크톱 시스템에 설치할 수 있습니다. 로컬 MongoDB 데이터베이스를 사용하여 데이터를 저장하고 관리되는 서버와 Cloud Manager과 동일한 방식으로 통신합니다. 모니터링 에이전트를 금지하는 보안 정책이 있는 경우 MongoDB Ops Manager를 사용해야 합니다.

운영 체제 모니터링

AEM MongoDB 클러스터를 실행하려면 운영 체제 수준 모니터링이 필요합니다.

Ganglia는 이러한 시스템의 좋은 예이며 CPU, 로드 평균 및 사용 가능한 디스크 공간과 같은 기본 상태 지표를 뛰어넘는 필요한 정보의 범위와 세부 정보를 제공합니다. 문제를 진단하려면 엔트로피 풀 수준, CPU I/O 대기, FIN_WAIT2 상태의 소켓과 같은 하위 수준 정보가 필요합니다.

로그 집계

여러 서버로 구성된 클러스터에서 중앙 로그 집선은 운영 시스템의 요구 사항입니다. Splunk과 같은 소프트웨어는 로그 집계를 지원하고 팀이 로그를 수동으로 수집하지 않고도 애플리케이션의 동작 패턴을 분석할 수 있도록 합니다.

체크리스트

이 섹션에서는 프로젝트를 구현하기 전에 AEM 및 MongoDB 배포가 제대로 설정되었는지 확인하기 위해 수행해야 하는 다양한 단계를 설명합니다.

네트워크

  1. 먼저 모든 호스트에 DNS 항목이 있는지 확인합니다.
  2. 모든 호스트는 라우팅 가능한 다른 모든 호스트의 DNS 항목으로 확인할 수 있어야 합니다.
  3. 모든 MongoDB 호스트는 동일한 클러스터의 다른 모든 MongoDB 호스트에서 라우팅할 수 있습니다
  4. MongoDB 호스트는 MongoDB Cloud Manager 및 다른 모니터링 서버로 패킷을 라우팅할 수 있습니다
  5. AEM 서버는 모든 MongoDB 서버로 패킷을 라우팅할 수 있습니다
  6. AEM 서버와 MongoDB 서버 간의 패킷 지연 시간은 2밀리초 미만이며 패킷 손실이 없으며 표준 분포는 1밀리초 이하입니다.
  7. AEM과 MongoDB 서버 간에 최대 2개의 홉이 있는지 확인합니다.
  8. MongoDB 서버 두 대 사이에는 두 개 이상의 홉이 없습니다
  9. 코어 서버(MongoDB 또는 AEM 또는 그 조합) 간에 OSI 레벨 3보다 높은 라우터가 없습니다.
  10. VLAN 트렁킹 또는 모든 형태의 네트워크 터널링을 사용하는 경우 패킷 지연 검사를 준수해야 합니다.