- 講演資料：データ分析で始めるサービス改善最初の一歩
これまでの運用と直面していた課題
はじめに、石原氏は今回のセッションテーマの題材となったサービスの大まかな構成図を示し、概要の説明を行いました。構成図は以下の内容となります。このサービスは解析ツールに自社サービス＋αの形でRやElasticsearch、FlumeといったOSSを活用・併用しています。
サービスの現状として石原氏が掲げたポイントは2点。障害検知を元にした監視については監視基盤として社内共通のものを用意したり、サーバ監視ツールのmuninを導入したりなどの対策を行っていました。しかしながらこの環境は"単体の"障害を検知できていたものの、障害の全体像を把握するには至らない環境でした。そしてもう1点は自動化に関するもの。テスト自動化の仕組みとしては稼働しているものがあったのですが、ユニットテストや結合テストが中心の構成だったため、定常的なパフォーマンス計測については手薄な部分がありました。
この2点のポイントを踏まえて石原氏は「"サービスの全体傾向をつかむ"という部分ができていなかった。まずログを収集・分析することで改善・問題解決への実現を目指した」と現状認識からのアクション実践へと移ります。
「ログ収集と可視化」の取り組み内容
1つめのアクションとして行った「ログ収集と可視化」では、オープンソースを活用。ログ収集をFlumeで行い、Elasticsearchに収集したログを蓄積し、蓄積したログの可視化にKibanaを選択することでアクションに取り組みました。この仕組みで「リクエスト単位での利用傾向を確認する」というのが1つのゴールとなり、必要なプラグインの設定等を行い、下記画像のような構成ができ上がりました。
しかし運用を続けていくと、いくつかの問題点が見えてきます。当該環境ではログの出力量が多く（1日あたり20GB）、そのまま長期間保存を続けて行くと"容量的に厳しい"状況となることが分かります。また、出力されているログレベルや内容がまちまちだったこともあり、有用なログを選別していくことが困難であることも分かりました。
この問題については、収集するログをApacheアクセスログのみとすることで大幅に削減。サイバーエージェント社の事例を参考に、FlumeにEsperを組み込むことで対応を行いました。Esperは複合イベント処理（CEP：Complex Event Processing）が可能なJavaベースのオープンソースで、SQLライクなイベントデータの操作を可能とします。Esperの機能を使って必要な集計値などを割り出し、Elasticsearchには必要な値のみを投入することでログの量を大幅に削減することができました。また、Elasticsearchに投入するデータについてはKibanaで可視化する際の設定を踏まえて可視化・項目選択の試行錯誤を繰り返し、有用な可視化対象項目の選定を行いました。
この取り組みによって、「障害の全体像がわからない」「需要予測がしづらい」といった課題が解決、アクセス傾向も掴める様になったと石原氏は振り返りました。更には、ElasticsearchやKibanaを使った可視化は殊の外簡単ではあるものの、何を集めてどう可視化するのかというポイントを踏まえたデータの判別を行わないと同種の問題に突き当たることになる、という反省点にも併せて言及しました。
