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());
    }

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

Kibana Discover 에서 데이터 요청 시 _source 는 false 로 가져 오지 않습니다.
다만, View 형식을 Table 에서 JSON 으로 변경 시 _source:true 로 데이터를 가져 오게 됩니다.
그렇기 때문에 기본 fields 를 이용해서 문서의 field 를 가져 오게 됩니다.

이걸 기록 하는 이유는 

log file ->

filebeat input log -> filebeat processors decode_json_fields -> filebeat output logstash ->

logstash input beat -> logstash output elasticsearch -> logstash output elasticsearch codec json -> 

elasticsearch ->

kibana

이 과정에서 kibana 에서 불필요한 데이터 요청을 하는 것 같아 확인을 해보니 Table 뷰와 JSON 뷰가 다르다는 걸 확인한 결과를 기록 한 부분 입니다.

기본 요청은 _source:false 이기 때문에 불필요한 요청을 하지 않습니다.

불필요한 요청이라고 하는 이유는 fields 는 _source 에서 정보를 가져오기 때문에 중복입니다.

$ vi .bashrc

export http_proxy=http://proxy.host:port
export https_proxy=https://proxy.host:port

$ bin/logstash-plugin install plugins...

외부 인터넷 망이 막혀 있는 경우 proxy 를 이용해서 plugin 설치를 하면 됩니다.

output elasticsearch proxy 랑은 다른 내용입니다.