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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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