Elasticsearchの3つの強み
ぐるなびの導入事例に入る前にElasticsearchについて触れておこう。Elasticsearchは、もともとオープンソースの分散型検索エンジンで、大規模データに対して高速かつ柔軟に検索できることを得意としている。
現在Elasticsearchはプラットフォームとなり、この上にすぐに使える2つのソリューション「Elastic Observability（ログ分析）」「Elastic Security（セキュリティ分析）」と、自由に構築するためのソリューション「Elastic Search（検索AI）」がある。
今回のテーマはオブザーバビリティ（可観測性）だ。さまざまなログからシステムの状態を分かるようにすることの重要性が年々高まっている。Elasticsearch株式会社 ソリューションズアーキテクチャ プリンシパル ソリューションアーキテクト 杉本知洋氏は「ログの流れ、取り込みから気づきまで、全部できるのがElasticsearchです」と話す。ElasticsearchではAI活用も特徴的だが、今回はぐるなびにおける活用事例にフォーカスしよう。
ぐるなび（現：楽天ぐるなび）の開設は1996年6月。飲食店の検索や予約ができるサイトでは老舗と言える。2025年1月時点で会員数は2745万人、総掲載店舗数は約42万店まで広がった。企業としては「食でつなぐ。人を満たす。」というPURPOSEのもと、さまざまな食に関連するサービスを展開している。2025年1月にはAIを活用した飲食店検索アプリ「UMAME!」をリリースした。AIが目的に応じて飲食店を提案してくれる。
今回のぐるなびにおける事例では、Elasticsearchを活用したアクセスログ分析とKibanaを利用したログアラーティングを解説する。なお、ぐるなびではオンプレミスとクラウドのハイブリッド環境で、それぞれのログはElastic Cloudに構築されたElasticsearchに集約されている。開発者はデータ視覚化・解析ツールKibanaを用いてログ分析を行う。
ぐるなびの運用課題と解決策
ぐるなびが主に運用で注視しているのは、アクセス集中による負荷上昇だ。これが高まるとサービスに影響を与える障害になりかねない。アクセス集中の原因はいくつかあり、悪意ある攻撃、ボットによるアクセス、（掲載している店舗がテレビで紹介されるなど）外的要因によるアクセス集中などがある。
同じサーバー負荷上昇だとしても、要因ごとに対応が異なる。悪意ある攻撃であればアクセスをブロックする。ボットの場合は全てブロックするわけにはいかないので、適切なアクセス制御で調整していく。外的要因の多くは一時的だが、長期的に続くならスケールアウトを検討する必要もある。
こうして要因ごとに対応が分かれるため、アクセス集中が発生したら、まずはどのようなアクセスか見極めるところから行う。例えば、単一IPからのアクセスか、どのようなユーザーエージェントからアクセスが来ているか、どの国からか、どのパスにアクセスが来ているかなどの情報から見極めていく。
これらの情報は異なるサーバーから出力されるログからなるため、もしログが連携や集約されていなければ都度サーバーにアクセスしてログ解析しなくてはならない。その場合、ログ解析用のコマンドを調整するとか、複数サーバーにわたるログを解析する必要がある。また過去のトレンドとの比較は難しく、ログの数字を見るだけでは傾向を把握しづらい。
こうした課題を解決するのがElasticsearchだ。現在のアクセス数推移に、先週や先々週の同じ時間帯の推移を重ねて見ることができる。またアクセス元の国で色分けした棒グラフで表示したり、アクセス元のユーザーエージェント（AndroidのChromeやiOSのSafariなど）の割合を円グラフで表示したりもできて、直感的に把握が可能だ。またフィルター機能を使えば、時間帯、サーバー、送信元IPアドレスを用いて正常なステータスは除外するなどして、着目すべきものだけを抽出することも可能だ。
これまで紹介したようなグラフをまとめたダッシュボードも作成できる。リアルタイムで、すぐに現在の傾向を把握することができる。
アクセスログ分析では、Elasticsearchを使うことで効率的なログ分析（コマンドを叩くことなくブラウザ上でリアルタイムにログ分析が可能）、視覚的なデータ理解（ダッシュボードでデータの傾向や異常値を一目で把握可能）、共有の容易さ（ダッシュボードのリンクを共有することで他チームメンバーとも簡単に共有や連携可能）といったメリットが得られる。
アラートログの可視化や複数の通知先設定
続いて、ぐるなびでは特定のログが出力された際にアラートを出したかったため、Elasticsearchで実現した。それまでオンプレでは、アプリケーションサーバーからsyslogをログ監視ツールswatchサーバーに送り、メールやSlackを通じてアラーティング（アラート発報）していた。
現在ではswatchではなく、ログをElasticsearchに送りアラーティングするような構成に変更した。ここで鍵となるのがKibana Rules。Elasticsearchに連携されたログをもとにアラートを設定できる。対象とするログの条件や、条件と合致するログ件数のしきい値、これらの条件を満たした時に実行されるアクションなどを設定することでアラーティングが可能となる。
単純なアラートの設定であれば管理画面上で記入できるが、やや複雑な条件であればクエリで設定することも可能だ。例えば正規表現を用いてホスト名を指定したり、ワイルドカードを用いてエラーコードを指定したりなどだ。アラート通知先はメール、Slack、Teams、PagerDuty、Webhook、ServiceNowなど、さまざまななかから選べる。
アラートの仕組みは導入できたものの、1つ課題があった。それはメンテナンスで稼働停止しているサーバーのアラートは抑止することだ。ぐるなびではアラート抑止のためのスクリプトを自動化しており、対象サーバーの監視をコマンドで停止できるようにしている。ここにKibana Rulesのアラートもスクリプトで抑止できるようにしたかった。
この監視停止の仕組みについては、Kibanaで提供されている設定変更を行えるAPIを使うことにした。まずKibana RulesのConfigファイルに監視除外用のフィルターを追加する。続いてそのConfigファイルを元にAPIを通じて、Kibana Rulesを変更する。なお特定のフィルターだけ追加することはできないため、ファイル丸ごと上書きする形となる。
佐々木氏は「APIキーの権限設定が複雑でなかなかうまくいかず、問い合わせをしながら実装しました。またConfigファイルの一部だけ変更できないため、差し替え用の設定ファイルを実行サーバー側で保持する必要がありました」と話す。
ログアラーティングを実装することで、アラートログをKibanaで確認できるようになり、リアルタイムで問題の特定が可能となった。佐々木氏は「これまでの古いアラートの仕組みをモダンな仕組みに切り替えることができてよかったです」と話す。また複数の通知方法を設定できるようになった。
今後Elasticsearchで実現したいこと
今後ぐるなびでは、ダッシュボードの拡張を予定している。佐々木氏は「活用できていない視覚化やグルーピング機能などを利用することで、より分かりやすいダッシュボードへと改善していきたいです」と話す。
また機械学習を用いることでアラートの自動化をより高度化していくことも計画している。AIOps機能を用いれば、ログデータ内の異常やパターン検出を自動化していくことが可能になる。さらにぐるなびではSREを進めているところなので、ElasticsearchのSLO機能からサービスのSLOを計測する予定だ。
最後に佐々木氏は「Elasticsearchを自社システムにうまく組み込むことで、アクセスログでは、リアルタイムなアクセス状況確認やグラフを用いた視覚的なデータ理解が可能になりました。またKibanaを用いたログアラーティングの仕組みを導入し、APIで監視抑止の自動化をすることで効果的なログ監視が可能となりました。これら2点により、ぐるなびのオブザーバビリティが向上したと考えています」と述べた。
