ヌーラボの松浦です。私がSREのエンジニアリングマネージャーとしてプロジェクトのサポートに携わっているプロジェクト管理ツールのBacklogは、2019年7月にJavaからScala / Play Frameworkに完全移行をしました。
このPlay化プロジェクトは、10年がかりで改良され仕様が明文化されていなかったBacklogを、JavaからScala / Play Frameworkに移行するという壮大なプロジェクトでした。
約4年にわたる「Backlog Playプロジェクト」(以下、Play化プロジェクト) で体験した“紆余曲折”を記録に残し、後のプロジェクトにつなげるために、今回から7回に渡って、技術的な挑戦やプロジェクト管理の視点など、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。
連載第1回目の本記事では、序章としてPlay化プロジェクトの概要と4年間の道のりをまとめた歴史、そして技術的な選定ポイントについてご紹介します。
目次
はじまり
Play化プロジェクトは、2019年7月にPlay Frameworkへの移行が無事に完了するまで、4年間の紆余曲折がありました。プロジェクトの頓挫や人的リソースの枯渇、チームの再編など、大規模なプロジェクトではつきもののと呼ばれるような障害が、Play化プロジェクトでも起きました。
その度に、チームで話し合い、他の部署や時には経営層を巻き込んで、障害を解決していき、見事にプロジェクトを完了させました。
私たちがプロジェクトで経験したこの“紆余曲折”は、以下のような人にもしかしたら役にたつかもしれません。
- Play Frameworkへの移行を悩んでいる人
- レガシーな技術をモダンな技術に変えるノウハウが必要な人
- 大規模なプロジェクトで人をどう巻き込んでいくか
そこで、今回から7回に渡って、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。
序章として、Play化プロジェクトの概要と4年間の道のりをまとめた歴史、そして技術的な選定ポイントをさっそく以下からお届けします。
Play化プロジェクトの目的〜我々はなぜここにいるのか〜
Play化プロジェクトの目的は「Backlogのサーバーサイドを進化させる“土台”を作る」というものです。Backlogを開発している社内メンバー（特にサーバーサイドメンバー）が開発しやすい環境を整えることで、Backlogの進化をより加速できると考えました。
Play化プロジェクトの半ばにつくられたインセプションデッキより
この目的を達成する上で、重要になるのは以下の3つでした。
- セキュリティの強化
- コードメンテナンス性の向上
- サービスの安定化
そして、これを実現するために私達は「Java/Seasar 2で書かれたBacklogのコードを、Scala/Play Frameworkで書かれたコードに置き換える」というアクションを選びました。
セキュリティの強化
Play Frameworkに移行する前にBacklogで使われていた、フレームワークのSeasar2は、2016年9月以降のメンテナンスリリースおよびサポートが終了することが発表されていました。そのため、フレームワークを乗り換えは必須でした。
また、同じくBacklogで使われていたライブラリのWebWorkはStruts 2に取り込まれており、WebWork単体での開発は止まっている状況でした。そのため、Struts 2に脆弱性が発見されたときには、BacklogのWebWorkでも再現するのか確認して、必要なら修正を行うという対応が必要でした。これらは、発生したらすぐに対応しなければならない上に、その対応にも時間がかかっていました。Struts 2の脆弱性は毎年何件も報告されていたので、今後も使い続けるのはコストが高いと判断しました。
コードメンテナンス性の向上
Backlogのコードは10年以上に及ぶ改変によって複雑化していました。
以前から、社内のBacklogチームからの要望として「コードのメンテナンス性を上げるために、コード上でしっかりと責務分割するように書き直したい」という要望があがっていたこともあり、今回のPlay移行ではこの点についても重要な要素として考えました。
サービスの安定化
10年以上続いたフレームワークと複雑なコードにより、発生原因のわからないエラーや、応答時間の悪化がたびたび発生していました。セキュリティの強化と、コードメンテナンス性の向上を進めると同時に、このような既存の問題を解決する取り組みも進めました。
Scala / Play Frameworkを選択した理由
Scala / Play Frameworkは利用者が多いフレームワークであり、現在もメンテナンスが行われています。また、それ以外にも以下の理由があり、Scala / Play Frameworkを選択しました。
- ScalaがJVM言語だから
- 既存のJavaコードを再利用することによって、移行作業を短縮できる可能性があった
- 既存のアプリと同様にJVM上で動作するので、今までの知見が活用できる
- 既にヌーラボ社内で、Typetalk (2013年7月にプレビューベータ公開) とBacklog API (2014年7月にScala / Play Frameworkで書かれたVersion 2が正式リリース) での利用実績があったから
- Backlog APIは再利用することを考慮して、Scala / Play Frameworkでコードが書かれていた
Play化プロジェクトの概要〜4年におよぶ移行の歴史〜
Play化プロジェクトの期間は、2015年11月から2019年7月までの約4年です。そして、プロジェクトに参加したメンバーは、2015年の時点の1名から、最終的には7名まで増えました。
Play化プロジェクトの変遷を1年ごとに振り返ろうと思いますが、その前にPlay化プロジェクトが複雑化した理由と技術的な進め方についてお話しします。
Play化プロジェクトの概要と仕様について
別のフレームワークからScala / Play Frameworkに移行するプロジェクトは、Backlog以外のサービスでも実践されています。他のプロジェクトと比較すると、BacklogのPlay化は4年と少々時間がかかっています。
その理由のひとつとしては、「Backlogが10年がかりで改良されたアプリケーションで、仕様が明文化されていない部分もあった」といった背景があります。仕様が決まった経緯はBacklog上に残っているのですが、細かい部分までわからないことも多く「コードが一番のドキュメント」となっている部分があったりしました。
そのため、Backlogの既存のJavaのコードを解読し、それを少しずつScala / Play Frameworkのコードに置き換えるというプロセスでコードの置き換え作業を進める必要がありました。
移行手順には、古いJavaのコードで動いているサーバと、新しいScalaのコードで動いているサーバの2つを用意して、Wikiやファイル共有といった、機能単位でURLのエンドポイントをNginxで切り換えていくという進め方を選択しました。
より詳しい情報は以前発表したプレゼンテーションスライドを参照ください。
Play Framework移行プロジェクトの歴史
Play化プロジェクトメンバーの変遷
2017年からのPlay化プロジェクトの機能単位の移行状況
■ 2015年
BacklogのPlay Frameworkへの移行作業が始まったのは、今を遡ること4年前の2015年の秋でした。
このころは、BacklogのUIリニューアルを実施する前で、8月にGitにプルリクエストの機能が追加されたという時期でした。
Play化プロジェクトは、Backlog APIのVersion 2を書いていたエンジニアの1人が、Backlog本体のコードを書き換えをしたことがきっかけで始まりました。
当初の見積もりでは、ざっくりと2016年9月にはすべての書き換えが完了することになっていました。
■ 2016年
しかし、Playチームでメンバーを増やそうとしたタイミングで、Backlog UIのリニューアルを優先させることになり、結局メンバーは増えないまま、当初のメンバーが1人でベースレイヤーの作成をしていました。
■ 2017年
この時期は、BacklogのUIリニューアルも落ち着き、Backlogの契約数自体も増えてきました。エンジニアの採用も強化され、それに伴いBacklogの全体のメンバーが増えていました。しかし、ヌーラボアカウント連携機能の開発が優先されたこともあり、Play化プロジェクトに人が増えたのは2017年の秋頃でした。
機能単位で移行をしていたPlay化プロジェクトは、Backlogのダッシュボードの移行が完了して、続いて、こちらも大きい移行となる、課題の詳細と追加機能を移行しようとしましたが、こちらは完了しないまま年を越えてしまいました。
■ 2018年
2017年に完了できなかった、課題関連の機能の移行がようやく完了します。さらに、4月には、Play化チームにSREが1名参加しました。チームのスキルセット的に足りていなかった部分を補ってもらう存在として、彼の参加はとても貴重でした。
そして、続いて、Git、ファイル、wiki、ガントチャートなどの機能も順調にPlay化が完了していきました。
■ 2019年
2019年に入ると、主要な機能の移行がほぼ完了してきました。プロジェクトの終わりも見え始めたところで、ある問題が起きました。検索インデックスの作成やWebhookの送信などを行うジョブ系の移行作業に着手した際に、事前の見積もりよりも必要な作業量が多い事が判明したのです。
このとき「スケジュールを伸ばすべきか否か」という議論が起きました。プロジェクト自体は7月完了の見通しでしたが「4月頃にプロジェクトを縮小させて、残りは細々と移行すればよいのではないか？」という意見もありましたが、最後までやりきるための算段がプロジェクトメンバーに見えていたため、人員を追加投入してやりきる判断をしました。
そして、7月に無事にジョブ系、契約周り、ログインを置き換えて移行を完了させることができました。
Play化プロジェクトの規模感について
プロジェクトのスケールについては、2015年12月時点でのソースでは、バックエンドにあたるJavaのクラス数2075（うちテストクラス700）、コード32万行（うちテストコード10万）でした。Play化プロジェクトはヌーラボ史上では大規模なプロジェクトでした。
おわりに
連載第1回目の記事は、BacklogにおけるScala / Play Frameworkへの移行プロジェクトの概要と歴史のご紹介でした。
これから毎週公開の予定で、このプロジェクトに携ったメンバーによる以下の記事をお届けします！
- 開発チームが大規模リプレイスを成功させるために取り組んだ “7つの取り組みと反省”
- Backlogのコードメンテナンス性を向上させるために気をつけたこと
- JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと
- SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか
- 大規模プロジェクトに途中参加して感じたこと
- 長期プロジェクトを効果的に “ふりかえる”ためにBacklogチームでやったこと
プロジェクトの反省と教訓から、技術的なノウハウを詰め込んだ記事まで、多種多様な視点でPlay化プロジェクトを振り返りますので、みなさんどうぞお楽しみに！
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com