2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「 DEVDAY21 +Interview 」では、発表内容をさらに深堀りし、発表では触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「分断されてしまったデータを2000台を超えるひとつのデータプラットフォームに統合した話」です。
LINEでは現在、200ペタバイトを超えるデータ分析基盤を運用しています。このデータプラットフォームはInformation Universe（以下、IU）と呼ばれており、LINEで扱うすべてのデータを蓄積し、さまざまなサービスで適切かつ効果的に利活用することを目指しています。
IUの登場前は、それぞれの組織が個別のHadoopクラスタを運用していました。その体制下では、データのやり取りの複雑性やマシンリソースの非効率性、データ管理ポリシー・技術スタックの違いなど、データを利活用するうえで大きな課題があったのです。
この問題を解決するために、適切に権限管理を行い、かつLINE全社員がひとつの環境でデータ分析できるように複数のHadoopクラスタを統合するプロジェクトが発足しました。既存サービスに影響を与えることなくデータ分析基盤をIUへと移行するためにとったアプローチを、Data Engineering1チーム マネージャーの奥田輔が解説します。
プラットフォーム統合に伴い、発生した複数の課題
――まずはData Engineering1チームの役割と奥田さんの業務内容を教えてください。
Data Engineering1チームは、LINEのデータプラットフォームにおける根幹的なエンジニアリングワークを担当しています。具体的には以下のような業務です。
- オンプレミス環境のHadoopやElasticsearchのパフォーマンス向上やアーキテクチャ改善
- LINE内のさまざまなサービスからのデータ流入を実施できる、スケールアウトが容易なデータパイプラインの開発
- 非エンジニアでも簡単にデータ分析が行えるBIツールの開発・導入
- 適切なデータガバナンス体制を保つための監査・セキュリティ機能の検証・導入 など
このチームで私はエンジニアリングマネージャーとして、さまざまなコンポーネントの改善提案や意思決定、人的リソースの最適化などを行っています。
――LINEのデータプラットフォームIUができた経緯をご説明ください。
IUができる前は、LINE社内にDatachainとDatalakeという2つの大きなクラスタが存在していました。もともと、Datachainはメッセージ本体のデータ蓄積基盤として、DatalakeはLINEの様々なファミリーサービスを含めたより高度なデータ分析基盤として誕生し、それぞれの役割も運用する組織も異なっていました。
しかし、DatachainやDatalakeのクラスタを利用する人やチームが増えるにつれて、もともと想定していなかった使い方をされるケースが出てきました。両方のクラスタにあるデータ同士を結合したい、ある時間帯に一方のクラスタが高負荷になるためもう一方のクラスタを使いたいなどのニーズが生じてきたのです。その結果、LINEのデータ分析におけるデータフローや業務の流れがとても複雑になってしまいました。
大きく分けると3つの問題がありました。テーブルカタログを持つメタストア同士が分断されていることで、テーブルのジョインができないこと。YARNやPrestoをそれぞれの組織が別個で運用することにより、互いにコンピューティングリソースの共有ができないこと。データを保存するストレージの分断による権限管理の断裂があることです。
データの分断を解決するため、私たちは新しくひとつのクラスタを作成し、データを統合しようと考えました。しかし、極めて大規模なクラスタであるため、統合に際していくつかの課題が見つかりました。
まず、どのようにデータをコピーするかという課題です。旧環境のDatachainやDatalakeでは、多くのユーザーがさまざまなデータを作成しています。何も配慮せずそれらのデータを一斉にコピーすると、データの依存関係が狂ってしまいますし、システムのトラブルが生じる可能性が高いです。
また、Hadoopクラスタ間でデータコピーを行うDistCpでは、データの規模が大きい場合に多くのYARNリソースを消費します。これにより、vCoresやメモリが過剰に浪費されるだけではなく、ネットワークトラフィックも増加します。最悪の場合、データプラットフォームに関係のないサービスにまで影響が及ぶ危険性があります。
また、移行する組織の順番も重要です。LINEでは分析ジョブやテーブル同士の依存関係が複雑であり、かつ組織間でのデータのやり取りも頻繁に行われています。そのため、あるシステムが依存しているデータを新しいデータプラットフォームに移行することで、システムが動かなくなる可能性も考えられます。
全組織とコミュニケーションをとりつつ移行プロジェクトを進める方法も提案されましたが、厳しいと判断しました。コミュニケーションコストが相当に高くなるうえ、プロジェクト計画の変更が容易ではありません。
また、移行プロジェクト初期の段階ではストリーミングジョブを分割し、新旧それぞれのデータプラットフォームにデータを書き込むDouble Writeの方式が提案されました。しかしこの方法を採用する場合、書き込みを行った両方のデータが必ず同一であるという整合性を満たす必要がありますが、その要件は非常にハードルが高いです。
何かのトラブルによりどちらか片方にデータが書き込まれなかった場合に、新旧データプラットフォームのいずれのデータが正しいのかを判断できません。これらの課題を解決できる、別のアプローチを考える必要が生じました。
データ分析基盤構築のアプローチ：技術編
――技術的アプローチとデータマネジメント的アプローチの両面から解決を図ったと伺っています。まずは技術的アプローチについてご説明ください。
実施した施策は大きく分けて3つあります。1つ目は、HDFSの機能のひとつであるフェデレーションの導入です。フェデレーションとは、ひとつのHDFSクライアントから複数のHDFSクラスタにアクセスを可能にする機能です。
こうすることでIUのHDFSクライアントから、IUだけではなく旧クラスタのDatachainやDatalakeにもアクセスできる状態になりました。この方法を採用することで、データのコピーやDouble Writeの必要がなくなります。これまでのディレクトリ構造や権限体系を維持できるだけではなく、移行途中のデータ重複を防ぎディスクリソースも効率化できます。
今回導入したのは論理フェデレーションであり、物理的に全てのクラスタは同じディスクを共有しています。これによりキャパシティプランニングが容易になりました。特にIUのHDFSにおいては、ViewFsを導入したことで透過的なクラスタ間アクセスが可能になっています。
2つ目は計算リソースの再配置です。具体的にはIDCレベルの再設計を伴う、HadoopとYARNクラスタの大規模な物理的移動を行いました。IU専用の新しいデータセンターを用意し、DatachainやDatalakeがあったデータセンターから新しいデータセンターへとサーバーを物理的に移動して再配置しました。この業務では、インフラチームや運送業者とともに何ヶ月にもわたるデコミッション・リコミッションの計画を立てて、サービス影響を極力抑えられるように計算リソースの調整を行いました。
3つ目はカタログの同期です。このタスクは非常に難易度が高く、最初はなかなか良い方法を発見できませんでした。旧クラスタとIUの両方に同じテーブル情報があった場合、それら複数クラスタにまたがるカタログアクセスを提供できるケースが非常に少なかったのです。複数クラスタにまたがるカタログアクセスは、当時はPrestoでは実現可能だったものの、HiveやSparkではまだ機能が実装されていない状態でした。
この課題を解決するため、私たちはメタストアのDDLイベントを一つひとつ旧クラスタからIUへと自動的に同期するシステムを開発することを考えました。私たちはこのシステムをMetastoreSyncerと呼んでいます。これらの施策のより詳細な情報は「LINE DEVELOPER DAY 2021」のセッションにて語っていますので、よろしければ動画も覧ください。
データ分析基盤構築のアプローチ：データマネジメント編
――次にデータマネジメント的アプローチについてもご説明ください。
どれほど優れたデータ分析基盤を構築しても、そのプラットフォームを利用するユーザーが新環境へと移行してくれなければプロジェクトは完了しません。私たちはデータマネジメント的アプローチを用いることで、移行にかかる負担をなるべく低減する方針にしました。
取り組んだこととして3つをピックアップします。1つ目は接続先の切り替えのみで完了することです。データ分析基盤を利用する方々が、旧クラスタとIUのそれぞれに接続しながらシステム移行をする方針を選ぶと、取り扱うデータの複雑性も高くなり整合性の担保が難しくなります。
そこで、接続先をIUに切り替えるだけで、ユーザーは旧環境と同じデータを参照できるような設計を用いました。HDFSフェデレーションを活用することにより、仮にデータが旧クラスタに存在していてもIU上のエンジンを通して閲覧できるようにしました。
2つ目は旧環境で用いていた権限をIUでもそのまま維持することです。新しいデータ分析基盤を構築する際に、権限申請をゼロからやり直す必要があったり、権限の移行に失敗したりといった事態は避けるべきです。私たちはこの課題を、HDFSフェデレーションとそれに伴う権限管理システムやRanger、LDAPの統合により解決しました。
3つ目はデータ分析基盤のステークホルダーを重要度・複雑度の観点で段階分けすることです。LINE社内ではさまざまな組織が自立的に動いています。そして、各組織のデータプラットフォームへの依存度や結合度、データ利活用のリテラシーや技術的なスキルはさまざまです。
そのため、全ての組織へ画一的にアナウンスやガイドするのではなく、重要度・複雑度を鑑みて、それぞれの組織にカスタマイズした移行手順を提示しました。より詳細な情報は、こちらもセッションで詳細をお話ししています。
問題発見・問題解決のスキルの重要性
――この事例での学びをふまえて、データ移行やデータ収集基盤構築のプロジェクトに携わる読者に伝えたいことはありますか？
私たちが扱うデータプラットフォーム上では、各サービス担当者がセルフサービスの形式でデータを運用します。そのため、各ステークホルダーが納得できるようなプランで、データ移行を実現することが重要です。どれほど意義のあるデータ分析基盤の移行だとしても、プラットフォームのユーザーからすると短期的に見れば負担が増えてしまいます。
だからこそ、各ステークホルダーにとってなるべく負荷の少ない方法を選択することや、ステークホルダーを適切に説得することが重要になります。この事例においては、必要があれば私たちが各組織の担当者と随時ミーティングやレクチャーを実施し、なるべく移行がスムーズに進むように段取りをしました。
――学びの多い事例でした。Data Engineering1チームの業務は難易度が高くも非常にやりがいの大きいものだと思いますが、どのようなタイプのエンジニアが活躍しやすいでしょうか？
問題発見・課題解決のスキルが非常に重要になります。IUでは2,000台を超えるHadoopクラスタを扱っており、それ以外にElasticsearchやKubernetesなども相当に規模の大きなものを扱っています。これほど膨大な規模では、少し調べたくらいでは原因がわからないような障害もよく発生します。原因究明のために、データベースやミドルウェアなどの深い部分を掘っていかなければならないケースもあります。つまり問題発見の力が求められます。
さらに具体的にどのような方法を用いることで改善に結びつくのか、複数プランがあるならばどういった策を選ぶのが最善の結果になるのかといった課題解決の力が必要になります。もちろん決して簡単な仕事ではありませんが、こうした業務に楽しさを見いだせる方にとっては、非常に挑戦する価値のある職場だと思います。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！
今回のインタビューと関連する募集ポジションはこちらです。