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

클러스터 캐시 관리

캐싱은 디스크 I/O를 줄이는 데 도움이 되기 때문에 모든 데이터베이스(DB)의 가장 중요한 기능 중 하나입니다. 가장 자주 액세스되는 데이터는 버퍼 캐시라는 메모리 영역에 저장됩니다. 쿼리가 자주 실행되면 디스크 대신 캐시에서 직접 데이터를 검색합니다. 이렇게 하면 속도가 더 빠르고 확장성과 애플리케이션 성능이 향상됩니다. shared_buffers 파라미터를 사용하여 PostgreSQL 캐시 크기를 구성합니다. 자세한 내용은 Memory(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은 기본 데이터베이스 인스턴스의 버퍼 캐시를 기본 백업 인스턴스와 지속적으로 동기화하여 애플리케이션 및 데이터베이스 성능을 복구하는 데 도움이 되므로 장애 조치로 인한 비즈니스 손실을 방지할 수 있습니다.