LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

低レイヤーの知識が求められる、挑みがいのある仕事。Developer向けプロダクト開発の魅力とは

LINEの技術組織が取り組んでいる・今後取り組む未解決課題を深堀りするインタビューシリーズ「Unresolved Tech Issue」、今回のテーマは「大規模なアクセスをハンドリングする Developer Productのプラットフォーム開発」プロジェクトです。

LINEは、一般ユーザー向けのプロダクトや店舗・事業者向けのプロダクトだけではなく、サードパーティーのエンジニア向けのプロダクトも提供しています。

それらのDeveloper向けプロダクトは利用数が急増し、大規模なアクセスに耐えうる設計・実装が求められています。また、すべてのエンジニアにとって利便性の高いシステムになるように、各種の機能をより使いやすく、わかりやすく改善していくことも重要です。

今回はDeveloper向けプロダクトのサーバーサイド開発を担う尾上良範に、取り組んでいるプロジェクトの内容や仕事の魅力について聞きました。

Developer向けならではの開発と運用

――LINEが提供するDeveloper向けプロダクトにはどのようなものがあるか、簡単に教えてください。

プロダクトは多岐にわたるのですが、いくつかピックアップしてお話しすると、まずユーザーがLINEアカウントで簡単にサイトやアプリにログインできる「LINEログイン」や、その機能をネイティブアプリに組み込むための各種SDKが挙げられます。

他にはLINEアプリのトークルーム内で動作するウェブアプリ「LINEミニアプリ」や、その開発をするためのプラットフォーム「LINE Front-end Framework(以下、LIFF)」、LINEのボットを構築するためのAPI群である「Messaging API」もあります。

加えて、Bluetooth LEに対応したIoTデバイスをLINEアプリ上で連携・操作できるプラットフォーム「LINE Things」、 LINEが提供するブロックチェーンサービス開発プラットフォームである「LINE Blockchain Developers」などもあります。私が業務で携わっているのは、「LINEログイン」と「LIFF」のサーバーサイドの設計・開発です。

――一般ユーザー向けのプロダクトや店舗・事業者向けのプロダクトと比較して、Developer向けのプロダクトは開発・運用において異なる点がありますか?

通常LINEのプロダクト開発では、プランナーやプロダクトマネージャーが仕様を決め、その内容をもとにエンジニアが設計・実装を進めるケースが多いです。一方Developer向けプロダクトの場合は、そうした職種の方々も仕様策定に携わるものの、プロダクトの利用者自体がエンジニアであるため、私たちエンジニアが仕様についての意見を積極的に出し、その内容が反映されるケースが特に多いです。また、一度インターフェースを決めてしまうと非互換変更を入れることが難しいのも、Developer向けのプロダクトだからこその特徴です。

秒間あたり数十万のアクセスに耐えられる負荷制御機構の構築

―― Developer向けのプロダクトは、どれくらいの利用があるのでしょうか?

「LINEログイン」や「LIFF」は、平常時でも秒間あたり数千ほどのアクセスがあります。何か大規模なイベントや重要なニュースなどがあった際には、突発的に秒間あたり十数万ほどのアクセススパイクが発生することさえあります。

――とてつもない数値ですね。アクセス増加に耐えられるアーキテクチャにするために、現在はどのような仕組みを用いているのでしょうか?

基本的には、サーバーの台数を増やしてスケールアウトさせる構成をとっています。サーバーをなるべくスピーディーに増設できるように、セットアップの自動化も行っています。

現在、大部分のサーバーはVirtual Machineの技術を用いてスケールさせているのですが、今後はKubernetesを積極的に活用したいと考えています。そこで、一部のサーバーを社内のKubernetesクラスタに移行して動作検証をしています。試験して問題ないことがわかれば、各サーバーを順次Kubernetes環境に移行していくことを構想しています。

それ以外にも、特定サービスからのリクエストが多すぎる場合に、一部のリクエストを遮断する制御機構をアプリケーション内に実装しています。この仕組みは、サーバーサイドのサーブレットフィルターなどのモジュールに自前で実装をしています。

――制御機構にサードパーティー製のOSSなどを使わなかった理由はありますか?

制御機構の内部実装をなるべく自分たちで把握し、何かあった際に調査可能にしておきたかったのと、将来的に機構そのものを拡張できるようにと考えて、自作しました。

――そのシステムをさらに改善するための「動的な負荷制御機構」の詳細を教えてください。

現在の負荷制御は、閾値による判定を行うシンプルな機構になっています。サーバー負荷が上昇して閾値の条件を超過した場合に、自動的にそれ以上のリクエストを遮断するようになっています。閾値の設定値については、エンジニア自身が各種メトリクスを参照しながら臨機応変に調整することもあります。

この作業を定型化・自動化することで、業務プロセスの改善に取り組んでいます。さらに、将来的にはシンプルな閾値ベースではなく、より複雑な設定ができる負荷制御機構の開発や、サーバーのオートスケーリングの導入なども検討しています。

よりメンテナンスしやすいアーキテクチャや実装への大幅刷新

――現状のアーキテクチャや実装についてどのような課題があるのでしょうか?

現在のアーキテクチャでは、複数のコンポーネントが複雑に絡み合う構成になっていて、ここが開発効率低下の原因になっています。一例を挙げると、外部に提供しているAPIの一部では、Thrift固有のプロトコルでリクエストを受け付けている部分と、ピュアなHTTPのプロトコルでリクエストを受け付けている部分があります。

前者のリクエストが起点となっている処理のなかには、ロジックの実体が後者のWeb API側に存在しているものもあります。そのため、Thrift固有のプロトコルでリクエストを受け付けた後にWeb API側のコンポーネントで処理を行うのですが、このAPI内部でさらに別のAPIを呼び出さなければならないケースがあります。

異なるプロトコルでの、APIの相互呼び出しが発生している状態です。このような構造ですとメンテナンスもしづらいですし、何か障害が起きたときに原因特定も難しくなってしまいます。

――どのような歴史的経緯でそのような設計になったのでしょうか?

過去には、外部からのリクエストを受け付けるプロキシサーバーのルーティングの設定が、柔軟に行えない時代がありました。その制約の都合上、特定のThrift のAPIリクエストのみを特定サーバーに振り分けることができなかったため、このようになっています。しかし、現在は機能改善が行われてルーティングを柔軟に設定できるようになったため、APIの設計を変更してリクエストの流れをよりシンプルにしていきたいと考えています。

他には、マシンリソースをなるべく効率良く使うために、今後は Spring WebFluxとKotlin Coroutineの組み合わせやLINEが提供するOSSのArmeriaなどを活用して、一部のコンポーネントをノンブロッキングな実装にしていく予定で、実際に一部は書き換えが行われています。

通常、ノンブロッキングな処理を行うためのコードはどうしても記法が複雑になりやすく、かつアプリケーション全体に影響する致命的なバグが混入しやすいという課題があります。しかし、これらのライブラリを活用することで、ブロッキングなコードを書くときとほぼ同じようなコーディングスタイルで、ノンブロッキングなコードを実装できるようになりました。このリファクタリングがうまくいけば、サーバーのリソースを有効活用できるようになるため、高負荷対策にもつながります。

また、今回のインタビューでは詳しく解説しませんが、私たちの所属するDeveloper Product室では、Developer向けプロダクトを利用する方々のDeveloper Experienceの改善も行っています。詳しくは「アプリ利用者のUXまで見据えて開発体験向上を目指すLIFFチームの取り組み」というインタビュー記事で解説していますので、よかったらご覧ください。

――最後に、どのようなスキルやマインドを持ったエンジニアがDeveloper向けプロダクトの開発に向いているかを伺いたいです。

近年、アプリケーションエンジニアは各種のクラウドプラットフォーム上でサービスを開発・運用するケースが多くなっているため、インフラ・ミドルウェアなどのレイヤーの知識を学ぶ機会があまりありません。

しかし、私たちが扱っているプロダクトではそうしたレイヤーの知識を学ぶことが相当に重要になります。アプリケーションレイヤーだけではなく、インフラやミドルウェアのレイヤーにも興味がある方が、Developer向けプロダクトの開発には向いています。機能要件だけではなく、非機能要件にも気を配れる方ということですね。低レイヤーの技術を扱えるようになるとキャリアアップにもつながりますし、私自身も今後さらにそうした領域の知識を深めていきたいです。

また、私たちが担当するプロダクトはサードパーティーのエンジニアの方々が利用するものです。だからこそ「どのような仕様にすればエンジニアにとって使いやすくなるか」を徹底的に考え、積極的に意見を出せるような人が開発に向いていると思います。

――世の中のエンジニアを支えるプロダクトの開発は、やりがいが大きいですね。貴重なお話をありがとうございました!

私たちのチームでは一緒に課題に取り組む仲間を募集しています。