こんにちは！クラシルでサーバーサイドエンジニアをやっています @_kobuuukataです！👩🏻💻
私は、現在クラシルサーバーサイドの技術改善チームに所属し、技術的負債の解消に取り組んでいます！
今回の記事では、技術改善チームでどんなことに取り組んでいるかについて紹介したいと思います💁♀
技術改善チームについて
クラシルサーバーサイドの技術改善チームは2021年1月より発足しました。
それまではスピード重視での開発を進めてきたのですが、使っているミドルウェアやライブラリがEOLを迎え、サービス全体に影響のあるものに対して向き合っていく必要が出てきました。
当初はRails, Rubyバージョンアップが大きなミッションでしたが、
現在は「開発スピードとシステムの品質を長期的に維持していくために、開発メンバーとシステムを根本からサポートする」ことを目的としたチームとして、日々の業務に取り組んでいます。
これまでに技術改善チームが取り組んできた主な課題
Rails, Rubyのバージョンアップ
サービス開始当時からRails,Rubyのバージョンアップは行っておらずEOLを迎えていました。
2021年1月時点で利用していたバージョンは以下の通りです😨
Rails v5.0（EOL 2018年4月）
Ruby v2.3（EOL 2019年3月）
バージョンアップ対応を行うにあたっては、テストコードのカバレッジ率が78%と低く品質の担保が出来なかったため、最初にテストコードを追加してカバレッジ率の向上を行いました。
現在は97.7%まで維持できるようになりました↓
また、リリース時は全てのサービスのサーバーに対しデプロイするのではなく、一部のサーバーのみに適用して1日問題がなければ翌日全サーバに反映するなど、できる限りサービスに影響が出ないように工夫しました。
2021年から約1年半かけてサポート範囲内までバージョンアップが完了しました🎉
Rails: v5.0 → v5.1 → v5.2 → v6.0 → v6.1
Ruby: v2.3 → v2.4 → v2.5 → v2.6 → v2.7
バージョンアップ対応の詳細は以下の記事をご覧ください↓
動画変換基盤の改善
クラシルでは内製レシピの動画変換基盤がhlsとwebmで異なっており、複雑な構成になっていました。
こちらをAWS Elemental MediaConvertに移行し、動画変換基盤を1本化しました。
MediaConvertに移行するにあたっては、ElasticTranscoderやECSで実行されていたffmpegでの変換パラメータをMediaConvertに読み替える作業が一番大変でした。。
動画変換基盤がシンプルになったことで、AWSの不要なリソースも削除することができたり、チーム全員が理解しやすいものになりました🎉
アプリケーションログ量の調整
アプリケーションが吐き出すログが多すぎて、インフラ費用が多くかかってしまっていたり、ログ基盤への負荷がかかっていました。
デフォルトで吐き出されるログや、意図的に吐き出しているが閲覧しないものを整理しました。
具体的には以下の対応を行いました
- ActiveModelSerializerのログを削除
- log levelをwarnに変更
- Dynamodbの操作ログを削除
- debug logに変更
- Sentryのログを削除
- sentry sdkのlog levelをwarnに変更
対応後はログ量が最大で1/70まで減りました🎉
技術改善チームではこの他にも
- gemのバージョンアップ
- bundlerのバージョンアップ
- CIの速度改善
- クエリチューニング
- 脆弱性対応
- 使われていないコードの削除
などなど、の負債解消を行ってきました🙌
最後に
クラシルの開発部では、業務の30%を負債解消に当ててもよいルールや、隔週の金曜日に負債解消に取り組むといった様々な技術負債解消に向けた仕組みを試してきました。しかし、日々の業務でなかなか時間が取れなかったり、工数のかかる負債解消には取り組みづらかったりといった課題がありました。
サーバーサイドでは技術改善チームを作ったことで負債解消のスピードを加速させられたのはとてもよかったと思います！
クラシルでは機能開発はもちろん、こういった負債解消にも積極的に取り組んでいることが伝われば幸いです🌸
クラシルに少しでも興味を持ってくれた方がいれば、以下の採用ページをのぞいてみてくださいね💁♀ careers.dely.jp
