2024.12.03
企業の情報漏えいで最も多いのは「中途退職者」による持ち出し 内部不正が発生しやすい3つの要素
リンクをコピー
記事をブックマーク
齋藤智之(以下、齋藤):みなさん、こんにちは。本日はよろしくお願いいたします。
自己紹介をします。齋藤智之と申します。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.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.11.25
論理的に「詰める」マネジメントでは本質的な解決にならない マッキンゼー流、メンバーの理解と納得を得る接し方
2024.11.28
管理職の「疲弊感」がメンバーに伝わるリスク 部下の「働きがい」を育む6つのポイント
2024.11.27
部下に残業させられず、自分の負担ばかり増える管理職 組織成長のカギを握る「ミドル層」が抱える課題
2024.11.27
仕事中の「今ちょっといいですか」が苦痛… いしかわゆき氏が語る、ADHD気質にマッチした働き方のヒント
2024.11.26
仕事の質を左右する「ムダな習慣」トップ5 忙しくなる前に棚卸ししたい“やめたほうがいいこと”とは
2024.11.28
“新規事業が生まれない組織”に足りていないもの 「PoC貧乏」に陥らず、アイデアを形にするためのヒント
不機嫌な自分をやめるために!認知行動療法の専門家 中島美鈴先生新刊『脱イライラ習慣! あなたの怒り取扱説明書』発売記念【無料オンラインイベント】
2024.10.25 - 2024.10.25
ログミーBusiness リニューアル記念イベント開催
2024.11.29 - 2024.11.29
品がある人、育ちがいい人の見える 人のセリフ 3選
2022.11.30 - 2022.11.30
ミドル層が組織成長のキーになる!〜働きがいを高める、一生働きたい職場の作り方〜
2024.09.25 - 2024.09.25
新しい事業創出のヒントはスタートアップにあり! ~著者に聞く、今こそ知りたいスタートアップの世界~
2024.10.23 - 2024.10.23