はじめに
こんにちは。SREグループの佐々木です。普段はオンプレの仮想基盤やクラウド上のコンテナ環境の運用、サービスの品質向上に向けたSREを行っています。
2月14日に開催された「Developers Summit 2025」にElasticsearch株式会社さんと一緒に登壇し、ぐるなびにおけるElasticsearchの活用事例について発表を行いました。
Developers Summit(以降、デブサミ)は、日本最大級のソフトウェア開発者のためのカンファレンスです。ここでは、最新の技術情報や開発手法に関する講演、ワークショップ、パネルディスカッションなどが行われます。今回は2020年までのデブサミ会場としておなじみの、東京・目黒区のホテル雅叙園東京での開催となりました。
今回はセッションで使用したスライドの内容に基づき、セッション中にお伝えしきれなかった情報も含めて紹介させていただきます。
ログ分析とアラートシステムの導入による運用方法の変革
背景
ぐるなびでは、オンプレやクラウド上のログをElasticsearchに集約して管理しています。 それぞれのログはLogstashを通してElasticsearchに送信され、開発者はKibanaを利用しログを確認することができます。 この環境下においてぐるなびではどのように利用することでElasticsearchを活用できているかを発表しました。

Elasticsearchを活用したアクセスログ分析
ぐるなびでは飲食店検索などのWebサービスを提供しており、想定以上のアクセスを受けることで障害につながることがあります。 アクセス集中の主な要因としては以下のようなものがあげられます。
- 悪意のある攻撃
- 外的要因によるアクセス集中
- Botによるアクセス
このようなアクセス集中時、迅速な対応を行うために、どのようなアクセスか見極める必要があります。ログ連携されていないサーバの場合、直接サーバにログインの上ログの解析を行う必要があり、以下のような課題がありました。
- ログ解析用のコマンドの調整が必要
- 全体の分析を行うには複数サーバでのログ解析が必要
- 過去のトレンドとの比較が困難
- 数字のみのため直感的にわかりずらい
これらの課題をElasticsearchを活用することで解決しています。
Elasticsearchを導入するメリットとしては以下があげられます。
- 効率的なログ分析
- 視覚的なデータ理解
- 共有と連携の容易さ
ぐるなびではアクセス分析のため、以下のような形でグラフ化し視覚的な理解を図っています。


これらの情報をダッシュボードで可視化し、リアルタイムに状況を把握できるようにしました。

Kibanaを利用したログアラーティング
Elasticsearchに連携されたログを元に、Kibana Rulesを利用してアラートの設定を行っています。 Kibana Rulesにてどのように行っているかを解説します。
Kibana Rulesは以下を設定することでアラーティングを行うことができます。
- 対象とするログの条件
- 条件と合致するログ件数の閾値
- トリガーされたときに実行されるアクション
設定は柔軟に行うことができ、例えば以下のような設定ができます。
- 正規表現を用いてホスト名を指定
- ワイルドカードを用いてエラーコードを指定
- テスト環境を指定
アラートの通知先としては、Slack、Teams、PagerDutyなどに対応しており、Webhookも利用可能です。
これによりアラートの仕組みを導入することができました。
また、メンテナンスを行う際に特定のアラートについては抑止したいのでアラートの抑止を行うための仕組みも併せて導入しました。
アラートの抑止についてはKibanaのAPIを利用してスクリプトを実行する形で実装しました。

スクリプトを実行することで特定のアラートを除外するためのフィルターを追加しアラートの抑止を行っています。

この仕組みを利用することでメンテナンス時にコマンドを叩くだけで特定のアラートの抑止を行うことができるようになり運用を効率的に行うことを可能にしました。
この仕組みを導入するにあたって一番苦労した点としてはAPIキーの設定となります。 デブサミの発表時にはあまり掘り下げて話すことが出来なかったのでこちらでもう少し詳しく解説します。
最初このスクリプトを実行した際、Kibana Rulesの更新自体は上手くいったにもかかわらず、それが正常に動作しなくなるという事象が発生しました。
原因としてはKibanaはルール作成および更新のリクエスト元が有する権限のスナップショットを内部的なAPIキーとして保管し、ルールはその権限で実行されるという仕様によるものでした。 つまり、Kibana Rulesは作成や更新を行ったユーザの権限にて動作するというもので、作成時は管理者権限を持つユーザで作成を行ったため正常に動作していたのですが、更新に利用するために作成したAPIキーにはKibana Rulesを更新する権限のみで実行に必要な権限が足りていなかったため動作しなくなるというものでした。
APIキーに対して実行に必要な権限を付けてあげることで正常に動作するようになりました。
まとめ
Elasticsearchを自社システムに上手く組み込むことで以下のことが実現できました。
- アクセスログ分析
リアルタイムにアクセス状況を確認でき、グラフを用いて視覚的なデータ理解が可能になりました。 - ログアラーティング
Kibanaを用いたログアラートを導入し、APIを用いた監視抑止の自動化を作りこむなどして、効果的なログ監視が可能になりました。
最後に
効率的なログ分析やリアルタイムな監視を行うことができるログ基盤を構築することでサービスの品質向上につながったと考えています。 今後もこの基盤を最大限に活用し、サービスの品質向上に貢献していきたいと考えています。
最後までお読みいただきありがとうございました。
