ElasticSearch Cluster를 검토해보고 사용할 때 정말 많은 사람들이 아무 생각 없이 Replica를 사용하고 있는데, 이는 굉장히 중요한 개념이므로 사용 목적에 대해 깊게 고민해보아야 한다.
Replica는 말 그대로 데이터의 복제본이다. 이를 사용하는 근본적인 이유는 당연히 하드디스크 즉, 물리장치의 장애가 발생했을때 데이터가 유실되는 것을 방지하기 위해 같은 내용의 데이터를 복사하여 다른 물리장치에 저장해두는 것이다. 이 목적이 Replica라는 개념이 나오게 된 이유이자 가장 근본적인 목적이기 때문에 elasticsearch cluster에서도 yellow라는 status를 따로 만들어 primary shard와 replica shard를 클러스터에 노드가 단 하나가 있더라도 절대 같은 노드에 배치될 수 없도록 해둔 것이다.
흔히 기업에서 업무를 할 때, 우리가 인프라를 요청하면 VM을 준다. 그리고 이 VM 위에서 elasticsearch cluster를 구축한다. 얼핏보면 전혀 문제가 없는 것 같지만, replica의 목적을 다시 한 번 생각해보면 굉장히 큰 허점이 보인다. 바로 VM을 서비스하고 있는 베어메탈에 장착된 하드디스크에 문제가 생기면, VM 하나만 다운되는 것이 아니고 그 베어메탈에 속한 모든 VM이 다운되고 그 말은 VM 환경에서는 우리가 elasticsearch cluster를 구축해놓고 다른 디스크에 데이터를 분산 저장한 것처럼 보일지라도 사실 물리적으로는 같은 디스크에 데이터를 사용하고 있다는 말이 된다.
당연히 기업에서 VM을 제공해줄 때 이 VM을 서비스하는데 사용되는 디스크를 레이드 구성 등을 통해 복구가 될 수 있도록 해두겠지만 Elasticsearch 운영 담당자는 VM 위에서 elasticsearch를 구성할 경우 자신이 설정한 replica는 물리적 디스크 장애에 대한 예방이 아닌 VM 자체 장애에 대한 예방책임을 반드시 인지하고 있어야 할 것이다.
+ replica는 부수적으로 검색 성능을 증가시키는데 기여한다. primary와 검색에 있어서는 동등한 수준의 업무를 한다. 그러나 데이터 동기화 이슈가 있기 때문에 데이터 삽입, 삭제, 업데이트 시에는 당연히 replica가 없을 때보다 오래걸린다.
'ElasticSearch' 카테고리의 다른 글
[Elasticsearch] Splitbrain이란? 클러스터 마스터 노드가 홀수개면 좋은 이유 (0) | 2020.09.09 |
---|---|
[ElasticSearch] Rolling Restart 방법 (0) | 2020.09.08 |