다중 테넌트 및 동시 개발 이해

소개

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

또한 여러 개발 팀이 동일한 AEM 환경에서 작업할 때 재생 시 몇 가지 멀티 테넌시가 있을 수 있습니다. 특히 지배 구조, 운영 및 개발 시 직면하는 어려움들을 중심으로 AEM 환경에서 여러 세입자를 지원하려고 시도하는 현실적인 고려 사항에 대해 많은 것이 기록되었다. 이 백서에서는 멀티 테넌트 환경에서 AEM을 구현하는 데 있어 기술적 어려움 몇 가지를 짚어 볼 수 있지만 이러한 권장 사항 중 대부분은 여러 개발 팀이 있는 모든 조직에 적용됩니다.

AEM은 여러 사이트와 단일 환경에 배포되는 여러 브랜드를 지원할 수 있지만 진정한 멀티 테넌시는 제공되지 않습니다. 일부 환경 구성 및 시스템 리소스는 환경에 배포된 모든 사이트에서 항상 공유됩니다. 본 백서에서는 이러한 공유 리소스의 영향을 최소화하기 위한 지침을 제공하며 이러한 영역에서 의사 소통 및 공동 작업을 능률화하는 방법을 제안합니다.

장점 및 과제

멀티 테넌트 환경을 구현하는 데는 많은 문제가 있습니다.

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

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

그러나 멀티 테넌트 애플리케이션을 실행하면 다음과 같은 이점이 있습니다.

  • 하드웨어 비용 절감
  • 향후 사이트 출시 시간 단축
  • 향후 세입자를 위한 구현 비용 절감
  • 비즈니스 전반의 표준 아키텍처 및 개발 사례
  • 일반적인 코드베이스

비즈니스에 다른 임차인에 대한 지식이 전혀 없고 공유 코드, 컨텐츠 또는 공통 작성자가 없는 진정한 멀티 테넌시가 필요한 경우 별도의 작성자 인스턴스만이 실행 가능한 옵션입니다. 개발 노력의 전반적인 증가는 인프라 및 라이선스 비용 절감 효과와 비교하여 이 방식이 가장 적합한지를 판단해야 합니다.

개발 기법

종속성 관리

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

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

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

이러한 문제를 해결하기 위해, 우리는 한 상위 원자로 프로젝트의 모든 마웬 프로젝트 하위 프로젝트를 만드는 것을 권장합니다. 이 원전 프로젝트는 2가지 목적을 갖고 있다.원할 경우 모든 프로젝트를 함께 빌드하고 배포할 수 있으며 모든 하위 프로젝트에 대한 종속성 선언이 포함되어 있습니다. 상위 프로젝트는 종속성 및 해당 버전을 정의하지만, 하위 프로젝트는 상위 프로젝트에서 버전을 상속하면서 필요한 종속성을 선언합니다.

이 시나리오에서는 프로젝트 B를 작업하는 팀이 foo 버전 1.1의 기능을 필요로 하는 경우 이러한 변경 사항이 프로젝트 A를 중단시키므로 개발 환경에서 쉽게 확인할 수 있습니다.이때 팀은 이 변경 사항에 대해 논의할 수 있으며 Project A가 새 버전과 호환되도록 하거나 프로젝트 B에 대한 대체 솔루션을 찾을 수 있습니다.

따라서 이러한 팀은 의존성을 공유할 필요가 없습니다. 문제를 신속하면서도 신속하게 강조 표시하여 팀이 모든 위험에 대해 토론하고 솔루션에 동의하게 할 수 있습니다.

코드 복제 방지

여러 프로젝트에서 작업할 때는 코드가 중복되지 않도록 해야 합니다. 코드 중복은 코드 베이스의 결함 발생 가능성, 시스템 변경 비용 및 전반적인 경직성 가능성을 높입니다. 중복을 방지하기 위해 여러 프로젝트에서 사용할 수 있는 재사용 가능한 라이브러리로 일반적인 논리를 재평가합니다.

이러한 요구 사항을 충족하기 위해 모든 팀이 의존하거나 기여할 수 있는 핵심 프로젝트의 개발 및 유지 관리를 권장합니다. 이 경우 이 핵심 프로젝트가 개별 팀의 프로젝트에 의존하지 않도록 하는 것이 중요합니다.이렇게 하면 코드 재사용을 홍보하면서 독립적으로 배포할 수 있습니다.

핵심 모듈에 일반적으로 포함되는 코드의 몇 가지 예는 다음과 같습니다.

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

모듈형 프로젝트 아키텍처

따라서 여러 팀이 동일한 코드 세트를 의존하거나 업데이트할 필요가 없습니다. 핵심 프로젝트를 제작함으로써 팀 간에 공유되는 코드베이스의 크기는 줄었지만 공유 리소스의 필요성을 없애지는 못했습니다.

이 핵심 패키지에 대한 변경 사항이 시스템의 기능을 방해하지 않도록 수석 개발자 또는 개발자 팀이 관리 감독을 유지하는 것이 좋습니다. 한 가지 옵션은 이 패키지의 모든 변경 내용을 관리하는 단일 팀을 갖는 것입니다.다른 하나는 이러한 리소스에 의해 검토 및 병합된 가져오기 요청을 팀에 제출하도록 하는 것입니다. 관리 모델은 팀이 설계하고 이에 동의하며 개발자는 이를 따라야 합니다.

배포 범위 관리(&N)

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

/apps/my-company vs./apps/my-company/my-site

/etc/clientlibs/my-company vs./etc/clientlibs/my-company/my-site

/etc/designs/my-company vs./etc/designs/my-company/my-site

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

한 사이트에만 국한되지 않고 글로벌 시스템 경로이므로 여기에서 변경한 내용이 모든 팀에 영향을 줄 수 있으므로 핵심 프로젝트에 다음 서블릿을 포함해야 합니다.

/apps/sling/servlet/errorhandler

오버레이

오버레이는 종종 기본 AEM 기능을 확장하거나 교체하는 데 사용되지만 오버레이를 사용하면 전체 AEM 응용 프로그램에 영향을 줍니다. 즉, 모든 기능 변경 사항은 모든 테넌트에 대해 제공됩니다. 만약 세입자들이 오버레이에 대한 요구 사항이 다르다면 이것은 더 복잡할 것이다. 비즈니스 그룹은 AEM 관리 콘솔의 기능 및 모양에 동의하기 위해 함께 작업해야 합니다.

다양한 사업 단위 간에 합의가 이루어지지 않는다면, 가능한 해결책은 단순히 오버레이를 사용하지 않는 것입니다. 대신, 사용자 지정 기능 사본을 만들고 각 테넌트에 대해 다른 경로를 통해 해당 기능을 노출합니다. 따라서 각 테넌트는 완전히 다른 사용자 경험을 할 수 있지만, 이 방법은 구현 및 후속 업그레이드 노력을 증가시킵니다.

워크플로 런처

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

별칭 URL

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

구성 요소 그룹

여러 제작 그룹의 구성 요소 및 템플릿을 개발할 때는 componentGroup 및 allowedPaths 속성을 효과적으로 사용해야 합니다. 사이트 디자인과 함께 이러한 효과를 활용함으로써 브랜드 A의 작성자는 사이트에 대해 작성된 구성 요소 및 템플릿만 표시하고 브랜드 B의 작성자는 자체 사이트만 볼 수 있도록 할 수 있습니다.

테스트

훌륭한 아키텍처 및 개방형 커뮤니케이션 채널을 사용하면 사이트의 예상치 못한 영역에 결함이 발생하지 않도록 할 수 있지만 이러한 접근 방식은 완벽하지 않습니다. 이러한 이유로 프로덕션에 어떤 것을 출시하기 전에 플랫폼에 배포 중인 항목을 완전히 테스트해야 합니다. 이를 위해서는 출시 주기에 대한 팀 간의 조정이 필요하며 가능한 많은 기능을 포함하는 자동화된 테스트 세트의 필요성을 강화합니다. 또한 하나의 시스템이 여러 팀에서 공유되기 때문에 성능, 보안 및 로드 테스트가 이전보다 더 중요해집니다.

작동 고려 사항

공유 리소스

AEM은 단일 JVM 내에서 실행됩니다.배포된 모든 AEM 애플리케이션은 원래 서로 리소스를 공유하며, 일반적인 AEM 실행 시 이미 사용한 리소스 외에도 JVM 공간 자체에는 스레드의 논리적 분리가 없으며 메모리, CPU 및 디스크 i/o와 같이 AEM에 사용할 수 있는 한정된 리소스도 공유됩니다. 자원을 소비하는 임차인은 다른 시스템 세입자들에게 불가피하게 영향을 미칠 것이다.

공연

AEM 모범 사례를 따르지 않는 경우 리소스를 사용하는 애플리케이션을 일반 리소스를 초과하는 애플리케이션을 개발할 수 있습니다. 이러한 예제는 많은 노드에 대해 MSM 푸시 온-수정 작업을 사용하거나 값비싼 JCR 쿼리를 사용하여 컨텐츠를 실시간으로 렌더링하는 대량의 워크플로우 작업(예: DAM Update Asset)을 트리거하는 것입니다. 이러한 효과는 다른 테넌트 애플리케이션의 성능에 영향을 미칠 수 있습니다.

로깅

AEM은 공유 개발 시나리오의 이점을 활용할 수 있는 강력한 로거 구성을 위한 즉시 인터페이스를 제공합니다. 각 브랜드에 대한 개별 로거를 패키지 이름으로 지정하면 로그 분류의 정도를 달성할 수 있습니다. 복제 및 인증과 같은 시스템 차원의 작업은 여전히 중앙 위치에 기록되지만 비공유 사용자 지정 코드를 별도로 기록할 수 있으므로 각 브랜드의 기술 팀에 대한 모니터링 및 디버깅 작업을 간소화할 수 있습니다.

백업 및 복원

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

보안 고려 사항

ACL

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

이 페이지에서는