고급 설정

Commerce은(는) 모든 크기의 판매자를 위한 솔루션을 포함하는 유연성과 확장성이 뛰어난 제품입니다. 이 단원에서는 대량의 데이터, 과도한 로드 및 기타 엔터프라이즈 사례에서 작동하도록 Commerce을 구성하는 데 대한 모범 사례 및 권장 사항을 다룹니다.

색인 성능 보정

대량의 데이터를 처리할 때는 리인덱싱이 문제가 될 수 있습니다. Commerce 팀은 가장 많이 로드된 인덱스와 일괄 인덱싱 기능을 활성화하여 각 반복에서 처리할 데이터 부분을 설정할 수 있도록 했습니다. 이러한 방식으로 사용자는 데이터베이스의 데이터 유형 및 크기에 따라 배치 크기를 조정할 수 있습니다.

이 설정을 관리하려면 해당 모듈의 di.xml 파일에서 batchRowsCount 매개 변수를 편집하십시오. 이 기능을 지원하는 색인은 다음과 같습니다.

인덱스 일괄 처리 크기 변수를 조정하여 인덱서 성능을 조정할 수 있습니다. 인덱서가 한 번에 처리하는 엔티티 수를 제어합니다. 어떤 상황에서는 인덱싱 시간이 크게 줄어드는 것을 보았습니다.

예를 들어 B2B Medium과 유사한 프로필을 실행하는 경우 app/code/Magento/catalog/etc/di.xml의 구성 값 batchRowsCount을(를) 재정의하고 5000의 기본값을 1000(으)로 재정의할 수 있습니다. 이렇게 하면 기본 MySQL 구성을 사용하여 전체 인덱싱 시간을 4시간에서 2시간으로 단축할 수 있습니다.

웹 사이트별로 고객 그룹 및 공유 카탈로그 제한

많은 수의 제품 SKU, 웹 사이트, 고객 그룹 또는 공유 카탈로그는 제품 가격 및 카탈로그 규칙 인덱서의 실행 시간에 영향을 줍니다. 기본적으로 모든 웹 사이트가 모든 고객 그룹(공유 카탈로그)에 할당되기 때문입니다.

색인 지정 시간을 줄이기 위해 고객 그룹(공유 카탈로그)에서 특정 웹 사이트를 제외할 수 있습니다.

Redis 설정

경우에 따라 하나의 Redis 인스턴스만으로는 수신 요청을 처리할 수 없습니다. 이러한 상황을 해결하기 위해 권장할 수 있는 몇 가지 해결 방법이 있습니다.

먼저 Commerce을(를) 사용하면 각 캐시 유형에 대해 별도의 캐시 저장소를 구성할 수 있습니다. 이렇게 하면 Magento에 등록된 캐시 유형 수만큼 별도의 Redis 인스턴스를 설치할 수 있습니다. 실제로는 구성, 레이아웃 및 블록과 같이 가장 활발하게 사용되는 캐시에 대해 Redis 인스턴스가 필요할 수 있습니다.

또 다른 솔루션은 파일 시스템에 구성 캐시를 배치하고 다른 캐시를 Redis 서버로 이동하는 것입니다. 이 솔루션을 사용하면 모든 웹 노드에서 구성 캐시의 중앙 무효화를 위한 별도의 도구가 필요합니다.

자동으로 증가하는 노드 수로 병렬 읽기/쓰기 작업을 수행하는 Redis 클러스터를 사용할 수도 있습니다. Commerce은(는) 이 사례에 대한 구성을 제공하지 않지만 약간의 사용자 지정으로 시작할 수 있습니다.

RabbitMQ 설정

Adobe Commerce은 RabbitMQ을(를) 통해 구현된 메시지 큐를 지원합니다. Commerce은(는) B2B 카탈로그 작업 및 비동기 재고 업데이트를 포함하여 다양한 비동기 작업을 실행하는 데 이 서비스를 사용합니다. 작업 서버에 더 많은 작업을 추가하기 위한 모든 인터페이스는 제품과 함께 배포되며 서드파티 확장의 범위에서 사용자 지정 비동기 논리 구현에 사용할 수 있습니다. 다른 통합과 마찬가지로 Commerce은(는) 모든 권장 설정을 포함하고 프로덕션을 사용할 준비가 완료된 RabbitMQ에 대한 샘플 구성 파일을 제공합니다.

데이터베이스 분할

Adobe Commerce을 사용하면 증가하는 비즈니스의 요구 사항을 충족하도록 확장 가능한 데이터베이스 스토리지를 구성할 수 있습니다. 특정 도메인을 제공하는 세 개의 개별 마스터 데이터베이스를 설정할 수 있습니다.

추가 데이터베이스를 구성하려면 빈 데이터베이스를 만들고 다음 명령 중 하나를 실행해야 합니다.

기본 DB 체크아웃용

bin/magento setup:db-schema:split-quote

OMS 기본 DB용

bin/magento setup:db-schema:split-sales

이 명령은 특정 도메인 테이블을 주 데이터베이스에서 도메인 데이터베이스로 마이그레이션합니다. 해당 연결 및 제약 조건 처리를 허용하도록 Commerce 구성도 변경합니다.

체크 아웃과 Order Management을 위한 별도의 데이터베이스를 확보하면 데이터베이스 서버 간에 로드를 분산할 수 있습니다. 카탈로그 및 기타 작업의 가용성에 영향을 주지 않고 더 많은 체크아웃을 제공하고 초당 더 많은 주문을 처리할 수 있습니다. Flash 또는 활성 판매 기간이 있는 경우 데이터베이스를 분할하거나 자연적으로 로드가 높은 프로젝트에는 영구적으로 사용하는 것이 좋습니다. 데이터베이스 간의 현재 데이터 마이그레이션은 시스템 관리자의 감독하에 실행해야 합니다. 프로덕션 모드에서 데이터베이스를 분할하지 마십시오.

마스터 데이터베이스 외에 Commerce을(를) 사용하면 시스템에서 선언된 각 데이터 리소스에 대해 여러 개의 슬레이브 데이터베이스를 구성할 수 있습니다. 슬레이브 데이터베이스는 주 데이터베이스 또는 도메인 마스터 데이터베이스 중 하나의 전체 복제본 역할을 합니다. 특정 리소스에 대한 읽기 작업에 대해 발행됩니다.

다음 명령을 실행하여 슬레이브 데이터베이스를 추가할 수 있습니다.

bin/magento setup:db-schema:add-slave

이 명령은 구성 변경을 수행하지만 복제 자체는 구성하지 않습니다. 수동으로 수행해야 합니다.

마스터 데이터베이스를 분할하고 슬레이브 데이터베이스를 설정한 후 Commerce은(는) 요청 유형(POST, PUT, GET 등) 및 데이터 리소스를 기반으로 결정을 내리면서 특정 데이터베이스에 대한 연결을 자동으로 조절합니다. Commerce 또는 해당 확장에서 GET 요청에 대해 쓰기 작업을 수행하는 경우 시스템에서 연결을 슬레이브에서 마스터 데이터베이스로 자동으로 전환합니다. 이 방법은 마스터 데이터베이스와 같은 방식으로 작동합니다. 체크아웃 관련 테이블을 사용하는 즉시 시스템은 모든 쿼리를 특정 데이터베이스로 리디렉션합니다. 한편 모든 카탈로그 관련 쿼리는 기본 데이터베이스로 이동합니다.

구성 및 여러 마스터/슬레이브 구성의 이점에 대한 자세한 내용은
데이터베이스 성능 솔루션 분할.

미디어 콘텐츠 제공

Magento은 미디어 콘텐츠를 제공하고 전달하기 위한 특정 통합을 제공하지 않습니다. 모든 일반적인 접근 방식은 Magento에서 함께 사용할 수 있습니다.

미디어 콘텐츠를 제공하는 가장 쉬운 방법은 Varnish 서버에서 미디어 콘텐츠를 제공하고 캐싱하는 것입니다. 이 방법에서는 미디어 콘텐츠를 저장하기 위한 공유 파일 시스템이나 Varnish을(를) 가리키는 전용 서버로 가정합니다.

중간 및 고부하 환경의 경우 Fastly, Akamai 등과 같은 CDN(Content Delivery Network) 서비스를 사용하는 것이 좋습니다. 이러한 서비스를 사용할 때 Commerce은(는) 콘텐츠 업데이트에 클래식 가져오기 방법을 사용합니다. 해당 CDN 서비스에서 작동하도록 Commerce URL을 구성해야 합니다. 미디어 콘텐츠를 CDN으로 이동하면 인스턴스의 로드가 크게 줄어듭니다.

로그 저장소 구성

로그 저장과 다른 디스크 작업에 미치는 영향은 특히 로드가 많은 상황에서 웹 노드의 가용성에 영향을 미칩니다. 필요하지 않은 경우 로깅을 최소화하는 것이 좋습니다. 또한 액세스 속도가 빠른 별도의 스토리지 시스템에 쓰도록 로깅을 구성할 수도 있습니다. 로그 스토리지 액세스 시 발생하는 모든 병목 현상이 흐름의 일부로 쓰기 또는 읽기 작업을 기록하는 수신 요청 처리에 직접 영향을 줄 수 있습니다.