データは財産である　LINE Data Platform室のSREが大切にしているミッション

LINEのData Platform室におけるSRE

奥田輔氏（以下、奥田）：私からは、LINEのData Platform室におけるSREで、どういうチャレンジがあるのか、どういう仕事なのかを紹介します。よろしくお願いします。

まずは、自己紹介からです。Data Platform室のData Engineering1というチームで、エンジニアリングマネージャーをしている奥田と申します。2013年に、弊社のLINEに新卒入社です。もともとは、LINE GAMEのDBAをやっていました。そこから社内異動で、LINE本体のETLエンジニアからインジェスチョンパイプライン、Hadoopにデータを入れるようなパイプラインの開発。

2020年はいくつかHadoopクラスタがあって、Hadoopの移行といったクラスタ統合の全社プロジェクトのリーダーを経て、今はマネージャーをやっています。

今日のアジェンダはこんな感じでいこうと思います。ミッションとLINEにおけるData Platformは何か。その次にData PlatformにおけるSREと、その技術的チャレンジを紹介していこうと思います。

LINE全体のミッション

最初はミッションです。これはLINE全体のミッションなのですが、コーポレートサイトに「CLOSING THE DISTANCE」というミッションが入っています。この下で、行動規範としてLINE STYLEもまた公開されています。そこにいくつかある中で、LINE STYLEの4番目に、「Always Data-driven　感覚ではなく、データ＝事実を信じる」という目標が掲げられています。

何が言いたいかというと、全社的にデータは財産である。データというのはすごく重要で、エンジニアリングとして使うだけじゃなく、ビジネス、企画、いろいろな場所でデータを信じて仕事をやっていこうというポリシーがあります。

なので、このLINE STYLEのAlways Data-drivenに合わせれば、Data Platformのミッションはすごくシンプルです。「Make Data-driven easy」という、データ主導の企画や開発といった、いろいろなお仕事を簡単に、手軽にできるようにすることが目的となっています。

LINEにおけるData Platform

では簡単にミッションを紹介した上で、LINEにおけるData Platformはどんなものかを説明します。

まずはIU。Information Universeと言いますが、こちらはLINEにおけるData Platformのブランド名です。弊社LINEのデータの分析基盤だったり活用基盤がIUというブランド名で、全社に周知されています。

技術スタックも含めたアーキテクチャも、本当に簡単にですが説明します。文字なしで簡単に説明しますが、左側のこちらがデータの投入基盤です。みなさんが持っているスマートフォンのことで、LINEのアプリケーションなどのいろいろなLINEのサービスを（スマートフォンで）使われている方も多いかと思います。

それが、クライアントから直接だったり、クライアントがサーバーにコミュニケーションしたそのサーバーのアクセスログやAuditログであったり。またそこが抱えているバックエンドのデータベース、MySQLとかMongoDBとか先ほど説明がありましたけどそういったデータなど、データと名の付くものすべてが、IUというプラットフォームに集まっている感じになります。

集めるだけじゃダメで、その先に活用がないといけません。なので例えば、機械学習だったりデータビジュアライゼーションだったり、またサービス側にフィードバックしたりを通じて全社的にいろいろなデータの活用が行われています。

当然、機械学習チームやデータサイエンティストチームも別に存在するんですが、そういったチームが私たちのプラットフォームの上でいろいろな活動をしています。また、サービスごとの企画者だったり開発者も私たちのプラットフォームの上で何かトラブルが起きた時に、なぜこんなログが発生したのか、いつ発生したのかみたいな時系列データだったり、最近ユーザー数が伸び悩んでいるけどいつからなんだろうといったことをビジュアライズしてみたりも、このIUのプラットフォームの上で行われています。

こちらが技術スタックです。採用ページのジョブディスクリプションです。採用概要にも載っていますが、こんなようなツールを使っています。一部、この緑色になっているのが社内で開発しているようなツールです。

Yanagishimaというクエリツールだったり、OASISというノートブック、Datahubというデータのインテグレーションツール、LINE Analyticsというログを投入すると自動的に可視化できるようなツール。こういったものは自社開発しています。

当然自社開発のものだけじゃなくて、この下にあるようなオープンソース。HadoopのみならずKubernetesやElasticsearch、またストリーミングシステムのSparkやFlink。クエリエンジンのTrino、前の名前で言うとPrestoというツールで、いろいろなかたちでデータを活用できるように、いろいろなソリューションを提供していることを理解してもらえればなと思います。

またデータプラットフォームである以上、データガバナンス、セキュリティや権限コントロールは非常に重要です。なので、カタログシステムであるIU Portalだったり、Central Dogmaというコンフィグレーションの管理ツールも使ったりします。

データのスケール

では簡単にですが、どれぐらいのデータを抱えているのかというスケールをこれから紹介いたします。1枚1KPIでいきます。まずこのHDFS。IU、HadoopのHDFSのキャパシティがだいたい270PB。

こちらはどんどん増えています。どのぐらい増えているかと言うと、1日あたり400TB。日によって増減はありますが、このぐらい増えています。

サーバーの数は、だいたい5,000台を超えてきています。物理マシンと仮想マシンを合わせて、だいたいこれぐらいの台数があります。

Hiveテーブルは1つのデータのタイプによって1つのテーブルが作られているという感じなんですが、だいたい5万を超えるデータの種類が私たちのIUと呼ばれるプラットフォームの中で活動している。

1日あたりの統計だったりストリーミングジョブだったりですが、いろいろなジョブがだいたい1日で30万ぐらい実行されています。自動的に実行するものもあれば、手作業でアナライザーがいろいろなSQLを投げたりするものも含まれています。

それを支えるデータを投入するパイプライン、これも開発は私たちデータプラットフォームのSWEの使命なのですが、これがだいたい秒間で、ピーク時に1,300万レコードぐらい入っています。多いからどうかというのはないですが、僕的にはけっこうチャレンジングな環境だなと思っています。

全体像を見ると、いくつか出していない数字もありますが、このような感じになります。

こちらをだいたい80名ぐらいのエンジニアで、日本、韓国合わせて補っている感じになります。

組織図

組織図を簡単に説明します。こういったData EngineeringやData Scienceといったそれぞれの部署があって、その中でもData Platformはこちらの図の一番上の組織になっています。他には、データガバナンスを司るData Management室と協業しながらやっています。またData Platform室の中にはいくつかのそれぞれの特性に合わせたチームがあります。

例えば僕がマネージャーをしているData Platform Engineering。そういったことを専門でやる組織があったり、他にはETLを専門とする組織やカタログWeb APIを作るような専門組織です。

だいたいヒストリーを追うと、最初はいろいろな環境でそれぞれが開発、管理していたデータウェアハウスが、統合、センタライズされて、そうすると今度はスケールの問題が発生します。人もクラスタもスケールをしないとということで、1つの組織でデータを管理して、さらにデータデモクラシーを起こす。サービス側にデータ活用できるようなData openという施策まで、今は到達しています。

他の組織との関わりはありませんが、当然先ほどのデータデモクラシー、日本語では「データの民主化」と言えばいいかと思うんですが、サービスサイドにいろいろな活用ができるようなシステム、サービスというのを提供しています。当然サービスは各サービスの開発だったり、マシンラーニングや統計チームにも使ってもらっています。

またデータガバナンスも、先ほどから申し上げているとおり重要なので、セキュリティチームと協業して、全社共通のデータ活用のルールというのを決めたり、リスクというのはどこにあるのかを定義したりしています。

おもしろいポイント

弊社のデータ組織のおもしろいポイントは、オンプレミスというところがあると思います。なかなかないスケールを維持するために、オンプレミスという選択をしています。そういったところにやはりいろいろなテクニカルチャレンジがあるので、単純にいろいろなパブリッククラウドのソリューションを使うだけでは味わえない、いろいろな挑戦があるかなと思っています。

またサービスやユーザーが非常に多いです。社内ユーザーだけで700ということなので、そういったデータを利活用してもらうための、データの民主化やデータのスケールからくるさまざまなトラブルも解決する必要があります。

Data PlatformのSRE

では本題です。Data PlatformのSREを説明します。だいたいこんなような理由があると思います。日に日に増え続けるデータがある。そこにいろいろなシステムが統合されています。また、オープンソースによって私たちは成り立っています。

そういったところで、増え続けるデータをキャパシティプランニング。どれぐらいのデータサイズ、どれぐらいのシステムであればいいか。またシステムが密に統合しているので、High Availability、高可用性やシステムの見える化、Observabilityを担保する必要がある。またオープンソースで成り立っているので分散システムにおける非常に深い知識というのが求められます。

キャラクター的にはこんな人が望ましいです。まずはプロアクティブ、自発的に問題を解決してくれる人だったり、ステークホルダー、いろいろな組織と密に連携しているので、それぞれのステークホルダーにいろいろ自発的に交渉したりアイディアを提供したりしてくれる人。またオープンソースで成り立っているので、分散システムにすごく興味がある人はウェルカムです。

採用情報はパブリック情報なので少し割愛しますが、私たちData Platformでは2種類のポジションがあります。Site Reliability Engineerと、もう1つはDistributed System Administrator。

この2つの違いなんですけど、Site Reliability Engineerは、どちらかというと専門。HadoopならHadoop、ElasticsearchならElasticsearchに特化したポジションとなっています。なのでスペシャリストを求めているようなポジションになります。また技術的にかなり難しい問題を解決していくポジションです。

一方でDistributed System Administratorは、けっこう一般的なSREに近いかもしれませんが、ジェネラリスト。いろいろなシステムを統合してプラットフォームとして維持運用をしていくのにフォーカスしています。なのでチームとしてプラットフォームを運用するにはどうしたらいいか。またチームビルディングまで考えてくれるような人を募集しています。

技術的チャレンジ

ちょっと時間があれなので、技術的チャレンジというのを1つだけ紹介します。1つ、先ほどSREの業務の中にあったキャパシティプランニングですね。今すごくチャレンジングだなと思うことは、Data Platform専用のデータセンターを構築するということもチャレンジしています。

なので私たち専用のデータセンターはどのようなものがいいか。また既存のデータセンターとのネットワークのプランはどうすればいいか。また古いデータのアーカイブポリシーだったり、いつまでもデータを保存していくとリソースを食っていくので、そのリソースの最適化というのも、キャパシティプランニングの1つのお仕事となっています。あと他にあるんですが、ちょっとここは割愛します。

結論としては、いくつか私たちが抱えているテクニカルな問題があります。複数のサービスがあったりオープンソースだったり、またデータスケールが大きいということがあります。こういった技術的難しさをチャレンジとして捉えて、私たちのLINEの行動規範の1つであるAlways Data-drivenを叶えるのが私たちのミッションです。

そういった人材というのをぜひ募集しているので、興味があればぜひお声がけください。以上になります。ありがとうございました。