2023年3月のふりかえりです。 引き続き B 社(週4日)にて Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務に携わっています。

B 社

3 月はマネジメント 2 割、プレイヤー 8 割といった割合で対応していました。

マネジメント系

  • エンジニア育成
  • TechLead 業務
    • ひきつづき各エンジニアの成果物のレビューや、設計方針の相談・レビューなどに時間を使っています。
    • 2023 年の開発チーム全体の方向性に思いを馳せる時間をとっていました。
      • 最近は2〜3年前との比較で、非常に開発しやすい開発環境になっていたり DevOps 完備といえる状況になってきています。
      • 基本線は引き続きレガシーアーキテクチャからの脱却と同時にパフォーマンス改善(実行パフォーマンスも開発効率も)を続ける方向です。
        • どこから手をつけると効率がいいのかが結構悩ましいので、そこを中心に考えているところです。
      • 今期はまだやらないと思っていますが、EC のサービスとしてあるあるな、大規模化した際のカート・チェックアウトフローの改善をどうやっていくか、業務側のシステム(わかりやすいのは在庫系とかですね)をどのように刷新していくかという点について想いを馳せる時間を多めにとっていきたいなと考えています。

プレイヤー系

  • 検索関連
    • その時の人気なキーワードで検索できる機能がありそちらのデータの保守を行いました。
    • これまでは SP 版のみ検索機能を提供していましたが、これを PC / Tablet でも提供することができるように基盤部分を整えました。
      • Tablet 版は検索 UI を提供し始めています。
      • PC 版はデザインがまだ出来上がっていないため後日の対応になります。
  • 春のモノ日向けパフォーマンス改善関連
    • 2月から継続して開発していた、サイト内の商品ランキングを50件ほど一覧表示する機能の高速化対応を完了しリリースしました。
      • 結果としては概ね想定通りのパフォーマンス改善ができました。MySQL の slow query が半減、システム全体の Latency が 30% 程度改善といった結果になりました。
        • 既存実装はレガシー Rails あるあるな、アプリケーション側のループを回しながら様々な処理を行ったり N+1 な SQL を発行しつづけるような実装になっていました。
        • 新しい実装は検索システムの導入時に実装した Elasticsearch での商品ランキング生成を流用した API を開発しつつ、フロントエンドから非同期にランキングをレンダリングするように変更することで、サーバー側の負荷を下げつつ、UX 的にも改善する結果にできたかなと考えています。
      • Google のリッチレザルトに対応できていなかった部分やアクセシビリティ面での改善ポイントを投入しており、Google Search Console 上で改善していることを確認できています。
      • Lighthouse の各種数値も改善が見られるので、すこし時間が経過した後に SEO 的にも良い影響がでてくるかなと考えています。
    • 上記の副作用で、商品のランキングに使用している商品の画像のクオリティが以前よりも落ちた、という問題が発生しました。
      • 参照先の画像が従来よりも低解像度な画像を指していたのが原因だったため、商品のオリジナル画像(保持している画像のなかで最も解像度が高い画像)を参照するように変更することで、むしろ従来よりも高解像度にすることができました。
    • さらに副作用で、商品のオリジナル画像が一定のアスペクト比になっていない(歴史があるサービスあるあるですね)という問題があり、ランキング内の画像のサイズが一定になっておらず気持ち悪いリスティングになるという問題がありました。
      • Imgix にアスペクト比を一定にするレンダリングパラメータがあるためこちらを使用することで、画質は高いままにアスペクト比を揃えることができました。Imgix を有効活用できて大変よかったです。
        • 現在のシステムは paper clip を使用していることから、オリジナル画像から複数の解像度の画像を生成して S3 に保持していますが、Imgix の機能を使うことでこのフロー自体削除できるなと考えています。
    • 去年まではモノ日まえに EC2 インスタンスのスケールアウトを行っていましたが、今年は上記等の対応もあり、インスタンス量はそのままで行く予定です。
      • 関連して、EC2 Saving Plan の一つが 3 月で満了しましたが、Saving Plan を減らした状態のままで行こうと考えています。 これは最近のサーバーレス化文脈の進捗が想定よりも出ており、1年契約の単位で契約をしてしまうとカバレッジが超過する可能性があるかなというところを鑑みてそのままで、という判断を下しています。
    • APIGW のキャッシュ時間を 1 分から 3 分へ伸ばしました。
      • キャッシュヒットレートがちょっと低すぎたので、業務側への影響がほぼないであろう 3 分まで伸ばしました。結果、平均 20% ほどキャシュヒットレートが向上したのでバッチリいいかんじです。
  • Developer Productivity Engineering 関連
    • 上記の実装でつかっている新しい React 環境ではなく、レガシー Rails 側のリポジトリに存在している旧 React 環境側の機能撤去や未使用になったライブラリの撤去などを行いました。これにより Webpack コンパイル時間がかなり短縮し、デプロイが数分速くなる結果になりチームみんなで喜んでました。
    • モノ日期間に突入しているため、商品自体や在庫面の状態が普段と違うことが多く、E2E が依存している商品の状態が安定しないことから E2E が Flaky だったり通らなくなったりしていました。これをモノ日だったら一部のテストを省略したり商品を変更したりしやすくするという改善を入れました。
    • Slack の証明書が変更になった影響で、チームで使用していた Hubot が動かなくなり、復旧対応を行っていました。
      • ほぼメンテしていない・さわれない状態になっていたため手探りで色々調査などした結果以下の対応を行うことで解決しました。
        • node のバージョンアップ(8系から16系へ)
          • この対応で証明書の影響がなくなりました
        • hubot-slack のバージョンアップ
          • retired な API (rtm.start)を使い続けていたので、使用可能な API (rtm.connect) をデフォルトで使うバージョンへバージョンアップしました。
          • 元々使用していたバージョンでも設定で変更できましたが、いい機会なのでバージョンアップまで済ませました。
          • とはいえ hubot 自体すでに終わっている感じなので、別リポジトリで開発中の新しい Slack Platform を使う形式に移行するなどしようと考えています。(今回気持ちを新たにしました)
    • レガシー Rails のリポジトリの整理をいろいろ行いました。
      • すでに使用していない app/assets/images 配下の画像群を削除してリポジトリの zip のサイズを 15MB ほど小さくしました。
      • すでに使用していないテーマ系のファイル(サービス開始当初に使っていたらしい、現在は全く使っていないと思われるスタイル群)を削除しました。
        • こちらに関連して、jquery や bootstrap、さらにはその拡張系ライブラリがいろいろな場所に散らばって存在していたり、jquery は 3 バージョン存在していたりなど… といった状況を整理しつつ、概ね 1 バージョンのみになるように削除したり修正したりしました。
          • 結果、asset precompile 後の all.js と all.css のサイズが 4 割くらい削減できたかと思います。Lighthouse のスコアに顕著に影響があったのでかなり感動しました。
      • この環境の sprockets で処理される javascript は ES5 までしか使えないのですが、その理由を探していました。
        • まだ確定ではないのですが、おそらく uglifier を harmony 対応版にバージョンアップする必要がありそう、というところまで調査して一旦寝かせてあります(他作業を優先しています)
    • 静的解析のサービスである Codacy を撤去しました。
      • すでに GHA で必要な CI は全部整えてあることや、Codacy が終了するまで待つのが非常にだるいというのが理由でした。
        • リポジトリが巨大なので git push に付き 15 分くらい待つ必要がありました。また、頻繁に動作しないことも若干ストレスでした。
      • 一方、Codacy のようなサービスのよい点として、継続的に静的解析の結果が蓄積して中長期での改善を観測し続けることができるという点があるかと思います。
        • 僕たちのチームはすでに狙っていた改善は一定達成し終わっており、あとは日々の CI の結果を維持し続ければ静的解析で確認できる範囲のクオリティは担保し続けることが可能という点で、撤去してよいと判断しました。

おわり