(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 4 ) - 안티패턴과 멱등성 관리

이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ

엘라스틱서치에 원본 데이터를 싱크할 때, 주의해야하는 점이 있다.

Why Marking Source Records is an Anti-Pattern

엘라스틱서치 인덱싱 필요 여부를 체크하는 방법 중, 원본 테이블에 필드를 하나 추가하는 방법이 있다. 

그런데 이건 안티패턴이다. 하면 안된다.

안티패턴인 이유 

1. 엘라스틱서치 데이터 복제와 원본 데이터 간의 커플링이 높아진다. 그러면 유지보수가 어렵다. 

   - 장애로 실제 인덱싱 여부와 원본 데이터에 저장된 인덱싱 여부가 달라질 수도 있다. 

2. 전체 테이블을 재인덱싱해야하는 경우, 전체 테이블을 업데이트해줘야한다.

  UPDATE SET reindex=TRUE  이런식으로.. 

  그래서 테이블 크기가 큰 경우, 롱쿼리가 발생할 수 있다.

3. 필드를 추가해야하기 때문에 서버 리소스를 잡아먹는다. 

Error Handling in Replication

데이터를 복제하는 작업에서 발생하는 에러를 잘 관리하려면, 멱등성이 보장되도록 데이터를 관리해야한다.

이는 스크립트를 한번만 돌리면 과거 데이터가 고대로 복구되는 상황을 의미한다.

1. 큐로 데이터를 복제뜨는 경우

큐에 있는 데이터들이 엘라스틱서치에 정상적으로 복제된 경우에만 큐를 비워줘야 한다. 

만약 큐에 있는 데이터가 모두 복제되지 않은 상태에서 큐를 비우는 경우, 어디서부터 다시 복제를 해줘야하는지 알 수 없다.

2. 원본 데이터에 범위를 설정해서 데이터를 복제뜨는 경우

복제 범위에 들어간 데이터들이 정상적으로 복제된 경우에만, 최종 데이터 싱크 범위 저장소(last_range_end)을 갱신해줘야한다. 

만약 복제 범위에 들어간 데이터가 모두 복제되지 않은 상태에서 "최종 데이터 싱크 범위 저장소"를 갱신하는 경우,

어디서부터 다시 복제를 해줘야하는지 알 수 없다.