はじめに

本投稿はRetty Advent Calendar 2021 Part1 17日目の記事です。

こんにちは、Rettyに21卒新卒として今年入社した@sntree_suzunoki です。GoとGraphQLが大好きなバックエンドエンジニアです。

先日、初めて焼き芋というジャンルのお店に行ったのですが、美味しすぎてたまげたので是非この記事を読んでいる方にも行っていただきたいと思っております鈴木です。 retty.me

GoConference 2021 Autumnで発表をしました

engineer.retty.me

私は、GoConference 2021 AutumnにLT枠で登壇させていただいて、Rettyのマイクロサービスで利用しているORMであるGORMのVersionを上げたことについて５分という短い枠の中でお話をしました。

gocon.jp

しかし、もうちょっとだけ載せたかったことがあったので本投稿で外伝として書かせていただきます。

もうちょっと載せたかったこと

LTの内容簡単なまとめ

LTで使用したスライドはこちらなので、詳しいことに関してはこちらをご覧ください。

speakerdeck.com

LTでは、GORMをUpdateする上で苦労した点と得たご褒美についてお話しました。

苦労した点

修正量が多い
PreparedStatementModeを利用するときの注意
既存の実装に苦しめられる

ご褒美

大幅なパフォーマンスアップ（取得遅延35%削減）

以降でこれに追加してお話ししたいことに触れたいと思います。

1. 最終的にどれぐらい効果が出たの？

LTを行った時には、取得遅延は35%ほど削減されたとしていますが、これはギリギリ最終リリースが間に合っていなかった結果でした。

f:id:rettydev:20211216111833p:plain — LT時の取得遅延削減

最終リリースを終えた後のグラフは以下になります。

取得遅延(下から50, 75, 90, 95パーセンタイル)
最終的な取得遅延グラフ
メモリ使用量
最終的なメモリ使用量グラフ

最終リリースを終えた頃にはLatencyは始める前の４割程度、メモリ使用量は始める前の７割程度で安定しました。
すごい！！GORM様様です！！

2. どうやって置き換えていったの？

まず、全体的な進め方として、影響が小さい順から段階的なリリースを行いました。「1. 最終的にどれぐらい効果が出たの？」に載せたグラフで階段状に変化している部分がリリースのタイミングにあたります。

段階的なリリースを行った理由は以下です

タスクとして持っていたわけではなくて、CIの待ち時間やレビュー待ち時間にちょこちょこ進める予定だった
下調べはしていて、時間がかかることは把握できていたので、親ブランチを作ってそこに入れていく作戦をとってしまうとコンフリクトの解消で心が折れそう
サービスの中核を担うマイクロサービスであるため、失敗した時のリスクはなるべく小さくしたい
どこで切っても独立して出せる修正であり、出せばその都度パフォーマンスは上がるので、その時の提供できる価値の最大化を考えるとため込む理由がない

以上の理由より、丁度いい粒度（検証のやりやすさやPRの読みやすさ、影響範囲が広すぎない）に区切って置き換え&リリースを進めていきました。

具体的な進め方に関しては、

既存のGORMに加えて新しいGORMをRepository層に注入するようにする。
go-sqlmockでDBをモックしたテストを書いて、ローカルで細かく確認しながらGORMを新しい方に置き換えていく。
レビューできる粒度でPRにまとめて都度本番にリリースしていく。
ガクッと変化するAPMをみてその日の残りの時間をホクホク過ごす。大体この日の夜はいい夢が見れる。
Go Conferenceで登壇することができてホクホク。
全てが終わったら古いGORMを消してリリース。
全体に報告してその反応でホクホク。

f:id:rettydev:20211216122514p:plain — 途中経過ホクホク

f:id:rettydev:20211216120429p:plain — 最終報告ホクホク

という流れで進めていました。都度ホクホクを味わいながらモチベーションキープを行うホクホク駆動開発を行っていました。

f:id:rettydev:20211216113640p:plain — ホクホク

3. LTの内容以外に辛かったことある？

LTでは大変な点として、

修正量が多い
PreparedStatementModeを利用するときの注意
既存の実装に苦しめられる

を上げていました。
大変なところは大体これらの区分に当てはまるので、もうちょっと解像度を上げたポイントを挙げるとすると、既存の実装にとにかく苦しめられました。

GORMが用いられていたサービスではRepository層のテストが書かれていなかったので、終始テストを追加してローカルで細かく確認をしながら置き換えを行なっていました。
テストが書かれることに関してはとても良いことだったのですが、Repository層にビジネスロジックが溶け込んでいた影響でとても煩雑なテストになり、開発の速度を出し辛かった & 書いたテストをそのまま残した時にそれが増殖されると負債になりかねないテストとなってしまいそうと判断して最終的にはテストは削除して残しませんでした。