実運用の障害対応時間比較に見るFluentd＋Elasticsearch＋Kibanaのログ管理基盤の効果：実運用が分かる、OSSでログ管理入門（2）（1/2 ページ）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介します。
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する本連載「実運用が分かる、OSSでログ管理入門」。第1回では一般的なFluentd、Kibana、Elasticsearchを用いたログ管理基盤の概要、導入方法を紹介しました。
第2回では実案件を事例とし、ログ管理基盤の有用性を紹介します。なお、前回紹介した各ツールとバージョンは異なりますが、基本的な利用方法に大きな違いはありません。
ログ管理基盤導入対象システムの概要
実運用における事例を紹介する前に、今回ログ管理基盤を導入した弊社システムの規模や構成に関して簡単に説明します。
今回対象としたシステムは、さまざまな要件を実現するため、複数のパッケージ製品やOSS（オープンソースソフトウェア）を利用している大規模システムです。とりわけメインとなる業務処理は、アプリケーション開発で実現しており、これらは可用性を高めるために十数台のアプリケーションサーバで冗長構成を組んでいます。
弊社システムにおけるログ管理における課題
続いて、ログ管理基盤導入前まで、弊社システムで抱えていたログ管理に関する課題を紹介します。
肥大化したログの扱い
複数台あるアプリケーションサーバのうち幾つかは、ログ調査のためにトレースレベルでのログ出力が必須であったため、プレーンテキスト形式で1日に約6GBものログが出力されています。障害発生時、エラー発生箇所ならびに、その前後のログを取得するだけでも多くの時間を要していました。またログ調査自体にも危険性を伴います。
過去に、障害発生時にサーバ上で肥大化したログを展開（catコマンド実行）しようとした結果、OOMキラー（Out of Memory Killer）が働き、Javaプロセスが停止するといった事象が発生しました。普段Linuxの操作になじみのない担当者が実施したということもあるのですが、そもそも『システムを保守していく上で、6GBにも及ぶプレーンテキスト形式のログをどのように扱っていくか』という点に課題があると考えました。
サーバごとに分散したログの扱い
システム概要にも記載した通り、今回ログ管理基盤導入の対象としたアプリケーションサーバは冗長構成を組んでいます。障害発生時、Zabbix（サーバの監視ツール）によってエラーを検知したサーバや時刻は確認できますが、冗長構成を組んでいる別のサーバで同様のリスクがないか、また別のサーバが起因となっていないかなどの調査に時間がかかっていました。同様にアクセス量を調査する場合においても、各サーバに分散しているアクセスログを、ツールを用いてグラフ化し比較する、といったように手間を掛けないと横断的な調査はできませんでした。
対応策（ログ管理基盤導入）
対象のシステムにおいて、このようなログ管理における課題を解決するため、Fluentd、Kibana、Elasticsearchを用いたログ管理基盤を導入しました。対象のサーバは冗長構成を組んでいる全てのアプリケーションサーバとし、収集対象のログはサーバログ、アクセスログとしています。導入したそれぞれのプロダクトのバージョンは以下の通りです。
- ログ収集ツール：Fluentd 0.10.41
- ログ検索ツール：Elasticsearch 0.90.9
- ログ可視化ツール：Kibana 3.0.0
アプリケーションサーバの構成とログ管理基盤の関係を図1に示します。
ログ管理基盤の導入効果
続いて、ログ管理基盤導入後に明らかになった効果を紹介します。
視覚的に分かりやすいログ解析が可能
保守担当者は、ブラウザ経由でKibanaにアクセスします。Kibanaは、ユーザーが指定した任意の形式でElasticsearchに蓄積されたログデータを変換することで、視覚的に分かりやすいログ調査を実現します。
対象システムでは、収集したログ情報をヒストグラムならびに「サーバ名、時間、ログレベル、ログメッセージ」一覧として表示しています。ヒストグラム上で障害発生時間帯を範囲指定することで、グラフ範囲が絞られ同時に一覧の範囲も絞ることができます（図2）。
またフィルタリング機能で独自の検索条件を作成でき、例えばログレベルをエラー（level:ERROR）と記載することでエラーのみのログに絞ることができます。これらを駆使することでエラー発生時のログだけではなく、前後の詳細なログも簡単に確認できます。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか
リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。初回は全体的なアーキテクチャ、採用技術、開発体制について。
AWSがElasticsearchサービスを発表
Amazon Web ServicesがElasticsearchサービスをリリース。数分でElasticsearchのためのクラスター環境を構築でき、可視化環境や「CloudWatch Logs」との連携機能も持つ。
OSS製品ベンダーの開発手法の神髄はここにあり──コミュニティ活動を通じて世界中から優秀な技術者の獲得に成功したElastic
CTOとは何か、何をするべきなのか――日本のIT技術者の地位向上やキャリア環境を見据えて、本連載ではさまざまな企業のCTO（または、それに準ずる役職）にインタビュー、その姿を浮き彫りにしていく。第7回は人気のオープンソース検索エンジン「Elasticsearch」のクリエイターであり、Elasticの創設者でCTOを務めるシャイ・バノン氏に話を伺った。