2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
齋藤智之(以下、齋藤):みなさん、こんにちは。本日はよろしくお願いいたします。
自己紹介をします。齋藤智之と申します。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と、このくらいの規模になっております。
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05