• トップ
  • カイシャ・組織
  • LINE Fukuoka Engineer Job Talk~第3回「0→1と10→100、異なるフェーズのサーバーサイドが直面する課題とは」レポート~

LINE Fukuoka Engineer Job Talk~第3回「0→1と10→100、異なるフェーズのサーバーサイドが直面する課題とは」レポート~

LINE Fukuoka Engineer Job Talk~第3回「0→1と10→100、異なるフェーズのサーバーサイドが直面する課題とは」レポート~ サムネイル画像

【お知らせ】2023年10月1日にLINE Fukuoka株式会社からLINEヤフーコミュニケーションズ株式会社へ社名を変更しました。2023年9月30日以前の記事には旧社名で記載しています。

LINE Fukuokaでは、2月25日から3月25日までの毎週金曜ランチタイム(12~13時)に、「LINE Fukuoka Engineer Job Talk」というイベントを実施しました。
ここでは、第3回目となる「0→1と10→100、異なるフェーズのサーバーサイドが直面する課題とは」の模様をレポートします。

新田 洋平
LINE Fukuoka 開発センター 開発2室 室長
東京で化粧品クチコミの事業会社など複数のネットサービス事業会社での勤務を経験後に2012年3月に福岡へ転職しモバイルゲームの開発に従事。2014年 LINE Fukuokaへ入社。LINEバイトの立ち上げにバックエンドエンジニアとして参加し、2018年1月より開発組織のマネージャー。

森田 郷一
LINE Fukuoka 開発センター 開発Dチーム
2014年LINE Fukuoka入社のサーバーサイドエンジニア。Perl や Java のプロダクトを経て、現在はサーバーサイド Kotlin を用いた「LINEスキマニ」の開発を担当。同プロダクトをローンチするまでは開発チームのマネジメント、リードを行い、現在はIC (Individual Contributor: 非マネージャー職) として開発を行なっている。

平井 一史
LINE Fukuoka 開発センター 開発Kチーム マネージャー
メーカー系、ベンチャー系SIerで約10年間、WEBパッケージソフトの開発を経験。 2016年入社後、LINE STOREのサーバーサイドエンジニアを担当。現在はLINE STOREチームのマネージャーおよびLINE Shopチームのサーバー開発を担当。私生活では2児の父で、リモートワークで家族と過ごす時間が増加中。趣味は、ランニング、キックボクシングなど体を動かすこと。

 

イベントの冒頭で新田よりLINEおよびLINE Fukuokaについて説明し、
続いて森田より「0→1のフェーズで直面した2つの課題」と題したプレゼンテーションを実施しました。

001

画像1

森田

私の担当プロジェクト「LINEスキマニ」は、明日すぐに、あるいは数時間だけ働きたいという方に向けて、企業とユーザーの「スキマ」時間をマッチングする単発雇用サービスです。いわゆる「ギグワークサービス」と呼ばれる領域になります。従来LINEが提供していた数週間~数か月単位のアルバイト紹介サービスとは異なり、働きたいときにすぐに働けるといった世界観を目指し、20213月にサービス提供を開始しました。

 

002

 
画像1

森田

本サービスは、昨年リリースしたばかりであることに加え、ギグワークという新しい事業ドメインへの挑戦です。立ち上げに当たる「0→1フェーズ」において、「リードタイム短縮の課題」と、「技術的課題返済の課題」という2つの課題がありました。それらを解決するためにおこなった取り組みをいくつかご紹介します。

 

003

画像1

森田

「リードタイム短縮の課題」については、「はじめから完璧なものを作らない」ことを念頭に、機能検証の改善をおこないました。実装しなくても効果を確かめられるのであれば、手動で検証を実施しており、極力コストを払わない方針となっています。また、マイクロサービス・アーキテクチャやWebSocketなど、採用を見送った技術もあります。また、仕様がまだ7割の時点で開発者がレビューすることで、手戻りのリスク軽減や、企画書のクオリティ担保に繋がりました。

その他「担当者以外(2名)でのコードレビュー」についても品質担保を目的に実施しています。

 

004

画像1

森田

開発速度を優先することで、技術的負債が溜まっていくという課題もありました。例えばライブラリのバージョンが古くなる、パフォーマンスが悪化する、現状とマッチしないモデルになるといったものです。そこで我々は開発主導の定期的な「Kaizenリリース」を設けました。

 

005

画像1

森田

LINEスキマニでは、約2週間に1度のサイクルでリリースをおこなっています。このリリースにおいて、事業要件に対応するものを3回行った次のリリースを「Kaizenリリース」として、開発手動で内容を決めたリリースを実施しています。

このKaizenリリースを通して、ライブラリのバージョンアップやパフォーマンスの改善、開発効率の向上などを目的とした修正を行い、技術的負債を定期的に返済するようにしています。

 

 

続いて、「10→100のフェーズで直面した2つの課題」について平井が説明しました。

006

画像2-1

平井

私が担当している「LINE STORE」は、LINEの各デジタルアイテムを販売する公式オンラインストアです。スタンプや絵文字、着せかえの販売に加えて、LINEファミリーサービスや LINE GAMEで使用できる一次通貨の販売を行っています。また、サブスクリプションサービスに加入する際の導線にもなっています。

 

007

画像2-1

平井

本サービスでは、技術的課題と目標管理、2つの課題がありました。

「技術的課題」においては、成熟したサービス特有の複数の課題を抱えていました。コードやアーキテクチャの複雑化に加え、開発トレンドによる影響、また脆弱性発生に繋がるミドルウェアのバージョンアップなど、共感する方もいらっしゃると思います。

これらを解決するため「課題や技術的負債を、タスクとして事前に開発計画に組み込む」運用に切り替えました。機能追加などと同様に計画的に実施することで、課題や技術的負債に対応できるようになりました。当社ではチケット管理システムを用いて実施しています。また、改修前に「関連するコードのリファクタリング」もおこなっています。見通しが良くなり、修正漏れによるバグ発生なども防ぐことができるため、開発作業のクオリティ向上に繋がりました。

 

008

画像2-1

平井

新しいテクノロジーの導入も、技術的課題の解消に寄与しています。

こちらはテクノロジースタックの遷移です。10年前と比べると大きく変化していることが伝わるかと思います。特にミドルウェアについては、定期的にバージョンアップし、最新バージョンとの乖離が広がらないように心がけています。

 

009

画像2-1

平井

Armeria」は、LINEで開発しているオープンソースソフトウェアで、Non-blocking I/Oを採用し、多くのリクエストを効率的に捌けるマイクロサービス向けフレームワークです。導入によって、リクエストスパイクによる障害発生の防止や、マイクロサービスアーキテクチャ改善の効果がありました。

続いて「RxJava」。当社のサービスやプロダクトのコードには、レイテンシーを改善するために複数並行して処理する箇所が多数存在します。その可読性向上を目的として、導入しました。

三つ目の「Kafka」は、バックグラウンド処理信頼性向上のために導入しましたが、バックグラウンド処理のリトライや流量制御なども実現しています。

最後はLINEのプライベートクラウド「Verda」です。リソースの管理やサーバーのスケールアウトが非常に容易かつ高速になりました。

 

010

画像2-1

平井

SeleniumAppiumを使ったE2EEnd to End)テストの自動化にも取り組みました。E2Eテスト自体はデイリーで実行しており、テストに失敗した場合は自動で開発者やテストチームに通知し、調査する運用をおこなっています。自動化テストの導入は、テスト工数の削減やリリースサイクルの高速化に大きく貢献しています。

従来、共通ロジックの変更やミドルウェアのバージョンアップなど、サービス全体に影響を及ぼす変更が発生した際は、それなりのリソースを費やしてマニュアルテストを導入していました。テスト自動化により、次の日に結果を確認するだけで完結するようになりました。

 

011

画像2-1

平井

最後に「目標管理」の課題について。

本サービスのように運用期間が長くなると、ローンチ当初に掲げていたビジョンやミッションがメンバーに浸透しなくなります。そうすると、目指す方向が分からず、無難かつ曖昧な目標を設定するケースもあります。実際、あるチームにおいて「売り上げは昨年と同水準で」という目標が設定されていました。

解決策として、LINE STOREプロジェクト全体で目標管理ツールOKRObjectives and Key Results)を導入しました。OKRを用いることで、チャレンジングな目標を設定/明確化できるようになりました。チームのモチベーションを維持しつつ、目標達成に向けて各メンバーが自律的に行動できる仕組み作りを目指しています。


Q&A

プレゼンテーションの後、参加者からさまざまな質問が寄せられました。そのうちのいくつかをご紹介します。

Q:業務で必要とされる技術について教えてください。

新田さん

新田

サーバーサイドで使われている技術として、主流となっているのはJavaKotlin2つの言語です。LINEではPerlで書かれたプロダクトもありますが、そのうちの1つである「LINE Creators Market」でKotlinへの置き換えプロジェクトが立ち上がるなど、徐々にJavaもしくはKotlinに統合している状況です。

Q:課題選考について、選択できる言語と選考のポイントを教えてください。

新田さん

新田

課題選考はコーディング試験を実施しています。「Codility」を用いて、当社が設定した課題を解いていただきます。プログラミング言語としては、JavaKotlinのほかにPerlPythonが選択可能です。選考のポイントは、アルゴリズムとして問題なく書かれているかをチェックしています。また、選択したプログラミング言語の特徴を捉えて、コードを書いていただくとよいと思います。

Q:ある程度トラフィックのあるサービスのデプロイメントはどのように進めるべきと考えていますか。

画像2-1

平井

私が担当しているあるサービスでは、平日のピークでおおよそ秒間50,000リクエストが発生します。サーバー台数は70台なので、1台あたり約700リクエスト/秒を処理している計算です。このサービスは仮想マシンで構成されており、インハウスで開発したツールを使ってアプリケーションのデプロイメントをおこなっています。デプロイメントをおこなうときは、カナリアデプロイやローリングデプロイを行い、サービス全体のパフォーマンスが著しく下がらないようにしています。

また、デプロイメント直後のサーバーにおいてレイテンシが大きくなる問題に対しても対策をしています。レイテンシが大きくなるのは、サーバーの再起動直後はローカルキャッシュがないこと、ミドルウェアやフレームワークの初期化処理がおこなわれるなどの理由があります。

そこでRedisを使ってローカルとリモートの両方でキャッシュレイヤーを持つようにしたり、新サーバーをサービスインする前に暖機運転をあらかじめおこなったりすることで、レイテンシの悪化を抑えています。またバックエンドAPIに関しては、起動直後のサーバーへのリクエストは徐々に増やす、スロースタートという実装をクライアント側でおこなっています。

Q:アサインされるプロジェクトは選択できますか。

新田さん

新田

サービスの開発状況や、ご本人のスキルや志向性を加味して配属を決定いたします。現状、多数のプロジェクトでサーバーサイドエンジニアの採用をおこなっており、幅広い選択肢があります。

Q:設計書はどの程度の粒度で作成していますか。

画像1

森田

私が関わっているプロダクトでは、設計書の粒度は機能単位になります。

元々設計書を書くことをチームとして強制しておらず、個人の裁量に任せていました。ただ、設計書が無いとコードレビューのタイミングで設計にもレビューが入ると手戻りが生じるほか、そもそもレビューがしづらいといった問題があり、設計書を書くようになりました。レビューをおこないやすいように、設計意図や思想が分かるように記述しています。

このほかにもさまざまな質問が寄せられ、それぞれの登壇者が回答していました。
本イベントは2月~3月にかけて全5回開催されたものです。
この後も各技術領域別のレポートを更新していきますので、是非ご覧いただけますと幸いです。
また、イベントやレポートを通じて興味をお持ちいただけた方は下記からご応募やカジュアル面談へのエントリーもお待ちしております!!

LINEヤフーコミュニケーションズ
公式SNS

ブログ記事更新のお知らせやLINEヤフーコミュニケーションズの最新情報を配信中!