기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

부하 제한

응답 시간을 개선하고 중요한 워크플로에 사용할 수 있는 리소스를 늘리려면 불필요한 부하를 없애야 할 수 있습니다. 이 섹션에서 다루는 대부분의 솔루션은 절충안을 위한 결정입니다. 이는 애플리케이션에 영향을 미치므로 신중하게 고려해야 합니다. 다음과 같은 경우 이러한 솔루션 사용을 고려할 수 있습니다.

즉각적인 변경 사항에는 다음이 포함됩니다.

이러한 조치를 취하기 전에 장기적인 비즈니스 목표 및 위험의 맥락에서 평가하세요.

읽기 및 쓰기 워크로드 분리

MySQL 기반 애플리케이션을 실행할 때 흔히 사용되는 기법은 쓰기(프라이머리) 데이터베이스 인스턴스에서 하나 이상의 읽기 전용 데이터베이스 복제본으로 읽기 작업을 오프로드하는 것입니다. 읽기를 오프로드하면 기본 데이터베이스 인스턴스의 전체 부하를 줄이고 쓰기를 위한 공간을 확보할 수 있습니다. 복제본에 대한 즉각적인 쓰기 후 읽기 일관성에 의존하지 않는 읽기만 대상으로 해야 합니다. 보다 효율적인 방법은 모든 읽기 트래픽을 복제본으로 이동하고 복제가 지연되는 경우 쓰기 후 읽기를 재시도하도록 계획하는 것입니다. 보고 서비스와 같이 오프로드할 수 있는 독립적인 읽기 워크로드가 있습니다. 다른 읽기에는 읽기가 실행된 이유에 대한 컨텍스트가 잘 알려진 애플리케이션 수준에서 변경이 필요합니다.

또 다른 접근 방식은 애플리케이션과 데이터베이스 간의 중개자 역할을 하는 데이터베이스 프록시 솔루션을 구현하는 것입니다. 이 솔루션은 애플리케이션이 인식하지 못하는 상태에서 읽기 쓰기 분할 및 쿼리 라우팅 기능을 제공할 수 있습니다. ProxySQL, MariaDB MaxScale, ScaleARC 및 Heimdall Data는 사용 가능한 MySQL 호환 프록시 솔루션 중 일부입니다. 이러한 제품은 캐싱 또는 연결 멀티플렉싱과 같은 여러 추가 기능을 제공합니다. 트래픽이 갑자기 급증하여 애플리케이션 스택에 새로운 기술을 구현하는 경우, 의도하지 않은 부작용이 발생할 수 있는 추가 기능을 사용하기 전에 먼저 읽기/쓰기 쿼리를 분할하는 기본 기능부터 시작하여 동작과 성능을 테스트하는 것이 좋습니다.

오래된 데이터 보관 또는 삭제

데이터베이스 성능을 개선하는 또 다른 방법은 기록 데이터를 다른 테이블, 데이터베이스 또는 Amazon Simple Storage Service(S3)에 오프로드하는 방법입니다. 대부분의 데이터베이스는 애플리케이션의 전체 기록에 대한 모든 데이터를 인라인으로 보관합니다. 일반적인 사용자 대상 애플리케이션의 일반적인 상황에서 이렇게 하면 사용자가 이전 주문을 모두 볼 수 있습니다. 수요가 갑자기 급증하면 애플리케이션을 사용하는 많은 사용자가 신규 사용자이거나 신규 주문에 집중하고 있을 수 있습니다. 기록 데이터가 수십억 개의 행을 포함하는 단일 테이블에 온라인으로 존재하는 경우 상황이 더 복잡해집니다. 테이블에 큰 인덱스도 있을 수 있습니다. 테이블 데이터와 인덱스 모두 트리 구조로 저장됩니다. 테이블에 더 많은 항목을 포함하려면 트리의 수준이 더 많이 필요하므로 행에 액세스하려면 더 많은 I/O 작업이 필요합니다. 이렇게 하면 개별 레코드를 찾기 위한 액세스 시간이 늘어납니다. 더 중요한 것은 인덱스의 불필요한 부분이 데이터베이스 페이지 캐시(nnoDB 버퍼 풀)에 많이 있게 된다는 것입니다.

오래된 데이터를 별도의 테이블, 별도의 데이터베이스 또는 Amazon S3에 아카이브하면 최종 사용자의 액세스 시간을 줄이고 귀중한 캐시를 확보하고 전반적인 애플리케이션 성능을 개선할 수 있습니다. 이벤트 전에 오래된 데이터를 보관(예: 30일 또는 90일만 유지)하면 중요한 테이블의 테이블 및 인덱스 크기가 제한됩니다. 이 변경 사항을 적용하려면 기록 데이터를 보도록 명시적으로 요청하는 소수의 사용자에 대해서만 보조 위치에서 이전 데이터를 쿼리하도록 애플리케이션을 수정해야 합니다.

중요하지 않은 ETL 프로세스 연기

기본 데이터베이스 시스템에서 ETL 프로세스를 위해 데이터를 추출하면 대규모 환경에서 트랜잭션 및 동시 작업이 많이 발생하는 경우 안정성 위험이 발생할 수 있습니다. ETL 프로세스는 다음과 같은 특징으로 알려져 있습니다.

가변적이거나 예측할 수 없는 ETL 프로세스(예: 쿼리 INSERT INTO ... SELECT FROM ...;)는 부하 및 경합의 전반적인 변동성을 가중시켜 안정성 위험을 증가시킵니다.

가능하면 ETL 프로세스 실행 빈도를 연기하거나 줄입니다. 특히 중요한 기능을 제공하지 않는 경우에는 더욱 그렇습니다. 중요한 ETL 프로세스의 경우, 고정된 수의 행(예: LIMIT 절 사용)의 처리 배치와 같은 제한된 작업 단위에서 작동하도록 수정하거나, 별도의 트랜잭션을 사용하거나, DB 인스턴스의 최대 리소스 요구량을 줄이기 위해 장기간에 걸쳐 더 적은 양의 데이터를 끌어옵니다.

덜 중요한 애플리케이션 기능 끄기

급증하는 요청을 처리할 때 사용자 환경을 적절하게 저하시키거나 비핵심 기능을 제거하면 중요한 기능을 위한 데이터베이스 리소스를 절약할 수 있습니다. 이렇게 하려면 고객 환경에 약간의 변화가 필요할 수 있지만 사이트가 다운되는 것보다는 다른 흐름을 사용하는 것이 좋습니다. 항상 데이터베이스 호출을 수행하는 사이트 첫 페이지의 개인 설정 기능을 일시적으로 비활성화할 수도 있습니다. 또는 제품을 선택할 때 재방문 고객에게 맞춤형 오퍼를 제시하는 것을 중단할 수 있습니다. 기능을 일시적으로 끄면 데이터베이스에 액세스할 필요 없이 페이지를 캐시하거나 전달할 수 있습니다.

다른 예로는 데이터베이스 호출이 필요한 데이터 변경 사항을 확인하는 폴링 메커니즘이 있는 프런트엔드가 있습니다. 폴링 빈도를 줄이면 즉시 데이터베이스 호출 수가 감소합니다. 페이지 매김이 필요하거나 상위 결과에서 멀리 떨어진 정렬된 결과 세트를 검색할 수 있는 옵션을 사용자에게 제공하는 사용자 인터페이스의 경우 데이터베이스 호출 비용이 점점 더 증가합니다. 가장 비용이 많이 드는 데이터베이스 호출로부터 데이터베이스를 보호하려면 결과 세트의 페이지 수를 제한합니다. 애플리케이션 계층의 기능 플래그를 사용하면 애플리케이션 또는 데이터베이스 부하가 증가할 때 운영 팀이 기능을 끄거나 성능을 저하시킬 수 있습니다.