jjeong

docker compose 실행 시  permission denied 에러 경험을 하실 수 있습니다.

아래와 같은 방법으로 문제를 해결 할 수 있으니 환경에 맞게 적용 해 보면 좋을 것 같습니다.

docker-compose.yml)

    volumes:
      - /elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro
      - /elasticsearch/data:/usr/share/elasticsearch/data:rw
      - /elasticsearch/logs:/usr/share/elasticsearch/logs:rw

Case 1)

$ chmod 777 /elasticsearch/data

$ chmod 777 /elasticsearch/logs

Case 2)

- docker-compose.yml 안에 uid, gid 를 설정

user: "1002:0" # uid 는 host user 로 설정, gid 는 container group 으로 설정

Elasticsearch 의 경우 docker 로 구성 하시면 Container 내부에서 1000:0 으로 실행 됩니다.

즉, uid 1000(elasticsearch), gid 0(root) 가 됩니다.

그래서 bind mount 의 경우 host 에서의 권한과 container 에서의 권한을 잘 맞춰 주셔야 합니다.

$ id -u username

$ id -g username

$ docker exec -it container-name /bin/bash

그럼 즐거운 Elastic 되세요.

설정 하고 왜 바로 동작 안하지 그랬는데, 다 이유가 있었습니다.

[LifecycleSettings.java]

/*
 * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
 * or more contributor license agreements. Licensed under the Elastic License;
 * you may not use this file except in compliance with the Elastic License.
 */
package org.elasticsearch.xpack.core.ilm;

import org.elasticsearch.common.Strings;
import org.elasticsearch.common.settings.Setting;
import org.elasticsearch.common.unit.TimeValue;
import org.elasticsearch.xpack.core.scheduler.CronSchedule;

/**
 * Class encapsulating settings related to Index Lifecycle Management X-Pack Plugin
 */
public class LifecycleSettings {
    public static final String LIFECYCLE_POLL_INTERVAL = "indices.lifecycle.poll_interval";
    public static final String LIFECYCLE_NAME = "index.lifecycle.name";
    public static final String LIFECYCLE_INDEXING_COMPLETE = "index.lifecycle.indexing_complete";
    public static final String LIFECYCLE_ORIGINATION_DATE = "index.lifecycle.origination_date";
    public static final String LIFECYCLE_PARSE_ORIGINATION_DATE = "index.lifecycle.parse_origination_date";
    public static final String LIFECYCLE_HISTORY_INDEX_ENABLED = "indices.lifecycle.history_index_enabled";

    public static final String SLM_HISTORY_INDEX_ENABLED = "slm.history_index_enabled";
    public static final String SLM_RETENTION_SCHEDULE = "slm.retention_schedule";
    public static final String SLM_RETENTION_DURATION = "slm.retention_duration";


    public static final Setting<TimeValue> LIFECYCLE_POLL_INTERVAL_SETTING = Setting.positiveTimeSetting(LIFECYCLE_POLL_INTERVAL,
        TimeValue.timeValueMinutes(10), Setting.Property.Dynamic, Setting.Property.NodeScope);
    public static final Setting<String> LIFECYCLE_NAME_SETTING = Setting.simpleString(LIFECYCLE_NAME,
        Setting.Property.Dynamic, Setting.Property.IndexScope);
    public static final Setting<Boolean> LIFECYCLE_INDEXING_COMPLETE_SETTING = Setting.boolSetting(LIFECYCLE_INDEXING_COMPLETE, false,
        Setting.Property.Dynamic, Setting.Property.IndexScope);
    public static final Setting<Long> LIFECYCLE_ORIGINATION_DATE_SETTING =
        Setting.longSetting(LIFECYCLE_ORIGINATION_DATE, -1, -1, Setting.Property.Dynamic, Setting.Property.IndexScope);
    public static final Setting<Boolean> LIFECYCLE_PARSE_ORIGINATION_DATE_SETTING = Setting.boolSetting(LIFECYCLE_PARSE_ORIGINATION_DATE,
        false, Setting.Property.Dynamic, Setting.Property.IndexScope);
    public static final Setting<Boolean> LIFECYCLE_HISTORY_INDEX_ENABLED_SETTING = Setting.boolSetting(LIFECYCLE_HISTORY_INDEX_ENABLED,
        true, Setting.Property.NodeScope);


    public static final Setting<Boolean> SLM_HISTORY_INDEX_ENABLED_SETTING = Setting.boolSetting(SLM_HISTORY_INDEX_ENABLED, true,
        Setting.Property.NodeScope);
    public static final Setting<String> SLM_RETENTION_SCHEDULE_SETTING = Setting.simpleString(SLM_RETENTION_SCHEDULE,
        // Default to 1:30am every day
        "0 30 1 * * ?",
        str -> {
        try {
            if (Strings.hasText(str)) {
                // Test that the setting is a valid cron syntax
                new CronSchedule(str);
            }
        } catch (Exception e) {
            throw new IllegalArgumentException("invalid cron expression [" + str + "] for SLM retention schedule [" +
                SLM_RETENTION_SCHEDULE + "]", e);
        }
    }, Setting.Property.Dynamic, Setting.Property.NodeScope);
    public static final Setting<TimeValue> SLM_RETENTION_DURATION_SETTING = Setting.timeSetting(SLM_RETENTION_DURATION,
        TimeValue.timeValueHours(1), TimeValue.timeValueMillis(500), Setting.Property.Dynamic, Setting.Property.NodeScope);
}

설정을 하셨다면 이제는 기다리시면 됩니다. 

Elastic Stack 을 사용하다 보면 Index 를 자동으로 생성 시켜 주는 설정들을 사용 하게 됩니다.

beats 에서는 output elasticsearch 사용 시 설정을 하게 되고,

logstash 에서도 output elasticsearch 사용 시 설정을 하게 됩니다.

보통 이 설정을 아래와 같이 하는데요.

Logstash)

index

- Value type is string
- Default value is "logstash-%{+YYYY.MM.dd}"

Beats)

index

The index name to write events to when you’re using daily indices. 
The default is "beat-%{[agent.version]}-%{+yyyy.MM.dd}" 
(for example, "beat-7.6.2-2020-04-02"). 
If you change this setting, you also need to configure the setup.
template.name and setup.template.pattern options (see Elasticsearch index template).

output.elasticsearch:
  hosts: ["https://localhost:9200"]
  index: "beats-%{[agent.version]}-%{+yyyy.MM.dd}"

- filebeat, metricbeat ...

보시면 아시겠지만, Daily rolling 으로 많이 사용하게 됩니다.

무조건 하루 단위로 생성이 되기 때문에 규모가 너무 작거나 너무 크거나 할 경우 효율이 떨어 질 수 밖에 없습니다.

그래서 Index Lifecycle Management 라는 기능을 Elasticsearch 에서 제공하고 있으니 활용 하시기 바랍니다.

여기서 문제)

그럼 output.elasticsearch.index 설정과 ilm 설정이 동시에 사용 중일 때 어떤 설정에 맞춰서 index 가 생성이 될까요?

정답)

ilm 설정이 우선 합니다. 

Elastic 의 공식 메시지는 이렇습니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html

You can configure index lifecycle management (ILM) policies to automatically manage indices according to your performance, resiliency, and retention requirements.

Elasticsearch 를 Single Node 로 구성 하기 위한 docker-compose.yml 내용을 살펴 봅니다.

참고문서)

https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html

docker-compose.yml)

version: '2.2'
services:
  ${ES-SERVICE-NAME}:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    container_name: ${ES-SERVICE-NAME}
    environment:
      - node.name=${NODE-NAME}
      - cluster.name=${CLUSTER-NAME}
      - discovery.type=single-node
      - discovery.seed_hosts=${NODE-NAME}
      - path.data=/usr/share/elasticsearch/data
      - path.logs=/usr/share/elasticsearch/logs
      - bootstrap.memory_lock=true
      - http.port=9200
      - transport.port=9300
      - transport.compress=true
      - network.host=0.0.0.0
      - http.cors.enabled=false
      - http.cors.allow-origin=/https?:\/\/localhost(:[0-9]+)?/
      - gateway.expected_master_nodes=1
      - gateway.expected_data_nodes=1
      - gateway.recover_after_master_nodes=1
      - gateway.recover_after_data_nodes=1
      - action.auto_create_index=true
      - action.destructive_requires_name=true
      - cluster.routing.use_adaptive_replica_selection=true
      - xpack.monitoring.enabled=false
      - xpack.ml.enabled=false
      - http.compression=true
      - http.compression_level=3
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nproc:
        soft: 1024000
        hard: 1024000
      nofile:
        soft: 1024000
        hard: 1024000
    sysctls:
      net.core.somaxconn: 65000
    healthcheck:
      test: ["CMD-SHELL", "curl --silent --fail localhost:9200/_cat/health || exit 1"]
      interval: 30s
      timeout: 30s
      retries: 3
    restart: always
    volumes:
      - ${NAMED-VOLUME-DATA}:/usr/share/elasticsearch/data:rw
      - ${NAMED-VOLUME-LOG}:/usr/share/elasticsearch/logs:rw
#      - ${FULL-PATH-DATA}:/usr/share/elasticsearch/data:rw
#      - ${FULL-PATH-LOG}:/usr/share/elasticsearch/logs:rw
    ports:
      - 9200:9200
      - 9300:9300
    expose:
      - 9200
      - 9300
    networks:
      - ${NETWORK-NAME}

volumes:
  ${NAMED-VOLUME-DATA}:
    driver: local
  ${NAMED-VOLUME-LOG}:
    driver: local

networks:
  ${NETWORK-NAME}:
    driver: bridge

Single Node 로 구성 하기 위해 중요한 설정은

- environment: 섹션에서 discovery.type=single-node 

입니다.

만약, Clustering 구성을 하고 싶다면 위 설정을 제거 하고 아래 세개 설정을 작성 하시면 됩니다.

- cluster.initial_master_nodes=# node 들의 private ip 를 등록 합니다.
- discovery.seed_hosts=# node 들의 private ip 를 등록 합니다.

- network.publish_host=# 컨테이너가 떠 있는 host 의 private ip 를 등록 합니다.

path.data 에 대한 구성을 복수로 하고 싶으실 경우

- volumes: 섹션에서 named volume 을 여러개 설정 하시거나

- bind mount 설정을 구성 하셔서 

적용 하시면 됩니다.

위 docker-compose.yml 을 기준으로 single node 구성과 cluster 구성을 모두 하실 수 있습니다.

• ${....} 는 변수명 입니다.
  • 본인의 환경에 맞춰 작명(?) 하셔서 변경 하시면 됩니다.

정답이라기 보다는 구성 하면서 경험한 내용을 작성 한 것입니다.

나중에 기억이 나지 않을 수도 있으니 정상 동작 했던 내용을 기록 합니다.

Elasticsearch Docker Compose 구성 중 주의 사항)

- volume 구성 시 bind mount 를 사용할 경우는 mount 할 storage 를 미리 생성해 두어야 합니다.
- bind mount 사용 시 absolute path 설정을 하셔야 합니다.
- single node 구성 시 network.publish_host 설정은 하지 않아도 됩니다.
- cluster 구성 시 (물리적으로 node 3개) 개별 node 에서 clustering 을 하기 
위해서는 network.publish_host 설정을 하셔야 합니다.
- cluster 구성 시 컨테이너 내부 node 설정에는 private ip 를 등록 합니다.
- sysctls 옵션 에서 vm.max_map_count 설정이 되지 않기 때문에 host 에서 
$ sudo sysctl -w vm.max_map_count=262144 를 실행 해야 합니다.

Elasticsearch 버전이 올라 가면서 master node 를 최소 쿼럼 구성으로 해야 하는데요.

아마 잘 아시겠지만 Single node 구성을 원하시는 분은 아래 설정을 통해서 실행 하시면 됩니다.

[Single node 설정]

discovery.type=single-node

이 설정은 아래 설정이 포함되어 있을 경우 충돌이 납니다.

cluster.initial_master_nodes

본 설정을 주석 처리 하거나 삭제 하신 후 실행 시키면 정상 동작 합니다.

Elastic 공식 문서에 자세한 설명이 나와 있으니 참고 하시면 좋습니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-settings.html#modules-discovery-settings

Elasticsearch 를 사용 하다 보면 Maximum 값에 대한 궁금증이 생길 때가 있습니다.

지나가다 또 기억 못할 까봐 적어 봅니다.

1. Shard 하나가 가질 수 있는 최대 Document/Term 의 수는 대략 21억개 입니다.

Elasticsearch 에서 Shard 는 Lucene 기준에 Segments 에 해당 합니다.

공식 문서에는 아래와 같이 나와 있습니다.

https://lucene.apache.org/core/8_4_1/index.html

https://lucene.apache.org/core/8_4_1/core/org/apache/lucene/codecs/lucene84/package-summary.html#Limitations

Lucene uses a Java int to refer to document numbers, 
and the index file format uses an Int32 on-disk to store document numbers. 
This is a limitation of both the index file format and 
the current implementation. 
Eventually these should be replaced with either UInt64 values, 
or better yet, VInt values which have no limit.

그래서 == 2,147,483,647

2. Shard  1개의 크기는 너무 작아도 너무 커도 안됩니다.

실시간 서비스를 위한 용도로는 ~ 10GB

백오피스 운영을 위한 용도로는 ~ 50GB (그러나 Aggregation 질의가 많고 검색 범위가 넓을 경우 20GB 정도로 사용하세요.)

정답은 없으며, 다양한 환경에 따라 적절히 구성해서 사용을 하셔야 합니다.

3. Document 1개의 크기는 최대 2GB 까지 입니다.

그러나 이렇게 까지 사용 하시라고 절대 저는 추천 하지 않습니다.

Top N 개에 대한 문서를 검색 하기 위한 성능 개선 제안으로 2012년에 처음 이슈화 되었던 것 같습니다.

처음에 저도 WAND 가 뭐지?? 했었는데요.

기억력이 나빠서 자꾸 잊어버리네요.

Weak and = Weak AND = WAND 이렇게 됩니다.

즉, Elasticsearch 에서는 minimum_should_match 라는 개념이 들어가 있다는 것인데,

정확도가 떨어지지 않는다고 합니다.

어찌되었든,  WAND와 유사 개념이라고 보시면 이해 하기 쉬우실 것 같습니다.

근데 앞에 보시면 Block-Max 라고 붙어 있죠.

이걸 또 초간단하게 설명 하면 문서를 특정 블럭단위로 묶으고 그 안에서의 Max Score 를 기록해 두는 방식 입니다.

이렇게 해서 문서 스캔 범위를 줄이게 되어 성능성 이득을 볼 수 있는 내용이라고 보시면 될 것 같습니다.

뭐 문서랑 알고리즘을 잘 읽어 보시면 더 심오한 내용이 있으나 쉽게 접근하는 것도 중요하다고 생각 하기 때문에 이렇게 정리 하도록 하겠습니다.

자세한 내용이 궁금하신 분은 아래 문서 보시면 됩니다.

http://engineering.nyu.edu/~suel/papers/bmw.pdf

더불어 Elastic 공홈에 올라온 관련 글 링크 입니다.

https://www.elastic.co/blog/elasticsearch-7-6-0-released
https://www.elastic.co/blog/faster-retrieval-of-top-hits-in-elasticsearch-with-block-max-wand
https://www.elastic.co/blog/index-sorting-elasticsearch-6-0

여기서 추가적으로 나오는 기법들이  

- Early Termination

이건 탐색 할 때 특정 조건에 맞춰 전체를 스캔 하지 않고 중간에 멈추고 스캔한 문서를 대상으로 리턴 하는 방식입니다.

- Document At A Time

문서에 대한 포인트 탐색 으로 보시면 될 것 같고 성능이 우수 합니다.

- Term At A Time

색인어에 대한 탐색을 하는 것으로 별도의 데이터구조에 따른 병목이 발생 할 수 있습니다.

등이 있습니다.

최종 정리를 하면,

1. Top N 개에 대해서 빠르게 조회를 한다.

2. 정확도가 떨어지지 않는다.

3. 그러므로 고민 하지 말고 최신 Elasticsearch 를 사용 하면 알아서 성능적 향상을 가져 올 수 있으니 사용 하시면 된다

는 이야기 였습니다.

굉장히 좋은 제품인데 ㅎㅎ 아직 잘 모르시는 분들이 많으신 것 같아서 제가 소개해 보려고 합니다.

이미 Elastic 공홈에는 올라가 있습니다.

관련 글)

https://www.elastic.co/kr/blog/automation-through-search-analytics-with-elastic-app-search

https://www.elastic.co/kr/blog/elastic-app-search-now-available-on-elasticsearch-service

https://swiftype.com/documentation/app-search/getting-started

기본적으로는 elastic 사가 swiftype 이라는 회사를 합병 하면서 관련 제품이 enable 되었다고 보시면 됩니다.

제 기억에는  샌프란시스코에서 했던 2번째 Elastic{On} 에서 소개가 되었던 것 같습니다.

기본 통신 방식은 (글로 작성 하기 때문에 전달이 잘 안될 수도 있으니 양해 바랍니다.)

Elasticsearch Cluster <-----> App Search <-----> App Search API <-----> Your Application

보셔서 아시겠지만 App Search API 를 이용하기 때문에 기존에 Elasticsearch Cluster 로 질의 하기 위한 별도 API Gateway 나 WAS 를 구현 하셨던 분들은 더 이상 구현 하지 않으셔도 됩니다.

더불어 검색을 통한 사용자 행동로그 역시 요구사항에 따라 다를 수 있지만, App Search 에서 자동으로 수집, 분석을 다 해줍니다.

엄청나게 편리 하겠죠!!

이 제품을 잘 활용 하시면 실제 구축 시간 절약이 가능하고, 검색관련 전문 지식이 없으셔도 검색 서비스를 잘 운영 할 수 있습니다.

한번 시도해 보시죠)

https://www.elastic.co/app-search

https://www.elastic.co/downloads/app-search

https://www.elastic.co/downloads/elasticsearch

위에서 말씀 드렸듯이 기본 Elasticsearch 가 설치 되어 있어야 합니다.

다운로드 페이지 보시면 기본 설치 과정에 대한 내용이 있으니 참고 하셔서 좋은 경험해 보시길 바랍니다.

Elasticsearch Analysis Arirang Plugin 7.5.0 올렸습니다.

바뀐 내용없고 lucene 과 elasticsearch 버전만 올라 갔습니다.

https://github.com/HowookJeong/elasticsearch-analysis-arirang/releases/tag/7.5.0

설치 방법은 아래와 같습니다.

로컬 빌드 후 파일로 설치)

elasticsearch-7.5.0$ bin/elasticsearch-plugin install file:///git/elasticsearch-analysis-arirang/target/elasticsearch-analysis-arirang-7.5.0.zip

github 에 올라간 release 파일로 설치)

elasticsearch-7.5.0$ bin/elasticsearch-plugin install https://github.com/HowookJeong/elasticsearch-analysis-arirang/releases/download/7.5.0/elasticsearch-analysis-arirang-7.5.0.zip