[온-프레미스]{class="badge informative" title="Adobe Commerce 온-프레미스 프로젝트에만 적용됩니다."}
성능 최적화를 위한 L2 캐시 구성
L2(2단계) 캐싱은 각 웹 노드에 로컬 캐시 계층을 추가하여 원격 캐시 스토리지(Redis 또는 Valkey)와 Commerce 애플리케이션 간의 네트워크 트래픽을 줄입니다. 표준 Commerce 인스턴스는 요청당 약 300KB를 전송하며, 트래픽은 일부 상황에서 1000개 이상의 요청으로 빠르게 증가할 수 있습니다.
L2 캐싱을 사용하면 각 웹 노드는 자주 액세스하는 데이터를 로컬에 저장하고 원격 캐시를 두 가지 용도로 사용합니다.
- 최신 캐시가 로컬에 저장되었는지 확인하기 위해 캐시 데이터 버전 확인
- 업데이트된 캐시 데이터를 원격 저장소에서 로컬 시스템으로 전송 중
Commerce은 해시된 데이터 버전을 원격 캐시에 저장하고, 일반 키에 접미사 :hash을(를) 추가합니다. 로컬 캐시가 오래된 경우 캐시 어댑터를 통해 원격 컴퓨터에서 데이터를 가져옵니다.
Adobe Commerce에서는 두 가지 L2 캐시 구현을 사용할 수 있습니다.
Symfony L2 캐시는 Adobe Commerce 2.4.9 이상 릴리스에 권장되는 구현입니다. 기존 RemoteSynchronizedCache에 비해 성능이 크게 향상된 최신 PSR-6 호환 캐싱 구현을 제공합니다.
기존 L2 캐시 구성(RemoteSynchronizedCache)
기존 L2 캐시 구성 지침은 이전 버전의 Adobe Commerce에 적용됩니다. Adobe Commerce 버전 2.4.9 이상을 사용하고 있는 경우 최신 Symfony L2 캐시 구현과 함께 Valkey를 사용하십시오.
Redis를 지원하는 Adobe Commerce 온-프레미스 버전의 경우 다음 예제를 사용하여 app/etc/env.php 파일의 기존 캐시 섹션을 수정하거나 바꾸세요.
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
]
위치:
-
backend은(는) L2 캐시 구현입니다. -
backend_options은(는) L2 캐시 구성입니다.remote_backend은(는) 원격 캐시 구현인 Redis 또는 MySQL입니다.remote_backend_options은(는) 원격 캐시 구성입니다.local_backend은(는) 로컬 캐시 구현입니다.Cm_Cache_Backend_File.local_backend_options은(는) 로컬 캐시 구성입니다.cache_dir은(는) 로컬 캐시가 저장된 디렉터리에 대한 파일 캐시 관련 옵션입니다.
Redis를 지원하는 2.4.9 이전 Adobe Commerce 버전의 경우, Adobe에서는 'local_backend_options' => ['cache_dir' => '/dev/shm/']을(를) 사용하여 원격 캐싱(\Magento\Framework\Cache\Backend\Redis)에 Redis를 사용하고 공유 메모리에 있는 데이터의 로컬 캐싱에 Cm_Cache_Backend_File을(를) 사용하는 것이 좋습니다.
Adobe은 Redis에 대한 압력을 크게 낮추기 때문에 cache preload 기능을 사용할 것을 권장합니다. 미리 로드 키에 대해 접미사 :hash을(를) 추가하는 것을 잊지 마십시오.
부실 캐시 옵션
Commerce 2.4부터 use_stale_cache 옵션을 사용하면 새 캐시 데이터가 병렬 프로세스에서 생성되는 동안 이전에 캐시된 데이터를 제공함으로써 특정 경우에 대한 성능을 향상시킬 수 있습니다. 이 섹션에서 설명하는 권장 캐시 유형 및 상쇄는 기존 RemoteSynchronizedCache 및 symfony_l2 구현 모두에 적용됩니다. symfony_l2 구성 예제는 부실 캐시가 있는 Symfony L2 캐시를 참조하십시오.
일반적으로, 잠금 대기를 갖는 상계는 성능 관점에서 받아들여질 수 있다. 그러나 블록 또는 캐시 항목의 수가 증가하면 잠금 대기에 더 많은 시간이 걸립니다. 일부 시나리오에서 대기 시간은 프로세스에 대해 최대 키 수 x 조회 시간 초과일 수 있습니다. 드문 경우이지만 판매자는 Block/Config 캐시에 수백 개의 키를 보유할 수 있으므로 잠금에 대한 작은 조회 시간 제한도 초 단위로 소요될 수 있습니다.
'use_stale_cache' => true을(를) 추가하십시오.Adobe에서는 다음을 포함하여 가장 많은 혜택을 받는 캐시 유형에 대해서만 use_stale_cache 옵션을 사용하도록 권장합니다.
block_htmlconfig_integration_apiconfig_integrationfull_pagelayoutreflectiontranslate
Adobe에서는 default 캐시 유형에 대해 use_stale_cache 옵션을 활성화하지 않는 것이 좋습니다.
다음 코드는 기존 RemoteSynchronizedCache 백엔드에 대한 예제 구성을 보여 줍니다. symfony_l2의 예제는 부실 캐시가 있는 Symfony L2 캐시를 참조하십시오.
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
],
'stale_cache_enabled' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
],
'use_stale_cache' => true,
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled']
],
],
최신 Sympony L2 캐시 구현
Commerce 버전 2.4.9+에서 기존 L2 캐시 대신 Sympony 캐시 기반 L2 캐시 구현(symfony_l2 백엔드)을 사용합니다. Symfony L2 캐시는 최신 PSR-6 호환 캐싱 구현을 제공하며 기존 RemoteSynchronizedCache에 비해 성능이 크게 개선되었습니다.
- Adobe Commerce 2.4.9 이상
- 2.4.8-p4 이상 패치
- 2.4.7-p9 이상 패치
- 2.4.6-p14 이상 패치
- 2.4.5-p16 이상 패치
Symfony L2 캐시의 이점
- 최신 아키텍처: Symfony 캐시 구성 요소를 기반으로 구축(PSR-6 준수)
- 향상된 성능: Igbinary serialization, gzip 압축 및 Lua 스크립트에 대한 네이티브 지원
- 영구 연결:은(는) 연결 풀링으로 Valkey 연결 오버헤드를 줄입니다.
- 미리 로드 키:은(는) 중요 데이터에 대한 캐시 키 미리 로드를 지원합니다.
- 오래된 캐시 지원:
use_stale_cache옵션과의 완전한 호환성 - 간소화된 구성: 클리너 백 엔드 형식 이름(
valkey,file)
RemoteSynchronizedCache에서 Symfony L2로 마이그레이션
기존 RemoteSynchronizedCache 백엔드에서 symfony_l2(으)로 온-프레미스 설치를 업그레이드하는 경우 app/etc/env.php을(를) 업데이트하기 전에 다음을 검토하세요. backend 값만 변경하면 안 됩니다. 구성 구조, 키 이름 및 일부 기본 동작이 다릅니다.
-
구성 구조가 변경됩니다.
remote_backend,remote_backend_options및local_backend은(는)symfony_l2에서 다른 값을 사용합니다. 예를 들어remote_backend은(는) 정규화된 클래스 이름이 아닌'valkey'이(가) 됩니다. 기존 기존 구성을 편집하지 않고 아래의 구성 예제를 시작점으로 사용하십시오. -
preload_keys은(는)symfony_l2.(으)로 권장되지 않습니다. 레거시 구성에preload_keys이(가) 포함된 경우 마이그레이션의 일부로 제거하십시오. 키를 미리 로드해도symfony_l2에서 성능이 향상되지 않으며, 불필요한 추가 키 조회를 트리거하여 Valkey에 대한 로드를 늘릴 수 있습니다. -
압축에는 명시적 플래그가 필요합니다.
compression_lib만 설정하면symfony_l2에서 압축을 사용할 수 없습니다. 필요한compress_data설정에 대해서는 Symfony L2 캐시에 대한 백엔드 옵션을 참조하십시오. -
수동으로 구성된 온-프레미스 배포에 대해 부실 캐시가 기본적으로 사용하도록 설정되어 있지 않습니다.
use_stale_cache의 기본값은symfony_l2에서false입니다(백엔드 옵션 테이블 참조). 레거시 구성이stale_cache_enabled프런트 엔드를 사용한 경우 부실 캐시가 있는 Symfony L2 캐시의 패턴을 사용하여 명시적으로 다시 만들어야 합니다.
VALKEY_BACKEND: symfony_l2 배포 변수를 설정하는 클라우드 환경의 Adobe Commerce에는 ece-tools에 의해 자동으로 생성된 stale_cache_enabled 프론트엔드를 포함한 전체 L2 구성이 있습니다. 클라우드별 동작은 Symfony L2 캐시 구성을 참조하십시오.- Redis는
symfony_l2에 대해 지원되는 원격 백엔드가 아닙니다. 이 변경 사항의 일부로 Valkey로 마이그레이션합니다. 유효성 검사 설정을 참조하세요.
Sympony L2 캐시를 사용한 구성 예
app/etc/env.php 구성에 대한 것입니다. 클라우드의 Adobe Commerce의 경우 캐시 구성은 ece-tools에 의해 자동으로 관리됩니다. env.php을(를) 직접 편집하지 않고 Symfony L2 캐시 구성을(를) 참조하십시오.app/etc/env.php 파일에서 L2 캐시에 대해 간소화된 symfony_l2 백 엔드 유형을 사용합니다. 이 예제에서는 symfony_l2에 권장되지 않는 preload_keys 구성을 포함하지 않습니다. 자세한 내용은 RemoteSynchronizedCache에서 Symfony L2로 마이그레이션을 참조하십시오.
'cache' => [
'frontend' => [
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
// L2 (Remote): Valkey with Symfony Cache
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_default',
'timeout' => '2.5',
'read_timeout' => '2.0',
'use_lua' => '1',
],
// L1 (Local): File cache
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
'cleanup_percentage' => 90,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
],
부실 캐시가 있는 교감 L2 캐시
캐시 유형이 부실 캐시에서 혜택을 받는 부실 캐시 옵션과(와) 그 이유를 참조하십시오.
다음 예제를 사용하여 symfony_l2 부실 캐시 지원에 대해 별도의 프론트엔드를 구성하십시오.
'cache' => [
'frontend' => [
// Default frontend: NO stale cache
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_default',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
],
],
// Stale cache enabled frontend
'stale_cache_enabled' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_stale',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1_stale'
],
'use_stale_cache' => true,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled'],
],
],
Symfony L2 캐시를 위한 백엔드 옵션
remote_backend'valkey'valkey 또는 file. L2 캐시에 valkey을(를) 사용합니다.remote_backend_options[]local_backend'file'file 또는 apculocal_backend_options[]cleanup_percentage95use_stale_cachefalsecompress_datafalsecompression_lib과(와) 결합할 경우 압축을 활성화합니다. compression_lib만 설정하면 압축을 사용할 수 없습니다.persistenttruefalse('0')(으)로 설정합니다. 이 동작은 기본적으로 비영구 연결로 설정됩니다.-
remote_backend옵션에서도redis값을 사용할 수 있지만 Redis는 공식적으로 지원되지 않습니다(최신 Symfony L2 캐시 구현에 있는 위의 참고 사항 참조). -
기존
RemoteSynchronizedCache구성에 사용된frontend_options.write_control이(가)symfony_l2에 적용되지 않습니다.
향상된 Sympony L2 캐시 성능 및 안정성
symfony_l2을(를) 사용하는 Adobe Commerce 2.4.9 배포에 적용되며 패치 ACP2E-5132에서 사용할 수 있습니다. Adobe Commerce 온프레미스의 경우 품질 패치 도구(QPT)를 사용하여 이 패치를 적용합니다. Cloud의 Adobe Commerce의 경우 이 패치는 Commerce용 클라우드 패치를 통해 자동으로 제공됩니다.최신 업데이트를 통해 Symfony L2 캐시 확장성이 향상되고 불필요한 파일 시스템 I/O가 감소하며 캐시 일관성 및 안정성이 향상되었습니다.
최적화된 Sympony L2 캐시 태그 스토리지
중복 파일 시스템 태그 인덱스 쓰기를 제거하여 Valkey 지원 배포를 위해 최적화된 Sympony L2 캐시 비헤이비어 이제 캐시 태그는 Valkey에만 저장되며, Sympony L2 캐시 동작을 레거시 캐시 구현에 맞춥니다. 이렇게 하면 불필요한 디스크 I/O가 줄어들고 캐시 쓰기 성능이 향상되며 var/cache/symfony/tags/ 디렉터리의 증가를 방지할 수 있습니다.
파일 기반 캐시 동작 개선
파일 기반 캐시를 사용하는(유효성 검사 없이) 배포의 경우 캐시 무효화를 지원하기 위해 로컬 태그 인덱스가 계속 유지됩니다. 이제 태그 인덱스가 이전에 하드코딩된 var/cache 위치 대신 구성된 cache_dir에 기록되어 일관된 캐시 디렉터리 사용을 보장하고 사용자 지정 캐시 구성에 대한 지원을 개선합니다.
다시 태그 지정 후 오래된 태그 멤버십 수정
캐시 항목을 다시 태깅하면 더 이상 속해 있지 않은 태그와 연결되어 있을 수 있습니다. 이제 다시 태그 지정 시 오래된 태그 멤버십이 지워지므로 캐시 항목은 현재 할당된 태그에 의해서만 무효화됩니다.
변경되지 않은 저장을 위한 이중 원격 쓰기 수정
변경되지 않은 콘텐츠로 캐시 항목을 저장해도 원격(Valkey) 백엔드에 대한 쓰기가 트리거됩니다. 이제 콘텐츠가 변경되지 않으면 저장을 생략하여 불필요한 원격 쓰기를 줄일 수 있습니다.
L1 크기 기반 제거 수정(cleanup_percentage)
L1 크기 기반 제거에 사용된 cleanup_percentage 임계값이 정리를 일관되게 트리거하지 않았습니다. 이제 L1 캐시 제거에서 구성된 cleanup_percentage을(를) 올바르게 적용합니다.
부실 캐시에 대한 재생성 잠금
use_stale_cache이(가) 활성화되어 있고 항목의 원격 복사본을 일시적으로 사용할 수 없는 경우 이제 한 프로세스만 단기 잠금을 획득하여 해당 항목을 다시 생성합니다. 동일한 항목에 대한 다른 동시 요청은 기존 로컬 값을 직접 재생성하는 대신 계속 처리되므로 재생성 스탬프와 중복 백엔드 로드가 줄어듭니다.
영향
- Valkey 지원 Symfony L2 캐시 배포를 위한 중복 파일 시스템 태그 인덱스 쓰기를 제거하여 디스크 I/O를 줄이고
var/cache/symfony/tags/디렉터리의 불필요한 증가를 방지합니다. - 파일 기반 캐시 배포가 캐시 무효화 동작을 유지하면서 로컬 태그 인덱스에 대해 구성된
cache_dir을(를) 일관되게 사용하도록 합니다. - 다시 태깅한 후 오래된 태그 멤버십이 남아 있어 잘못된 캐시 무효화를 방지합니다.
- 변경되지 않은 캐시 저장에 대한 불필요한 원격 쓰기를 줄여 네트워크 및 백엔드 로드 감소.
- 구성된
cleanup_percentage임계값에서 L1 캐시 제거를 안정적으로 트리거합니다. - 모든 동시 요청 재구축 대신 키당 하나의 재생기를 선택하여
use_stale_cache항목에 대한 재생성 속도를 줄입니다.
자세한 구성 옵션은 다음을 참조하십시오.