Elasticsearch 기본 개념을 잡아보자

Elasticsearch 기본 개념을 잡아보자

NRT(Near Realtime)

Elasticsearch는 NRT(준실시간) 검색 플랫폼입니다.

즉 문서를 색인화하는 시점부터 문서가 검색 가능해지는 시점까지 약간의 대기 시간 약 1초정도 걸린다고 보시면 됩니다.

Cluster(클러스터)

클러스터는 전체 데이터를 가지고 모든 노드간의 통합 인덱싱 및 검색이 가능한 1개 이상의 노드(서버)집합 입니다.

기본값이 elasticsearch인 유니크한 이름으로 구분 됩니다.

클러스터 이름이 중요한 이유는 각각의 노드가 1개의 클러스터에 속해질 수 있으며 설정될 때 클러스터 이름을 가지고 구성이 됩니다.

권고드리는 것은 다른 환경일지라도 동일한 클러스터 이름으로 구성을 하지 마시기 바랍니다.

그렇지 않으면 결국에는 각각의 노드가 원치 않은 다른 클러스터에 구성될 수 있습니다.

예를 들면, 개발, 스테이징, 운영 환경에 대한 클러스터가 필요한 경우에는 개발은 logging-dev, 스테이징은 logging-stage, 운영은 logging-prod로 구분하시기 바랍니다.

1개의 노드를 가지는 1개의 클러스터로 구성해도 문제 없고, 유니크한 이름을 가지는 다수의 클러스터로 구성해도 좋습니다.

하나의 Cluster는 여러개의 Node로 구성됩니다.

여기서 Node가 위치한 물리적인 서버는 아래와 같이 분리 될 수 있습니다.

노드 Node

노드는 클러스터의 부분이 되는 단일 서버로써, 데이터를 저장하고 클러스터에 참여하여 인덱싱과 검색 역할을 수행합니다.

클러스터와 같이 노드가 기동될 때 랜덤 UUID(Universally Unique IDentifier)를 기본값으로 하여 각각의 노드를 식별합니다.

기본값을 원치 않는다면 각각의 노드에 명명할 수 있습니다.

노드는 클러스터 명을 가지고 참여여부를 설정합니다.

별도로 정의하지 않는다면 elasticsearch라는 클러스터명을 가지고 노드가 구성됩니다.

그 의미는 아무런 설정없이 동일 네트워크 상에서 다수의 노드를 기동하게 된다면, elasticsearch라는 이름으로 단일 클러스터가 자동으로 구성이 되는 것 입니다.

네트워크 상에서 어떤 노드가 클러스터에 구성되었는지 관리하기 쉽게하려면 각각의 노드에 이름을 정의하는 것을 추천합니다.

단일 클러스터에서 원하는 많큼 다수의 노드를 구성할 수 있습니다.

게다가 현재 네트워크에 기동중인 다른 노드가 없는 상태에서 노드 하나를 기동시키면 자동으로 elasticsearch라는 단일 클러스터를 만들게 됩니다

인덱스 Index

인덱스는 비슷한 형질을 가지는 문서 간의 집합이라고 보시면 됩니다.

예로들면 고객정보, 제품카탈로그, 주문정보 같은 것 입니다.

소문자로 구성된 이름으로 구분이 되며 인덱스 이름은 문서에 대한 인덱싱/검색/갱신/삭제 등을 수행할 때 참조값으로 사용됩니다.

단일 클러스터에서 원하는 대로 다수의 인덱스를 정의할 수 있습니다.

각 Node에는 Index라는 개념으로 데이터를 저장합니다.(Apache Lucene 기반)

참고로 Index는 Document/Type으로 구성이 됩니다. 

Document는 JSON기반으로 구성되며 Index상에 여러개로 구성되어 있는 실제 데이터 레코드이며, Type은 각 Index별 카테고리화를 할 수 있도록 제공하는 개념이라 보시면 됩니다.

SQL 과 비교하면 아래와 같은 형식이 됩니다.

타입 Type

인덱스안에 1개 이상의 타입을 정의할 수 있습니다.

타입은 당신이 정의한 의미기준으로 인덱스를 논리적 분류/파티션입니다.

일반적으로 문서의 공통 속성들을 가지고 정의됩니다.

예로 블로그 시스템을 구성하고 단일 인덱스에 모든 데이터를 구성한다고 하면 타입은 사용자, 블로그, 댓글로 구분될 것 입니다.

문서 Document

문서는 인덱싱된 정보의 기본 단위입니다.

예로 하나의 고객 정보, 제품 정보, 주문 정보 입니다.

문서는 어디든 호환이 가능한 JSON(JavaScript Object Notation)으로 구성됩니다.

인덱스/타입과 함께 원하는 만큼의 문서를 저장할 수 있습니다.

문서는 물리적으로 인덱스에 있기는 하지만, 필히 인덱스 안에 있는 타입을 기준으로 인덱싱/할당 되어야 합니다.

샤드 & 리플리카편집

색인은 방대한 양의 데이터를 저장할 수 있는데, 이 데이터가 단일 노드의 하드웨어 한도를 초과할 수도 있습니다.

예를 들어 10억 개의 문서로 구성된 하나의 색인에 1TB의 디스크 공간이 필요할 경우, 단일 노드의 디스크에서 수용하지 못하거나 단일 노드에서 검색 요청 처리 시 속도가 너무 느려질 수 있습니다.

Elasticsearch는 이러한 문제를 해결하고자 색인을 이른바 샤드(shard)라는 조각으로 분할하는 기능을 제공합니다.

색인을 생성할 때 원하는 샤드 수를 간단히 정의할 수 있습니다.

각 샤드는 그 자체가 온전한 기능을 가진 독립적인 "색인"이며, 클러스터의 어떤 노드에서도 호스팅할 수 있습니다.

샤딩은 무엇보다도 2가지 이유로 중요합니다.

콘텐츠 볼륨의 수평 분할/확장이 가능해집니다.

작업을 (어쩌면 여러 노드에 위치한) 여러 샤드에 분산 배치하고 병렬화함으로써 성능/처리량을 늘릴 수 있습니다.

샤드가 분산 배치되는 방식 및 그 문서가 다시 검색 요청으로 집계되는 방식의 메커니즘은 모두 Elasticsearch에서 관리하며 사용자에게는 투명하게 이루어집니다.

언제든 오류가 일어날 가능성이 있는 네트워크/클라우드 환경에서는 어떤 이유에서든 샤드/노드가 오프라인 상태가 되거나 사라지게 될 경우에 대비하여 페일오버 메커니즘을 마련하는 것이 매우 유익하고 바람직합니다. 이러한 취지에서 Elasticsearch에서는 색인의 샤드에 대해 하나 이상의 복사본을 생성할 수 있는데, 이를 리플리카 샤드(replica shard), 줄여서 리플리카라고 합니다.

이처럼 리플리카를 만드는 복제는 무엇보다도 2가지 이유로 중요합니다.

샤드/노드 오류가 발생하더라도 고가용성을 제공합니다. 따라서 리플리카 샤드는 그 원본인 기본 샤드와 동일한 노드에 배정되지 않습니다.

모든 리플리카에서 병렬 방식으로 검색을 실행할 수 있으므로 검색 볼륨/처리량을 확장할 수 있습니다.

요약하자면 각 색인은 여러 개의 샤드로 분할할 수 있습니다.

또한 하나의 색인은 복제하지 않거나(리플리카 없음) 1회 이상 복제할 수 있습니다.

복제되면 각 색인은 기본 샤드(복제 원본 샤드)와 리플리카 샤드(기본 샤드의 복사본)를 갖습니다.

샤드 및 리플리카의 수는 색인별로, 색인 생성 시점에 정의할 수 있습니다.

색인이 생성된 다음 언제라도 탄력적으로 리플리카의 수를 변경할 수 있으나, 샤드 수는 사후 변경이 불가합니다.

기본적으로 Elasticsearch의 각 색인은 기본 샤드 5개, 리플리카 1개를 갖습니다.

따라서 클러스터에 최소한 2개의 노드가 있다면 색인은 기본 샤드 5개, 리플리카 샤드 5개(완전한 리플리카 1개)를 가지므로 색인당 총 10개의 샤드가 존재하게 됩니다.