- Elasticsearch : Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득한다.
- Logstash : 다양한 소스 (DB, csv 파일 등) 의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 Elasticsearch 전달
- kibana : Elasticsearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링
- 인덱스 생성, 삭제
- 클러스터 노드의 추적, 관리
- 데이터 입력 시 할당할 사드 선택
- 클러스터 마다 하나의 마스터 노드 존재
- CRUD, 색인, 통계 등 데이터 작업 처리
- 모니터링 작업, 마스터 노드와 분리 필요
- 클러스터에 관한 것은 마스터 노드로 넘기고, 데이터와 관련된 것은 데이터 노드로 넘긴다.
- 라운드 로빈 방식 : 우선순위를 두지 않고 순서대로 시간 단위로 자원을 할당한다.
- 프라이머리 샤드(Primary Shard)
- 데이터의 원본, Elassticsearch에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청하게 되면서 레플리카 샤드에 복제된다.
- 레플리카 샤드(Replica Shard)
- 프라이머리 샤드의 복제본, 기존 원본 데이터가 무너졌을 때 그 대신 사용하면서 장애를 극복한다. 기본적으로 프라이어머리와 동일한 노드에 배정하지 않는다.
- 매 요청마다 새로운 세그먼트를 만들면 엄청난 용량이 필요하게 될 것이다. 이 때문에 인메모리 버퍼를 사용한다.
- 인메모리 버퍼는 일정 시간이 지나거나 버퍼가 가득차면 flush를 취하고 flush 작업이 수행되면서 시스템 캐시에 세그먼트가 저장된다. 이 시점부터 검색이 가능하다.
- 이후에 일정 시간이 지나면 commit을 통해서 물리적인 디스크에 세그먼트를 저장해주고 저장된 세그먼트는 하나로 병합된다. 병합을 통해 세그먼트가 줄어들기 때문에 검색 성능은 향상된다.
- RDBMS의 데이터베이스에 하나의 테이블만을 가진다고 생각하면 된다.
- RESTful API를 사용한다는 것은 다양한 플랫폼에서 응용이 가능해진다.
- 수정이 불가하며 Update 시 데이터를 삭제하고 다시 생성한다.
- 다중 스레드 환경에서 동시성 문제 회피(수정이 불가하므로 lock 필요없음)
- 높은 시스템 캐시 활용도(수정할 경우 시스템 캐시 삭제 및 재생성이 필요)
- ES는 인메모리 버퍼를 사용하므로 쓰기와 읽기를 동시에 작업할 경우 세그먼트가 생성되기 전까지 해당 데이터를 검색할 수 없다.
- 분산 시스템 구성의 특징 때문에 시스템 비용 소모가 큰 트랜잭션, 롤백을 지원하지 않는다.
- 세그먼트에서 데이터가 업데이트하면 soft-delete를 하고 수정된 데이터를 새로운 세그먼트로 생성한다.
Reference :