Check Point
- 엘라스틱 서치가 복제를 하는 방법과 이유
- 엘라스틱 서치의 스냅샷을 사용하는 방법
- 엘라스틱 서치의 복제와 스냅샷의 차이
- 엘라스틱 서치의 복제로 인한 성능 향상 방법
단편화?
단편화적으로 인덱스는 기본적으로 단일 샤드로 구성된다.
샤드가 저장된 노드가 파괴되면 어떻게 되나?
데이터가 손실되기 때문에 사본이 존재하지 않게 된다. 하드웨어 스캔은 언제라도 실패할 수 있는 큰 문제가 된다. 결과적으로 클러스터를 실행하는 데 사용되는 하드 드라이브가 많을수록 고장 날 확률이 높아진다. 이러한 문제는 분명히 해결해야하고, 안전하게 저장소를 관리할 수 있는 방법이 된다.
내결함성에 대한 내구성과 페일오버(장애 조치) 메커니즘해결책?
- 엘라스틱 서치는 기본적으로 샤드 복제를 지원하며 이는 기복적으로 활성화되어 있다.
- 대부분 데이터베이스는 복제 기능이 있지만 복잡하고 사용에 대한 런닝커브가 있다. 하지만 엘라스틱 서치는 기본베이스로 디폴트로 복제가 설정되어 있고 무료로 사용가능하다.
엘라스틱 서치가 복제를 어떻게 작동시킬까?
- 인덱스는 여러개의 샤드 내에 데이터를 저장하도록 설정되어 있다. (여러 개의 노드에 저장될 수 있다.) 마찬가지로 복제도 인덱스 레벨에서 구성된다.
- 복제는 인덱스에 있는 각 조각의 복사본을 만드는 것이고, 이러한 사본을 복제본 또는 복제 조각이라 한다.
- 복제 샤드는 다음과 같이 조회 요청을 처리할 수 있는 샤드의 완전한 복사본이다.
- 인덱스를 생성할 때 각 조각의 복제본 수를 선택할 수 있다. (1개가 디폴트값)
- 복제가 됨에 따라 인덱스에는 N개의 레플리카 샤드를 포함하고 있다.
물리적 복사본을 가지고 있는데 디스크 전체가 작동을 멈추고 모든 데이터가 손실되면 어떻게 도움이 될까?
- 이러한 사태를 막기위해 복제된 샤드는 원래 조각과 절대 같은 노드에 저장되지 않는다. 결과적으로 노드 하나가 사라지면 적어도 하나의 데이터 복사본이 다른 노드에서 사용가능한 상태로 변경된다.
- 남아 있는 복사본 수는 인덱스에 대해 구성된 복제본 수에 따라 달라진다. (클러스터가 포함하고 있는 노드의 수에 따라)
- 복제는 하나 이상인 클러스터에만 해당되며 사용 가능한 유일한 노드가 다운되면 복제에 대한 도움이 되지 않는다.
- 이러한 이유로 엘라스틱 서치는 여러 개의 노드를 가진 클러스터에만 추가할 수 있도록 되어 있다.
복제 방법의 설명 및 예
- 단일 노드로 구성된 클러스터로 시작된다.
- 인덱스는 각 샤드를 한 번 복제하도록 구성되어 있지만 복제 샤드는 단일 노드만 실행 중이기 때문에 그렇지 않다.
- 이러한 상황은 개발 환경에 적합하다. 그 이유는 데이터가 손실되는 경우에만 불편해지기 때문이다. 상용 환경에서 데이터를 잃는 위험을 감수하는 짓을 하면 안되기때문에 클러스터에 노드를 추가해야 한다.
- 해당 노드는 성능과 같은게 필요하기보다 독립된 하드웨어에서 실행되도록 보장만 해주면 된다. 그래야 손실이 잃어났을때 단일 장애로 인한 지점 파괴가 없어진다.
- 엘라스틱 서치는 클러스터에 노드를 추가했음을 인식하면 자동으로 복제를 시작한다.
- 이때 샤드를 두 번 복제하도록 인덱스를 구성했다면 두개의 복제본 샤드가 다른 노드에 놓였겠지만 현재 작동되는 원리의 개념과 동일하게 복제된다.
복제한 샤드의 수에 따른 선택?
- 일반적으로 하나 또는 두 개의 복제도 괜찮을 수 있지만 중요도에 따라 구성이 달라질 수 있다.
- 두 노드가 동시에 고장 나면 다른 데이터 소스에서 저장된 데이터를 복원할 수 있을까? (관계형 데이터 베이스 처럼)
- 데터를 복구하는 동안 사용이 불가능해도 괜찮나?
- 엘라스틱 서치를 사용하여 검색 기능을 강화하는 경우, 개인 워드프레스 블로그같은 작은 규모에서는 이 리스크에 대해 괜찮다.
- 하지만 큰 규모의 병원 내나 사용자 관련해서 데이터를 만이 축척하는 중요한 사항에서는 이러한 리스크는 정말 위험하기 때문에 이러한 위험을 감수할 필요가 없다. 과감하게 늘려주자.
- 결과적으로 간단한 시스템은 한번이면 충분할 수 있지만, 중요한 시스템의 경우 두 번 이상 복제하는 것을 추천한다. 결과적으로 상용환경에서는 최소 2개의 노드가 필수적이며, 데이터 손실로부터 자산을 보호하기 위해 꼭 대비하자.
스냅샷 기능?
- 엘라스틱 서치도 스냅샷 기능을 지원하기 때문에 데이터 손실방지를 어느정도 극복할 수 있다.
- 스냅샷을 통해 특정 시점으로 복원이 가능해진다.
- 특정 지점(인덱스 레벨)이나, 전체 그륩(클러스터)에 대해 스냅샷을 지정할 수 있다.
스냅샷이 있는데 왜 데이터 복제라는 기능이 필요할까?
| 복제 | 스냅샷 |
|---|---|
| 복제란 데이터 손실을 예방하는 방법이다. 하지만 복제는 실시간 데이터에만 작동한다. | |
| “본래 의미는 복제가 주어진 인덱스가 현재 시점에 저장하는 데이터를 잃지 않도록 보장하는 것이다.” | 스냅샷은 클러스터의 현재 상태를 내보낼 수 있다. (특정 인덱스)파일로 내보낸다. 이 파일은 다음에 특정 상태로 복원하는 데 사용할 수 있다. |
| (클러스터 상태 또는 인덱스) |
- EX ) 인덱스에 저장된 수백만 개의 문서를 재구성해야한다고 했을때
- 사용자는 개발 단계에서 시험해봤기 때문에 잘될거라고 생각한다.
- 어떤 시점에서도 복구할 수 있도록 하기 위해서 쿼리를 실행하기 전에 인덱스를 스냅샷을 찍음
- 쿼리를 실행하고 확인해봤더니 라이브 인덱스에 저장된 문서와 테스트 문서가 다르기 때문에 계획되로 진행되지 않음
- 문서가 엉망이 되서 되돌려야 한다. 근데 여기서 문제는 복제는 도움이 되지 않는다. 복제는 최신 데이터를 잃지 않도록 보장하기 때문이다. 이미 이전에 실행할 때 최신 데이터를 잃게 된다.
- 이때 여기서 마지막에 스냅샷으로 저장하여 성공한 데이터를 이용해서 복구하면 된다.
- 사용자는 개발 단계에서 시험해봤기 때문에 잘될거라고 생각한다.
스냅샷이 사용되는 시기?
- 스냅샷은 일반적으로 일일 백업에 사용된다.
- 일반적으로 데이터를 저장하기전에 수동 스냅샷을 사용하여 저장하게되면 뭔가 잘못되었을때 변경 사항을 되돌릴 수 있기 때문.
그러면 복제는?
- 복제는 색인이 된 노드 장애로부터 복구되고 계속 서비스를 제공할 수 있도록 보장한다.
- 복제의 두 가지 목적?
- 데이터 손실을 방지하는 것
- 인덱스 처리량에 대해 성능을 높이는 데 사용할 수 있다.
복제를 이용해서 성능을 높인다는 이야기는 무엇일까?
사용자는 쿼리 병목현상을 경험하기 시작하는데 이것을 다룰 수 있는 방법을 찾게된다.
결과적으로 생각할 수 있는 방법들은
- 클러스터에 노드를 추가하는 것이고, 2개의 노드로 구성된 클러스터가 생성된다.
- 하나의 기본 샤드와 하나의 복제본 샤드만 있으면 둘 이상의 노드에 분산시킬 수 없기 때문에 도움이 되지 않는다.
- 추가 노드를 사용하려면 결과적으로 샤드의 수를 늘리거나 복제품의 수를 늘려야한다.
하지만 다른 노드는 필요 없고 하드웨어를 늘리는 추가적인 비용을 감수하고 싶지도 않을것이다. 이러한 상황에서 처리할 수 있는게 바로 레플리카의 수를 하나 이상으로 늘리는 것이다.
- 노드가 2개밖에 없기 때문에 인덱스의 가용성을 증가시키는 것이 아니라, 인덱스의 처리량을 증가 시킨다.
- 이게 가능한 이유는 복제한 샤드도 그 자체로 완전한 기능을 하는 인덱스기 때문이다.
- 결과적으로 두 개의 레플리카 샤드를 동시에 쿼리를 참조할 수 있게 되면서 성능향상이 이루어진다.
노드 안에 레플리카 샤드를 늘리면 성능이 빨라지는 이유가 뭘까?
- 엘라스틱 서치가 쿼리가 실행될 곳을 자동으로 조정해 좌표화 하기 때문이고, 병렬화 시킨다.
- 엘라스틱 서치는 문자열 기반으로 지정된 쿼리를 실행할 조각을 자동으로 선택한다.
- 3개의 검색 요청이 동시에 들어오는 경우
- 세 가지의 다른 청크로 실행하며, 기본 샤드와 두 복제의 샤드를 참조한다.
- 결과적으로 3개의 쿼리를 가지게 되고, 3개의 쿼리를 동시에 실행하면 동일한 인덱스를 찾는다.
노드가 두 개 뿐인데 어떻게 그게 가능할까?
- 10년 미만의 모든 CPU는 다중코어이며, 멀티 쓰레드로 다중 작업이 능통하기 때문이다.
- 이런 예제에서 두 복제본 샤드를 호스팅하는 노드가 각 샤드에서 병렬로 검색 쿼리를 수행하여 인덱스의 성능을 높인다.
Kibana Console에서 인덱스 생성 하기
# 인덱스 생성
PUT /pages
# 클러스터 상태 확인
GET /_cluster/health
{
"cluster_name": "elasticsearch",
"status": "yellow", # 옐로 상태로 변경됨?
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 14,
"active_shards": 14,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 1,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 93.33333333333333
}
# 인덱스 목록 확인
GET /_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open pages oWEGuGkoT22GqT25t1TLyQ 1 1 0 0 225b 225b
green open .fleet-file-data-agent-000001 jxaqA7nVQ6K7Vb_ABvwsjg 1 0 0 0 225b 225b
green open .fleet-files-agent-000001 oZMaUmUxQjW5wwmKZDMDPA 1 0 0 0 225b 225b- 새로 만든 인덱스의 상태가 yellow로 되어 있는 이유는 어떤 노드에도 할당되지 않았기 때문이다.
- 복제 샤드가 결과적으로 원본 인덱스와 같은 노드를 사용할 수 없기때문에 현재는 할당되지 않은 상태가 된다.
- 여기서 새로 클러스터를 생성하면 자동으로 할당되도록 보류되어 있다는 얘기.
- 최종적으로 옐로우는 데이터 손실이 발생할 위험이 있다는것에 대한 경고
복제 된 샤드의 위치 확인
# 샤드가 어느 인덱스에 속해있는지 알려준다.
GET /_cat/shards?v
index shard prirep state docs store ip node
.kibana-event-log-8.7.1-000001 0 p STARTED 2 13.8kb 127.0.0.1 jeonhong-uui-iMac.local
.security-7 0 p STARTED 124 408.8kb 127.0.0.1 jeonhong-uui-iMac.local
.fleet-file-data-agent-000001 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local
.fleet-files-agent-000001 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local
.apm-custom-link 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local
.ds-.logs-deprecation.elasticsearch-default-2023.05.07-000001 0 p STARTED 2 24.7kb 127.0.0.1 jeonhong-uui-iMac.local
.kibana_security_session_1 0 p STARTED 2 13.1kb 127.0.0.1 jeonhong-uui-iMac.local
.kibana_8.7.1_001 0 p STARTED 908 2.7mb 127.0.0.1 jeonhong-uui-iMac.local
.kibana_task_manager_8.7.1_001 0 p STARTED 26 8.9mb 127.0.0.1 jeonhong-uui-iMac.local
pages 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local
pages 0 r UNASSIGNED
.ds-ilm-history-5-2023.05.07-000001 0 p STARTED 9 20.1kb 127.0.0.1 jeonhong-uui-iMac.local
.security-profile-8 0 p STARTED 1 8.6kb 127.0.0.1 jeonhong-uui-iMac.local
.apm-agent-configuration 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local
.apm-source-map 0 p STARTED 0 225b 127.0.0.1 jeonhong-uui-iMac.local- prirep의 P는 Primary (주 조각) r은 (replica)로 복제 조각이다.
- 기본 샤드의 상태는 STARTED다.
- Kibana의 인덱스는 값이 “0-1″인 “auto_expand_replicas”. “이 설정이 하는 일은 클러스터에 포함된 노드 수에 따라 복제본 수가 동적으로 변경된다.
- 단일 노드만 있으면 복제본은 0이 되고, 노드가 하나 이상이면 복제본은 하나이상이 된다.
- rep는 복제 수를 말한다.
문제 풀이
- Elasticsearch는 고가용성을 어떻게 보장합니까?
- 복제는 노드가 다운될 경우 다른 노드에서 데이터를 사용할 수 있도록 합니다(클러스터가 둘 이상의 노드로 구성된 경우).
- 기본 샤드란 무엇입니까?
- 복제된 샤드
- 복제 샤드란 무엇입니까?
- 기본 샤드의 복사본
- 복제 그륩이란 무엇입니까?
- 기본 샤드의 복제본 및 기본 샤드 그 자체
- 샤드당 기본 복제본 수는 얼마입니까?
- 1
- 기본적으로 인덱스에 몇 개의 샤드가 추가됩니까?
- 2(기본 샤드 1개 + 복제본 샤드 1개)