Elasticsearch 7.11 でGAとなった Searchable Snapshot の紹介です。 Async Search についても少し言及します。

1. Searchable Snapshot でコスト削減
Acroquest Technology株式会社
Elastic Certified Engineer / Analyst
樋口 慎

2. 樋口 慎 (@shin0higuchi)
Acroquest Technology
業務
執筆
• データ分析（時系列データ・自然言語）
• 検索システム構築／コンサルティング
• Elasticsearch NEXT STEP
• Elasticsearch NEXT STEP 2
資格
• Elastic Certified Engineer
• Elastic Certified Analyst

3. 前提のお話
1. Elasticsearchのデータ構造
① インデックスは、内部的に「シャード」という単位で分割保持される。
② 各シャードは通常、レプリカを保持することで可用性を保っている。
node_1
Primary1
node_2
Primary3
node_3
Primary2
Replica1
Replica3
Replica2
Elasticsearchクラスタ
Replica Shardは、
Primary Shardとは別の
ノードに配置される

4. Searchable Snapshotとは？
1. クラウドストレージなどに保存しておいた Snapshot を
Elasticsearchにマウントし、検索可能にする機能。
2. 想定されるユースケース
① 検索リクエストが少ないインデックスのReplica代わりに利用する。
② 過去データのアーカイブとして、必要な時のみElasticsearchにマウント。
node_1
Primary1
node_2
Primary3
node_3
Primary2
クラウドストレージ等に
保存されたSnapshot
クラウドストレージに
Snapshotがあるため
レプリカが不要※
[※] 検索リクエストが多い場合は、スループットを向上させる目的でレプリカを保持する場合があることに注意。

5. 1. たとえば、時系列データが "syslog-yyyymmdd" のように、
日毎のインデックスに保持される場合…
時系列データのライフサイクル例
No. フェーズ 保持するログ期間 特徴
1 Hot 当日のログのみ 書込み・検索に耐えうるHot Nodeに配置する。
（充分なRAM・CPU・SSD推奨）
2 Warm ~1ヶ月前のログまで
(Hot除く)
書込みが発生しないので、Hot Nodeよりも
一般に要求スペックが低いWarm Nodeに配置する。
検索速度要件が緩いならHDD利用も選択肢のひとつ。
3 Cold※ 1ヶ月以上過去のログ Searchable Snapshot を利用する。
レプリカを保持しないため、ストレージを節約できる。
※ 現在開発中のFrozen Tierでは、メタデータのみをElasticsearchに保持し、さらなるストレージ節約が可能となる見込み

6. 結局何が嬉しいのか？
1. ストレージコストの削減
① レプリカシャードを保持しない
② 過去のアーカイブデータはElasticsearchから退避させることができる
2. ヒープ利用率の低減
① レプリカシャードを保持しない

7. デモ
1. 手動でAPIから実行する。
① Snapshot取得
② Mount snapshot APIの実行
③ 検索してみる
2. ILM (Index Lifecycle Management)で自動化する。
3. Async Search

8. Snapshot取得
PUT _snapshot/gcs_repository
{
"type": "gcs",
"settings": {
"bucket": "my_bucket",
"client": "my_client"
}
}
GCSの場合
①リポジトリ作成
②Snapshot取得

9. 取得したSnapshotを確認

10. Mount Snapshot API
• 対象のインデックスが既に open になっている場合は、renamed_index で別名にする。
→ 元インデックスを削除してからマウントする方が良いかも
• "index_settings"や"ignored_index_settings"で、インデックス設定を変更可能。

11. ILM設定
1. Kibanaから設定可能

12. Async Search
1. Ver. 7.7 で実装された、非同期検索機能。
時間のかかる検索をバックグラウンドで走らせておき、
あとで結果を取得することができる。
2. 過去の大量データを集計するなどの重い処理に適しており、
Searchable Snapshotと併せて利用するケースが想定できる。

13. Async Search
POST <index名>/_async_search
※bodyには、あえて重いクエリを記述している
クエリが実行中の場合は、一旦 id を返す

14. Async Search
GET /_async_search/<先ほど受け取ったid>
先ほどとは違い、結果が取得できている

15. さいごに
1. Searchable Snapshotは、
ログ分析における Index Life Cycle の定石となりそう。
2. 今後の Frozen 対応でさらにリソース効率が向上する見込み。

16. ご清聴ありがとうございました。
Evolve the Earth with Emotion of Technology