LINE株式会社およびヤフー株式会社は、2022年11月17日・18日の2日間にわたり、技術カンファレンス「Tech-Verse 2022」をオンライン（ライブストリーミング形式）にて開催しました。特別連載企画「Tech-Verse 2022 アフターインタビュー」では、発表内容をさらに深掘りし、発表で触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「Flink@Data Platform - Ingestion Pipelineの再設計とオートスケーリング」です。
LINEのData Platform室では、Apache Flinkによるストリーミング処理パイプラインを開発・運用しています。本セッションでは、このパイプラインを高パフォーマンスかつ安定的に運用するために取り組んでいる2つのプロジェクトについて発表しました。
前半はKafka-to-Elasticsearchのパイプラインを、Kafka StreamsからFlinkに移行したプロジェクトの紹介。後半はFlinkによるストリーミング処理システムにおいてオートスケーリングを実現したプロジェクトの紹介でした。
今回はセッションの発表内容についての秘話を、LINEのIU Data Connect Teamに所属するSoftware Engineerの大須賀敦俊とData Engineerのフロックエルベにインタビューしました。
左：フロックエルベ 右：大須賀敦俊
Flinkは非常にバランスのとれたフレームワーク
――IU Data Connect Teamの担っている役割と、大須賀さん・エルベさんの業務内容を簡単に教えてください。
大須賀：IU Data Connect Teamの大須賀です。IU Data Connect Teamは、LINE社内のデータプラットフォームにおけるデータパイプラインを設計・開発・運用する仕事を担っています。私はKafkaからHDFSに、またはKafkaからElasticsearchにデータを受け渡すデータパイプラインを主に担当しています。
エルベ：IU Data Connect Teamのエルベです。私は主にKafkaからKafkaにデータを受け渡すデータパイプラインを担当しています。
――今回のインタビューでは、セッションで語られた内容の裏話を伺います。まずは前半パートの大須賀さんが話された内容について。大須賀さんは、Kafka-to-Elasticsearchのデータパイプラインで使用する技術を、Kafka StreamsからFlinkに移行したことを解説されていました。ストリーミング処理を行うフレームワークはFlink以外にも存在していますが、それらのフレームワークではなくFlinkを選ばれた理由は何ですか？
大須賀：質問の意図からズレてしまうかもしれないですが、まず前提としてIU Data Connect TeamがもともとFlinkを活用しており、その流れを踏襲してこのプロジェクトでもFlinkを導入したという経緯があります。Flinkを使っていて思うのは、非常にバランスのとれたフレームワークだということです。
ストリーミング処理系の他のフレームワークとしてはKafka StreamsのようにシンプルなKafkaの機能を使ってタスクをディストリビューションするものもありますが、Flinkはそこから一歩踏み込んで利便性を向上させており、かゆいところに手が届いている印象があります。Flinkに備わっている各種の仕組みを使うことで、データの流れそのものは大きく変えることなく、抽象化されたパイプラインを実装できることが特徴です。
エルベ：付け加えると、Flinkは他のフレームワークよりも使い方を習得しやすい印象があります。ドキュメントも整備されていますし、初心者でも比較的容易にFlinkを活用したアプリケーションを作れます。新しい人がチームに参画する際にも、オンボーディングしやすいです。
――Flinkを用いて構築したアーキテクチャにおいて、システムの可用性や耐障害性などを向上させるために設計面で工夫したことはありますか？
大須賀：データパイプラインにKubernetesを導入することで、何か障害が起きた場合でも自動修復できるようにしました。LINE社内にはKubernetesクラスタを管理している専門のチームが存在しており、彼らの提供するプラットフォームを活用することで、自分たちが運用に割く工数をなるべく軽減できるようにしました。
また、IU Data Connect Teamが構築しているパイプラインは数多くのトピックをコンシュームしてインデクシングするものなので、「どれくらいの粒度でジョブを切り分けるか」を考慮することが非常に重要になります。もしも特定のトピックの処理が遅延してしまうと他のトピックもそれにつられて遅延する事象が発生し得るため、ジョブの設計方針については、パイプライン構築時にメンバーと綿密に議論を重ねました。
継続的な運用改善の一環としてオートスケーリングを導入
――セッション後半ではエルベさんが、Flinkで構築されたストリーミング処理システムにオートスケーリングを導入したプロジェクトを紹介されていました。今回のタイミングでオートスケーリングの導入を決めた経緯を教えてください。
エルベ：IU Data Connect Teamはアーキテクチャや運用体制を改善し続けており、2021年にはシステムにCI/CDを導入するプロジェクトを推進しました。それによって運用はある程度楽になったものの、クラスタの台数をスケールアウトする運用は依然としてエンジニアが手作業で行っており、それなりの工数を割いていたんです。
その運用の負担を軽減するため、オートスケーリングを導入しました。また、ちょうどKafka-to-Kafkaのレプリケーションのために導入していたMirror MakerをFlinkに移行するタイミングでもあったため、それと同時にオートスケーリングを取り入れる方針になりました。
――セッション内では、リアクティブモードに対応していないクラスタにもオートスケールを適用させるため、社内で独自のソリューションを開発したというお話がありました。この仕組みを作るうえで設計面で工夫したことや、アイデアとしては挙がったものの採用しなかった案などはありますか？
エルベ：仮に、特定のKafkaパーティションにたくさんのデータがあり、かつ他のパーティションにほとんどデータがない場合、Flinkがその影響を受けてしまいうまく処理を進められないケースがあります。なるべくそうした事態を避けるため、オートスケール時のFlinkクラスタの台数を工夫しました。Kafkaのトピックはパーティションが偶数個であるため、それに合わせてFlinkクラスタがスケールするときにも必ず偶数個になるようにしています。
また他には、開発したオートスケールのソリューションにFlinkの再起動の機能を実装する案もありましたが、できるだけシステムの構造をシンプルに保ちたかったため、その案は採用しないことになりました。
――他に、セッション内では話さなかったもののプロジェクトで経験した印象深いエピソードはありますか？
大須賀：2つあります。実は、私が担当したKafka-to-ElasticsearchのパイプラインをKafka StreamsからFlinkに移行したプロジェクトでは、オートスケーリングの仕組みもこのプロジェクト内で実装しようと思っていました。ですが、エルベさんがちょうど同じ課題を感じていたため、オートスケーリングの実装をエルベさんに担当してもらうことで、チーム内で役割分担をして進めることができました。
もうひとつは、Elasticsearch側に負荷がかかっている場合にFlinkのリクエストの量を減らす仕組みを実装しようと思っていたのですが、いつの間にかその機能がFlinkのBase Implementationに入っていました。Flinkは開発が活発に進められているフレームワークであり、機能改善の速さを感じましたね。
エルベ：最近バージョンのFlinkが用いているKafkaコンシューマーとKafkaプロデューサーのライブラリは旧バージョンと異なっているのですが、実は現時点（取材時点）でそれらのライブラリに不具合があり、出力しているメトリクスの計算が誤っています。Flinkのオートスケーリングを実装した際に、その誤ったメトリクス情報を使ってしまい、思った通りの処理にならないことがありました。不具合があることを私たちが開発コミュニティに報告したため、今後リリースされる新しいバージョンのFlinkでは改善されるはずです。
大規模なデータを扱うからこそエンジニアとして成長できる
――IU Data Connect Teamにいるからこそ経験できたことはありますか？
エルベ：IU Data Connect Teamは大規模なデータをリアルタイムで処理するシステムを運用しており、もしも障害が発生すると何億レコードという規模の処理遅延が発生します。このような環境で働くことにより、有事の際にスピーディーに対応したり、システムの障害を起こさないような設計・実装をしたりといったスキルが身につきました。
大須賀：エルベさんの話されたことと重複しますが、IU Data Connect Teamは社内向けに大規模なデータパイプラインを、特にストリーミング処理を扱っていることが、データ分析周りに関心のあるエンジニアにとって面白いです。
それからチームが小規模であるため、ひとりのエンジニアが担当する業務領域の幅が広くなります。システムの設計・開発から運用までを、同じ人が担当することも多いです。自分の作ったシステムに責任を持って、ユーザーに使ってもらうところまで面倒を見ることができることに、私自身は面白さを感じています。
――他社ではなく、LINEでデータ分析業務に携わる醍醐味はどのような点にありますか？
大須賀：一般的なIT企業は外部のクラウドなどを使ってインフラを構築するケースが多いですが、LINEはインフラ周りから内製している珍しい会社です。そういった仕事に魅力を感じる方は、きっと楽しめると思います。
エルベ：LINEはデータ基盤の構築に力を入れている会社です。あらゆるデータを簡単に分析できる環境があり、それをビジネスに生かしています。これができる会社は、世の中にそれほど多くないはずです。
――最後に、大須賀さん・エルベさんのエンジニアとしての今後の目標を教えてください。
エルベ：私はシステムの異常検出など、運用関連の技術に興味があります。そこで、データ関連の運用において重要とされる“データオブザーバビリティ”という概念を、今後はIU Data Connect Teamに導入して、さらにシステムを改善したいです。
大須賀：データエンジニアリングは非常に進歩が早い領域であり、その専門家として活躍していくために今後も勉強を続けていきます。また、個人的にはデータ基盤を構築する技術に興味があります。たとえばApache Arrowなど、系統の異なるデータ分析システム間で、ローコストにデータのやり取りを行うための仕組みをLINEで導入するチャンスがあれば、ぜひプロジェクトに携わってみたいです。
――お二人が今後もさらに成長されることを楽しみにしています。今回はありがとうございました。
