大規模なB2Bプロダクトを安定して稼働させるために　「LINE公式アカウント」や「LINE DMP」のSREとは

LINE公式アカウント・LINE DMPなどのSRE

長谷部良輔氏：それでは「LINE公式アカウント，LINE DMP等のSRE」というタイトルで発表いたします。よろしくお願いします。

最初に、私の自己紹介をします。開発4センターのOA Dev 2チームでマネージャーをしている長谷部と言います。主に、サーバーサイドエンジニアとして活動をしています。経歴で言うと、2013年の9月に、LINEに中途入社しました。当時はLINEのゲームプラットフォームのサーバーサイドの開発を担当していました。

その後、2016年の4月ぐらいに現在の部署に異動してきました。現在の部署に異動してからは、ここに書いてあるような各種サービスの新規開発を担当したり、運用を担当したりしていました。

最近で言うと、LINE公式アカウントのチャットシステムを開発・運用していたり、「LINEで予約」というサービスの開発を担当していたり、あとは「LINE スケジュール」というサービスがちょっと老朽化してきたので、全部書き直したりしていました。

最近の趣味で言うと、「愛犬と子どもと遊ぶ」とスライドに書いてありますが、もしかしたら子どもや犬の鳴き声が聞こえてくるかもしれませんが、ご了承ください。

今日話すアジェンダです。最初に開発4センターに関して紹介いたします。次に、開発4センター内におけるSREについて話をいたします。そして次に、開発4センターでSREに関連する直近の課題について話をします。そして最後に、こんな人が向いていそうだ、求めていますなど、そういった話をしようと思います。

開発4センターの紹介

それではまず、開発4センターに関する紹介です。開発4センターは主にB2B向けのプラットフォームや、プロダクトを開発する組織です。実際のプロダクトはこのあと簡単に紹介いたします。だいたいエンジニアの数が約70名ぐらいいます。この70名は、ほぼ全員サーバーサイドエンジニアです。

プロダクトを開発する時は、基本的に他の組織と協業する形式になります。例えば企画を行うチームやWebのフロントエンド開発を行うチーム、ネイティブアプリを開発するチームなど、LINEでは担当する領域ごとに組織が分かれていて、その組織同士で協業して仕事をする形式になっています。

開発4センター内の話でいうと、Official Account開発室と、Developer Product室、Ad Network & Performance室の3つに分かれています。

LINEのB2Bプロダクト

B2Bプロダクトというと、あまりプロダクトのイメージが付かないと思うので、代表的なプロダクトをいくつか紹介していきます。1つ目が「LINE公式アカウント」です。もしかしたら、すでにいくつかのLINE公式アカウントと友だちになっている方もいるかもしれません。LINE公式アカウントと友だちになっていると、定期的にメッセージが送られてくると思いますが、あのメッセージは、実はこういったWebサイト上から送られています。

中には、友だちの数が1億を超えるLINE公式アカウントとかもあります。このサイトでメッセージを送ると、1億のユーザーにババッとという感じでメッセージが送られています。それ以外にも、LINE公式アカウントにはけっこういろいろな機能がありまして、例えばユーザーと個別にチャットする機能や、クーポンを作成して配ったりする機能、お店のスタンプカードみたいな用途で使える機能など、いろいろあります。

2つ目が、「Talk Head View」と言われるプロダクトです。LINEを使っていたら見たことがあるかもしれませんが、こういったトークリストと言われる画面があって、この最上部に、広告などが表示されているのを見たことがある人もいると思います。ここにコンテンツを配信する仕組みを「Talk Head View」と呼んでいます。

広告だけだと人によってはウザがられちゃうかもしれませんが、天気や占い、ニュース、漫画の新刊情報など、そのユーザーが興味がありそうなコンテンツをレコメンドして表示するような仕組みも担っています。なので、用途は非常に多岐に渡っています。

このスクリーンショットだけだと、地味なプロダクトに見えますが、ここに表示するだけで一瞬にトラフィックがバーッと来たりするので、非常におもしろいプロダクトだと思います。

次が「DMP」と呼ばれるものです。広告に馴染みのある人だとご存知の人もいるかもしれません。ざっくりと言うと、LINEのプラットフォーム上で発生したデータやクライアントの企業がアップロードしたデータを、LINEのDMPと呼ばれる場所に溜め込んで保存していきます。そしてその溜め込んだデータを使って、ユーザーごとに最適化した広告を出せるようにする仕組みです。

あとは、広告以外にも、先ほど説明したLINE公式アカウントからメッセージを送信する時に、最適化のために使うこともあります。ここで言う最適化というのは、具体的にいうと例えば20代の男性と推定されるユーザーに対して広告を送ったり、LINE公式アカウントからメッセージを送ったり、そういったことを意味しています。

このDMPは、ストレージとしてはHBaseを使っていて、だいたい2,000億を超えるような件数のデータがこのHBaseに保存されています。

次が「LINEポイントクラブ」と言われるプロダクトです。このスクリーンショットを見るとイメージが湧くかもしれませんが、これですね。LINEスコアというサービスでスコア診断をすると5ポイントもらえますよ、みたいなやつです。ユーザーにはポイントというわかりやすいインセンティブをあげて、そのユーザーを企業のサービスに誘導できるプロダクトです。なので、ユーザーも企業もwin winになれてうれしいプロダクトとなっております。

次でプロダクトの紹介は最後となります。「LINEログイン」をもしかしたら使ったことがある人もいるかもしれませんが、いわゆるOAuth2/OIDCをベースとしたソーシャルログインの仕組みも提供しています。あとは、ちょっとこれと関連している仕組みではありますが、「LINEミニアプリ」も担当しています。これは初めて聞く人もいるかもしれませんが、簡単に言うと、LINEのアプリ上でWebアプリを作成するための仕組みです。

この仕組みは、社内に限らず社外にも一般提供しています。社内のわかりやすい事例で言うと、LINEアプリ上でニュースを見ることができると思いますが、そのニュースを見る時の仕組みにも、このミニアプリを使っています。なので、もしもこのLINEミニアプリの認証基盤やその周辺に障害が出てしまうと、社内と社外のあらゆるところでも障害が出てしまうので、そういった意味では非常に大事で、やりがいのあるプロダクトです。

LINE公式アカウントのシステム規模

次が、システムの規模です。開発4センターのプロダクト全体を合算するのは難しかったので、今日はLINE公式アカウントの場合で紹介いたします。だいたいリクエストのスループットで言うと、10万リクエスト/secを超えるぐらいですかね。使用しているCPUのコアの数でいうと4,500を超えるぐらい。メモリが14テラバイトで、サーバーの数ではだいたい600台ぐらい使っている規模です。あくまでこれはLINE公式アカウントのみなので、他のシステムとかも含めるともっと大きな規模になります。

あとはシステムだけじゃなくて、簡単に事業の規模についても紹介いたします。事業の規模って難しいのですが、今回は一番わかりやすいかなと思った売上収益を例に、紹介したいと思います。この資料は上場廃止前の2020年12月のIR資料からの引用なので、ちょっとだけ古い資料となっているのはご了承ください。

売上の割合ですが、この赤枠で囲ってある部分が開発4センターが携わっている領域です。なので、だいたい半分以上の会社の売上を担っているということで、非常に大事でやりがいのあるプロダクトを開発・運用しています。

開発4センターで使われる技術

開発4センターで主に使われる技術の一覧です。これは、先ほどの発表と被ってしまう部分もありますが、紹介いたします。言語としてはだいたいKotlinとJavaが使われることが多いです。最近は、既存のJavaコードもガシガシとKotlinに移植したりとかしているので、次第にどんどんKotlinが増えていくと思います。

フレームワークとしてはSpring Bootと、社内で開発しているArmeriaを使うことが多いです。管理画面を作ることも当然あるので、そういった領域ではJavaScriptやTypeScript、フレームワークとしてVue.jsなどを使うことが多いです。ミドルウェアは、だいぶざっくりとした括りで列挙していますが、だいたいデータベースとしてMySQLとHBaseが使われることが多いです。

キャッシュとしてはRedisが多いです。あとはメッセージキュー、イベントハブの役割としてKafkaを使うことが多いです。あとは検索システムやログを保存するのにElasticsearchを使っていて、コンフィグ管理でCentraldogmaなどを使っています。あとは、Web系の企業だと、一般的ですがNGINXやFluentdを使うことが多いです。

アプリケーション実行基盤でいうと、Verdaと呼ばれるプライベートクラウドがあって、そこで作ることができるVMとPMを使うことが多いです。一部のプロダクトだと、Kubernetesを使うことも増えてきました。あとはロギング、モニタリングとかでいうと、だいぶ一般的な感じにはなりますが、PrometheusとGrafanaとKibanaを使うことが多いです。

あとは社内でIMONと呼ばれるシステムがあり、そちらも使っています。その他ツールとしては、GitHub Enterpriseを使っていて、CIとしてJenkins、Drone、Circle CIなどを使っています。VMやPMを使っている場合は、プロビジョニングにAnsibleを使っています。Kubernetesを使っているプロダクトだとGitOpsをしているので、そのためにArgoCDを使っています。

開発4センターにおけるSRE

次に、開発4センターにおけるSREの話です。実は、これからSREを立ち上げようとしているので、現時点だと組織が存在しません。今でいうと、僕と一部のエンジニアでSREっぽい動きをしているという状況です。さきほど紹介したようなプロダクトのSREの立ち上げから参加したいという人には、おすすめかなと思っています。

役割としては、チーム横断的に各種プロダクトのReliabilityを横断的に向上するという役割を担ってほしいと思っています。具体的な例としては、障害の検知をしやすくする仕組み、ダッシュボードを作ったり。あとはもしも障害が起きているなら、それを解消するために動いたり、そもそもそれを予防するためにパフォーマンスチューニングを行ったり。

あとはモニタリング業務をしやすくするために、共通ライブラリとかツールの開発をしてもらいたいと思っています。他には、アプリケーションの運用負荷でけっこうコストに感じる部分があるので、そこを削減するために動いてもらうと。さらに、Developer Experienceと言うか、生産性を向上させるために各種ソフトウェアとかの開発もしてもらいたいと思っています。

なので、先ほど「3つの室がある」と言ったんですけど、SREはそれらを横断的に見ていくようなことを考えています。

直近の課題とやりたいこと

開発4センターのSREに関連して、直近の課題とやりたいことですね。先ほど説明したように、開発4センターは多くのプロダクトがあるのですが、プロダクトごとにログやモニタリングのやり方にバラつきがあるという問題点があります。バラつきだけで済むのならまだいいのですが、中にはそれがちゃんとできていないプロダクトもあるので、それは問題だなと思っていて、こういったことをやりたいなと思っています。

あとは現状、プロダクトごとにSLIやSLOがちゃんと策定されていないので、どうしてもプロダクトの運用がなぁなぁになっているなと感じているので、それをしっかりやっていきたいなと思っています。また、現状オンコール体制が整備されていないという問題があって、現時点だとアラートに気付いて動ける人が障害対応するというかたちになってしまっているので、あまり良くない状態だと考えています。ですので、その辺をちゃんと整備したいなと思っています。当然、SREだけがオンコールをやるというわけではないので、その辺はご安心ください。

あとは、現状多くのアプリケーションがプライベートクラウド上のVMで動いているのですが、そうするとサーバー増加が突発的にしにくかったり、そもそもその新規サーバー構築に時間がかかってしまうという問題があって、ちょうどプライベートクラウド上でマネージドのKubernetesが提供されるようになったので、そちらへの移行を進めたいなと思っています。

どういった人が向いているか・求めているか

最後に、どういった人が向いてそうでどういった人を求めているかについて話したいと思います。あくまで、ここに書いてあることは本当に理想論なので、全部満たしていなくても、問題ありません。スキル面で言うと、どうしてもJavaとKotlinを使ったアプリケーションが多いので、そういったアプリケーションの運用経験がある人だといいなと思っています。

あとは、ライブラリなどの開発ツールもガシガシ実装してもらうことを想定しているので、JavaかKotlinでガッツリとコードを書ける人がいいなと思っています。あとはSREチームの新規立ち上げとなりますので、リードをできる人が望ましいなと思っています。主体的に問題を発見して、問題を解決できる人がいいなと思っています。

次にマインドの面です。大きなトラフィックや大きな事業規模など、そういったプロダクトを支えたいという人に向いているのかなと思っています。けっこうコテコテの技術思考みたいな感じの人よりかは、わりとサービスを運用するのが好きな人が向いているのかなと思っています。あとは、トラブルシューティングが好きな人とかですかね。めげずにちゃんと最後までトラブルシューティングができる人です。

あとは、開発効率を上げるために、何か便利なツールを作って同僚のエンジニアに感謝されるのが好きな人がいいのかなと思っています。また、何でも自動化するのが好きな「自動化厨」みたいな人だとよいのかなと思っています。もしうちの組織に興味を持ってくれた人がいたら、ぜひ応募してくれるとうれしいなと思っています。

ご清聴ありがとうございました。