Opensearch概念まとめ

## 1. **ILM (Index Lifecycle Management)**

**ILM（インデックスライフサイクル管理）**は、OpenSearchでインデックスの**作成から削除まで**データのライフサイクルを管理するポリシーです。データを保存するインデックスは時間の経過とともに、頻繁にアクセスされるデータからほとんど使用されなくなるデータへと変化します。こうしたデータを効率的に管理するため、ILMポリシーを設定することができます。

### ILMの主要なフェーズ:
- **Hotフェーズ**: 頻繁にクエリされ、リアルタイムでインデックス化されるデータを保存する段階。
- **Warmフェーズ**: 頻繁に使用されないが、まだデータを参照する必要がある場合に使用する段階。**セグメントマージ**などの最適化作業によりストレージスペースを節約可能。
- **Coldフェーズ**: ほとんど使用されない古いデータを保存する段階で、**低コストのストレージ**でデータを保持し、パフォーマンスよりもコスト効率を重視。
- **Deleteフェーズ**: データが不要になったときに**自動的にインデックスを削除**する段階。

### ILMの主な利点:
- **コスト最適化**: データの使用頻度に応じて適切なストレージに移動させ、保存コストを削減。
- **自動化**: データを管理するプロセスを自動化し、手動で管理する必要が減少。
- **パフォーマンス維持**: 頻繁に使用されるデータは高性能ストレージに保存し、古いデータはコスト効率の良いストレージに移動。

### ILMの例:
```json
{
  "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フェーズ**、**30日後にcoldフェーズ**、**90日後に削除**される設定がされています。

---

## 2. **Cold Storage**

**Cold Storage**は、OpenSearchにおいて**ほとんど使用されないデータ**を保存する**低コストのストレージ**です。Cold Storageは、即座の応答速度が必要ないデータを長期間保存するために使用され、コスト効率を最大化することを目的としています。

### Cold Storageの特徴:
- **低コスト**: 高性能を必要としないデータに対して安価なハードウェアリソースを使用。
- **読み取り専用**: Cold Storageに保存されたデータは修正が不可能で、主に読み取り専用で使用。
- **クエリ性能の低下**: coldストレージに保存されたデータのクエリ性能は低下するが、コスト削減を優先。

### Cold Migration:
Cold Migrationとは、インデックスがhotまたはwarmストレージから**coldストレージに移動する過程**を指します。**ILMポリシー**によって自動的にcoldフェーズに移行できます。Coldストレージに保存されたデータはもはや修正されず、頻繁にクエリされないデータで、主にコスト削減のために移動されます。

---

## 3. **Index Template (インデックステンプレート)**

**Index Template**は、OpenSearchにおいて新しいインデックスを作成する際に使用するテンプレートです。インデックステンプレートを使ってインデックスのマッピング、設定、ILMポリシーの適用などを事前に定義しておけば、インデックス作成時に一貫した設定を維持できます。

### Index Templateの主な構成要素:
- **マッピング (Mappings)**: フィールドの型や分析器を定義し、データの保存および検索方式を決定。
- **設定 (Settings)**: インデックスのレプリカ、セグメント、ストレージ割り当てなど様々な設定を定義。
- **ILMポリシー適用**: インデックステンプレートを使用して作成されたインデックスに**ILMポリシーを自動適用**可能。

### Index Templateの例:
```json
{
  "index_patterns": ["logs-*"],
  "template": {
    "aliases": {
      "my-alias": {
        "is_write_index": true       // このエイリアスを介してデータを書き込むインデックスに設定
      }
    },
    "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**に移行することで、**データ保管コストを削減**し、必要に応じてデータを削除する役割を果たします。

3. **Cold Storage**は頻繁にアクセスされないデータを保存し、性能よりも**コスト最適化**を重視し、ILMポリシーを通じて効率的に管理されます。

こちらは、OpenSearchの**Rollover**機能に関する技術情報の日本語訳です。

---

### 3-1. OpenSearchの**Rollover**機能

**Rollover**は、OpenSearchでインデックス管理を自動化する重要な機能です。主に、**特定の条件**（ドキュメント数、インデックスサイズ、インデックスの年齢など）が満たされたときに、**新しいインデックスを作成**し、そのインデックスにデータを書き込む方法です。これにより、インデックスが大きくなりすぎたり、古いデータを含む場合でも、別の新しいインデックスにデータを移行して管理できます。

#### Rolloverが必要な理由：
1. **インデックスのパフォーマンス管理**: インデックスが大きくなると、パフォーマンスが低下する可能性があります。Rolloverを使ってパフォーマンス低下を防ぐことができます。
2. **データの分離**: 古いデータと新しいデータを分けることで、検索パフォーマンスと管理の効率を向上させます。
3. **自動化**: 手動でインデックスを管理する必要がなく、自動的にインデックスを作成して管理できます。

### **RolloverとAliasの関連性**

Rolloverは通常、**エイリアス（alias)** と一緒に使用されます。**Alias**は、Rolloverによって作成された複数のインデックスを1つの名前でまとめ、データを書き込むインデックスを指定するために使用されます。通常、Rolloverされたインデックスは読み取り専用になり、新しく作成されたインデックスが**書き込み可能なインデックス（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`エイリアスが新しいインデックスを指すように設定されます。

### RolloverとAlias設定の例

#### 1. **最初のインデックスとAliasの作成**:

```bash
PUT /logs-000001
{
  "aliases": {
    "logs": {
      "is_write_index": true  // 現在このインデックスにのみデータを書き込む
    }
  }
}
```

#### 2. **Rollover条件設定**:

```bash
POST /logs/_rollover
{
  "conditions": {
    "max_age": "7d",         // 7日経過後にRollover
    "max_docs": 1000,        // ドキュメント数が1000件を超えた場合にRollover
    "max_size": "5gb"        // インデックスサイズが5GBを超えた場合にRollover
  }
}
```

#### 3. **新しいインデックスとAliasの自動切り替え**:
Rollover条件が満たされると、OpenSearchは自動的に新しいインデックス(`logs-000002`)を作成し、`logs`エイリアスを新しいインデックスに接続します。以前のインデックス(`logs-000001`)は読み取り専用となり、新しいインデックス(`logs-000002`)が書き込み可能なインデックスとして設定されます。

### RolloverとAliasの関係まとめ

| **項目**            | **説明**                                                                                      |
|---------------------|-----------------------------------------------------------------------------------------------|
| **Alias**           | 複数のインデックスを1つの論理名でまとめる機能。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. **Rollover発生**: `logs`aliasが指すインデックスの条件（7日経過、ドキュメント数1000件超過、またはサイズ5GB超過）が満たされた場合、新しいインデックス(`logs-000002`)を作成し、`logs`aliasは新しいインデックスを指すように切り替え。
3. **継続的な管理**: 繰り返し新しいインデックスを作成し、aliasを更新しながらインデックスを自動管理。

---

### 4. OpenSearchの**インデックス作成**方式

**インデックス作成**とは、データをOpenSearchに保存する際に、データを**検索可能な形式に変換**するプロセスです。OpenSearchは、各ドキュメントを保存する際、そのフィールドを解析し、**逆インデックス（inverted index）**という形式で保存します。逆インデックスは、通常、単語とドキュメントの関係を効率的に見つけるためのデータ構造です。

#### インデックス作成プロセス:

1. **ドキュメントの保存**: OpenSearchに新しいドキュメントが保存されると、そのドキュメントは**JSON形式**で表現されます。このドキュメントは、フィールドとフィールド値のペアで構成されます。

2. **フィールドの解析**: 各フィールドはインデックス作成が必要かどうかに応じて処理されます。基本的にテキストデータは、分析器を通じて解析されます。

3. **逆インデックスの作成**: テキストフィールドを解析した結果（トークン、単語など）を**逆インデックス**に保存します。逆インデックスは**検索時**に使用され、単語とその単語が含まれるドキュメント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の例:
```json
{
  "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がどのようにテキストデータを処理するかによって、データがどのように検索されるかが決まります。
- **検索プロセスでのAnalyzerの役割**: 検索時にも**Analyzer**は検索クエリを解析し、同じ方法でトークン化して、インデックス作成されたデータと比較し、検索結果を返します。


---


こちらは、OpenSearchのText Analysisに関する要素の日本語訳です。

---

### 7. OpenSearchのText Analysis要素のまとめ

| **分類**           | **説明**                                                                                           | **種類と説明**                                                                                                                                                                  |
|--------------------|----------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Analyzers**       | テキストをトークン化し、フィルタリングするプロセスを定義します。                                       | - **standard**: 基本の分析器。一般的なテキストのトークン化を行う。<br>- **simple**: アルファベット以外の文字を基準にテキストをトークン化。<br>- **whitespace**: 空白を基準にテキストをトークン化。         |
|                    |                                                                                                    | - **stop**: ストップワード（無視される単語）を除去する分析器。<br>- **keyword**: テキスト全体を1つのトークンとして処理。<br>- **custom**: ユーザー定義の分析器。tokenizerとtoken filterを組み合わせて使用。              |
| **Tokenizers**      | テキストをトークンに分割する処理を行います。                                                         | - **standard**: 一般的なテキストを単語単位で分割。<br>- **whitespace**: 空白文字を基準に分割。<br>- **letter**: アルファベット文字を基準にトークン化。                     |
|                    |                                                                                                    | - **ngram**: n-グラム単位でテキストを分割。<br>- **edge_ngram**: 文字列の先頭からn-グラム単位で分割。<br>- **pattern**: 正規表現を使ってトークン化。                             |
| **Token Filters**   | トークン化されたテキストに追加処理を行い、変換またはフィルタリングを行います。                          | - **lowercase**: すべての文字を小文字に変換。<br>- **stop**: ストップワードを除去。<br>- **porter_stem**: 単語を語幹（stem）に変換（ステミング）。                                                |
|                    |                                                                                                    | - **asciifolding**: 非ASCII文字を似たASCII文字に変換。<br>- **synonym**: 同義語を処理し、同義語検索を可能に。<br>- **shingle**: 複数のトークンを組み合わせて新しいトークンを生成。 |
| **Normalizers**     | 主に**keyword**フィールドで使用され、フィールドを比較する前に文字列を正規化します。                     | - **lowercase**: すべての文字を小文字に変換。<br>- **asciifolding**: 非ASCII文字を似たASCII文字に変換。<br>- **custom**: ユーザー定義のフィルターを適用可能。                   |

### 各要素の説明：

1. **Analyzers（分析器）**: テキストをどのように処理するかを決定する**分析器**で、テキストをトークン化し、フィルタリングする全体のプロセスを定義します。OpenSearchはデフォルトの分析器を提供しており、ユーザーが**カスタム分析器**を定義することも可能です。

2. **Tokenizers（トークナイザー）**: テキストを**トークン（単語）**に分割する役割を持ちます。例えば、`standard tokenizer`は単語単位でテキストを分割し、`ngram tokenizer`はn文字の単位で分割するなど、さまざまな方法でテキストをトークン化することができます。

3. **Token Filters（トークンフィルター）**: トークン化されたテキストに追加の変換を適用するフィルターです。例えば、**lowercaseフィルター**はすべての文字を小文字に変換し、**synonymフィルター**は同義語を追加することで、より柔軟な検索を可能にします。

4. **Normalizers（ノーマライザー）**: 主に**keywordフィールド**で使用され、テキストフィールドを保存する前に文字列を正規化する処理を行います。通常は、小文字変換や非ASCII文字の変換といったシンプルな操作を行い、検索時の一貫性を保ちます。