멀티 테넌트 관리 및 동시 개발 이해

소개

여러 팀이 동일한 AEM 환경에 코드를 배포할 때 다른 팀의 의견을 따르지 않고 팀이 가능한 한 독립적으로 작업할 수 있도록 해야 하는 경우가 있습니다. 완전히 제거할 수는 없지만 이러한 기법은 팀 간 종속성을 최소화합니다. 동시 개발 모델이 성공하려면 개발 팀 간의 원활한 커뮤니케이션이 중요합니다.

또한 여러 개발 팀이 동일한 AEM 환경에서 작업하는 경우 재생 시 멀티 테넌트 관리 정도가 있을 수 있습니다. 특히 거버넌스, 운영 및 개발을 관리할 때 발생하는 당면 과제를 해결하기 위해 AEM 환경에서 여러 테넌트를 지원하려는 시도가 실제로 고려된 경우가 많습니다. 이 백서에서는 다중 임차인 환경에서 AEM을 구현하는 것과 관련된 몇 가지 기술적 과제를 살펴보지만, 이러한 권장 사항 중 대다수는 여러 개발 팀이 있는 모든 조직에 적용됩니다.

AEM은 여러 사이트를 지원할 수 있지만 단일 환경에 배포되는 여러 브랜드도 지원하지만 진정한 멀티 테넌트 관리 기능은 제공하지 않는다는 점을 명심하십시오. 일부 환경 구성 및 시스템 리소스는 항상 환경에 배포되는 모든 사이트에서 공유됩니다. 이 백서에서는 이러한 공유 리소스의 영향을 최소화하기 위한 지침을 제공하고 이러한 영역에서 커뮤니케이션 및 공동 작업을 간소화하기 위한 제안을 제공합니다.

이점 및 과제

다중 임차인 환경을 구현하려면 많은 문제가 있습니다.

이러한 쿠키에는 다음이 포함됩니다.

  • 추가적인 기술적 복잡성
  • 개발 오버헤드 증가
  • 공유 리소스에 대한 조직 간 종속성
  • 운영 복잡성 증가

어려운 과제에도 불구하고 멀티 테넌트 애플리케이션을 실행하면 다음과 같은 이점이 있습니다.

  • 하드웨어 비용 절감
  • 향후 사이트 출시 시간 단축
  • 향후 테넌트에 대한 구현 비용 절감
  • 비즈니스 전반에서 표준 아키텍처 및 개발 사례
  • 일반적인 코드베이스

비즈니스에 다른 테넌트에 대한 지식이 없고 공유 코드, 컨텐츠 또는 일반 작성자가 없는 진정한 다중 임차인이 필요한 경우, 별도의 작성 인스턴스가 유일한 실행 가능한 옵션입니다. 개발 노력의 전반적인 증가는 인프라 및 라이센스 비용의 절감과 비교하여 이러한 접근 방식이 가장 적합한지 결정해야 합니다.

개발 기법

종속성 관리

Maven 프로젝트 종속성을 관리할 때는 모든 팀이 서버에서 지정된 OSGi 번들의 동일한 버전을 사용하는 것이 중요합니다. Maven 프로젝트가 잘못 관리될 때 발생할 수 있는 문제를 보여주기 위해 다음 예를 제공합니다.

프로젝트 A는 라이브러리의 버전 1.0에 따라 다릅니다.버전 1.0은 서버 배포에 포함됩니다. 프로젝트 B는 라이브러리의 버전 1.1에 따라 다릅니다.버전 1.1은 배포에 포함되어 있습니다.

또한 이 라이브러리에서 버전 1.0과 1.1 간에 API가 변경되었다고 가정해 보겠습니다. 이때 두 프로젝트 중 하나가 더 이상 제대로 작동하지 않습니다.

이러한 문제를 해결하려면 모든 Maven 프로젝트를 한 부모 반응기 프로젝트의 하위 항목으로 만드는 것이 좋습니다. 이 원자로 프로젝트는 두 가지 용도로 사용됩니다.필요한 경우 모든 프로젝트를 함께 빌드하고 배포할 수 있으며 모든 하위 프로젝트에 대한 종속성 선언이 포함되어 있습니다. 상위 프로젝트는 종속성 및 해당 버전을 정의하는 반면 하위 프로젝트는 필요한 종속성을 선언하며 상위 프로젝트에서 버전을 상속합니다.

이 시나리오에서 프로젝트 B를 작업하는 팀이 foo 버전 1.1의 기능을 필요로 하는 경우, 이 변경 사항이 프로젝트 A를 중단한다는 것이 개발 환경에서 빠르게 드러납니다.이때 팀은 이 변경에 대해 논의하고 프로젝트 A가 새 버전과 호환되도록 하거나, 프로젝트 B를 위한 대체 솔루션을 찾을 수 있습니다.

이는 이러한 팀이 이러한 종속성을 공유할 필요가 없도록 합니다. 이는 문제가 빠르고 빨리 강조되므로 팀이 모든 위험을 논의하고 솔루션에 동의할 수 있습니다.

코드 복제 방지

여러 프로젝트에서 작업하는 경우 코드가 중복되지 않도록 하는 것이 중요합니다. 코드 중복은 코드 베이스의 결함 발생 가능성, 시스템 변경 비용, 전체 강성 가능성을 높입니다. 중복을 방지하기 위해 공통 논리를 여러 프로젝트에서 사용할 수 있는 재사용 가능한 라이브러리로 리팩터링합니다.

이러한 요구 사항을 지원하려면 모든 팀이 믿고 기여할 수 있는 핵심 프로젝트의 개발 및 유지 관리를 추천합니다. 이때 이 핵심 프로젝트가 개별 팀의 프로젝트에 의존하지 않도록 하는 것이 중요합니다.이렇게 하면 코드 재사용을 프로모션하는 동안 독립 배포를 수행할 수 있습니다.

일반적으로 코어 모듈에 있는 코드의 몇 가지 예는 다음과 같습니다.

  • 다음과 같은 시스템 전체 구성:
    • OSGi 구성
    • 서블릿 필터
    • ResourceResolver 매핑
    • Sling 트랜스포머 파이프라인
    • 오류 처리기(또는 ACS AEM Commons Error Page Handler1 사용)
    • 권한 구분 캐싱에 대한 권한 부여 서블릿
  • 유틸리티 클래스
  • 핵심 비즈니스 논리
  • 타사 통합 논리
  • 작성 UI 오버레이
  • 사용자 지정 위젯과 같은 작성에 필요한 기타 사용자 지정
  • 워크플로우 런처
  • 여러 사이트에서 사용되는 일반적인 디자인 요소

모듈식 프로젝트 아키텍처

따라서 여러 팀이 동일한 코드 세트를 종속하거나 업데이트할 필요가 없습니다. 핵심 프로젝트를 만들어 팀 간에 공유하는 코드 베이스의 크기를 줄였는데 공유 리소스가 필요하지 않게 되었습니다.

이 핵심 패키지를 변경해도 시스템의 기능이 저하되지 않도록 개발자 또는 개발자 팀이 감독을 유지 관리하는 것이 좋습니다. 한 가지 옵션은 이 패키지의 모든 변경 사항을 관리하는 단일 팀을 갖는 것입니다.다른 하나는 팀이 이러한 리소스로 검토 및 병합된 끌어오기 요청을 제출하도록 하는 것입니다. 거버넌스 모델은 팀이 설계하고 동의하며 개발자가 이를 따르는 것이 중요합니다.

배포 범위 관리(&nbsp)

다른 팀이 동일한 저장소에 코드를 배포하므로 서로의 변경 사항을 덮어쓰지 않는 것이 중요합니다. AEM에는 컨텐츠 패키지인 필터를 배포할 때 이 작업을 제어하는 메커니즘이 있습니다. xml 파일. 필터 간에 겹치지 않는 것이 중요합니다. xml 파일이 없으면 한 팀의 배포가 다른 팀의 이전 배포를 삭제시킬 수 있습니다. 이 점을 설명하려면 잘 만들어진 필터 파일과 문제가 있는 필터 파일의 다음 예를 참조하십시오.

/apps/my-company와/apps/my-company/my-site

/etc/clientlibs/my-company와/etc/clientlibs/my-company/my-site

/etc/designs/my-company와/etc/designs/my-company/my-site

각 팀이 작업 중인 사이트로 필터 파일을 명시적으로 구성하는 경우, 각 팀은 서로의 변경 사항을 지우지 않고 구성 요소, 클라이언트 라이브러리 및 사이트 디자인을 독립적으로 배포할 수 있습니다.

이 경로는 전역 시스템 경로이며 한 사이트에만 국한되지 않으므로 여기에서 변경한 사항이 모든 팀에 영향을 줄 수 있으므로 다음 서블릿은 핵심 프로젝트에 포함되어야 합니다.

/apps/sling/servlet/errorhandler

오버레이

오버레이는 기본 제공 AEM 기능을 확장하거나 교체하는 데 자주 사용되지만 오버레이를 사용하는 것은 전체 AEM 애플리케이션에 영향을 줍니다(즉, 모든 테넌트에 대해 기능 변경 사항이 제공됨). 만약 세입자들이 오버레이에 대한 요구 사항이 다르다면 이것은 더 복잡할 것이다. 가장 좋은 방법은 비즈니스 그룹이 함께 AEM 관리 콘솔의 기능과 성능에 동의해야 하는 것입니다.

다양한 비즈니스 단위 간에 합의에 도달하지 못할 경우 가능한 해결 방법은 오버레이를 사용하지 않는 것입니다. 대신 기능의 사용자 지정 사본을 만들고 각 테넌트에 대한 다른 경로를 통해 노출합니다. 이를 통해 각 임차인은 완전히 다른 사용자 경험을 사용할 수 있지만, 이 접근 방식을 통해 구현 비용과 후속 업그레이드 작업도 증가합니다.

워크플로 런처

AEM은 워크플로우 런처를 사용하여 저장소에 지정된 변경 사항이 있을 때 워크플로우 실행을 자동으로 트리거합니다. AEM은 새로운 자산과 업데이트된 자산에 대해 표현물 생성 및 메타데이터 추출 프로세스를 실행하기 위해 즉시 여러 개의 런처를 제공합니다. 이러한 런처를 그대로 둘 수 있지만, 다중 임차인 환경에서 테넌트가 다른 런처 및/또는 워크플로우 모델 요구 사항을 가지고 있는 경우 각 임차인에 대해 개별 런처를 만들고 유지 관리해야 할 가능성이 있습니다. 이러한 런처는 다른 테넌트의 컨텐츠를 그대로 두면서 임차인의 업데이트에 대해 실행되도록 구성해야 합니다. 임차인별로 지정된 저장소 경로에 런처를 적용하여 이를 쉽게 수행할 수 있습니다.

별칭 URL

AEM에서는 페이지별로 설정할 수 있는 별칭 URL 기능을 제공합니다. 다중 임차인 시나리오에서 이 접근 방식의 문제는 AEM이 이 방식으로 구성된 별칭 URL 간의 고유성을 보장하지 않는다는 것입니다. 서로 다른 두 사용자가 페이지마다 동일한 별칭 경로를 구성하는 경우, 예기치 않은 동작이 발생할 수 있습니다. 이러한 이유로 아웃바운드 전용 리소스 확인자 규칙과 함께 중앙 구성 지점을 허용하는 Apache Dispatcher 인스턴스에서 mod_rewrite 규칙을 사용하는 것이 좋습니다.

구성 요소 그룹

여러 작성 그룹에 대한 구성 요소 및 템플릿을 개발할 때는 componentGroup 및 allowedPaths 속성을 효과적으로 사용하는 것이 중요합니다. 사이트 디자인과 함께 이러한 기능을 효과적으로 활용함으로써 Adobe는 브랜드 A의 작성자가 사이트에 대해 만들어진 구성 요소 및 템플릿만 보고 브랜드 B의 작성자는 자신의 자산만 볼 수 있도록 할 수 있습니다.

테스트

적절한 아키텍처와 개방형 통신 채널을 통해 사이트의 예기치 않은 영역에 결함이 유입되는 것을 방지할 수 있지만 이러한 접근 방식은 완벽하지는 않습니다. 이러한 이유로 프로덕션에 릴리스하기 전에 플랫폼에 배포되는 내용을 완전히 테스트하는 것이 중요합니다. 따라서 릴리스 주기에 대해 팀 간의 조정이 필요하며, 가능한 한 많은 기능을 제공하는 자동화된 테스트 제품군의 필요성을 보강합니다. 또한 하나의 시스템이 여러 팀에서 공유되므로 성능, 보안 및 로드 테스트가 그 어느 때보다 중요해집니다.

작업 고려 사항

공유 리소스

AEM은 단일 JVM 내에서 실행됩니다.배포된 모든 AEM 애플리케이션은 기본적으로 리소스를 공유하며, AEM의 정상적인 실행 시 이미 사용된 리소스 위에 있습니다. JVM 공간 자체에는 스레드의 논리적 분리가 없으며 메모리, CPU, 디스크 i/o와 같이 AEM에서 사용할 수 있는 유한 리소스도 공유되지 않습니다. 자원을 사용하는 임차인은 필연적으로 다른 시스템 테넌트에 영향을 미칠 것이다.

공연

AEM Best Practice를 따르지 않을 경우, 정상적인 것으로 간주되는 리소스를 초과하는 애플리케이션을 개발할 수 있습니다. 이러한 작업의 예로는 많은 노드에 대해 MSM 푸시 온 수정 작업을 사용하거나 값비싼 JCR 쿼리를 사용하여 실시간으로 컨텐츠를 렌더링하는 등 많은 복잡한 워크플로우 작업(예: DAM 자산 업데이트)이 트리거됩니다. 이는 다른 테넌트 애플리케이션의 성능에 영향을 줄 수 있습니다.

로깅

AEM은 공유 개발 시나리오에서 유용하게 사용할 수 있는 강력한 로거 구성을 위한 기본 인터페이스를 제공합니다. 각 브랜드에 대해 패키지 이름으로 별도의 로거를 지정하면 로그 분리를 어느 정도 수행할 수 있습니다. 복제 및 인증과 같은 시스템 전체 작업이 여전히 중앙 위치에 기록되지만, 비공유 사용자 지정 코드를 별도로 기록할 수 있으므로 각 브랜드의 기술 팀에 대한 모니터링 및 디버깅 노력을 줄일 수 있습니다.

백업 및 복원

JCR 저장소의 특성으로 인해 기존 백업은 개별 컨텐츠 경로가 아니라 전체 저장소에서 작동합니다. 따라서 임차인별로 백업을 쉽게 분리할 수 없습니다. 반대로 백업에서 복원하면 시스템의 모든 테넌트에 대한 컨텐츠와 저장소 노드가 롤백됩니다. VLT와 같은 툴을 사용하여 타겟팅된 컨텐츠 백업을 수행하거나 별도의 환경에서 패키지를 구축하여 복원할 체리 선택 컨텐츠를 선택할 수 있지만,
접근 방식은 구성 설정 또는 애플리케이션 로직을 쉽게 포괄하지 않으며, 관리하는 데 번거로울 수 있습니다.

보안 고려 사항

ACL

물론 ACL(액세스 제어 목록)을 사용하여 컨텐츠 경로를 기반으로 컨텐츠를 보고, 만들고, 삭제할 수 있는 액세스 권한을 가진 사용자를 제어하려면 사용자 그룹을 만들고 관리해야 합니다. ACL 및 그룹을 유지 관리하는 데 어려움을 겪는 것은 각 테넌트에 다른 항목에 대한 지식이 전혀 없는지, 배포된 응용 프로그램이 공유 리소스에 의존하는지 여부에 따라 달라집니다. 효율적인 ACL, 사용자 및 그룹 관리를 위해 효율성 및 보안을 강화하는 방식으로 액세스 제어 및 주도자가 겹치거나 겹치지 않도록 필요한 감독을 갖춘 중앙 집중식 그룹을 사용하는 것이 좋습니다.

이 페이지에서는