Opensearch

1. ILM (Index Lifecycle Management)

ILM(인덱스 수명 주기 관리)는 OpenSearch에서 인덱스의 생성부터 삭제까지 데이터의 수명 주기를 관리하는 정책입니다. 데이터를 저장하는 인덱스는 시간이 지남에 따라 자주 액세스되던 데이터에서 거의 사용되지 않는 데이터로 바뀔 수 있으며, 이러한 데이터를 효율적으로 관리하기 위해 ILM 정책을 설정할 수 있습니다.

ILM의 주요 단계:

  • Hot Phase: 자주 쿼리되고 실시간으로 인덱싱되는 데이터를 저장하는 단계.
  • Warm Phase: 자주 사용되지는 않지만 여전히 데이터를 조회해야 할 때 사용하는 단계. 세그먼트 병합과 같은 최적화 작업을 통해 저장 공간을 절약할 수 있음.
  • Cold Phase: 거의 사용되지 않는 오래된 데이터를 저장하는 단계로, 저렴한 스토리지에서 데이터를 유지하며 성능보다는 비용 효율성을 중시.
  • Delete Phase: 데이터가 더 이상 필요 없을 때 자동으로 인덱스를 삭제하는 단계.

ILM의 주요 이점:

  • 비용 최적화: 데이터의 사용 빈도에 따라 적절한 스토리지로 이동시켜, 저장 비용을 줄임.
  • 자동화: 데이터를 관리하는 프로세스를 자동화하여, 수동으로 관리할 필요를 줄임.
  • 성능 유지: 자주 사용되는 데이터는 고성능 스토리지에 저장하고, 오래된 데이터는 비용 효율적인 스토리지로 이동함.

ILM 예시:

{
  "policy": {
    "phases": {
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "require": {
              "box_type": "warm"
            }
          },
          "forcemerge": {
            "max_num_segments": 1
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "require": {
              "box_type": "cold"
            }
          },
          "freeze": {},
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

이 예시에서는 7일 후 warm phase, 30일 후 cold phase, 90일 후 삭제를 설정하고 있습니다.

2. Cold Storage

Cold Storage는 OpenSearch에서 거의 사용되지 않는 데이터를 저장하는 저비용 스토리지입니다. Cold 스토리지는 빠른 응답 속도가 필요하지 않은 데이터를 장기적으로 저장하기 위해 사용되며, 비용 효율성을 극대화하는 데 목적이 있습니다.

Cold Storage의 특징:

  • 저비용: 고성능이 필요하지 않은 데이터에 대해 저렴한 하드웨어 리소스를 사용.
  • 읽기 전용: Cold Storage에 저장된 데이터는 수정이 불가능하고, 주로 읽기 전용으로 사용됨.
  • 쿼리 성능 저하: cold 스토리지에 있는 데이터는 쿼리 성능이 낮지만, 비용 절감을 위해 이를 감수할 수 있음.

Cold Migration:

Cold Migration은 인덱스가 hot 또는 warm 스토리지에서 cold 스토리지로 이동하는 과정을 말합니다. ILM 정책을 통해 자동으로 cold phase로 이동할 수 있습니다. Cold 스토리지에 저장된 데이터는 더 이상 수정되지 않고, 자주 쿼리되지 않는 데이터로, 주로 비용 절감을 위해 이동됩니다.

3. Index Template (인덱스 템플릿)

Index Template는 OpenSearch에서 새로운 인덱스를 생성할 때 사용하는 템플릿입니다. 인덱스 템플릿을 통해 인덱스의 매핑, 설정, ILM 정책 적용 등을 미리 정의해 놓으면, 인덱스를 생성할 때 일관된 구성을 유지할 수 있습니다.

Index Template의 주요 구성 요소:

  • 매핑 (Mappings): 필드 유형과 분석기를 정의하여 데이터의 저장 및 검색 방식을 결정.
  • 설정 (Settings): 인덱스의 복제본, 세그먼트, 스토리지 할당 등 다양한 설정을 정의.
  • ILM 정책 적용: 인덱스 템플릿을 사용하여 생성되는 인덱스에 ILM 정책을 자동으로 적용할 수 있음.

Index Template 예시:

{
  "index_patterns": ["logs-*"],
  "template": {
    "aliases": {
      "my-alias": {
        "is_write_index": true       // 이 alias를 통해 데이터를 기록할 수 있는 인덱스로 설정
      }
    },
    "settings": {
      "index.lifecycle.name": "my-ilm-policy",
      "index.lifecycle.rollover_alias": "logs-alias",
      "number_of_shards": 1,
      "number_of_replicas": 1
    },
    "mappings": {
      "properties": {
        "@timestamp": {
          "type": "date"
        },
        "message": {
          "type": "text"
        }
      }
    }
  }
}

이 예시에서는 logs-* 패턴으로 생성되는 인덱스에 대해 ILM 정책을 적용하고, 매핑 및 설정을 정의합니다.

ILM, Cold Storage, 그리고 Index Template의 연계

  1. Index Template는 인덱스를 생성할 때 ILM 정책을 자동으로 적용하여 데이터가 적절한 수명 주기를 거칠 수 있도록 합니다.
    • 예를 들어, 로그 데이터를 수집하는 인덱스는 logs-* 패턴으로 생성되고, ILM 정책에 따라 hot, warm, cold 스토리지로 이동한 후 일정 시간이 지나면 삭제됩니다.
  2. ILM은 데이터를 cold storage로 이동시키는 과정에서 데이터 보존 비용을 절감하고, 필요에 따라 데이터를 삭제하는 역할을 합니다.
    • 일정 시간 동안 자주 사용되지 않은 데이터는 ILM에 의해 cold phase로 자동 이동되고, 그 이후에 delete phase로 이동하여 삭제됩니다.
  3. Cold Storage는 자주 액세스하지 않는 데이터를 저장함으로써 성능보다는 저장 비용을 최적화하는 역할을 하며, ILM 정책을 통해 효율적으로 관리됩니다.

OpenSearch에서 데이터를 인덱싱(indexing)하는 방식과 analyzer(분석기)의 역할은 데이터의 저장, 검색, 검색 성능에 중요한 영향을 미칩니다. 인덱싱은 데이터가 어떻게 저장되고 검색될 수 있도록 준비되는 과정이며, 분석기는 텍스트 데이터를 어떻게 처리하고 분석할지를 결정합니다.

3-1. OpenSearch의 Rollover 기능

Rollover는 OpenSearch에서 인덱스 관리를 자동화하는 중요한 기능입니다. 주로 일정 조건(문서 수, 인덱스 크기, 인덱스의 나이 등)이 만족되었을 때, 새로운 인덱스를 생성하고, 그 인덱스에 데이터를 기록하게 하는 방식입니다. 이를 통해 인덱스가 너무 커지거나 오래된 데이터를 포함하는 경우, 새로운 인덱스로 데이터를 넘기며 관리가 가능합니다.

Rollover가 필요한 이유:

  1. 인덱스의 성능 관리: 인덱스가 커지면 성능이 저하될 수 있습니다. Rollover를 통해 성능 저하를 방지할 수 있습니다.
  2. 데이터 분리: 오래된 데이터와 새로운 데이터를 분리하여, 검색 성능과 관리의 효율성을 높일 수 있습니다.
  3. 자동화: 수동으로 인덱스를 관리할 필요 없이, 자동으로 인덱스를 생성하고 관리할 수 있습니다.

Rollover와 Alias의 연관성

Rollover는 보통 alias와 함께 사용됩니다. Alias는 롤오버를 통해 만들어진 여러 인덱스를 하나의 이름으로 묶고, 데이터를 기록할 인덱스를 지정하는 데 사용됩니다. 주로 롤오버된 인덱스는 읽기 전용으로 바뀌고, 새로 생성된 인덱스가 write index로 설정됩니다.

Rollover의 주요 조건

Rollover는 아래와 같은 조건을 기준으로 작동합니다.

  • max_age: 인덱스의 나이가 특정 기간을 초과했을 때.
  • max_docs: 인덱스에 저장된 문서 수가 특정 숫자를 초과했을 때.
  • max_size: 인덱스의 크기가 특정 용량을 초과했을 때.

Rollover와 Alias 사용 예시

Alias와 Rollover 설정 절차:

  1. Alias 설정: logs라는 alias를 만들고, logs-000001이라는 첫 번째 인덱스를 생성합니다.
  2. Rollover 설정: 일정 조건이 만족되면 자동으로 새로운 인덱스(logs-000002)가 생성되고, logs alias가 새 인덱스를 가리키게 됩니다.

Rollover와 Alias 설정 예시

1. 첫 번째 인덱스와 Alias 생성:

PUT /logs-000001
{
  "aliases": {
    "logs": {
      "is_write_index": true  // 현재 이 인덱스에만 데이터를 기록
    }
  }
}

2. Rollover 조건 설정:

POST /logs/_rollover
{
  "conditions": {
    "max_age": "7d",         // 7일이 지나면 롤오버
    "max_docs": 1000,        // 문서가 1000개 이상이면 롤오버
    "max_size": "5gb"        // 인덱스 크기가 5GB를 넘으면 롤오버
  }
}

3. 새 인덱스와 Alias 자동 전환:

롤오버 조건이 만족되면 OpenSearch는 자동으로 새로운 인덱스(logs-000002)를 생성하고, logs alias를 새 인덱스로 연결합니다. 이전 인덱스(logs-000001)는 읽기 전용 상태가 되고, 새 인덱스(logs-000002)가 쓰기 가능한 인덱스로 설정됩니다.

Rollover와 Alias의 관계 정리

항목 설명
Alias 여러 인덱스를 하나의 논리적 이름으로 묶는 기능. Rollover와 함께 사용하여 읽기 및 쓰기 인덱스 관리.
Rollover 조건 max_age, max_docs, max_size 등의 조건에 따라 새로운 인덱스를 생성.
is_write_index Alias가 가리키는 여러 인덱스 중 실제 데이터를 기록할 인덱스를 지정하는 옵션.
Rollover 명령 특정 조건을 만족하면 새로운 인덱스를 생성하고, alias가 새로운 인덱스를 가리키도록 전환.
인덱스 관리 Rollover를 통해 인덱스가 너무 커지거나 오래되기 전에 새로운 인덱스로 데이터를 기록하게 관리.
Alias의 이점 인덱스의 이름이 바뀌어도 alias를 통해 지속적으로 데이터를 기록하고, 검색할 수 있음.

예시 플로우:

  1. 초기 설정: logs-000001 인덱스를 생성하고, logs라는 alias에 is_write_index를 true로 설정.
  2. 롤오버 발생: logs alias가 가리키는 인덱스의 조건(7일이 경과하거나, 문서가 1000개 이상, 또는 크기가 5GB를 초과)이 만족되면, 새로운 인덱스(logs-000002)를 생성하고, logs alias는 새 인덱스를 가리키도록 전환.
  3. 지속적인 관리: 반복적으로 새로운 인덱스를 생성하고 alias를 업데이트하며 인덱스를 자동 관리.

4. OpenSearch의 인덱싱(Indexing) 방식

인덱싱은 데이터를 OpenSearch에 저장할 때 그 데이터를 검색 가능한 형태로 변환하는 과정입니다. OpenSearch는 각 문서를 저장할 때 해당 문서의 필드를 분석하여 역색인(inverted index) 형태로 저장합니다. 역색인은 일반적으로 단어와 문서의 관계를 효율적으로 찾을 수 있도록 하는 데이터 구조입니다.

인덱싱 과정:

  1. 문서(Document) 저장: OpenSearch에 새로운 문서가 저장되면, 그 문서가 JSON 형식으로 표현됩니다. 이 문서는 필드와 필드 값의 쌍으로 이루어져 있습니다.

  2. 필드 분석(Field Analysis): 각 필드는 인덱싱이 필요한지 여부에 따라 처리됩니다. 기본적으로 텍스트 데이터는 분석기를 통해 분석됩니다.

  3. 역색인(Inverted Index) 생성: 텍스트 필드를 분석한 결과(토큰, 단어 등)를 역색인에 저장합니다. 역색인은 검색 시 사용되며, 단어와 그 단어가 포함된 문서 ID가 매핑됩니다. 이를 통해 단어가 포함된 문서를 빠르게 찾을 수 있습니다.

OpenSearch 인덱싱의 특징:

  • 실시간 인덱싱: OpenSearch는 데이터를 실시간으로 인덱싱하여 검색할 수 있도록 설계되어 있습니다.
  • 역색인 구조: 각 단어를 문서와 매핑하는 방식으로 검색 성능을 극대화합니다.
  • 유연한 스키마: 인덱싱 시 자동으로 필드의 타입을 감지하거나, 미리 설정된 매핑을 통해 필드의 타입을 지정할 수 있습니다.

5. Analyzer(분석기)의 역할

Analyzer(분석기)는 텍스트 데이터를 분석하고 처리하는 도구입니다. OpenSearch는 텍스트 데이터를 분석하여 검색 가능한 형태로 변환하는데, 이 과정에서 분석기는 텍스트 데이터를 토큰화하고 필터링하는 작업을 수행합니다.

Analyzer의 역할:

  1. 토큰화(Tokenization):
    • 분석기는 텍스트 데이터를 단어(토큰)로 분리합니다. 예를 들어, "The quick brown fox"라는 텍스트가 있다면, 분석기는 이를 [the, quick, brown, fox]로 분리할 수 있습니다.
  2. 소문자 변환:
    • 분석기는 대문자를 소문자로 변환하여 검색 시 대소문자 구분 없이 처리할 수 있게 만듭니다. 예를 들어, "Quick"는 quick로 변환됩니다.
  3. 불용어(Stop Words) 제거:
    • 분석기는 검색에서 의미가 없는 불용어를 제거할 수 있습니다. 예를 들어, "the", "and", "is"와 같은 단어는 일반적으로 검색의 중요성을 떨어뜨리므로 제거됩니다.
  4. 형태소 분석:
    • 분석기는 언어에 따라 형태소 분석을 수행하여 단어의 다양한 형태를 처리할 수 있습니다. 예를 들어, “running”은 “run”으로, “cars”는 “car”로 변환될 수 있습니다.
  5. 커스터마이징 가능:
    • OpenSearch에서는 기본 분석기를 사용할 수 있지만, 필요에 따라 사용자 정의 분석기를 만들어 사용할 수도 있습니다. 이를 통해 특정한 토큰화 방법이나 필터링 규칙을 설정할 수 있습니다.

Analyzer의 구성 요소:

  1. Char Filter:
    • 텍스트 데이터를 토큰화하기 전에 먼저 처리하는 필터입니다. 특정 문자를 제거하거나 변환하는 작업을 합니다. 예를 들어, HTML 태그를 제거하는 필터가 포함될 수 있습니다.
  2. Tokenizer:
    • 분석기의 핵심 역할을 하는 토큰화 과정입니다. 텍스트를 단어(토큰)로 나누는 작업을 수행합니다. OpenSearch는 여러 종류의 토크나이저를 제공하며, 텍스트의 구조에 따라 적절한 토크나이저를 선택할 수 있습니다.
  3. Token Filter:
    • 토큰화된 데이터를 추가로 처리하는 단계입니다. 예를 들어, 소문자 변환, 불용어 제거, 형태소 분석 등이 이 단계에서 수행됩니다.

Analyzer 예시:

{
  "settings": {
    "analysis": {
      "analyzer": {
        "custom_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "stop",
            "porter_stem"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "content": {
        "type": "text",
        "analyzer": "custom_analyzer"
      }
    }
  }
}

이 예시에서는 custom_analyzer를 정의하여 standard tokenizer와 lowercase 필터, 불용어 제거(stop filter), 그리고 porter_stem 필터를 사용하여 텍스트를 처리합니다.

  • standard tokenizer: 텍스트를 단어 단위로 나누는 기본 토크나이저.
  • lowercase filter: 대문자를 소문자로 변환.
  • stop filter: 불용어 제거.
  • porter_stem filter: 단어의 어근(stem)으로 변환하여 검색 성능 향상.

6. 인덱싱과 Analyzer의 관계

  • 인덱싱 과정에서 Analyzer의 역할: OpenSearch에서 문서를 인덱싱할 때, Analyzer는 필드의 텍스트 데이터를 처리하여 역색인을 생성합니다. 분석기가 텍스트 데이터를 처리한 결과에 따라 데이터가 어떻게 검색될지가 결정됩니다.
  • 검색 과정에서 Analyzer의 역할: 검색할 때도 분석기는 검색어를 분석하여 동일한 방식으로 토큰화하고, 이를 통해 인덱싱된 데이터와 비교하여 검색 결과를 제공합니다.

7. rediSearch와 비교

Redis는 기본적으로 key-value 구조를 사용하지만, RediSearch는 검색을 효율적으로 처리하기 위해 역색인(Inverted Index) 기능을 추가로 제공하여 보다 복잡한 검색 쿼리를 처리할 수 있습니다. 역색인이 가능해진 이유는 RediSearch가 일반적인 Redis 데이터 구조와는 다른 방식으로 데이터를 저장하고 조회하기 때문입니다. 이를 이해하기 위해 몇 가지 핵심 개념을 살펴보겠습니다.

7-1. Redis 기본 구조

  • Redis는 일반적으로 key-value 데이터베이스로 작동합니다. 각 키에 대해 단일 값을 저장할 수 있으며, 이 값은 문자열, 리스트, 셋, 해시맵 등의 형태를 취할 수 있습니다.
  • 기본적으로 키를 기반으로 데이터를 조회하고 관리하므로 고급 검색이나 텍스트 기반 검색은 지원되지 않습니다.

7-2. RediSearch의 역할

RediSearch는 Redis 위에서 동작하는 모듈로, 데이터를 검색할 수 있는 고급 기능을 추가합니다. 이를 통해 다음과 같은 기능을 사용할 수 있습니다:

  • 전체 텍스트 검색(Full-text search): 문서에서 특정 단어나 구를 검색하는 기능.
  • 다양한 필터링 및 정렬 옵션: 특정 필드 값을 기준으로 데이터를 필터링하고 정렬하는 기능.
  • 자동 완성, 하이라이팅 등의 검색 관련 기능도 제공합니다.

7-3. 역색인(Inverted Index)

  • 역색인은 검색 엔진의 핵심 데이터 구조로, 특정 단어가 어떤 문서에 위치하는지 빠르게 찾아낼 수 있도록 설계된 인덱스입니다.
  • 예를 들어, 문서 A, B, C에 단어 “apple”이 포함되어 있다면, 역색인은 “apple”이라는 키를 가지고 있고 그 키에 문서 A, B, C의 참조를 저장합니다.
  • 이를 통해 특정 단어에 해당하는 문서를 빠르게 찾을 수 있습니다.

7-4. RediSearch에서 역색인 구조

RediSearch는 Redis에 특화된 방식으로 역색인을 구현합니다. 텍스트를 저장할 때 RediSearch는 각 단어를 키로, 해당 단어가 포함된 문서 ID를 값으로 저장하는 방식입니다. 이 구조 덕분에, RediSearch는 단어 기반으로 데이터를 빠르게 검색할 수 있습니다.

  • 데이터 저장 방식: 문서를 저장할 때, RediSearch는 문서의 텍스트를 분석하고 단어별로 역색인을 만듭니다.
  • 역색인 조회: 검색할 때는 역색인에서 특정 단어가 포함된 모든 문서를 조회하고, 결과를 반환합니다.
  • 예를 들어, Hello world라는 텍스트를 인덱싱하면 RediSearch는 Hello와 world라는 단어에 대해 각각 역색인을 만듭니다. 그 후 사용자가 world라는 단어를 검색하면 해당 단어가 포함된 문서를 빠르게 찾을 수 있습니다.

7-5. RediSearch에서 가능하게 하는 이유

  • 데이터 구조: RediSearch는 Redis의 기본 key-value 구조와는 별개로, 데이터의 효율적인 검색을 위해 역색인(Inverted Index)을 사용합니다. 이를 통해 단어와 문서 ID를 매칭하는 테이블을 생성하여 빠른 검색이 가능합니다.
  • 트리 구조: RediSearch는 B-tree와 같은 고급 데이터 구조를 활용하여 검색 성능을 향상시키고, 역색인과 결합하여 빠르게 특정 문서나 데이터를 찾을 수 있습니다.
  • 추가적인 기능: RediSearch는 텍스트 분석, 토큰화, 정규화 등을 통해 단어를 처리하고 인덱스에 저장하여 검색 성능을 최적화합니다.

7-6. Redis 자체에는 없는 고급 검색 기능

  • Redis의 기본 키-값 구조는 단순하지만, RediSearch 모듈은 역색인과 같은 고급 데이터 구조를 활용하여 텍스트 검색, 복합 쿼리 등을 지원하는 방식으로 확장된 기능을 제공합니다. RediSearch는 자체적으로 추가된 모듈이므로, Redis의 성능을 그대로 유지하면서 복잡한 검색 기능을 구현할 수 있는 것입니다.

8. OpenSearch Text Analysis 요소 정리

분류 설명 종류 및 설명
Analyzers 텍스트를 토큰화하고 필터링하는 프로세스를 정의합니다. - standard: 기본 분석기. 일반적인 텍스트 토큰화를 수행.
- simple: 비알파벳 문자를 기준으로 텍스트를 토큰화.
- whitespace: 공백을 기준으로 텍스트를 토큰화.
    - stop: 불용어를 제거하는 분석기.
- keyword: 전체 텍스트를 단일 토큰으로 처리.
- custom: 사용자 정의 분석기, tokenizer와 token filter를 조합해 사용.
Tokenizers 텍스트를 토큰으로 나누는 작업을 수행합니다. - standard: 일반적인 텍스트를 기준으로 단어 단위로 분리.
- whitespace: 공백 문자를 기준으로 분리.
- letter: 알파벳 문자를 기준으로 토큰화.
    - ngram: n-그램 단위로 텍스트를 나눔.
- edge_ngram: 문자열의 앞부분에서 n-그램으로 분리.
- pattern: 정규 표현식을 사용하여 토큰화.
Token Filters 토큰화된 텍스트를 추가로 처리하여 변환하거나 필터링합니다. - lowercase: 모든 문자를 소문자로 변환.
- stop: 불용어를 제거.
- porter_stem: 단어를 어근으로 변환(어간 추출).
    - asciifolding: 비ASCII 문자를 유사한 ASCII 문자로 변환.
- synonym: 동의어를 처리하여 동의어 검색이 가능하게 함.
- shingle: 여러 토큰을 조합해 새로운 토큰 생성.
Normalizers 주로 keyword 필드에 사용되며, 필드를 비교하기 전에 문자열을 표준화합니다. - lowercase: 모든 문자를 소문자로 변환.
- asciifolding: 비ASCII 문자를 유사한 ASCII 문자로 변환.
- custom: 사용자 정의 필터를 적용할 수 있음.

각 요소 설명:

  1. Analyzers: 텍스트를 어떻게 처리할지 결정하는 분석기로, 텍스트를 토큰화하고 필터링하는 전체 프로세스를 정의합니다. OpenSearch는 기본적인 분석기를 제공하며, 사용자가 직접 custom analyzer를 정의할 수도 있습니다.

  2. Tokenizers: 텍스트를 토큰(단어)로 나누는 역할을 합니다. 예를 들어, standard tokenizer는 단어 단위로 텍스트를 분리하고, ngram tokenizer는 n개의 문자 단위로 나누는 등 다양한 방식으로 텍스트를 토큰화할 수 있습니다.

  3. Token Filters: 토큰화된 텍스트에 추가적인 변환을 적용하는 필터입니다. 예를 들어, lowercase 필터는 모든 문자를 소문자로 변환하고, synonym 필터는 동의어를 추가하여 더 유연한 검색을 가능하게 합니다.

  4. Normalizers: 주로 keyword 필드에 사용되며, 텍스트 필드가 저장되기 전에 문자열을 표준화하는 작업을 수행합니다. 일반적으로 소문자 변환이나 비ASCII 문자 변환과 같은 간단한 작업을 수행하며, 검색 시 일관성을 유지하도록 돕습니다.