멀티테넌트 관리 및 동시 개발 이해 understanding-multitenancy-and-concurrent-development

소개 introduction

여러 팀이 동일한 AEM 환경에 코드를 배포하는 경우 다른 팀의 입장을 방해하지 않고 팀이 최대한 독립적으로 작업할 수 있도록 팀이 따라야 할 연습이 있습니다. 완전히 제거할 수는 없지만 이러한 기술을 통해 팀 간 의존도를 최소화할 수 있습니다. 동시 개발 모델이 성공하려면 개발 팀 간의 원활한 의사 소통이 중요합니다.

또한 여러 개발 팀이 동일한 AEM 환경에서 작업하는 경우 일부 멀티 테넌시가 있을 수 있습니다. 특히 거버넌스, 운영 및 개발을 관리할 때 직면하는 어려움과 관련하여 AEM 환경에서 여러 테넌트를 지원하려는 경우의 실질적인 고려 사항에 대해서는 많은 내용이 설명되어 있습니다. 이 백서에서는 다중 테넌트 환경에서 AEM을 구현하는 것과 관련된 몇 가지 기술적 과제에 대해 알아보았지만, 이러한 권장 사항의 대부분은 여러 개발 팀이 있는 모든 조직에 적용됩니다.

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

이점 및 과제 benefits-and-challenges

다중 테넌트 환경을 구현하려면 많은 문제가 있습니다.

여기에는 다음이 포함됩니다.

이러한 어려움에도 불구하고 다중 임차인 애플리케이션을 실행하면 다음과 같은 이점이 있습니다.

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

개발 기법 development-techniques

종속성 관리 managing-dependencies

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

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

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

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

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

이렇게 해도 이러한 팀이 이러한 종속성을 공유할 필요가 없어지지는 않습니다. 팀이 위험을 논의하고 솔루션에 동의할 수 있도록 문제를 빠르고 일찍 강조 표시합니다.

코드 복제 방지 preventing-code-duplication-nbsp-br

여러 프로젝트에서 작업할 때는 코드가 중복되지 않도록 하는 것이 중요합니다. 코드 중복은 결함 발생의 가능성, 시스템에 대한 변경의 비용, 및 코드 베이스의 전체적인 경직성을 증가시킨다. 중복을 방지하려면 공통 로직을 여러 프로젝트에서 사용할 수 있는 재사용 가능한 라이브러리로 리팩터링하십시오.

이러한 필요성을 뒷받침하기 위해 모든 팀이 의존하고 기여할 수 있는 핵심 프로젝트 개발 및 유지 관리를 권장합니다. 이렇게 할 때 이 핵심 프로젝트가 개별 팀의 프로젝트에 종속되지 않도록 하는 것이 중요합니다. 이렇게 하면 코드 재사용을 촉진하면서도 독립적으로 배포할 수 있습니다.

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

모듈식 프로젝트 아키텍처

따라서 여러 팀이 동일한 코드 세트에 의존하여 잠재적으로 업데이트할 필요가 없습니다. 핵심 프로젝트를 만들어 팀 간에 공유되는 코드 베이스의 크기를 줄였지만 공유 리소스에 대한 필요성을 없애지 못했습니다.

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

배포 범위 관리 managing-deployment-scope

서로 다른 팀이 동일한 저장소에 코드를 배포하는 경우 서로의 변경 사항을 덮어쓰지 않는 것이 중요합니다. 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 vs. /etc/designs/my-company/my-site

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

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

/apps/sling/servlet/errorhandler

오버레이 overlays

오버레이는 기본 제공 AEM 기능을 확장하거나 대체하는 데 자주 사용되지만, 오버레이를 사용하면 전체 AEM 애플리케이션에 영향을 줍니다(즉, 모든 테넌트에 대해 오버레이된 기능 변경을 사용할 수 있음). 이는 임차인들이 오버레이에 대한 상이한 요건들을 갖는 경우 더 복잡할 것이다. 비즈니스 그룹은 AEM의 관리 콘솔의 기능과 모양에 대해 합의하기 위해 함께 협력해야 합니다.

다양한 사업부 간에 합의가 이루어지지 않을 경우, 가능한 해결책은 단순히 오버레이를 사용하지 않는 것입니다. 대신 기능의 사용자 지정 복사본을 만들고 각 테넌트에 대해 다른 경로를 통해 노출합니다. 이렇게 하면 각 테넌트가 완전히 다른 사용자 경험을 가질 수 있지만, 이 접근 방식은 구현 및 후속 업그레이드 시의 비용도 증가시킵니다.

워크플로 런처 workflow-launchers

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

Vanity URL vanity-urls

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

구성 요소 그룹 component-groups

여러 작성 그룹에 대한 구성 요소 및 템플릿을 개발할 때는 componentGroup 및 allowedPaths 속성을 효과적으로 사용하는 것이 중요합니다. 이를 사이트 디자인과 함께 효과적으로 활용함으로써 Brand A의 작성자는 해당 사이트에 대해 만들어진 구성 요소와 템플릿만 볼 수 있고 Brand B의 작성자는 해당 구성 요소와 템플릿만 볼 수 있습니다.

테스트 testing

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

운영 고려 사항 operational-considerations

공유 리소스 shared-resources

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

공연 performance

AEM 모범 사례를 따르지 않을 경우 정상으로 간주되는 것 이상의 리소스를 사용하는 애플리케이션을 개발할 수 있습니다. 이러한 예로는 많은 수의 대량 워크플로우 작업(예: DAM 자산 업데이트) 트리거, 많은 노드에 대한 MSM 푸시-온-수정 작업 사용 또는 고가의 JCR 쿼리를 사용하여 콘텐츠를 실시간으로 렌더링하는 작업이 있습니다. 이는 필연적으로 다른 테넌트 애플리케이션의 성능에 영향을 미칠 것이다.

로깅 logging

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

백업 및 복원 backup-and-restore

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

보안 고려 사항 security-considerations

ACL acls

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