CLOSE

ログ収集プラットフォーム開発におけるElasticsearchの運用(全2記事)

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

2018年1月30日、LINE株式会社が主催する技術者向けミートアップ「LINE Developer Meetup in Tokyo #27 -Elastic-」が開催されました。27回目となる今回のテーマは「Elastic」。LINE社内ではElasticsearchがどのように運用されているのか? ゲストスピーカーにElasticのエヴァンジェリストも迎え、最新の事例と今後について語ります。プレゼンテーション「ログ収集プラットフォーム開発におけるElasticsearchの運用」に登場したのは、LINE株式会社開発3室の齋藤智之氏。ログ収集分析基盤とはなにか? Elasticsearchはどのように運用されてきたのか? 知られざる舞台裏とElasticsearchに関する知見を紹介します。

ログ収集プラットフォーム開発における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と、このくらいの規模になっております。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 大変な現場作業も「動画を撮るだけ」で一瞬で完了 労働者不足のインフラ管理を変える、急成長スタートアップの挑戦 

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!