[클라우드의 Commerce]{class="badge informative" title="클라우드 프로젝트의 Adobe Commerce에만 적용됩니다."}
Valkey 및 Redis 서비스 구성에 대한 우수 사례
Adobe Commerce 애플리케이션 캐시, 세션 저장소 및 Adobe Commerce on Cloud 배포용 L2 캐시에 대해 Redis 또는 Valkey를 구성할 때 이러한 권장 사항을 사용하십시오.
Adobe Commerce 온-프레미스 캐시 구성에 대해서는 성능 최적화를 위한 L2 캐시 구성을 참조하세요.
이러한 권장 사항에서는 다음 사항을 다룹니다.
- 지원되는 캐시 서비스 선택
- 복제본 연결 사용
- 별도의 캐시 및 세션 인스턴스
- 캐시 압축 구성
- 비동기 해제 사용
- 다중 스레드 I/O 사용
- 클라이언트 시간 초과 및 재시도 증가
- 미리 로드 키, 부실 캐시 및 Symfony L2 캐시를 포함하여 L2 캐시 구성
- 구성 예제 검토
지원되는 캐시 서비스 선택
Redis는 Adobe Commerce 2.4.9 및 시스템 요구 사항이 대신 Valkey를 지정하는 패치 릴리스의 캐시 구성에 대해 지원되지 않습니다. 캐시 백엔드 옵션 및 저장소 참조 및 시스템 요구 사항에서 항상 정확한 Commerce 버전, 패치 수준 및 서비스 버전을 확인하십시오.
ece-tools 패키지를 사용 중인지 확인하십시오. 그렇지 않으면 최신 버전으로 업그레이드하십시오. composer show magento/ece-tools CLI 명령을 사용하여 로컬 환경에 설치된 버전을 확인할 수 있습니다.복제본 연결 사용
.magento.env.yaml 파일에서 복제본 연결을 사용하도록 설정합니다. 이 변경 사항으로 Adobe Commerce은 쓰기에 기본 끝점을 계속 사용하는 동안 읽기에 추가 캐시 연결을 사용할 수 있습니다. 이 구성을 통해 기본 캐시 서비스의 읽기 로드를 줄이고 읽기 트래픽을 보다 효과적으로 분산할 수 있습니다.
ece-tools 버전에 따라 다릅니다. 이 설정을 사용하기 전에 echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp을(를) 실행하고 USE_SLAVE_CONNECTION 항목을 확인하여 서비스에 대한 복제본 관계가 있는지 확인하십시오. 토폴로지에서 복제본 끝점을 프로비전하는지 확인하려면 ece-tools을(를) 업그레이드하고 다시 배포하거나 USE_SLAVE_CONNECTION 항목이 없는 경우 Adobe Commerce 지원에 문의하세요.symfony_l2의 경우 복제본 연결 지원은 ece-tools 및 클라우드 패치 업데이트를 통해 제공됩니다. VALKEY_USE_SLAVE_CONNECTION: true을(를) 변경하는 것 외에는 추가 캐시 구성이 필요하지 않습니다. 수정 사항을 받으려면 최신 ece-tools 버전으로 업데이트하십시오.Valkey의 경우 다음을 사용합니다.
| code language-yaml |
|---|
|
환경 변수 구성에 대한 자세한 내용은 Commerce on Cloud Infrastructure Guide의 VALKEY_USE_SLAVE_CONNECTION을(를) 참조하십시오.
Redis의 경우 다음을 사용합니다.
| code language-yaml |
|---|
|
환경 변수 구성에 대한 자세한 내용은 Commerce on Cloud Infrastructure Guide의 REDIS_USE_SLAVE_CONNECTION을(를) 참조하십시오.
별도의 캐시 및 세션 인스턴스
캐시와 세션 구성은 독립적입니다. 사용하는 캐시 백 엔드 또는 L2 캐시 구현에 관계없이 SESSION_CONFIGURATION은(는) 캐시 동작에 영향을 주지 않습니다. 캐시와 세션을 분리하면 독립적으로 관리할 수 있습니다. 캐시와 세션 트래픽 간의 경합을 줄이고, 캐시 관련 압력이 세션에 영향을 주지 않도록 하며, 각 Redis 또는 Valkey 인스턴스의 크기를 조정하고 자체 워크로드에 맞게 조정할 수 있도록 합니다.
.magento/services.yaml 및 .magento.app.yaml 파일과 함께 Adobe Commerce 지원 티켓을 제출해야 합니다.세션에 대한 전용 인스턴스를 프로비저닝하려면 아래 단계를 따르십시오.
-
.magento/services.yaml구성 파일을 업데이트하여<version>을(를) 사용 중인 서비스 버전으로 바꿉니다. 릴리스별 지원되는 서비스 버전에 대해서는 시스템 요구 사항을 참조하십시오.code language-yaml mysql: type: mysql:<version> disk: 35000 valkey: type: valkey:<version> valkey-session: # This is for the new Valkey instance type: valkey:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> disk: 2048 -
.magento.app.yaml구성 파일을 업데이트합니다.code language-yaml relationships: database: "mysql:mysql" valkey: "valkey:valkey" valkey-session: "valkey-session:valkey" # Relationship of the new Valkey instance search: "search:elasticsearch" rabbitmq: "rabbitmq:rabbitmq" -
프로덕션 및 스테이징 환경에서 세션 전용 새 Valkey 인스턴스를 요청합니다.
Adobe Commerce 지원 티켓을 제출하세요. 업데이트된
.magento/services.yaml및.magento.app.yaml구성 파일을 포함합니다.이 업데이트로 인해 가동 중지 시간은 발생하지 않지만, 새 서비스를 활성화하려면 배포가 필요합니다.
-
새 인스턴스가 실행 중인지 확인하고 포트 번호를 확인합니다.
code language-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
.magento.env.yaml구성 파일에 포트 번호를 추가합니다.note important IMPORTANT ece-tools이(가)MAGENTO_CLOUD_RELATIONSHIPSValkey 세션 서비스 정의에서 Valkey 세션 포트를 자동으로 검색할 수 없는 경우에만 Valkey 세션 포트를 구성하십시오.note NOTE 최상의 성능을 위해 disable_locking을(를)1(으)로 설정하십시오. 드문 경우지만 동시 세션 활동이 많기 때문에 경합 상태가 발생하는 경우 잠금을 활성화하려면0(으)로 설정하십시오.code language-yaml SESSION_CONFIGURATION: _merge: true redis: # keep 'redis' even if you are using Valkey. timeout: 5 disable_locking: 1 bot_first_lifetime: 60 bot_lifetime: 7200 max_lifetime: 2592000 min_lifetime: 60 -
Valkey 캐시 인스턴스의 기본 데이터베이스(
db 0)에서 세션을 제거합니다.code language-terminal valkey-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
-
.magento/services.yaml구성 파일을 업데이트하여<version>을(를) 사용 중인 서비스 버전으로 바꿉니다.code language-yaml mysql: type: mysql:<version> disk: 35000 redis: type: redis:<version> redis-session: # This is for the new Redis instance type: redis:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> disk: 2048 -
.magento.app.yaml구성 파일을 업데이트합니다.code language-yaml relationships: database: "mysql:mysql" redis: "redis:redis" redis-session: "redis-session:redis" # Relationship of the new Redis instance search: "search:elasticsearch" rabbitmq: "rabbitmq:rabbitmq" -
프로덕션 및 스테이징 환경에서 세션 전용 새 Redis 인스턴스를 요청합니다.
Adobe Commerce 지원 티켓을 제출하세요. 업데이트된
.magento/services.yaml및.magento.app.yaml구성 파일을 포함합니다.이 업데이트로 인해 가동 중지 시간은 발생하지 않지만, 새 서비스를 활성화하려면 배포가 필요합니다.
-
새 인스턴스가 실행 중인지 확인하고 포트 번호를 확인합니다.
code language-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
.magento.env.yaml구성 파일에 포트 번호를 추가합니다.note important IMPORTANT ece-tools이(가)MAGENTO_CLOUD_RELATIONSHIPSRedis 세션 서비스 정의에서 자동으로 검색할 수 없는 경우에만 Redis 세션 포트를 구성하십시오.note NOTE 최상의 성능을 위해 disable_locking을(를)1(으)로 설정하십시오. 드문 경우지만 동시 세션 활동이 많기 때문에 경합 상태가 발생하는 경우 잠금을 활성화하려면0(으)로 설정하십시오.code language-yaml SESSION_CONFIGURATION: _merge: true redis: timeout: 5 disable_locking: 1 bot_first_lifetime: 60 bot_lifetime: 7200 max_lifetime: 2592000 min_lifetime: 60 -
Redis 캐시 인스턴스의 기본 데이터베이스(
db 0)에서 세션을 제거합니다.code language-terminal redis-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
캐시 압축
6GB 이상의 Redis 또는 Valkey maxmemory을(를) 사용하는 경우 캐시 압축을 사용하여 키에 사용되는 공간을 줄일 수 있습니다. 이 설정은 메모리 절감을 위해 클라이언트측 성능을 처리합니다. 여유 CPU 용량이 있는 경우 활성화해 보십시오. 구성 가이드에서 세션 저장소에 Redis 사용 또는 세션 저장소에 Valkey 사용을 참조하십시오.
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
compress_data: 4 # 0-9
compress_tags: 4 # 0-9
compress_threshold: 20480 # don't compress files smaller than this value
compression_lib: 'gzip' # snappy and lzf for performance, gzip for high compression (~69%)
비동기 해제 사용
Adobe Commerce 클라우드 인프라에서 lazyfree을(를) 사용하려면 다음 Redis 또는 Valkey 구성을 환경에 적용할 것을 요청하는 Adobe Commerce 지원 티켓을 제출합니다.
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes
lazyfree이(가) 활성화되면 Redis 또는 Valkey는 제거, 만료, 서버에서 시작된 삭제, 사용자 삭제 및 복제본 데이터 세트 플러시를 위해 백그라운드 스레드로 메모리 재확보를 오프로드합니다. 이렇게 하면 기본 스레드 차단이 줄어들고 요청 지연이 감소할 수 있습니다.
lazyfree-lazy-user-del yes 옵션을 사용하면 DEL 명령이 UNLINK과(와) 같이 동작하여 키의 연결이 즉시 해제되고 비동기적으로 메모리를 확보할 수 있습니다.다중 스레드 I/O 사용
Adobe Commerce 클라우드 인프라에서 Redis I/O 스레딩을 사용하려면 아래의 I/O 스레딩 구성을 요청하는 Adobe Commerce 지원 티켓을 제출하십시오. 이 구성은 더 높은 CPU 사용 비용으로 소켓 읽기, 쓰기 및 명령 구문 분석을 기본 스레드에서 오프로드하여 처리량을 향상시킬 수 있습니다. 로드 중 유효성 검사 및 호스트 모니터링
레디스의 경우:
| code language-text |
|---|
|
Valkey의 경우:
| code language-text |
|---|
|
io-threads을(를) 줄이거나 I/O 스레드에서 읽기를 사용하지 않도록 설정하십시오.클라이언트 시간 초과 및 재시도 증가
.magento.env.yaml에서 백엔드 옵션을 조정하여 Redis 또는 Valkey 캐시 클라이언트의 허용 한도를 짧은 채도 기간으로 늘립니다.
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
connect_retries: 3 # Number of connection retries
remote_backend_options:
read_timeout: 10 # Timeout
이러한 설정은 연결 설정을 다시 시도하고 Redis 또는 Valkey에서 답글 작성 시간을 더 많이 허용하여 짧은 스파이크 동안 간헐적인 연결 및 읽기 시간 초과 오류를 줄일 수 있습니다.
L2 캐시 구성
.magento.env.yaml 구성 파일에서 VALKEY_BACKEND 또는 REDIS_BACKEND 배포 변수를 설정하여 L2 캐시를 구성합니다.
클라우드 인프라의 Adobe Commerce에 두 가지 L2 캐시 구현을 사용할 수 있습니다.
- 레거시 구현에서는 로컬 저장소에
Cm_Cache_Backend_File과(와) 함께RemoteSynchronizedCache을(를) 사용합니다. - 최신 구현에서는 PSR-6 준수 및 향상된 성능을 통해
symfony_l2을(를) 사용합니다. 최신 구현은 Valkey만 지원합니다.
(Valkey가 지원되는 경우)
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'VALKEY_BACKEND: 'symfony_l2'Valkey를 지원하는 Commerce 2.4.8 및 이전 버전에서 다음 구성을 사용합니다.
| code language-yaml |
|---|
|
Commerce 2.4.9 이상에서는 Symfony L2 구현과 함께 다음 구성을 사용합니다.
| code language-yaml |
|---|
|
Redis를 지원하는 버전 2.4.8 및 이전 Commerce 버전에서는 다음을 사용합니다.
| code language-yaml |
|---|
|
환경 구성에 대한 자세한 내용은 Commerce on Cloud Infrastructure Guide의 REDIS_BACKEND을(를) 참조하십시오.
Symfony L2 캐시가 있는 Valkey로 마이그레이션
기존 클라우드 기반 Adobe Commerce 프로젝트를 RemoteSynchronizedCache(Redis 또는 Valkey)에서 symfony_l2(으)로 마이그레이션하는 경우 .magento.env.yaml을(를) 업데이트하기 전에 다음을 검토하십시오.
-
배포 변수를 변경하면
symfony_l2을(를) 사용할 수 있습니다.VALKEY_BACKEND: symfony_l2만 설정하면 전체 L2 캐시 구성이 자동으로 빌드됩니다. 사용된 이전RemoteSynchronizedCache구성에 사용된backend_options구조를 수동으로 다시 만들 필요가 없습니다. 구성 Symfony L2 캐시를 참조하십시오. -
기존 구성에서
preload_keys을(를) 제거합니다.RemoteSynchronizedCache구성에CACHE_CONFIGURATION아래의preload_keys이(가) 포함된 경우 마이그레이션의 일부로 제거하십시오. 자세한 내용은 키 미리 로드를 참조하십시오. -
오래된 캐시 동작이 자동으로 변경됩니다.
symfony_l2에서ece-tools은(는)RemoteSynchronizedCache에 필요한 수동 프론트엔드 구성 없이 일반 캐시 형식(예:layout,block_html,full_page및translate)에 대해 오래된 캐시를 자동으로 활성화합니다. 이전에 부실 캐시를 수동으로 구성했으며 정확한 이전 동작을 유지하려면 마이그레이션하기 전에 부실 캐시 활성화를 검토하십시오. -
압축에는 명시적 플래그가 필요합니다.
CACHE_CONFIGURATION을(를) 통해symfony_l2압축을 사용자 지정하는 경우compression_lib만 설정하면 압축이 활성화되지 않습니다.compress_data도 설정해야 합니다. 캐시 압축을 참조하세요. -
Redis는
symfony_l2에 대해 지원되는 원격 백엔드가 아닙니다. 이 변경 사항의 일부로 Valkey로 마이그레이션합니다. Valkey 서비스 설정을(를) 참조하십시오. -
세션 구성은 이 마이그레이션의 영향을 받지 않습니다.
SESSION_CONFIGURATION은(는) 캐시 백엔드와 독립적이므로symfony_l2(으)로 이동할 때 변경할 필요가 없습니다. 캐시와 세션 인스턴스 구분을 참조하십시오.
app/etc/env.php에서 symfony_l2을(를) 수동으로 구성하지 마십시오. 배포 중에 ece-tools이(가) 설정을 적용하고 유지할 수 있도록 .magento.env.yaml을(를) 통해 구성하십시오. 구성 Symfony L2 캐시를 참조하십시오.미리 로드 키
올바른 위치(backend_options 또는 remote_backend_options 아래)를 사용하는 경우 미리 로드 키를 symfony_l2 구성에 적용할 수 있습니다. 하지만 Adobe에서는 symfony_l2에 미리 로드 키를 사용하지 않는 것이 좋습니다. symfony_l2 미리 로드 구현은 키를 한 번에 하나씩 가져오므로 RemoteSynchronizedCache의 경우처럼 라운드 트립이 줄어들지 않으며 성능상의 이점 없이 Valkey의 로드를 늘릴 수 있습니다.
미리 로드 기능을 사용하면 Magento이 요청 중에 처음 액세스할 때 단일 파이프라인에서 가져오는 자주 사용하는 키 목록을 제공할 수 있습니다. 그런 다음 Magento은 가져온 값을 나머지 해당 요청에 대해 PHP 메모리에 유지하므로 Redis 또는 Valkey로의 반복된 라운드 트립이 줄어들고 해당 키에 대한 요청 부트스트랩 성능을 향상시킬 수 있습니다.
Redis 또는 Valkey에서 활성 명령을 모니터링하여 자주 사용되는 키를 식별할 수 있습니다.
미리 로드 키가 .magento.env.yaml 구성 파일에 구성되어 있습니다. 이 예는 RemoteSynchronizedCache을(를) 지원하는 Adobe Commerce 2.4.8 및 이전 버전에 대한 구성을 보여줍니다.
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
backend_options:
preload_keys: # List the keys to be preloaded
- '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
- '061_GLOBAL_PLUGIN_LIST:hash'
- '061_DB_IS_UP_TO_DATE:hash'
- '061_SYSTEM_DEFAULT:hash'
키를 나열하려면 다음 명령을 실행합니다.
redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys
10초 후 Ctrl+C를 누릅니다. 그런 다음 다음 다음 명령을 실행합니다.
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50
이 로그에는 미리 로드할 수 있는 키가 나열됩니다. 키의 내용을 보려면 다음 명령을 실행합니다.
redis-cli -p 6370 -n 1 hgetall "<key_name>"
부실 캐시 활성화
부실 캐시는 다른 요청이 이미 동일한 항목을 다시 만드는 동안 Adobe Commerce에서 /dev/shm의 기존 로컬 캐시 값을 제공할 수 있는 L2 캐시 기능입니다. 이렇게 하면 동시 요청이 대기하지 않습니다. 이렇게 하면 값비싼 캐시 항목을 재생성하는 동안 캐시 스템피드 및 잠금 경합이 줄어듭니다.
Adobe Commerce 2.4.9 이상의 경우 .magento.env.yaml 파일에서 VALKEY_BACKEND: symfony_l2을(를) 설정합니다.
stage:
deploy:
VALKEY_BACKEND: symfony_l2
ece-tools은(는) default 프론트엔드와 stale_cache_enabled 프론트엔드를 모두 자동으로 생성하고, layout, block_html, reflection, config_integration, config_integration_api, full_page 및 translate 캐시 형식을 부실 사용 프론트엔드에 매핑합니다. 이러한 형식에는 수동 use_stale_cache 또는 프론트엔드 구성이 필요하지 않습니다. 이러한 자동 매핑은 그 자체로 선택적 부실 캐시 활성화의 한 예입니다. 특정 캐시 유형만 부실 사용 프론트엔드를 사용하며 그 전부는 아닙니다. stale_cache_enabled에 매핑되는 형식을 사용자 지정하거나 기본값 이외의 형식을 추가하려면 L2 캐시 구성 사용자 지정을 참조하십시오. Symfony
full_page 캐시 유형은 전체 페이지 캐싱에 Fastly를 사용하므로 클라우드 인프라 프로젝트의 Adobe Commerce과 관련이 없습니다. ece-tools에서 기본 symfony_l2 매핑에 수동 구성 예제에 full_page이(가) 포함되어 있어도 이 섹션의 수동 구성 예제에서는 이 때문에 이 예제를 생략합니다.다음 레거시 구성은 RemoteSynchronizedCache을(를) 사용하고 수동 부실 캐시 및 프론트엔드 구성이 필요한 Adobe Commerce 2.4.8 이하에 적용됩니다. 여기에도 동일한 전역 중복 권장 사항이 적용됩니다.
레거시 RemoteSynchronizedCache 백엔드의 작동 방식
RemoteSynchronizedCache을(를) 사용하면 Magento은 각 캐시 항목의 복사본 두 개를 유지 관리합니다. 하나는 /dev/shm에 로컬 복사본이고 다른 하나는 Redis 또는 Valkey에 원격 복사본입니다. 원격 복사본을 사용할 수 없고 해당 키에 대한 재생성 잠금이 이미 있는 경우, 동시 요청은 새 값이 기록될 때까지 기다리지 않고 이전 로컬 값을 수신할 수 있습니다.
2.4.8 및 이전 버전에 대해 오래된 캐시를 활성화하려면 .magento.env.yaml 파일에서 구성합니다.
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
use_stale_cache: true
default 캐시 프런트 엔드에서 오래된 캐시를 활성화하며, 이로 인해 해당 프런트 엔드를 사용하는 모든 캐시 항목에 오래된 캐시 동작이 적용됩니다. Magento 코어 캐시 유형은 이 설정에서 예상대로 작동합니다. 그러나 프로젝트에 전용 캐시 프론트엔드 없이 일반 \Magento\Framework\App\Cache API(예: $this->cache->save())를 통해 캐시에 쓰는 사용자 지정 코드 또는 확장이 포함되어 있는 경우 이러한 항목은 재생성 중에도 부실 값을 제공할 수 있습니다.default 프런트 엔드에 오래된 캐시를 사용하지 않도록 설정한 후 아래 표시된 것처럼 선택한 캐시 유형에 대해서만 사용하도록 설정하십시오.캐시 유형별로 오래된 캐시 활성화(이전)
.magento.env.yaml에서 전용 캐시 프런트 엔드를 정의하고 선택한 캐시 유형을 매핑하여 선택한 캐시 유형에 대해서만 오래된 캐시를 활성화할 수 있습니다. 이 수동 접근 방식은 레거시 RemoteSynchronizedCache 백엔드에 적용됩니다. symfony_l2은(는) 위에서 설명한 대로 이 매핑을 자동으로 수행합니다.
올바르게 작동하려면 사용자 지정 프론트엔드를 CACHE_CONFIGURATION.frontend에서 전체 프론트엔드로 정의해야 합니다. 새 프론트엔드 이름에 대해 use_stale_cache: true만 정의하면 충분하지 않습니다.
예제 구성
버전 2.4.8 및 이전 버전의 Redis의 경우, 다음 구성은 layout, reflection, config_integration, config_integration_api 및 translate 캐시 유형에 대해 오래된 캐시를 활성화하고 다른 구성은 오래된 캐시가 비활성화된 기본 프런트 엔드를 사용합니다.
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # In this frontend, we keep stale cache set to false.
id_prefix: '001_'
backend_options:
use_stale_cache: false
# Now, create a new frontend called 'stale_cache_enabled'.
# It must contain the same backend connection settings as the frontend 'default':
stale_cache_enabled:
id_prefix: '001_'
backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
backend_options:
remote_backend: '\Magento\Framework\Cache\Backend\Redis'
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the frontend 'default' in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same port used by the frontend 'default' in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: 'Cm_Cache_Backend_File'
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true # stale cache here is enabled
# Now select which cache types you want to enable (stale_cache_enabled), or disable (default)
type:
default:
frontend: default
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
stale_cache_enabled에 복사합니다.Symfony L2 캐시 구성
Adobe Commerce 2.4.9 이상 버전은 symfony_l2 캐시 백엔드를 지원합니다. symfony_l2 백엔드는 Adobe Commerce에서 L1 및 L2 캐시 동작을 관리하는 데 사용하는 캐시 구현입니다. 원격 캐시 서비스로 Redis 또는 Valkey를 대체하지 않습니다.
ece-tools이(가) 배포 중에 설정을 적용하고 유지 관리하도록 .magento.env.yaml 배포 변수를 통해 symfony_l2을(를) 구성하십시오. 배포가 수동 env.php 변경 내용을 덮어쓸 수 있으므로 app/etc/env.php에서 symfony_l2을(를) 수동으로 구성하지 마십시오. ece-tools이(가) symfony_l2을(를) 적용하지 않으면 Commerce이 파일 기반 캐시로 대체되어 디스크 I/O가 증가하고, 다중 노드 환경에서 파일 시스템 복제 오버헤드가 추가되며 성능이 저하될 수 있습니다.Adobe Commerce 2.4.9용 symfony_l2 캐시를 사용하려면 다음 단계를 완료하십시오.
-
클라우드 프로젝트에서
ece-tools패키지 v2002.2.12 이상을 사용하고 있는지 확인하십시오. -
.magento.env.yaml파일에서 배포 변수를 설정합니다.VALKEY_BACKEND=symfony_l2.code language-yaml stage: deploy: VALKEY_BACKEND: symfony_l2
VALKEY_BACKEND 배포 변수를 symfony_l2(으)로 설정하면 default 및 stale_cache_enabled 프런트 엔드를 포함한 Valkey 서비스 연결 세부 정보에서 일반 캐시 형식이 이미 매핑된 전체 L2 캐시 구성이 자동으로 빌드됩니다. CACHE_CONFIGURATION 정의는 선택 사항이며 특정 백엔드 옵션을 사용자 지정하려는 경우에만 필요합니다.
cleanup_percentage) 문제를 해결하여 Symfony L2 캐시 성능과 안정성을 개선합니다. 이를 통해 디스크 I/O 및 백엔드 로드를 줄이는 동시에 캐시 일관성을 향상시킬 수 있습니다. Adobe Commerce 구성 가이드에서 향상된 Symfony L2 캐시 성능 및 안정성을(를) 참조하십시오.ece-tools)에 포함되어 있으며 최신 ece-tools 버전으로 업데이트할 때 배포 중에 자동으로 적용됩니다. 패치를 받으려면 ece-tools의 최신 버전으로 업데이트하십시오.Symfony L2 캐시 구성 사용자 지정
ece-tools은(는) default 및 stale_cache_enabled 프런트 엔드에 대한 Valkey 연결 세부 정보(server, port, database, serializer, compression_lib, persistent_id)를 자동으로 파생합니다. 로컬 캐시 디렉터리와 같은 다른 백엔드 옵션을 사용자 지정하려면 VALKEY_BACKEND: symfony_l2과(와) 함께 _merge: true을(를) 사용하여 CACHE_CONFIGURATION을(를) 정의합니다. 여기서 정의하는 값은 자동 생성된 해당 기본값을 재정의합니다. 생략하는 모든 옵션은 ece-tools에서 자동으로 파생되는 값을 계속 사용합니다.
stage:
deploy:
VALKEY_BACKEND: symfony_l2
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1
stale_cache_enabled:
backend: symfony_l2
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1_stale
use_stale_cache: true
symfony_l2에 대해 CACHE_CONFIGURATION을(를) 정의할 때 프로젝트의 Valkey 서비스 이외의 캐시 끝점을 의도적으로 가리키고 있는 경우에만 server 또는 port을(를) 재정의하십시오. ece-tools 패키지는 Valkey 서비스 관계에서 이러한 값을 자동으로 파생합니다.server을(를) 재정의하는 경우 프로젝트의 Valkey 서비스에 연결할 때 해당 값은 localhost이어야 합니다. 잘못된 server 또는 port 값을 제공하면 캐시 연결 오류가 발생하여 배포가 실패합니다.Adobe Commerce Cloud용 L2 캐시 메모리 크기 조정
L2 캐시는 저장소 메커니즘으로 임시 파일 시스템(/dev/shm)을(를) 사용합니다. MPFS는 전문 키-밸류 저장소와 달리 키 제거 정책이 없으므로 메모리 사용량이 무제한 증가할 수 있습니다. 소진을 방지하기 위해 Adobe Commerce은 사용량이 구성 가능한 임계값(기본적으로 95%)에 도달하면 L2 저장소를 자동으로 지웁니다. 더 큰 /dev/shm 마운트를 요청하거나 정리 임계값을 낮추어 메모리 사용을 제어할 수 있습니다.
프로젝트 요구 사항에 따라 최대 L2 캐시 메모리 사용량을 조정합니다. 다음 방법 중 하나를 사용하십시오.
/dev/shm탑재 크기를 조정하려면 지원 티켓을 만드십시오. 이 시나리오에서는/dev/shm마운트 크기를 15GB로 설정하는 것이 좋습니다.- 응용 프로그램 수준에서
cleanup_percentage속성을 조정하여 다른 서비스에 사용할 수 있는 저장소 사용 및 사용 가능한 메모리를 제한합니다.
캐시 구성 그룹cache/frontend/default/backend_options/cleanup_percentage아래의 배포 구성에서 구성을 조정할 수 있습니다.
cleanup_percentage 옵션이 Adobe Commerce 2.4.4에 도입되었습니다.다음 예제는 .magento.env.yaml 파일의 구성 코드를 보여 줍니다.
Commerce 2.4.9 이상의 경우 다음 구성을 사용하여 정리 임계값을 90%로 설정합니다.
| code language-yaml |
|---|
|
Commerce 2.4.8 및 이전 버전의 경우 다음 구성을 사용하여 정리 임계값을 90%로 설정합니다.
| code language-yaml |
|---|
|
캐시 요구 사항은 프로젝트 구성 및 사용자 지정 타사 코드에 따라 다릅니다. 캐시가 빈번한 임계값 히트 없이 작동할 수 있도록 L2 캐시 메모리의 크기를 지정합니다.
이상적으로 L2 캐시 메모리 사용은 빈번한 스토리지 지우기를 피하기 위해 임계값 아래에서 안정됩니다.
다음 CLI 명령을 실행하고 /dev/shm 줄을 검토하여 클러스터의 각 노드에서 L2 캐시 저장소 메모리 사용을 확인할 수 있습니다.
df -h /dev/shm
사용법은 노드에 따라 다르지만 비슷한 값으로 수렴합니다.
구성 예
다음 예를 Redis 또는 Valkey 서비스 구성의 시작점으로 사용하십시오.
모든 모범 사례 권장 사항 적용
VALKEY_BACKEND: symfony_l2의 경우 ece-tools이(가) default 및 stale_cache_enabled 프런트 엔드와 해당 캐시 유형 매핑을 생성하게 합니다. 광범위한 default 프런트 엔드에서 use_stale_cache을(를) 설정하지 마십시오. 아래의 CACHE_CONFIGURATION 블록에는 명시적 백엔드 옵션 무시만 포함되어 있습니다.
| code language-yaml |
|---|
|
Adobe Commerce 2.4.8 및 이전 버전의 Redis에 대해 다음 구성을 사용하십시오.
| code language-yaml |
|---|
|
캐시 유형별로 부실 캐시 구분
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|