[ 기초부터 다지는 ElasticSearch 운영 노하우] 4장. ElasticSearch 기본 개념

eunsol Jo·2021년 9월 15일
elasticsearch
0

🔎   기초부터 다지는 ElasticSearch 운영 노하우

목록 보기
3/4
post-thumbnail

4.1 클러스터와 노드의 개념

ElasticSearch 클러스터 :

여러개의 ElasticSearch프로세스(=노드)들을 하나의 ElasticSearch프로세스 처럼 사용.

  • 어느 노드에 API를 요청해도 동일한 응답과 동작을 보장.

  • 하나의 노드를 이용해도, 단일 노드로 구성괸 클러스터로 동작.

  • 사용자의 요청을 클러스터 단위로 처리.

  • 하나의 노드가 죽어도, 다른 노드에서 응답 처리 가능 → 안정성

  • 고유한 클러스터명 + UUID(Universally Unique Identifier)로 노드들을 클러스터링함.

  • 클러스터 정보 확인

    $ curl localhost:9200
    {
      "name" : "eunsolJos-MacBook-Pro.local",  # 노드 이름
      "cluster_name" : "elasticsearch", # 클러스터명
      "cluster_uuid" : "FHHVK_dITWeUef1Jts8qmQ", # 클러스터UUID (클러스터 생성시 자동 부여)
      "version" : {
      "number" : "7.13.1",
      "build_flavor" : "default",
      "build_type" : "tar",
      "build_hash" : "9a7758028e4ea59bcab41c12004603c5a7dd84a9",
      "build_date" : "2021-05-28T17:40:59.346932922Z",
      "build_snapshot" : false,
      "lucene_version" : "8.8.2",
      "minimum_wire_compatibility_version" : "6.8.0",
      "minimum_index_compatibility_version" : "6.0.0-beta1"
      },
      "tagline" : "You Know, for Search"
    }

노드 역할

  1. 마스터(Master-eligible)

    • 클러스터 상태, 메타데이터 관리. 반드시 한대 이상.

    • 클러스터내 모든 노드 → 현재노드 상태, 성능정보, 가진 샤드의 정보를 마스터 노드에 알림.

    • 마스터 노드 → 모든 노드들에게 자신의 상태 보고.

    • 위 정보들을 수집/관리 하며 클러스터의 안정성을 확보하는 작업 진행.

    • 마스터 노드(Master) & 마스터 후보 노드(Master-eligible)

      실제 메타데이터를 관리하는 마스터 노드는 한개

      마스터 노드 3개로 구성된 클러스터? 나머지 두갠 마스터 후보 노드!

      마스터 노드 & 마스터 후보 노드 항상 같은 메타 데이터를 유지해, 장애발생시 중단없는 서비스 가능.

  2. 데이터(Data)

    • 사용자의 문서를 실제로 저장.
    • 검색요청을 처리해 결과 리턴.
    • 처리 하지 못할 경우, 다른 데이터 노드로 요청. (By. 마스터 노드로 부터 받은 클러스터 정보 바탕)

  3. 인제스트(Ingest)

    • 사용자 문서 저장(색인)전 문서내용 사전처리.
    • 데이터 노드 저장전 특정 필드값 가공. (사용자요청 → 인제스트 노드 → 데이터 노드)

  4. 코디네이트(Coordinate)

    • 사용자의 요청을 데이터 노드로 전달. + 데이터 노드로 부터 결과를 취합
    • 저장/처리는 하지 않는 데이터 노드.

  • 하나의 노드에서 모든 역할을 수행 가능

    실 서비스시에는 역할에 따라 노드 수를 구성한다.

     ---- ElasticSearch Cluster --------------------------------------
    |		                                                              |
    |		 ----Node----         ----Node----         ----Node----       |
    |		| master     |       | master     |       | master     |      |
    |		| coordinate |       | coordinate |       | coordinate |      |
    |		 ------------         ------------         ------------       |
    |		                                                              |
    |		 ----Node----         ----Node----         ----Node----       |
    |		| data       |       | data       |       | data       |      |
    |		| ingest     |       | ingest     |       | ingest     |      |
    |		| coordinate |       | coordinate |       | coordinate |      |
    |		 ------------         ------------         ------------       |
    ------------------------------------------------------------------

4.2 인덱스와 타입

인덱스

  • 사용자 데이터가 저장되는 논리적인 공간 (in RDBMS 데이터베이스)
  • 인덱스 이름은 클러스터 내에서 유일.
  • 인덱스에 저장된 문서들은 모든 Data Role 이 포함된 노드에 분산 저장됨.

타입

  • 인덱스 안의 데이터를 유형별로 논리적으로 나눈 공간 (in RDBMS 테이블)
  • 문서들을 논리적으로 한번더 나눈다는 의미. (테이블 = 타입) 유사.
  • doc 로 타입명 권고. (5.x 버전에선 로 시작하는 타입명 사용X)

※ 하나의 인덱스에는 하나의 타입만 가질 수 있다. (ElasticSearch 6.x 이후)

  • 멀티 타입을 허용하지 않게된 이유?

    하나의 인덱스에 서로 다른 타입에서 동일한 이름의 JSON문서 필드 존재 가능.

    인덱스 + JSON문서 필드로 조회 → 의도하지 않은 타입의 필드가 조회됨.

    ex.

    test_index / test_type1 / name필드

    test_index / test_type2 / name필드

    조회 : curl -XGET "http://localhost:9200/test_idex/_search?q=name:elasticsearch&pretty"

    ⇒ 두 타입에서 문서가 조회됨.

4.3 샤드와 세그먼트

샤드

  • 인덱스에 색인 되는 문서들이 저장되는 논리적인 공간

세그먼트

  • 샤드의 데이터들을 가지고 있는 물리적인 파일

  • 불변(immutable)

    수정 : 기존 색인된 문서를 update시 버전이 변경됨

    삭제 : 기존 문서를 삭제(불용처리)하고 → 동일한 문서id로 새로운 문서를 색인한다.

    ※ 세그먼트 병합

    세그먼트의 불변 특성으로 인해 update/delete 시 불용처리된 세그먼트들이 다수 존재.

    ⇒ 백그라운드에서 세그먼트 병합 처리를 한다.

    1. 불용처리된 세그먼트를 디스크에서 삭제

    2. 여러개의 작은 세그먼트들을 큰 세그먼크로 합침.

      ⇒ 검색 요청시 접근 파일의 수가 줄어, 적은 비용으로 빠른 응답을 줌

문서 저장 과정

  1. 샤드에 분리 저장(논리) by. 해시 알고리즘
  2. 색인된 문서는 시스템의 메모리 버퍼 캐시에 저장됨 (검색 불가능)
  3. refresh 과정 후 (10장)
  4. 디스크에 세그먼트 단위로 문서가 저장 (검색가능)

노드 & 인덱스 & 샤드 & 세그먼트

: 인덱스 (1:N) 샤드 (1:N) 세그먼트

4.4 프라이머리 샤드와 레플리카 샤드

ElasticSearch 클러스터 서비스의 연속성, 안정성 유지를 위한 필수 작업!

프라이머리 샤드

  • 최초 인덱스 생성시 개수 결정. 변경불가. → 중요하고, 어려운작업 (12장)
    curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_shards" : 5 }'
  • 어떤 문서를 어떤 샤드에 저장? by 해시 알고리즘 (프라이머리 샤드 번호 = Hash(문서ID) % 프라이머리 샤드 개수)
  • 만약 프라이머리 샤드의 개수가 변한다면, 문서들의 프라이머리 샤드 번호를 모두 변경해줘야함. 그래서 변경 불가.

레플리카 샤드

  • 프라이머리 샤드와 동일한 문서를 가짐
  • 사용자 검색 요청에도 응답 가능 → 응답속도 향상
  • N번 샤드 장애 → N번 샤드에 저장된 문서 조회 불가 → 레플리카(복제) 샤드를 만들어둠 → 안정성
  • 반드시 프라이머리 샤드와 다른 노드에 저장
  • 노드 장애 발생 → 해당 레플리카 샤드가 프라이머리 샤드로 변경 → 추가로 레플리카 샤드가 생성

레플리카 샤드 개수는 운영중에도 변경 가능

    curl -X PUT "localhost:9200/shard_idex?pretty" -H 'Content-Type: application/json' -d'{ "index.number_of_replicas" : 5 }'

0개로 하면, 존재하던거 모두 제거
검색성능에도 영향

4.5 매핑

매핑 : RDBMS의 스키마와 유사한 개념

  • JSON 문서의 키, 형태값을 정의
    • 정적매핑 : 미리 정의함
    • 동적매칭 : 최초 색인된 문서를 바탕으로 자동으로 매핑(높은편의성)
  • 매핑 생성후 문서는 매핑정보에 따라 색인 되어야함. (long타입으로 정의된 필드에 문자열 색인시 에러)

필드 데이터 타입 종류

  • String : text, keyword

  • Numeric : long, integer, short, byte, double, float, half_float, scaled_float

  • Date : date

  • Boolean : boolean

  • Binary : binary

  • Range : integer_range, float_range, long_range, double_range, date_range

  • 매핑정보 확인

curl -X GET "localhost:9200/firstindex/_mapping?pretty"

{
  "firstindex" : {    # 인덱스명
    "mappings" : {
      "_doc" : {    # 타입명
        "properties" : {
		  "필드명" : {
		    "type" : "text",   # text데이터타입의 매핑이 생성
			  "fields" : {
			    "keyword" : {  # keyword데이터타입의 매핑이 추가로 생성됨
				  "type" : "keyword",
				  "ignore_above" : 256
				}
			  }
		   },
		   ...
        }
      }
    }
  }
}
profile
eunsol Jo
Later never comes 👩🏻‍💻
이전 포스트

[ 기초부터 다지는 ElasticSearch 운영 노하우] 2장. ElasticSearch 기본 동작

다음 포스트

[ 기초부터 다지는 ElasticSearch 운영 노하우] 5장. 클러스터 구축하기

0개의 댓글