Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Yahoo!カレンダーがPHPからKotlinに技術移行し品質アップ! 成功の鍵とは?【デブサミ2018 関西】

【A-4】なぜYahoo!カレンダーはPHPからKotlinへ技術移行を進めるのか

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/10/23 14:00

 2000年にサービス提供を開始して以来、毎年成長を続けているYahoo!カレンダー。サービスや組織の成長に伴い、出てきた課題を解決するため、PHP製のサーバーサイドシステムを改修してきた。その結果、アプリケーションが細かく分割されすぎることで、修正コストが増加。サービス追加などへの対応も時間がかかるようになってしまった。そこでPHPからKotlinに技術移行を決断。Kotlinに移行したことで、品質や生産性も高まったという。この技術移行の概要についてヤフー IDサービス統括本部 PIM本部 サーバーサイドエンジニア(登壇当時)の岡田信夫氏が解説した。

目次
ヤフー株式会社 IDサービス統括本部 PIM本部 サーバーサイドエンジニアの岡田信夫氏
ヤフー株式会社 IDサービス統括本部 PIM本部 サーバーサイドエンジニア(登壇当時) 岡田信夫氏

「ユーザーのための時間」を増やすため技術移行を決意

 Yahoo! JAPANが提供するサービスの1つ「Yahoo!カレンダー」は、2000年にWebのサービスとして提供を開始。2005年、2012年、2014年、2016年と画面デザインの変更や機能追加などのリニューアルを繰り返してきた。一方、アプリは別プロダクトとして2015年にリリース。2017年にWeb版とアプリが統合した。「Yahoo!カレンダーアプリは累計800万ダウンロードを達成。月間アクティブユーザー数も昨年と比べると140%の成長を遂げるなど、年々成長を続けているサービス」だと岡田氏は説明する。

 サービス開始から18年。「これだけ長いと技術的な負債を抱えてしまう」と岡田氏。実際に、サーバーサイドでは次の課題を抱えていたという。第一に、アプリケーションが細かく分割されすぎて修正コストが高くついていたこと。「機能を1つ追加しようとすると、AとBとCも変更しなくてはならなくなり、どうしても工数が膨らんでしまう。なかなか新しい機能が提供できない状況に陥っていた」と岡田氏は明かす。

 第二にPHPのアプリでフレームワークを使っておらず、個別の実装が多かったこと。「年季の入ったコードも多く、コントローラーの動きが違うなどの問題があった」と話す。第三はスケールが簡単にできないこと。第四は運用面でのコストが増え続けることだ。「このままでは安定してユーザーに価値提供ができなくなるのでは、と考えるようになった」と岡田氏は話す。

 岡田氏が言う価値とは、プロダクト面で言えば圧倒的な簡単さや心地よさを指す。サーバーサイド面での価値とはユーザー体験を支えるスループットとレイテンシーが担保されること、およびユーザーが増えても安定して稼働することである。Yahoo!カレンダーサービスを提供する限り、「(予定が外に)漏れない、(予定が)消えない、止まらない」を守り切らねばならない。これらの課題を解決するため「改めて技術を再検討しようという流れになった」と岡田氏は振り返る。

 チーム全員が集まり、ゴールのセッティングを行った。その際に大事にしたことが2つある。まず技術移行は目的ではなく手段とすること。あくまでゴールはユーザーの時間を最大化することである。次に、チームで話し合い、自分たちの考えを言語化することだ。

 技術移行をする目的の第一は、システムのための作業時間を削減し、ユーザーのための時間を大きくすることである。第二に、場当たり的に対応することが多かったところを、少し長い目で考えられるようにすること。第三は前向きな選択ができるようにすること。つまり「もっと多くの人に価値提供を続けていくための戦略的選択ができるようにすること」が技術移行を進める理由だったと語る。

 どの技術に移行するべきかについては、組織の状況が関わってきた。2000年にサービスが開始された当初の拠点は東京のみ、3人でチームを組んで開発をしていた。現在は東京2カ所に加え、大阪、ベトナム・ホーチミンの計4カ所、20人でチームを組み開発を行っている。大きくなったのは組織だけではない。システムも拡大していた。そのため「過去の最適解が今の最適解ではなくなった」と岡田氏。また拠点が分かれていることや、メンバーが増えたことによって、自分が当たり前だと思っていることが他のメンバーに伝わっていないこともあったという。こういった状況下で一定のレベルを担保するためにも「言語やフレームワークなど、システム的な制約を設けたい、そしてインフラもより課題に合ったスケールしやすい環境に変えていきたい、という思いが高まった」と岡田氏は力強く語る。

 こういったポイントを踏まえ、現行の「OpenStack+Apache Traffic Server+PHP(一部Java)」といった構成から、インフラ部分をKubernetesやOSSのPaaS基盤であるCloud Foundryに、言語はKotlinに変えていくことに決めたのである。

現行の採用技術と移行後の技術
現行の採用技術と移行後の技術

  • LINEで送る
  • このエントリーをはてなブックマークに追加

修正履歴

  • 2018/10/26 11:06 2ページ目、「RBAC(ロールベースアクセス制御)システム」について情報を追記しました。

著者プロフィール

バックナンバー

連載:【デブサミ2018 関西】セッションレポート
All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5