体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

はてな粕谷氏が語る、安全なPlay Frameworkのバージョンアップのコツとは─by Scala福岡2017

なぜ、バージョンアップが必要なのか

ご存知の方も多いと思うが、サーバ管理・監視ツール「Mackerel」を直訳すると、「サバ」という意味。それをもじって名付けた。現在、粕谷氏は同ツール開発チームディレクターとして、開発メンバーをマネジメントしている。

株式会社はてな Mackerel開発チームディレクター 粕谷 大輔氏

現在、MackerelはPlay2.5.12で動作しているが、リリース時点ではバージョン2.3.1を採用していた。その後、2.3.7までマイナーアップデートは大きな問題もなく追随してきた。

しかし2.4のバージョンアップでは、成功したものの課題が残った。初期のバージョンアップや開発の様子について知りたい人は、ぜひ、ScalaMasturi2014で辻川貴哉氏が発表したスライド「Scala useCases at Hatena」を見てほしい。ちなみに辻川氏は、Mackerelのコードの1行目を書いた人物である。

なぜ、Pray Frameworkを2.4にする必要性があったのか。例えば粕谷氏が前職で担当していたソーシャルゲームなどであれば、長期間運用される予定がないソフトウェアに関しては、バージョンを固定化して安定運用を図ればよいと考える。

しかしMackerelはBtoBビジネス向けのサービス。10年後も当たり前のように動いていなければならない。2027年にMackerelが10年前の技術で動いていては、パッチが当たらなくなることで脆弱になったりするなど、サーバーサービスとして継続するリスクもある。

さらにPray2.3のWS(HTTPクライアント)に入っているデフォルト認証局情報が古くなり、Webhook通知の処理などに支障が出始めていた。WSだけを新しくするという方法もあるが、Mackerelはフルスタックなフレームワーク。一部のライブラリだけを載せ替えるより、全体をアップデートした方がよいと考えた。

Slickのアップデートに苦戦

これらの理由により、Play2.3から2.4へのアップデートをすることになったが、非常に大変だったという。まずコネクションプールをBooneCPからHikariCPに置き換えるには、細かい設定などのパラメータチューニングをやり直す必要があるからだ。

次に、Slick2.x→Silick3.xへのアップデート。DBIOという非同期ベースなクエリになる。特に大変だったのがSlick3.xへの移行である。Slick3.xは前述したように非同期がベース。MackerelはSlick2.xでブロッキングなクエリ処理をしていた。

それを非同期なものに置き換えていく必要がある。MackerelのSQLは数えたくないほどの数。それを普段の機能開発をしながら、すべて非同期の処理に置き換えていくのは難しい

なぜならそれは、Mackerelのサービスの提供ポリシーにかかわってくるからだ。Mackerelは毎週新機能をリリースすることにこだわっている。

定期リリースは火曜日と木曜日。年末年始とゴールデンウィーク、夏季休暇期間を除いて、156週連続リリース継続している。つまりこの毎週リリースを継続しながらフレームワークを更新することがミッションとなる。

まずは、Slickのアップデートに取り組むことになった。毎週リリースしながら、DBIOの置き換えができるのか。毎週の機能開発とコンフリクトしないようにするのは、どう考えても無理なのではないか。これがネックとなり、たびたびPlay2.4化にチャレンジするが、撤退を繰り返していたのである。

1 2 3次のページ
CodeIQ MAGAZINEの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。