Self-Hosted Open Source Infrastructure

OpenSearch Shard Optimization: Managing Petabyte-Scale Log Indexes Without Cluster Performance Degradation

著者 Kinetikatech Operations Team · 更新日 2026-07-20

OpenSearch clusters degrade when shard count grows unchecked. Too many small shards waste memory and CPU; too few large shards create hotspots. At petabyte scale, shard strategy determines whether the cluster survives. This guide optimizes shards for log workloads.

要点

Size shards deliberately. Target 10-50 GB per shard; smaller shards waste overhead, larger ones slow recovery.
Use time-based indices. Daily or weekly indices match log ingestion patterns and simplify retention.
Limit shard count. Keep total shards under a few thousand per node to avoid memory pressure.
Configure ILM policies. Automate rollover, shrink, and delete to control shard growth.
Use forcemerge on old indices. Merging segments reduces memory and improves query speed.
Monitor shard allocation. Uneven distribution creates hot nodes; use allocation awareness.
Tune refresh intervals. Longer intervals reduce indexing overhead for high-throughput logs.
Plan capacity. Calculate shard count from data volume and retention before deploying.

Architecture

Logs flow into time-based indices, each with a configured number of primary shards. ILM policies rollover when size or age thresholds are met, shrink old indices, and delete expired data. Shard allocation balances across nodes, and forcemerge compacts segments.

Production configuration

ILM policy for log indices json

{
  "policy": {
    "description": "Log retention policy",
    "default_state": "hot",
    "states": [
      {"name": "hot", "actions": [{"rollover": {"max_size": "50gb", "max_age": "1d"}}], "transitions": [{"state_name": "warm", "conditions": {"min_age": "1d"}}]},
      {"name": "warm", "actions": [{"forcemerge": {"max_num_segments": 1}}, {"shrink": {"number_of_shards": 1}}], "transitions": [{"state_name": "delete", "conditions": {"min_age": "30d"}}]},
      {"name": "delete", "actions": [{"delete": {}}]}
    ]
  }
}

Create index template bash

curl -X PUT 'localhost:9200/_index_template/logs' -H 'Content-Type: application/json' -d '{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "30s"
    }
  }
}'

Monitor shard health bash

curl -s 'localhost:9200/_cat/shards?v&h=index,shard,prirep,state,docs,store' | head -20
curl -s 'localhost:9200/_cluster/health?pretty'
curl -s 'localhost:9200/_cat/nodes?v&h=name,shards'

Edge cases from production

Rollover requires an alias; ensure the write alias points to the current index.
Shrinking changes shard count; queries must handle the new topology.
Forcemerge on large indices is I/O intensive; schedule during low traffic.
Replica shards double storage; balance cost against availability needs.

よくある質問

How many shards per node?

Keep total shards under a few thousand per node; memory is the limiting factor.

Should I use daily or weekly indices?

Daily for high-volume logs, weekly for lower volume; match to your data rate.

What happens if I have too many shards?

Memory pressure, slow queries, and cluster instability.

Can I change shard count after creation?

No, you must reindex; plan shard count before going live.

How do I reduce shard count?

Use shrink or reindex to consolidate into fewer shards.

self-hosted open source infrastructure に対するKinetikatechの支援

self-hosted open source infrastructure の専門家になる必要はありません：Running sovereign collaboration, storage, and identity stacks on hardware you control. それがまさにサーバー管理とWebサイト保守が存在する理由です。セットアップ、強化、監視、そして昼夜を問わず駆けつける人間のサポート。

エンジニアに相談する