웹사이트 검색

Ubuntu 14.04에서 Apache 콘텐츠 캐싱을 구성하는 방법

캐싱이란 무엇입니까?

캐싱은 일반적으로 요청되는 콘텐츠를 더 빠르게 액세스할 수 있는 방식으로 일시적으로 저장할 수 있도록 하여 서버 성능을 향상시키는 방법입니다. 이렇게 하면 일부 리소스 집약적인 작업을 제거하여 처리 및 전달 속도를 높일 수 있습니다.

효과적인 캐싱 규칙을 생성하여 캐싱에 적합한 콘텐츠를 저장하여 응답 시간을 개선하고 리소스를 절약하며 부하를 최소화합니다. Apache는 다양한 유형의 작업 속도를 높이는 데 적합한 다양한 캐시를 제공합니다. 이 가이드에서는 다양한 캐싱 모듈을 사용하여 Ubuntu 14.04에서 Apache 2.4를 구성하는 방법에 대해 설명합니다.

일반 캐싱 전략 개발에 대해 자세히 알아보려면 이 기사를 확인하세요.

Apache의 캐싱 소개

Apache는 다양한 수준의 정교함과 확장성으로 콘텐츠를 캐시할 수 있습니다. 프로젝트는 콘텐츠가 캐시되는 방법에 따라 이들을 세 그룹으로 나눕니다. 일반적인 분석은 다음과 같습니다.

  • 파일 캐싱: 가장 기본적인 캐싱 전략으로, 서버가 시작될 때 단순히 파일이나 파일 설명자를 열고 액세스 속도를 높이기 위해 사용 가능한 상태로 유지합니다.
  • 키-값 캐싱: 주로 SSL 및 인증 캐싱에 사용되는 키-값 캐싱은 반복적으로 계산하는 데 비용이 많이 드는 항목을 저장할 수 있는 공유 개체 모델을 사용합니다.
  • 표준 HTTP 캐싱: 가장 유연하고 일반적으로 유용한 캐싱 메커니즘인 이 3가지 상태 시스템은 응답을 저장하고 만료 시 유효성을 검사할 수 있습니다. 특정 요구 사항에 따라 성능 또는 유연성을 위해 구성할 수 있습니다.

위의 설명을 간단히 살펴보면 위의 방법이 일부 겹치는 부분이 있지만 동시에 둘 이상의 전략을 사용하는 것이 도움이 될 수 있음을 알 수 있습니다. 예를 들어 SSL 세션에 대한 키-값 저장소를 사용하고 응답에 대한 표준 HTTP 캐시를 활성화하면 데이터 소스의 상당한 부하를 줄이고 클라이언트에 대한 많은 콘텐츠 전달 작업의 속도를 높일 수 있습니다.

이제 각 Apache의 캐싱 메커니즘에 대해 폭넓게 이해했으므로 이러한 시스템을 자세히 살펴보겠습니다.

파일 캐싱

일반 개요

  • 관련 기본 모듈: mod_file_cache
  • 주요 사용 사례: 서버가 시작될 때 파일 내용 또는 파일 설명자를 저장합니다. 이는 서버를 다시 시작할 때까지 안정적으로 변경할 수 없는 정적 표현입니다.
  • 기능: 단순함, 느린 파일 시스템의 성능 향상
  • 단점: 실험적 기능, 파일 시스템의 업데이트에 응답하지 않음, 운영 체제의 제한에 맞게 아껴서 사용해야 함, 정적 파일에서만 사용할 수 있음

세부사항

mod_file_cache 모듈은 주로 파일 시스템이 느린 서버에서 파일 액세스 속도를 높이는 데 사용됩니다. 두 가지 구성 지시문 중 하나를 선택할 수 있으며, 둘 다 파일이 요청될 때가 아니라 서버가 시작될 때 일부 작업을 수행하여 정적 파일을 제공하는 프로세스를 가속화하는 것을 목표로 합니다.

CacheFile 지시문은 액세스를 가속화하려는 디스크의 파일 경로를 지정하는 데 사용됩니다. Apache가 시작되면 Apache는 지정된 정적 파일을 열고 파일 핸들을 캐시하므로 요청 시 파일을 열 필요가 없습니다. 이 방법으로 열 수 있는 파일 수는 운영 체제에서 설정한 제한에 따릅니다.

MMapFile 지시문은 Apache가 처음 시작될 때 파일도 엽니다. 그러나 MMapFile은 파일 핸들러가 아닌 파일의 내용을 메모리에 캐시합니다. 이렇게 하면 해당 페이지의 성능이 더 빨라지지만 몇 가지 심각한 제한이 있습니다. 사용한 메모리 양에 대한 기록을 유지하지 않으므로 메모리가 부족할 수 있습니다. 또한 하위 프로세스는 할당된 메모리를 복사하므로 초기에 예상했던 것보다 더 빠른 리소스 고갈이 발생할 수 있습니다. 이 지시어는 드물게 사용하십시오.

이러한 지시문은 Apache가 시작될 때만 평가됩니다. 이는 Apache가 시작된 후 변경 사항을 선택하는 데 Apache에 의존할 수 없음을 의미합니다. Apache 세션의 수명 동안 변경되지 않는 정적 파일에만 사용하십시오. 파일 수정 방법에 따라 서버에 변경 사항을 알릴 수 있지만 이는 예상된 동작이 아니며 항상 올바르게 작동하는 것은 아닙니다. 이러한 지시문에 전달된 파일을 변경해야 하는 경우 변경을 수행한 후 Apache를 다시 시작하십시오.

파일 캐싱을 활성화하는 방법

파일 캐싱은 mod_file_cache 모듈에서 제공합니다. 이 기능을 사용하려면 모듈을 활성화해야 합니다.

Ubuntu 14.04를 실행할 때 모듈이 설치되지만 Apache를 설치할 때 비활성화됩니다. 다음을 입력하여 모듈을 활성화할 수 있습니다.

  1. sudo a2enmod file_cache

그런 다음 기본 구성 파일을 편집하여 파일 캐싱 지시문을 설정해야 합니다. 다음을 입력하여 파일을 엽니다.

  1. sudo nano /etc/apache2/apache2.conf

파일 핸들 캐싱을 설정하려면 CacheFile 지시문을 사용하십시오. 이 지시문은 다음과 같이 공백으로 구분된 파일 경로 목록을 사용합니다.

CacheFile /var/www/html/index.html /var/www/html/somefile.index

서버가 다시 시작되면 Apache는 나열된 파일을 열고 빠른 액세스를 위해 파일 핸들을 캐시에 저장합니다.

대신 몇 개의 파일을 메모리에 직접 매핑하려는 경우 MMapFile 지시문을 사용할 수 있습니다. 구문은 기본적으로 마지막 지시문과 동일하며 단순히 파일 경로 목록을 취합니다.

MMapFile /var/www/html/index.html /var/www/html/somefile.index

실제로 동일한 파일 집합에 대해 둘 다 CacheFile 및 MMapFile을 구성할 이유가 없지만 서로 다른 집합에서 둘 다 사용할 수 있습니다. 파일의.

완료되면 파일을 저장하고 닫을 수 있습니다. 다음을 입력하여 구성 파일 구문을 확인하십시오.

  1. sudo apachectl configtest

마지막 줄에 Syntax OK가 표시되면 Apache 인스턴스를 안전하게 다시 시작할 수 있습니다.

  1. sudo service apache2 restart

Apache가 다시 시작되어 사용한 지시문에 따라 파일 내용 또는 핸들러를 캐싱합니다.

키-값 캐싱

일반 개요

  • 관련 기본 모듈: mod_socache_dbm, mod_socache_dc, mod_socache_memcache, mod_socache_shmcb
  • 관련 지원 모듈: mod_authn_socache, mod_ssl
  • 주요 사용 사례: SSL 세션 또는 인증 세부 정보 저장, SSL 스테이플링
  • 특징: 복잡한 리소스를 저장하기 위한 공유 개체 캐시, SSL 세션 캐싱 및 스테이플링 지원, 유연한 백엔드
  • 단점: 유효성 검사 메커니즘이 없으며 더 성능/유연한 백엔드를 위해 별도의 소프트웨어를 구성해야 함, 코드의 일부 버그

세부사항

키-값 캐싱은 파일 캐싱보다 복잡하며 더 많은 이점이 있습니다. 공유 개체 캐시라고도 하는 Apache의 키-값 캐시는 주로 콘텐츠 자체가 아닌 콘텐츠에 대한 클라이언트의 액세스 설정과 관련된 비용이 많이 드는 작업을 반복하지 않도록 하는 데 사용됩니다. 특히 인증 세부 정보, SSL 세션을 캐시하고 SSL 스테이플링을 제공하는 데 사용할 수 있습니다.

현재 모든 공유 개체 캐시 공급자에 몇 가지 문제가 있습니다. 문제에 대한 참조는 아래에 요약되어 있습니다. 이 기능을 활성화할지 여부를 평가할 때 이러한 사항을 고려하십시오.

실제 캐싱은 공유 개체 캐싱 공급자 모듈 중 하나를 사용하여 수행됩니다. 이것들은:

  • mod_socache_dbm: 이 백엔드는 해싱 및 고정 크기 버킷을 사용하는 파일 기반 키-값 저장소인 간단한 dbm 데이터베이스 엔진을 사용합니다. 이 공급자는 약간의 메모리 누수가 발생하므로 대부분의 경우 mod_socache_shmcb를 대신 사용하는 것이 좋습니다.
  • mod_socache_dc: 이 공급자는 distcache 세션 캐싱 소프트웨어를 사용합니다. 이 프로젝트는 2004년 이후로 업데이트되지 않았으며 일부 배포판에 대해서도 패키지화되지 않았으므로 신중하게 사용하십시오.
  • mod_socache_memcache: 항목을 저장하기 위해 memcache 분산 메모리 개체 캐시를 사용합니다. 이것은 여러 서버 간의 분산 캐시에 가장 적합한 옵션입니다. 현재 항목이 제대로 만료되지 않지만 문제를 해결하는 패치가 Apache의 버전 제어 트렁크에 커밋되었습니다.
  • mod_socache_shmcb: 현재 키-값 캐싱을 위한 최상의 옵션입니다. 이는 공유 메모리의 순환 버퍼에 캐시되며 가득 차면 항목을 제거합니다. 현재 크기가 11k를 초과하는 항목에서 질식합니다.

위의 공급자 모듈과 함께 캐시되는 개체에 따라 추가 모듈이 필요합니다. 예를 들어 SSL 세션을 캐시하거나 SSL 스테이플링을 구성하려면 mod_ssl을 활성화해야 합니다. 그러면 SSLSessionCache 및 SSLStaplingCache 지시어가 각각 제공됩니다. 마찬가지로 인증 캐싱을 설정하려면 AuthnCacheSOCache 지시문을 설정할 수 있도록 mod_authn_socache 모듈을 활성화해야 합니다.

키-값 캐싱을 활성화하는 방법

위의 버그와 주의 사항을 염두에 두고 Apache에서 이러한 유형의 캐싱을 구성하려면 아래를 따르십시오.

키-값 캐시를 설정하는 데 사용되는 방법은 사용 대상과 사용 중인 공급자에 따라 다릅니다. 아래에서 인증 캐싱과 SSL 세션 캐싱의 기본 사항을 살펴보겠습니다.

현재 캐시 공급자에 대한 인수 전달을 방지하는 인증 캐싱 버그가 있습니다. 따라서 대체할 기본 설정을 제공하지 않는 공급자는 문제가 있습니다.

인증 캐싱

인증 캐싱은 LDAP 또는 데이터베이스 인증과 같은 값비싼 인증 방법을 사용하는 경우에 유용합니다. 이러한 유형의 작업은 인증 요청이 이루어질 때마다 백엔드를 적중해야 하는 경우 성능에 상당한 영향을 미칠 수 있습니다.

캐싱 설정에는 기존 인증 구성 수정이 포함됩니다(이 가이드에서는 인증 설정 방법을 다루지 않음). 수정 자체는 백엔드 인증 방법에 관계없이 거의 동일합니다. 데모에는 mod_socache_shmcb를 사용할 것입니다.

먼저 다음을 입력하여 authn_socache 모듈과 mod_socache_shmcb 공급자 모듈을 활성화합니다.

  1. sudo a2enmod authn_socache

  2. sudo a2enmod socache_shmcb

인증에 사용할 이 공유 캐시 백엔드를 지정할 수 있도록 기본 Apache 구성 파일을 엽니다.

  1. sudo nano /etc/apache2/apache2.conf

내부에서 파일 위쪽으로 AuthnCacheSOCache 지시문을 추가합니다. shmcb를 공급자로 사용하도록 지정합니다. 앞에서 논의한 옵션 전달 방지 버그가 이 글을 읽을 때 수정되면 캐시의 위치와 크기를 지정할 수 있습니다. 숫자는 바이트 단위이므로 주석이 달린 예제는 512KB 캐시가 됩니다.

AuthnCacheSOCache shmcb

# If the bug preventing passed arguments to the provider gets fixed,
# you can customize the location and size like this
#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

완료되면 파일을 저장하고 닫습니다.

그런 다음 인증이 구성된 가상 호스트 구성 페이지를 엽니다. 000-default.conf 가상 호스트 구성을 사용한다고 가정하지만 환경을 반영하도록 수정해야 합니다.

  1. sudo nano /etc/apache2/sites-enabled/000-default.conf

인증을 구성한 위치에서 블록을 수정하여 캐싱을 추가합니다. 특히 AuthnCacheProvideFor를 추가하여 캐시할 인증 소스를 알려주고, AuthnCacheTimeout으로 캐시 시간 제한을 추가하고, socache를 AuthBasicProvider 기존 인증 방법보다 앞서 나열합니다. 결과는 다음과 같습니다.

<VirtualHost *:80>

    . . .

    <Directory /var/www/html/private>
        AuthType Basic
        AuthName "Restricted Files"
        AuthBasicProvider socache file
        AuthUserFile /etc/apache2/.htpasswd
        AuthnCacheProvideFor file
        AuthnCacheTimeout 300
        Require valid-user
    </Directory>
</VirtualHost>

위의 예는 파일 인증을 위한 것으로 캐싱의 이점이 별로 없을 것입니다. 그러나 구현은 다른 인증 방법을 사용할 때 매우 유사해야 합니다. 유일한 실질적인 차이점은 위의 예에서 "file\ 사양이 있는 경우 다른 인증 방법이 대신 사용된다는 것입니다.

파일을 저장하고 닫습니다. 캐싱 변경 사항을 구현하려면 Apache를 다시 시작하십시오.

  1. sudo service apache2 restart

SSL 세션 캐싱

SSL 연결을 설정하기 위해 수행해야 하는 핸드셰이크에는 상당한 오버헤드가 있습니다. 따라서 추가 요청에 대한 이 초기화 단계를 피하기 위해 세션 데이터를 캐싱하면 잠재적으로 이 페널티를 피할 수 있습니다. 공유 개체 캐시는 이를 위한 완벽한 장소입니다.

Apache 서버에 SSL이 이미 구성되어 있으면 mod_ssl이 활성화됩니다. Ubuntu에서 이는 ssl.conf 파일이 /etc/apache2/mods-enabled 디렉토리로 이동되었음을 의미합니다. 이것은 실제로 이미 캐싱을 설정합니다. 내부에는 다음과 같은 줄이 표시됩니다.

. . .

SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout  300

. . .

이것은 실제로 세션 캐싱을 설정하기에 충분합니다. 이를 테스트하기 위해 OpenSSL의 연결 클라이언트를 사용할 수 있습니다. 유형:

  1. openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

세션 ID가 모든 결과에서 동일하면 세션 캐시가 올바르게 작동하는 것입니다. 터미널로 돌아가려면 CTRL-C를 누르십시오.

표준 HTTP 캐싱

일반 개요

  • 관련 기본 모듈: mod_cache
  • 관련 지원 모듈: mod_cache_disk, mod_cache_socache
  • 주요 사용 사례: 일반 콘텐츠 캐싱
  • 기능: HTTP 캐싱 헤더를 올바르게 해석할 수 있고 오래된 항목을 재검증할 수 있으며 필요에 따라 최대 속도 또는 유연성을 위해 배포할 수 있습니다.
  • 단점: 잘못 구성된 경우 중요한 데이터가 유출될 수 있으며 캐싱 정책을 올바르게 설정하려면 추가 모듈을 사용해야 합니다.

세부사항

HTTP 프로토콜은 콘텐츠 전달 경로 전체에서 응답을 캐싱하기 위한 메커니즘을 권장하고 제공합니다. 콘텐츠에 접근하는 모든 컴퓨터는 콘텐츠의 출처와 컴퓨터 자체의 캐싱 규칙에 명시된 캐싱 정책에 따라 특정 시간 동안 각 항목을 잠재적으로 캐시할 수 있습니다.

Apache HTTP 캐싱 메커니즘은 표시되는 HTTP 캐싱 정책에 따라 응답을 캐싱합니다. 이것은 배달에 관여하는 중간 서버가 따르는 것과 동일한 규칙을 준수하는 범용 캐싱 시스템입니다. 이것은 이 시스템을 매우 유연하고 강력하게 만들고 콘텐츠에 이미 설정해야 하는 헤더를 활용할 수 있도록 합니다(이 작업을 수행하는 방법은 아래에서 설명합니다).

Apache의 HTTP 캐시는 "3가지 상태\ 캐시라고도 합니다. 저장한 콘텐츠가 세 가지 상태 중 하나일 수 있기 때문입니다. 최신 상태일 수 있습니다. 즉, 추가 확인 없이 클라이언트에 제공될 수 있습니다. 이는 콘텐츠의 TTL이 만료되었음을 의미하는 부실하거나 콘텐츠가 캐시에서 발견되지 않으면 존재하지 않을 수 있습니다.

콘텐츠가 오래되면 다음 요청 시 캐시가 원본에서 콘텐츠를 확인하여 유효성을 다시 검사할 수 있습니다. 변경되지 않은 경우 신선도를 재설정하고 현재 콘텐츠를 제공할 수 있습니다. 그렇지 않으면 변경된 콘텐츠를 가져오고 캐싱 정책에서 허용하는 기간 동안 저장합니다.

모듈 개요

HTTP 캐싱 논리는 mod_cache 모듈을 통해 사용할 수 있습니다. 실제 캐싱은 캐싱 공급자 중 하나와 함께 수행됩니다. 일반적으로 캐시는 mod_cache_disk 모듈을 사용하여 디스크에 저장되지만 공유 개체 캐싱은 mod_cache_socache 모듈을 통해서도 사용할 수 있습니다.

mod_cache_disk 모듈은 디스크에 캐싱하므로 원격 위치에서 콘텐츠를 프록시하거나 동적 프로세스에서 생성하거나 보다 빠른 디스크에 캐싱하여 작업 속도를 높이려는 경우 유용할 수 있습니다. 콘텐츠는 일반적으로 에 상주합니다. 이것은 가장 잘 테스트된 공급자이며 대부분의 경우 첫 번째 선택이어야 합니다. 캐시는 자동으로 정리되지 않으므로 htcacheclean이라는 도구를 가끔 실행하여 캐시를 줄여야 합니다. 수동으로 실행하거나 일반 cron 작업으로 설정하거나 데몬으로 실행할 수 있습니다.

mod_cache_socache 모듈은 공유 개체 공급자 중 하나(마지막 섹션에서 논의한 것과 동일)에 캐시합니다. 이것은 잠재적으로 mod_cache_disk보다 더 나은 성능을 가질 수 있습니다(선택된 공유 캐시 공급자에 따라 다름). 그러나 훨씬 더 새롭고 이전에 논의한 버그가 있는 공유 개체 공급자에 의존합니다. mod_cache_socache 옵션을 구현하기 전에 포괄적인 테스트가 권장됩니다.

HTTP 캐시 배치

Apache의 HTTP 캐시는 필요에 따라 두 가지 다른 구성으로 배포할 수 있습니다.

CacheQuickHandler가 "on\으로 설정되면 요청 처리 프로세스 초기에 캐시를 확인합니다. 콘텐츠가 발견되면 추가 처리 없이 바로 제공됩니다. 매우 빠르지만 콘텐츠에 대한 인증과 같은 프로세스를 허용하지 않는다는 의미도 있습니다. 캐시에 일반적으로 인증이나 액세스 제어가 필요한 콘텐츠가 있는 경우 CacheQuickHandler는 \켜짐으로 설정됩니다.

기본적으로 이것은 웹 서버 앞에 별도의 캐시를 에뮬레이트합니다. 웹 서버가 어떤 종류의 조건부 확인, 인증 또는 권한 부여를 수행해야 하는 경우에는 이런 일이 발생하지 않습니다. Apache는 또는 블록 내의 지시문도 평가하지 않습니다. CacheQuickHandler는 기본적으로 \on으로 설정되어 있습니다!

CacheQuickHandler가 "off\로 설정되어 있으면 요청 처리 시퀀스의 후반부에 캐시가 확인됩니다. 이 구성은 Apache 처리 논리와 실제 콘텐츠 사이에 캐시를 배치하는 것으로 생각하십시오. 이 구성은 캐시에서 콘텐츠를 검색하기 전에 기존의 처리 지시문을 실행할 수 있습니다. 이것을 "off\로 설정하면 요청을 더 깊이 처리할 수 있는 능력을 위해 약간의 속도를 맞바꿉니다.

표준 HTTP 캐싱을 구성하는 방법

캐싱을 활성화하려면 mod_cache 모듈과 캐싱 공급자 중 하나를 활성화해야 합니다. 위에서 언급했듯이 mod_cache_disk는 잘 테스트되었으므로 이에 의존할 것입니다.

모듈 활성화

Ubuntu 시스템에서는 다음을 입력하여 이러한 모듈을 활성화할 수 있습니다.

  1. sudo a2enmod cache

  2. sudo a2enmod cache_disk

이렇게 하면 다음에 서버를 다시 시작할 때 캐싱 기능이 활성화됩니다.

필요한 경우 캐시를 줄이는 데 사용되는 htcacheclean 유틸리티가 포함된 apache2-utils 패키지도 설치해야 합니다. 다음을 입력하여 설치할 수 있습니다.

  1. sudo apt-get update

  2. sudo apt-get install apache2-utils

글로벌 구성 수정

캐싱을 위한 대부분의 구성은 개별 가상 호스트 정의 또는 위치 블록 내에서 수행됩니다. 그러나 mod_cache_disk를 활성화하면 일부 일반 속성을 지정하는 데 사용할 수 있는 전역 구성도 활성화됩니다. 지금 해당 파일을 열어 살펴보십시오.

  1. sudo nano /etc/apache2/mods-enabled/cache_disk.conf

주석이 제거된 파일은 다음과 같아야 합니다.

<IfModule mod_cache_disk.c>
    CacheRoot /var/cache/apache2/mod_cache_disk
    CacheDirLevels 2
    CacheDirLength 1
</IfModule>

IfModule 래퍼는 Apache가 mod_cache_disk 모듈이 활성화된 경우에만 이러한 지시문에 대해 걱정하도록 지시합니다. CacheRoot 지시문은 캐시가 유지될 디스크의 위치를 지정합니다. CacheDirLevels 및 CacheDirLength는 모두 캐시 디렉토리 구조가 구축되는 방식을 정의하는 데 기여합니다.

제공되는 URL의 md5 해시가 데이터를 저장하는 데 사용되는 키로 생성됩니다. 데이터는 각 해시의 시작 문자에서 파생된 디렉토리로 구성됩니다. CacheDirLevels는 생성할 하위 디렉토리 수를 지정하고 CacheDirLength는 각 디렉토리의 이름으로 사용할 문자 수를 지정합니다. 따라서 위에 표시된 기본값이 있는 b1946ac92492d2347c6235b4d2611184의 해시는 b/1/946ac92492d2347c6235b4d2611184의 디렉토리 구조에 보관됩니다. 일반적으로 이러한 값을 수정할 필요는 없지만 용도를 아는 것이 좋습니다.

CacheRoot 값을 수정하도록 선택한 경우 /etc/default/apache2 파일을 열고 HTCACHECLEAN_PATH 의 값을 수정해야 합니다. 선택 항목과 일치합니다. 이것은 정기적으로 캐시를 정리하는 데 사용되므로 캐시의 올바른 위치가 있어야 합니다.

이 파일에서 설정할 수 있는 다른 값으로는 CacheMaxFileSize 및 CacheMinFileSize가 있으며 Apache가 캐시에 커밋할 파일 크기 범위를 바이트 단위로 설정합니다. CacheReadSize 및 CacheReadTime: 클라이언트에 보내기 전에 콘텐츠를 대기하고 버퍼링할 수 있습니다. 콘텐츠가 이 서버가 아닌 다른 위치에 있는 경우 유용할 수 있습니다.

가상 서버 수정

캐싱을 위한 대부분의 구성은 가상 호스트 정의 또는 특정 위치 블록에서 보다 세분화된 수준에서 발생합니다.

따라할 가상 호스트 파일 중 하나를 엽니다. 이 가이드에서는 기본 파일을 사용한다고 가정합니다.

  1. sudo nano /etc/apache2/sites-enabled

위치 블록 외부의 가상 호스트 블록에서 일부 캐싱 속성 구성을 시작할 수 있습니다. 이 가이드에서는 더 많은 처리가 수행되도록 CacheQuickHandler를 끄고 싶다고 가정합니다. 이를 통해 보다 완전한 캐싱 규칙을 사용할 수 있습니다.

또한 이 기회에 캐시 잠금을 구성할 것입니다. 이것은 콘텐츠가 여전히 유효한지 확인하기 위해 콘텐츠 원본을 체크인할 때 Apache가 사용할 파일 잠금 시스템입니다. 이 쿼리가 충족되는 동안 동일한 콘텐츠에 대한 추가 요청이 들어오면 백엔드 리소스에 대한 추가 요청이 발생하여 로드 스파이크가 발생할 수 있습니다.

유효성 검사 중에 리소스에 대한 캐시 잠금을 설정하면 리소스가 현재 새로 고쳐지고 있음을 Apache에 알립니다. 이 시간 동안 오래된 리소스는 상태를 나타내는 경고 헤더와 함께 제공될 수 있습니다. /tmp 폴더의 캐시 잠금 디렉터리로 이를 설정합니다. 잠금이 유효한 것으로 간주되는 데 최대 5초가 허용됩니다. 이 예제는 Apache 문서에서 직접 가져온 것이므로 우리의 목적에 잘 맞습니다.

또한 Set-Cookie 헤더를 무시하고 캐시에 저장하지 않도록 Apache에 지시합니다. 이렇게 하면 Apache가 실수로 사용자별 쿠키를 다른 당사자에게 유출하는 것을 방지할 수 있습니다. 헤더가 캐시되기 전에 Set-Cookie 헤더가 제거됩니다.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie
</VirtualHost>

이 가상 호스트에 대한 캐싱을 실제로 활성화해야 합니다. CacheEnable 지시문을 사용하여 이를 수행할 수 있습니다. 이것이 가상 호스트 블록에 설정된 경우 캐싱 방법(disk 또는 socache)과 캐시해야 하는 요청된 URI를 제공해야 합니다. 예를 들어 모든 응답을 캐시하려면 CacheEnable disk /로 설정할 수 있지만 응답을 /public URI 아래에만 캐시하려면 다음과 같이 설정할 수 있습니다. CacheEnable 디스크 /public.

특정 위치 블록 내에서 캐시를 활성화하여 다른 경로를 택할 것입니다. 이렇게 하면 CacheEnable 명령에 URI 경로를 제공할 필요가 없습니다. 해당 위치에서 제공되는 모든 URI는 캐시됩니다. 또한 CacheHeader 지시문을 켜서 응답 헤더가 캐시가 요청을 처리하는 데 사용되었는지 여부를 나타내도록 합니다.

우리가 설정할 또 다른 지시어는 CacheDefaultExpire입니다. 따라서 Expires도 Last-Modified 헤더도 아닌 경우 만료(초)를 설정할 수 있습니다. 내용에 설정되어 있습니다. 마찬가지로 CacheMaxExpire를 설정하여 항목이 저장되는 시간을 제한합니다. Last-Modified 날짜가 있지만 만료가 없는 경우 Apache가 만료 날짜를 생성할 수 있도록 CacheLastModifiedFactor를 설정합니다. 합리적인 만료를 설정하기 위해 수정 이후 시간을 계수에 곱합니다.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    <Location />
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5
    </Location>
</VirtualHost>

필요한 모든 것을 구성했으면 파일을 저장하고 닫습니다.

다음을 입력하여 구문 오류에 대한 전체 구성을 확인하십시오.

  1. sudo apachectl configtest

오류가 보고되지 않으면 다음을 입력하여 서비스를 다시 시작하십시오.

  1. sudo service apache2 restart

콘텐츠에 만료 및 캐싱 헤더 설정

위의 구성에서 HTTP 헤더에 의존하는 HTTP 캐싱을 구성했습니다. 그러나 우리가 제공하는 콘텐츠에는 실제로 지능적인 캐싱 결정을 내리는 데 필요한 Expires 또는 Cache-Control 헤더가 없습니다. 이러한 헤더를 설정하려면 몇 가지 모듈을 더 활용해야 합니다.

mod_expires 모듈은 Expires 헤더와 Cache-Control 헤더의 max-age 옵션을 모두 설정할 수 있습니다. mod_headers 모듈은 캐싱 정책을 추가로 조정하기 위해 보다 구체적인 Cache-Control 옵션을 추가하는 데 사용할 수 있습니다.

다음을 입력하여 이 두 모듈을 모두 활성화할 수 있습니다.

  1. sudo a2enmod expires

  2. sudo a2enmod headers

이 모듈을 활성화한 후 가상 호스트 파일을 다시 수정할 수 있습니다.

  1. sudo nano /etc/apache2/sites-enabled/000-default.conf

mod_expires 모듈은 세 가지 지시문만 제공합니다. ExpiresActive는 "on\으로 설정하여 특정 컨텍스트에서 만료 처리를 켭니다. 다른 두 지시어는 서로 매우 유사합니다. ExpiresDefault 지시어는 기본값을 설정합니다. 만료 시간 및 ExpiresByType은 콘텐츠의 MIME 유형에 따라 만료 시간을 설정합니다. 둘 다 Expires 및 Cache-Control을 설정합니다. \max-age를 올바른 값으로 바꿉니다.

이 두 설정은 두 가지 다른 구문을 사용할 수 있습니다. 첫 번째는 단순히 "A\ 또는 "M\ 뒤에 몇 초가 오는 것입니다. 이는 콘텐츠가 마지막으로 "액세스\ 또는 "수정\된 시간과 관련하여 만료를 설정합니다. 예를 들어, 둘 다 액세스한 후 30초가 지나면 콘텐츠가 만료됩니다.

ExpiresDefault A30
ExpireByType text/html A30

다른 구문은 더 자세한 구성을 허용합니다. 인간이 계산하기 쉬운 초 이외의 단위를 사용할 수 있습니다. 또한 전체 단어 "액세스\ 또는 "수정\을 사용합니다. 전체 만료 구성은 다음과 같이 따옴표로 묶어야 합니다.

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"
ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

우리의 목적을 위해 기본 만료를 설정합니다. 5분으로 설정하여 시작하겠습니다. 익숙해지다가 실수하면 클라이언트의 컴퓨터에 매우 오랫동안 저장되지 않습니다. 콘텐츠에 적합한 정책을 선택할 수 있는 능력이 더 확실해지면 이를 보다 공격적인 것으로 조정할 수 있습니다.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    <Location />
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5

        ExpiresActive on
        ExpiresDefault "access plus 5 minutes"
    </Location>
</VirtualHost>

이렇게 하면 Expires 헤더가 미래 5분으로 설정되고 Cache-Control max-age=300이 설정됩니다. 캐싱 정책을 더 세분화하기 위해 Header 지시문을 사용할 수 있습니다. merge 옵션을 사용하여 Cache-Control 옵션을 추가할 수 있습니다. 이것을 여러 번 호출하고 원하는 추가 정책을 추가할 수 있습니다. 콘텐츠에 대해 설정하려는 캐싱 정책에 대한 아이디어를 얻으려면 이 가이드를 확인하십시오. 우리의 예에서는 다른 캐시가 사본을 저장할 수 있음을 확인할 수 있도록 "public\을 설정합니다.

사이트의 정적 콘텐츠에 대해 ETags를 설정하려면(검증에 사용) FileETag 지시문을 사용할 수 있습니다. 이것은 정적 콘텐츠에 대해 작동합니다. 동적으로 생성된 콘텐츠의 경우 애플리케이션에서 ETags를 올바르게 생성해야 합니다.

지시어를 사용하여 Apache가 Etag를 계산하는 데 사용할 속성을 설정합니다. 를 수정하려는지에 따라 INode, MTime, Size 또는 All이 될 수 있습니다. 파일의 inode가 변경되거나 수정 시간이 변경되거나 크기가 변경되거나 위의 모든 사항이 변경될 때마다 ETag. 둘 이상의 값을 제공할 수 있으며 새 설정 앞에 + 또는 -를 붙여 하위 컨텍스트에서 상속된 설정을 수정할 수 있습니다. 여기서는 모든 변경 사항이 등록되도록 "all\을 사용하겠습니다.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    <Location />
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5

        ExpiresActive on
        ExpiresDefault "access plus 5 minutes"

        Header merge Cache-Control public
        FileETag All
    </Location>
</VirtualHost>

이렇게 하면 Cache-Control에 이미 있는 모든 값에 "public\(쉼표로 구분)이 추가되고 정적 콘텐츠에 대한 ETag가 포함됩니다.

완료되면 파일을 저장하고 닫습니다. 다음을 입력하여 변경 사항의 구문을 확인하십시오.

  1. sudo apachectl configtest

오류가 발견되지 않으면 서비스를 다시 시작하여 캐싱 정책을 구현하십시오.

  1. sudo service apache2 restart

결론

Apache로 캐싱을 구성하는 것은 옵션이 많기 때문에 어려운 작업처럼 보일 수 있습니다. 다행스럽게도 간단하게 시작한 다음 더 많은 복잡성이 필요함에 따라 확장하기 쉽습니다. 대부분의 관리자는 각 캐싱 유형이 필요하지 않습니다.

캐싱을 구성할 때 다양한 구현 선택에서 길을 잃지 않도록 해결하려는 특정 문제를 염두에 두십시오. 대부분의 사용자는 최소한 헤더를 설정하면 도움이 됩니다. 콘텐츠를 프록시하거나 생성하는 경우 HTTP 캐시를 설정하는 것이 도움이 될 수 있습니다. 공유 개체 캐싱은 백엔드 공급자를 사용하는 경우 SSL 세션 또는 인증 세부 정보 저장과 같은 특정 작업에 유용합니다. 파일 캐싱은 시스템이 느린 파일로 제한될 수 있습니다.