[AWS] RDS DB 유저 커넥션 폭증시 트러블 슈팅 / btr_search_latch편

 

안녕하세요, 오늘은 RDS DB 커넥션 수가 폭증했을 때 트러블 슈팅하는 방법에 대해서 알아보겠습니다.

 

당시의 enhanced monitoring으로 살펴본 RDS 인스턴스의 카운터 지표는 다음과 같습니다.

 

 

데이터 베이스 로드는 다음과 같았습니다.

 

해당 내용 AAS를 확인하시면, btr_search_latch가 확인이 됩니다.

이 내용으로 인해서 인스턴스의 읽기 성능이 저하될 수 있는데요,

 

Adaptive Hash Index의 경우 InnoDB가 자체 내부 해시 인덱스를 구축하고 가장 자주 사용되는 인덱스 페이지에 대한 데이터를 저장하는 데이터 구조입니다.

 
AWS 공식 문서에서는 해당 내용을 확인하시면 Adaptive Hash Index를 활성화하는 것으로 권장하고 있습니다.
해당 내용 확인시에는 인스턴스 파라미터 그룹에 innodb_adaptive_hash_index가 지정되어 있지 않았었는데요,

이 내용을 활성화하여 해당 내용을 해소할 수 있었습니다.

 

이를 통해서 Aurora DB의 경우 워크로드를 일시적으로 Writer Instance로 리디렉션 진행할 수 있습니다.

 
RDS for MySQL을 사용하시는 경우에는, 파라미터 그룹 수정을 진행하시면 됩니다.

DB 파라미터 그룹에 innodb_adaptive_hash_index라는 파라미터가 있습니다.

 

MySQL InnoDB의 대표 인덱스는 B-Tree 구조로 되어 있습니다.

 
데이터는 Primary Key 순으로 정렬되어 관리되고, Secondrary Key는 인덱스키+PK를 조합으로 정렬이 되어 있습니다.
 
즉, 특정 데이터를 찾기 위해서는 Secondrary Key에서 PK를 찾고, 그 PK를 통해 다시 원하는 데이터로 찾아가는 형태로 데이터가 처리됩니다. 트리의 가장 큰 강점은 데이터 접근 퍼포먼스가 데이터 증가량에 따라서도 결코 선형적으로 증가하지 않다는 점에 있습니다.
 
데이터가 증가하더라도 데이터 접근에 소요되는 비용은 크게 증가되지 않음에도, 상황에 따라 효율이 좋지 않습니다. 

 

즉, 전체 데이터를 대상으로 해시값을 생성하지는 않는다는 말인데요, Adative Hash Index에 할당되는 메모리는 전체 Innodb_Buffer_Pool_Size의 1/64만큼으로 초기화됩니다.
 
최소 메모리 할당은 저렇게 할당되나, 최대 사용되는 메모리 양은 알 수는 없습니다.
서버의 특성마다 다르겠지만, Apdaptive Hash Index를 활성화한 경우 반드시 현재 사용하고 있는 관련 메모리를 모니터링을 해야합니다. (서버마다 사용량이 다를 수 있습니다.)
 
자주 사용되는 자원을 해시를 통해서 직접 접근하기 때문에, 내부적인 락(이를테면 Mutex)으로 인한 지연이 줄어듭니다. 게다가 B-Tree의 데이터 접근 비용(O(LogN))에 비해, 해시 데이터 접근 비용인 O(1)으로 굉장히 빠른 속도로 데이터 처리가 가능한 것이죠. 단 자주 사용되는 자원 만을 해시로 생성하기 때문에, 단 건 SELECT로 인하여 반드시 해당 자원을 향한 직접적인 해시 값이 만들어지지 않습니다.
 
말씀드린 바와 같이 Adaptive Hash Index를 활성화 하신다면 특정 데이터가 집중적으로 액세스 될 경우
효과를 볼 수 있습니다. 다만, 앞서 말씀드린 바와 같이 원하시는 만큼의 성능이 나오지 않을 수 있기 때문에
인스턴스 타입을 일시적으로 상향하시는 것을 권장드립니다.
 
자세한 내용은 하기 링크를 참조해 주시기 바랍니다.
 
참조 링크 : https://tech.kakao.com/2016/04/07/innodb-adaptive-hash-index/
https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html

MySQL :: MySQL 5.7 Reference Manual :: 14.5.3 Adaptive Hash Index

 

그럼 오늘 하루도 좋은 하루 보내셔요!

감사합니다.