お使いのブラウザのバージョンのサポートが終了しました。最新のブラウザにアップデート、またはGoogle Chromeをお使い下さい。

LINE Digital Frontier 株式会社の中途採用/求人/転職情報

転職サイトGreen(グリーン)

Page top
Top img
LINE Digital Frontier 株式会社
Green Premium Interview
1日12億以上のリクエストを処理!
LINEマンガだからできる「SREエンジニア」の仕事

「LINEマンガ」は、スマートフォンやタブレットで気軽にマンガ作品が楽しめる電子コミックサービス。2013年に日本国内でサービスを開始し、現在約112万点以上の作品を配信。LINEマンガでしか読めないオリジナル作品や独占・先行配信作品も取り揃え、モバイルアプリ収益ランキング世界9位※にランクインするなど人気を博している。
※出展:2021年上半期 非ゲーム「世界モバイルアプリ」収益ランキング / SensorTower

人気サービスだけあって、「LINEマンガ」は1日12億リクエスト※と高いトラフィックを誇る。サービスの明暗を分ける “安定稼働”へ向けたエンジニアの戦いも、アツいものがある。「LINEマンガ」を運営するLINE Digital Frontier株式会社(以下LDF)では「SRE (Site Reliability Engineering)」の手法を導入し、サービスの安定稼働と品質改善に努めている。
※2022年6月時点

近年、大規模なサービスの現場で耳にする「SRE」とは、どんな手法なのか? LDFで「LINEマンガ」のバックエンド開発に携わるエンジニアに話を聞いた。

Matsuda1
開発Aチーム Senior Software Engineer
松田 一樹氏
京都大学、奈良先端科学技術大学院大学を卒業後、社内SEを経て、独立系ソフトウェアベンダで開発責任者を務める。17年にLINE株式会社へ入社し、LINE STORE、LINE 公式アカウント、LINE ショッピングなどの開発を経て、22年にLINE Digital Frontier株式会社へ転籍。現在はLINEマンガのバックエンド開発を務める。
Kyle1
開発Aチーム Software Engineer
トラウトナー・カイル氏
アメリカ出身。カーネギーメロン大学を卒業後、15年に楽天株式会社に入社し、楽天ブックスのバックエンド開発に携わる。19年に株式会社エイチームに転職し、ECサービスの開発や子会社のIncrements株式会社(現Qiita株式会社)にて転職サービスのバックエンド・フロントエンドの開発を担当。21年にLINE Digital Frontier株式会社へ入社し、LINEマンガのバックエンド開発に従事。

Index

1. 開発と運用をドッキング。純粋なエンジニアリングが楽しめる「SRE」
2. 高トラフィックに耐えるRedis Issueへの独自のアプローチ
3. エンジニア主導で問題解決。自由に提案・実行できる企業カルチャー

Cap1
開発と運用をドッキング。
純粋なエンジニアリングが楽しめる「SRE」

——「LINEマンガ」の運用に活用されている「SRE」とは、どんな開発・運用手法なのですか?

松田

SRE は Site Reliability Engineering の略で、インフラや運用の現場で発生する問題に、ソフトウェア工学を適用して、ソフトウェアエンジニア自身が解決していこうという問題の解決法です。またそのような業務に携わるエンジニア自体を指すこともあります。2000年代初頭に、Googleがこのやり方を開発し、現在では業界に広く取り入れられています。

2000年代までは、システム開発の世界では、開発と運用は別のチーム、場合によれば別の会社が担当することも多かったと思います。いかにも“モノづくり”といった華がある開発に比べて、運用業務は地味な作業が多く、どちらかというと出来上がったものを押しつけられる退屈な業務になってしまいがちでした。実際には運用が重要なことを、現場のエンジニアはみんな感じているにもかかわらずです。

カイル

2000年以前のIT業界は「to B向け」の業務システムが開発の主体で、納品がゴール。インフラやシステムの安定運用に関しては契約に含まれていませんでした。乱暴な言い方をしてしまうなら「安定性や使いやすさはお金にならない」ということです。SIの世界では今でも、開発と運用が明確に分かれていますよね。

一方、「LINEマンガ」のようなサービスは、作った物をユーザーに長く使ってもらい、そこから収益を得るビジネスモデルです。新しい機能の追加は、ゴールではなくスタート。その機能を24時間安定してユーザーに届けられるかが重要になります。

——開発エンジニアが、SRE に特化する魅力やメリットはありますか?

松田

機能開発とは別の視点から、ピュアなエンジニアリングを楽しむことができます。クライアントエンジニアやディレクターと一緒に開発するのも楽しいですが、その後の安定化・パフォーマンス改善はサービス内容に関係ない、純粋なエンジニアリングの世界です。それでいて、ユーザー体験に直結する仕事だから責任も重大で、売り上げを左右することもあります。エンジニアリングが価値を生む現場で働くのは、やりがいを感じます。

カイル

ダッシュボードでサービスのトラフィックを見える化しているため、サービスの成長を技術的な数値として捉えられるところも楽しさの一つです。グラフや数値を材料にボトルネックになっている箇所を見つけて、改善できればグラフが変化するのが一目瞭然。自分の仕事が数字で見えるのはおもしろいです。

松田

ログ・データ可視化には「Grafana」や Elasticsearch, Presto, 内製の Yanagishima等のツールを使っています。Grafana ではサーバーが受け取るリクエスト数・レスポンスにかかっている時間・CPUやメモリの利用率などを取得してリアルタイムに確認できるようにしています。見ているだけでも楽しいです。

SRE は実際にコードを書いてサービスの内部挙動を変えていきます。パフォーマンス計測のためのコードを追加することはもちろん、悪い部分がみつかれば実際のロジックも最適な形に書き換えていきます。SRE がパフォーマンス計測や改善のインフラを提供する事で、機能開発メンバーは新機能をシンプルに実現することに安心して取り組めます。

——どのような体制で、開発に取り組んでいるのですか?

カイル

サービス開発エンジニアはLDF所属ですが、インフラおよびそれを運営するメンバーはLDF含むLINE グループ全体で共通の体制となっています。複数のデータセンター上に多数のサーバーをもち、それをプライベートクラウドとして利用しています。大きな会社でありがちな稟議などを無しに、100台規模のサーバーの追加がいつでも可能です。ネットワーク・データベースには専門部署があり、物理レイヤーの設計やハードウェア選定など、サービス開発エンジニアがリソースとして使えるような状況を用意してくれます。サービスの運用で実際に発生するパフォーマンス上の問題に関しても、非常に専門的な知識をもっており、サービス開発エンジニアは、彼らと協力して一つのプロダクトを作り上げていきます。

松田

我々はデータベースとして、MySQLを使っています。MySQL について高度な知識を持った DBAはいますが、最低限基本的な知識は開発チームでももったうえで、より専門的な内容についてコンサルテーションやオペレーションを担当してもらいます。MySQLもクラウドプラットフォームを通じたセルフサービス化が構築されており、新規作成やレプリカ追加はサービス開発エンジニアが WebUI から操作します。一般的なテーブル設計や事前のindex作成についても、開発チームの責任で実施しています。

Cap2

Cap3

担当ライターから

業務システムとWeb/モバイルサービスの開発は、似て非なるものなのかもしれない。ウォーターフォールモデルで要件定義から設計、開発、テストまで、開発の全工程を事前にがっちりと組み上げる業務システムの開発に比べ、Web/モバイルサービスの開発はユーザーのフィードバックを反映させながらブラッシュアップを続けるアジャイルモデル。運用においても安定稼働させるだけではなく、処理速度も求められる。

LINEマンガのようなコンシューマー向けサービスの場合、たった3秒のロードタイムでもユーザーの離脱につながる。その意味では、日々の安定的な運用とパフォーマンスの継続的な改善こそビジネスの根幹を握っており、サービスのクオリティを決定する。SREの仕事こそ、実はサービス開発の“花形ポジション”なのではないだろうか。

高トラフィックに耐える
Redis Issueへの独自のアプローチ

——SREエンジニアとして働くなかで、高トラフィックサービスならではの楽しさや苦労はありますか?

松田

LDFのバックエンドチームでは、サーバーの負荷に関して、今まさに処理中のリクエスト数を「Inflight」と呼んで、最も注目すべき指標の1つに設定しています。LINEマンガでは、このInflightsがピーク時には1000を越えます。API のResponse Timeは平均すると100ms以下ですが、リクエスト数が膨大なので、ピーク時には1000個の処理を並行処理中ということになります。こういった高トラフィックを扱えることが LDF で SRE 業務を行う魅力だと思います。

カイル

華々しい開発のポジションに比べ、運用は地味なイメージがあるかもしれないですが、LINEマンガの場合、SRE はサービスを根底で支える重要な役割で、サービスのクオリティが手に取るようにわかります。新機能の開発は楽しいですが、エンジニアリングの観点からすると、そこまで難しいものではありません。作ったものをどれだけ速くできるか、これは非常に難易度が高い仕事です。

松田

SRE業界では、多くの代表的なMetricsがあります。4 Golden Signal、USE Metrics、RED Metricsなどです。しかし、実際にサービスを運用していると、どのMetricsを使っても結局項目が多すぎてなにを見ればよいのか解らない・伝えきれないという苦しさもありました。現在は「Inflights」をまず確認する KPI に置いています。SREというと「レイテンシ・Response Percentile」「QPS」それぞれを取得するケースが多く、特にレイテンシはユーザーの体験に直結する値として我々も重視しています。これらの指標はクールに見えるかもしれませんが、一方で直接サーバーの負荷や待ち時間の合計を示しません。

カイル

Inflights というのは、例えば「移動」について議論したいとき、「かかった時間」や「速度」ではなくて「距離」に着目するのと似ています。「リリース後から急に遅くなった」「夜間に負荷がシステムの許容値を超えた」といったケースでは「Inflights」が状況をストレートに反映します。

松田

次のキャリアとして、SREを念頭に置くエンジニアは多いと思います。SREを支えているのは「サービスは安定して使われてこそ意味がある」という価値観です。サービスの規模が小さい場合、たとえ安定したパフォーマンスでも多くのユーザーに使われていないならあまり意味を成さない。LINEマンガはユーザー数が多くて、SRE として楽しく働けると思います。

カイル

ユーザーから厳しいレビューを貰う事もありますが、エンジニアとしての技術力が問われていると思っています(笑)LINEマンガは、ピーク時にはAPI 呼び出し数が秒間3万を超えます。シンプルなベンチマークでは驚くような数字ではありませんが、LINEマンガの場合はこれが実際のサービスリクエスト数で、その中には1秒を超える処理時間が必要な呼び出しも含まれるため膨大な量です。

ーー問題を見逃さぬように、何か工夫していることはありますか。

松田

Metricsをもとにしたダッシュボードによるモニタリングや、その値が想定値を超えた場合の自動通知を実施しています。モニタリングの目的は2つあって、1つは、予想外のトラフィック増加やハードウェア故障といった外部起因の問題に気付けることです。基本的には、故障については自動的にサービスアウトされるように設計していますが、まれにパフォーマンスが低いままオンラインにとどまってしまうこともあります。いずれの場合においても、検出さえすれば対応はそんなに難しくはありません。もう1つが SREにとって非常にありがたいことなのですが、内部起因であるアプリケーションの性能的な不具合に早く気付けることです。

カイル

LINEマンガでは、毎週さまざまな機能改善がリリースされます。リリース前にコードレビューやCI、実際の Query の実行計画を本番DBで確認する作業を行っています。とはいえ、エラーは起こりうるものです。エラーを完全になくすよりも、エラーに早く気がついてリカバーする方がコストパフォーマンスにすぐれています。99%と100%の間には、大きなコストの差があります。それなら、99%のまま、1%の事態に備えた体制を構築する方が、ビジネスの現場では合理的でもあります。

ーーSREが主体となって、運用の課題解決をしている事例を教えてください。

松田

最近の事例として「Redis」を使ったキャッシュの Hot Key への対応をあげさせてください。Redisはメモリ上でデータを管理するKVSです。MySQL のようにデータを構造化して保存することはできない反面、シンプルな put/get に対して非常に高いパフォーマンスを発揮します。

カイル

Redisを使ったキャッシュは、中規模から大規模なサービスでよく活用されています。LINEマンガでもRedisを導入してサーバーのレスポンス速度を上げようとしましたが、ある特定のキーにアクセスが集中してしまうことで、Redisでも処理しきれなくなる事態に直面しました。Redisもデータベースと同じく分散処理すると高負荷を乗り切れますが、同じキーにアクセスが集中すると分散処理ができません。例えば、LINEマンガのアプリ内にあるコンテンツの人気順を表した「ランキング」。データの種類も1種類なので、誰がリクエストしても同じキー、同じ Redis インスタンスが処理を担当する事になります。

松田

アクセスが集中してしまうキーを「Hot Key」と呼んで、Redis ではこれは避けなければなりません。Hot Key が存在してしまうと Skew と呼ばれるリクエストの偏りが発生してしまい、アクセスが偏るということは、サーバーを追加してもサービスがスケールしなくなってしまうからです。

カイル

LINE マンガでも Skew により Redis の特定ノードが過負荷になり、サービスの全体障害に繋がるという事を何回か経験していました。
Redis は非常に性能が良いソフトウェアなので、中規模サイトであれば Skew があっても障害に繋がることは無いと思います。しかし、LINE マンガのような秒間数万リクエストの世界では、多数のサーバーで処理を分散するスケーラビリティが安定稼働の前提になります。Skew の発生はその前提を壊してしまいます。

松田

Skew は障害の原因にもなるわけですが、実はパフォーマンス改善の大きなヒントでもあります。なぜなら、Skew が発生しているということは多数のリクエストで同じ Key を必要としているということであり、Cache が効果的なデータであることを証明してくれているからです。

Cache が効果的な場面でも、リクエストが特定の項目に集中しすぎていると Redis だけでは負荷に耐えられないということがわかってきました。現在の私たちは、ローカルキャッシュとRedisキャッシュを両方使う二段構えの「ハイブリッドキャッシュ」を導入しています。ユーザーのリクエストに際して、まずはAPIサーバー内のローカルキャッシュで対応する。ローカルキャッシュに無ければ Redis に問い合わせ、そこにもデータがなかったときに始めて MySQL にアクセスします。

カイル

APIサーバーのローカルキャッシュは、有効期限が短くすぐに消えます。消えてもRedisキャッシュがあれば MySQL にアクセスしなくて済みます。ローカルキャッシュでも対応したことで、Redisキャッシュへの高負荷は改善されました。

松田

毎回 MySQL にアクセスしていたらサービスが成り立ちません。更に、 LINEマンガでは毎回 Redis にアクセスしても障害になることがあるとわかりました。現在、この部分は99% のケースで Redisにすらアクセスせずにユーザーからのリクエストに応えています。

Cap4

Cap5

担当ライターから

秒間3万リクエストのトラフィックをさばく経験は、LINEマンガならではだと思われる。しかも、無料で利用しているユーザーだけでなく、マンガを購入した課金ユーザーは、アプリケーション上でマンガを所有している身であり、サービスが重くなるとストレスを感じる。一般的なECサイトならアクセスが集中しても、ユーザーの購入が終わればあとは問題ない。LINEマンガの場合、マンガが売れれば売れるほど、その後もサイトにアクセスするユーザーが増えることになる。日々の運用を担当するエンジニアは、常にサービスの最適化を迫られる。

LDFでは、ローカルキャッシュでユーザーのリクエストに応えていた。アクセス数が増えたことで「Redis」を導入した。それでもリクエストが一部のデータに集中したため、ローカルキャッシュとRedisキャッシュを併用する「ハイブリッドキャッシュ」を編み出した。こうしてサイト運営の最適化を常に行って、サイトの安定稼働を維持するのが、SREの仕事なのだ。

エンジニア主導で問題解決。
自由に提案・実行できる企業カルチャー

——LDFのサーバーサイドエンジニアの組織はどんな体制になっていますか?

松田

社員とパートナーのエンジニアをあわせて、おおよそ30名ほどのチームで開発と運用を行っています。以前は、全員でワンチームとして動いていましたが、コミュニケーションがうまくいかず、現在は6人前後のサブチームを作って、コミュニケーションを活発にし、開発しています。

サーバーサイドのなかでも、カイルはアプリの新機能に関連した開発と実装を担当しています。私は、SRE業務やCS(カスタマーサポート)のイシュー、キャンペーンのオペレーションなどをもう一人のリーダーと共に担当しています。その他に商品マスタ関係のシステムの開発を担当するチームなどもあります。メンバーは一つのチームに所属しますが、本人の希望でチーム異動もできます。エンジニアにはいろんなことを経験してほしいです。

カイル

役割は異なっても、みんな同じサービスを開発している仲間。仕事を効率よく進めるためにチームを分けていますが、勉強会をひらくなどコミュニケーションはチームの垣根を越えて実施しています。開発の進行はアジャイルを基本としています。私が所属するサブチームは「スクラム開発」を取り入れています。開発チームがステークホルダーと一緒に機能開発の計画を定期的に見直すこと、開発チームが一丸となって計画を進めることを大事にしているためこの手法を選びました。

松田

私が所属するサブチームでも、アジャイルではありますが、業務の性質上、スクラムは合わなかったので廃止しました。「検索改善」「Redis利用方法の改善」「ローカル開発体験の改善」などの大きなテーマがあって、必要に応じてメンバー同士でディスカッションなどをしながら、最終的には各メンバーがオーナーシップをもってやっていくという形です。大学の研究室のような仕事の仕方をしていければと思っています。あえて分類するならアジャイルの中でもXPとよばれるものに近いと思います。属人化を避けるために、ある程度区切りが付いたタイミングでドキュメント化して、On-call体制に移行し、当番制にして、その日の担当者が確認する形にしたいです。

カイル

スクラムでも、そうでなくても、全体としてJIRAやConfluenceを使ったタスクの整理や情報共有が活発です。LDFのサーバーサイドエンジニアが所属する部署は、多様性のある組織で、検索技術が得意な人、クライアントアプリの開発からサーバーサイドに移ってきた人、アルゴリズムに興味がある人など、それぞれ得意な領域をもっています。サービスを開発・運用するには、この多様性が大事。開発を進めるに当たって、組織内に誰か詳しい人がいるのは強みだと思っています。

ーー大切にしているカルチャーや価値観は?

松田

自由に提案・実行できるカルチャーは大切にし、「怒られない障害報告会」「専門家を担当者とするさまざまな勉強会」などに取り組んでいます。

カイル

「怒られない障害報告会」は、いい取り組みですよね。

松田

この話をするとびっくりされることも多いんですよ。障害報告しても怒られないのはどういうこと? みたいな。

カイル

自由に提案・実行できるカルチャーは、実感しています。ダッシュボードによるモニタリング、Redisとローカルキャッシュを併用したハイブリッドキャッシュなど、どれもエンジニアの発案。やりたいことを提案すればチャレンジさせてくれる環境があります。

松田

エンジニアはオーナーシップをもって仕事に臨んでいます。ユーザー視点を大切にして、ユーザー体験の最大化を意識した動きを、会社は求めています。どんな方法で実現するかは、エンジニアに任せられているので、エンジニアはスキルを生かして働けます。SI業界の業務システム開発と大きく違うのは、上から降りてきた仕事を時間内に終える意識ではなく、自ら考えてベストなプロダクトを作り上げるマインドが必要な点です。

カイル

開発ももちろん好きですが、自分が4〜5年前から興味をもっているのは、開発手法やプロジェクトマネジメント。LINEマンガでは「開発」と「企画」のチーム間のコミュニケーションが非常に重要なので、複数のチームをまたいで新しい機能を実装できるとやりがいを感じます。

松田

プロダクトに興味があって、「エンジニアリングで改善したい」という思いをもっていれば、悪い結果にはならないと信じています。もちろん失敗することもあるでしょうが、次につなげられれば「経験」になります。失敗はマネジャーやリーダーが何とかすればいい話で、エンジニアには失敗を恐れずにどんどんチャレンジしてほしいと願っています。

Cap6

Cap7

担当ライターから

サービス開発・運用だけでなく、組織のビルドアップでも、トライ&エラーで作り上げるマインドを、LDFは持っている。30名規模のエンジニア組織になると、コミュニケーションをスムーズにするのが難しいが、サブチームに分けて密なコミュニケーションがとれるように工夫している。

自由に提案・実行できるカルチャーを大切にし「怒られない障害報告会」を開くなど、対人関係もロジカルに組み上げている点は、エンジニア組織ならではだと感じた。SREにチャレンジした人材でも、希望すれば機能開発などに携わることも可能。失敗を恐れず果敢にチャレンジする人材が成果を上げられる会社だといえるのだろう。

Cap8

474813

LINE Digital Frontier 株式会社資本金100百万円(2019年12月末時点)設立年月日2018年07月従業員数200人

電子コミックサービス「LINEマンガ」の開発・運営

この企業が募集している求人

474943
エンターテイメントで世界を熱狂させる|国内DL数4,000万突破「LINEマンガ」を更なるステージへと導くITインフラマネージャー募集
ITインフラマネージャー / LINEマンガ / LINE Digital Frontier

電子コミックサービス「LINEマンガ」を運営するLINE Digital Frontier株式会社でITインフラチームのマネージャーをお任せいたします。 「LINEマンガ」は、スマートフォンやタブレットで気軽にマンガ作品が楽しめる電子コミックサービスです。 2022年12月に国内アプリ累計ダウンロード数が4,000万を突破し、2013年のサービス開始以降、国内マンガアプリの累計ダウン...

474943
エンターテイメントで世界を熱狂させる|国内DL数4,000万突破「LINEマンガ」を更なるステージへと導くIT内部統制担当者募集
IT内部統制担当 / LINEマンガ / LINE Digital Frontier

電子コミックサービス「LINEマンガ」を運営するLINE Digital Frontier株式会社のJP Privacy&Securityチームで、日本地域における安定的なサービスの展開のために、ISMS(情報セキュリティマネジメントシステム)の構築・強化をはじめとする情報セキュリティ及び個人情報保護に関する様々な施策の展開や活動をご担当いただきます。 「LINEマンガ」は、スマートフ...

391573
【リモート可】バックエンドエンジニア|大規模toCサービスの開発!ボトムアップ・データドリブンな環境です
サーバーサイドエンジニア

■担当するサービス 電子コミックサービス「LINEマンガ」のサーバーサイド開発業務に携わっていただきます。 「LINEマンガ」は2013年にリリースされて以降、右肩上がりで成長してきました。  <直近の実績>  ・国内:アプリ消費支出ランキング2位(ゲームを除く/2022年度/出展:data.ai)  ・世界全体:アプリ消費支出ランキング8位(ゲームを除く/2022年度/出展:...

474943
エンターテイメントで世界を熱狂させる|国内DL数4,000万突破「LINEマンガ」を更なるステージへと導く海外配信担当募集
海外配信担当 / LINEマンガ / LINE Digital Frontier

当社は国内最大級の利用者数を抱える電子コミックサービス「LINEマンガ」を展開しております。 「LINEマンガ」は2013 年に国内でサービスを開始し、現在では国内マンガアプリ累計ダウンロード数で 1 位を記録するなど成長を続けています。 また、本サービスでは LINE マンガでしか読めないオリジナル作品や独占配信作品、先行配信作品を 1,500 タイトル以上取り揃えており、幅広い支持を...

ここで働いてみたいと思った方は
求人を見てみよう
×