2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
提供:LINE株式会社
リンクをコピー
記事をブックマーク
大原康平氏:「8年続くPerlプロダクトをKotlinに書き換えた話」と題して、開発4センターの大原が発表いたします。本日のアジェンダに入る前に、私について紹介いたします。大原といいます。新卒2018年入社です。現役でPerlやKotlinのコードを書いています。
アジェンダです。まず、今回Kotlinに書き換えたPerlプロダクトである「LINEポイントクラブ」について紹介します。そのあと、なぜPerlをKotlinに書き換えたのかを説明して、書き換え後のシステムオーバービューをお見せします。
そして、プロジェクトをどのように進行したのかについて簡単に紹介します。最後に、プロジェクト中に発生した難しさや知見、そして別言語に書き換えるメリットについて話します。
今日のこのセッションの話を最後まで聞くと、移行プロジェクトの全貌がわかります。新規サービスを開発している人は、自分は関係ないと感じるかもしれませんが、その今作っているシステムも必ず古くなります。なのでこのセッションは、システムを開発している人、全員に当てはまる話です。なので、よかったら聞いて行ってください。
まず今回、PerlからKotlinに書き換えたプロダクトである、LINEポイントクラブについて紹介します。
LINEポイントクラブは、LINEアプリのウォレットタブにあるポイントクラブアイコンをタップするとアクセスできます。「LINE Pay」での支払いやLINEの各種サービスで使える共通ポイントであるLINEポイントを貯められる、さまざまなミッションの提供や連携サービスでの利用を案内するポータルサービスです。LINEポイントクラブは、2013年6月に「LINE フリーコイン」としてサービスを開始しました。
LINEポイントクラブには、「貯めるタブ」と「使うタブ」があります。「貯めるタブ」では、ポイントを貯められます。動画を見たりアプリをインストールしたりすることでポイントが貯められます。
「使うタブ」では、ポイントを交換できます。例えば「LINE マンガ」のコインやMUSICクーポン、その他さまざまなものに交換できるので、ぜひ利用してください。
トラフィックについて話します。平均的には秒間700リクエスト、ピーク時には秒間1万5,000リクエスト、デイリーでは約5,700万リクエストといった感じになっています。ただしリクエスト数については、適当な期間を選んで出した値なので、画面で見せた数字よりも多い日や少ない日もあります。
Perl時代のサーバー側のシステム構成の図を簡略化した図です。上のほうがインターネットです。外からリクエストが来ると、ロードバランサーで受けて、「nginx」で「貯めるタブ」と「使うタブ」のアプリケーションへそれぞれプロキシします。「貯めるタブ」と「使うタブ」で別々のデータベースを持っており、それぞれのアプリケーションがコンテンツを返す構成です。
「貯めるタブ」がPerlで、「使うタブ」がKotlinで書かれています。なぜ言語が違うのかというと、「貯めるタブ」が2013年からサービス開始したのに対して、「使うタブ」は、2015年の4月からサービスを開始したという歴史があったためです。ちなみに、2015年4月にサービス開始した当初、使うタブはJavaで書かれていたのですが、2020年にKotlinに書き換えています。
言語が違う2つのアプリケーションを管理する大変さというのがあって、エンジニアリソースの配分や、「貯めるタブ」と「使うタブ」で同じ機能をそれぞれ開発する必要があるという大変さがありました。
このセッションでは、Perlプロダクトである「貯めるタブ」を書き換えた話がメインなので、「貯めるタブ側」についてもう少し説明します。
「貯めるタブ側」のシステムオーバービューを少し詳細にしたものがこちらです。1つずつ紹介していきます。
まず、media、admin、cv-workerというアプリケーションが「Amon2」というPerlのフレームワークで書かれています。
そして、HBase gatewayと書いているアプリケーションが、Kotlin/Javaで書かれていて「Spring Boot」というフレームワークを使っています。
ここで、「あれ? Perlプロダクトと言っていたのに、Java/Kotlinがすでにあるんじゃん」と感じた方がいると思います。これには歴史的な理由があって、PerlからHBaseを直接使えなかったということがありました。なので、PerlからHBase gatewayを使ってHBaseを操作していました。このHBaseの問題については、別言語に書き換えた理由を話すセクションでも触れます。
オーバービューに戻ります。図のMySQL for job queueの部分について話します。ユーザーが、「貯めるタブ」で動画を視聴するなどの、ポイントを獲得するための条件を達成すると、コンバージョンのデータをジョブキューにエンキューしていきます。ジョブキューはMySQLのテーブルに溜められていって、cv-workerが処理する構成でした。
最後に、ほかにもデータベースとしては、MySQLやキャッシュDBとして「Redis」や「Memcached」を使っていました。
ここから、PerlをなぜKotlinに書き換えたのかという話をします。そもそも、「なぜKotlinなのか?」という理由なのですが、その理由はシンプルで、会社でサーバーサイドの開発で最も使われている言語がJava/Kotlinだからです。隣のチームも、ほとんどJava/Kotlinで書いています。
同じ言語を選択すると、エンジニアリソースの配分や社内のエコシステムを使う上で、かなりのメリットがあります。それなのでJava/Kotlinを選びました。では、なぜJavaを選ばなかったのかというと、チームで開発しているほかのプロダクトと技術セットを合わせたかったから、という理由です。
PerlをKotlinに書き換えることに決めた理由を話します。まず、システムの構成が複雑化していました。これについては、Perlのシステムのオーバービューをお見せした時にも話したように、「貯めるタブ」と「使うタブ」が別言語で実装されていたり、PerlがHBaseを使うためのゲートウェイアプリケーションを管理する必要があったりしました。
2つ目に、8年間さまざまな機能が追加・変更・削除されたことにより、機能自体も複雑化していました。すでに使われていない機能もたくさんありました。
3つ目に、Perlエンジニアの少なさゆえ、いずれ開発続行が不可能になる未来が見えていました。
4つ目に、プロジェクト開始前の段階で、直近半年くらいは大きな変更はなさそうだったので、取り組むなら今だとなったわけです。これはポジティブな理由でした。
5つ目に、Perlのライブラリをメンテナンスする人口が減ってきていて、最近のミドルウェアに対するクライアントライブラリが豊富とは言えなくなってきています。例えばHBaseは、何年か前にPerlから使おうと挑戦したことがあって、クライアントライブラリが、当時よく動くものがなくてThriftを使って、HBaseを使おうとしたりとかいろいろ試したのですが、私たちが望むような動作をしませんでした。
そして結局、HBase gatewayアプリケーションをJavaやKotlinで実装しました。RedisクラスタもPerlからだとうまく扱えませんでした。
ここで補足なのですが、私はPerlは好きなので、Perlのことを悪く言うつもりはまったくありません。私たちのケースにおいて、当時望む結果が得られなかったということであって、時間が経った今試した場合や別のプロダクトで使う場合には、うまく動くかもしれません。
Kotlinに書き換えたあとのシステムオーバービューです。簡単に書くと、こんな感じになりました。順番に話していきます。まず、すべてのアプリケーションがSpring Boot(Kotlin)で実装されています。
右下のデータベースは、過去に使っていた「貯めるタブ」と「使うタブ」のデータベースをそのまま使っています。
新しくなった部分について話します。アプリケーション間の通信は、gRPCで行うようにしました。知っている人には釈迦に説法になってしまいますが、Protocol Buffersでデータをシリアライズして高速に通信できることと、IDLで定義したAPI仕様からクライアント側とサーバー側でそれぞれコードを生成してくれるのが便利です。
ポイントクラブの貯めるタブのデータは複雑で、データのサイズが大きいものもあるので、そういったデータをアプリケーション間でやり取りする時に苦しまずに済んだのは、かなりメリットに感じました。
次に「Kafka」をジョブキューとして導入しました。Perl時代はMySQLを使っていました。Kafkaを使うことによってスケーラビリティが上がったことと、自前のジョブキュー管理の実装が不要になったことと、別のコンシューマを追加して別の処理もできるようになったことがメリットです。
HBaseについて話します。Perl時代に使っていたHBase gatewayアプリケーションが不要になり、管理コストが減りました。coreやcv-workerといったアプリケーションから直接HBaseを操作できるようになりました。
adminアプリケーションについて説明します。adminアプリケーションは、「貯めるタブ」のデータをmedia DBに取り込みます。そして、「使うタブ」のデータもmedia DBに取り込みます。つまり、media DBが「貯めるタブ」と「使うタブ」のデータの違いを吸収するような層になっています。
その結果、mediaアプリケーションは、「貯めるタブ」と「使うタブ」の両方のコンテンツを返せるようになりました。そして、mediaアプリケーションは、今後「Kubernetes」などにすることを見据えて、Redisクラスタにのみ接続することで、スケーラビリティが高い状態にしています。
プロジェクトをどのように進めたのかという話に入っていきたいと思います。開発メンバーの構成を紹介します。6名のエンジニアで開発しました。3名がJava/Kotlinエンジニアで、3名がPerlエンジニア。Java/Kotlinエンジニアについては、Java/KotlinとSpring Bootの開発経験が豊富なメンバーです。Perl時代の「貯めるタブ」の仕様についてはあまり知らないです。
プロジェクトの初期は、Perlエンジニアも開発がスムーズに行えるように環境を整えてくれました。彼らなしではリメイクプロジェクトを完遂することは難しかったと思います。なので言語を書き換える時には、書き換え先の、今回で言うとKotlinのエンジニアが必要だということが認識できました。
Perlのエンジニアについては、「貯めるタブ」の仕様についてはおおよそ把握しています。プロジェクトの初期は、仕様を書くことを主に行っていました。
プロジェクト期間中のサービスの運営と企画について、どのような体制にしていたのか話します。
まず、旧システムには、新しい変更を加えないことを決定しました。変更があると、書き換え先のKotlinにも適用する必要があって、開発工数がかさみ、いつまで経っても書き換えが完了しないからです。これについては、プランナーや運用サイドのメンバーに理解してもらえたのが助かりました。
プロジェクト期間中、デイリーミーティングを開発側でやっていたのですが、プランナーにも参加してもらうことで、仕様の変更の決定を迅速にできたのでよかったです。
今回のプロジェクトのスケジュールは、ざっくりこのように進みました。まず、2021年、つまり今年の1月からプロジェクトがスタートしました。そして4月頃、coreアプリケーションの開発が完了しました。
coreアプリケーションというのは、先ほどお見せしたシステムオーバービューの真ん中上の、この緑のcoreの部分のことです。
スケジュールに戻りまして、8月にほかのアプリケーションの開発を完了しました。ほかのアプリケーションというのは、この緑のアプリケーションのことです。そして、8月から9月にかけて、インテグレーションとQAを行って、2021年9月27日にメイン部分をリリースしました。スケジュールについてはこのような感じでした。
(後半へつづく)
LINE株式会社
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには