2장 - 인프라

캐싱 인프라 설정

이 시리즈의 1장에 Publish 시스템과 Dispatcher의 기본 토폴로지가 소개되었습니다. Publish 및 Dispatcher 서버 세트는 예상 로드, 데이터 센터의 토폴로지 및 원하는 페일오버 속성에 따라 다양한 방식으로 구성할 수 있습니다.

우리는 가장 일반적인 토폴로지를 스케치하고 장점과 부족한 부분을 설명할 것이다. 물론 그 목록은 결코 포괄적일 수 없다. 유일한 한계는 상상력이다.

"레거시" 설정

초기에는 잠재적 방문자의 수가 적고 하드웨어가 비싸며 웹 서버가 현재와 같이 비즈니스에 중요한 요인으로 간주되지 않았습니다. 일반적인 설정은 한 개의 Dispatcher이 둘 이상의 Publish 시스템 앞에 로드 밸런서 및 캐시 역할을 하는 것이었습니다. Dispatcher의 핵심에 있는 Apache 서버는 매우 안정적이었고 대부분의 설정에서 상당한 양의 요청을 처리할 수 있을 만큼 능력이 있었습니다.

"레거시" Dispatcher 설정 - 오늘의 표준에서는 흔하지 않습니다

여기에서 Dispatcher가 이름을 받았습니다. 기본적으로 요청을 발송하는 것입니다. 현재 필요한 성능 및 안정성의 높은 요구를 충족할 수 없으므로 이 설정은 더 이상 흔하지 않습니다.

다발 설치

현재는 약간 다른 토폴로지가 더 일반적입니다. 다중 레그 토폴로지에는 Publish 서버당 하나의 Dispatcher이 있습니다. 전용(하드웨어) 로드 밸런서는 AEM 인프라 앞에 위치하며 다음 두 개 이상의 레그에 요청을 전달합니다.

최신 "표준" Dispatcher 설정 - 처리 및 유지 관리가 쉬움

이러한 설정의 이유는 다음과 같습니다.

"확장" 설정

Apache 서버는 저렴하고 프로비저닝이 쉬우므로 해당 수준을 조금 더 확장해 보십시오. 각 Publish 서버 앞에 Dispatcher가 두 개 이상 없는 이유는 무엇입니까?

"Scale Out" 설정 - 일부 응용 프로그램 영역이 있지만 제한 사항 및 주의 사항도 있습니다.

그렇게 하셔도 됩니다! 그리고 그 설정에 대한 많은 유효한 응용 시나리오가 있습니다. 그러나 당신이 고려해야 할 몇 가지 제한과 복잡성도 있습니다.

무효화

각 Publish 시스템은 여러 Dispatcher에 연결되며 콘텐츠가 변경되면 각 시스템을 무효화해야 합니다.

유지 관리

Dispatcher 및 Publish 시스템의 초기 구성이 조금 더 복잡함은 물론이다. 그러나 "롤링" 릴리스의 노력도 약간 더 높다는 점을 명심하십시오. AEM 시스템은 실행 중에 업데이트할 수 있으며 업데이트해야 합니다. 하지만 적극적으로 요청을 들어주면서 하지 않는 것이 현명합니다. 일반적으로 Publish 시스템의 일부만 업데이트하고 다른 시스템은 여전히 능동적으로 트래픽을 처리하고 테스트 후 다른 부분으로 전환하려는 경우가 있습니다. 운이 좋으며 배포 프로세스에서 로드 밸런서에 액세스할 수 있는 경우 여기에서 유지 관리 중인 서버에 대한 라우팅을 비활성화할 수 있습니다. 직접 액세스 권한 없이 공유 로드 밸런서를 사용하는 경우에는 업데이트하려는 Publish의 Dispatcher를 종료하는 것이 좋습니다. 많으면 많을수록 당신은 더 많은 문을 닫아야 할 것이다. 숫자가 많고 자주 업데이트를 계획하는 경우 일부 자동화가 권장됩니다. 자동화 도구가 없다면 어차피 확장을 하는 것은 좋지 않은 생각입니다.

과거 프로젝트에서 다른 트릭을 사용하여 로드 밸런서 자체에 직접 액세스하지 않고 로드 밸런서에서 Publish 시스템을 제거했습니다.

로드 밸런서는 일반적으로 "ping", 서버가 실행 중인지 확인하는 특정 페이지입니다. 보통 사소한 선택은 홈페이지에 ping을 하는 것입니다. 하지만 ping을 사용하여 로드 밸런서에 신호를 보내 트래픽 균형을 조절하지 않으려면 다른 옵션을 선택해야 합니다. 본문에서 또는 http 응답 코드로 "up" 또는 "down"(으)로 응답하도록 구성할 수 있는 전용 템플릿 또는 서블릿을 만듭니다. 해당 페이지의 응답은 Dispatcher에서 캐시되지 않아야 합니다. 따라서 항상 Publish 시스템에서 새로 가져옵니다. 이제 이 템플릿이나 서블릿을 확인하도록 로드 밸런서를 구성하는 경우 Publish이 다운된 것처럼 "가장할" 수 있습니다. 로드 밸런싱의 일부가 아니며 업데이트할 수 있습니다.

전 세계 배포

"Worldwide Distribution"은 각 Publish 시스템 앞에 여러 Dispatcher가 있는 "규모 확장" 설정으로서, 이제 고객에게 더 가깝고 더 나은 성능을 제공하기 위해 전 세계에 배포됩니다. 물론 이 시나리오에는 중앙 로드 밸런서가 없지만 DNS 및 지역 IP 기반 로드 밸런싱 체계가 있습니다.

수평 크기 조절

로컬 데이터 센터에서도 각 Publish 시스템 앞에 여러 Dispatcher가 있는 "Scale Out" 토폴로지가 일부 이점이 있습니다. 높은 트래픽(및 양호한 캐시 적중률)으로 인해 Apache 서버에서 성능 병목 현상이 발생하고 더 이상 하드웨어를 확장할 수 없는 경우(CPU, RAM 및 더 빠른 디스크 추가) Dispatcher를 추가하여 성능을 높일 수 있습니다. 이를 "수평 크기 조정"이라고 합니다. 그러나 여기에는 제한이 있습니다(특히 트래픽을 자주 무효화하는 경우). 그 효과를 다음 절에서 설명하겠다.

확장 토폴로지의 제한

프록시 서버를 추가하면 일반적으로 성능이 향상됩니다. 그러나 실제로 서버를 추가하면 성능이 저하될 수 있는 시나리오가 있습니다. 어떻게? 매분마다 새로운 기사와 페이지를 소개하는 뉴스 포털이 있다고 가정해 보겠습니다. Dispatcher은 "자동 무효화"에 의해 무효화됩니다. 페이지가 게시될 때마다 동일한 사이트의 캐시에 있는 모든 페이지가 무효화됩니다. 이는 유용한 기능입니다. 이 시리즈의 챕터 1에서 다루었지만 웹 사이트에서 변경 내용이 자주 있으면 캐시를 무효화하는 경우가 많습니다. Publish 인스턴스당 하나의 Dispatcher만 있는 경우 페이지를 요청하는 첫 번째 방문자가 해당 페이지의 재캐싱을 트리거합니다. 두 번째 방문자는 이미 캐시된 버전을 가져옵니다.

두 개의 Dispatcher가 있는 경우 두 번째 방문자는 페이지가 캐시되지 않을 확률이 50%이며 그런 다음 해당 페이지가 다시 렌더링될 때 지연이 더 커집니다. Publish당 더 많은 Dispatcher가 있으면 상황이 더욱 악화됩니다. 이때 각 Publish에 대한 페이지를 별도로 다시 렌더링해야 하므로 Dispatcher 서버가 더 많은 로드를 받습니다.

캐시가 자주 플러시되는 규모 확장 시나리오의 성능이 저하되었습니다.

과도한 확장 문제 완화

문제를 완화하기 위해 모든 Dispatcher에 대해 중앙 공유 스토리지를 사용하거나 Apache 서버의 파일 시스템을 동기화할 수 있습니다. 우리는 제한된 직접 경험만 제공할 수 있지만, 이것이 시스템의 복잡성을 가중시키고 완전히 새로운 종류의 오류를 도입할 수 있도록 준비할 수 있다.

NFS에 대한 몇 가지 실험이 있었지만 NFS는 콘텐츠 잠금으로 인해 막대한 성능 문제를 초래했습니다. 이것은 실제로 전반적인 성능을 감소시켰습니다.

결론 - 여러 디스패처 간에 공통 파일 시스템을 공유하는 것은 권장되지 않는 방법입니다.

성능 문제가 발생하면 게시자 인스턴스에서 최대 로드를 방지하기 위해 Publish 및 Dispatcher를 동일하게 확장하십시오. Publish/Dispatcher 비율에 대한 골든 규칙은 없습니다. 이는 요청 분포 및 게시 및 캐시 무효화 빈도에 따라 크게 달라집니다.

방문자가 경험하는 지연 시간이 걱정되는 경우 이 시리즈의 Chapter 1에 설명된 대로 콘텐츠 전달 네트워크 사용, 캐시 다시 가져오기, 선제적 캐시 준비, 유예 시간 설정 또는 Part 3의 일부 고급 아이디어를 참조하십시오.

"교차 연결됨" 설정

가끔 볼 수 있는 또 다른 설정은 "교차 연결" 설정입니다. Publish 인스턴스에는 전용 Dispatcher가 없지만 모든 Dispatcher는 모든 Publish 시스템에 연결됩니다.

교차 연결 토폴로지: 중복성이 증가하고 복잡성이 증가합니다.

이는 얼핏 보기에는 비교적 적은 예산에 대해 좀 더 많은 중복성을 제공한다. Apache 서버 중 하나가 중지되어도 두 대의 Publish 시스템에서 렌더링 작업을 수행할 수 있습니다. 또한 Publish 시스템 중 하나가 충돌해도 캐시된 로드를 제공하는 Dispatcher가 두 개 있습니다.

그러나 이것은 대가와 함께 제공됩니다.

첫째, 정비를 위해 한쪽 다리를 빼는 것은 상당히 번거롭다. 사실, 이것이 이 계획이 고안된 목적입니다; 더 탄력적이고 가능한 모든 방법으로 기운을 유지하세요. 우리는 이것을 다루는 방법에 관한 복잡한 유지 보수 계획을 보아 왔습니다. 먼저 교차 연결을 제거하여 Dispatcher 2를 다시 구성합니다. Dispatcher 2 다시 시작 Dispatcher 1을 종료하고 Publish 1을 업데이트하는 중… 등. 다리가 두 개 이상 늘어날 수 있는지 신중히 생각해야 한다. 결론에 도달하게 될 것입니다. 그것은 실제로 복잡성과 비용을 증가시키고 인간의 실수에 대한 가공할 원천입니다. 이를 자동화하는 것이 가장 좋습니다. 따라서 프로젝트 일정에 이 자동화 작업을 포함할 인력이 실제로 있는지 확인하는 것이 좋습니다. 이를 통해 하드웨어 비용을 절약할 수 있지만 IT 직원에게 두 배의 비용을 지출할 수 있습니다.

둘째, AEM에서 로그인이 필요한 일부 사용자 애플리케이션이 실행되고 있을 수 있습니다. 고정 세션을 사용하여 한 사용자가 항상 동일한 AEM 인스턴스에서 제공되도록 하여 해당 인스턴스에 대한 세션 상태를 유지할 수 있습니다. 이러한 교차 연결 설정을 사용하면 고정 세션이 로드 밸런서와 디스패처에서 제대로 작동하는지 확인해야 합니다. 불가능한 것은 아니지만, 이를 인식하고 추가 구성 및 테스트 시간을 추가해야 합니다. 이는 다시 한 번 하드웨어를 절약하여 계획된 절감 효과를 높일 수 있습니다.

결론

이 교차 연결 구성표를 기본 옵션으로 사용하는 것은 권장되지 않습니다. 그러나 이를 사용하기로 결정한 경우 위험과 숨겨진 비용을 신중하게 평가하고 구성 자동화를 프로젝트의 일부로 포함시킬 계획입니다.

다음 단계