発生するログは1日あたり約200億レコード　LINEの基幹サービスを支えるログ収集分析基盤の裏側

ログ収集プラットフォーム開発におけるElasticsearchの運用

齋藤智之（以下、齋藤）：みなさん、こんにちは。本日はよろしくお願いいたします。

自己紹介をします。齋藤智之と申します。2015年にLINEに新卒で入社しました。

現在はSite Reliability Engineerとして働いております。所属する部署は開発1センター開発3室というところになりまして、LINEメッセンジャー本体のサーバーサイドの開発をサポートする仕事をしています。

例を挙げますと、サーバー・アプリケーションのメトリックやログの収集ですとか、サービスのデプロイツールの提供ですとか、そういう開発用のインフラを提供する部署になります。

2016年11月からは、ログ収集や分析の基盤を構築するプロジェクトにジョインいたしました。主にElasticsearchの運用ですとか、Elasticsearchに書き込みを行うサービスの開発を担当しております。本日は、このプロジェクトの中で経験してきたことについてお話をしようと思います。

本日のアジェンダです。初めに、ログ収集分析基盤がどういうものかというプロジェクトの概要をご紹介します。具体的にどういったシステムを構築しようとしているのか、Elasticsearchがどのように使われているのか、そういったことをお話します。その後に、Elasticsearchに関して取り組んできましたイシューや改善したいと考えているところについてお話しようと思います。

では、プロジェクトの概要をご紹介していきます。ぼくたちが取り組んでいるプロジェクトのミッションを表したものがこちらになります。

LINEサーバー開発者向けのログ分析環境の構築です。こちらでLINEサーバーと言っているのは、LINEのメッセージング機能を提供しているサーバーを含めたLINEの基幹サーバーのことを指しています。

例えば、LINEの基幹サービスにはこんなものがあります。

メッセージングの機能を提供しているtalk-serverですとか、オブジェクトストレージのOBSですとか、認証機能を提供しているAuthのサーバーなどがあります。こういった基幹サービスはリクエスト数が多く、ログの量もそれに比例して大きくなっています。

talk-serverのリクエストログの量を例に挙げますと、ログのレコード数が1日当たり200億レコード、サイズにすると1日当たり9テラバイト、ピーク時のスループットが1秒当たり40万レコードです。本プロジェクトでは、大規模なログを抱える基幹サービスの開発者に向けてログの分析環境をインフラとして提供します。LINEサーバー開発者が、管理コストをかけずに大容量ログの分析をできるようにすることが1つの目標となります。

さまざまなログの分析のニーズを満たすために、複数の分析用のサービスを管理・提供していきます。

1つめに挙げますのがElasticsearch、それからKibanaの提供をしていきます。これによって、インタラクティブなログの検索やダッシュボード作りが簡単にできるようになります。

2つめに、hadoop HDFSへのデータの保存をサポートしています。大規模なアグリゲーションですとか、長期間のログの保存をしたいとか、そういったニーズに応えています。

3つめに、Kafkaへのデータ保存もサポートしています。ストリーミング処理をしたり、データパイプラインの起点に使いたいといったニーズに応えています。

プロジェクトの目的とシステム構成

プロジェクトの目的をまとめます。

本プロジェクトでは、LINEサーバーの開発者に向けて、インフラとしてログ分析環境を提供しようとしています。また、簡単にログ分析環境を使えるようにするために、使いやすいログ収集手法を確立しようとしています。LINEの基幹サーバーのログを扱うので、大容量のログでも安定してログの収集・分析ができるようにシステムを設計しています。

次に、どういったシステムを実際に構築しようとしているのかをご紹介します。こちらがシステムのアーキテクチャーの図になります。

一番左にLINEの基幹サービスなどのログの送信者であるログプロデューサーがあります。一番右側にはElasticsearchなどの分析用のストレージが並んでいます。なので、左から右に向かってデータが流れていくデータパイプラインになっています。

APACH Kafkaという分散メッセージングシステムをみなさんご存じでしょうか？　メッセージキューとして使うことができまして、パブリッシュ・サブスクライブモデルでデータの転送をすることができます。このシステムの中では、サービスからのログがすべてKafkaに集約されるようになっています。

なので、ログを送るサービス側と分析基盤を開発する側で、Kafkaを境界として2つに分かれているように見ることができます。Kafkaを介してメッセージングを行うことで、ログ送信者は分析基盤側での障害ですとか、新しい分析基盤の追加といった変化に対して影響が分離されるという利点があります。

次に、Kafkaに入っているデータを処理するのが、Sinkと呼んでいるKafka consumer applicationになります。

Kafkaに集約されたデータをフェッチして、分析ストレージにデータを書き込む役割を果たしています。Elasticsearchに書き込みを行うSinkの場合には、KafkaからフェッチしたデータをJSONに変換してbulk indexingを行うということをしています。このシステムのユーザーであるログ送信者から見ますと、Kafkaにデータを送信したあとは何もすることなく、Elasticsearchやhadoopでの分析が可能になっているということになります。

実際にシステムのユーザーがログの分析ができるようになるまでの流れは、このようになっております。まず初めにメッセージのスキーマを提示してもらいます。

このスキーマの定義にはGoogleのProtocol Buffersを利用しています。右上のボックスで示したようなフォーマットでスキーマを定義することができまして、この定義を基にシリアライズ、デシリアライズを行うコードを生成してサービスで使うことができます。サービスによってロギングしたいデータの構造はさまざまあるので、必要に応じてそういったスキーマを定義できるようになっています。

スキーマを定義した後に行うのが、Tableの作成という行程になります。Tableと呼んでいるものは、データフローのunitと考えてもらうのがよいかと思います。

どんなデータが送られてくるかを表すメッセージスキーマや、どこにデータが送られてくるのかを表すKafka topic、どう使いたいのかを表す分析ストレージの設定などを記述してもらって、このシステム開発者であるぼくらのチームに送ってもらいます。

このTableの設定に基いて、Sinkや分析用のストレージの設定を、ぼくらのシステムの中で調整しています。例えばElasticsearchに関しては、index retentionですとかindex rolling period などの設定は、ユーザーからもらったプロパティーに応じて変更できるようになっています。このTableの作成までできますと、あとはKafkaにログを送るだけでログの分析が可能になります。

Kafkaでのログの送信のサポートとして、logging SDKの開発なども行ってきました。

LINEの基幹サービスでは、JavaのロギングライブラリであるLogbackを利用しているサービスが多いです。なので、Logbackのappenderをこのシステム用にカスタマイズしました。

具体的には、ログのレコードをprotobuf messageに変換してKafkaに送信するappenderを開発して提供しました。これを使うことでライブラリーの追加とLogbackの設定変更だけで、コードの修正なくKafkaにログを送信させることができるようになります。現在、半分くらいのデータがこのlogging SDKを利用して送られてきています。

システムのアーキテクチャーについて説明してきました。このシステムの構築に向けてぼくたちのチームでは、KafkaやElasticsearch、hadoopの管理・運用ですとか、Sinkの開発、ログの送信をサポートするライブラリーやサービスの開発、そしてシステムの自動化、自律化を目指して開発をしています。

プロジェクトの説明の最後に、現在運用しているElasticsearchのクラスターの規模についてご紹介します。

現在、クラスターを3つ運用しています。

すべて合わせまして100を超えるデータノードがあります。1日のデータの流入量がドキュメントの数で160億ドキュメント、サイズにして18テラバイトになります。その他のデータ量に関しても、細かい数字を載せておきました。

Elasticsearchに保存されている総データ量が3,700億ドキュメント、400テラバイト。インデックスの数が3,000、シャードの数が17,000と、このくらいの規模になっております。