オープンソースと自社開発を組み合わせて、データプラットフォームの基盤を作る　LINEのデータ基盤開発部門のお仕事

LINEのデータプラットフォームのアーキテクチャ

湯川航氏（以下、湯川）：湯川と申します。よろしくお願いします。Data Platform室という、データを管理する部署のエンジニアなんですが、そこのアーキテクチャなどを紹介していきたいと思います。

こちらが今日のアジェンダです。最初にLINEのデータプラットフォームのアーキテクチャを簡単に紹介して、規模感をイメージしていただくためにちょっとした数字、KPIを出したいと思います。

その後、今どういう課題、チャレンジがあるかについて紹介し、最後に、うちのエンジニアがたまにLINEのカンファレンスで登壇したりエンジニアリングブログを書いたりしているので、そのへんをシェアしたいと思っています。

まず、アーキテクチャに関してですが、一応こういう感じです。まず、黒字で書かれているものが、いわゆるオープンソースのミドルウェアですね。青い字のものが、いわゆるLINE社内で開発した内製のツールです。これらオープンソースのものと自社開発したものを組み合わせて、データプラットフォームの基盤を作っています。

基盤についての話は、またこの後のスライドで軽く話しますが、最初に一番右のData Governance周りについての話は、ユニークな話かもしれないので簡単にお話しします。特にPrometheus、Grafanaはモニタリングで使うので、みなさんすでにご存じかもしれませんが、Hadoop、Hiveの基盤上で権限管理をどうするかは、たぶんどこの会社もキーポイントなのかなとは思います。私たちの環境では、Apache Rangerを使ってHDFSベースで管理しています。

というのも、私たちの環境であるHive、Spark、Trino（Presto）は、こういった3つのSQLエンジンを採用していることもありまして、Hive特有の機能で権限管理をするといったことが今はできないという背景もあり、Apache Rangerを用いてHDFSベースで権限管理をしています。

また、そのApache Ranger自体を直接ユーザーが触るのではなくて、内製のポータルサイトみたいなものを作って、ユーザーはそこで権限申請をすると、裏側のバックエンドで、そのRangerのAPIを叩いて権限を与えると。それでユーザーがHiveテーブルにアクセスできるようになる仕組みです。

実際にデータがどういうふうに格納されていくのかの流れがこちらのスライドです。わりとオーソドックスな構成だとは思いますが、私たちのほうでクライアントSDKであったり、サーバーサイド用のSDKであったりを開発していて、ストリーミングデータの場合、それらを通してログが送られてきます。

そのデータを、まずいったんApache Kafkaにproduceします。このへんはけっこう一般的な構成かなと思います。そのKafkaに入ったデータをFlink上のジョブを使って読み込んで、書き込んでいます。Flinkのジョブは、Kubernetesクラスタ上で動いています。

Flinkのジョブは種類がいっぱいありますが、一番典型的なケースは、FlinkのジョブでまずKafkaにあるtopicをconsumeして、そのデータをHDFSにランディングするケースです。

さらにいうと、HDFSでランディングした後に、ORCファイルに変換したり、Hiveのパーティションを作ったりもしています。

Hadoop以外だと、Kafka上のデータをconsumeして、Elasticsearchのインデックスを作るといったようなFlinkジョブもあります。このように、いろいろなジョブがあって、中には他のシステムに連携するようなこともやっていたりはします。

ここで、HDFS上に格納されたデータをどのようにビジュアライズしていくかという話をします。私たちの環境では、Spark、Hive、Trinoという3つのSQLエンジンを使っているので、これを使ってデータの加工処理をして、可視化していくことを行なっています。

そのデータを各自いったんストアしたものを、さらに加工したりする処理ももちろんあって、それを私たちのようなプラットフォーム側がやることもありますし、サービス側独自のデータであればサービス側のほうでETLして、Hiveでselect, insert, joinして、別のテーブルに格納し、それを例えばTableauでTrinoを経由してデータを可視化するようなこともやっています。

中には、OASISという、これはApache ZeppelinやJupyterのようなツールを内製したものなのですが、こちらを使ってPySparkでHiveテーブルを呼んで、いろいろ加工処理を行なって、いろいろ可視化するようなことも行なっています。

LINEの分析環境

次にざっくり私たちの分析環境、データ基盤のスケールを紹介したいと思います。

まずHadoopですが、HDFSのキャパシティは270PB（ペタバイト）という構成になっています。1日の増加分という意味では、410TB（テラバイト）。さらに私たちのサーバー、フィジカルマシン、バーチャルマシン、全部含めると5,400台という規模になっています。

Hadoopクラスタに関しては、1個のHadoopクラスタでだいたい2,000台ぐらいの物理サーバーを使っています。他にElasticsearchであったり、Kafkaであったあり、いろいろなサーバーがあります。

Hiveテーブルとして、56,000ぐらいあります。YARN、Presto（Trino）など、ジョブであれば、1日300,000ジョブあります。さらにストリーミングジョブのレコード数は一秒間だいたい13,000,000。全部1個のKafkaトピックではなくて、全部のトピックを合計するとこれぐらいの規模になっています。

エンジニアの数は、JPとKR両方あって、総勢75名となっています。いろいろな国籍の方がいます。

データプラットフォームの課題

次に私たちのチャレンジ、課題について紹介したいと思います。先ほど簡単に数字を紹介しましたが、けっこうなかなかな規模だとは思っていて、正直これだけの規模になってくると、いろいろ大きな問題がいっぱいあるわけです。そのへんのつらさ、つらみではないですけど、どのへんがチャレンジングなのかを簡単に紹介したいなと思っています。

HadoopやElasticsearchやKafka、こういった分散処理のミドルウェアは、基本的にはスケールアウトしやすい構成となっています。なので基本的にはサーバーを追加してスケールアウトしていくっていうのが一般的な構成なのですが、ある程度までいくと、ちょっと単純にサーバーを追加するだけでは解決できない問題も生じてきています。

例えば私たちの環境だと、namenodeは実は4つあります。namenodeはスモールファイルがたくさんあるとやはり非常にメモリ容量を食って、上限があるというようなこともあって、複数のnamenodeを立てて分散しています。HDFSのfederationを使って、4つのnamespaceで、datanodeはそれぞれ全部共有する構成を使っています。

また、Elasticsearchに関しては、現在5つのElasticsearchクラスタがありますが、それぞれにもインデクシングやシャードの数に上限があるので、1つのクラスタで大量のシャード数を管理するのは現実的に難しいです。そのためクラスタを分けることもやっています。

Hive metastoreの課題

またそれ以外にHive metastoreですね。これも、よく問題にはなっていますが、私たちの環境なんかでは、1つのテーブルで大量のパーティションがあるものもあります。確か4,000,000を超えるパーティションがあるテーブルがありまして、そういうテーブルに対してうっかりパーティションをフルスキャンするようなクエリとか投げてしまうと、まあもうとんでもないことになってしまいます。

要は裏側のHive metastoreのMySQLが、非常に負荷が高くなるというような問題があって、ここはちょっとスケーラビリティの課題のハードルを上げている部分でして。現状だと、ちょっとユーザーに注意喚起していくとか、Hiveのパーティション数をなるべく減らしてくような方向で対応しています。

恐らく根本的なソリューションはHiveではなく、Icebergのような別のソリューションを適用することかなとは思っていまして、現在Icebergの調査、技術開発も進めています。

また、私たちの環境は、本来あるべきはユーザーが間違って重いクエリを投げたとしても、サービスが安定的に運用できるような状態だと思うのですが、まだそこまで若干できていない部分もあるので、随時やっていくといっている状況です。

さらに、ストレージやコンピューティングリソースを効率的に使うことが重要です。で、結局大量のリソース、コンピューティングリソース、ストレージリソースを使っていますが、現状だとまだ優先順位付けができていないという状況があって。

例えば重要なサービスであればある程度手厚くする必要があるとか、そういったプライオリティ付けはまだちょっとぜんぜんできていない状況なので、そういったところ、コストレポートを作るとか、そういったことを今検討しています。

いろいろなデータがあるので、そういったどういうデータがあるのかのカタログを作る必要があると感じていて、すでに現在Hiveテーブルに関しては、どういうテーブルがあってどういうカラムがあって、といったようなカタログ情報をすでに集めています。

またそれに加えて、どういうデータを持っているのかや、将来的には恐らくHiveだけではなくてKafkaとかElasticsearchのインデックスに対しても、これはちょっと人間にしか付けられない情報だと思いますが、これはどういうデータなのかという情報を付けられるようにすることも考えています。

またデータの種類としても、Kafkaを通して入ってくるようなデータ、ストリーミングデータもあれば、サービス側のMySQLのデータをSqoopを使ってスナップショットで毎日取ってくるみたいなケースもあるので、そういったデータの種類もあります。

また、このデータオーナーは誰なのか、管理者は誰なのかも管理していく必要があります。さらに、そのへんのストレージ・コストや、コンピューティングリソースといったことも検討していく必要があるので、こういった情報を集めて、きちんと管理・検索しやすいものを作っていくのが重要かなと思っています。

キャパシティプランニング

また、キャパシティプランニングに関しては、IDCももちろんあって、ただサーバールームの随時増設はしていっていますが、やはりどうしてもルームにキャパシティに限界があって、ちょっとサーバーを移動しなきゃいけないみたいなこともあるので、そういったときには、随時慎重に作業を進めていく必要があります。

古いデータに関しては、あまりもう使われないので、アクティブじゃない状態、アーカイブストレージに格納することも今検討しています。一部HadoopのErasure codingを使って、アーカイブストレージ、といってもHadoop上ではありますが、Erasure coding化して格納することもやっています。

コンピューティングリソースの最適化に関しても、普通になんか物理サーバーを並べるというよりかはKubernetesを活用して、ダイナミックに活用するといったことも検討しています。実際、例えばFlinkのジョブはKubernetes上で動いています。

エンジニアのパブリックアクティビティ

そして次のトピックは、エンジニアのパブリックアクティビティということですが。2019年、2020年のLINE DEVELOPER DAYに、LINEのデータプラットフォームのエンジニアが登壇して発表しているので、もし興味があったら参考にしてください。

また、カンファレンスに比べて、エンジニアリングブログのほうがもうちょっと頻繁に更新しているので、データプラットフォーム室のちょっとカジュアルな感じの紹介や、どういったミドルウェア、パイプラインを使っているかなども掲載しています。このFreyは、さきほどチラッと話したSqoop、簡単にいってしまうとSqoopのWeb UIなのですが、サービス側の担当エンジニアがこれを使って、サービス側のMySQLのデータをHadoop上にインポートするようなことをやっています。

また、先ほどチラッと話したキャパシティプランニングのデータセンター移行について、どういったかたちでサーバーを移動したかという話もエンジニアリングブログで紹介しています。

また、私たちの環境では、オープンソースを活用して、システムやプロダクトを作っています。その中で気づいたものについては、随時コントリビューションをしています。

最後に、これはまあお約束ではありますが、採用募集中ということで。データプラットフォーム室では、エンジニアを募集しています。もちろん中途に限らず新卒も募集していて、いくつかいろいろなポジションがあって、上のデータプラットフォームエンジニア、ソフトエンジニア、サイトリアライビリティについては、エンジニア系はだいたい想像つくかもしれませんが、最後の2つは若干ちょっと少しユニークな感じかもしれないですね。

ソリューションエンジニアというのは、私たちのサービスのユーザーは社内のエンジニアなんですが、その社内のエンジニアに対して、少しアドバイスや、コンサルテーション、随時必要なベストプラクティスを提供するなどの調整を行うエンジニアです。また、私たちのプトダクト、内製のプロダクトを作っていくにあたってのプロダクトマネージャーなども募集しています。

以上、私の発表は終わります。ご清聴ありがとうございました。

質疑応答

司会者：湯川さん、ありがとうございました。ではQ＆Aに移ってまいりたいと思います。まず質問1つ目ですね。「Jupyter、RStudioに並ぶ内製ツールは、前者2つの既存ソフトと比べ、どういう部分をするためのツールなのでしょうか」と。

湯川：そうですね。たぶんOASISという内製ツールを私たちの会社では3年ぐらい前に開発し始めていて、これはZeppelinを元に、参考にして開発し始めたものです。一番今使われているのは、このOASISというツールですね。

どういう部分をするためのツールかというと、基本的に似たような感じなんですが、ノートブック上にPythonのコードでPySparkや、Spark SQLといったコードを書いて、一応cronの機能もあるので、デイリーバッチのETLツールとして、使うことができます。

またグラフ、ビジュアライズの機能もあるので、普通に折れ線グラフ、日々のKPIみたいなグラフを作ることも簡単にできます。

おそらくJupyterやRStudioは、コアなデータサイエンティストみたいな人が使っていて、プランナーとかエンジニアは、私たちの開発したOASISを使っているのがざっくりとした住み分けかなと思います。

司会者：ありがとうございました。