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

——「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作成についても、開発チームの責任で実施しています。

——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にすらアクセスせずにユーザーからのリクエストに応えています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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