LINEにおけるすべてのデータの蓄積から利活用まで　データプラットフォーム「IU」はなぜデータを統合できたのか

データの分断をどのように解決したか①ストレージの問題

本移行プロジェクトにおいて、アプローチを大きく2つに分類してお話しします。1つは、技術的アプローチ。複雑な問題・システムを簡単にするようなアプローチです。もう1つはデータマネジメント的アプローチ。ユーザーにとって移行のコストを下げるべく、現在の状態をできるだけ変えることなく、変更点を少なく移行ができるように心がけました。

まずは技術的アプローチです。大きく3つ、ストレージのフェデレーション、計算リソースの再配置、カタログの同期です。図にするとこんな感じです。カタログ機能を持つMetaStoreは、旧クラスターからIUへ同期をする。計算リソースは旧クラスターからIUヘデータセンターごと再設計し、物理的な移行を行う。ストレージは旧クラスターとIUを同列に定義し、双方ともアクセスを可能にする。こちらも1つずつ見ていきます。

まずはストレージから。こちらはHDFSの機能の1つである、フェデレーションを導入しました。フェデレーションとは、この図のように、1つのHDFSクライアントから、複数のHDFSクラスターにアクセスできるようにすることです。

こうすることで、IUのHDFSクライアントからは、IUのみならず、旧クラスターのDatachainやDatalakeにもアクセスできる状態になりました。この方法を採ることで、データのコピーやDouble writeの必要もなくなりました。これまでのディレクトリ構造や、権限体系も維持できます。また、ディスクリソースの効率化もできます。

今回導入したのは、論理フェデレーションであり、物理的にすべてのクラスターは同じディスクを共有しています。これにより、よりキャパシティプランニングが容易になりました。特にIU HDFSにおいては、viewfsを導入し、複数クラスターがあることは意識をせず、より透過的にクラスター間でアクセスできるようになりました。

データの分断をどのように解決したか②コンピューティングの問題

次にコンピューティングです。具体的には、Hadoop YARNの移行になります。YARNもフェデレーションをサポートしていますが、実際のリソース配分、Queue設計の関係上、この方法は選択せず、IDCレベルの再設計を伴う大規模な物理的移動を行いました。

図にするとこんな感じです。新しいIU専用のデータセンタールームを用意し、Datachain、Datalakeがあったデータセンターから、物理的に新しいデータセンターにサーバーを再配置しました。

この部分では、インフラチームや輸送業者とともに、デコミッション・リコミッションの計画を立てて、サービス提供を極力抑えられるように計算リソース調整を行いました。

この再配置では、100台から200台程度に小分けをして、段階的に再配置しました。こうすることで、それぞれのフェーズでIU、Datachain、Datalakeにどのぐらいリソースがあるのか、そのリソースがあればどういったジョブが回るのかを見積もれて、その情報を元に移行対象のユーザーに時期をガイダンスできました。

例えばMLチームは、Datalake上の大量のリソースを使用していました。そのため、IU上にも同等のリソースが必要となりますが、Datalakeをデコミッションしてしまうと、MLサービスに影響が出てしまいます。そのため、まずリソースの余裕があるDatachain側から移行を開始し、その間にMLチームの移行を並列で進める、といった計画を立てていきました。

この再配置により、IDCレベルでのキャパシティプランニングも行いました。ネットワークインターフェイスの容量を上げたり、ラック設計の見直しを行う。こうすることで、将来的な負荷の増加にも耐えられるように見直しを図りました。

データプラットフォームは、ネットワーク体系を非常に大量に使います。データセンターを分けることで、別サービスとの帯域分離を行い、高負荷なジョブの投入難易度を下げたり、障害時の問題切り分けを簡単に行えるようにしました。

データセンター間の移動に関しては、引越し業者とも協業したりしました。普段のエンジニアリング業務ではなかなか触れることのない業態と接して、目新しさをとても感じました。

もう1つ、このトピックに関する技術的なアプローチは、Hybrid Hiveserver2です。これは旧クラスターのYARNリソースが減っていく一方で、いまだにカタログ移行が完了せず、旧クラスターのMetaStoreを使い続けるケース。これに対応するためのアプローチです。

このケースに対応するため、HiveにKerberosの認証関連パッチなどを当てて、MetaStoreは旧クラスター、YARNリソースはIU、といった両方を同時に使えるエンドポイントを用意できました。

データの分断をどのように解決したか③カタログの問題

技術的アプローチ、最後はカタログです。ここは非常にハードルが高く、最初は良い方法を見つけられませんでした。旧クラスターとIU、両方に同じテーブル情報があった場合、フェデレーションのような複数クラスターにまたがるカタログアクセスを提供できるケースは、非常に少なかったのです。

この複数クラスターにまたがるカタログアクセス、当時はPrestoにおいては実現可能でしたが、HiveやSparkではまだApacheのJIRAにパッチがあるだけで、正式に提供できるほどの状態ではありませんでした。

一方で、手動でのテーブル情報の移動は、先ほどの問題セクションでも話しましたとおり、ステークホルダーの整理に多大な時間と労力を要します。そこで我々は、MetaStoreのDDLイベントを一つひとつ、旧クラスターからIUに自動的に同期するシステムを開発することを考えました。我々はこのシステムを「MetaStore Syncer」と呼んでいます。

こちらがその図です。LINEでは、HiveMetaStoreにテーブル情報を保存しています。Hiveでは「MetaStoreEventListener」という抽象クラスが定義されています。これを利用することで、HiveMetaStore上で起きたイベントをトリガーとして、さまざまな処理を行えるのです。

今回はMetaStoreEventListenerの中でもDDL系のイベント、テーブル、パーテーションの作成、削除や変更といったものをトリガーにしました。これらイベントが起きた時に、それらイベントをJSON形式に変換して、Kafkaに送信します。ここではネットワーク障害が起きた時でも、復旧が容易に可能となるような工夫があります。こちらは次のスライドで紹介します。

Kafkaに送られたイベントは、SyncWorkerというKafkaコンシューマによってフェッチされます。SyncWorkerでは、IU移行に必要のないDB、テーブルのフィルタリングや、名前の変換などのロジックを持っています。この変換におけるルールは、LINEのOSSである設定管理ツール、CentralDogmaを利用して管理・反映されています。

これらの変換が終わった後に、SyncWorkerはIUのHiveMetaStoreに書き込みを行います。これが一連のMetaStore Syncerの流れです。

MetaStore Syncerのメリットと工夫点

MetaStore Syncerのメリットや工夫点を紹介します。まず、このSyncによってIUユーザーは自分たちのジョブをIU上だけで利用可能になります。自分たちでテーブルや過去のパーテーションを移行する手間の必要がなくなったわけです。これにより、移行の難易度はグッと下がり、IUへの移行が促進するきっかけとなりました。

このMetaStore Syncerはストリーミングプロセッシングです。正常に動いている時はほぼリアルタイムで反映されますが、システムには障害が付き物です。もしこのMetaStore Syncerのサーバーが1つでもダウンしたらどうなるでしょう。

こういった障害時にデータをできるだけ取りこぼさないよう、MetaStoreEventListenerから直接Kafkaへプロデュースするのではなく、一度ローカルファイルに書き出して、fluentd経由で各イベントをKafkaに送ることにしました。ネットワーク越しのアクセスよりも、ローカルディスクアクセスのほうが信頼性が高いと考えたためです。

また、書き出しのパフォーマンスも良いため、MetaStoreEventListenerそのものの処理パフォーマンスによるHiveMetaStoreの性能劣化の懸念も抑えられました。

特定のテーブルが大量のパーティションを更新することも懸念材料でした。大量のMetaStoreEventによりストリーミングプロセッシングが遅延し、多くのテーブルが最新状態ではない、というトラブルが容易に想像できたわけです。

この影響をなるべく小さくするため、コンシューマー側のKafkaパーティションアサインは、テーブルを基準としたものとしました。このお陰で、MetaStore Syncerのトラブルシューティングも、その原因となるイベントがなんなのか、簡単に発見できるようになりました。

先ほどの図でも挙げたとおり、SyncWorkerでは、フィルタリングや変換ロジックが存在します。データ自体が古く、IU移行に必要のないテーブルも数多く存在しました。これらを除外し、IU側の整理に役立てることがこの機能の主な目的です。また「ユーザー自身で旧クラスターとIU、両方管理をしていきたい」というニーズにも応えられました。

IUを使用するユーザーの移行①接続先の切り替え

これらの技術的アプローチにより「IUだけを使えばいい」という状況を作れたわけです。しかし、どんなに新しい環境においても、IUを使用するユーザーが移行してくれなくては完了ではありません。また、システムの理解から作業コストまで、その移行という作業自体が負担となることも否めません。そのため、データマネジメント的アプローチにて、移行における変更を最小限にし、移行ハードルを下げることに注力しました。

具体的には、この3つのポイントに分けて説明いたします。1つ目は接続先の切り替えのみで完了すること。2つ目は権限を旧クラスターから維持できること。3つ目はステークホルダーを重要度、複雑度の観点で段階分けすること。

まずは接続先の切り替えのみで完了することに関して説明します。旧クラスターと新しいIU、それぞれに接続しながら、「どちらが正解か」を判断しながらシステム移行を行うのは、データ整合性の担保や複雑性の増加など、かなりのコストを伴います。

そこで、エンドポイント、接続先をIUに切り替えるだけで、同じデータを見れるシチュエーションを作りました。

図にするとこんな感じです。まずはデータの投入に関して。こちらはHDFSフェデレーションのお陰で、データが旧クラスターにあっても問題ない構成になっています。これにより、データ投入のパイプラインは既存のまま、一切の変更をする必要がなくなりました。

それぞれのHDFSクラスターに保存されたデータは、どのように参照されるのでしょうか。これは、MetaStore Syncerのお陰で、旧クラスターの重要なテーブルはすべてIU MetaStore上でも参照できるようになっています。

これらのデータの実態は、旧HDFSクラスターのもともとのデータと同じです。つまり、同じファイルを参照しているため、データの整合性は担保されている、といえます。これらを総合して、データの整合性を気にすることなく、IU側へ接続先を切り替える。それだけで旧クラスターと同じような感じでデータを利用可能になったわけです。

IUを使用するユーザーの移行②権限の旧クラスターからの維持

次に、権限を旧クラスターから維持できることについてです。まっさらなクラスターを用意した場合、権限申請を1からやり直さないといけなかったり、必要な権限が足りていなかったりしてしまう危険があります。当然のことながら、不必要な権限を与えてしまうことは重大なインシデントとなり、最優先で避けるべき事項です。

この点は、HDFSフェデレーションとそれに伴う権限管理システム、Ranger・LDAPの統合により達成しました。既存のデータは旧クラスターにあるので、これら権限は以前と同等なまま維持されます。ファイル、ディレクトリのユーザーや、それらのパーミッションポリシーも同一にし、IU移行後も権限によるトラブルが起きないようにしました。

LINEのデータプラットフォームでは、ユーザーの管理にLDAP、権限管理にRangerを用いています。これらを別々に管理することは、管理コストの増大だけでなく、権限ポリシーの不一致など、重大なオペレーションミスを招く危険がありました。そのため、Ranger、LDAPも1つに統合し、すべてのHDFSを1つの権限システムで管理できるようにしました。

IUを使用するユーザーの移行③ステークホルダーの段階分け

3つ目は、ステークホルダーを重要度・複雑度の観点で段階分けすること。LINEではさまざまな組織が自律的に動いています。これはとても良いことだと考えていますが、各々の組織においてのデータプラットフォームに対する依存度やデータサービスとの結びつき具合、そしてデータ利活用のリテラシーや技術的スキルがさまざまになっています。また、問題のセクションで提示したとおり、組織同士がデータ生成において依存していることも多い状況です。

そのため、すべての組織を画一的にガイドするのではなく、基本的なポリシーをシンプルにしながら、データプラットフォームとの重要度に鑑みて、各々の組織にカスタマイズされた移行手順を提示しました。具体的には、このようなティアーで分けて考えています。最上位のティアーは、生データや全社的に幅広く利用されているデータ生成に責任を持つデータプラットフォームとなります。

次にそれら生データを利用し、より高度なデータモデルなどを生成する、機械学習、データサイエンティストチームなど。そして最後にそれらデータを利活用しながらサービスにとおしたデータ生成や、ダッシュボード管理をしているサービスサイド。

このような段階に分けて、下のティアーから順番にIU移行をすることで「データがIUに存在しない」「他のチームが移行したせいで自分のシステムが壊れた」といったサービストラブルを最小限に抑えられました。

ではなぜ下のティアーから移行すると、移行がうまくいくのか。データ生成フローの末尾であるティアー3から移行したとします。彼らより上のティアー1、ティアー2は、MetaStore Syncerのお陰ですでにIU側にデータが用意されています。よって、ティアー3のユーザーはIU側に切り替えるだけでデータ生成を行えるのです。

この時点では旧クラスターにはティアー3のデータは存在しなくなります。しかし、彼ら以降はデータ生成の依存関係が存在しないため、彼らが移行しても他の組織に影響はありません。そして、旧クラスターの依存度を減らすことで、計算リソースのデコミッションが行え、サーバーの物理的移動や要らないコンポーネントの廃止など、システム整備を進められました。ティアー3がすべて移行できた後、ティアー2に対して同等の方法を採ってあげることで、徐々に移行が完了していくわけです。

このセクションの振り返り

アプローチセクションの振り返りです。このセクションでは、技術的・データマネジメント的の両方から、どのようなアプローチをもってIU移行を達成したかを紹介いたしました。

技術的にはストレージのフェデレーション、計算リソースの再配置、カタログの同期。データマネジメント的には接続先を切り替えのみで完了すること、権限を旧クラスターから維持できること、ステークホルダーを重要度・複雑度の観点で段階分けすること。これらにより複雑なシステムをシンプルにし、変更を最小限にすることで移行のハードルを下げることに成功しました。

IU移行の結果と将来像

本セッションのまとめとして、このIU移行における結果と、IUにおける将来像を紹介して締めようと思います。

このIU移行を通じて我々が学んだことを紹介します。1つ目は、技術者として内部仕様を理解すること。それは複雑な物事を明確にし、よりシンプルな解決策を思いつく助けとなりました。

2つ目は、プラットフォームを提供する側として、できるだけ既存の環境を維持できるようにすること。変更というのはそれだけでコストです。サービスの進化のために、どこが重要な変更点で、どこは維持できるのかを見極め、変更コストを最小化することで、システムへの影響を減らせました。

3つ目に、シンプルにすることで、大規模なスケールのシステム・サービスを進化させられるようになること。複雑というだけで新しいことを取り組むのは困難になり、システムはより老朽化していきます。この状況を一つひとつ解きほぐし、システムを明快にすることで、新しい技術の導入や使いやすくするツールの開発コストの削減など、さまざまなメリットが生まれます。

3つ目に関して、我々が次に挑むべきチャレンジを紹介します。まずはデータデモクラシー、データの民主化です。先ほど挙げたIU Webをより進化させ、現在のIUが持つデータのセキュリティレベルを適切に管理しながら、データ活用を促進していこうとしています。その中でもApache Atlasを導入し、データリネージュを提供することで、より自動的にデータ間の依存関係や、権限の委譲などが効率化できればと考えています。

また、MLインフラとしても進化しようとしています。Icebergなどを用いたデルタテーブルを導入することで、データ生成から利活用までのスピードを上げ、サービス連携のパフォーマンスを高める計画を持っています。また、キャパシティプランニングをより大規模に行い、さまざまな分野で機械学習を行なっても十分なパフォーマンスが出るようなインフラにしていこうと考えています。

この挑戦を共に挑んでIUをより良いものにしたい、LINEのデータドリブンを加速したい、という熱意を持つエンジニアを我々は募集しています。それでは本セッションを終了いたします。長い時間、ご清聴ありがとうございました。