【Team & Project】LINEのMessaging Server開発業務、Apache Kafkaプラットフォームの開発・運用をしているチームを紹介します

LINE Engineering2020-06-12

LINE Engineering Blog official account

LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。
今回は、LINEのMessaging Server開発業務、Apache Kafkaプラットフォームの開発・運用をしているチームについて紹介します。Z PartチームのWonpill Seo、井出真広、Javier Luca de Tena、河村勇人に話を聞きました。

―― まず、自己紹介をお願いします。

Wonpill：LINEのMessaging Server開発業務、Apache Kafkaプラットフォームの開発・運用を担当しているZ Partチームでマネージャーとして働いています。

井出：今所属しているZ Partでは、主にMessaging platformで利用しているRedisクラスタの運用やRedisを使ったサービスの開発を担当しています。また、LINEがOSSとして開発しているJavaのRPCフレームワーク「Armeria」の各種サービスへのインテグレーションとそのサポートもしています。

Javier：私はZ Part内のUnitの一つである、HBase Unitのテックリードとして働いています。Apache HBaseクラスタの開発を主に担当し、Messagingバックエンドに関連するビジネスロジックから保守・改善まで行なっています。Scalability、Transactional、Reliability issuesを解決することが好きです。

河村：私は2015年に新卒で入社して以降、LINE本体のServer開発業務を担当しているZ Partチームに所属しています。現在は、LINE全体に提供されているApache Kafkaプラットフォームの開発・運用を担当するチームのテックリードとして働いています。入社当初の数ヶ月間は、HBaseクラスタのオペレーションや自動化を担当していましたが、その後、LINEのサーバーアーキテクチャをApache Kafkaを使って改善するプロジェクトを始めました。そのプロジェクトを当初から継続して担当しています。Performance EngineeringとReliability Engineeringが好きです。

―― みなさんがLINEに入った理由、働くやりがいなどを教えてください。

Wonpill：前職の同僚が先にLINEに入社していたので、その方からの紹介がきっかけでLINEに入りました。

井出：5年前に新卒でエンジニアとして入社しました。入社前は、LINEのアプリを使ったことはほとんどありませんでしたが、私の家族や友達が使っていたので名前は知っていました。LINEは、「実世界でユーザに与えている影響が見える」というフィードバックがとても分かりやすく、利用者の数やサービスの複雑度やサービスのパフォーマンス・可用性・信頼性などに注力して開発できる環境がとても魅力的で、そういった環境が整っていることが入社の決め手になりました。

Javier：LINEでは、1日に数千万人のユーザと数十億のリクエストがある大規模開発に取り組むことが出来るので大変魅了的です。私たちが持っている課題はとても大きく、パフォーマンス・可用性・信頼性・大量のデータを扱うトランザクションの課題・悪用検知など、どれもとても重要です。そして、私たちと同様の取り組みをしている企業は、日本にはそれほど多くはありません。多くのユーザに使われるLINEを開発できることは、それだけモチベーションが上がります。また、LINEは私たちの取り組みに対する姿勢や、誰と一緒に仕事をするかなど、自由度がとても高いので魅力的ですね。

河村：私は、入社前の学生時代からLINE（当時のライブドア、入社直後にNHN Japanへ統合）のサービス開発でアルバイトをしていました。学生の頃は、ローレベルなコンテナ技術などの研究をしていたのですが、アルバイトではサービス開発を担当していたのでWeb系の技術に幅広く関わることが出来ました。数年間サービス開発を担当した後、バックエンドに寄った仕事をしたいと思っていました。LINE本体のバックエンドを開発しているメンバーに誘ってもらったのがきっかけで、新卒になるのと同じタイミングでZ Partに所属することになりました。LINEはグローバルな開発拠点があり、多種多様でレベルの高いエンジニアが働いているのでとても刺激的です。英語を使う機会も多く、良い意味で日本的ではない文化への期待が決め手となりました。

左上から時計回りにZ PartチームのマネージャーWonpill Seo、井出真広、Javier Luca de Tena、河村勇人

Wonpill：私たちが担当している開発業務は、多くの人の日常生活に影響を与えています。自分の仕事を通して世の中の人々に大きなインパクトや影響を与えることが出来るのは、大きなやりがいに繋がっています。

井出：私たちはサービスのパフォーマンスに対して、非常に注力してRedisを活用してきました。一方でRedisは、インメモリデータベースであるため、サーバプロセスが終了するとメモリ上のデータも消えてしまいます。データの保証に関しては多くの課題がありますが、より安全に安定的に運用できるようにHBaseなど他のpersistent storageへ移行するなど、私たちは日々色々なことに挑戦しています。そのような課題に対する挑戦が、今の私のやりがいになっていると思います。

Javier：私たちは、LINEのMessaging platformに大きな責任を持っています。LINE のMessagingバックエンドの既存機能、そして今後追加されるであろう機能の大部分のプライマリストレージを提供しています。LINEのストレージは毎日大量のトラフィックを受けているため、信頼性・可用性・パフォーマンスを向上させ、システムの攻撃者を排除しながら、一貫性を保つ必要があります。そして、Messaging platformのビジネスロジックにも深く関わっているので、コアロジックを改善しながら新機能のサポートや開発を行っています。このように私たちが担当する業務は、日本国内で取り組むことが出来るのは大変珍しくとても面白いですね。

河村：そうですね。日本国内で私たちと同様の環境で仕事ができる企業はほとんどないですね。私がやりがいに感じるポイントとしては、LINEの規模感もそうですが、より重要なのは「社会インフラ」になっているという点です。入社した当時はソーシャルゲーム系の会社が流行っていましたが、私はより直接的に多くの人たちの生活を豊かにしているサービスに関わりたいと思っていました。その点でLINEはユーザの生活や社会に大きな影響を与えることが出来ます。そして、多くのユーザはLINEを日常的なコミュニケーションインフラとしいて利用しているため、高い信頼性を保つための責任はとても大きいです。このような環境の中で適度なプレッシャーを感じながら、高いスケーラビリティと高い信頼性から生じる、様々な技術的挑戦に取り組めることは私にとって大きなやりがいです。

―― チームの構成・役割などについて教えてください。

Wonpill：LINEアプリのスタートとともに誕生したLINEのMessaging platformは、現在、日本と韓国のエンジニアによって開発が進められています。2011年にLINEがリリースされて以降、サービスの急成長に伴いメッセージやソーシャルグラフなど数十種類のユーザーデータが飛躍的に増え始めました。その結果、ストレージ層だけでも数千台単位でサーバー数が増え、運用コストだけでなく、定型化された解決策がないという問題があり、拡張性・信頼性・複雑性などの点で一般的ではない要件が急速に増え始めました。

Z Partチームは、これらの問題を根本的に集中して解決するために生まれました。私たちのチームは、5～6人を更に1つのグループとし、Messaging platformのストレージの中核となるRedis、HBase、そしてApache Kafkaプラットフォームの開発・運用と3つの技術領域に分けて構成されています。

Redis、HBaseのグループでは、その名の通りOSSサーバの運用だけでなく、各OSSを利用するための業務・アプリケーション層のコードも担当しています。企画段階から開発に関わっているのですが、LINEユーザからの膨大なトラフィックを考慮しつつ、他の開発チームとの連携によりユーザシナリオを把握しています。そして、それらに応じて最適なソリューションを見つけて実装しています。また、チームメンバー全員が各OSSのエキスパートとして日々新しい問題と戦い、チームとして蓄積された様々な問題解決の経験やベストプラクティスを積極的に共有し、様々なOSSに自ら直接パッチを当てることで貢献しているほか、社内での解決策をOSSとして公開しています。
LINEは、サービス開始時のプライベートメッセージとしての役割だけでなく、社内外の様々なサービスと連携し、商品や金融、災害などの情報をユーザーに迅速に提供する巨大なプラットフォームへと進化しています。このような変化に伴い、Z Partチームは優れた技術でユーザー体験を守り、向上させることに注力しています。

河村：私たちはApache Kafkaプラットフォームの開発・運用を担当しているのですが、当初は、「LINEのサーバアーキテクチャをApache Kafkaを使って改善する」という一つのプロジェクトとして始動しました。
そのプロジェクトで構築したモデルがとてもうまく機能したため、他のサービスやプロジェクトでも実践され始めました。そこですでに高い信頼性のKafkaクラスタを運用していた我々のチームに対して、そのインフラを使わせて欲しい、といった要望が集まり始め、我々のクラスタは自然にプラットフォームへと進化していきました。
LINEでApache Kafkaが使われ始めてまだ数年ですが、すでにLINEにおいて最もポピュラーなミドルウェアの1つになり、今では80を超えるサービスで利用されています。
私たちは、非常に大きなスケールのトラフィックを捌きながら高いサービスレベルを維持するために、日々多くの時間をリライアビリティエンジニアリングに費やしています。主に、SLOのビジュアライゼーション、オートメーション、アーキテクチャの提案、トラブルシューティングと、そこから発生する予防的なエンジニアリングに注力し、各サービスがクライアント側の設定なども含めて理想的な形でApache Kafkaプラットフォームを使えるように努めています。

―― チームメンバーを紹介してください。

Wonpill： Z Partチームは、様々な国の多種多様なエンジニアが集まっています。例えば、OpenJDKコミッターやJVMのスペシャリストとして、カンファレンスでの発表や雑誌記事の執筆などを積極的に行っている方がいます。Apache Kafkaプラットフォームの開発・運用のリードをしている河村は、Kafka summitや日本JavaユーザグループのカンファレンスでLINEのApache Kafkaクラスタや問題解決事例を紹介しています。また、Redis領域を担当する井出は、LINE DEVELOPER DAYなどの技術カンファレンスでLINEの技術を積極的にアピールしています。

―― 利用技術・開発環境について教えてください。

Wonpill：プログラミング言語としては、Javaをメインに使用していますが、技術的な適性を考慮してPython、C、Scala、Luaも使用しています。また、Spring、Thrift、Protocol BuffersなどのライブラリからAkka、Central-dogmaなどのフレームワークを使用しています。コアな技術セットは厳選して管理していますが、それ以外は技術適性や保守性を考慮して比較的自由に利用しています。

―― 今のチーム課題と解決に向けた取り組みについて教えてください。

井出：Redisの技術領域を担当する私たちは、これまでに開発してきたMessaging serviceの多くの部分でRedisをstorageとして利用しているため、persistent storage（HBase）への移行が必要不可欠と考えています。先ほどもお話ししましたが、Redisは、インメモリデータベースであるため、サーバプロセスが終了するとメモリ上のデータも消えてしまいます。その為、HBaseへ移行を進め、障害に強いサービスづくりを続けなければいけません。また、それに加えて、単にpersistent storageに移行するだけでなく、パフォーマンスを犠牲にしないで移行できる仕組みづくりが必要であると考えています。Redisは、約50個のクラスタで、10000を越えるインスタンスを5、6人という少ない人数で運用しています。また、多くの部分を手作業で運用しているため、ダウンタイムを少なくしたり、より高品質なRedisのサービスを安定的に提供する必要があります。このpersistent storage への移行と運用のコストの2つが私たちの大きな課題であると考えています。

役割としては、2020年に入ってから開発を主とする人、運用を主とする人の3:2の割合で分けて担当しています。完全に分けているわけではなくて、必要に応じてそれぞれ業務を担当するスタイルです。クラスタの分担に関しても基本的に担当は決まっているのですが、韓国側のオフィスメンバーとも連携しているので、日本と韓国で柔軟に対応しています。
運用のコストの課題に向けた取り組みとしては、私たちは自動化を進めることによって手作業で運用しているコストを削減し、開発面での課題により注力できるようにしたいと思っています。具体的には、内製のクラスタ管理のツールを使い、それにプラスアルファとしてDockerやAnsibleを使ってクラスタの管理を自動化する仕組みを現在開発しています。実際には一部運用もしていますが、継続的に開発を進めているところです

Javier：私たちはHBase Unitの開発・運用を担当しています。大きく分けて以下6つの分野について課題意識を持ち力を入れて取り組んでいます。

HBase storageへ移行
ユーザー設定を汎用的に保存・処理・同期する新サービスを構築
HBaseの新バージョンへの移行
コア機能を改善しながら、他のチームの新機能開発支援
コストを削減しながら、クラスタの改善
災害復旧計画の改善

まず1つ目は、Redisの技術領域を担当するグループが持っている課題と同様に、LINEのMessaging serviceのバックエンドのほとんどの機能をHBase storageへ移行しています。HBaseをプライマリストレージにするための紐付けについてはいくつかの課題があり、トラフィック量が多い中でRedisとHBaseとの整合性を保ち、トランザクションを考えていく必要性があります。しかしそれは非常に困難な為、Redisをキャッシュにしたり、HBaseへのアクセス方法を変えたりと、協力しながらアーキテクチャや論理的な変更を進めています。
2つ目は、ユーザ設定を汎用的に保存・処理・同期する新サービスを構築し、追加開発コストをかけずに新しい設定の追加を可能にしています。

3つ目は、HBaseの新バージョンへの移行です。これは新機能やパフォーマンス、コミュニティによるサポートを受けるための対応などの理由だけでなく、単一障害点などの旧バージョンの問題点を解決するためにも行われました。新バージョンへの移行中は、複数のストレージを制御して調整するシステムを設計し、潜在的な不整合を減らすなどの対応をしています。また新バージョンの評価をすることでオープンソースコミュニティへの貢献に繋げています。

4つ目は、コア機能を改善しながら、データベーススキーマの設計やクラスタの構築とチューニング、モニタリング、アプリケーションのビジネスロジックへの関与など、他のチームの新機能開発を支援する取り組みを行っています。チーム間で多くの調整が必要なため、コミュニケーションを円滑に取りながら進めています。
5つ目は、コストを削減しながら、クラスタの信頼性・可用性・パフォーマンスなどを改善し続けています。現在は、マシン障害後の復旧時間とディザスタリカバリクラスタのパフォーマンスの向上に注力しているほか、DevOpsや自動化ツールを改善し、コストを削減しています。6つ目は、災害復旧計画を改善し、将来に向けてよりマルチデータセンター指向のアーキテクチャを採用しています。これは、別のデータセンターへの切り替えを可能な限り迅速に行うために、システムを最適化しています。クラスタを最適化し、他のチームにリソースを使用させることで、データセンターをより有効に活用しようとしています。データセンターのトラフィックスイッチを回避するために、より積極的なディザスタリカバリ計画とマルチデータセンター指向のアプローチについて考え始めました。また、今後は新しいタイプのデータベースについても検討する予定です

河村：Apache Kafkaプラットフォームの開発・運用を担当する私たちの大きな課題は、Apache Kafkaのプラットフォーム自体の安定性や信頼性を向上させ、多くのサービスが最良な状態で使えるようにすることです。先ほどお話しした通り、私たちは一つのプロジェクトとして始動しました。最初は1サービスで使っていたプラットフォームを色々なサービスが利用するにあたり、流れるレコードの数やユーザ数はどんどん増えていきました。それに伴い最初に課題になったのは、Apache Kafkaのプラットフォーム自体の安定性や信頼性です。実際約2年前に大きな障害が発生し、プラットフォームに依存している色々なサービスが影響を受けてしまうことがありました。そこから去年一年は信頼性の向上に注力し、信頼線向上に向けた取り組みを徹底して行いました。昨年の詳しい取り組みの内容はLINE DEVELOPER DAY 2019で発表しています。

年間のクラスタのアベイラビリティに関しては、99.999パーセント、いわゆるFive Ninesという、世の中のクラウドサービスベンダーが出している値と比べても同じか、それ以上と言える安定性を達成しています。これは年間で累計のダウンタイムが5分未満であることを意味します。また、Kafkaクラスタの重要なAPIのレスポンスタイムについては、99パーセンタイルで40ms以下という非常に厳しい条件が設定されています。
昨年の取り組みを踏まえて、私たちの大きな課題である「Apache Kafkaのプラットフォーム自体の安定性や信頼性を向上させ、多くのサービスが最良な状態で使えるようにすること」に対する次の課題は、大きく分けて2つあります。

1つ目は、アグレッシブな自動化の推進によるオペレーショナルコストの削減です。これまでの取り組みにより高い信頼性自体は達成出来ましたが、そこにかけた人的コストを始め、現在も継続的にかけ続けている人的コストがかなり高いという課題があります。今後もユーザ数が増えていくことを想定すると、必然的にそこにかける人的コストは今と同じか、またはそれ以上になっていくことが予測されます。そのためには様々な作業を自動化し、自律的に動くプラットフォームに進化させていく必要があります。具体的には、マシンが故障したら私たちが手作業でマシンをサービスアウトしなくても、プラットフォームが自律的に故障したマシンをサービスから外し、他のマシンをレプリカでリストアする仕組みを作るなどです。現在、私たちが手作業でやっているような信頼性維持の仕組みを、機械によって自動的行い、完全に自立したプラットフォームにする為の開発を進めています。

2つ目は、LINE社内でApache Kafkaがかなり多く使われるようになり、高い信頼性のインフラとして存在することで様々なサービスの開発コストを減らし、安定性の向上に貢献できていますが、Apache Kafka自体はまだまだ新しい技術であり、それを使う側のサービスでベストな形で利用できてない場合があります。個別のケースごとに毎回私たちがサポートするのでは人的コストが高くなってしまうので、私たちは、内部向けのSDKの開発やクライアントライブラリ、Decatonなどの開発をしています。2020年4月に公開したDecatonは、多くの Kafka consumerフレームワークでは不可能な、単一のパーティションからconsumeレコードを並列に処理することを可能にするように設計されたKafka consumerフレームワークです。特にI/O処理の多いワークロードで高いスループットを実現できます。
既に、毎秒100万件以上のタスクを処理するLINE本体や、「Kafkaを利用したジョブキューライブラリ「Decaton」の活用事例」で紹介されているスマートチャンネルをはじめとした多くのサービスで使ってもらっていますが、さらに多くのサービスに適用して高効率なタスク処理が進むように、継続して機能開発をしていきたいと思っています。

―― 最後に、Z Partチームに興味を持ってくれた人にメッセージをお願いします。

Wonpill：個人を尊重し、その能力や強みを信じています。簡単なこと、当たり前のこと、チャレンジできない問題に飽きた方を歓迎します。

井出：私達のチームでは，数億人のユーザが利用する大規模分散システムの開発をすることができます。他のチーム、多拠点のメンバーと協業しながらシステムの可用性、信頼性、パフォーマンス改善などの課題に取り組むことに興味のある方は、ぜひ私達のチームに参加してください。

Javier：多くのユーザーやリクエストのある大規模プロジェクトに取り組む意欲のある方、分散システムで働き、スケーラビリティ、可用性、信頼性、トランザクションの問題などを克服するための難しいタスクを達成することに意欲がある方は、是非、私たちのチームに参加してください。私たちは、オープンソースコミュニティへの貢献も含め、そのプロセスに関わる全ての技術的な側面を意識して仕事をしています。国際的な文化がありますので、使用している技術や分散システムでの大きな経験は求めていませんが、新しいことを学び、日々自分自身を向上させることが好きな方を求めています。

河村：典型的なWebサービスの開発では体験できない、高トラフィックと高いサービスレベル要求の組み合わせから生じる高難易度の技術的挑戦、それに付随する大きな責任を体験できます。最初は分散ミドルウェアやReliability Engineeringの経験がなくても、学習のために時間を費やすことを尊重する文化があるので問題ありません。向上心のある人にオススメの環境です。日本でも有数の高レベル技術者が集まっている中で仕事ができますし、学べることがとても多いです。

Z Partチームではメンバーを募集しています。

分散ストレージリライアビリティエンジニア / LINE platform

サーバーサイドエンジニア / LINE platform

Blog

【Team & Project】LINEのMessaging Server開発業務、Apache Kafkaプラットフォームの 開発・運用をしているチームを紹介します