2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
LINEのファミリーサービス サーバサイドエンジニアの仕事の進め方 (全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
堀内和也氏:みなさん、こんにちは。「LINE ファミリーサービス サーバサイドエンジニアの仕事の進め方」ということで、堀内がお話させていただきます。よろしくお願いします。
まず軽く自己紹介をさせていただきます。私は開発3センターのHチームに所属しております。現在はLINE LIVEというサービスのサーバー開発全般を担当しております。
LINEに来るまでのキャリアとしては、独立系SIerで、通信キャリアのサービスの開発や業務システムの開発をしていました。そこから、2015年11月にLINEに入社したので、そろそろ4年になる感じです。
本日のアジェンダです。まず、サーバサイドエンジニアの役割の全体像をお伝えします。次にサービス開発をする上で便利な、社内で共通しているサービスがあるので、そういったものもお伝えしつつ、詳しい開発スタイルの紹介という感じでいきます。次に技術スタックと作業環境をお伝えしまして、最後に採用のお話をさせていただきます。
まずはサーバサイドエンジニアの役割についてです。アプリはアプリエンジニア、WebページはUIT(User Interface × Technology)チームが主に作ってくれていますが、そういったところと協力してサービスを作っているので、連携するAPIをどう作るか、提供する情報を効率よく、高トラフィックが来てもちゃんと返せるように考えて作っています。
バックエンドの処理は、バッチ処理などのよくあるものです。非同期の処理に関しては、アプリからリクエストされて、処理してからレスポンスするのでは遅い場合が多々あったりするので、重い処理に関しては裏でキューを貯めておいて、先にレスポンスだけ返して裏で処理することになってきます。そういったところなどの設計と開発をしています。
次に、瞬間的な高トラフィックにどう耐えるかは常に考えています。人によってはすごくおもしろいところになるとは思うんですが、例えば、通知です。何かサービスに関する通知を送ると、それにユーザーが反応して一瞬でトラフィックが発生します。
あとはLINE LIVEの例で言いますと、超大型配信のときに、配信を開始したらユーザーが反応して見にくることもあります。そういった瞬間的なスパイクが起きたときに耐えられるかどうかを考えたりしています。ここらへんは問題が起きやすい部分なので、環境を常に整備したりしています。
あと、ほかのサービスとの連携です。ここに関してはサーバーの特徴的なところでもあります。例えば、LINE NEWSで災害や大きなニュースの速報を出すときに、LINE LIVEで流すニュースにもうまくリンクするように連携していたりします。
最後に、企画/QA/運用のサポートです。何か企画をするときにエンジニアリングとしてどうか、という観点での相談に乗っています。そもそも、その企画がいいか悪いかまで、エンジニアが入り込んで一緒に考えています。こういう感じで、柔軟に案件を進めたりしています。
運用のサポートに関しても、サービスが軌道に乗ってきたときに、運用はすごくつらくなっていきます。運用の稼働が高くなっていくわけですが、どこか非効率な部分をエンジニアがシステム化して、うまいこと運用を円滑にできないかを相談に乗ったり、こちらからヒアリングして改善しています。
そういったところでも主体的に動けたりするので、そういうことが好きな人もけっこう楽しいんじゃないかなと思います。
次に便利な社内共通サービスの説明です。まずお伝えしたいのがVerdaというプライベートクラウドです。例えば、みなさんもご存知だと思うんですが、簡単にサーバーを調達できるところですね。開発環境でも、リアル環境を使って自分で試したいときにも、サーバーを自由にちょっと調達して、動かして試したりできます。
例えば「ここがちょっと負荷が高くなるな」という予想がついてるのであれば、リアル環境でもすぐに、一時的にサーバーを増やせます。リアル環境で試して、それが過ぎ去ったら、また増やした分だけ返却できます。そういった柔軟なことがしやすい環境が非常に整っています。
そのほかは細かいことなんですが、オブジェクトストレージも社内のサービスとしてあります。「簡単にサムネイルの画像を登録して、それを出しておきたい」といったことですね。そういうことに対しても、クラウド上にアップして使えたり、ユーザーインターフェースに出したりできるように、簡単に作れるオブジェクトストレージもみんなで使っています。
財務処理や決済処理に関しては、Billing Serviceという社内サービスでとりまとめています。Billing Serviceで財務関係を取りまとめてくれているおかげで、サービス側はサービスを提供することに注力できます。
最後にLSSです。これは動画のエンコードやトランスコードをするシステムです。LSS側も常にブラッシュアップしていて、遅延の少ない動画配信ができるように常にレベルアップしています。ほかのサービスとの連携という意味でも、いろいろと便利になります。
次に詳細な開発スタイルです。まず大きなものとしては、基本的ですが案件対応です。これは企画がある程度主導になって企画されたものを、開発案件として開発側に共有されるものです。ただ、企画が企画しきってそこで開発するのかというと、そうではありません。企画の初期段階から技術的な部分で相談に乗ったり、「そもそも企画できるのか」というところも開発が入っていきます。
そのあと、仕様が決まったところで、スペックレビューもちゃんとしていきます。どのタイミングでも開発の人が入って、柔軟に開発していける環境になっています。
とはいえ、ある程度フローは決めているので、基本的には企画主導で進んでいます。リリース日までのスケジュールも、基本的にはしっかり決めています。そこに向けてマネジメントして開発していく感じのスタイルです。
続いて、継続的な環境整備です。サーバーに限った話ではないですが、「作ったからこれでいいじゃん」的な感じで放置しすぎて取り返しのつかない問題が起きないように、言語自体を変えるのはあんまりないんですが、ミドルウェアやフレームワークはどれがいいのか、今のアーキテクチャが今の仕様に適しているかを常に議論しています。あと、とくによくやるのは言語やミドルウェアのバージョンアップで、基本的にこういうことを積極的にやっています。
それ以外にも、SonarQubeを用いると潜在的なバグを教えてくれたりするので、それを潰していったり、やりすぎはちょっと注意なんですが、リファクタリングもしてコードをきれいにしたりもしています。
最後にサービスの運用改善をエンジニアが主導でやっていたりもします。
次に、調査と緊急対応です。サーバサイドに関わっている人は、ここらへんはご存知だと思います。例えば、瞬間的な高トラフィックが来るときは問題が起きやすいです。ある程度予想して対応していても、それ以上の何かが起きてしまうことも多々あります。
そういった場合に、なぜそれが起きたかを考えて分析して次に活かしたり、不意にインフラの障害……例えばさっき言ったプライベートクラウドで何か起きたときや、連携している周辺サービスで障害が発生したときに、自分たちのサービスがどれくらい影響を受けたかを調査しています。
そういった対応をすることで、知見が得られたりもします。そういったものに関しても、ちゃんとレポートを作成して、Confluenceというwikiを使って組織内で知見を共有しています。
詳細な開発サイクルなんですが、突拍子もないことはあまりしていないです。本当に基本的なことをしています。
まず、JIRAでのチケットの作成は「タスクの明確化」が目的です。忘れないように、基本的に何かやろうとしたものを残しておかないと、「そういえば、前にそんなこと言ってたな」みたいな感じで、だいたい忘れていたりします。忘れないように整理するために、まずチケットを作ります。
新規開発や新機能の追加など、大きく仕様が変わる部分は、基本的にまずアーキテクチャを考えるはずです。そういった細かい技術仕様はConfluenceにまとめて、それを知らない人や、あとから入ってきた人でもわかるように、ある程度まとめています。
アプリなどのフロントと連携するための仕様も全部wikiにまとめています。最近はwikiだけではなくて、詳細なAPI仕様に関してはSwaggerを使って自動生成して、それをアプリのメンバーに見てもらっています。
次に、開発にはGitHubを使っていまして、私たちの場合は、ブランチ作成して、プルリクエストを1回作っちゃいます。ここで、今は誰が何を開発しているのかがわかるようにしています。
そこからはもう開発に集中です。コードレビューをしてもらって、レビューで指摘があったらそれを修正して、マージ。そこから開発環境にデプロイするんですが、すごい優秀なQAエンジニアがいろいろなテストをしてくれます。本当に細かいところまで、バグを見つけてくれたりします。バグがあったらエンジニアが対応して、それをリリース日までずっとサイクルを繰り返してる感じですね。
最終的にできあがったものを、スケジュールに沿ってリアル環境にリリースする、という感じになります。
次に、技術スタックと作業環境です。まず技術ですが、基本的にはJavaとSpring Bootの組み合わせで作っています。
最近はKotlinが入ったり、一部サービスではPerlで動いていたりします。ほかにエンジニアの中でのちょっとしたツールを作りたいとか、そういったものに関しては好きな言語を使う感じのスタイルになっています。そこでPythonやGolangを使ったりします。
ストレージについては本当にこれも基本的なもので、MySQL、Redis、Elasticsearchですね。Elasticsearchに関しては基本、検索機能だとかランキングなどで使ったりします。
スパイクしそうなAPIに関しては、データをRedisにキャッシュしておきます。そういった基本的なことをしています。CIに関しては、基本はJenkinsですね。最近Droneも流行ってきているので、そこを導入する話が出たりもしています。
細かいところを言うと多くなっちゃうので、「その他」でまとめています。サーバー関係などはNginxやJettyなどです。非同期処理はKafkaを使って実現しています。新しいサービスではgRPCやkubernetesなどを導入する動きもあります。
続きまして、作業環境です。これもオーソドックスです。ある程度自由に選べるんですが、だいたいMacBook Proの15インチを選ぶ人が多いです。IDEはIntelliJですね。GitHubを使っていて、サーバーに関してはVerdaというプライベートクラウドを使っています。
コミュニケーションに関しては、基本的にはSlackです。ほかにLINEやLINE WORKSを使うんですが、遠距離のミーティングに関してはZoomやPolycomを使って、フェイストゥフェイスでできるようになっています。
ドキュメントに関してはConfluenceです。あとは、なにかドキュメントを共有するときにBOXを使っていたりします。タスクマネジメントはJIRAですね。このように、いろいろなツールを使って開発を進めています。
次におすすめというか、こんな人にとっておもしろいんじゃないかなというのが「大規模Webサービスに関わりたい」です。LINE自体のユーザーはご存知の通りすごく多いです。LINEユーザーが多いからといって、必然的に周辺サービスも多いとは限らないですが、サービスが成長すると高トラフィックになってくるので、そういったところでもエンジニアリングしていきたい人は、おもしろいんじゃないかなと思います。
開発スタイルはモダンだと思います。あとは、事業の立ち上げというと大げさかもしれないですけど、新しいサービスを作る話もよくありますので、そういった立ち上げから関わりたいという人もおもしろいと思います。裁量もしっかり与えられますし、うまく機能している会社だなと思っています。
我々の対象サービスはこの通りです。
採用情報ですが、だいたいサーバサイドとして6つぐらいある感じになります。興味を持った方はぜひ応募していただけるとうれしいです。どうもありがとうございました。
(会場拍手)
LINE株式会社
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗