디스패처 캐시 최적화

개요

이 문서는 AEM 디스패처의 최신 최적화 및 이를 가장 잘 활용하는 방법에 중점을 둡니다.  AEM 디스패처는 Adobe Experience Manager와 함께 사용하도록 설계된 캐싱 역방향 프록시 서버로서,  기존 웹 서버 소프트웨어 내에서 모듈로 설치 및 실행할 수 있습니다.  이 문서를 작성하는 시점에는 Apache HTTP Server, Microsoft IIS 및 iPlanet에서 디스패처 모듈이 지원됩니다.

디스패처 캐싱의 작동 방식

가장 기본적인 수준에서 AEM 디스패처는 캐싱, 캐시 플러시 및 캐시 무효화를 수행하여 작동하는 역방향 프록시입니다.  

디스패처에 대한 자세한 내용은 관련 링크를 참조하십시오.

  1. 디스패처의 작동 방식 및 설치 방법.
  2. 디스패처에서 사용 가능한 구성 옵션.
  3. 디스패처의 작동 방식에 대한 웨비나 - 프레젠테이션의 일부 정보는 이전 버전의 디스패처를 기반으로 합니다.
  4. 디스패처 기능, CDN 사용 및 보안에 대한 Gems 웨비나 세션.
  5. 디스패처의 최신 기능에 대한 Gems 세션(v4.1.9 이후).

디스패처 캐시 최적화

다음은 디스패처 캐시를 최적화하는 몇 가지 방법입니다.

  1. 거의 모든 것을 캐싱 - 이는 사용자가 두 번 이상 요청하는 모든 컨텐츠를 캐싱함을 의미합니다.
  2. 다양한 기간 동안 개인화된 컨텐츠 캐싱 - 사이트에 개인화된 컨텐츠가 있다면 AEM 애플리케이션에서 Apache Sling Dynamic Include로 Ajax(브라우저 수준의 비동기 JavaScript 및 XML 호출), SSI(웹 서버 수준의 서버측 Include) 및 ESI(CDN 수준의 에지측 Include)를 활용하여 다양한 기간 동안 페이지의 다양한 부분을 캐싱하는 것을 고려해 보십시오.
  3. 라이브 디스패처에서 디스패처 캐시를 절대로 삭제하지 않음 - 디스패처가 라이브 컨텐츠를 제공하고 있는데 캐시를 삭제하면 대량의 요청이 AEM으로 되돌아갑니다.  이로 인해 디스패처 캐시가 라이브 디스패처에서 절대 삭제되지 않아야 합니다.
  4. 캐시 프라이밍 - 디스패처 캐시를 삭제하기 전에 디스패처를 로드 밸런서에서 꺼내고 캐시를 삭제한 다음, 웹 크롤러 도구를 실행하여 디스패처에서 파일을 캐싱한 후 로드 밸런서에 배치하십시오. 
  5. 오류 페이지 캐싱 - DispatcherPassError 1(Apache Web Server 특정) 지시문을 활용하여 디스패처 캐시에서 404와 같은 오류 페이지를 제공하십시오.
  6. 사전 압축된 파일을 제외한 모든 파일 유형을 GZip으로 압축 - Apache Web Server에서 mod_deflate를 사용할 수는 있지만 Vary: User-Agent 헤더가 설정되어 있지 않은지 확인하십시오.  Microsoft IIS에서는 동적 압축을 사용하십시오.
    Apache 구성 예(사전 압축된 파일 유형을 피하기 위해 특정 컨텐츠 유형만 지정):
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
  7. /cache 구성에서 /serveStaleOnError 활성화 - AEM 인스턴스가 오류를 제공할 때 이전 캐시 파일을 제공합니다.
  8. /cache 구성에 /gracePeriod 추가 - 마지막 컨텐츠 게시 이벤트("활성화") 후에 오래된 자동 무효화된 리소스가 여전히 캐시에서 제공될 수있는 시간(초)을 정의하십시오.이렇게 하면 "트리 활성화"와 같은 대규모 컨텐츠 게시 활동 중에 게시 인스턴스로 돌아가는 요청 수가 줄어듭니다.
  9. /ignoreUrlParams에 규칙 추가 - 애플리케이션에 필요하지 않거나 사용되지 않는 querystring 매개 변수를 무시하십시오.  이렇게 하면 querystring이 있는 경우에도 URL을 캐싱할 수 있습니다.
  10. Cache-Control 및 Last-Modified 응답 헤더 캐싱 - /headers 구성을 사용하여 HTTP 응답 헤더 Cache-ControlLast-Modified(및/또는 AEM에서 보내는 경우 ETag 헤더)를 캐싱하십시오.  이것은 CDN 및 브라우저 수준의 캐싱을 단순화하고 최적화하는 데 도움이 됩니다.  이러한 헤더를 캐싱하면 웹 서버 자체가 아닌 AEM만 헤더를 설정합니다.  이 작업을 수행한 다음에는 AEM 애플리케이션으로부터 헤더 전송을 시작해야 합니다.
  11. 가능한 한 오랫동안 컨텐츠를 캐싱하고 AEM으로 돌아가는 요청을 줄임 - 모든 플러시 에이전트에서 다시 가져오기(refetching) 플러시를 활성화하여 플러시 요청을 최적화하십시오.  또는 /enableTTL을 사용하고 파일을 가능한 한 오래 캐싱하도록 Cache-Control: max-age=... 헤더를 설정합니다.  이 주제에 대한 자세한 내용은 아래를 참조하십시오.

TTL 사용

Dispatcher 버전 4.1.11부터 .any 파일 구성에서 /enableTTL 1을 설정할 수 있습니다.  이 설정은 디스패처가 HTTP Cache-Control 응답 헤더에 설정된 캐시 만료를 준수하도록 합니다.  다시 말해, 디스패처는 파일이 만료될 때 기본 형태의 캐시 무효화가 발생하는 CDN과 유사하게 작동하게 됩니다.  이를 구현하고 AEM의 모든 응답에 대해 Cache-Control: max-age=...를 보내기 시작하면 게시 인스턴스에서 디스패처 플러시 에이전트를 안전하게 비활성화할 수 있습니다.

게시 인스턴스에서 플러시 에이전트를 비활성화한 후에도 여전히 디스패처 캐시를 플러시할 수 있습니다.  이 경우 ACS Commons - Dispatcher Flush UI를 사용할 수 있습니다.  이 도구는 작성자 인스턴스에 설치되며,  사용자에게 수동 캐시 플러시 요청을 수행할 수 있는 UI를 제공합니다.

I. TTL("Time to Live" 또는 만료) 스타일 무효화를 활성화하는 단계:

  1. AEM 애플리케이션에서 소스 코드를 수정하여 이것이 아직 설정되지 않은 모든 요청에 대해 Cache-Control 헤더 및 Last-Modified를 보냅니다.
  2. Dispatcher 4.1.11 이상을 설치합니다.
  3. 사이트의 .any 팜 구성에서 /enableTTL 1을 설정합니다.
  4. Cache-ControlLast-Modified 헤더를 캐싱하도록 /headers 구성을 설정합니다.
  5. 웹 서버를 다시 시작합니다.

II. 게시 인스턴스에서 디스패처 플러시 에이전트 비활성화:

디스패처가 이제 Cache-Control 헤더를 사용하여 캐시 파일의 무효화를 제어합니다.  따라서 게시 인스턴스의 디스패처 플러시가 더 이상 필요하지 않습니다.

  1. 각 게시 인스턴스에서 /etc/replication/agents.publish.html로 이동합니다.
  2. 각 플러시 에이전트의 구성으로 이동하여 에이전트를 비활성화합니다.

III. 작성자 인스턴스의 수동 디스패처 플러시 요청 허용:

플러시 에이전트가 비활성화되었으므로 이제 Cache-Control 헤더에 전적으로 의존하여 디스패처에서 컨텐츠를 새로 고치는 시기를 제어하게 됩니다.  여전히 여러분은 사용자가 디스패처 캐시를 수동으로 플러시하도록 허용할 수 있습니다.

  1. 작성자 인스턴스에서 ACS Commons - Dispatcher Flush UI를 설치합니다.
  2. 작성자 인스턴스에서 플러시 에이전트를 구성합니다.
  3. 각 에이전트 구성에서 Triggers => Ignore Default 옵션을 enabled로 설정합니다. 이 옵션은 사용자가 AEM UI에서 게시( 취소) 또는 (비)활성화를 클릭하면 플러시 에이전트가 무시하도록 합니다.

디스패처 플러시 다시 가져오기

디스패처 플러시 요청을 최적화하려면 모든 디스패처 플러시 에이전트에 다시 가져오기(refetching) 플러시라는 기능이 활성화되어 있어야 합니다.

디스패처 플러시를 다시 가져오려면 다음을 수행하십시오.

  1. http://aemhost:port/crx/packmgr/index.jsp로 이동하여 관리자로 로그인합니다.
  2. 여기에서 패키지를 다운로드합니다.
  3. 패키지를 패키지 관리자에 업로드하고 설치합니다.
  4. 디스패처 플러시 에이전트 구성으로 이동합니다. 예: /etc/replication/agents.author/flush.html
  5. 편집을 클릭합니다.
  6. 다음을 설정합니다.
    • 직렬화 유형 = 디스패처 플러시 다시 가져오기
    • 확장됨 => HTTP 메서드 = POST
  7. 저장을 클릭합니다.

위에 설치된 패키지는 기본 예일 뿐입니다.  플러시 다시 가져오기를 사용자 지정하고 최적화하기 위해, 전송되는 URI 목록을 수정할 수 있습니다.  코드는 오픈 소스이며 여기에서 찾을 수 있습니다.  이 코드는 디스패처에게 다시 가져올 경로를 알려주는 매개 변수로서 URI 목록을 요청 본문에 추가합니다.  사이트의 캐싱 기능을 최적화하기 위해 애플리케이션 요구 사항에 따라 더 많은 경로를 추가할 수 있습니다.

플러시 다시 가져오기에 대한 자세한 설명

일반적으로 디스패처 플러시는 파일을 삭제하여 작동합니다.

  1. .stat 파일 터치
  2. /content/foo 삭제.*
  3. /content/foo/_jcr_content 삭제

2단계에서 파일이 삭제되었다는 사실로 인해 다음에 사용자가 /content/foo.html 또는 /content/foo.json과 같은 파일을 요청하면 파일을 "다시 가져올" 때 동일한 파일에 대한 후속 요청도 파일이 캐싱되기 전까지 이 게시 인스턴스에 전송됩니다.  이로 인해 응답 속도가 느리거나 홈 페이지와 같이 트래픽이 많은 페이지의 경우 게시 인스턴스 계층이 넘칠 수 있습니다.

이 문제를 해결하려면 다시 가져오기(re-fetching)라는 디스패처의 기능을 사용하십시오.  이 기능을 사용하면 디스패처가 삭제하는 대신 사전에 "다시 가져와서" 바꿔야 하는 URI 목록을 보낼 수 있습니다.

작동 방식 및 구성 방법에 대한 데모는 이 프레젠테이션 기록의 22:41-27:05를 참조하십시오.

Adobe 로고

내 계정 로그인