Technology/Elastic
[Elastic] - ElasticSearch(엘라스틱 서치) 란?
nam_ji
2024. 4. 5. 09:00
ElasticSearch(엘라스틱 서치) 란?
ElasticSearch란
- ElasticSearch는 Apache Lucene(아파치 루씬) 기반의 Java 오픈 소스 분산 검색 엔진입니다.
- 데이터 저장소가 아니기 때문에 MySQL 같은 데이터베이스를 대체할 수 없습니다.
- 방대한 양의 데이터를 신속하고 거의 실시간으로 저장, 검색, 분석할 수 있습니다.
- ElasticSearch는 검색을 위해 단독으로 사용되기도 하며, ELK(ElasticSearch / Logstash / Kibana) 스택으로 사용되기도 합니다.
ELK (ElasticSearch / Logstash / Kibana) 란
- ELK는 분석 및 저장 기능을 담당하는 ElasticSearch, 수집 기능을 담당하는 Logstash, 이를 시각화 하는 도구인 Kibana의 앞 글자만 딴 단어입니다.
- ELK는 접근성과 용이성이 좋아 Log 및 데이터 분석 도구로 자주 사용되는 기술입니다.
- Logstash
- 다양한 소스 (DB, csv파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 ElasticSearch로 전달합니다.
- ElasticSearch
- Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득합니다.
- Kibana
- ElasticSearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링합니다.
- Logstash
ElasticSearch와 RDBMS 비교
RDBMS | ElasticSearch |
schema | mapping |
database | index |
table | type |
row | document |
column | field |
ElasticSearch를 Rest API를 사용한 RDBMS 관계
ElasticSearch | Relational Database | CRUD |
GET | SELECT | READ |
PUT | UPDATE | UPDATE |
POST | INSERT | CREATE |
DELETE | DELETE | DELTE |
ElasticSearch 핵심 개념
1) 클러스터
- 클러스터는 하나 이상의 노드(서버)가 모인 것이며, 이를 통해 전체 데이터를 저장하고 모든 노드를 포괄하는 통합 색인화 및 검색 기능을 제공합니다. 클러스터는 고유한 이름으로 식별되는데, 기본 이름은 elasticsearch입니다.
- 어떤 노드가 어느 클러스터에 포함되기 위해서는 이름에 의해 클러스터의 구성원이 되도록 설정되기 때문에 이 이름은 매우 중요합니다.
- 노드가 잘못된 클러스터에 포함될 위험이 있으므로 동일한 클러스터 이름을 서로 다른 환경에서 재사용하면 안됩니다.
- 예를 들어 개발, 스테이징, 프로덕션 클러스터에 loggin-dev, loggin-stage, loggin-prod라는 이름을 사용해야 합니다.
- 클러스터에 하나의 노드만 있는 것은 유효하며 또한 각자 고유한 클러스터 이름을 가진 독립적인 클러스터를 여러개 둘 수도 있습니다.
2) 노드
- 노드는 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여합니다. 노드는클러스터처럼 이름으로 식별되는데, 기본 이름은 시작 시 노드에 지정되는 임의의 UUID(Universally Unique Identifier)입니다. 기본 이름 대신 특정 이름으로 정의가 가능합니다.
- 네트워크의 어떤 서버가 ElasticSearch 클러스터의 어떤 노드에 해당하는지 식별해야 하기 때문에 노드의 이름은 관리의 목적에서 중요합니다.
- 노드는 클러스터 이름을 통해 어떤 클러스터의 일부로 구성될 수 있습니다. 기본적으로 각 노드는 elasticsearch라는 이름의 클러스터에 포함되도록 설정됩니다. 즉, 네트워크에서 다수의 노드를 시작할 경우 (각각을 검색할 수 있다고 가정하면) 이 노드가 모두 자동으로 elasticsearch라는 단일 클러스터를 형성하고 이 클러스터의 일부가 됩니다.
- 하나의 클러스터에서 원하는 개수의 노드를 포함할 수 있습니다. 뿐만 아니라 현재 다른 어떤 elasticsearch 노드도 네트워크에서 실행되고 있지 않은 상태에서 단일 노드를 시작하면 기본적으로 elasticsearch라는 이름의 새로운 단일 노드 클러스터가 생깁니다.
3) 인덱스
- 색인(인덱스)은 다소 비슷한 특성을 가진 문서의 모음입니다. 이를테면 고객 데이터에 대한 색인, 제품 카탈로그에 대한 색인, 주문 데이터에 대한 색인을 각각 둘 수 있습니다. 색인은 이름(모두 소문자)으로 식별되며, 이 이름은 색인에 포함된 문서에 대한 색인화, 검색, 업데이트, 삭제 작업에서 해당 색인을 가르키는데 쓰입니다.
- 단일 클러스터에서 원하는 개수의 색인을 정의 할 수 있습니다.
4) 타입
- 하나의 색인에서 하나 이상의 유형을 정의할 수 있습니다. 유형이란 색인을 논리적으로 분류 / 구분한 것이며 그 의미 체계는 전적으로 사용자가 결정합니다. 일반적으로 여러 공통된 필드를 갖는 문서에 대해 유형이 정의 됩니다. 예를 들어 블로그 플랫폼을 운영하고 있는데 모든 데이터를 하나의 색인에 저장한다고 가정하면 이 색인에서 사용자 데이터, 블로그 데이터, 댓글 데이터에 대한 유형을 각각 정의 할 수 있습니다.
5) 도큐먼트
- 도큐먼트는 색인화 할 수 있는 기본 정보 단위입니다. 예를 들어 어떤 단일 고객, 단일 제품, 단일 주문에 대한 도큐먼트가 각각 존재할 수 있습니다. 이 문서는 JSON(JavaScript Object Notation)형식인데, 이는 널리 사용되는 인터넷 데이터 교환 형식입니다.
6) 샤드 & 리플리카
- 색인은 방대한 양의 데이터를 저장할 수 있는데, 이 데이터가 단일 노드의 하드웨어 한도를 초과할 수도 있습니다. 예를 들어 10억 개의 문서로 구성된 하나의 색인데 1TB의 디스크 공간이 필요한 경우, 단일 노드의 디스크에서 수용하지 못하거나 단일 노드에서 검색 요청 처리 시 속도가 너무 느려질 수 있습니다.
- ElasticSearch는 이러한 문제를 해결하고자 색인을 이른바 샤드(Shard)라는 조각으로 분할하는 기능을 제공합니다. 색인을 생성할 때 원하는 샤드 수를 간단히 정의할 수 있습니다. 각 샤드는 그 자체가 온전한 기능을 가진 독립적인 색인이며 클러스터의 어떤 노드에서도 호스팅할 수 있습니다.
- 샤딩이 중요한 2가지 이유가 있습니다.
- 컨테츠 볼륨의 수평 분할 / 확장이 가능해집니다.
- 작업을 여러 샤드에 분산 배치하고 병렬화 함으로써 성능 / 처리량을 늘릴 수 있습니다.
- 샤드가 분산 배치되는 방식 및 그 도큐먼트가 다시 검색 요청으로 집계되는 방식의 매커니즘은 모두 ElasticSearch에서 관리하며 사용자에게는 투명하게 이루어집니다.
- 언제든 오류가 일어날 가능성이 있는 네트워크 / 클라우드 환경에서는 어떤 이유에서든 샤드 / 노드가 오프라인 상태가 되거나 사라지게 될 경우에 대비하여 Fail - Over 매커니즘을 마련하는 것이 매우 유익하고 바람직합니다. 이러한 취지에서 ElasticSearch에서는 색인의 샤드에 대해 하나 이상의 복사본을 생성할 수 있는데, 이를 리플리카 샤드 (Replica Shard), 줄여서 리플리카라고 합니다.
- 리플리카를 만드는 복제가 중요한 2가지 이유가 있습니다.
- 샤드 / 노드 오류가 발생하더라도 고가용성을 제공합니다. 따라서 리플리카 샤드는 그 원본인 기본 샤드와 동일한 노드에 배정되지 않습니다.
- 모든 리플리카에서 병렬 방식으로 검색을 실행할 수 있으므로 검색 볼륨 / 처리량을 확장할 수 있습니다.
- 요약하자면 각 색인은 여러 개의 샤드로 분할할 수 있습니다. 또한 하나의 색인은 복제하지 않거나 (리플리카 없음) 1회 이상 복제할 수 있습니다. 복제되면 각 색인은 기본 샤드(복제 원본 샤드)와 리플리카 샤드(기본 샤드의 복사복)를 갖습니다. 샤드 및 리플리카의 수는 색인별로, 색인 생성 시점에 정의할 수 있습니다. 색인이 생성된 다음 언제라도 탄력적으로 리플리카의 수를 변경할 수 있으나, 샤드 수는 사후 변경이 불가합니다.
- 기본적으로 ElasticSearch의 각 색인은 기본 샤드 5개, 리플리카 1개를 갖습니다. 따라서 클러스터에 최소한 2개의 노드가 있다면 색인은 기본 샤드 5개, 리플리카 5개(완전한 리플리카 1개)를 가지므로 색인당 총 10개의 샤드가 존재합니다.
- 각 ElasticSearch 샤드는 Lucene 색인입니다. 단일 Lucene 색인이 포함할 수 있는 문서 수의 최대 한도가 있습니다. Lucene-5843에 따르면 2,147,483,519`개(= Integer.MAX_VALUE - 128)입니다. {ref/cat-shards.html[`_cat/shards] API를 사용하여 샤드 크기를 모니터링 할 수 있습니다.
ElasticSearch를 사용하는 이유
- 속도
- ElasticSearch는 Lucene을 기반으로 구축되기 때문에, 전체 텍스트 검색에 뛰어납니다. ElasticSearch는 또한 겅의 실시간 검색 플랫폼입니다. 이것은 문서가 색인될 때부터 검색이 가능해질 때까지의 대기 시간이 아주 짧다는 뜻입니다. 이 대기 시간은 보통 1초입니다. 결과적으로 ElasticSearch는 보안 분석, 인프라 모니터링 같은 시간이 중요한 사용 사례에 이상적입니다.
- 분산적
- ElasticSearch에 저장된 문서는 샤드라고 하는 여러 다른 컨테이너에 걸쳐 분산되며, 이 샤드는 복제되어 하드웨어 장애 시 중복되는 데이터 사본을 제공합니다. ElasticSearch의 분산적인 특징은 수백 개의 서버까지 확장하고 페타바이트의 데이터를 처리할 수 있게 해줍니다.
- 광범위한 기능 세트와 함께 제공
- 속도, 확장석, 복원력뿐 아니라, ElasticSearch에는 데이터 롤업, 인덱스 수명 주기 관리 등과 같이 데이터를 훨씬 더 효율적으로 저장하고 검색할 수 있게 해주는 강력한 기본 기능이 다수 탑재되어 있습니다.
- Elastic Stack은 데이터 수집, 시각화, 보고 간소화
- Beats와 LogStash의 통합은 ElasticSearch로 색인하기 전에 데이터를 훨씬 더 쉽게 처리할 수 있게 해줍니다.
Kibana는 ElasticSearch 데이터의 실시간 시각화를 제공하며, UI를 통해 애플리케이션 성능 모니터링(APM), 로그, 인프라 메트릭 데이터에 신속하게 접근할 수 있습니다.
- Beats와 LogStash의 통합은 ElasticSearch로 색인하기 전에 데이터를 훨씬 더 쉽게 처리할 수 있게 해줍니다.