[Elasticsearch] Elasticsearch Engineer Training -3

• 본 포스트는 상명대학교 Elasticsearch 엔지니어 트레이닝 과정을 이수하고 작성한 글입니다.
  
• 개인이 간단하게 실습을 위해 작성한 포스트이며 Enterprise 급 운용을 위한 글이 아님을 밝힙니다.

Day03

Logstash

• 데이터 파이프라인 도구
• 실습했던 파일, 표준 입력 외에도 여러가지 input 방법이 존재한다.
• 데이터 filter 섹션을 잘 작성하는 것이 중요
• 엘라스틱 서치는 데이터를 가공하는 것에 시간을 많이 써야한다.
  • 읽고자 하는 형식으로 데이터를 가공하지 않으면 나중에 후회한다.
• logstash는 사용자가 만든 conf 파일을 실행 시 마다 컴파일하고, 라이브러리로 올려 빌드하기 때문에 시간이 많이 소요된다.
  • 따라서 FileBeat로 데이터를 logstash로 보내 필터링을 거쳐 elasticsearch로 보내는 것이 효율적
  • filebeat.yml의 output.logstash 설정을 logstash를 바라보게 수정.
  • logstash conf 파일 input 섹션에도 Beat로 입력을 받을 준비를 하면 된다.

grok filter

• 일반 표현식 패턴을 사용하여 필드와 구문을 모두 일치시키는 필터

geoip filter

• IP 주소를 읽어들여 해당 국가 정보를 출력
• 또한, 사용자의 디바이스, 브라우저 정보 등 여러 Agent 정보를 통해 시각화 가능

데이터 성질과 필드

Text와 Keyword의 차이

• Text Field : 그룹핑이 필요없고 그냥 읽기만 하면 되는 속성

  • 게시판 제목
  • 사람 이름

• Keyword Field : 그룹핑이 필요하고(Category), 집계(Count) 목적이거나, 쪼개서 들어가면 안되는 속성

  • Song title
  • Company

• ignore_above Field : 값으로 들어가는 숫자 만큼의 문자열 길이가 아니라면 의미가 없다고 판단하는 속성

• 데이터에 date 필드가 있다면 date 형태로 저장

새로운 Index 만들어 넣기 - PUT

• 인덱스는 conf 파일을 넣어 만들 수 있지만 Dev Tools에서 자체적으로 인덱스를 만들어 내는 방법이 있다. HTTP Method 중 하나인 PUT을 사용하여 넣는 법을 알아보자.
• 아래 형식을 꼭 지켜서 작성해준다.
• 저장한 인덱스에 Message를 넣어서 생성하고자 한다면 블럭을 넣어 아래와 같이 필드 : 값 형태로 작성한다. 해당 데이터는 _search 연산 시 _source 필드에 저장된다.

  1. PUT _index/_type/_id
  
  2. PUT _index/_type/_id
      {
          "field" : "value"
          ...
      }

저장된 Index 조회하기 - GET

GET _index/_type/_id     //PUT으로 저장한 데이터 조회

GET _index/_search
GET _index/_count

Index의 _Settings

GET _index/_settings

• number_of_shards : 데이터 Primary Shard
• number_of_replicas : Optional Shard (노드 손상 시 샤드 데이터를 복구하는 복사본의 수)
  • replica는 하나 이상 원칙

Replica Concept

• 같은 노드에 프라이머리 샤드와 리플리카는 절대 같이 두면 안된다.
  • 노드 마다 그 노드의 리플리카를 다른 노드로 분산시켜 노드 크래쉬에 대응할 수 있어야 한다.
• Document는 _id % 샤드 수로 나머지 연산에 의해 분산 저장
  • 서비스의 영속성, 안전성

Elasticsearch Node and Shards

Master Node

• 클러스터 안에 여러 노드 존재
  • my_cluster 안에 node1, node2, node3

Elasticsearch Communication

• 노드 간의 통신
  • transport : 노드 사이의 내부 통신
  • HTTP : REST API로 외부와의 통신

HTTP communication

• 9200번 포트 사용

Transport communication

• 9300번 포트 사용

Special values for network settings

Discovery module

Cluster State and Master Nodes

GET _cluster/state

• 클러스터의 상태 정보값

  • 클러스터 이름
  • 라우팅 테이블
  • 노드 : 노드의 갖은 정보들
  • 스냅샷 : 데이터 loss 방지를 위해 히스토리들을 저장
  • etc

• 노드들이 클러스터 상태들을 공유

  • 만약 node1이 클러스터의 마스터 노드일 때
    • 다른 노드들에게 클러스터 상태를 뿌려줌
    • 인덱스 생성
    • 노드들의 이탈, 조인 요청 등의 변경되는 클러스터 상태값들을 담당
    • 두개의 노드들이 하나의 인덱스를 만들기 위해 각각의 샤드들을 페어링 한 상태이다.
      • 그런데 한 노드가 끊어져버렸다고 가정함
      • 페어링된 두개의 샤드 중 하나가 끊어져버려 인덱스를 만들 수 없을 때
      • 여유 공간이 생긴다면 마스터 노드가 담당하여 다시 페어링한다.

• 마스터 노드는 데이터 저장을 안하기 때문에 해당 노드에는 좋은 하드웨어 스펙을 가질 필요가 없다.

Node Roles

• 마스터 후보 노드
• 데이터 노드
  • 최근 티어링으로 세분화 됨
  • 데이터의 라이프사이클 관리 측면에서 바뀌게 됨
• Ingest 노드
  • 데이터 삽입 용도
  • PUT Command (Ingesting)
  • indexing
• 머신 러닝 노드
  • ML 작업
  • 다른 데이터 대비 이상 징후 관측
• 변환 노드
  • 데이터 포맷 변환
• 원격 클러스터 클라이언트 노드
  • 각 클러스터 간 상호 커뮤니케이션
  • 상호 Search

Configuring node roles

• elasticsearch.yml

Data Nodes

• 마스터 노드 역할은 하지 않고 데이터만 저장하는 노드
• 실제로 인덱싱된 데이터를 저장하고 있는 노드

  node.master = false
  node.data = true

Ingest Node

• 로그스태쉬, 파일비트가 없어도 입력된 데이터에 대한 ingest 파이프라이닝이 가능하다
• 싱글 인스턴스에서도 가능하지만 엘라스틱서치에서 하기에는 리소스 낭비다.

Machine Learning Nodes

• 머신러닝 실행
• 머신러닝 API 핸들링
• node.ml 에서 Configuration

Coordinating Node

• 노드의 수신과 특정 클라이언트의 요청을 핸들링
  • 모든 노드는 암묵적으로 coordinating node이다.
  • 데이터 저장은 필요없음
    • 오로지 Coordinate 역할만 수행

Understanding Shards

• Index는 Shard 라는 단위로 분산되어 각 Node들에 저장된다.
• 샤드는 업계 용어이며, 분산 환경에서 많이 쓰임

PUT sangmyung/_doc/2

GET indices

노드의 인덱스 모음 디렉토리
/mnt/data/nodes/0/indices/

//1. Dev Tools에서 인덱스 조회하여 PUT operation으로 생성한 인덱스의 uuid값 조회

//2. indices 폴더 내에서 생성한 uuid(인덱스 고유번호)를 이름으로 한 디렉토리 찾기
/mnt/data/nodes/0/indices/

//3. 특정 샤드의 위치 
/mnt/data/nodes/0/indices/`uuid`/0/index/
//여러 파일들이 생성됨

• 어떤 경우로 샤드의 양이 많아지면 성능이 좋지 않을 수 있다.
  • 어떤 파일들이 생성되는지 알고, 샤드 디자인을 잘해야 할 필요가 있다.

Primary vs Replica

• write는 프라이머리 샤드부터, 그다음 Replica

• Read Throughput을 높이고 싶다면 replica의 양을 늘리면 된다.

  • 어느것을 읽던 같은 데이터이기 때문.

• Replica 운영 목적에서는 아무 문제 없지만, Crash issue에선 필수적으로 필요하다.

• 긍정적 의미의 Oversharding

• 부정적 의미의 Oversharding

  • 서비스에 하루 접속 건수 10건

• 고가용성

  • 프라이머리 샤드가 있던 노드가 사라져도 같은 정보를 갖고 있는 리플리카가 프라이머리 역할을 대신 할 수 있다.

GET _cluster/health

• status : yellow

Shard allocation

• UNASSIGNED

  • 노드 준비 상태

• INITIALIZING

• STARTED

  • 프라이머리가 STARED 되면 리플리카를 만들 수 있는 상태

• RELOCATING

  • 여러 노드 중 한 노드가 여유 공간으로 분산되는 상태

  • 사용률이 95% 이상일 때 read는 되지만 write는 안되는 상태

  • 임계치가 넘어가서 샤드의 상태값이 RELOCATED되어 여유 노드를 찾아다니는 상태이다.

• Node 1, 2에 각 프라이머리와 리플리카가 꽉 차게 저장되어 있을 때 빈 노드 3,4가 들어온다면,

  • Node 1 : P0 RELOCATING 에서 Node 4 : P0 INITIALIZING 되어 옮겨짐
    • 이후 Node 4 P0 STARTED 되고 분산 완료

• 데이터의 쓰기는 프라이머리가 우선, 노드 하나의 프라이머리가 없고, 리플리카만 존재하면 클러스터엔 Red 상태가 된다.

  • 엘라스틱은 그 때 남아있는 리플리카를 프라이머리로 승격시켜 운용시킨다.
  • Yellow 상태로 변경

Elasticsearch의 자료형

• 정수 입력은 long
• 소수점 입력은 float

인덱스를 새로 넣고 mapping

PUT test-number/_doc/3
{
  "value" : 15.3
}
GET test-number/_mapping

• 저장된 자료형은 float로 저장한다.

GET test-number/_search

• 입력한 그대로 값이 조회되는 것을 확인할 수 있다.
• 하지만 쿼리 시에는 조건에 따라 다르게 조회되는 경우가 발생하므로 주의

Analyzer

`Elasticsearch 엔지니어 트레이닝 코스 오프라인 출석부`

• Standard analyzer는 text 분석 시 대문자를 만나면 소문자로 변환한다.

  • 띄어쓰기 단위로 토크나이징

• keyword 일 때는 변환없이 위 모든 텀이 들어가게 된다.

  • keyword는 서치가 어렵다.

• English analyzer

  • a, the 같은 관사들은 모두 무시하고 토큰화
  • 단수, 복수형을 무시하고 단어의 어원을 찾음 : Stemming
  • https://www.elastic.co/guide/en/elasticsearch/reference/current/stemming.html

• 노리 analyzer

English analyzer

GET _analyze 
{
  "analyzer": "english",
  "text" : ["Elasticsearch a the 엔지니어 트레이닝 오프라인 교육 출석부"]
}

standard analyzer

GET _analyze 
{
  "analyzer": "standard",
  "text" : ["Elasticsearch a the 엔지니어 트레이닝 오프라인 교육 출석부"]
}

GET _analyze 
{
  "analyzer": "standard",
  "filter" : ["lowercase", "asciifolding"]
  "text" : ["Elasticsearch a the 엔지니어 트레이닝 오프라인 교육 출석부"]
}