문제 상황 최근에 현업에서 업무를 진행하면서 특정 시간마다 DB에 부하가 심하게 발생하여 해당 클러스터를 사용하는 전체 서비스에 장애가 발생하고 있었습니다. 중복된 이벤트가 발생하여 수많은 콜백 로직이 동시다발적으로 수행되어 DB에 수많은 쿼리가 한 번에 요청되는 것이 문제였습니다. 과도한 Write 요청으로 인해 락을 획득하지 못하는 작업이 대기열에 쌓이고 Timout에 도달하여 오류가 발생했습니다. Unable to acquire ticket with mode '2' within a max lock request timeout of '5ms' milliseconds. 와 같은 에러 메시지에서도 볼 수 있듯이, 락 모드 '2'인 배타적 락을 획득하기 위한 티켓을 획득하지 못하여 문제가 발생하는 것입니다..
회사에서 기능 요구 사항으로 아이템 검색 기능을 추가해달라는 요구를 받았었습니다. Mongodb의 Atlas Search와 ElasticSearch 중에서 어떤 도구를 선택해야 좋을지 고민이 됐었는데 결론적으로 Elastic Search를 선택했습니다. 이 도구를 선택한 이유는 쿼리를 정말 다양하게 사용할 수 있다는 점과, atlas search에 비해서 참고할 자료가 많았던 점, DB와 함께 사용하면서 복잡한 쿼리 혹은 데이터 색인 과정에서 리소스를 어느 정도 필요로 한다는 점이었습니다. 하지만, 마냥 장점만 있던 것은 아니었습니다. 사이드 이펙트가 꽤 단순하지 않아서 골머리를 앓았던 경험이 떠오르네요.그래서 이번에는 엘라스틱 서치를 도입하면서 어떤 문제점을 맞닥뜨렸는지 공유드리겠습니다. DB - ES..
엘라스틱서치에서 가장 중요한 작업중 하나가 인덱스의 매핑을 어떻게 설정할 것인가? 라고 생각합니다. 기본적으로 동적 매핑을 true로 설정하면 내부적으로 알아서 입력하는 데이터에 맞춰 매핑을 설정하지만, 이렇게 설정되는 매핑이 내가 원하는 설정대로 되지 않는 경우도 종종 발생합니다. 예를 들어 단순 정수값을 데이터로 넣었을 때, 작은 값이더라도 long 타입으로 매핑하기 때문에 비효율적입니다. date 타입 또한 마찬가지로 ISO Date에 맞추지 않은 date 값이 존재하므로 text 타입으로 매핑될 수도 있습니다. 그리고 매핑을 수정해야 하는 경우도 이따금씩 발생합니다. 예를 들어, 커스텀 분석기를 수정하거나, 기존 필드에 새로운 서브 필드를 추가해야 하는 경우가 그러합니다. 하지만, 엘라스틱 서치의..
1. MySQL에서의 문자 데이터 타입 의문점 MySQL와 PostgreSQL에서는 String 데이터 타입으로 VARCHAR와 TEXT가 존재합니다. 전자는 가변길이 문자열로 고정된 길이 없이 자유자재로 길이가 달라지는 문자열의 데이터 타입을 의미합니다. 이와 반대로 고정 길이 문자열인 CHAR은 지정한 길이의 문자열을 튜플에 저장하게 됩니다. MySQL에서는 CHAR를 쓰는 게 VARCHAR 보다 성능이 조금 더 좋다고 하죠? 그 이유는 여러 가지가 있는데 조사한 바론 대표적으로 아래의 이유가 있었습니다. CHAR는 고정된 길이의 공간에서 값이 저장되므로, 값의 수정이 발생하는 경우 그 공간을 재활용할 수 있다. 하지만, VARCHAR의 경우 현재 저장된 값보다 긴 문자열로 수정이 될 때, 새로운 영..
