Hatena Engineer Seminar #17 にて発表しました。
発表内容をかいつまんで記事にも書いておきます。
Hatena::Let とは
はてラボ のサービスの一つ。
僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、
- ラボならではの挑戦的なサービス
- 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度
も含んでいます。
で、Hatena::Let は、現在は主に 
id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。
ソフトウェア式年遷宮とは
初出は 2013 年の 
id:kenjiskywalker によるもので、このときはインフラの B/G デプロイメントのことを指していた。*1
blog.kenjiskywalker.org
JAWS DAYS 2014 Immutable Infrastracture Track のパネルディスカッション で 
id:antipop によって紹介されて更に広まる。*2
Immutable Infrastracture の文脈のまま、クックパッドのサーバプロビジョニング事情 - クックパッド開発者ブログ や クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について - Speaker Deck でも語られていく。
この Cookpad TechConf 2016 での 
id:mirakui の発表では「作り直すことを前提にすることで長寿命化」というキーワードが出ている。2014 年に Martin Fowler が 犠牲的アーキテクチャ という名前を付けたものとも紐付いたのだろう。
id:takahashim の発表でも、犠牲的アーキテクチャ＝式年遷宮で技術の継承を行うのだとされている。
www.slideshare.net
2018 年、ソフトウェアを定期的に全て作り直すという拡大解釈が @edvakf により行われる。作り直せる規模にしておくというのは、マイクロサービスの流れとも合流しているんじゃないかな。
2020 年、
id:daiksy により、ブラックボックスになりかけている要素をリプレースする過程でドメイン知識を継承する、と意味が加えられる。
といった感じで、
- 定期的に一部、または全てをリプレースする
- リプレース時にモダンな技術にし、メンテナビリティを高める
- リプレースの過程で、ドメイン知識を継承し、チームのスキルを維持する
というのが「ソフトウェアの式年遷宮」なのだろう。
「はじめからやり直したい症候群」とは違い、難しいものを難しいと認めた上で、運用し続けられる体制を維持する、というのがポイントなのだと思う。
Hatena::Letの遷宮
サービスを引き継いだので、コードベースの隅々まで把握するために遷宮しました。
なんと次の Hatena Engineer Seminar ではコードベースの隅々まで把握する方法という話をするつもりです…… https://t.co/2SPlj5LtIp https://t.co/jWCneFEoje
— Takafumi ONAKA (@onk) November 13, 2021
サービスの全貌を我が物にするためには、
- システム構成を把握する
- データ構造を把握する
- エンドポイントを把握する
をやると良くて、*3
- インフラ移行 (EC2 -> ECS)
- ORM 移行 (MoCo -> ActiveRecord)
- routes/controller の移行 (Ridge -> Sinatra)
とそれぞれリプレースすることで実現した。
技術選定を ActiveRecord にしたのは DB リファクタリングのためで、狙い通りにリプレース後にリファクタリングすることができた。次はフロントのリプレースや機能開発をやっていく。
まとめ
サービスを引き継ぐ際に Perl から Ruby に全て書き換えた裏側にあった目論見、つまり仕様を完全に把握するための遷宮と、遷宮時の技術選定について話した。また、定期的に (＝式年) 遷宮する必要があることも示した。
