시간이 없어서 전체적으로 다 살펴 보지는 못했네요.

우선 확인 한것만 그냥 올려 놓습니다.

Elasticsearch 8.0 

- path.data 다중 설정이 deprecated.
7.13.0 부터 deprecated 되었으나 아직까지는 기능을 제공 하고 있음.
디스크를 추가 하기 보다 data node 를 늘리는 것을 추천함.
단일 경로 설정 사용을 권장함.

- system index 에 접근 제어.
allow_restricted_indices: true 로 하면 접근 가능함.

- 8.0 실행 시 jdk 17 을 요구함.
warning: ignoring JAVA_HOME=/Users/henry/.jenv/versions/11.0; using ES_JAVA_HOME
The minimum required Java version is 17; your Java version from [/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home] does not meet this requirement

https://adoptium.net/ 에서 다운로드 받아 설치 합니다. (pkg)

/Library/Java/JavaVirtualMachines/temurin-17.jdk
$ jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
$ ES_JAVA_HOME='/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home' bin/elasticsearch

- 8.0 부터는 보안이 기본 적용 됩니다.
관련 security 기능을 사용하고 싶지 않을 경우 xpack.security.enable: false 로 설정 하면 됩니다.


✅ Elasticsearch security features have been automatically configured!
✅ Authentication is enabled and cluster connections are encrypted.

ℹ️  Password for the elastic user (reset with `bin/elasticsearch-reset-password -u elastic`):
  5mZOrRjTURT=V90LqU5N

ℹ️  HTTP CA certificate SHA-256 fingerprint:
  24d263ef19a4e66de19ab35dbd8a0cbf4ca303598123d3ee6acbb96852e25421

ℹ️  Configure Kibana to use this cluster:
• Run Kibana and click the configuration link in the terminal when Kibana starts.
• Copy the following enrollment token and paste it into Kibana in your browser (valid for the next 30 minutes):
  eyJ2ZXIiOiI4LjAuMCIsImFkciI6WyIxOTIuMTY4LjAuMTA0OjkyMDAiXSwiZmdyIjoiMjRkMjYzZWYxOWE0ZTY2ZGUxOWFiMzVkYmQ4YTBjYmY0Y2EzMDM1OTgxMjNkM2VlNmFjYmI5Njg1MmUyNTQyMSIsImtleSI6Imd0R2g1bjRCc3hnWEYtbV92bU43OnlwVDhOaXNaU2ZXejRhdEhTaExfS0EifQ==

ℹ️  Configure other nodes to join this cluster:
• On this node:
  ⁃ Create an enrollment token with `bin/elasticsearch-create-enrollment-token -s node`.
  ⁃ Uncomment the transport.host setting at the end of config/elasticsearch.yml.
  ⁃ Restart Elasticsearch.
• On other nodes:
  ⁃ Start Elasticsearch with `bin/elasticsearch --enrollment-token <token>`, using the enrollment token that you generated.


- elasticsearch.yml 내부에 환경 변수 설정이 가능 합니다.
node.name:    ${HOSTNAME}
network.host: ${ES_NETWORK_HOST}

export HOSTNAME="host1,host2"

- transient 설정을 더 이상 추천 하지 않습니다.
영구 설정을 사용 하세요.

- data directory 에 대한 어떠한 조작, 수정도 하지 마십시오.


- lucene-analyzers-common 이 lucene 9.0.0 으로 넘어 가면서 lucene-analysis-common 으로 변경 되었습니다.
import org.apache.lucene.analysis.util.TokenizerFactory;
to
import org.apache.lucene.analysis.TokenizerFactory;
로 변경 되었습니다.

import org.apache.lucene.analysis.standard.ClassicFilter;
to
import org.apache.lucene.analysis.classic.ClassicFilter;
로 변경 되었습니다.

- node 단독 실행 시 아래 설정이 꼭 되어야 합니다.
discovery.type: single-node
or
cluster.initial_master_nodes, discovery.seed_hosts, discovery.seed_providers 중 하나는 꼭 설정 되어야 합니다.

- mapping 파라미터 중 boost 파라미터가 삭제 되었습니다.
.The `boost` parameter on field mappings has been deprecated
.The `boost` parameter on field mappings has been removed

- jdk 변경 된 점
Remove support for JAVA_HOME
Require Java 17 for running Elasticsearch

- exist action some removed.
Remove aliases exist action
Remove indices exists action
Remove types exists action

- Enable LZ4 transport compression by default

arirang plugin 을 사용 하면서 사전 데이터에 대한 classpath 설정은 했는데 config/dictionary path 생성을 하지 않았을 경우 reload api 가 동작 하지 않는다고 합니다.

이럴 경우 config/dictionary path 생성 하고 사전 데이터 배포 후 node 를 재시작 해주셔야 하는 번거로움이 있으니 초기 설치 시 꼭 사전 데이터에 대한 배포 후 실행을 해주시면 좋을 것 같습니다.

혹시 같은 실수 반복 할 수도 있어서 기록합니다.

2022년에는 방식이 변경 된다고 해서 활동을 거의 하지 않았는데 다행히 Bronze 를 주셨네요. ^^

참여 하고 싶으신 분들은 아래 링크 통해서 하시면 됩니다.

https://contributor-program.app.elstc.co/

Elastic Bronze Contributor 2022

Elastic Bronze Contributor 2021

공식 문서)

Exists query | Elasticsearch Guide [7.16] | Elastic

exists query 는 field 자체가 아래 이유등으로 인해 생성 되자 않는 문서를 찾습니다.

즉, 

- null 또는 empty array (빈문자열 "" 은 해당 되지 않습니다.)

- index: false

- ignore_above 설정 값을 넘었을 때

- ignore_malformed 설정에 걸렸을 때

검색 엔진 특성상 null, empty string 에 대해서는 전처리를 통해서 명확히 제거 하거나 목적에 맞게 변형 하는 것이 좋습니다.

검색엔진을 이용해서 field:"" 또는 field: " " 과 같은 질의를 작성 하는 것은 좋지 않습니다.

공식 문서)

Cardinality aggregation | Elasticsearch Guide [7.16] | Elastic

Derivative aggregation | Elasticsearch Guide [7.16] | Elastic

Cumulative cardinality aggregation | Elasticsearch Guide [7.16] | Elastic

현재 값과 직전 값에 대한 차이를 구합니다.

공식 문서에 자세한 내용들이 나와 있으니 보시면 좋습니다.

제가 사용 했던 예제는 공식 문서에 있는 거 활용 했습니다.

DAU 를 cardinality aggs 로 구하고 

Daily DAU 에 대한 누적 카운트를 cumulative_cardinality aggs 로 구하고 (여기서 buckets_path 는 cardinality aggs) 

Daily DAU 에 대한 변화를 derivative aggs 로 구했습니다. (여기서 buckets_path 는 cumulative_cardinality aggs)

아래는 공식 문서 예제 올려 둔 내용입니다.

GET /user_hits/_search
{
  "size": 0,
  "aggs": {
    "users_per_day": {
      "date_histogram": {
        "field": "timestamp",
        "calendar_interval": "day"
      },
      "aggs": {
        "distinct_users": {
          "cardinality": {
            "field": "user_id"
          }
        },
        "total_new_users": {
          "cumulative_cardinality": {
            "buckets_path": "distinct_users" 
          }
        }
      }
    }
  }
}

Elasticsearch 에서 질의 후 매칭된 문서의 수를 알아 내는 방법은 두 가지가 있습니다.

1. track_total_hits

2. _count API

여기서 WAS 의 에러로그 발생에 대한 알람을 구성 할 경우 어떤걸 사용 하면 좋을까요?

1. track_total_hits

false

true

numeric

이와 같이 값을 설정 할 수 있는데요.

false 이면 total hits 값을 구할 수 없습니다.

true 이면 total hits 값을 구할 수 있습니다.

특정 값을 넣게 되면 그 값 보다 작거나, 같은 값을 구할 수 있으며, relation 을 통해서 실제 매칭 문서의 규모를 파악 할 수 있습니다.

2. _count API

기본적으로 non-scoring API 이며, 어떤 데이터도 요청 하지 않기 때문에 빠릅니다.

Lucene Core 에 TotalHits.Relation 이 들어 있습니다.

  public enum Relation {
    /**
     * The total hit count is equal to {@link TotalHits#value}.
     */
    EQUAL_TO,
    /**
     * The total hit count is greater than or equal to {@link TotalHits#value}.
     */
    GREATER_THAN_OR_EQUAL_TO
  }

보시는 것 처럼 eq 아니면 gte 가 리턴 됩니다.

그래서 특정 수치 이상을 점검 하기 위해서는 relation:gte 로 조건을 잡으셔야 합니다.

그냥 위에서 처럼 1,2 번을 놓고 보면 _count API 를 사용하는게 일반적입니다.

그러나 대상 문서의 규모가 넓고 많을 경우 track_total_hits 에 특정 임계 값을 넣어서 질의 하는게 더 빠를 수 있습니다.

대부분의 성능 이슈는 서버 엔진 보다는 클라이언트 단에서 사용을 잘 못 하는 경우가 많이 있습니다.

Low Level Rest Client 와 Springboot 조합으로 API 개발 시 튜닝 요소를 조금 정리 합니다.

나중에 또 기억 못할 것 같으니...

RestClientBuilder 에 보면 아래와 같이 기본 설정이 되어 있습니다.

public static final int DEFAULT_MAX_CONN_PER_ROUTE = 10;
public static final int DEFAULT_MAX_CONN_TOTAL = 30;

이 기본 값으로 그냥 사용하게 되면 너무 리소스를 제한적으로 사용하기 때문에 성능이 제대로 나오지 않게 됩니다.

해당 값을 적절하게 튜닝을 하셔야 하는데 모든 케이스에 다 적용 가능한 부분은 아니지만 그래도 가늠 할 수 있는 기준 정도로는 사용이 가능 할 것 같아 공유 합니다.

분석 결과는 Core 1 개당 setMaxConnPerRoute 설정 시 25 개씩이 최적 값으로 보입니다.
4 core 짜리면 4 x 25 = setMaxConnPerRoute(100)

아래는 실제 코드 내부에 작성 되어 있는 코멘트를 보여 드리기 위해 캡쳐 했습니다.

HttpAsyncClientBuilder httpClientBuilder = HttpAsyncClientBuilder.create().setDefaultRequestConfig(requestConfigBuilder.build())
  //default settings for connection pooling may be too constraining
  .setMaxConnPerRoute(DEFAULT_MAX_CONN_PER_ROUTE).setMaxConnTotal(DEFAULT_MAX_CONN_TOTAL)

코드에서도 동일하게 기본 설정은 너무 제한적일 수 있다고 되어 있습니다.

Embedded Tomcat 에서의 기본 Max Connection 은 8192 개 입니다.

Tomcat 과 HttpClient 그리고 Elasitcsearch 에 대한 각각의 Connection, Thread Count 를 잘 조정 하셔야 성능을 최적화 할 수 있습니다.

추가적으로 Connection 과 Route 의 비율은 10:1 정도가 적절해 보입니다.

아래는 Tomcat 기본 설정 내용입니다.

- Embedded Tocmat 의 설정 중
    acceptCount 는 기본 100 개 이며 이 설정은 maxConnection 에 다다랐을 때 OS 레벨에서 큐잉 하게 되는 값 입니다.
    maxConnections 는 기본 8192 개 이며 NIO/NIO2 를 사용 하며, -1 로 설정 시 카운팅 하지 않습니다. (unlimited)
    maxThreads 는 기본 200 개 이며 connection 당 생성 가능한 최대 thread 수 입니다.
    BIO 일 경우 maxConnections 와 maxThreads 값은 같아야 합니다.

정답은 없으나 시스템 리소스 상황에 맞춰서 최적 값을 찾아 내는게 제일 중요 합니다.
위에 설정 방식이나 값이 최적 값이 아니며 상황에 맞춘 최적 값이고 다른 환경에서는 튜닝 포인트가 된다고 보는게 좋을 것 같습니다.

시스템의 ulimit 설정을 꼭 확인 하고 사용하는 stack 의 default 값도 꼭 확인 하고 사용 합시다.

성능 최적화를 위해 함께 살펴 봐야 하는 소스 코드는 

Java NIO, Executor
Tomcat Connector
Http Client (Components)
Elasticsearch RestClient

보통 Elasticsearch LLRC 를 이용해서 RESTful API 요청 하게 되면
...중략...
Request request = new Request(...중략...);
Response response = esClient.getRestClient().performRequest(request);
String body = EntityUtils.toString(response.getEntity());
...중략...

String 으로 결과를 받아서 리턴 하게 되는데 이 과정에서 JSON String 변환 시 slash 가 추가 되는 불편함이 있을 수 있습니다.
이걸 해소 하려면
...중략...
String body = EntityUtils.toString(response.getEntity());
JsonNode jsonNode = ObjectMapper.readTree(body);
...중략...
readTree 해서 JsonNode Object 로 변환 한 후 처리 하시면 {}, [] 등 모두 깔끔하게 처리가 가능 합니다.

ASIS)

{
	"response": "{ \"alias\": \"henry\" }"
}

{
	"response": "[
    	{ \"alias1\": \"henry\" },
        { \"alias2\": \"jeong\" }
      ]"
}

TOBE)

{
	"response": { "alias": "henry" }
}

{
	"response": [
    	{ "alias1": "henry" },
        { "alias2": "jeong" }
      ]
}

참고문서)

https://www.elastic.co/guide/en/logstash/current/plugins-filters-split.html

https://www.elastic.co/guide/en/logstash/current/plugins-filters-mutate.html#plugins-filters-mutate-split

예제코드)

라인단위로 정보가 작성 되어 있을 때

데이터 예시)
1|A|가
2|B|나

filter {
	split { }

	mutate {
		split => { "message" => "|" }
		add_field => {
			"first" => "%{[message][0]}"
			"second" => "%{[message][1]}"
			"third" => "%{[message][2]}"
		}
	}
}

보셔야 하는 클래스는

- TermQueryBuilder

- TermsQueryBuilder

입니다.

두 Query 의 큰 차이는 단독으로 사용 되었을 때 Scoring 이 어떻게 되느냐 인데요.

Term 은 Score 계산이 되어서 나오고 Terms 는 Constant Score Query 처럼 1.0 으로 나온다는 것입니다.

코드를 좀 더 따라 가다 보면 

- MapperFieldType

클래스 내 Query API 들에 대한 Interface 나 Implement 코드를 확인해 보실 수 있습니다.

아래는 Terms Query 에 대한 코드를 가져온 내용입니다.

    /** Build a constant-scoring query that matches all values. The default implementation uses a
     * {@link ConstantScoreQuery} around a {@link BooleanQuery} whose {@link Occur#SHOULD} clauses
     * are generated with {@link #termQuery}. */
    public Query termsQuery(Collection<?> values, @Nullable SearchExecutionContext context) {
        BooleanQuery.Builder builder = new BooleanQuery.Builder();
        for (Object value : values) {
            builder.add(termQuery(value, context), Occur.SHOULD);
        }
        return new ConstantScoreQuery(builder.build());
    }

뭐 혼자 기억 하기 위한 기록 이라서 이 정도까지만 기록해 두겠습니다.