1. ILM (Index Lifecycle Management)
ILM(インデックスライフサイクル管理)は、OpenSearchでインデックスの作成から削除までデータのライフサイクルを管理するポリシーです。データを保存するインデックスは時間の経過とともに、頻繁にアクセスされるデータからほとんど使用されなくなるデータへと変化します。こうしたデータを効率的に管理するため、ILMポリシーを設定することができます。
ILMの主要なフェーズ:
- Hotフェーズ: 頻繁にクエリされ、リアルタイムでインデックス化されるデータを保存する段階。
- Warmフェーズ: 頻繁に使用されないが、まだデータを参照する必要がある場合に使用する段階。セグメントマージなどの最適化作業によりストレージスペースを節約可能。
- Coldフェーズ: ほとんど使用されない古いデータを保存する段階で、低コストのストレージでデータを保持し、パフォーマンスよりもコスト効率を重視。
- Deleteフェーズ: データが不要になったときに自動的にインデックスを削除する段階。
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フェーズ、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の例:
{
"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の連携
-
Index Templateは、インデックスを作成する際にILMポリシーを自動適用して、データが適切なライフサイクルをたどるようにします。
- 例えば、ログデータを収集するインデックスは
logs-*
パターンで作成され、ILMポリシーに基づいてhot、warm、coldストレージに移行し、一定期間後に削除されます。
- 例えば、ログデータを収集するインデックスは
-
ILMはデータをcold storageに移行することで、データ保管コストを削減し、必要に応じてデータを削除する役割を果たします。
-
Cold Storageは頻繁にアクセスされないデータを保存し、性能よりもコスト最適化を重視し、ILMポリシーを通じて効率的に管理されます。
こちらは、OpenSearchのRollover機能に関する技術情報の日本語訳です。
3-1. OpenSearchのRollover機能
Rolloverは、OpenSearchでインデックス管理を自動化する重要な機能です。主に、特定の条件(ドキュメント数、インデックスサイズ、インデックスの年齢など)が満たされたときに、新しいインデックスを作成し、そのインデックスにデータを書き込む方法です。これにより、インデックスが大きくなりすぎたり、古いデータを含む場合でも、別の新しいインデックスにデータを移行して管理できます。
Rolloverが必要な理由:
- インデックスのパフォーマンス管理: インデックスが大きくなると、パフォーマンスが低下する可能性があります。Rolloverを使ってパフォーマンス低下を防ぐことができます。
- データの分離: 古いデータと新しいデータを分けることで、検索パフォーマンスと管理の効率を向上させます。
- 自動化: 手動でインデックスを管理する必要がなく、自動的にインデックスを作成して管理できます。
RolloverとAliasの関連性
Rolloverは通常、エイリアス(alias) と一緒に使用されます。Aliasは、Rolloverによって作成された複数のインデックスを1つの名前でまとめ、データを書き込むインデックスを指定するために使用されます。通常、Rolloverされたインデックスは読み取り専用になり、新しく作成されたインデックスが**書き込み可能なインデックス(write index)**として設定されます。
Rolloverの主要な条件
Rolloverは以下の条件に基づいて動作します。
-
max_age
: インデックスの年齢が指定された期間を超えた場合。 -
max_docs
: インデックスに保存されたドキュメント数が指定された数を超えた場合。 -
max_size
: インデックスのサイズが指定された容量を超えた場合。
RolloverとAliasの使用例
AliasとRollover設定手順:
-
Alias設定:
logs
というaliasを作成し、logs-000001
という最初のインデックスを作成します。 -
Rollover設定: 一定の条件が満たされると、自動的に新しいインデックス(
logs-000002
)が作成され、logs
エイリアスが新しいインデックスを指すように設定されます。
RolloverとAlias設定の例
1. 最初のインデックスとAliasの作成:
PUT /logs-000001
{
"aliases": {
"logs": {
"is_write_index": true // 現在このインデックスにのみデータを書き込む
}
}
}
2. Rollover条件設定:
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を使って継続的にデータを書き込み、検索できる。 |
例のフロー:
-
初期設定:
logs-000001
インデックスを作成し、logs
というaliasにis_write_index
をtrue
として設定。 -
Rollover発生:
logs
aliasが指すインデックスの条件(7日経過、ドキュメント数1000件超過、またはサイズ5GB超過)が満たされた場合、新しいインデックス(logs-000002
)を作成し、logs
aliasは新しいインデックスを指すように切り替え。 - 継続的な管理: 繰り返し新しいインデックスを作成し、aliasを更新しながらインデックスを自動管理。
4. OpenSearchのインデックス作成方式
インデックス作成とは、データをOpenSearchに保存する際に、データを検索可能な形式に変換するプロセスです。OpenSearchは、各ドキュメントを保存する際、そのフィールドを解析し、**逆インデックス(inverted index)**という形式で保存します。逆インデックスは、通常、単語とドキュメントの関係を効率的に見つけるためのデータ構造です。
インデックス作成プロセス:
-
ドキュメントの保存: OpenSearchに新しいドキュメントが保存されると、そのドキュメントはJSON形式で表現されます。このドキュメントは、フィールドとフィールド値のペアで構成されます。
-
フィールドの解析: 各フィールドはインデックス作成が必要かどうかに応じて処理されます。基本的にテキストデータは、分析器を通じて解析されます。
-
逆インデックスの作成: テキストフィールドを解析した結果(トークン、単語など)を逆インデックスに保存します。逆インデックスは検索時に使用され、単語とその単語が含まれるドキュメントIDがマッピングされます。これにより、単語を含むドキュメントを素早く見つけることができます。
OpenSearchインデックス作成の特徴:
- リアルタイムインデックス作成: OpenSearchはデータをリアルタイムでインデックス作成し、即座に検索可能にします。
- 逆インデックス構造: 各単語をドキュメントとマッピングすることで、検索性能を最大化します。
- 柔軟なスキーマ: インデックス作成時にフィールドの型を自動検出するか、事前に設定されたマッピングを使用してフィールドの型を指定できます。
5. Analyzer(分析器) の役割
Analyzer(分析器)は、テキストデータを解析し、処理するツールです。OpenSearchは、テキストデータを解析して検索可能な形式に変換します。この過程で、分析器はテキストデータをトークン化し、フィルタリングする作業を行います。
Analyzerの役割:
- トークン化(Tokenization):
- 分析器はテキストデータを**単語(トークン)**に分割します。たとえば、「The quick brown fox」というテキストがあれば、分析器はこれを「[the, quick, brown, fox]」に分割することができます。
-
小文字変換:
- 分析器は大文字を小文字に変換し、検索時に大文字小文字を区別せず処理できるようにします。たとえば、「Quick」は「quick」に変換されます。
-
ストップワード(Stop Words)削除:
- 分析器は、検索において意味を持たないストップワードを削除することができます。たとえば、「the」、「and」、「is」といった単語は、一般的に検索の重要性が低いため削除されます。
-
形態素解析:
- 分析器は言語に応じて形態素解析を行い、単語のさまざまな形を処理します。たとえば、「running」は「run」に、「cars」は「car」に変換されることがあります。
-
カスタマイズ可能:
- OpenSearchでは、デフォルトの分析器を使用することもできますが、必要に応じてカスタム分析器を作成して使用することもできます。これにより、特定のトークン化方法やフィルタリングルールを設定できます。
Analyzerの構成要素:
-
Char Filter:
- テキストデータをトークン化する前に、特定の文字を削除したり変換したりするフィルタです。たとえば、HTMLタグを削除するフィルタなどが含まれます。
-
Tokenizer:
- 分析器の核心的な役割を果たすトークン化プロセスです。テキストを単語(トークン)に分割します。OpenSearchはさまざまなトークナイザーを提供しており、テキストの構造に応じて適切なものを選択できます。
-
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がどのようにテキストデータを処理するかによって、データがどのように検索されるかが決まります。
- 検索プロセスでのAnalyzerの役割: 検索時にもAnalyzerは検索クエリを解析し、同じ方法でトークン化して、インデックス作成されたデータと比較し、検索結果を返します。
こちらは、OpenSearchのText Analysisに関する要素の日本語訳です。
7. OpenSearchのText Analysis要素のまとめ
分類 | 説明 | 種類と説明 |
---|---|---|
Analyzers | テキストをトークン化し、フィルタリングするプロセスを定義します。 | - standard: 基本の分析器。一般的なテキストのトークン化を行う。 - simple: アルファベット以外の文字を基準にテキストをトークン化。 - whitespace: 空白を基準にテキストをトークン化。 |
- stop: ストップワード(無視される単語)を除去する分析器。 - keyword: テキスト全体を1つのトークンとして処理。 - custom: ユーザー定義の分析器。tokenizerとtoken filterを組み合わせて使用。 |
||
Tokenizers | テキストをトークンに分割する処理を行います。 | - standard: 一般的なテキストを単語単位で分割。 - whitespace: 空白文字を基準に分割。 - letter: アルファベット文字を基準にトークン化。 |
- ngram: n-グラム単位でテキストを分割。 - edge_ngram: 文字列の先頭からn-グラム単位で分割。 - pattern: 正規表現を使ってトークン化。 |
||
Token Filters | トークン化されたテキストに追加処理を行い、変換またはフィルタリングを行います。 | - lowercase: すべての文字を小文字に変換。 - stop: ストップワードを除去。 - porter_stem: 単語を語幹(stem)に変換(ステミング)。 |
- asciifolding: 非ASCII文字を似たASCII文字に変換。 - synonym: 同義語を処理し、同義語検索を可能に。 - shingle: 複数のトークンを組み合わせて新しいトークンを生成。 |
||
Normalizers | 主にkeywordフィールドで使用され、フィールドを比較する前に文字列を正規化します。 | - lowercase: すべての文字を小文字に変換。 - asciifolding: 非ASCII文字を似たASCII文字に変換。 - custom: ユーザー定義のフィルターを適用可能。 |
各要素の説明:
-
Analyzers(分析器): テキストをどのように処理するかを決定する分析器で、テキストをトークン化し、フィルタリングする全体のプロセスを定義します。OpenSearchはデフォルトの分析器を提供しており、ユーザーがカスタム分析器を定義することも可能です。
-
Tokenizers(トークナイザー): テキストを**トークン(単語)**に分割する役割を持ちます。例えば、
standard tokenizer
は単語単位でテキストを分割し、ngram tokenizer
はn文字の単位で分割するなど、さまざまな方法でテキストをトークン化することができます。 -
Token Filters(トークンフィルター): トークン化されたテキストに追加の変換を適用するフィルターです。例えば、lowercaseフィルターはすべての文字を小文字に変換し、synonymフィルターは同義語を追加することで、より柔軟な検索を可能にします。
-
Normalizers(ノーマライザー): 主にkeywordフィールドで使用され、テキストフィールドを保存する前に文字列を正規化する処理を行います。通常は、小文字変換や非ASCII文字の変換といったシンプルな操作を行い、検索時の一貫性を保ちます。