ELKスタック(Elasticsearch · Logstash · Kibana)

1. 概要

A. 定義

大容量のログ・イベントデータを収集(Logstash/Beats)→インデックス化・検索(Elasticsearch)→可視化(Kibana)するオープンソースのログ分析スタックであり、軽量コレクタBeatsを含めてElastic Stackと呼ばれる。

ELKは3つのオープンソースの頭文字を取った名称であるが、本質は「非構造化ログを検索可能な構造に変換し、リアルタイムに照会・分析する」パイプラインである。リレーショナルDBが構造化データを行・列で扱うのとは異なり、ログは形式がまちまちで毎秒数万件ずつ押し寄せるため、従来のRDBMSでは保存・検索が非効率である。ELKはこの問題を転置インデックス(Inverted Index)ベースの検索エンジンで解決する。

B. 登場背景および必要性

MSA・クラウドネイティブ環境では、1つのリクエストが数十のサービスを経由するため、ログが各サーバ・コンテナに散在する。障害が起きると、どのサーバのログを見るべきかさえ把握しにくい。そのため、ログを1か所に集め(中央集約)、サービス・時間・相関関係で検索できるオブザーバビリティ(Observability)基盤が必要となった。ELKは商用APM・SIEMに比べて導入コストが低く、インデックス化・検索・可視化を1つのスタックで提供するため、ログ統合・リアルタイム分析の事実上の標準となった。

2. 構成要素

flowchart LR
  B[Beats<br/>軽量収集エージェント] --> L[Logstash<br/>収集・パース・変換]
  L --> E[Elasticsearch<br/>インデックス・検索・集計]
  E --> K[Kibana<br/>可視化・ダッシュボード]
  B -.直接投入.-> E

各構成要素はパイプラインの1段階を担い、役割が分離されているため、必要に応じて選択的に組み合わせる。例えば変換が不要であれば、BeatsからElasticsearchへ直接投入してLogstashを省略できる。

Beats(収集): 各サーバにインストールされる軽量エージェントで、Filebeat(ログファイル)・Metricbeat(メトリクス)・Packetbeat(ネットワーク)のように目的別に分かれている。リソース占有が小さいため、数千台のサーバに負担なく展開できる。
Logstash(変換): input→filter→outputのパイプラインでログをパースする。核心はGrokフィルタであり、192.168.0.1 - GET /api 200のような非構造化文字列をclient_ip、method、statusフィールドに構造化する。重い代わりに強力な変換が可能である。
Elasticsearch(中核): Luceneベースの分散検索エンジンであり、転置インデックスで全文検索を、集計(Aggregation)で統計をリアルタイムに提供する。ELKの心臓部である。
Kibana(可視化): 検索・ダッシュボード・アラートのUI。KQLクエリでログを探索し、時系列・ヒストグラム・地図などで可視化する。

構成	役割	特徴
Beats	軽量収集	サーバごとに展開、低負荷
Logstash	パース・変換・投入	Grokなど強力なフィルタ
Elasticsearch	インデックス・検索・集計	転置インデックス・分散・リアルタイム
Kibana	可視化・アラート	ダッシュボード・探索UI

3. 主要技術原理

ELKの性能は、Elasticsearchの2つの設計に由来する。第一に、転置インデックスは「文書→単語」ではなく、「単語→その単語を含む文書のリスト」へとインデックスを反転させておく。そのため「errorを含むログ」を探す際、全体を走査せずにerror項目が指す文書だけを即座に返す。これが、数億件のログでもミリ秒単位の検索が可能な理由である。

第二に、分散・シャーディングである。インデックスを複数のシャード(shard)に分割してノードに分散し、各シャードをレプリカ(replica)として複製しておく。データが増えればノードを追加し(水平スケーリング)、ノードがダウンしてもレプリカによってサービスが維持される(高可用性)。ただし、シャードが多すぎるとかえってオーバーヘッドが大きくなるため、シャード数の設計が運用の鍵となる。

技術	原理	効果
転置インデックス	単語→文書のマッピング	高速な全文検索
分散・シャーディング	インデックスの分割・複製	水平スケーリング・HA
集計	インデックス上での統計演算	リアルタイムダッシュボード

4. 活用分野

ログ分析が基本であるが、「検索+集計+可視化」という特性のおかげで活用の幅は広い。SIEM(セキュリティ情報・イベント管理)では、ファイアウォール・認証ログを集めて異常ログイン・攻撃パターンをリアルタイムに検知し、オブザーバビリティ(APM)では応答遅延・エラー率を追跡する。例えば、特定APIの5xxエラーが急増すると、Kibanaダッシュボード上で即座にスパイクとして現れ、アラート(Watcher)によって担当者に通知される。

分野	活用例
ログ分析	アプリ・システムログの統合、障害原因の追跡
セキュリティ(SIEM)	異常検知・脅威ハンティング・コンプライアンス
オブザーバビリティ(APM)	遅延・エラー率のモニタリング、トレーシング

5. 考慮事項および示唆

コスト・ライフサイクル管理: ログは際限なく蓄積されるため、ILM(Index Lifecycle Management)で古いインデックスをHot→Warm→Cold→削除へと自動的に階層化し、保存コストを統制しなければならない。
ライセンス問題: ElasticがライセンスをSSPLに変更したことで、AWS主導のオープンソースフォークであるOpenSearchが登場した。ベンダーロックイン・コストの観点から代替の検討が必要である。
標準との連携: 近年はOpenTelemetry標準でログ・メトリクス・トレースを統合収集する流れにあり、ELKもOTel収集パイプラインと連携する方向へ進化している。
運用負担: クラスタのチューニング(シャード・ヒープ・マッピング)が難しいため、マネージドサービス(Elastic Cloud)の活用も代替案である。

一言まとめ: ELKスタックは*Beats/Logstash(収集・変換)→Elasticsearch(転置インデックス・分散検索)→Kibana(可視化)*で大容量の非構造化ログをリアルタイムに検索・分析するオープンソーススタックであり、ログ分析・SIEM・オブザーバビリティに使われ、ILM・ライセンス(OpenSearch)・OpenTelemetry連携が運用上の課題である。