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

클러스터 캐시 관리

캐싱은 디스크 I/O를 줄이는 데 도움이 되므로 모든 데이터베이스 (DB) 에서 가장 중요한 기능 중 하나입니다. 가장 자주 액세스하는 데이터는 버퍼 캐시라는 메모리 영역에 저장됩니다. 쿼리가 자주 실행되면 디스크 대신 캐시에서 직접 데이터를 검색합니다. 이렇게 하면 속도가 더 빠르고 확장성과 애플리케이션 성능이 향상됩니다. shared_buffers파라미터를 사용하여 PostgreSQL 캐시 크기를 구성합니다. 자세한 내용은 메모리 (PostgreSQL 문서) 를 참조하십시오.

장애 조치 후 Amazon Aurora PostgreSQL 호환 에디션의 클러스터 캐시 관리 (CCM) 는 애플리케이션 및 데이터베이스 복구 성능을 개선하도록 설계되었습니다. CCM이 없는 일반적인 장애 조치 상황에서는 일시적이지만 심각한 성능 저하를 겪을 수 있습니다. 이러한 현상이 일어나는 이유는 장애 조치 DB 인스턴스가 시작될 때 버퍼 캐시가 비어 있기 때문입니다. 빈 캐시는 콜드 캐시라고도 합니다. DB 인스턴스는 디스크에서 읽어야 하는데, 이는 캐시에서 읽는 것보다 느립니다.

CCM을 구현할 때 선호하는 리더 DB 인스턴스를 선택하면 CCM은 캐시 메모리를 기본 또는 라이터 DB 인스턴스의 캐시 메모리와 지속적으로 동기화합니다. 장애 조치가 발생하면 기본 리더 DB 인스턴스가 새 라이터 DB 인스턴스로 승격됩니다. 웜 캐시라고 하는 캐시 메모리가 이미 있기 때문에 페일오버가 애플리케이션 성능에 미치는 영향을 최소화합니다.

클러스터 캐시 관리는 어떻게 작동합니까?

장애 조치 DB 인스턴스는 기본 라이터 DB 인스턴스와는 다른 가용 영역에 있습니다. 기본 리더 DB 인스턴스는 우선 순위 장애 조치 대상이며, 이는 계층 0 우선 순위 수준을 할당하여 지정됩니다.

CCM은 라이터 DB 인스턴스의 캐시를 기본 리더 DB 인스턴스와 동기화합니다. 리더 DB 인스턴스는 현재 캐시된 버퍼 주소 세트를 블룸 필터로 라이터 DB 인스턴스에 보냅니다. 블룸 필터는 요소가 집합의 구성원인지 여부를 테스트하는 데 사용되는 확률적이고 메모리 효율적인 데이터 구조입니다. 블룸 필터를 사용하면 리더 DB 인스턴스가 동일한 버퍼 주소를 라이터 DB 인스턴스로 반복해서 보내는 것을 방지할 수 있습니다. 라이터 DB 인스턴스는 블룸 필터를 수신하면 버퍼 캐시의 블록을 비교하여 자주 사용하는 버퍼를 리더 DB 인스턴스로 보냅니다. 기본적으로 버퍼는 사용 횟수가 3보다 크면 자주 사용되는 것으로 간주됩니다.

다음 다이어그램은 CCM이 라이터 DB 인스턴스의 버퍼 캐시를 기본 리더 DB 인스턴스와 동기화하는 방법을 보여줍니다.

CCM에 대한 자세한 내용은 Aurora PostgreSQL의 클러스터 캐시 관리를 통한 페일오버 후 빠른 복구 (Aurora 설명서) 및 Aurora PostgreSQL 클러스터 캐시 관리 소개 (AWS블로그 게시물) 를 참조하십시오. CCM을 구성하는 방법에 대한 지침은 클러스터 캐시 관리 구성 (Aurora 설명서) 을 참조하십시오.

제한 사항

CCM 기능에는 다음과 같은 제한 사항이 있습니다.

클러스터 캐시 관리 사용 사례

소매, 은행 및 금융과 같은 일부 산업의 경우 단 몇 밀리초의 지연으로 인해 애플리케이션 성능 문제가 발생하여 상당한 비즈니스 손실이 발생할 수 있습니다. CCM은 기본 데이터베이스 인스턴스의 버퍼 캐시를 기본 백업 인스턴스와 지속적으로 동기화하여 애플리케이션 및 데이터베이스 성능을 복구하는 데 도움이 되므로 장애 조치로 인한 비즈니스 손실을 방지하는 데 도움이 될 수 있습니다.