[엘라스틱서치] 엘라스틱 서치 실무 가이드

 

저자 : 권택환 김동우 김홍래 박진현 최용호 황희정

출판사 : 위키북스

 

 

엘라스틱 서치를 ES라고 줄여서 표현

관계형 데이터베이스를 RDB라고 줄여서 표현

엘라스틱 서치

RDB와 ES는 동일하게 검색할 수 있는 기능이 존재한다.

하지만 기존의 RDB의 검색시 정형화된 데이터베이스에 대해서만 검색이 가능했고 동의어나 유의어를 활용하기 어려웠다.

이러한 점을 해결하기 위해서 역색인 구조를 가진 엘라스틱 서치가 등장했다.

1. 속성 비교

ElasticSearch 7.X버전 이후 기준

 

관계형 데이터베이스	엘라스틱 서치
테이블	인덱스
파티션	샤드
행	문서
열	필드
스키마	매핑
SQL	QueryDSL

 

CRUD 기능 비교

 

기능	관계형 데이터베이스	엘라스틱 서치 HTTP 메소드
데이터 조회	SELECT	GET
데이터 생성	INSERT	PUT
인덱스 업데이트, 데이터 조회	UPDATE, SELECT	POST
인덱스 정보확인	-	HEAD

기본 저장방식은 JSON 형태로 저장되며 전문검색(Full-Text)가 가능하다.

전문검색은 내용전체를 색인해서 특정 단어가 포함된 문서를 검색하는 것을 의미한다.

 

2. 단점

1. 실시간이아니다

-> 내부적으로 커밋과 플러시라는 복잡한 과정이 일어나기 때문에 데이터는 통상 1초 뒤에나 검색이 가능한 Near Realtime 이다.

 

2. 트랜잭션과 롤백 기능을 제공하지 않는다. 분산시스템이기 때문에 비용 소모가 큰 롤백과 트랜잭션을 지원하지않는다.

-> 데이터 손실 위험

 

3. 데이터의 업데이트가 아닌 기존문서를 삭제하고 변경된 문서를 새로 생성하는 방식을 사용한다.

-> 불변적인 데이터 구조는 단점이 될 수 있고 장점이 될 수 있다.

단 공부하다보니 불변성 == 엘라스틱 서치의 정체성인 것 같다.

 

엘라스틱 서치 구조

클러스터 : 클러스터는 기본적으로 함께 작업하는 여러 컴퓨터(또는 노드)를 의미한다. 하나의 컴퓨터가 노드 역할을 할 수도 있고 여러 컴퓨터가 노드 역할을 수행해서 클러스터를 형성한다.

 

Cross Cluster Search : 일반적으로 데이터가 적으면 하나의 클러스터에서 검색을 수행해도 충분하지만 데이터가 많아지는 경우 클러스터를 분리해 다수의 클러스터에서 검색할 수도 있다.

그림그림그림그림그림

 

노드 : 노드는 논리적인 클러스터를 이루는 구성원의 일부이며 실제 데이터를 가지고있는 단일 서버 이기도 하다.

말이 어렵지만 쉽게 말해서 노드를 물리적인 컴퓨터라고 생각하고 클러스터를 이러한 컴퓨터를 하나로 묶어서 편하게 사용하기 위해 묶어 놓은 그룹이라고 볼 수 있다.

노드 안에는 샤드가 있는데 샤드는 프라이머리 샤드와 레플리카 샤드가 있다.

프라이머리 샤드는 주로 쓰기를 담당하고 레플리카샤드의 경우 장애 복구를 위한 백업데이터의 역할과 읽기용 작업을 주로 수행한다.

1. 노드 종류

마스터 노드 : 클러스터의 제어를 담당한다.

데이터 노드 : 데이터를 보유하고 CRUD, 검색 집계 등 데이터 관련 작업을 담당한다.

인제스트 노드 : 색인 전 전처리 작업을 담당한다.

코디네이팅 노드 : 검색이나 집계 시 분산 처리만을 위한 목적으로 설정된 노드, 대량의 데이터를 처리할 경우에 효율적으로 사용할 수 있는 노드다.

2. 인덱스

유사한 문서들을 모아둔 컬렉션이다. RDB의 테이블과 유사한 개념이라고 볼 수 있다.

3. 문서

검색이 되는 실제 물리적인 데이터를 의미한다.

인덱스에 문서를 저장하고 실제로는 물리적인 샫 형태로 다수의 노드에 분산되어 저장된다.

4. 샤드

물리적인 한계를 뛰어넘기 위해 도입된 것으로 인덱스에 문서를 저장할 수 있으며 수평 확장이 가능해진다.

물리적인 한계는 하나의 하드웨어가 가지고있는 리소스의 한계를 의미하며 하나의 하드웨어에 검색으로 느리다며 추가 (노드) 하드웨어를 도입하여 샤드를 추가함으로써 데이터를 분산시켜 저장하기 때문에 방대한양의 데이터 저장이 가능하다는 의미다.

 

쉽게 말해서 분산시스템이 아닌 RDB로 치면 하나의 테이블에 4만건의 데이터를 하나의 컴퓨터가 읽는데 걸리는 시간이라고 생각한다면 분산시스템 방식의 데이터 저장은 컴퓨터 4대를 놓고 1대씩 1만건의 데이터를 저장해서 검색 시 각 4대에서 개별로 가져오기 때문에 빠를수 밖에 없다

검색 요청 -> 모든 클러스터 -> 모든 샤드 검색 ( 각 샤드는 독립적인 검색 서비스 ) -> 각 결과 취합

 

예시로 얼마전에 유튜브에서 NVME 4개를 활용해서 분산저장하는 경우 속도가 매우 빠른데 이러한 느낌과 유사하다고 생각한다.

 

https://www.youtube.com/watch?v=9k-l3KXZkJQ

문제가 되는경우는 삭제하겠습니다.

 

샤드는 2가지 종류가 있는데 

 

1. 프라이머리 샤드

주로 데이터의 색인작업을 담당하며 CRUD를 수행한다.

 

2. 레플리카 샤드

분산저장시 검색에 활용되며 샤드에 장애가 났을 경우 미리 생성해둔 레플리카를 통해서 복구 작업이 진행된다.

노드의 장애를 대비 하기 위한 것이기 때문에 레플리카는 다른 노드에 저장이된다. 서로 다른 노드끼리 백업 파일을 갖고 장애 시 복구를 도와주고 임시로 샤드역할을 수행 해준다. 또한 프라이머리 샤드와 동일한 데이터를 갖고 있기 때문에 읽기 분산에 활용된다.

 

샤드를 한마디로 정의하자면 장애복구 기능을 가진 작은 루씬 기반의 단일 검색 서버 라고 할 수 있다.

루씬의 구조

엘라스틱서치의 실제 검색엔진 자료 구조는 루씬을 기반으로 되어 있기 때문에 어느정도 알고 있어야 이해하기 쉽다.

루씬의 자료구조

 

세그먼트 - 루씬의 자료 구조 중요!!

우리가 엘라스틱 API를 통해서 저장하지만 실제로는 루씬 검색엔진에 세그먼트에 저장된다고 보면 된다.

문서들을 빠른 검색에 유리하도록 설계된 특수한 자료구조이며 역색인 형태로 문서를 변환하여 저장한다.

역색인은 일반적인 검색처럼 처음부터 끝까지 인덱스를 읽는게 아닌 이미 입력받은 단어에 해당하는 문서 위치를 색인해두고 그 위치를 통해 값을 리턴해준다.

 

루씬의 주요 클래스 2가지

IndexWirter : 데이터 색인하여 세그먼트 생성, 세그먼트 Merge(병합)

IndexSearcher : 세그먼트를 읽어 검색결과 제공

 

루씬의 Flush

루씬은 효율적인 색인 작업을 위해서 일정 크기의 버퍼(In-memory buffer)를 가지고 있다.

이 버퍼를 통해서 요청 데이터를 순서대로 쌓고(Queue 역할) 한번에 처리된 데이터는 세그먼트 형태로 생성되고 즉시 디스크로 동기화 된다. 디스크 동기화 과정은 상당히 무거운 작업 이기 때문에 성능이 급격히 떨어질 수 있다. 따라서 write함수로 캐시에 기록한 상태에서 시스템이 비정상적으로 다운되는 경우 데이터가 유실 될 수 있다. 인 메모리 버퍼 기반의 처리 과정을 루씬의 Flush라고 부른다. 데이터 변경사항을 일단 버퍼에 모아뒀다가 일정 주기에 한 번씩 세그먼트를 생성하고 상대적으로 적은 비용으로 디스크에 동기화 하는 작업까지 수행하는 것이다.

 

루씬 Commit

fsync 함수를 호출하는 작업을 Commit이라고 한다. 물리 디스크와 동기화하는 작업시 fsync 함수를 호출한다.

Flush 단계가 존재함으로 매번 수행 할 필요는 없지만 일정 주기로 물리 디스크에 기록하는 작업을 수행해야한다.

 

루씬 Commit Point

루씬은 Update라는 수정 기능이 없고 대신 새로 생성하는 불변성을 특징으로 갖고 있다.

기존에 문서에 수정 사항이 생기면 새로운 세그먼트를 생성하고 추후에 사용자가 검색 시 오래된 세그먼트 순서대로 읽어서 하나의 결과를 제공하는데 이 방식을 Commit Point라고 한다.

시간이 지남에 따라서 세그먼트가 쌓이게 되고 파일 읽는 속도가 느려지는데 이때 세그먼트 파일을 하나로 합치는 Merge(병합) 작업을 수행한다.

 

루씬 Merge

병합(Merge)작업은 세그먼트를 합치기 위한 작업으로 Commit 작업이 동반되어야 하기 때문에 비용이 많이 드는 연산이다. 

적절한 주기마다 실행하도록 설정하는 것이 중요하다.

 

최초 색인 요청 시

1. IndexWirter가 세그먼트를 생성

2. IndexSearcher가 생성된 세그먼트를 읽어 검색을 제공한다.

 

추가 색인이 요청 시

1. IndexWriter가 세그먼트를 추가 생성

2. 세그먼트가 추가 생성되는 동안 기존 세그먼트 읽어 검색결과 제공

3. 세그먼트 생성이 완료되면 생성된 모든 세그먼트를 읽어 검색결과를 제공한다.

 

세그먼트 Merge 작업 시

1. IndexWriter가 Merge 대상 되는 세그먼트 복제

2. IndexWriter가 복제한 세그먼트들을 하나의 세그먼로 합친다.

3. 복제본 세그먼트들이 하나로 합쳐지는 동안 IndexSearcher는 원본 세그먼트를 검색결과로 제공

4. 복제본 통합 작업 완료시 원본과 교체하고 교체된 세그먼트 삭제

5. IndexSearcher는 새로운 세그먼트를 읽어 검색결과로 제공

 

생성, 수정

새로운 세그먼트 생성하여 추가한다.

 

삭제

세그먼트의 삭제여부 비트 배열에 flag로 삭제를 표시한다.

당장 삭제하지않고 추후에 머지 과정에서 삭제하며 검색 작업시 제외시킨다.

 

루씬은 분산저장 방식이 아니기 때문에 설치된 하드웨어의 리소스 한계를 뛰어넘을 수 없다는 단점이있었는데 이 부분을 엘라스틱 서치를 통해서 한번 더 감싸서 여러 루씬을 다룰 수 있게 만든 것이다.

단 엘라스틱 서치도 운영중에 동적으로 쉽게 샤드를 변경할 수는 없기 때문에 데이터의 양을 예측, 클러스터 장애 고려, 각 노드별 하드웨어적 리소스 가용성을 충분히 고려해서 초기에 잘 설정해야지 추후에 대처하기 편하다.

불변성을 통해서 얻는 장점

1. 동시성 문제를 피할 수 있다.

여기서 동시성 문제는 예를 들어서 동시에 같은 요청이 와도 같은 세그먼트를 읽을 때 수정이 되지 않기 때문에 서로 같은 검색 결과 값을 전달받는 다는 의미이다.

 

2. 시스템 캐시 적극 활용

불변성을 보장하지 않는경우 데이터 변경 때마다 시스템 캐시를 삭제하고 다시 생성해야 하는데 이는 성능 측면에서 비용이 큰 작업이므로 최대한 지양해야한다.

 

3. 높은 캐시 적중률

시스템 캐시의 수명이 길어진다. 검색 시 데이터를 메모리에서 읽어 올 수 있다는 의미로 큰 폭으로 성능이 향상될 수 있다.

 

4. 리소스를 절감할 수 있다.

역색인을 만드는 과정에서 많은 시스템 리소스(CPU, 메모리 I/O)가 사용된다. 수정을 허용하게 되면 일부분이 변경되더라도 해당 역색인을 대상으로 작업해야 하기 때문에 많은 리소스가 소모된다.

엘라스틱 서치의 자료 구조

엘라스틱 서치 Refresh

인덱스를 새로 고침한다는 의미이며 새로 추가한 데이터의 검색이 가능해지게 한다는 의미인 것이다.

엘라스틱 서치에서 각 샤드가 가지고 있는 루씬을 제어 할 수 있으며, 실시간 검색에 가깝게 동작하기 위해서 주기적으로 인메모리 버퍼에 대한 Flush 작업을 수행한다. 클러스터에 존재하는 모든 샤드에 기본적으로 1초마다 한 번씩 Refresh 작업이 수행된다.

 

엘라스틱 서치 Flush

엘라스틱 서치에서 Flush는 루씬의 Flush와 다른 개념이다.

엘라스틱 서치의 Flush는 루씬의 Commit을 수행하고 Translog를 시작한다는 의미이다.

Translog는 샤드의 장애 복구를 위해서 제공되는 파일이며 엘라스틱 서치는 자신에게 일어나는 모든 변경사항을 Translog에 먼저 기록한 후 내부에 존재하는 루씬을 호출한다. 시간이 흐를 수록 파일이 크기는 커지고 엘라스틱 서치의 Refresh가 일어나기 때문에 이러한 정보를 디스크와 동기화하기 위해서 엘라스틱 서치의 Flush를 수행한다. 

루씬의 Commit이후에 Translog 정보의 방금 Commit 시점까지 정보를 비로소 삭제하게된다.

장애복구를 위한 Translog관리 + 루씬의 Commit를 수행하는 작업

 

엘라스틱 서치 Optimize API

루씬의 Merge를 강제로 수행하는 기능이다.

엘라스틱 서치의 max_num_segements 옵션을 이용하면 샤드의 세그먼트를 설정된 개수로 강제로 병합할 수 있다.

더 이상 변경이 없다면 세그먼트 수를 하나로 강제 병합하는  편이 읽기 성능 측면에서 좋다.

 

고가용성을 위한 Translog

Translog는 엘라스틱 서치 샤드가 비용이 높은 Flush를 대신해서 Refresh를 1초마다 수행하고 있는데

이 Flush는 실제 디스크와 동기화 작업이 아니기때문에 Flush 전 장애 발생시 데이터 유실을 방지하고자 기록해놓는 파일이다.

기본적으로 Flush는 5초 간격으로 진행이된다.

Translog의 또 다른 장점이 있는데 Commit 작업중 추가 수정사항이 발생시 Translog에 반영한다는 것이다.

여러 상황에서 Translog가 안정적인 역할을 도와준다.

하지만 Translog 파일이 커질수록 장애 발생시 복구에 걸리는 시간도 비례하여 늘어나기 때문에 마지막 루씬 Commit 이후의 모든 내역을 재실행해서 세그먼트를 재성성하는 과정에 다시 에러가 발생하고 이런 과정이 무한 반복 되는 상황에 빠질 수 있다.

적절한 주기로 Flush를 수행해서 Translog 크기가 일정 크기를 유지 하도록 꾸준히 모니터링하고 관리하는것이 안정적인 클러스터 운영에 기본이된다.

 

인덱스에 문서 저장 흐름

1. 엘라스틱 서치의 인덱스에 문서를 저장하는 API 호출

2. 엘라스틱 서치의 클러스터에 등록된 노드를 확인한다

3. 적합한 노드선별후 적합한 샤드에 저장이 된다.

4. 샤드 내에 루씬의 역색인 과정을 거쳐서 세그먼트형태로 저장된다.

 

단점

실시간 반영이 어렵다. 수정이 불가능하기 때문에 일부 데이터가 수정되어도 전체 역색인 구조로 다시 만들어져야한다는 의미이다.

변경사항 반영하려면 역색인을 새롭게 만드는 작업이 반드시 동반돼야 하는데 변경이 매우 빠르게  일어날 경우 실시간 반영 자체가 불가능 해진다. 이런 단점 극복을 위해서 루씬은 기존 세그먼트를 두고 새로운 세그먼트를 생성하는 방법을 선택했다.

검색 요청 시 모든  생성된 세그먼트를 읽고 결과를 제공 하는 것 이다.

 

엘라스틱 서치 Refresh, Flush, Optimize API

 

루씬	엘라스틱 서치
Flush	Refresh
Commit	Flush
Merge	Optimize API

운영시 주의할점

운영중 샤드 갯수를 수정하지 못하는 이유

예를 들어 5천건의 데이터를 5개의 샤드가 나눠 가진다고 했을때 각 1천건씩 샤드에 배정이 될 것이다.

여기서 number_of_shards의 수를 10개로 늘린다고 해도 기존에 나눠져있던 1천건이 500건이 되면서 자동으로 분배 되지 않는다.

그 이유는 이미 루씬의 단일 머신(Stand Alone)형태와 불변성 특성 때문이다.

루씬은 엘라스틱 서치의 존재를 모르고 스스로 독립적인 존재로 알고 있기 때문에 동적으로 다른 샤드가 생성됬는지 전혀 알 수가 없다. 또한 불변성의 특징으로 역색인된 세그먼트들을 변경이 불가능하다.

엘라스틱 서치는 샤드가 추가 되는 경우 재색인 하도록 안내 하고있다.

ReIndex API를 사용해서 재 색인을 할 수 있다.

 

레플리카 수는 적절하게 설정

많은 양의 레플리카를 갖고 있다고해서 전체적인 성능이 향상되지 않는다.

오히려 지나치게 많은 경우 색인 작업시 프라이머리 샤드와 동일한 형태로 레플리카 샤드의 데이터도 수정되어야하기 떄문에 레플리카의 수만큼 부하가 걸리게된다. 레플리카가 읽기용으로 동작하기때문에 읽기는 빠르지만 색인성능은 떨어질수 밖에 없다.

 

클러스터에 많은 수의 샤드가 존재하는 경우

마스터 노드의 부하가 걸린다. 마스터 노드는 빠른 처리를 위해서 샤드의 정보와 같은 관리 데이터를 모두 메모리에 올려서 제공하기 때문에 너무 많은 샤드로 인해서 마스터 노드의 메모리가 부족해지지 않도록 주의해야한다.

 

역할

1. 모든 노드와 샤드 관리

2. 노드 상태 모니터링, 색인 요청시 데이터 라우팅 처리, 검색 요청시 부하 분산

3. 장애 발생시 레플리카를 이용해서 샤드 복구

 

엘라스틱 서치에서는 샤드의 크기는 50GB를 넘지 않도록 권장한다.

대용량 처리를 위한 시스템 최적화

1. 힙크기를 32GB 이하로 유지

엘라스틱 서치는 자바 기반 이기 때문에 JVM 옵션을 잘 다뤄야 한다.

분산 시스템 특성상 (스케일 인/아웃)이 빈번하게 발생, 장애 복구작업, ReIndex 작업등에 많은 메모리가 사용 되기 때문에

JVM 옵션은 수년간 경험을 바탕으로 기본 설정 되어있는 엘라스틱서치에서 제공하는 기본 옵션을 유지하는 것이 좋다.

단 초기에 엘라스틱 서치 jvm.option에 힙크기 1GB로 설정되어있는데 이는 테스트 용도 이며 실제 운영환경에서는 더 큰 크기로 변경해야한다.

힙의 크기는 너무 작으면 OOM(Out Of Memory) 오류가 발생하고 반대로 너무 크면 (Full GC)가 발생할 때 시스템이 마비 되는 STW(Stop The World)를 발생 시킬 수 있다.

 

OOM 발생 원인 : 메모리누수 ( 더이상 사용되지않는 객체의 참조가 존재하여 쌓인경우 GC 처리가 불가할때 혹은 객체가 폭발적으로 생성되어 GC의 처리 속도를 못따라 갈때 발생한다.)

 

STW 발생 원인 : 힙메모리가 최대로 8G 설정이 된 상태에서 8GB로 가득 찼을때(Full GC) GC가 동작하면서 비우는데 8G를 비우는 것과 16G를 비우는 속도 중에 8GB가 빠르기 때문에 상대적으로 빠르다 그렇기 때문에 FullGC 상태에서는 메모리가 클수록 프리징 상태가 길다.

 

힙사이즈 확인 : GET /_nodes/stats/jvm?pretty 

힙사이즈 설정 파일 : elasticsearch/config/jvm.option

-Xms 최소 힙 크기

-Xmx 최대 힙 크기

기본적으로 Xms 크기로 할당 했다가 부족하다고 판단되면 Xmx 크기까지 할당된다.

기본적으로는 두 값을 같게해두는 편이 좋다고 한다.

 

운영체제에 50% 메모리 공간을 보장한다

안정적인 서버 환경을 위해서 50%는 보장 해야하며 루씬에서 시스템 캐시를 통해 메모리를 최대한 활용할 수 있도록 한다.

 

다다익램?

많으면 좋다고 생각할 수 있지만 자바 어플리케이션에 있어서는 32GB 초과 힙 메모리 크기에서 JVM은 압축된  포인터 기술인COOP(Compressed Ordinary Object Pointers)를 사용할 수가 없다. 이 기술은 객체 포인터 공간에 낭비를 줄이도록 포인터를 압축하여 표현하는 일종의 트릭이다. 메모리 사용량을 줄이고 최적화 시켜준다.

-XX:+UseCompressedOops - COOP 사용 옵션

2. 서버 스펙에 따른 구성 예시

1번 케이스 고성능 서버인 경우

총 128GB 물리메모리

64GB를 운영체제에 할당한다.

32GB를 갖는 엘라스틱서치 인스턴스를 2개 생성한다.

 

2번 케이스 전문(Full-Text) 목적인 경우

총 128GB 물리메모리

96GB를 운영체제에 할당한다.

32GB를 갖는 엘라스틱 서치

전문(Full-Text) 검색의 경우 루씬의 역색인 구조를 이용하는 경우가 많을 것이기 때문에 루씬 내부의 mmap을 통해 가능한 시스템 캐시를 이용해 세그먼트를 캐시할 수 있어서 빠른 전문 검색이 가능해진다.

 

3번 케이스 일반적인 데이터 필드에서 정렬 / 집계 작업을 많이 수행하는 경우

총 128GB 물리메모리

96GB를 운영체제에 할당한다.

32GB를 갖는 엘라스틱 서치

루씬의 DocValues를 사용하기 때문에 힙 공간이 거의 사용되지 않는다.

3. Swap Off

운영체제에서 효율적인 메모리 관리를 위해서 스와핑이라는 기술을 사용한다.

이를 이용해서 사용되지 않는 애플리케이션의 물리 메모리를 디스크로 스왑 해버린다.

이때 동기화 작업으로 이해 순간적으로 성능이 저하되고 시스템 장애로 이어질수 있다.

엘라스틱 서치도 동작하는데 필요한 메모리를 언제든지 스왑 당할수있기 때문에 클러스터간에 연결이 불안정해질 수 있다.

따라서 스왑은 꺼둔다.

또한 어플리케이션 레벨에서 메모리를 스왑하지 못하도록 강제로 잡아 둘 수있다. 

elasticsearch.yml에 bootstrap.memory_lock: true

설정 확인 API GET _nodes?filter_path=**.mlockall

4. 운영체제 시스템 설정

운영체제에서 동시에 여러 어플리케이션이 실행 될 수 있기 때문에 특정 리소스가 독점하지 못하도록 설정하는것은 중요하다.

 

ulimit로 리소스 제한 수정

unlimit -m unlimited - 스와핑 최소화를 위해 memory lock 사이즈를 unlimited 값으로 변경

unlimit -a 명령어로 조회 했을때 수정 가능한 옵션이 많이 있다.

 

sysctl 리소스 제한 수정

sysctl -w vm.max_map_count = 262144 가상 메모리 mmap 카운트 변경

(mmap은 루씬의 색인 데이터가 메모리에 얼마나 올라갈 수 있는지 설정하는 것으로 기본보다 늘려 놓아야 검색 시 속도를 올릴 수 있다)

vi /etc/sysctl.conf 파일에서 영구적으로 수정 가능

 

max open file 한계 설정

엘라스틱 서치 노드에는 많은 수의 소켓을 사용해 클라이언트와의 통신을 수행한다. 이뿐만이 아니라 내부에 존재하는 색인데이터를 효율적으로 관리하기 위해서 파일 디스크립터가 사용되는데 일반적인 파일 시스템 보다 훨씬 더 많은 수의 파일을 생성할 수 있어야한다. 

unlimit -n 81920

vi /etc/security/limits.conf - 영구적으로 설정

리부팅후 ulimit -a 명령어로 확인

 

이외에도 추가 설정과 모니터링 방법이 있는데 아직 프로젝트 적용도 안해봤는데 나중에 봐도 될 것 같다.

아쉬운점은 책 중간 실습에서 자바 코드가 중복되는 부분이 좀 있는데 그 부분을 제외하고는 엘라스틱 서치가 잘 모르는 나 같은 사람한테는 큰 도움이 됬다. 기본 이론에 대해서 너무 로우 레벨이 아니고 사용할때 정확히 필요한 만큼 설명해주셔서 군더더기도 없는 좋은 책 읽어서 뿌듯하다.