[엘라스틱 스택 8] 엘라스틱 서치란?

엘라스틱 서치란?

엘라스틱 서치를 설명하는 여러 정의들이 있다.

• 방대한 양의 데이터를 검색하고 집계하는 데 사용하는 분상형 엔진
• 분석 엔진
• 문서 저장소 또는 NoSQL 데이터베이스

엘라스틱서치에 대한 정의가 광범위한 이유는 엘라스틱서치가 상당히 유연한 제품이기 때문이다.

• 스키마에 상관없이 JSON 문서를 저장하는 데 사용
  • 구조화되지 않은 데이터를 허용
  • JSON 형식을 사용하고 RESTful API를 지원
• 문서 값들에 대해 집계를 수행할 수 있음
  • 메트릭을 계산하거나 데이터를 버킷(bucket)으로 그룹화하기 위함
• 대규모 코퍼스에 적절하고 자유로운 텍스트 검색 기능을 구현하는 데 사용

엘라스틱서치는 자바로 구현된 대중적이고 빠른 전문 검색 라이브러리인 아파치 루씬을 기반으로 만들어짐. 루씬은 분산화가 불가능하고 리소스를 관리하거나 요청을 처리하지 않는다. 엘라스틱서치의 책심은 사용자 친화적인 API를 통해 데이터 색인, 검색, 집계를 지원함으로써 루씬과 같은 라이브러리와 직접 작업하는 복잡함과 번거로움을 덜어준다.

엘라스틱서치에 도입된 개념

• 관련 데이터를 인덱스로 구성하고 그룹화하는 방법
• 검색 성능을 개선하고 하드웨어 장애에 대비한 레플리카 샤드
• 다양한 유형의 요청과 클러스터 작업을 처리하면서 노드 리소스를 관리하는 스레드 풀
• 클러스터에서 인덱스의 크기 및 이동을 관리하는 인덱스 수명주기 관리(Index Lifecycle Management, ILM)나 데이터 스트림 같은 기능

엘라스틱서치를 사용하는 경우

대용량 데이터의 수집, 저장, 검색

엘라스틱서치는 수평 확장이 가능한 데이터 저장소로, 클러스터에 노드를 손쉽게 추가해 사용 가능한 리소스를 늘릴 수 있다. 각 노드는 데이터에 대한 여러 개의 프라이머리 샤드를 저장할 수 있고, 각 샤드는 다른 노드에 복제(레플리카 샤드)할 수 있다. 프라이머리 샤드는 읽기과 쓰기 요청을 처리하는 반면, 레플리캬 샤드는 읽기 요청만 처리한다.

데이터베이스 샤딩

대규모 데이터베이스를 여러 머신에 저장하는 프로세스. 단일 머신 또는 데이터베이스 서버는 제한된 양의 데이터만 저장하고 처리할 수 있다. 데이터를 샤드라고 하는 더 작은 청크로 분할하고 여러 데이터베이스 서버에 저장함으로써 이러한 한계를 극복한다. 샤드는 분할된 데이터 청크를 논리적 샤드라고 한다. 논리적 샤드를 저장하는 시스템을 물리적 샤드 또는 데이터베이스 노드라고 한다. 하나의 물리적 샤드는 여러 개의 논리적 샤드를 포함할 수 있다.

대량 수집

• 초당 방출 (Emitted Per Second; EPS) 이벤트가 많은 단일 인덱스나 데이터 소스
• 초당 대량의 집계 이벤트를 수신하는 인덱스 그룹이나 데이터 소스 그룹

엘라스틱서치는 검색과 집계를 위해 대용량 데이터를 저장할 수 있다. 장기 보존 기간 동안 데이터 비용을 효율적으로 유지하기 위해 클러스터를 hot, warm, cold 데이터 계층 (data tier)으로 설계 할 수 있다. 수명주기 동안 디스크 또는 IOPS(Input/Output Operations Per Seconde, 초당 입출력 연산) 사양이 다른 노드 간에 데이터를 옮겨 속도가 느린 디스크 드라이브가 가진 비용 절감의 효과를 얻을 수 있다.

대용량 데이터를 다루는 몇 가지 예

• 중앙집중식 로깅 플랫폼 ( 여러 소스에서 다양한 애플리케이션과 보안, 이벤트, 감사 로그를 수집)
• 여러 장비에서 매트릭/추적 데이터/원격 측정 데이터를 처리하는 경우
• 대규모 문서 저장소에서 데이터를 수집하거나 많은 수의 웹 페이지를 크롤링하는 경우

텍스트 데이터에서 관련 검색 결과 가져오기

엘라스틱서치는 색인과 검색 잡업에 루씬을 활용한다. 문서를 엘라스틱서치로 수집할 때 문서의 구조화되지 않은 텍스트 컴포넌트를 분석해 텀(term) 형태의 구조로 추출한다. 텀은 역인덱스 데이터 구조로 유지된다. 역인덱스는 제목에 있는 단어(또는 텀)의 모음과 해당 단어가 포함된 페이지 목록이다. 따라서 역인덱스를 사용하면 관심 있는 검색어를 사용해 관련된 모든 페이지를 더 쉽게 찾을 수 있다.

여러 텀을 포함한 검색 문자열은 유사한 분석 과정을 거쳐 텀을 추출한 다음, 역인덱스에서 일차하는 모든 텀과 텀이 존재하는 문서를 찾는다. 유사도 측정 모듈을 기반으로 각 필드 매치에 대한 점수가 계산된다. 기본적으로 (텀 빈도/역문서 빈도를 기반) BM25 순위 함수를 사용해 검색 쿼리에 대한 문서의 관련서을 추정한다. OR 연산자(기본값)를 사용한 경우에는 결과의 합집합을, AND 연산자를 사용한 경우에는 결과의 교집합을 반환한다. 점수별로 결과를 정렬해 가장 높은 점수를 가진 결과를 먼저 나타낸다.

데이터 집계

• 버킷 집계(Bucket aggregation) : 버킷 집계를 사용해 필드 값 또는 값이 있는 위치의 범위를 기반으로 문서를 그룹화(및 하위 그룹화)할 수 있다
• 매트릭 집계(Metric aggregation) : 문서의 필드 값을 기반으로 메트릭을 계산할 수 있다. 지원되는 메트릭 집계에는 avg, min, max, count, cardianlity가 있다. 데이터의 버킷/그룹에 대한 메트릭도 계산할 수 있다.

키바나 같은 도구는 집계를 많이 사용해 엘라스틱서치의 데이터를 시각화한다.

거의 실시간으로 데이터 작업을 수행

비정형/반정형 데이터 처리

사전 정의된 스키마가 필요하지 않다. 스토리지/메모리 소비를 제어하고 이후에 데이터를 사용하는 방식을 알고 있는 경우, 인덱스의 스키마를 미리 구성할 수 있다. 스키마는 문서 구조의 유연성과 성숙도에 따라 동적으로 구성할 수도, 정밀하게 구성할 수도 있다.

엘라스틱서치는 수집된 문서를 기반으로 인덱스 매핑을 동적으로 업데이트한다. 필드에 대한 매핑이 없는 경우 엘라스틱서치는 필드의 값을 기반으로 데이터 유형을 추측한다.

엘라스틱서치 아키텍처의 특징

여러 노드(엘라스틱서치 인스턴스) 그룹이 하나의 클러스터를 형성해 함께 작동하는 분산형 시스템으로 구성 할 수 있다. 클러스터를 미션 크리티컬 환경에 배포할 때 다양한 아키텍처 특성에 맞게 설정할 수 있다.

수평적 확장성

엘라스틱서치는 수평으로 확장 가능한 시스템이다. 저장 용량, 읽기/쓰기 처리량도 클러스터에 노드를 추가해 거의 선형으로 증가시킬 수 있다. 클러스터에 노드를 추가하는 작업은 가동 중지 없이 비교적 쉽게 수행할 수 있다. 클러스터는 사용 가능한 노드 수가 변경되면 자동으로 노드 간에 샤드를 균등하게 재할당해 노드 간의 성능을 최적화하고 리소스 활용률을 향상시킬 수 있다.

고가용성과 탄력성

엘라스틱서치의 프라이머리 샤드는 읽기와 쓰기 작업 모두 처리할 수 있는 반면, 레플리카 샤드는 프라이머리 샤드의 읽기 전용 복제본이다. 기본적으로 엘라스틱서치는 클러스터의 서로 다른 노드에 있는 각 프라이머리 샤드마다 하나의 레플리카 샤드를 할당하므로 하나 이상의 노드에서 장애가 발생해도 요청을 완료할 수 있는 고가용성 시스템이 될 수 있다.

프라이머리 샤드가 보유한 노드가 손실되면 레플리캬 샤드 중 하나를 선택해 프라이머리 샤드로 승격 시키고 클러스터의 다른 노드에 레플리캬 샤드를 할당한다. 레플리카 샤드를 보유한 노드가 손실되면 클러스터의 다른 노드에 레플리카 샤드를 할당한다.

색인과 검색 요청은 샤드가 할당되는 동안에도 원할하게 처리할 수 있으며, 클라이언트 입장에서는 가동 중지가 거의 또는 전혀 발생하지 않는다. 검색 요청이 실패하더라도 이런 아키텍쳐 덕분에 후속 검색 요청은 성공할 가능성이 높다.

엘라스틱서치의 샤드 할당은 노드의 속성을 고려해 좀 더 정보에 입각한 할당 결정을 내릴 수 있게 도와준다.

재해 복구 가능성

데이터를 지속해서 저장하거나 스냅숏을 생성해서 재해 발생 시 복구 가능한 시스템을 만든다. 기존 파일시스템이나 AWS S3 같은 객체 스토리지에 데이터를 쓰도록 스냅숏을 구성할 수 있다. 스냅숏은 데이터에 대한 특정 시점의 복사본으로 효과적인 재해 복구 방안을 만들려면 **복구 시점 목표(Recovery Point Objective; RPO)에 따라 일정 간격으로 스냅숏을 생성해야 한다.

클러스터 간 작업

원격 클러스터 간에 데이터를 검색하고 복제해서 더욱 정교한 아키텍쳐 패턴을 만들 수 있다.

클러스터 간 검색(Cross-Cluster Search; CCS)은 외부 또는 원격 엘라스칙서치 클러스터에 있는 데이터를 검색할 수 있는 기능이다. 하나의 검색 요청을 로컬 클러스터는 물론 하나 이상의 원격 클러스터에서 실행할 수 있다. 각 클러스터는 코디네이터 노드(검색 요청을 처리하는 노드)로 응답을 반환하기 전에 자체 데이터에 대해 독립적으로 검색을 실행한다. 그런 다음 코디네이터 노드에서 서로 다른 클러스터의 결과를 결합해 클라이언트에 하나로 응답한다. 로컬 노드는 원격 클러스터에 속해 있지 않으므로 클러스터 내부 통신보다 클러스터 사이의 통신에 네트워크 지연 시간이 더 길어질 수 있다. 이는 서로 다른 지리적 리전에 있는 여러 독립적인 클러스터에서 통합 검색 기능을 갖도록 서로를 검색해야 하는 시나리오에서 유용하다.

클러스터 간 복제(Cross-cluster replication; CCR)를 사용해 로컬 클러스터에서 원격 클러스터로 인덱스를 복제할 수 있다. CCR은 리더/팔로워 모델을 기반으로 설계되어 리더 인덱스에 대한 모든 변경 사항을 팔로워 인덱스로 복제한다. 이 기능을 통해 데이터를 사용하는 위치에 더 가깝게 복제해서 서로 다른 지리적 리전에서 동일한 데이터 세드를 빠르게 검색할 수 있다. 또한 지역 간 다중화 요구사항에도 CCR을 자주 사용한다.

CCS와 CCR은 여러 리전의 클러스터를 사용해 데이터를 독립적으로 저장하고 검색하는 동시에 통합 검색과 지리적 다중화가 가능한 좀 더 복잡한 유스케이스에 사용할 수 있다.

보안

사용자 요청을 인증하고 권한을 부여하는 데 도움이 되는 보안 기능을 제공하고, 클러스터로 향하는 네트워크 통신과 클러스터 내부의 네트워크 통신을 암호화한다.

• 전송 중 암호화
  • TSL 사용. 노드 간 통신과 REST API 요청을 암호화
• 액세스 제어
  • 역할 기반 엑세스 제어(Role-Based Access Control; RBAC)
    • 사용자와 역할을 연결하는 방식
    • 역할에는 권한 목록 (읽기/쓰기/업데이트)과 이러한 권한을 적용할 수 있는 리소스가 포함됨
  • 속성 기반 액세스 제어(Attribute-Based Access Control; ABAC)
    • 사용자가 가진 속성 (ex. 위치, 비밀 취급 인가, 직무 역할)
    • 클러스터에서 사용자가 수행할 수 있거나 액세스할 수 있는 작업을 결정하는 보안 정책 사용
    • RBAC보다 세분화된 권한 제어
• 문서 보안
  • 사용자가 인덱스에서 액세스할 수 있는 데이터의 하위 집합을 지정
  • 사용자가 문서의 특정 필드를 액세스할 수 있거나 액세스할 수 없게 지정할 수 있음
• 필드 보안
  • 문서의 특정 필드에 대한 사용자 액세스를 제어
• 인증 제공자
  • 로컬/내장 인증 외에도, 액티브 디렉터리와 LDAP, SAML, 커베로스 같은 외부 사용자 인증 서비스를 사용할 수 있음
  • 시스템 계정과 프로그래밍 방식 엑세스에 API 키 기반 인증을 사용할 수 있음

엘라스틱서치의 한계

관계형 데이터 처리

엘라스틱서치는 관계형 데이터를 처리하도록 설계되지 않았다. 엘라스틱서치를 사용해 성능 대비 적은 비용으로 부모-자식 관계나 중첩 관계 같은 단순한 데이터 관계는 유지 할 수 있다. 검색과 색인/업데이트 성능을 향상시키려면 엘라스틱서치 데이터를 비정규화(데이터 조인을 피할 수 있게 중복 필드를 문서에 복제하거나 추가)해야 한다.

다양한 유형의 연결된 데이터에 대해 관계를 관리하고 일관성 규칙을 적용해서 정규화된 데이터 레코드를 유지해야 하는 데이터베이스라면 엘라스틱서치가 적합한 도구가 아닐 수 있다.

ACID 트랜잭션 수행

엘라스틱서치는 트랜잭션 개념이 없으므로 ACID 트랜잭션을 제공하지 않는다. 개별 요청 수준에서 ACID 속성을 보장할 수 있다.

• 쓰기 요청을 모든 활성 샤드에 전송해서 원자성을 달성.
  • 요청은 전부 성공하거나 전부 실패. 부분 성공 불가
• 프라이머리 샤드에 쓰기 작업을 해서 일관성을 달성.
  • 성공 응답을 반환하기 전 데이터 복제를 동기화.
  • 쓰기 요청 이후에 모든 샤드에서 모든 읽기 요청은 동일한 응답을 보게 됨
• 동시 쓰기 또는 업데이트를 간섭 없이 성공적으로 처리할 수 있으므로 독립성을 제공.
• 문서가 일단 엘라스틱서치에 기록되면 시스템 장애가 발생하더라도 유지할 수 있으므로 지속성을 제공함
  • 루씬 커밋은 상대적으로 비용이 많이 드는 작업이므로 엘라스틱서치의 쓰기 작업은 디스크의 루씬 세그먼트에 즉시 반영되지 않는다.
  • 대신 문서를 트랜잭션 로그에 기록했다가 주기적으로 디스크로 옮김
  • 어떤 노드가 데이터가 디스크로 옮겨지기 전에 강제로 중지되면 노드가 재가동될 때 translog에 기록된 작업을 루씬 인덱스로 복구