ElasticSearch 환경 설정 에 대한 문제점

장준혁·2024년 2월 2일

Mere elasticsearch

ElasticSearch

목록 보기

1/2

이전 글 : Elastic 도입

🤔 기존 설정의 문제점

이전 작성한 글의 환경 설정에 비해 많은 설정들이 변화 했다.
이전 작성글의 오류와 기존 설정에 대한 문제점을 확인 할 수 있었고 짚고 넘어 가려 한다.

💣 last_run_metadata 의 값이 업데이트 되지 않는 문제

last_run_metadata_path , tracking_column 을 설정 함에 따라 데이터의 역 색인 작업이 어느 기점 까지 진행 되었는지 last_run_metadata_path 를 통해 파일을 생성하여 시간을 저장하고 관리 하려 했다.

하지만 Logstash Containner 에서 tracking column not found 예외 Log 를 확인 할 수 있었으며 동일한 데이터를 계속 요청 및 업데이트 하고 있었다.

다양한 구글링 도중 여러 블로그 및 Stackoverflow 에서 tracking_column_type = "timestamp" 라는 conf 파일 설정을 해준 것을 확인 할 수 있었고 현재 사용하는 conf 파일에 맞춰 적용 해보았으나 Logstash Container 가 정상적으로 작동하지 않았다.

해당 문제의 원인은 Logstash 버전에 있었고 tracking_column_type 은 Logstash 6.2.4 이후 버전에는 Deprecated 를 확인 했다.

현재 사용하고 있는 Logstash 버전은 6.6.1 이였기에 설정 해줄 필요 없었다.

다른 시도는 기존의 conf 파일의 statement의 변경 이였다.

기존 : statement => "SELECT * FROM tags WHERE updatedAt >:sql_last_value"

변경 후 : statement => "SELECT tagId, tagName, UNIX_TIMESTAMP(updatedAt) as updatedAt FROM tags WHERE updatedAt > :sql_last_value order by updatedAt ASC"

기존 쿼리와 달리 updateAt 을 Timestamp 로 가져오기 위해 정확히 명시 해주었고 결과로 Logstash 도 not found 없이 정상적으로 파일이 업데이트 됨을 확인 할 수 있었다.
하지만 위와 같이 updateAt 으로 설정을 진행한 결과 동일한 데이터를 중복 요청 하는 것은 사라지지 않았다.

updatedAt 을 사용하는 대신 ID(정렬이 가능한 데이터) 를 사용해서 오름차순 정렬을 통해 문제 해결을 시도했고
ID 를 적용했을때는 발생하지 않는 문제를 통해 updateAt 설정에 무언가 오류가 있다고 판단했다.

문제점 을 해결 하기 위해 last_run_metadata 파일을 확인 했을때
Timestamp 값으로 저장될거라 생각했던 metadata 는 Timestamp의 형태를 가지고 있지 않았던 것이다.

이유는 Logstash 에서 기본적으로 BigInt 형태의 UNIX epoch Timestamp 를 사용 하여 자동변환 해주는 것에 있었다.

따라서 updateAt 으로 단순히 불러오던 값을 unix_timestamp 으로 변환해서 불러왔다.

변경 전 : statement => "SELECT tagId, tagName, UNIX_TIMESTAMP(updatedAt) as updatedAt FROM tags WHERE updatedAt > :sql_last_value order by updatedAt ASC"

변경 후 : statement => "SELECT tagId, tagName, unix_timestamp(updatedAt) as updatedAt FROM tags WHERE unix_timestamp(updatedAt) > :sql_last_value order by updatedAt ASC"
추가적인 요청없이 마지막 업데이트 정보를 정확하게 불러올 수 있게 되었다.